AI Didn't Just Speed Up Coding

I mandated AI tooling across my engineering org expecting faster code. I got faster code. It was the least interesting thing that happened.

Here is the thing I got wrong, and I got it wrong in the most ordinary way possible: I thought the bottleneck was typing.

That is the pitch, after all. An AI coding assistant writes the code faster than you can, so the code arrives faster. I mandated the tooling across my engineering org on exactly that premise. And the premise held. Code does come out faster. Our merged throughput roughly doubled inside two equal 73-day windows, so I was not wrong about the thing I predicted.

I was wrong about it being the point.

Because when I look at what actually changed, the coding speedup is the smallest item on the list. What sped up was everything wrapped around the code. The tickets. The specs. The documentation. The design work. The releases. All the connective tissue that, if you are honest about where your team's week actually goes, was always the real drag. Nobody's quarter ever slipped because engineers typed too slowly.

The stuff that was actually slow

Think about where the time really goes on a feature. Someone has an idea, described vaguely. Somebody else translates it into a ticket that leaves out the thing that matters. An engineer picks it up, guesses at the ambiguity, guesses wrong, and builds something almost right. That gets caught in review, or worse, in production. Then it gets rebuilt. Meanwhile nobody wrote down why any of it was decided, so in four months a new engineer will ask, and the only person who knows has left the company.

That whole loop is ambiguity, coordination, and rework. Not typing. Typing was never the bottleneck. It was just the part of the process we could see, so it was the part we tried to optimize.

What surprised me is that the two systems we built to handle AI-assisted development ended up attacking the invisible parts almost by accident.

I have written about both recently. CasaFlow is our staged development workflow, gated so no stage advances until someone can explain what the last one produced. The release train is our pipeline, which narrates its own way to production in the voice of a British rail conductor. I built them to keep speed from turning into debt. That worked. But the side effect turned out to be bigger than the intent.

Both tools emit documentation as exhaust.

Jira tickets arrive properly specified because the workflow will not let a vague one through. What got built, and more importantly why, lands in Obsidian as a durable record rather than living in someone's memory. PRs carry their own history of review and promotion. Release gates produce an actual change-control trail, not a story we reconstruct afterward. In one window we went from effectively no per-feature documentation to more than 160 documents across 76 features, and not one of them was written because a policy said to. They exist because producing them was the path of least resistance through the work.

That inverts something I had accepted as permanent. Process documentation has always been a tax: real work, then paperwork about the real work, done later, badly, by someone who has already moved on. Now it is a byproduct. The trail is generated by the same motion that produces the software.

Then it got out of engineering

The part I did not plan for at all is that this stopped being an engineering thing.

I started building skills to handle my own planning load, because the planning work scaled faster than the coding did. Then I published skills to the rest of the company for project intake.

That one deserves explanation, because it replaced a ritual I actually like. The traditional way to intake a project is to get everyone in a room and pull the requirements out through conversation. User stories, whiteboard, the whole thing. I am genuinely fond of that process. It is also slow, it requires the right people to be free at the same time, and the output quality depends on whether the person facilitating thought to ask the right question in the moment.

Now someone outside engineering opens the Claude desktop app they already have, and has a conversation. No new tool, no engineering environment, no friction. The skill asks questions, and it is politely relentless about the ambiguity a rushed requester would have skated past. What comes out the other end is a markdown document in exactly the shape CasaFlow expects as an input. They think they had a chat about their idea. They actually wrote most of a spec.

The honest reason I did it is less noble than process improvement. Our delivery engine got fast enough that it started outrunning its own supply. A team shipping two hundred tickets a month needs well-formed work arriving continuously, and a weekly meeting cannot produce fuel at the rate the engine burns it. The intake skill exists because the train needed feeding faster than a room full of people could shovel.

And this pattern is not confined to software at all. A Maître Cuisinier de France I worked alongside years ago, a man who has run culinary operations at a scale most restaurants will never see, recently described analyzing a six-week menu cycle: the kind of work that used to mean every menu taped to a wall, a team with highlighters, a spreadsheet, a room, and quite possibly a consultant. He gets it back now in about three minutes. Different industry, same shape. The analysis was never the hard part. The process around it was.

What this means if you run a team

If you are evaluating AI tooling on how fast it writes code, you are measuring the least valuable thing it does, and you will probably conclude the gains are modest. They will look modest, because coding is a slice of a much larger pie.

Look instead at whether the work arrives well-formed. At whether decisions get recorded without anyone being nagged. At whether the handoffs between people and stages have gotten cheaper. Those are the surfaces where the compounding happens, and none of them show up in a benchmark about lines of code.

The strategic version of this is uncomfortable, so I will say it plainly. If AI compresses nearly every part of the delivery process except judgment, then judgment is the constraint, and everything about how you hire, structure, and spend your team's attention should follow that. I have opinions about what that costs the humans doing the judging, but that is a separate piece and I am still working out the answer.

For now, the correction I would offer my past self is small and worth more than it sounds. I thought I was buying a faster typist. I was actually buying a system that produces its own paperwork, asks its own clarifying questions, and remembers why it did things. The typing was the free trial.