Definition
How to roll out Codex and Claude Code across an engineering organisation
Rolling out Codex and Claude Code across an engineering organisation is four pieces of work, and buying licences is none of them. Skills packages come first: the repository conventions, tools and context an agent loads before it does anything, owned once and pointed at whichever vendor harness a team uses. A permission and identity model decides which repositories, systems and credentials an agent may reach, on whose behalf, and which actions stop for a person. Agent-written changes then go through the review path every other change already takes, with their provenance recorded on the change. And the skills themselves are evaluated in CI, because a skill that has drifted from the codebase is worse than no skill at all. Run it team by team, starting with one repository that already ships often, and read adoption from merged changes and rework rate rather than seats activated.
What a rollout actually consists of
A licence gives every engineer a coding agent and nothing else. The layer around it is what decides whether the third team gets the same agent the first team did: the engineering below, and one person answerable for it.
- Skills packages
- How this codebase is tested, what a good change looks like here, which internal services may be called and how. Written once and loaded by Codex, Claude Code or Cursor as the work requires, rather than reinvented per team.
- Permissions and identity
- Which repositories, cloud accounts and credentials an agent reaches, and on whose behalf. Agent identity is the part most rollouts postpone and the part that decides what a mistake can touch.
- Review gates
- The same pull request, the same code owners and the same required checks as every other change, with provenance recorded on the change so nobody has to guess later which ones an agent wrote.
- CI evaluation
- The skills are tested like code. A package that has drifted from the repository fails a check, rather than quietly producing worse changes for a quarter.
- A named owner
- One person accountable for the skills estate and the permission model. Without that, everything above becomes nobody's job by the third team.
The order matters more than the tool choice
Start in one repository that already ships frequently and has tests worth trusting, because it is the only place you can tell whether the agent helped. Get skills and permissions right there, in that order: skills give the agent enough context to be useful, permissions decide what its mistakes can reach.
Review gates come next, before the second and third team rather than after them. CI evaluation of the skills is the piece most organisations defer, and it is the one that decides whether the estate still works in six months. The trade-off is honest: done in this order the first three weeks look slow, because the visible output is configuration rather than merged pull requests. A rollout that starts with breadth instead buys three weeks and then spends a quarter unpicking a hundred private conventions formed in the first fortnight.
Where do-it-yourself rollouts stall
None of this is beyond a competent in-house team, and plenty of organisations do it themselves. The ones that stall tend to stall in the same places, and every one of them is organisational rather than technical.
- Skills nobody owns
- Each team writes its own, none are reviewed, and nobody can say whether the setups agree. The estate grows faster than the ability to reason about it.
- Permissions granted per person
- Access follows whoever asked, so what an agent can reach is whatever its operator happens to hold, and no one can answer what a bad run would have touched.
- A side channel to production
- Agent-written changes attract a lighter review because they read tidily. Tidy is the failure mode: fluent code passes eyes that would have caught the same error written badly.
- Adoption measured by licences
- Seat counts rise, nobody can name a change that reached production because of the tools, and the renewal conversation has no evidence in it.
An unowned skills estate accrues debt you can price
Leaving this layer unowned has a price, and on one engagement we can put a measurement against part of it. On an enterprise platform we hold the lead architect role for, the skills estate had drifted far enough that re-architecting it produced a material reduction in the average cost per session. The engagement file records the measurements and their provenance; both are 1AYM measurements on that platform, taken before and after the change, not a benchmark and not a forecast.
The mechanism was dull, which is the point. Skills written as flat, monolithic files dragged far more context into every session than the task in front of them used. Nobody had decided that; it accumulated, one unreviewed package at a time, which is exactly what an unowned estate does. The fix was architecture rather than heroics: routing, description budgets and evaluation, the same layer this page describes.
How do you measure adoption honestly?
Seat activation measures procurement. It tells you what was bought, not what changed. A handful of numbers, read per team and against that team's own baseline, tell you whether the rollout worked.
- Share of merged changes with agent involvement
- Recorded on the change automatically, never self-reported. A survey of how useful engineers found the tools measures enthusiasm.
- Time from first draft to review-ready
- The interval these tools genuinely compress. If it has not moved, the skills packages are too thin to carry the codebase.
- Reviewer time per change
- If this is rising, the rollout has moved cost from author to reviewer rather than removing it. That is a real result and it belongs in the report.
- Rework within thirty days
- Changes reverted or substantially rewritten. The number that says whether faster output was worth having.
When not to roll out
Do not roll out to an organisation that cannot merge a small change quickly today. Agents raise the volume of proposed changes, so if review is already the bottleneck, more proposals make it worse and the tools take the blame for a queue that predates them.
Do not roll out where nobody senior owns the outcome. Skills, permissions and gates are decisions with trade-offs attached, and a rollout without an owner reverts to whatever each team improvises.
And do not buy a programme where one squad and a fortnight would settle the question. Put Codex or Claude Code on a real repository with two weeks and a target, and count the changes that merged. If the answer there is no, an organisation-wide rollout will not rescue it, and the money is better spent on the tests and the review capacity that would have made the answer yes.
Related questions
Should we standardise on one coding agent, or run Codex and Claude Code side by side?
Run both, and write the layer around them once. The agents differ in harness behaviour and in what they are strongest at, and teams will form preferences you cannot usefully overrule. What must not differ is the skills packages, the permission model and the review path, because those are what make the estate legible. Standardise the operating layer, keep the tool a team-level choice, and revisit it when a measured difference in the numbers appears.
Do we pilot with one team first, or roll out to all of engineering?
One team, one repository that ships frequently, and a fixed end date. A pilot exists to produce evidence a wider rollout can be designed from: which skills the codebase actually needs, where permissions bite, what review load looks like. Rolling out to everyone first inverts that, and the conventions formed in the opening fortnight are then the thing you have to unpick before anything can be shared.
How long before engineers feel the difference?
Individuals feel it in days, because the tools are useful on day one without any of this. The organisation feels it when skills packages carry real repository context and the review path has stopped being a queue, which is usually six to twelve weeks depending on how much of the permission and identity model already exists. Anyone promising an organisation-wide change inside a fortnight is describing licence activation.
Who owns the skills packages once the rollout is done?
The client, in the client's repositories, reviewed like any other code, with a named owner for the estate and a maintainer per package. If an external firm holds the skills, the organisation has bought a dependency instead of a capability. The test is simple: can your engineers change a skill, evaluate it in CI and ship it without anyone external in the loop.
What do we do about engineers already using these tools without a policy?
Treat that as the starting material, not as a violation. Find out which repositories, which tools and which credentials are already in play, then write the permission model and the skills packages around what is genuinely happening. A ban produces the same usage with less visibility, and the conventions those engineers have already worked out are usually the best first draft of the skills estate.
Further
- AI harness & platform engineering · The engagement this is bought as: architecture, skills packages, guardrails and CI on Codex, Claude Code and Cursor.
- What is an AI harness? · Who builds the runtime the rollout sits on, and what the organisation still has to write.
- AI, data and automation enablement across a global agency · The engagement file behind the skills-debt measurements, with provenance stated.
- Agent proposes, verifier gates · The gating pattern behind the review and CI half of a rollout.
We build these systems for a living. See the engagement files for what that looks like in practice, or write to us if yours is the next one.
Last reviewed · 1AYM