AI Writes the Code. So What's Left for Engineers? - Laurie Voss, Arize AI
Laurie Voss, head of developer relations at Arize AI and co-founder of npm, argues that coding agents have made writing code nearly free, so the bottleneck keeps moving first to code review, then to operations and security. What agents can't take over is discovering what people actually need and defining what 'good' means. He introduces the product engineer as the role that remains, examines the collapse in junior engineering hiring, and offers practical advice for engineering leaders.
Code got cheap, so the bottleneck moved
Agents have made writing code nearly free. You pay for tokens, but relative to the time writing used to take, the cost is negligible. Everything downstream of writing did not get cheaper at the same rate, so the constraint keeps shifting. Writing code is now fast, and the queue forms in front of whatever has not yet been automated.
Right now that queue sits at code review. Developers using autonomous coding agents write about 8x more code (741% more) but ship only about 30% faster. A Cisco study from roughly 20 years ago found that human ability to parse code falls off sharply after about 450 lines per hour, so a 10,000-line diff would take a week to review properly. Yet the cost of producing plausible code has collapsed while the cost of knowing whether to trust it has not.
Machines reviewing machines isn’t enough yet
Automated review is already here. Copilot reviews more than one in five code reviews on GitHub, and some teams let it hold approval power. But AI reviewers are unreliable. In one comparison of four reviewers, each found real bugs, yet none agreed on any individual bug, so running a single reviewer is not enough. Skipping review entirely has failed too. Dex Horthy spent six months telling people not to read agent code, then reversed course after a painful rewrite. Amazon’s outages led it to require senior sign-off on agent-produced changes, and Anthropic published a postmortem on bugs that slipped past both human and machine reviewers.
The sharper point is about what tests measure. A model that passes a standard coding benchmark’s tests about 80% of the time drops to around 54% when Cognition’s benchmark asks whether a maintainer would actually merge the PR. The missing information, including code style, side effects, external systems, and project history, lives in the maintainer’s head rather than the codebase. That judgment of what ‘good’ means is what agents currently lack.
The theory of constraints applied to software
Goldratt’s novel The Goal (1984) gives the frame: every system has one bottleneck, and speeding up anything other than the bottleneck does nothing. Fixing the bottleneck doesn’t eliminate constraints; the constraint simply moves. Code review is the current one. After it likely come operations (deployment, scaling) and security (safety, privacy, keeping systems from going off the rails). The speaker expects those to take five to ten years to solve, not twelve months, and rejects ‘AGI 2027’ style timelines.
Demand is effectively infinite
The second assumption is that demand for software is effectively unlimited. Most websites people encounter are bad not because nobody knows how to build good ones, but because building well is expensive and skilled people are busy elsewhere. If software becomes nearly free to produce and appetite is unlimited, the real question becomes what agents won’t eat.
What agents won’t eat: deciding what good means
Every piece of software formalizes a human need, and those needs are hard to extract. Two order-tracking systems can look identical yet demand entirely different definitions of good depending on whether the business is a bakery, an auto parts store, or a manufacturer. That knowledge is not in training data or model weights. It lives in the heads of the people running the business and only comes out through conversation. It also doesn’t transfer: a calendar app and a scheduling app solve nearly the same problem but need different definitions of good. Configuration-heavy tools that try to do everything and still fail, Jira being the example, show the cost of skipping this step.
Fred Brooks, writing in 1986, separated accidental complexity (tools, syntax) from essential complexity (the problem itself) and predicted that no single tool would yield a tenfold productivity gain. Code becoming eight times cheaper while shipping barely improves fits that prediction. Code is a lossy projection of a specification, so whoever writes the spec becomes the real programmer.
There is a catch. Anything cheap to verify can be trained against. Cognition turned mergeability into a benchmark, and Cursor’s BugBot converts every thumbs-down from a team into a rule, with around 44,000 rules now. Each time a maintainer’s judgment is written down in a form models can learn from, the bottleneck moves again. That is why the speaker expects security and operations to eventually fall as well. What doesn’t get codified is the work of figuring out what people need.
The product engineer
Andrew Ng has argued for blurring PM and engineering roles rather than hiring more PMs. The speaker traces the history: in the 1960s, systems analysts talked to the business and didn’t write code. That role became the product manager, and now the two are collapsing back into one. He proposes the term product engineer for someone who finds out what people need, defines what good looks like, and ships it with agents doing the typing. Gergo Orosz described product-minded engineering as a nice trait in 2019. The speaker argues it is now essential. Forward-deployed engineer postings rose 800% in the first nine months of 2025, with average compensation around $240,000. Titles vary wildly, but the core point is that software development and programming have separated.
The speaker also flags his own bias. A product-minded person arguing that the hardest part is the part he’s good at deserves some skepticism, and a VC making the same argument about their own job would have the same problem.
The junior developer problem
Junior training traditionally relied on well-specified tickets and feedback on what the junior got wrong. Agents now absorb that role, which removes the apprenticeship ladder. Labor statistics since January 2023 show employment for engineers aged 22 to 25 collapsing, while employment for those aged 41 to 49 has risen. The speaker argues the industry needs enormous numbers of product engineers, possibly unlimited numbers, and is producing them only by accident. Google’s Associate Product Manager program turns out about 50 people per year. He estimates the need at 10,000 per year, and peer programs produce only around a thousand per year combined. Universities teach data structures and bootcamps teach React, but nobody teaches ‘go sit with a baker for a week and come back with a spec.’ IBM is already redesigning entry-level roles around customer conversations and specs. Engineering leaders will have to train product judgment on purpose, and soon.
For people who love the craft
Many people entered programming for the craft: elegant abstractions, cracking hard bugs, making machines do exactly what you asked. Those people will find this change painful, and the speaker offers no consolation prize. But the part many loved most may have been the moment before typing, when a problem clicks into a repeatable system. That spark survives. Craft has survived similar shifts before: woodworking survived the furniture factory, and programmers will still program the way singers sing, in empty rooms for the love of it, just not as the work people pay hundreds of thousands per year to have done.
History suggests the profession grows, but the transition is rough
Compilers, frameworks, and open source each made a generation of typing unnecessary, and each time the profession grew. The speaker predicts that in ten years the profession will be larger than today’s, pay about as well, and be shaped mostly like product engineering. The next decade will be ugly, though. The load arrives before the tools are ready, and the junior ladder disappears before a replacement exists.
What to do now
- Write down high-blast-radius code and make it the only code humans review closely. Automated reviewers can handle the rest.
- Delegate anything cheap to verify, and build automated ways to judge whether output is good before redesigning the review process around humans.
- Move your best people’s judgment into specs, rubrics, and evals. Turn knowledge that lives in people’s heads into something agents can use.
- Measure the right things. Lines of code were never the point. Track what actually ships, how often reviewer comments get acted on, and the gap between passing tests and a maintainer merging. Treat production as the last reviewer, and grade its behavior with another model as an eval.
The rise of the AI engineer was about engineers learning to build with models. The rise of the product engineer is about what remains when the models do the building: finding out what people need, writing down what good means, and making something people like. As the speaker puts it, we are all product engineers now.