What Remains for Software Developers When AI Writes Code?

AI writes code, and it will write more of it. There is no point competing with it on who types a function faster; that race is over. That is why I think “will AI replace software developers?” is the wrong question. The one I care about is different: which part of the work is left for the people who build software, and how does anyone learn to do that part?

This is an opinion piece, but it starts with the data, including the data that cuts against me.

The strongest case on the other side

In 2023, researchers from GitHub and MIT ran a controlled experiment: two groups of developers built the same HTTP server in JavaScript, one of them with GitHub Copilot. The group with the tool finished 55.8% faster. On a well-bounded task with a clear brief, AI speeds things up a lot.

The employment data is harder to sit with. Brynjolfsson, Chandar and Chen at the Stanford Digital Economy Lab track ADP payroll records in Canaries in the Coal Mine?. In the August 2026 version they find no widespread, economy-wide job displacement. But employment of 22-to-25-year-olds in the occupations most exposed to AI, software development among them, is 19% below where it would be had it kept pace with their less-exposed peers. The authors themselves present these figures as descriptive, not as proof of cause.

Taken together, these figures say something hard to dismiss: AI already does part of the implementation work, and the change seems to weigh most on people starting out.

Where the gain shrinks

In July 2025, METR published a randomised study of experienced developers working on open-source repositories they knew well, on real tasks. With AI, tasks took 19% longer. The participants believed they had been faster.

That number needs care. In February 2026, METR itself changed the experiment design, acknowledged selection problems that make its more recent data unreliable, and said developers in early 2026 were likely already being sped up by the tools. So the 2025 result is not a picture of today, and I don’t read it as proof that AI slows anyone down. I read it as a sign of something I recognise from my own work: when a task depends on context, project conventions and decisions nobody wrote down, the time AI saves on typing comes back as reading, reviewing and fixing.

The 2025 Stack Overflow Developer Survey points the same way: 46% of developers distrust the accuracy of AI tools, against 33% who trust it, and the most experienced are the most cautious. The 2025 DORA report describes AI as an amplifier: it strengthens whatever practices a team already has, good or bad.

What I think: fundamentals decide what goes into the prompt

To me, AI is like an assistant who is smarter than I am at many things. It makes me more productive. But it answers what I ask, and I only ask well about what I understand.

An integration example, since that is my field: a flow saves an order to the database and publishes an event for other systems. Asking for “save the order and publish the event” produces code that works in the demo. The trouble starts when the database commits the order and the event publish fails: the order exists and nobody hears about it. A transactional outbox handles that part by writing the event in the same transaction as the order and publishing it later. Then come retries, and with them the chance of the event arriving twice, so the consumer has to be idempotent. Three mechanisms for three different failures. Someone who knows them knows how to ask for the right solution and how to reject the wrong one. Someone who doesn’t won’t even notice the question exists. Renato Augusto puts it well in a video on the subject (originally in Portuguese, with an English audio track available in the player settings): the AI already knows, but you don’t. And “best practices” are not a seasoning you add to the prompt; every design choice is a trade-off someone has to own.

That is why I don’t treat fundamentals as optional. They tell me what to ask for, and they make me suspicious of an answer that merely looks right.

What I think: the cost shows up in maintenance

The second half of my position is about review. Trusting without reviewing feels like saving time until the day the code has to change or breaks. Then nobody knows what was done or why.

I have a case of my own. I built an orchestrator for Linear issues, almost entirely by AI under my direction. When an issue changed state in Linear, a webhook notified the orchestrator, which created an isolated worktree in Orca and set an LLM to implement the task. Once the implementation was done, a second LLM reviewed what the first had produced. Depending on what Orca returned, the orchestrator moved the issue in Linear: to human review, back for fixes, or to blocked. Webhooks carried the traffic between the orchestrator and Linear, and between Linear and Slack, so I could follow everything without opening a terminal. A Cloudflare Worker and Docker containers sat in the middle.

I know architecture and knew exactly what I was asking for. But I know little Python, the language it was written in.

The flow worked: I had run successful end-to-end executions. Even so, I asked another AI for two independent code reviews. The first found eight problems. The second, run after the fixes, found more, among them a token leaking into a subprocess environment, a file write that followed symbolic links and an approval that could hang forever. After that, the project reached 565 automated tests. All of them used stand-ins, fake versions of Linear, Orca and the other services: they proved the logic was right, but none of them talked to the real systems. I would not have found those defects on my own, because I don’t know the language well. Verification ended up in the hands of another AI.

I eventually froze the project and replaced it with a simpler setup. My architecture background let me direct the build and decide to stop. My lack of depth in the language kept me from maintaining what I had asked for. Maintenance cost is not all or nothing: it is cheap while the problem is the one you asked about, and expensive when the defect sits in a decision nobody made consciously.

I described a smaller case in When AI Writes the Code, the Engineer’s Work Moves: a plausible 200 response for an inactive customer, under a rule the requirement had left open.

The uncomfortable part

My position has a weak spot, and the Stanford data points to it. The figures don’t prove that AI caused the drop in employment among younger workers. But they raise a concern I share: if AI automates exactly the well-bounded, clearly specified task that used to be the job of people starting out, the risk is not the end of the profession. It is a narrower way in. I learnt fundamentals by building small things, getting them wrong and fixing them. If those tasks go to the AI, where does the next person learn what I am calling essential?

I don’t have a full answer, and the period observed is short. But I don’t think it is honest to say “just learn the fundamentals” without admitting that the place where people used to learn them may be shrinking.

What I would do about it

If you are starting out, I wouldn’t spend energy trying to be faster than the AI. I would spend it learning what the AI doesn’t decide for you: specifying the problem, writing the test that could disprove the solution, reading a diff and explaining why it is right. Use AI to learn as well, by asking why, not just asking for code.

If you lead a team, entry-level work has to be designed on purpose. Handing a junior a task the AI solves on its own teaches nothing. Handing them the review, the question the requirement didn’t answer and the responsibility of explaining the change does.

AI writes code. The job was always deciding what the code should do and answering for it. That part stays with us, as long as someone still knows how to do it.