Artificial Intelligence

Will AI Replace Software Developers? An Answer From Inside

AI writes most of my code, so this question is not hypothetical for me. What actually disappeared from the developer job, what grew, and who should worry.

7 minute read
Will AI Replace Software Developers? An Answer From Inside

I am a software developer, and AI writes most of my code. So when people ask whether AI will replace developers, they are asking about my own job, and I get to answer from inside the experiment instead of speculating about it.

The short answer: the job I was trained for is largely gone. I am busier than ever. Both of those are true at once, and the distance between them is where the real answer lives.

What already disappeared

Let us not soften this. The typing part of software development has effectively ended for people working at the front of this shift.

The creator of one of the most popular AI coding tools says the model writes all of his code, dozens of pull requests a day, largely managed from his phone with hundreds of agents running. Andrej Karpathy describes going from writing most of his code by hand to essentially none within a few months. My own experience is less extreme but the same shape: most days, most of my code is generated, and my hands-on-keyboard time goes into reading, steering, and deciding.

If your value as a developer is "give me a well-specified task and I will implement it correctly", that value is collapsing. Not in a decade. Now. Entry-level roles built around small implementation tickets are under genuine pressure, and pretending otherwise does not help anyone entering the field.

What did not disappear

Here is the part the doom headlines skip. A job is not one skill. It is a bundle of tasks, and AI is racing through some of them while barely touching others.

AI models are strongest exactly where results are verifiable: does it compile, do the tests pass, is it faster. On those rails they move incredibly fast. Off the rails, they stay strangely weak: knowing which problem is worth solving, noticing that the requirements contradict the business model, deciding what not to build, asking the question the client did not think to raise. The models are simultaneously brilliant and naive, and they do not know which mode they are in.

So the tasks that survived are the ones that were always the actual job:

  • Judgment. Of ten plausible implementations the AI will happily produce, which one will not hurt you in a year?
  • Context. The AI does not know your users, your regulator, or why the last migration failed. Someone has to carry that into every decision.
  • Verification. AI code looks right more convincingly than wrong code ever did. Someone accountable has to know the difference. I wrote about what happens when nobody does in my piece on vibe coding.
  • Accountability. When production breaks, "the AI wrote it" is not an answer any client accepts. Responsibility cannot be delegated to a model, and pricing that in changes everything about how you work.

The demand side everyone forgets

Replacement arguments quietly assume the amount of software stays fixed. It never has.

Software was expensive, so most software that could exist was never built. Every small business process that still runs on spreadsheets and memory is software that was not worth building at old prices. Drop the cost tenfold and that hidden demand becomes real projects. This is the Jevons paradox, and it is the same reason ATMs led to more bank tellers, not fewer: cheaper branches meant more branches.

I see it directly in my own work. Clients now greenlight tools that would never have justified an agency quote three years ago. The pool of viable software is exploding, and someone with judgment still has to build it well.

There is also a democratization effect: the best person to design accounting software is a great accountant, because coding was the easy part all along and knowing the domain was the hard part. That creates more people building software, and more built-by-domain-experts software that later needs an engineer's discipline. Both futures have developers in them.

So who should actually worry?

Be honest about which group you are in.

Worry if your work is executing well-specified tickets, you avoid learning the AI tools on the theory that this will blow over, or your identity is tied to the craft of typing code rather than the outcome of working software.

Do not worry if you own problems rather than tasks. Developers who understand the business, wield the AI tools fluently, and take responsibility for what ships are not being replaced. They are absorbing the output of ten former implementers each, and there are not enough of them.

The uncomfortable truth for my profession is that AI did not introduce a new standard. It revealed the old one. Typing was never the value. Judgment was. For developers who always worked that way, this era is the biggest amplifier of their careers. For those who hid behind the typing, the hiding place is gone.

I answered the same question for designers in a companion piece, and the conclusion converges: the execution automates, the judgment does not. What is left of every knowledge job, mine included, is deciding what should exist and standing behind it.