AI is a multiplier, not a replacement

Every few weeks someone asks me the same question, usually in a slightly lowered voice: is this job going away? They are developers, mostly. Sometimes they are founders asking whether they still need to hire one.

I have shipped more than a hundred and thirty products, most of them alone, and for the last two years I have used AI every working day. So here is the honest answer, with the parts that are usually left out.

What actually got faster

The gains are real, and they are bigger than the sceptics admit. But they cluster in a very specific place: work where the shape of the answer is already known and the cost is purely typing.

Scaffolding. New service, new screen, new migration, new test harness. The first eighty percent of a familiar structure.
Translation. Moving a component between frameworks, converting a schema, rewriting a query in another dialect.
The boring middle of a refactor. Renaming across forty files, updating call sites, teasing apart a function that grew for three years.
First drafts of tests. Not the ones that matter most, but the wide, dull coverage that nobody ever gets around to writing.
Reading unfamiliar code. Dropping into a codebase I did not write and getting oriented in minutes instead of an afternoon.

Add these up across a week and it is not a small effect. On a typical build I would put it somewhere near a third of the calendar time, and almost all of that saving comes out of the part of the job I never enjoyed anyway.

What did not move at all

Then there is the other list. Two years in, these have not shifted by a meaningful amount, and I no longer expect them to.

Deciding what to build. A client tells me they need a booking system. Four questions later it turns out they need a way to stop double bookings between two staff members who share a calendar. Those are different projects, and one of them takes a tenth of the time. No model sitting outside that conversation can make that call, because the useful information was never written down anywhere.

Architecture under real constraints. Not the textbook version. The version where the client has a legacy database that cannot be touched until October, a team of three who have never used the framework you prefer, and a hard deadline set by a trade fair. The right answer there is frequently the technically worse one, and knowing that is judgement, not recall.

Production debugging. The failure that happens once a day, only for one customer, only on mobile data. Finding it means holding the whole system in your head and forming a hypothesis about what is actually happening. AI helps me test hypotheses faster. It has never once handed me the hypothesis.

Being trusted. When a system goes down on a Friday evening, the client does not want a tool. They want a person who picks up and says they are on it. That is most of what they are paying for, and it is the one part of this work that has become more valuable, not less.

A multiplier applied to zero is still zero. The number it multiplies is your judgement, and that number is still earned the slow way.

The trap in the middle

The failure I see most often is not developers who refuse to use AI. It is developers who use it to skip the part where they understand the problem.

You get working code on the first try. It passes. You ship it. Three weeks later something breaks in a way that makes no sense, and you open the file and realise you have never actually read it. Now you are debugging a stranger's code in your own repository, under time pressure, for a client who thinks you wrote it.

I have done this. Once was enough. The rule I settled on is simple: I do not commit code I could not have written myself, and I do not commit code I cannot explain out loud. Both take seconds to check and they have saved me entire weekends.

How I actually work now

Nothing exotic. The workflow that survived contact with real deadlines looks like this.

I think through the problem and sketch the data model before I open anything. This step got slower on purpose.
I write the hard part myself. Usually that is the twenty percent where the real risk lives.
I delegate the surrounding eighty percent, then read all of it.
I use it hardest as a reviewer, not an author. Asking what breaks this is worth more than asking it to build the thing.
Anything touching money, permissions or personal data gets written and reviewed by hand. No exceptions, ever.

So what should you tell the junior asking

That the floor rose and the ceiling rose further. Work that used to take a small team is now genuinely reachable by one person who knows what they are doing, which is exactly why I can run a studio and still write the code. That is a real opportunity, and it is open right now.

But it only pays out on top of understanding. The people getting the most out of these tools are, without exception, the ones who were already good. The multiplier found them. It did not create them.

Learn the fundamentals anyway. Read the code anyway. Then let the machine handle the typing.