avday Google says AI now writes 75% of its new code. Yet in a METR study published in March, open-source maintainers wouldn’t merge roughly half of the AI pull requests that passed the tests.
That’s the short answer to what software engineers will do when AI writes the code. Writing it is now the easy part. Deciding what to build and checking the result are what’s left, and engineers who only supervise get worse at the checking.
When AI writes the code, the job splits in three
Only the middle part is shrinking:
- Before the code: finding out what people need and writing it down precisely enough that an agent can’t misread it.
- The code itself: increasingly typed by an agent, from a spec, in minutes.
- After the code: proving it works, keeping it secure and owning it once real users depend on it.
Laurie Voss, who co-founded npm and now runs developer relations at Arize AI, made the sharpest version of this case in a talk published on 24 October. He argued that being a software developer and being a programmer “have become divorced”, and called the job that’s left “product engineer”.
He also warned that it’s easy to decide the one part AI can’t automate is the part you happen to enjoy. Developer surveys are a useful check on that.
Developers keep AI out of production, planning and review
Stack Overflow asked 12,547 developers which parts of their work they hand to AI. Almost nobody rules it out for tests or familiar code: only 8.5% and 9% say they don’t use it there and don’t plan to.
The refusals pile up around the code instead. 36% keep AI out of deploying and operating production systems. Another 30.5% keep it out of writing requirements and plans, and 22.6% out of code review.
Developers do find AI useful for review and debugging, at 64.5% and 72.6%. Using it to find problems is one thing. Trusting it to say there are none is another, and that’s where the refusals sit.
Google’s DORA research, from a survey of nearly 5,000 technology professionals in 2025, points the same way. It linked AI adoption to faster delivery and to less stable delivery. Its summary: “AI doesn’t fix a team; it amplifies what’s already there.”
Five skills that grow when the agent types
Each of these sits before or after the agent runs:
- Problem framing and specs. GitHub’s Den Delimarsky says coding agents should be treated “more like literal-minded pair programmers”. He wrote in 2025: “With AI the specification becomes the source of truth and determines what gets built.”
- System design. JavaScript Mastery’s system design course argues that AI can build each part of a system, but choosing the parts and weighing their trade-offs is still a person’s job. In its words, “you can outsource the typing, but not the decision making”.
- Verification, including taste and security. Simon Willison’s rule: “Your job is to deliver code you have proven to work.” METR’s maintainers turned down passing AI code over quality and breaking other code. Veracode found AI-written Java passed its security tests just 30% of the time.
- Ownership in production. “You need to own your own code,” Charity Majors, Honeycomb’s CTO, told LeadDev in May 2025. DORA’s stability finding shows why.
- Talking to users. It’s the task developers rate AI weakest at, and 45.9% don’t use AI for emails and messages and don’t plan to.
Why some experienced engineers stopped using AI for code
Brett Chalupa has built web software for about 15 years. On DonTheDeveloper’s new podcast, published on 26 October, he said he stopped using AI for code entirely in late July. When he handed in his notice, his manager told him nobody had noticed he’d stopped. He has since left that job.
His reasons are specific:
- Review fatigue. He called reviewing huge AI-generated pull requests from colleagues “maddening”.
- Skills slipping. When his coding agent went down, he couldn’t do his work: “it was like I had been put back 10 years”. It took about a month of coding by hand to get back.
- Responsibility without understanding. On his blog on 30 September he wrote: “Beware deskilling engineers who are expected to be responsible for the code that’s being generated.”
The research backs the worry. In Anthropic’s trial, published in January, the engineers who learned a new Python library with AI scored 17% lower on the quiz. The biggest gap was on debugging questions.
Majors made the same point to LeadDev: “When you overly rely on AI tools, when you supervise rather than doing, your own expertise decays rather rapidly”.
The way through is in that same Anthropic data, though the groups were small. The four developers who handed all the coding to AI averaged 39%. The two who generated code, then asked follow-up questions to understand it, averaged 86%.
What to do this quarter
None of this needs a new job title. It needs a few habits, started now:
- Write the spec before the prompt. For your next feature, write a one-page spec with acceptance criteria and keep it in the repo. If the agent misreads it, fix the spec as well as the code.
- Make every change prove itself. No agent pull request merges without a test or a recorded check that fails before the change and passes after.
- Put security in the instructions. Veracode’s prompts had no security guidance. Add your rules to the spec and run a scanner on every agent change.
- Own something that’s live. Join the on-call rota, or read the dashboards and incident notes for a service you ship to.
- Hear from a user every fortnight. Sit in on a support call or a sales demo, and bring back one requirement you didn’t know.
- Debug by hand once a week. Take one bug a week without the agent. When you do use it, ask it to explain the cause before it changes anything.
For how the most experienced engineers set up their agents day to day, see how leading developers code with AI agents.
Our take
The parts of the job that grow are the parts that were always hard: knowing what to build, and knowing it works. Whether there’ll be enough of those jobs is a separate question, covered in what the 2026 data shows on AI replacing developers.
The survey measures what developers choose today, and choices shift as models improve. Two things would change our view: AI security pass rates well past Veracode’s July figure, or a DORA report linking AI adoption to more stable delivery. Neither has happened yet.
The skeptics are right about one thing. A developer who only supervises gets worse at checking, and checking is the job now. So we’d use agents for the typing and keep some coding by hand, on purpose.
Agents don’t make the job easier. If anything, they leave less room to be lazy. An agent will happily add a table that duplicates one you already have, or build an architecture that’s expensive to run, does nothing useful, repeats itself or simply breaks. You only catch that if you understand the technology, how your data relates and how the system fits together. Scope works the same way. Every feature you add to an MVP that it doesn’t need has to be tested, and if you aren’t testing it, someone else has to.
The other trap is trusting it too easily. The agent recommends something, it sounds fine, and it goes in without a second thought. Agents are very good at sounding right. If you hand over your design, your taste and your thinking entirely, the agent is doing the job, and you’ve made yourself the easiest part of the team to replace.
