Developers aren't being replaced, but coding might be

An AI coding tool tells you it fixed the bug with exactly the same confidence whether it succeeded, moved the bug ten lines down, or changed something you weren't working on.

I've fallen for that confidence more than once.

Early on, AI coding can feel effortless. The quick wins pile up, until you reach a detail the model doesn't understand and progress turns to mud.

I've watched people, myself included, spend hours while the tool regenerates the same broken code. "I've fixed the issue," it says. You point out the remaining error. It apologizes, changes something else, and creates a new failure. Three hours later you're reverting a pile of commits and wondering why you didn't write the damn thing yourself.

That experience changed my workflow. The tool no longer gets to decide when the work is done.

The AI doesn't get to declare victory

Tests run automatically. I use subagents whose job is to check whether the original problem was actually solved, followed by a review for regressions before anything gets committed.

It adds overhead, especially at the start. It also scales better than reading every generated line while the tool waits for approval.

Constant supervision gives you the worst version of the tool: it generates quickly, then waits while you become the test runner. I'd rather spend a few hours defining the checks than spend every hour acting as one.

We'll need fewer coders and more problem-solvers

I keep seeing the question of whether this replaces developers. I suspect we'll need fewer people whose contribution is limited to producing code, while the work of deciding what to build remains.

Developers have been lucky because writing code gave us access to interesting problems. Some of us enjoy the syntax and architecture patterns most. I understand the appeal. Those are also the parts AI can increasingly help produce.

The harder part is looking at a messy situation and finding the problem underneath. Which user need matters? What should "done" mean? Which failure would be expensive? How will we know the change worked?

The best developers I know are good at those questions. Their value was never measured only by typing speed, and faster code generation doesn't remove the need for their judgment.

I now spend more time defining what "done" looks like, writing test cases before prompts, and setting up checks so I don't have to inspect every output manually.

The balance of the job has moved. Less of my time goes into producing each line. More goes into framing the problem and building a feedback loop that can reject a plausible-looking mistake.

I'm still figuring out that balance. What has moved in your own work since you started using these tools?