What's left for engineers when AI writes the code

Key ideas

• Agents made writing code cheap, but everything after writing it, starting with review, still runs at human speed.
• Fix one bottleneck and the work piles up at the next one: review now, then operations, then security.
• Passing the tests and being worth merging are different bars, and the gap between them is the maintainer's knowledge.
• The work Voss expects to stay human is finding out what a specific customer needs and writing down what good means for them.
• Anything you can check cheaply, you can automate, so put your best people's judgment into specs, rubrics and evals.
• Entry-level hiring has already fallen, and nobody is yet training juniors for the job that's replacing programming.

Laurie Voss argues that agents made code nearly free, so the work that stays human is finding out what people need and writing down what good means. These are my notes on the talk, with each number checked against its source, since several were rounder in the talk than in the research. If you build software, the useful part is the order Voss expects the bottlenecks to fall in, and the list of what to do about it now.

Code got cheap, shipping didn’t

The research the talk leans on is an NBER working paper by Demirer, Musolff and Yang, “Writing Code vs. Shipping Code” (May 2026, revised September 2026). It follows developers through three generations of AI coding tools. For the most autonomous agents, commits rose 240%, the number of projects 80%, and actual releases only 30%. (The talk said “30% faster”; the paper counts releases, not speed.) The authors read that as human bottlenecks further down the line soaking up the gain.

Voss puts the first of those bottlenecks at code review. People can’t review faster than they read. SmartBear’s study of a Cisco team, from around 2006, found reviewers catch fewer defects once they go faster than about 500 lines an hour, and recommends reviewing under 400 lines at a time. A 10,000-line change from an agent is days of careful reading, so in practice it doesn’t get that reading.

Machine review today

The obvious move is to have machines review the code, and that’s underway. GitHub said in March 2026 that Copilot does more than one in five code reviews on the platform, and a repository can now let Copilot’s approval count toward the reviews a merge requires.

The reviewers aren’t reliable enough to stand alone yet. A three-week comparison of four AI reviewers over 146 pull requests found that all four never flagged the same line, though pairs overlapped a few dozen times. Each caught real problems the others missed, so running more than one pays.

The cautionary stories point the same way. Dexter Horthy of HumanLayer told people for about six months to read the agent’s plans rather than its code, then reversed that advice. Amazon now has senior engineers sign off on AI-assisted changes from junior and mid-level engineers, after press reports tied a run of incidents to them (Amazon disputes the cause). And Anthropic’s April 2026 postmortem on Claude Code quality describes a bug that got past several human and automated reviews and the unit tests.

The deeper gap is between passing tests and being mergeable. Coding benchmarks such as SWE-bench mostly ask whether the tests pass. METR found that roughly half of the test-passing fixes it studied wouldn’t have been merged by the project’s maintainers, and Cognition built a benchmark, FrontierCode, around the maintainer’s question instead. What the maintainer adds is the style, side effects, outside systems and history that aren’t written down anywhere. Voss’s word for it is a sense of what good means.

The bottleneck moves

Eliyahu Goldratt, a physicist turned management writer, made this case in his 1984 novel The Goal. Every system has one constraint, speeding up anything else doesn’t help, and fixing the constraint moves it somewhere else.

Voss applies that to software. Say automated review gets good enough. Next the work piles up at operations: deploying and scaling. After that it’s security: keeping things safe and private at scale. Voss expects agents to get past both, because humans have written a great deal down about how to do them, but over five to ten years, not twelve months. The other assumption is that demand for software is effectively unlimited. Most bad websites aren’t bad because nobody knows how to fix them, but because fixing them costs more than anyone will pay.

Deciding what good means

Voss ranks the parts of the job by how soon agents take them over. Writing code is already gone, review and maintenance are next, then shipping and scaling. What’s left after those is deciding what to build, defining what good means, and making it pleasant to use.

The example is a customer who says they need to track their orders. Thousands of programs do that, and the right one for a bakery is wrong for an auto parts store or a factory. That knowledge lives in the head of the person who runs the business, so you have to talk to them to get it. It also doesn’t carry over from one customer to the next: a calendar app and a scheduling app solve nearly the same problem and still need different definitions of good.

The talk backs this with two older ideas. Fred Brooks, who managed IBM’s System/360, split software’s difficulty in his 1986 paper “No Silver Bullet” into accidental complexity (the tools) and essential complexity (the problem), and predicted no single tool would bring a tenfold gain within a decade. Sean Grove of OpenAI argued in 2025 that code is a lossy copy of the spec, so whoever writes the spec is really doing the programming.

The catch is that anything written down can be trained on. Cursor’s reviewer, Bugbot, learns from the feedback teams give it and had more than 44,000 learned rules by April 2026. So the moment a maintainer’s judgment is written down, that bottleneck moves too, which is why Voss thinks operations and security fall eventually.

The product engineer

Voss thinks two jobs are merging back into one. In the 1960s a systems analyst talked to the business to work out the problem; that role became today’s product manager, separate from the engineer. Andrew Ng has said one of his teams proposed having twice as many product managers as engineers, a first for him. Voss’s answer is one role: the product engineer, who finds out what people need, defines what good looks like, and ships it with agents doing the typing.

Voss points to Gergely Orosz’s 2019 piece on the “product-minded software engineer” as an early description, and argues the trait has gone from nice to have to essential. The market already pays for something like it. Salesforce cites an 800% rise in forward deployed engineer postings from January to September 2025, and one analysis of 1,000 such listings put the median salary at about $174,000.

Voss is candid about the trap here: everyone in AI thinks the part they’re good at is the part that can’t be automated. That’s worth holding onto when reading this section.

The junior pipeline

Juniors used to learn on tightly specified tickets that a senior then corrected. That’s exactly the work agents do now. Stanford’s “Canaries in the Coal Mine” study by Brynjolfsson, Chandar and Chen found employment of software developers aged 22 to 25 down nearly 20% from its late-2022 peak, while older age groups grew.

Programs that train for the merged role are small. Google’s Associate Product Manager program takes in a class of about 45 a year, by Google’s own description as program guides quote it. IBM says it’s tripling entry-level hiring and moving those roles toward customer-facing work. Voss’s point is that universities teach data structures and boot camps teach frameworks, but nobody teaches you to sit with a baker for a week and come back with a spec, and teams will have to grow those people on purpose.

What to do now

The practical list from the talk:

• Mark the code where a mistake would do the most damage, and make that the only code humans review.
• Hand everything that’s cheap to verify to agents, and spend the effort on building an automatic way to tell whether the result is good.
• Write your best people’s judgment into specs, rubrics and evals.
• Measure shipping, not output: what you actually release, how often reviewer comments get acted on, and the gap between “tests pass” and “a maintainer would merge this.”
• Treat production as the last reviewer, with a model grading what the system does there.

The figures and their sources

The talk ends where it began: the rise of the AI engineer was engineers learning to build with models, and the product engineer is what’s left when the models do the building.

Key terms

Theory of constraints

Eliyahu Goldratt's idea that a system has one bottleneck, and speeding up anything else doesn't help.

Essential complexity

Fred Brooks's term for the difficulty of the problem itself, as opposed to the difficulty of the tools.

Product engineer

Voss's name for someone who finds out what people need, defines what good looks like, and ships it with agents doing the typing.

Forward deployed engineer

An engineer who works inside a customer's business to build what that customer needs.

Eval

An automated test of whether a model's or system's output is good, often graded by another model.

SWE-bench

A standard benchmark that checks whether a model's fix to a real open-source bug passes the project's tests.

Quotes from the talk