AI won't replace developers. Developers who use AI will.

Every few months a new demo makes the rounds and someone announces that programmers are finished. I don't buy it. But I don't believe nothing changes either. My view is simpler: AI won't replace software developers. Developers who use AI will replace developers who don't.

The tractor test

At the start of the 20th century, a farm could only produce as much as people and horses could pull. Then tractors arrived. A farmer with a tractor could plough, plant and harvest far more land than one with a team of horses, in a fraction of the time.

The farmers who bought tractors didn't stop being farmers. They still decided what to plant, when to plant it and how to look after the soil. The tractor did the heavy pulling. And the farmers who held out weren't beaten by machines. They were beaten by neighbours who had machines.

That's how I see AI in software. It's a tractor. It does a lot of the pulling, but it doesn't know which field to plough.

Where the analogy breaks, and why that's good news

There's an honest objection here. Tractors did shrink farming as a job. Around 1900, roughly four in ten American workers worked on farms. Today it's fewer than two in a hundred. If AI is a tractor, isn't that the same story?

I don't think so, and the difference is demand. People can only eat so much food, so when each farmer could produce far more, fewer farmers were needed. Software has never worked like that. Every time building it got cheaper, we found more things worth building. Compilers, high-level languages, open source, frameworks and the cloud each made a single developer far more productive, and the number of developers kept growing anyway.

Cheaper software means more software: more internal tools, more small businesses with custom apps, more ideas that are finally worth the effort. Most teams don't have a shortage of ideas. They have a backlog that never gets shorter.

What changes in the job

What does change is where the time goes. Typing code was never the hard part, but it took a lot of hours, and AI is good at exactly those hours:

• Scaffolding: the first version of a component, an endpoint or a database migration.
• Tests: the boring but valuable cases that usually get skipped.
• Reading: explaining an unfamiliar codebase, a regular expression or a stack trace.
• Chores: renaming, refactoring, and converting one format into another.

That leaves more of the day for the parts that were always the real job: understanding what users need, choosing the right trade-offs, designing how the pieces fit together, and saying no to features that would make the product worse.

The tractor still needs a driver

AI is confidently wrong often enough that you can't let go of the wheel. It invents APIs that don't exist, misses edge cases, and writes code that works in the demo and breaks at the boundaries. It doesn't know your users, your constraints, or why that strange line in your codebase is there.

So the skills that matter more now, not less, are the fundamentals:

• Reading code critically, because you'll review more code than you write.
• Knowing what good looks like, so you can tell a solid answer from a plausible one.
• Debugging, because when generated code breaks, you're the one who has to understand it.
• Security and data handling, where "looks fine" is not good enough.

If you don't understand the code you ship, it isn't your code. It's a liability with your name on it.

How I use it

My rule is simple: AI gets the speed, I keep the responsibility. I let it draft, and I read every line before it goes into a commit. I ask it to explain before I ask it to change anything. And when it's wrong, I take that as a sign to slow down and understand the problem myself.

Pick up the tractor

The developers who struggle won't be the ones replaced by a model. They'll be the ones who refused to learn the new tool while the people around them shipped twice as much. The good news is that the tractor is right there, and learning to drive it takes weeks, not years.

Learn it. Stay curious about how it fails. And keep doing the parts of the job that were always yours.