Code got cheap. The organisation didn't.

In April 2026 Sundar Pichai wrote that “75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall.”

I have put that sentence on a slide. What people react to is the size of the number, and the half of it they carry out of the room is the half that ends at “AI-generated”. The four words after that are the ones doing the work. Read whole, the figure is not a claim about how much code a machine now writes. It is a claim about how much code a person still has to approve.

Writing code was never the constraint

I have spent the last few years building a quality engineering function at a music retailer that ships every day. In that time I have not seen a release held up because somebody could not type fast enough.

What holds a release up is everything downstream of the typing. Deciding what the change should actually do, and confirming that the edge cases, the security boundaries and the data contracts still hold. Getting it through a review by someone who will have to maintain it in a year, and reaching the point where a team is willing to say yes, this can go to customers.

Agents made the cheap part cheaper and left the expensive part alone. An organisation that doubles its output without touching its capacity to verify has not become faster, it has moved its queue. The same review, the same pipeline and the same person deciding whether to ship are all still there, with more arriving at them, and less of what arrives was thought about by a human first.

The review trade-off

Reading every line of generated code protects comprehension. It also removes the speed the agent just created. Skimming it recovers the speed and quietly gives up the comprehension. Both are defensible, neither is free, and the same developer is asked for both at once: move fast, and stay accountable for what they merged.

I do not think that conflict has a clean answer, and I distrust anyone who offers one. What I have found is that it gets easier the less it rests on a person’s attention. If a change has to pass a suite that is fast, deterministic and trustworthy on the first read, a reviewer can spend their attention on intent and design rather than on working out whether the thing functions at all. The review does not get skipped. It gets aimed at the part a machine cannot judge.

That is the boundary I set out in Automation that keeps human judgment: tooling investigates, drafts and challenges, and a person approves. Cheap generation puts far more traffic through that boundary without moving it.

What the organisation did not change

The engineering leaders I talk to describe the same shift. Less typing, more specification, more judgment about what should exist, more verification that what was produced does what was claimed. I have no idea how representative that sample is, and I am not going to pretend otherwise.

What I do notice is that almost none of them describe a structural change to match it. The role definitions are the ones written before agents. Onboarding still treats the codebase as something a new joiner reads their way into. Progression still rewards output that is now close to free. The stated belief and the operating model have come apart, and the operating model is the one people are actually paid against.

I am not exempt from that. I run a function whose habits formed when the scarce thing was somebody who could write a reliable test, and I have been slower than I should have been to ask what it ought to reward now that writing one is the easy part.

Where the constraint went

Optimising for development capacity was the right call in every organisation I have worked in over the last decade. It was also, by the end of that decade, the wrong thing to optimise for.

When generating a change costs almost nothing, the limit on how fast an organisation ships becomes how quickly it can show that the change is safe, and how far it trusts that answer without a person deriving it again by hand. That is quality engineering, and it stops being a phase near the end of delivery and starts being the thing that sets the pace of it.

I would rather state that as a position than dress it up as a forecast. I lead a quality function, so I am not a neutral party in where the work lands. The argument survives a disagreement about who should own it. Somebody has to, and in the organisations I can see clearly enough to judge, nobody has been asked to.

What I am watching

The measure I want, and do not have, is how long it takes a team to get a trustworthy answer to whether something can ship. Not test count, not coverage, not how much of the diff an agent wrote. Time to a decision somebody will stand behind.

Code got cheap. Whether that turns into delivery or into a longer queue rests on the part nobody has automated: the willingness to say what “good enough to ship” means here, and to build the evidence that answers it.