The announcement is easy to picture, because most of us have now seen a version of it. We are going to be an AI-first company. Licences arrive on Monday. A short message goes round about how everyone is expected to use the new tools.
By Friday, two or three people are visibly flying. Everyone else has opened it twice.
The part worth noticing is who those two or three are. In most of the teams I have watched, they were already doing it — at home, in the evenings, on their own subscriptions, months before anyone bought anything. The rollout did not create them. It found them, and then quietly took credit for them. Everyone else, which is most of the team, is still waiting for someone to make this make sense for them.
Meanwhile the usage line goes up, because those two or three use it constantly. And the question closes. Tools distributed, usage rising, problem solved.
The problem is not solved. Very little about it has been touched.
Why This Is Not a Small Problem
I wrote earlier about what happens to a codebase when you accelerate it without steering it — AI won’t fix your architecture. The short version: a model that is fast and usually right is still making a great many choices that nobody decided. Each one is plausible. Each one is roughly in the right direction. Aggregate enough of them and the system arrives somewhere — just not anywhere in particular.
Left alone, a fast and mostly-right machine doesn’t hold a direction. It only gets somewhere sooner.
That is the consequence of an unsteered rollout, and it is not cosmetic. It shows up as a codebase harder to change than it was a year ago, decisions nobody can reconstruct, and conventions that exist in four incompatible versions because four people each asked a model and each got a reasonable answer.
The Opportunity Is Real
None of that is an argument against the tools. The transformation underneath the noise is genuine: building software has become cheap enough to change what is worth building — not typing faster, but which ideas now clear the bar.
This is worth doing. Which is precisely why it is worth not squandering.
Why Usage Becomes the Answer
I do not think companies land on the usage metric out of laziness. They land on it because the better question is genuinely hard, and something has to go in the report.
The better question is what should I be looking at? — and while that goes unanswered, you look at what is already being counted. Seats. Active users. Tokens. The line goes up.
That number is measuring something real. It tells you the tool is being used, which is a floor worth clearing. It just isn’t evidence about the thing you wanted to know. It’s attendance.
And it gets worse if you lean on it. Goodhart’s law — a measure that becomes a target stops being a good measure — is old and well attested. Ask for usage every month and usage is what will improve, including where reaching for the tool was the wrong call.
What a Real Rollout Starts From
The obvious alternative is to give good people good tools and get out of the way. I have made that argument myself — but look again at who took to it fastest. They taught themselves, before there was a policy, because they wanted to. The approach works beautifully on the people who needed no approach, and says little about everyone else.
What has worked for us starts from the other end: consistency first, adaptation second.
Before anyone is handed an agent, there is a set of practices fitted to this codebase and this organisation — not a generic best-practice document. Much of it is unglamorous and old: SOLID, continuous integration, a deployment pipeline that actually works. Those make good opening rules precisely because they are well understood and easy to state. Someone who understands them turns them into a harness: the conventions, the constraints, and the checks the model works inside.
The reason this comes first is specific and boring. If four developers each work inside their own private setup, the code that comes back disagrees with itself: exceptions raised here, error values returned there, two defensible conventions for the same decision. Every individual change passes review. The codebase quietly stops being one thing. A shared harness makes that a decision instead of an accident.
Then it adapts, because projects are not alike. One needs its debt paid down before anything else is worth attempting. Another has clean foundations and wants throughput on new features. Same starting point, different next move.
Two Ways to Get This Wrong
The interesting failures are not carelessness. They are managerial decisions, made sensibly, at a slight distance from the work.
The harness nobody is allowed to fix. I have seen a setup imposed from above and kept in a repository of its own. Contributing to it was permitted in principle — through architectural approval and a round of discussion. In practice the process to change a rule ran three times longer than the change itself, so people stopped proposing changes and started working around it. Within months there was no standard left, only a document describing one.
That is the trap on the other side of this argument. A harness so closed that the person inside it is confirming the machine’s suggestions and nothing else — next, next, next — is not a good harness. It is a highly standardised one, and those are not the same thing. And it fails by the same mechanism as having no harness at all: when the rules stop matching the work, moving fast means letting the model decide, and you are back to a system that goes somewhere in particular only by accident.
The cheaper model. A team was told to stay on the older one, because the newer cost about a dollar more. The newer one also had a much larger context window — so on the old one, long pieces of work kept hitting the limit and having to be compacted and restarted, while on the new one the same task went through in one pass. Faster, and in the end cheaper. Nobody was being foolish; the price difference was real and sat in a column somebody owned. What was missing was a person close enough to the work to know that a dollar in that column can buy back several elsewhere.
Both mistakes are the same shape. Somebody made a reasonable call about a system they were not close enough to see.
The Third Thing You Build
For years we built two things at once: the code, and the tests that hold it honest. There are now three. The harness is built alongside the system, in the same commits, by the same people.
That sounds like more work, and at first it is. Designed well, it is considerably less — because the third thing is what makes the other two cheap. A team that isn’t building it isn’t adopting AI; it is running AI commands.
This is also the shift in what a developer’s job is. Producing code is no longer where the value sits; the model does that well. What remains is looking after the system that produces it — because a well-maintained system produces code of the quality that person would have written by hand, and produces rather a lot of it.
For the company, that turns something soft into something structural. Practices used to be agreements: we said we would handle errors this way, and mostly we remembered. Encoded into the harness, they stop depending on everyone’s discipline on a bad Thursday.
And it lifts a real weight off the people doing the work. When the conventions live in the system rather than in everyone’s head, the cognitive load drops, and the attention that gets freed goes somewhere useful: how this should actually behave, which version is worth building, when, what the customer will do with it. The programmer finally has time to think about the customer.
How to Start Without Poisoning It
The instinct at this point is to get the harness right first and hand over something finished. I do not think that is the best move either, because there is no version of this you download and run. It always has to be adapted to the codebase you actually have.
So start with people rather than with completeness. Go in and find the ones who already want this — most organisations have two or three — and let them do the adapting, including the hard part: finding where standardisation should stop. They will accept a rough first version, because they already understand that the first version is always rough.
And leave everyone else alone for now. Not indefinitely, and not because they are the problem — but a half-built system handed to someone who did not ask for it produces exactly one outcome, which is a person who has now personally verified that this does not work. They will be right, at the moment they say it, and you will spend a year arguing with a true statement.
Not everyone comes to work to learn a new craft on top of the one they were hired for. That is a legitimate position, and it does not need converting. Bring those people in when the thing works well enough to be obviously worth their time, and let them judge it then.
The Real Work of a Leader
Here is the part that I think gets missed, and it is the more forgiving half of this argument: you do not have to understand how any of it works. You do not have to write the harness, or read it, or have an opinion about how errors are handled.
What you have to do is make sure it exists, that someone owns it, and that the team is expected to extend it rather than route around it. And then hold the boundary — standardise what is worth standardising, leave open what people need in order to keep developing it, and move that line as the project changes. That judgement is not delegable, because it is not a technical question. It is a question about your organisation.
That is what this asks for. Not a transformation programme, and not a bigger budget. Attentiveness, a working understanding of what the technology actually does, and the willingness to build the conditions rather than buy the tools and hope.
Where to point that attention first is the subject of the next piece: the constraint has moved, and it is not sitting where most of us are still looking.
What would you have to stop doing to give this the attention it needs?