AI Won't Replace Developers, But It Will Replace Developers Who Don't Use AI

We Have Done This Before

When IDEs got proper autocomplete, a certain type of developer refused to touch it. Real programmers type everything out, apparently. Using a tool that finished your method names was treated as a sort of moral failing.

Those developers aren’t around any more. Not because they were bad, plenty of them were excellent. They were just slower than the person sat next to them, and slower is a hard thing to survive in this industry.

We had the same argument about version control. About package managers. About linters, formatters, ORMs, and very nearly about syntax highlighting. Every time the shape is identical: a tool arrives, some people refuse it on principle, and the refusal quietly stops being a principle and becomes a handicap.

So when someone tells me they’re not using AI tooling because they don’t need it, I don’t hear a bold stand. I hear an argument I’ve watched lose four or five times already.

It Replaces Typing, Not Thinking

This is the distinction that gets lost in all the panic.

The question isn’t whether a model can think like an engineer. It can’t. It has no idea what your business actually does, why that one table has a column nobody dares drop, or which stakeholder will kick off if the flow changes. That’s the job, and it’s still yours.

What it can do is handle the part of the job that was never interesting. The boilerplate. The fourth almost-identical CRUD endpoint. The regex you write once every eighteen months and look up every single time. The test scaffolding you’d write the same way regardless.

Think of it less as a robot coming for your role and more as an extremely keen junior who never sleeps, types at the speed of light, and occasionally invents things with total confidence. You wouldn’t merge that junior’s work unread. You’d still be glad of the help.

Where It Genuinely Helps

The things I actually get out of it, roughly in order of value:

• Getting unstuck on an unfamiliar library without half an hour of trawling
• Boilerplate in seconds rather than minutes
• Sketching an approach cheaply enough that binning it doesn’t hurt
• Being shown an alternative I hadn’t considered, which occasionally catches a bug

That third one is underrated. The cost of trying an idea has dropped far enough that you can afford to explore two approaches before committing to either. That changes how you design things, not just how quickly you type them.

The Part That Should Worry You

I’m not going to pretend there’s no downside.

These tools will absolutely make you worse if you don’t understand what they produce. Accepting suggestions you can’t evaluate isn’t using a tool, it’s copy-pasting from a very confident stranger. The output looks plausible, which is exactly the problem. Plausible and wrong is far more dangerous than obviously broken.

So the understanding has to come first, and that’s a genuine risk for anyone early in their career. If you never write the thing yourself, you never build the judgement needed to spot when the suggestion is nonsense. The tool is a multiplier, and multiplying zero gets you nowhere.

There’s a real learning cost too. Time spent fiddling with tooling is time not spent shipping. For some workflows the juice honestly isn’t worth the squeeze.

I Might Be Wrong About This

The current tools are limited in ways that matter. Hallucinations, outdated suggestions, answers delivered with entirely unearned confidence. It’s possible the productivity gains are thinner than they feel, and that time saved writing gets handed straight back in review and debugging.

And prediction is a mug’s game. I was fairly convinced blockchain was going to change everything, and we all know how that went. There’s a decent chance this plateaus and somebody digs this post up in five years for a laugh.

But the downside of learning the tools and being wrong is that you wasted a few afternoons. The downside of refusing them and being wrong is quite a lot worse.

The question isn’t “will AI replace me?” It’s “will someone using it replace me?”

What I Would Actually Do

1. Use them, but read every line before it lands in a commit
2. Never accept code you couldn’t have written yourself. Learn it, then accept it
3. Point them at the boring work first. That’s where the return is
4. If you’re early in your career, write the hard bits by hand anyway. You’re buying judgement
5. Stay sceptical of anything delivered confidently. Confidence is not accuracy

I was sceptical when this generation of tooling turned up. I’d now feel a bit hobbled without it, and I don’t think that’s dependence so much as noticing when something helps and being honest enough to say so.

We all came round on IDEs eventually. This is the same argument in a different hat.

Until next time, happy coding!