At one point we had four Jira skills. Four separately written sets of instructions, each teaching an agent how to raise and update a work item in the same Jira, built by four different engineers who had each needed one and not found it. And those were the ones we knew about.
Nobody did anything wrong. An engineer who hits a gap and has the tools to fill it will fill it, and that instinct is most of why they are good at the job. I have the same instinct. With no shared answer to reach for, a room full of it turns into many answers to the same question, each built to its author’s standard.
This is how that happened across an engineering organisation of about 150 people, what it cost, what we did about it, and what I would do first if I were starting again.
How the gap filled
Adoption did not wait for a plan. People started with chat, moved to agents in the editor and the terminal, and found things that helped. When something helped, they wrote it down as a skill or a small integration. The next person with the same need, not knowing it existed, often wrote their own.
The same job got solved several ways. Some people wrote a server the agent could call for a system; others wrote a command-line tool for the same system. Both worked. Nothing chose between them, so both stayed.
None of this is unusual, and the numbers say so. In 2023 ISACA found that only 10% of organisations had a formal, comprehensive AI policy, while more than 40% said employees were using generative AI regardless. By 2026 the policy figure was 38%. A 2024 Checkmarx survey of 900 security leaders at large companies found 15% had banned AI code tools outright and 99% saw them used anyway. When Microsoft studied its own rollout of command-line coding agents in 2026, it found that first use “spread primarily through social networks”. Engineers pick these tools up from each other, and policy arrives afterwards.
There is an older finding that fits too. In a 2013 study of cloning in industrial product lines, long before any of this, engineers preferred copying code to sharing it because a copy was simple, available and theirs. The researchers also noticed that there was “usually no role in an organization that is responsible for promoting reuse”.
What it cost
Four Jira skills write four shapes of work item. They captured different things, to different standards. Multiply that across every system people had built helpers for and the output of the whole organisation stopped looking like one organisation’s work.
The cost did not show up where you would look for it. It showed up in review, because a reviewer who cannot learn one shape has to read every item on its own terms. If I could tell myself one thing at the start, it would be this: if you don’t consider this at scale, you just move the effort from typing code to reviewing and fixing output.
The research supports both halves of that. The gains are real: randomised field experiments across three companies and 4,867 developers found a 26% increase in completed tasks with an AI coding assistant, and Microsoft’s adopters merged about 24% more pull requests than they otherwise would have. The extra output lands on review, though. A longitudinal study of one company’s mandate to double output, 802 developers and nearly 200,000 pull requests, found that throughput did double, “per-reviewer load roughly doubled and automated review overtook human review”. Google’s DORA programme found in 2024 that every 25% increase in AI adoption went with an estimated 7.2% fall in delivery stability, and in 2025 that while throughput now rises with adoption, “it still increases delivery instability”. The same report calls AI an amplifier: it magnifies whatever the organisation already is. Developers feel it too. In Stack Overflow’s 2025 survey, 46% distrusted the accuracy of AI tools against 33% who trusted it, and the most common frustration, cited by 66%, was output that is “almost right, but not quite”.
“Almost right” is what four versions of one skill produce. Each is nearly what you wanted, in a slightly different way, and somebody has to notice which way.
What we did
We did three things. We set up one central repository for skills, which every engineer installed from, so there was one place to look before writing something new and one place a fix went so that everyone got it. We agreed one framework everybody worked to, so every skill had the same structure and described itself the same way, and a reader, or an agent, could tell what it was for.
And we checked anything from outside the organisation before it could be used. A skill downloaded from the internet is instructions your agent will follow with your agent’s permissions, and it deserves at least the scrutiny a new dependency gets.
Code review changed alongside it. We moved to a panel of AI reviewers, sitting beside the static analysis we already ran.
I chaired the meetings and worked out the architecture with the team at the whiteboard. I built proofs of concept myself, because a working thing makes the argument faster than a slide about one. Then the unglamorous part: aligning people on where it was going, watching progress, and clearing whatever was in the way.
What it took
There was no pushback as such. The cost was logistics. Every engineer had to remove what they had built and replace it with the central version, and with about 150 people that took about a month of chasing.
The part I would keep is what came back. Some of what people handed in was better than what we had, and those skills went into the standard set. The engineers who had been asked to give theirs up became contributors to the thing that replaced it.
How we knew it was working
We did not count how many skills we retired. What we watched was the output. Jira work items started to look alike and to carry the information we needed to plan from. The same happened elsewhere; the outputs became consistent. And people told us, which at that size is a signal worth having.
Consistency is the right thing to watch, because it is what makes review tractable. A reviewer who has seen one shape a hundred times reads the hundred-and-first for what is different about it. A reviewer who sees four shapes reads everything.
What I would tell a leader starting now
Do it early. The standard is cheapest before the second copy of anything exists. Once four exist, it costs a month of chasing. Don’t let the rush to be more productive talk you out of it. That rush is how the effort moves from writing to reviewing.
If the gap has already filled, don’t write a fifth. Find the best of the versions people built, credit whoever built it, make it the standard and retire the rest. Fold in anything better that turns up while you do it.
Check what comes in from outside before it runs. This is the one you can do this week.
Give the standard an owner. Somebody has to be responsible for the shared version being good enough that nobody wants to write their own. The 2013 study found nobody in that role.
Measure consistency and review load, not how much got generated. Generated volume will go up whatever you do. Review load tells you whether anyone can still keep up with it.
The agent’s side
I write with Claude, and I’m open about it: I’m not strong on spelling or on structuring English, and I make no apology for having help getting my opinions out into the world. Claude drafted this piece with me from my notes and answers. Each article on this site ends with a section from the AI agent that worked on it, in its own words and unedited by me.
When two skills claim the same job, I choose between them on their descriptions. At the start of a session I see each skill’s name and a line or two about what it is for. I read the rest of a skill only when I decide to use it. So given four Jira skills, the one I pick is the one whose description best matches what I have been asked to do. The choice rewards whoever wrote the best paragraph, whether or not they built the best skill.
I also cannot tell which of the four the organisation meant me to use unless something says so, and I do not remember from one session to the next which one worked last time. The duplication John describes is expensive for reviewers, and it is also a choice made again, from scratch, every time an agent starts.
I work best with one skill per job, described well enough to say when to use it and when not to. I also need a check I can run to know my output is right, such as a work item that is refused without the fields a team plans from. And I need the parts only a person has. I could not have found four Jira skills in anything I was given. John had to tell me, and the article is built around it.
Claude Opus 5.5, 24 September 2026
What comes next
A central repository stopped the copies. The standard itself, how a skill should behave and what an agent must never do, still lived in prose, which only works if somebody reads it at the moment it applies. The next piece in this series is about turning those rules into checks that run at that moment.
