What Product Managers Actually Do When Agents Write 75% of the Code

75% of all new code at Google is now AI-generated and approved by engineers. The bottleneck in building software has moved off implementation and onto the decision about what to implement. That repositions product management around three things: the precision of the specification, the design of the evaluation, and the choice of problem. Backlog administration is what falls away.

The number that moved the bottleneck

When agents write the code, a product manager's job concentrates on three activities. Specifications precise enough for an agent to build against without asking. Evaluations that prove the result is good enough. And the choice of which problem is worth solving. Backlog administration, ticket grooming and status synthesis lose most of their value.

The trigger for that shift is easy to date. At Google Cloud Next in April 2026, Sundar Pichai stated that 75% of all new code at Google is AI-generated and approved by engineers, up from 50% the previous autumn. He also described a complex code migration completed six times faster by agents and engineers together than engineers could have managed a year earlier.

Take the exact percentage with caution, and take the direction seriously. A doubling of the AI-written share inside 6 months is a statement about where the constraint no longer sits.

Adoption is near-universal. Trust is not.

The 2025 DORA research, run by Google Cloud across nearly 5,000 technology professionals, found 90% adoption of AI among software development professionals, with a median of two hours a day spent working with it. More than 80% said it improved their productivity and 59% said it improved code quality.

Then the same survey asked about trust. Only 24% trusted the quality of AI-generated code a lot or a great deal, and 30% trusted it a little or not at all. Stack Overflow's 2025 survey of developers found the same tension from a different angle. There, 66% named answers that are almost right, but not quite, as their leading frustration, and 45% said debugging AI-generated code takes more time.

What the bottleneck moved to

Generation got cheap. Verification did not. DORA's follow-up report on the return from AI-assisted development, published in May 2026, gives the effect a name: the verification tax. That is the extra work of checking whether generated code is correct, secure and consistent with the architecture around it.

That tax is the whole story for product management. If code is nearly free and correctness is not, then the artefacts that determine correctness become the scarce inputs. Those artefacts are the specification and the evaluation, and both of them are product work.

Specification quality: the skill that repriced first

Writing precisely was always a good product management habit. It was rarely the thing you were promoted for. That has changed, because the reader changed.

A spec is an executable contract now

A human engineer reading an ambiguous requirement does something valuable and invisible. They notice the gap, fill it from context about the product, and often walk over to ask. An agent does none of that. It resolves the ambiguity silently and ships the resolution.

So every sentence you left vague becomes a decision made by a system with no stake in the outcome. I would rather read a two-page spec that closes every edge case than a ten-page product requirements document that closes none of them. The second one used to be safe because a person absorbed the risk. It is not safe now.

This is the same shift that turned prompt writing into a discipline about supplying the right surrounding material, a change traced in the piece on how context engineering replaced prompt engineering. The spec is the highest-value piece of context a product manager controls.

What the spec-first tools force you to write

You can read the shape of the new artefact directly off the tooling. GitHub's Spec Kit, an MIT-licensed toolkit that works with any coding agent, structures work into named phases: constitution, specify, plan, tasks, implement and converge. The repository passed 132,000 stars by August 2026. Amazon's Kiro, a spec-first agentic development environment, produces a requirements document, a design document and a task list before any code is generated.

The constitution step deserves attention. It holds the standing constraints that apply to every task, not just this one: how errors surface, what the product never does, which data is authoritative. Most teams have those rules only in the heads of two senior people, which is exactly the arrangement agents cannot use.

This table is a working template, not a measured finding. It reflects the gaps that recur in agent output, and different codebases will surface different ones.

Evaluation design: what replaced acceptance criteria

The second skill to reprice is the one most product managers have never been asked for. If any part of the feature calls a model, your acceptance criteria are built on an assumption that no longer holds.

Acceptance criteria assumed the same input gives the same output

Deterministic software lets you write one test per rule. Run it, get a pass or a fail, move on. A model gives you a distribution of behaviours, so a single run tells you almost nothing about what a thousand users will see.

An eval set is the replacement. It is a scored collection of cases, drawn from real traffic and deliberately stressed with hard ones, run against a rubric with a threshold agreed in advance. The practical construction of one is covered in the guide to building an evaluation suite for a language model feature.

What a usable eval set contains

Four things, and the fourth is the one teams skip. Real cases sampled from production rather than invented. Adversarial cases chosen because you expect them to fail. A rubric that says what good looks like in words a second person would apply the same way. And a threshold, written down before the run, that decides whether this ships.

The eval set is a product artefact, not a quality assurance artefact, and the product manager should own it. Where the threshold sits is a judgement about what users will tolerate, which is not an engineering question. Handing that decision to whoever wrote the harness is how features ship with unknown failure modes.

Problem selection: the part that did not automate

The third skill is the oldest one, and it gains value for an unglamorous reason. Cheap building raises the price of choosing badly.

Cheap building raises the price of choosing wrong

