The Cheapest Question
I get invited out to talk about AI quite a bit now. Different rooms, different industries, same first question from the floor: which tools do you use?
I understand the instinct. It is the cheapest possible question, and if the answer were a tool then the answer would be purchasable. You could put it on a slide, sign the contract, and be done by Friday.
The honest answer is that our tool choices are not interesting and mostly not ours. We are standardised on Claude, we use Cursor, we use the frontier models the way everyone does. If you copied our vendor list exactly you would get almost none of what we got, because the vendor list was never the hard part.
So this is the start of a short series where I give away the recipe instead. Three things, one post each. All three are copyable, none of them are glamorous, and two of them will sound like things you already decided not to do.
One piece of context first, because it changes how you should read everything that follows. I work at AutoUncle. We are a Danish company of sixty-one people who sell software to car dealerships. No research lab, no AI budget worth bragging about, and a product that has nothing to do with artificial intelligence. If a company like that can get somewhere on this, the excuse that you would need to be a technology company is not available to you, which is rather the point of writing it down.
Where We Actually Are
Before the recipe, the evidence. I am not going to make the argument from vibes, and you should be suspicious of anyone who does.
Fewer than thirty of those sixty-one people sit in engineering, and that number has not moved in two years. Here is what happened to the amount of work each of them ships in a week.
The measure is merged pull requests. If that phrase means nothing to you: a pull request is one self-contained parcel of change to the software, proposed, checked, and then merged into the real product. It is the closest thing software has to a unit of finished work, and counting them per person per week is roughly like counting how many jobs a workshop completes.
Roughly five times more, same team, in under a year, and the quarter is not finished.
A caveat I want to put in myself rather than wait for someone to put it in for me: merged pull requests measure throughput, not value. A pull request can be a typo fix. We deliberately do not measure lines of code, because that metric is worse and rewards exactly the wrong behaviour. What the number is good for is direction and magnitude, and the direction and magnitude are not subtle.
The part I find more telling is where the usage sits. Across thousands of conversations with Claude between February and June, 56 percent of them were outside engineering. Sixteen different teams. Fifty-four of our sixty-one people have a licence, and in a normal week around 85 percent of us use AI for something.
For comparison, Gallup put daily-or-weekly AI use at 26 percent of US employees at the end of 2025, and Deloitte put the share of organisations actually running agents in production at 11 percent. We are in the 11 percent, at sixty-one people, selling software to car dealers.
The interesting number is not five times the output. It is that most of the usage is not in engineering.
What People Expect the Answer to Be
When I say it is not the tools, the follow-up guesses arrive in a predictable order.
Model choice. The models are extraordinary and they are close enough to each other that picking between them is a procurement exercise, not a strategy. Intelligence stopped being our bottleneck more than a year ago. I wrote about that in Still True: when AI fails on a task, it is almost never because the model was not smart enough.
Prompt craft. Marginally useful, wildly overrated as an organisational capability. The gap between people who get good results and people who do not is much less about phrasing than about whether they are willing to let the model do the work. That is a posture, not a technique, and I made that case in The Humility Gap.
A rollout and a mandate. Buy everyone a seat, run a training session, put it in the objectives. We did versions of all three. They are necessary and they are nowhere near sufficient. A seat with nothing behind it produces a colleague who tries it twice, gets generic output, and quietly concludes the technology is overhyped. They are not wrong about what they saw.
Every one of those guesses is a purchase or a memo. That is why they are the popular answers. The three things that actually mattered are all build decisions, and all three of them are infrastructure in the broad sense: they are the boring layer underneath, which is exactly why most companies skip them.
The Three Things
Here they are, in the order they have to happen, each with the reversal that makes it worth a post of its own.
A platform, built for everyone in the company
Platform engineering is not new. It was invented at scale, by companies with thousands of engineers, because only at that size did the coordination cost justify building the paved road. At thirty engineers it was premature scaling, and anyone who said so was right.
Two things inverted that. Output per person went up several times over with no change in headcount, so the coordination problem arrived at a company size that has never had it. And the road got cheap enough to build. The twist is who it now serves: when somebody in sales wants to run an automation, the platform team's customer is no longer just developers.
The practice is thirty years old. What is new is that it is affordable at our size, and that it serves the whole company.
Company knowledge, written down and structured
We all tried this before. Employee handbooks, wikis, Notion, best-practice documents, onboarding guides. The theory was beautiful: write down how we work, deploy it to everyone, stop relitigating the same decisions. In practice it rotted, because nobody read it.
The usual conclusion is that documentation has bad returns. That conclusion was correct and it stays correct, about human readers. What changed is that a second kind of reader turned up, and this one does what the document says.
The documentation was never the problem. The reader was. We did not get that analysis wrong. We got a new reader.
Judgment about where agents belong
With the first two in place, the constraint moves. It stops being can it and becomes should it, which is a much harder question and a human one. Most of my week is now spent on four tests that have to pass before we put an agent on a job.
It is also the post with the uncomfortable part in it, about what happens to the people whose work an agent takes over. Our marketing team is the clearest example I have. They still write, they still decide what is worth saying, and they still own whether it is any good. What moved is the balance of the week: far less of it on assembling each piece, far more on building the machinery that gets the work out of the door.
The question shifted from what do we publish to how do we publish. That is a platform question, and every function is starting to ask it.
Ahead Is Not Finished
One number to explain the urgency, because the recipe is worth nothing if you plan to start in two years.
METR, an independent research group that benchmarks AI systems, measures how long an agent can work on a task on its own before a human has to step in. In 2022, when ChatGPT launched, it was about thirty seconds. In 2025 it was around two hours. In 2026 it is around fourteen. Whatever you think of any individual model, that is not a curve you catch up to by watching it.
I do not think we are special, and I want to be clear that I am not claiming we solved anything. We were early, we were stubborn about the boring layer underneath, and we were willing to be wrong in public a lot. That is genuinely all of it, and all three are available to anybody reading this.
The Series
Three posts, in the order they have to happen.
- DevOps 3.0. What happens when somebody in sales wants to deploy an automation, why ad hoc setup stops being survivable once you take the human out of the loop, and why the developer platform now has to serve the person in finance.
- The Documentation Was Never the Problem. Twenty years of handbooks nobody read, why the reader was the bug rather than the writing, and what happened when we moved the company manual into the same version-control system our engineers use for code.
- The Agent's Ticket. Four tests before an agent gets a job, where we deliberately do not use AI, and the honest version of what it did to roles and hiring.
If you only read one, read the second. It is the one people find least exciting and it is the one that changed the most.