AI Agents Made Writing Code Nearly Free. Laurie Voss Asks What Engineers Are Left to Do

Laurie Voss opens by introducing himself as head of developer relations at Arize AI and a former co-founder of npm. He notes that a little over three years earlier, Swyx had written the essay "The Rise of the AI Engineer," arguing that shipping AI products requires engineers rather than researchers. Companies have hired for that title since then, and Voss says he is here to argue that the essay did not go far enough.

He states his claim directly: "There is not just an AI engineer revolution happening. There is a revolution happening to every kind of engineer." He says all engineering jobs are being replaced by a new type of job, and that not everyone will be happy to hear it.

Voss says the underlying change is that agents have made writing code basically free. You pay for the tokens, but compared with the time writing code used to take, the cost is small. Everything that comes after writing code, however, did not become free at the same time. Where writing code was once slow and everything else moved at roughly the same speed, writing code is now very fast, and the work gets stuck behind new steps.

Right now, the first thing the work is stuck behind is code review. Voss's thesis is that this will not be the last stop: teams will learn to automate code review and make it move at the speed of agents, then run into another bottleneck, and another, until they reach one that agents cannot get past.

Voss says that point is where humans will be left, and he makes a bet that there is some task agents really will not be able to do. He adds that the industry will then need to work out how to train the next generation of engineers for that job, since it is not training them for it now.

Voss says he has a large set of data but not enough time to present it all or to cite each source on the slides, so he asks the audience to trust him. The main figure he gives is that developers who switch on autonomous coding agents write 741% more code, about eight times as much, but ship only 30% faster. He says 30% faster is not nothing, but when the amount of code written rises eightfold, a one-third increase in actual shipping suggests the work is stuck somewhere.

Voss says the place it is stuck is code review, and that humans cannot simply review faster. He cites a Cisco study from about 20 years ago, which found that people's ability to parse code falls off sharply after about 450 lines per hour. By that measure, a 10,000-line diff produced by an agent would take roughly a week to review properly, and he says nobody is actually doing that. He points to a previous AIE talk titled "The Death of the Code Review" for more on the phenomenon.

Voss says machine review is already happening. He reports that GitHub's Copilot performed more than one in five of the code reviews on GitHub as of the previous month. Users can opt in to let Copilot act as the final reviewer before a change goes to production, with approval power. He says OpenAI has stated that humans may review its pull requests there but are not required to.

Voss says the machine reviewers are not yet very good. In a test he ran, four AI reviewers each found a number of bugs, but none found the same bugs, and they did not agree on any individual bug. All of them found real issues, just different ones, so Voss says they are worth running, but anyone serious about this should never rely on just one of them.

Voss describes teams that went further and decided not to review the code at all, assuming an agent would get it right in one attempt. He cites Dexter Horty, who spent six months telling people not to read the code, then said on stage that he had been wrong. Skipping code review was a disaster, he said, and the team had to replace whole systems. Voss says the agents are not good enough to get the code right on the first try.

He also cites Amazon, which had a run of outages that its postmortems traced to a coding agent producing a lot of sloppy code that was released without enough thought. Amazon now requires senior engineers to sign off on code reviews. Anthropic also published a postmortem on bugs that passed every human and machine reviewer it had.

Voss's conclusion is that the automated checks built so far to decide whether code is good enough are not good enough themselves. He compares two measures. On a standard coding benchmark, Claude Fable 5 passes the tests on 80% of tasks. Cognition, the makers of Devin, built a benchmark that asks a different question: would a maintainer of the repository merge this pull request? On that measure, the pass rate falls from 87% to 54%. Voss says a lot of extra information goes into that decision that the tests do not capture.

Voss turns to Eliyahu Goldratt, a physicist who became a management writer and, in 1984, published a novel about running a factory called The Goal. Goldratt's central idea is the theory of constraints: every system has one bottleneck, and speeding things up does not help unless the thing you speed up is the bottleneck. Voss says this is the problem with code review, since the code has been sped up but review has not.

Goldratt's second idea, which Voss says matters today, is that fixing a bottleneck does not make it disappear. It moves and piles up against the next constraint. Voss asks the audience to assume the code review problem is solved. He then predicts that the next bottleneck will probably be operations, meaning how to deploy and scale a system, followed by security, meaning how to make a system safe at scale, keep it private and stop it from going badly off track.

Voss says he is making a large assumption: that operations, scaling and security will also be solved. He explains that these areas are heavily studied by humans and there is a large amount of data about them, so if agents can be made more capable at them, the question becomes what role humans would have. He calls this a big, long-term question and says he is not predicting what happens in the next 12 months.