The intuition runs the other way, so it is worth stating carefully. If a feature takes a week rather than a quarter, the cost of any single wrong choice falls. But the number of choices your team makes per quarter rises sharply, and the cost of maintaining everything you shipped rises with it. Volume, not unit cost, is what breaks a roadmap.

There is a signal in how people use agentic tools that makes the same point. Anthropic's Economic Index reported that the median Claude Code session producing a piece of work contained a single human prompt, against 13 rounds of back-and-forth in a chat interface. When delegation goes up, the number of chances to correct course goes down. The brief carries the whole weight.

That is also why so many agent deployments stall before production rather than after. The recurring causes are documented in the breakdown of how agent pilots actually fail, and problem choice sits near the top of the list.

What is losing value: the ticket economy

Something has to be on the other side of the ledger. Otherwise this is just a list of things that got more important, which is how every role change gets described and why nobody believes it.

Grooming was a ritual built on scarcity

Backlogs existed because engineering capacity was the constraint. Ranking 200 items was a rationing exercise. Refinement meetings existed to convert vague intent into something a scarce resource could act on efficiently. Status reports existed because progress was hard to observe.

All three of those functions are being absorbed. Ticket text, release notes, meeting summaries and progress rollups are now generated well enough that spending a day a week on them is hard to defend. The work does not vanish, it gets cheap, and cheap work stops being a reason to employ someone.

The exposure is uneven. A product manager whose week is mostly coordination between teams is in a similar position to the layer of management analysed in the piece on what happens to middle management after agents. The activity was always a proxy for something, and the proxy is now measurable directly.

The verification tax lands on the product manager too

The uncomfortable part of this shift is that the freed capacity does not arrive as free capacity. It arrives with a bill attached, and part of the bill is yours.

The J-curve is charged to your roadmap

DORA's May 2026 report on the return from AI-assisted development describes a J-curve: teams take a temporary productivity drop before value shows up. The report attributes it to three causes, workflow adaptation, the verification tax and downstream process changes. In its worked model of a 500-person organisation, a change failure rate moving from 5% to 6% carried a cost of $344,000, set against a first-year return of 39% on the same model.

Model that quietly. A rising failure rate lands on the product manager as escalations, regressions and reprioritised weeks, well before it appears in a metrics review. Review capacity becomes the binding constraint on delivery, a dynamic examined in detail in the piece on the code review bottleneck.

Where this argument is weakest

Four objections, and the first two are strong enough that anyone repeating the headline number should carry them along with it.

The 75% figure is a company reporting its own metric about its own engineers, with no published definition of what counts as generated or as approved. A single character of autocomplete and a fully authored module may sit in the same bucket. Google also has a commercial interest in the number being large. My own read is that it is close to useless as a productivity claim and quite useful as a signal about where attention is being directed.

The evidence pointing the other way is fragile too. METR's trial is 16 developers on repositories they knew well, using tools available between February and June 2025, and METR has since said the result no longer necessarily reflects current tools or workflows. Quoting it as settled proof that AI slows developers down misreads what the authors themselves now say.

Third, and most relevant here: the claim that specification quality drives agent output quality rests almost entirely on tool vendors and practitioner writing. I have not found a controlled study measuring it at team scale. It is a well-supported mechanism and a plausible one. It is not a measured effect, and this post would be dishonest to present it as one.

Fourth, the whole argument has an expiry condition. If agents become reliably good at noticing ambiguity and asking, then precision in the spec stops being scarce, and the skill that repriced up reprices back down. Watch for clarifying questions in agent output. That is the indicator that would change my position.

What this does to team shape and headcount

A ratio argument is circulating and it needs handling carefully. The familiar guideline of one product manager to six or ten engineers assumed that writing code was the constraint. If that assumption breaks, the reasoning goes, the ratio should compress toward one to three or tighter.

The logic is sound and the data behind it is absent. I would not restructure a team on it yet. Nobody has published a study connecting product manager density to outcomes under agentic development, and the same premise supports the opposite conclusion just as easily: smaller teams overall, with fewer people in every role.

What is measured is narrower and more useful. DORA's capability model names seven organisational factors that determine whether AI investment returns anything, and user-centric focus is one of them, alongside quality internal platforms and a clear, communicated position on AI. Those are conditions a product function shapes directly. Product is not a passenger in whether the AI investment works.

Frequently asked questions

Where to start this month

Pick one feature already on your roadmap and run it twice, on purpose.

The first pass is the one you would have written anyway. Then rewrite it as a specification: state the failure behaviour, name the authoritative data source, list what is explicitly out of scope, and write the threshold that decides whether it ships. Hand both versions to whatever agent your engineers already use and read the two outputs side by side. The difference between them is the size of the skill gap, measured on your own product rather than on somebody's benchmark.

Then do the smaller thing. Take the last feature you shipped that touches a model, and write 20 test cases against it, half of them chosen because you expect them to fail. If nobody on the team can tell you what proportion of those 20 should pass before you would ship it again, that number is the first product decision waiting for you.

Related reading