Do We Still Need Experts?

“We’ve had enough of experts”, said Michael Gove in 2016. A facetious link into a very different subject, but in 2026 we’re having the conversation about whether coding agents will supplant the need for technology experts. Maybe he was on to something?

It’s been incredible to see the change in the capabilities of coding agents over the last 12 months. I myself was taking a much more cautious approach as recently as last September. We’d seen a few “vibe coded” projects up close and were thus very wary about the capabilities of the tooling, despite using it ourselves.

However, it can’t be denied that a shift is occurring. I have two very close examples from the last two months. In January we were contracted to build a brand new AI startup, and we took this as an opportunity to go all in on AI tools (specifically Claude Code) and really see how fast we could move on a blank slate. The result was spectacular - about 7 weeks later we are pretty much at launch. I wish I could say more, but it’s still in stealth mode for the moment. Regardless, 2 engineers and 7 weeks from inception to launch of a robust, secure, AI-powered SaaS product is crazy territory, and certainly wouldn’t have been possible 12 months ago.

Additionally, this weekend, I’ve built and launched two websites in my spare time - a handful of hours. This one that you’re on now, and a business site for a family member. Said family member was paying £36/mo for a Wix website, which I replaced with an entirely free site on GitHub pages which looked 10x better and took me barely 2 hours to build from start to finish.

I’ve stopped making slide decks in google slides or anything else - I just use Claude Code to make a HTML/CSS slide deck.

This is all the power of Claude Code and Opus 4.6. Is it eating everyone’s lunch? There’s no doubt it’s seriously impressive in capabilities. If you churn out high volume websites or slide decks, yeah, I’d be a bit scared right now. None of us are immune. We’ve been pushing the envelope of what we can do with both sandboxed self contained coding agents, and also specialist agents sitting inside some of our companies, doing things like data analysis and engineering, or log debugging. They perform analysis, check out a copy of our code, and submit PRs just like other engineers. Are we all going to be automated?

Perhaps, perhaps not. I think there are a few factors that still favour the human expert for the foreseeable. Let’s take myself for example - I am a generalist. I probably lack deep technical experience in specific languages, frameworks, technologies, etc, but I have an extremely broad technical and scientific vocabulary from my experience. That, I’ve found, has been extremely useful in getting the maximum out of Claude Code. I can not only give very precise instructions but also precise feedback. The ability to articulate thoughts and concepts stemming from general experience really helps you keep coding agents on the rails.

Secondly, I spent the last few weeks writing (or at least pondering) our AI policy. One of the principles I was torn over was the following:

AI makes the “un-fun” parts cheaper. Use this to your advantage. 50/50 ratio - Aim to spend as much time on chores, refactoring, and cleanup as on new features. AI makes tech debt easier to accrue, but also easier to resolve. When resolving tech debt, add tests if they don’t already exist.

Why 50/50? We’ve anecdotally observed that AI productivity decays over the lifetime of a project, and that the rate of decay is strongly influenced by codebase quality and complexity. Complexity grows unavoidably as a project matures; there’s not lots you can do about that. What you can control is quality, and that determines how steep the decline is. What drives this decay? Pattern amplification.

Coding agents replicate whatever patterns they encounter; from the codebase, from the current session, from their own prior output. They don’t distinguish particularly well between good patterns and bad ones, because there are so many of both in their training data. Bad patterns propagate just as readily as good ones, and each session that follows them reinforces them further.

This also raises an interesting question about rewrites. If AI productivity degrades on mature codebases, have rewrites suddenly become much more appealing? I recall Joel Spolsky’s famous and influential article about NetScape where he says:

They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

This article had a huge influence on me as an early career software engineer, and still does. I’ve stuck by this principle for a really long time and it’s guided a lot of advice that I’ve dished out. If you’re taking over a mature (read: legacy) project now, does this principle still hold?

I’m still not sure even with AI you would eagerly try to rewrite a C compiler or a web browser from scratch as per the example. The former is interesting, because Anthropic recently tried it, but, in the process, also revealed the key thing that must be present for such a task to be undertaken, even with AI: an unbelievably well defined and specified suite of tests, such as the GCC torture test suite. And tests are really just programmatic behaviour specification. The AI wrote the compiler, but Anthropic’s engineers defined what “correct” meant. The expertise was in the spec.

Which brings me back to the main point. We still need to have really tight requirements for what we’re building, and someone needs to be cognisant of them. Those requirements aren’t entirely functional either - it’s important, for example, that I know when building on AWS that I want to structure my SaaS platform in a VPC with a public and private subnet, etc. These kinds of details are often not chosen by the models themselves, and a non expert would therefore not even know what they didn’t know. There will be thousands of such small examples in any project.

So do we still need experts? In my view yes, and for quite a while yet. But compounding experience is probably more valuable than deep specialism. You know to put a VPC around your SaaS not because you’re a networking specialist, but because you’ve seen enough production systems to know what goes wrong. These tools are much more productive in experienced hands, and much less likely to get bogged down. That 7-week startup build wasn’t fast because the agents did all the thinking. It was fast because experienced engineers knew which decisions to make upfront.

Anyone can start a greenfield project with AI and move fast. The real test is keeping it productive as it matures, and that’s where experience compounds. So if you’ve got some miles on the clock it’s actually a pretty exciting time to be working in this space, possibly the most exciting time ever.