His timeline is that in the next 12 months there will probably be real progress on code review, but he does not expect operations, scaling and security to be sorted out within 12 months. He estimates it will take somewhere between five and ten years, and he dismisses predictions of AGI by 2027, saying the work will be iterated on slowly.

His second assumption is that the amount of software needed is effectively infinite. He argues this is an easier case to make. Most websites people encounter in production are probably bad, he says, not because nobody knows how to make good ones but because it is expensive to make them good and the people who could do it are busy with other things.

Voss says that if we can make as much software as we want basically for free, and the appetite for software is essentially infinite, then the situation is one of infinite demand and suddenly infinite supply. To find where the bottleneck ends up, he splits software development into as many pieces as he can and sorts them by how soon agents will reach them.

By his ordering, writing code has already collapsed. Reviewing and maintaining code is going soon. Shipping to production and scaling come next, though he says there is not much data on those yet. He considers the following parts probably safe for humans: deciding what to build, defining what good means, and finally making the product delightful. What is left, in his account, is finding out what people actually want, because every piece of software formalizes something a human wanted to get done.

Voss gives an example. A customer who says they need to keep track of their orders is describing something that thousands of software products already do. Whether a given one is good depends on the business: a bakery, an auto parts store and a large manufacturer each need something different. He says the requirement alone is not sufficient, and that the whole job is working out what the person means by keeping track of orders, what that means for their business, and how the process needs to work.

He says this knowledge is not in training data or model weights. It is in the mind of the person who runs the business, and the only way to get it out is to talk to them. Voss says this work does not transfer. A calendar app and a scheduling app solve nearly the same problem, he says, yet they have totally different requirements and different definitions of good, even though their use cases are close together and there are a zillion use cases. He cites Jira as an example of software with a huge number of configuration options that still fails to do what a user needs.

Voss says the bottleneck moves to describing the problem and defining what it means to have solved it, and that his bet for this talk and the next 10 years is that it stays there. He refers to Fred Brooks, who ran the IBM System/360 project and wrote The Mythical Man-Month, and who wrote about this in 1986. Brooks divided the difficulty of software into two kinds: accidental complexity, the difficulty of tools and languages such as typing and syntax, and essential complexity, the difficulty of the problem itself.

Brooks predicted that no single tool would make engineers 10 times more productive, because the essential part is the hard part. Voss says that prediction looks solid, since code was made eight times faster but shipping did not get much faster. He also cites Shawn Grove of OpenAI, who made a similar point a year earlier: code is a lossy projection of the specification, and whoever writes the spec, whether a product manager, a lawmaker, an engineer or a marketer, becomes the programmer. In Voss's view, writing down what good means is where the value is now.

Voss says anything you can verify cheaply can be trained against until it is beaten, if you are a model maker. He describes Cognition trying to define mergeability as a benchmark, so that the knowledge a maintainer uses to judge a change could be put into a benchmark and used to train a model. He also describes Cursor's reviewer BugBot, which turns every thumbs-down a team gives it into a rule. Voss says Cursor now has about 44,000 rules.

His point is that the moment a maintainer takes knowledge out of their head and writes it somewhere a model can train on it, the bottleneck moves again. He says this is why he thinks security and operations can also go, since those things can eventually be written down even though it has not been done yet.

Voss also cites Andrew Ng, co-founder of Google Brain and Coursera, who said one of his teams proposed having twice as many product managers as engineers. Ng said that was a first in his life, but his answer since then has been not to hire more product managers but to blur the jobs together. When an engineer understands users and can decide what to build and build it directly, Ng said, they can execute very quickly. Voss says this is where he thinks the answer is starting to emerge.

He notes that in the 1960s there was a job called the systems analyst, whose task was not to write code but to talk to the business and find out what the problem was. That role later became the product manager, and two professions replaced one and a half. Voss says the two are now collapsing back into one, and that this is a return to the 1960s, not the rise of an AI engineer.

Voss says the job he is describing is not just building with AI but building everything, all software. He has decided to call it the product engineer: someone who finds out what people need, defines what good looks like, and ships it with agents doing the typing.

He points to Gergo Orosz, who writes The Pragmatic Engineer newsletter and described the product-minded engineer in 2019 as a nice trait for an engineer to have. Voss says it has moved from nice to essential, from a skill that senior engineers used to have to a skill every engineer must have to call themselves an engineer.

Voss says the market already pays for this. Job postings for forward deployed engineers, who look very much like product engineers, rose 800% in the nine months of 2025. He says the average compensation for a forward deployed engineer is $240,000, which is in line with a senior engineer. He notes that nobody agrees on what to call the role yet, with about a thousand job titles for what he describes.

