Claude — And Just Like That, You're a Developer

There was a time when all it took was a slogan. Buy this, and just like that, you're someone else. Drink that coffee and you're already a man of the world, wear those shoes and you run like a champion. It worked because it sold a shortcut: the result without the journey.

Today I type that slogan into a terminal. I open Claude Code, describe what I need, and within minutes I have running code. Not a throwaway prototype: structured code, with its tests, its error handling, its documentation. A task that used to take a full day now takes half an hour. And just like that, you're a developer.

The exciting part is real, and there's no point being coy about it. The distance between the idea and the working thing has collapsed in a way that someone who's done this job for thirty years struggles to absorb. Scaffolding an app, integrating a web service, the script that cleans up three thousand messy rows, refactoring a legacy module: all the work that was pure friction — necessary but devoid of intellectual value — simply evaporates. What's left is the thinking: what do I want to build, and why. That's not a little. That's almost everything.

A story we've seen before

Except I've lived part of this story already. It was the mid-nineties, and Microsoft put a relational database inside Office. It was called Access, and it was a quiet little revolution. Suddenly you no longer needed an analyst, a DBA, and three months of project work to get a business application: all it took was the warehouse manager with a free afternoon and a bit of patience. Forms, queries, reports, all with the mouse. Productivity inside companies exploded. Entire departments started solving their own problems without waiting for IT.

And then, a few years later, the bill arrived.

Because all those .mdb files hadn't gone anywhere. They had multiplied. They lived on desktops, in shared folders, on floppy disks forgotten in a drawer. They had become business-critical — invoicing ran inside them, work orders, customer records — but nobody knew who had written them, how, or by what rules. They were black boxes that worked until they didn't. IT always discovered them at the same moment: when they broke. No documentation, no owner, no one able to touch them. Yesterday's speed had become today's technical debt.

The flip side of speed

Here's the part the slogan never tells you. The shortcut gives you the result, but it takes away the journey — and the journey was also where you learned to govern that result.

When you write the code yourself, line by line, you know it. You know where the trade-offs are, you know what you left behind, you know where to look when something breaks at two in the morning. When the code is generated for you by an artificial intelligence in thirty seconds, you have an artifact that works but that you didn't build. The question is no longer "can I write it?" but "do I know what I just accepted?".

And the knots tighten fast. Code piles up at a rate our capacity to review it can't keep up with. Dependencies get introduced that no one has assessed. Patterns get replicated without anyone checking whether they're the right ones for that context. We delegate to the AI not just the writing but — quietly — the architectural decisions too, which are exactly what you should delegate least. And above all, shadow IT is born again: applications created outside any governance, becoming critical before anyone even notices. The .mdb files of 2026 are repositories full of code nobody has actually read.

Speed, on its own, is not a virtue. It's a multiplier. It multiplies the discipline of those who have it, and it multiplies the mess of those who don't. The tool amplifies you: bring method, and you get accelerated method; bring improvisation, and you get chaos at industrial scale.

Where the difference lies

This isn't a call for luddite caution — that would be ridiculous, and frankly I don't believe in it. Claude Code is one of the most powerful tools I've held in thirty years of working in this field, and anyone not using it today is already at a disadvantage. The point is different: the difference is no longer being able to produce. That, largely, is solved. The difference is knowing how to govern what you produce.

What goes into production, and by what criteria. Who owns it. How it gets documented, tested, maintained. Which decisions stay human because they touch risk, security, data. Everything that, back in the nineties, nobody did with Access — and that we paid for over the following decade.

The slogan said: and just like that, you're a developer. It's true. But the craft was never writing the code. It was deciding which code deserved to exist, and taking responsibility for it. That part, thankfully, nobody generates for you.