McKinsey speakers: judging AI code needs as much training as writing it

McKinsey speakers on the AI Engineer show said reviewing AI-written code needs as much emphasis as generating it. Martin Harrysson, Prakhar Dixit and their colleague Shilpa described what large companies see when they use AI agents in software work. Our reading is that judging is becoming the scarcer skill. The speakers did not put it that strongly. The transcript also does not say who spoke each line, so we credit "a speaker" below.

What was said

One speaker said the shortage is no longer skills for AI agents. A skill is a packaged set of instructions that tells an agent how to do a task. There are plenty, and people keep making more. The speaker said curating the few that fit your own organization has become more critical.

The example was a client who needed a simple product requirements document. A quick web search turned up about 1,700 downloadable skills for that one task. The speaker described the result as "paralysis in decision-making."

Another speaker turned to quality. They said reports and data point downwards, even per developer and per pull request, which is one proposed code change. Their view was that teams must coach people to use AI to generate code, and give reviewing the output equal emphasis.

Their remedy was to feed agents curated examples of good work. Examples drawn from the typical code base are not enough. The speaker said "you really want to curate golden examples" that show what good looks like. They also wanted standards for good code built into every checkpoint, from requirements onward.

Why it matters

Our reading: if writing code gets cheaper, the work that stays costly is choosing and checking. A manager who tracks how much code the team produces may be measuring the easy part.

The speakers also said build and test are speeding up, so the bottleneck moves to writing requirements and to releasing. For leaders, that suggests training budgets should cover reviewing and curating, not just prompting. Someone must own the golden examples and decide which skills the team may use.

The other side

This is a consultant's view from client work, and the excerpts give no figures for the quality decline. One speaker conceded that some rise in defects is expected when more changes ship. They argued the drop also shows up per developer and per change, but we only have their word for it.

The excerpts also leave questions open. They do not say that judging has replaced writing as the scarce skill. They do not say how long curation takes, who should do it, or how often golden examples need replacing. Show notes say most companies still report modest gains, so the effect of better judging on results is not shown here.