Skip to content
Innovation & Growth Talking point

McKinsey speaker: faster AI coding shifts the problem to review, not away from it

A speaker on AI Engineer said quality per developer and per pull request is falling as AI writes code faster.

W
WebPulse Newsroom
AI-assisted · 2 min read
Share on X LinkedIn
McKinsey speaker: faster AI coding shifts the problem to review, not away from it
In brief
  • A speaker on AI Engineer said AI speeds up code writing, but bug and incident trends are worsening, even per developer and per pull request.
  • The speaker's answer is better review skills and curated examples. Our reading is that reviewers and customers pay when review is skipped.

A speaker on the AI Engineer podcast argued that faster AI coding does not remove risk. In their telling, the problem moves toward review. The point came in an episode with McKinsey's Martin Harrysson and Prakhar Dixit. The speaker said code is arriving faster, but quality is not rising with it.

What was said

The speaker pointed to unnamed "reports and data" they are seeing. Some decline is expected. If commits and pull requests (proposed code changes awaiting review) rise in number, more defects and incidents follow.

The surprise was that the trend also pointed the wrong way per developer and per pull request. So the problem is not only volume. The speaker's explanation was that teams coach people to generate code faster, but the skill of reviewing what was generated gets less attention. It needs equal emphasis, they said.

The remedy they described works on what the agents are given. The speaker said the more a team puts its definition of good, its policies and its standards into the agent's context, the better the outcome. They said "you don't want that to be the average of your code base" and that "you really want to curate golden examples". Rules to encode include whether code is maintainable, not complex, and merges well with other branches.

The speaker also said that building and testing are speeding up. That moves the bottleneck upstream, to writing requirements, and downstream, to how often a team can release.

Why it matters

Our reading: the speed gain shows up where code is written, while the cost lands where code is checked and used. An agent works from the examples and standards it is fed, so weak context sets a low ceiling on what it writes. People then have to catch what falls short. Reviewers face more output and need stronger judgment. Customers meet the defects that slip through.

The speaker did not say who pays. That step is ours, but it follows from their point about bugs and incidents being reported. For managers, output counts alone would hide the problem. Review skill and shared standards belong in the budget next to the coding tools.

The other side

The evidence here is thin. The speaker cited "reports and data" without naming them or saying how large the decline is. The excerpts give no results showing that curated examples or encoded standards fix the problem.

The episode's show notes add context that cuts the other way. They say most large companies still report modest gains. They say roughly the top 20 to 25 percent now see 2x end-to-end improvements. The same notes call measuring impact the hardest part. That leaves open whether the quality drop is general or concentrated in teams that adopted agents without changing how they review.

Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.

The conversation this talking point comes from