AI writes the code. The bottleneck moved.

Something changed in engineering this year and most of the reporting on it buried the interesting half. Yes, a large and growing share of committed code is now written with AI assistance. Yes, individual output is up sharply. The part worth paying attention to is that plenty of those teams are not shipping any faster, and some are shipping slower.

The reports I have read this year all describe the same shape. Time to open a pull request falls. Time for that pull request to get merged rises, in some measurements by a lot. More code, arriving quicker, sitting longer.

The constraint moved and nobody moved with it

Writing code used to be the expensive step. Everything around how teams work was built for that assumption: sprint sizing, estimates, the whole idea that engineering capacity is the thing you are short of.

Generation got cheap. Reviewing did not. Somebody still has to read the diff and decide whether it is safe, whether it does what was actually wanted, and whether it introduced a problem that will surface in three months.

And there is a second thing that got no cheaper at all, which is knowing what should have been built in the first place.

I can see it in my own week

I write the PRD and then I am one of the people who builds it. That has always been two jobs with different rhythms, and until recently they took roughly comparable effort.

The build half is faster now. Genuinely faster, not marginally. The document half is exactly as slow as it was, because none of the hard parts of it are typing. Working out which five words describe the states a vehicle can be in. Deciding whether the alarm should fire at four hours or at two. Sitting with the operations team until you understand why they do the thing that looks irrational on the dashboard.

No assistant shortens that. It can draft you a PRD in nine seconds, and the draft will confidently pick four hours because four is a round number.

Review is where trust gets spent

In a teardown I wrote earlier, the pattern with AI coding assistants was that developers adopt them, then quietly stop trusting them for anything load-bearing while carrying on using them for boilerplate. Nobody announces that. It shows up as a suggestion accepted at a lower rate and a review that takes longer than it used to.

That is the bottleneck in one sentence. The generated code is plausible, which is precisely what makes it expensive to check. A reviewer cannot skim something that looks right and is sometimes wrong in a subtle place. They have to actually read it.

I have argued before that at fleet scale, performance was a UX decision. This is the same species of argument. Review throughput is now a product delivery decision, not an engineering hygiene detail, and treating it as hygiene is how a team ends up with a 60 per cent output increase and nothing extra in production.

What a team is actually short of

If building is cheap and checking is expensive, then the scarce skills are the ones that reduce how much checking is needed.

Writing down what done means before anyone starts, in terms a person can verify without asking you. Killing the feature in the document instead of in review. Being clear enough about the edge cases that the diff does not surface eleven new questions. Knowing which of those eleven questions actually matters.

That list is a description of the job I have been doing under an engineering title. It is also, roughly, the job description for product management.

Where I should declare my bias

I am an engineer moving into product roles, and I have just argued that product judgement is the scarce resource. That is a convenient conclusion for me to reach and you should weigh it accordingly.

What I would say in my defence is that I arrived at it from the wrong direction. I did not decide to move into product and then look for a trend that justified it. I noticed that the half of my week which got dramatically faster was the half I thought was the valuable one, and that the half that did not budge was the half I had been treating as overhead.

What I would measure

Not lines of code and not commits, both of which now measure how fast a model types. Time from pull request opened to merged, which is where the queue actually is. What share of generated changes are merged without substantial rework. How many questions a review surfaces that a decent specification would have answered first.

And the one I would put on the wall: how much of what shipped this quarter, anybody uses.