Voss acknowledges that some listeners will say this is not programming, and he agrees. The programming is done by an agent. He says it is still recognizably software development, and that being a software developer and being a programmer have become divorced in 2026.

He then questions his own view. He says that when he argues the hard part is deciding what good is, he is falling into a trap many people in AI fall into: believing that everything except the thing they are good at can be automated. He says a VC told him recently that everything except their own job can be automated, and he responded that someone is going to automate his job any day now. He asks whether he is simply valuing the part of software development he enjoys, figuring out the problem, and invites listeners to tell him if he is wrong.

Voss asks listeners to accept the premise that programming goes to zero and product engineering goes to infinity. That, he says, raises a new problem with junior developers. Junior engineers used to be trained with well-specified tickets that told them to write software a particular way, after which senior engineers would point out all the ways they were wrong. That kind of work has gone, he says, because it is now what people do with coding agents: they ask for a thing, then tell the agent how it is wrong and hold a conversation with it. He says that is no longer a job humans need to do.

Voss says the industry still needs a large number of forward deployed or product engineers and has to get them from somewhere. He presents a graph of labor statistics since January 2023, sorted by age. The line for engineers aged 22 to 25 is collapsing, which he describes as an actual trend that has been happening for two years, not a future prediction. Over the same period, employment for engineers aged 41 to 49 has risen, because senior engineers remain very valuable. Voss says junior engineers are being squeezed and that the profession needs to fix that.

Voss argues that if the world is going to gain from 10 times more code output and from solving the rest of the software supply chain and figuring out what humans need to do, the industry will need a very large number of people. He says demand for software is effectively infinite, so the industry needs infinite people, and asks where they will come from. So far, he says, they have been created accidentally, and the industry needs a way to produce them on purpose.

He cites Google's associate product manager program as turning out people who look very much like product engineers, at about 50 per year. He says the industry needs about 10,000 a year. Other companies have copied programs like Google's, but they produce about a thousand people a year in total, and Voss says the number needs to be at least ten times that to keep up with demand. He adds that universities teach data structures and boot camps teach React, but nobody teaches people to sit with a baker for a week and come back with a spec.

Voss says leaders of engineering teams will have to grow product engineers on purpose. He notes that IBM is already redesigning its entry-level role around talking to customers and writing specs instead of programming. He says leaders need to work out how to train product people quickly, because the time to start was two years ago and there is now a cohort of unemployed juniors who have this problem.

Voss says many people entered programming because they love the craft: a clean abstraction, the feeling of a hard bug finally giving up, and making a machine do exactly what it was told. They did not sign up to interview bakers about what they want in their lives, and Voss says they will hate this and already are complaining loudly. He says he has no consolation prize for them.

He does offer an observation. For many people who think they love typing, he suggests, what they loved may have been the moment just before typing, when they figured out the problem. That part does not go away. The creative spark of seeing how to turn a problem into a repeatable system remains.

Voss says the craft of programming will survive in the way woodworking survived the furniture factory. Programmers program the way singers sing, in an empty room for the love of it, and that will not disappear. It just will not be the thing people pay hundreds of thousands of dollars a year to do.

Voss predicts that the next 10 years will be ugly, as the last two have been. He says the load of this change is arriving before the tools are ready, and the junior ladder disappeared before anyone worked out how to train more juniors. Many people who love the craft will have to decide whether they love the job replacing it.

He notes that this has happened before. Compilers, then frameworks, then open source each made a generation's worth of typing unnecessary, and each time the industry came out with more software developers, having changed what software development meant. He predicts that in 10 years there will be a profession bigger than today's, paying about as well, and mostly shaped like product engineering.

For practical steps, Voss advises: be ready for a world in which humans are barely involved in producing code; write down your high blast radius code and review only that, since automated reviewers will handle the rest; delegate everything that is cheap to verify, and invest in building an automatic way to judge whether the output is good so you can feed that to the agent; and put your best people's judgment into specs, rubrics and evals, which capture knowledge that otherwise exists only in people's heads.

Voss says that code volume was never the point. Leaders should measure how much they are actually shipping, how often reviewers' comments are acted on, and the gap between tests passing and a maintainer being willing to merge. He says to remember that the last reviewer is production, and that watching what happens there, with another model grading it, is itself an eval. He says he will not pitch Arize directly, and that this is simply what they do.

He closes by recalling Swyx's 2022 essay on the AI engineer, which described engineers learning to build with models, and says the rise of the product engineer concerns what remains when models do the building. Finding out what people need, writing down what good means and making something people like is the job now, he says, and it will be the job for everyone in the room, whether they like it or not.