Twenty-five years of building for the web. The first time I wrote PHP, it was version 3. I've watched the field go from hand-crafted HTML tables to React hooks, from FTP deployments to GitOps pipelines, from "will it work on Netscape?" to "will it pass Core Web Vitals?"
The changes have been continuous, but rarely sudden. Every transition had a clear predecessor. You could see the arc.
The current transition doesn't feel like an arc. It feels like a discontinuity.
The Real Shift
The early discourse around AI in software was dominated by two camps: the dismissers ("it's just autocomplete") and the panickers ("it will replace all developers"). Both were wrong, for the same reason: they thought of AI as a tool that does a single thing, rather than as a shift in the economics of cognition.
Here's what actually changed: the cost of translating thought into working code has dropped by an order of magnitude.
That might sound like a speed improvement. It's more than that. When a category of work becomes dramatically cheaper, you don't just do the same work faster — you do different work. Work that was previously too expensive to explore. This is profound.
Consider:
- Architectural exploration becomes cheap. You can spike three different approaches in an afternoon, where before you'd commit to one and spend weeks validating it.
- Documentation becomes natural. "Explain this to me in plain language" is a sentence. So is "write a clear comment for this function."
- The boring work becomes bearable. Boilerplate, test data, format transformations — the scaffolding that ate hours can now largely be described in a few sentences.
What hasn't changed: the need to understand what you're building and why. This, is also profound. And the masses don't see this as vital.
The Senior Advantage
So, this is where I want to spend some time, because I think it's genuinely underappreciated.
AI tools don't level the playing field between senior and junior developers. They tilt it further toward experience.
Here's why: junior developers can now generate code for problems they couldn't previously approach. But generating code is not the same as building software. The real work — the work that AI cannot do — is everything that surrounds the code:
- Choosing the right problem to solve
- Recognising that the elegant solution today is the maintenance nightmare in three years
- Understanding why the previous team made the choices they did (and when to override them)
- Knowing which edge cases are actually edge cases and which ones will bite you in production
- Reading AI output with the skepticism of a senior engineer who's seen confident mistakes before
These are judgment skills. They don't come from tutorials. They come from being wrong in interesting ways for years, from carrying pagers, from debugging production systems at 2am, from inheriting codebases built on decisions nobody remembers making.
Every year of that experience is worth more in an AI-assisted world, not less. AI amplifies judgment — and judgment is what experience builds.
For junior developers: the challenge is real, but so is the opportunity. Use AI as a teacher, not a shortcut. After every AI explanation, close the chat and explain it back to yourself. If you can't, you don't know it yet. Build the foundations — they matter more now, not less.
Sadly, I've recently come across a couple examples where a junior guy just used Littlebird to help him with all sorts of development. Over time, the critical thinking disappeared. He just copied and pasted script after script after script. Not knowing what he was developing, trusting the AI to make the right calls. Sadly, the software he developed was extremely flawed, un-maintainable and frustrating to the user and to him. AI will not change 'good taste'. It will not change judgment calls.
My friend Hans (@hansv) used these words: AI is like putting the ironman exoskeleton on. If you're Tony Stark, with good intentions, you become Iron Man (read: if you're a good developer, it gives you superpowers, it augments you). If you're an evil thief and you put on the ironman suit, you become a supervillain (read: bad developers/juniors will produce crap software of monumental scale).
The Workflow Evolution
My development process has changed considerably:
| Before | Now |
|---|---|
| Grep through documentation | Conversational API exploration |
| Write boilerplate from memory | Describe structure, generate scaffold |
| Debug by reading stack traces | Debug by describing symptoms |
| Tests written last (or not at all) | Tests written alongside the feature |
| Architecture lives in my head | Architecture externalised and discussed |
The last row is the most valuable to me. Having a thinking partner to externalise architectural decisions with — even if that partner is a language model — produces markedly better outcomes than holding everything in your own head.
On Code Quality: The One Rule
I have one non-negotiable rule: never commit code you can't explain.
AI will produce confident, plausible-looking code that has subtle bugs, unnecessary complexity, or simply doesn't match the actual requirements. The only defence is reading it carefully, testing it properly, and being able to articulate what each part does.
The golden rule: AI is a drafting partner, not an authority. Review everything with the skepticism you'd apply to code from a very confident intern. They might be right. They might not.
Where We Are
The developers building deep intuitions right now — learning when AI is reliably excellent and when it confidently fails, developing workflows, understanding the limits as well as the capabilities — will have a compounding advantage over the next few years.
The web transitions of the 90s and 2000s created a generation of developers who built their careers on being early. This feels like one of those moments.
Written by Kenneth Himschoot and published on February 1, 2026.