AI coding: what matters, what doesn't

There’s a firm in Hong Kong that has built a successful business flying tailors to cities like London and New York on a regular schedule. They take a suite in a good hotel, bring cases full of fabric samples, and spend a few days measuring clients for made-to-measure suits. The measurements go back to Hong Kong. Two weeks later, you have a well made suit that fits properly, at a fraction of Savile Row prices. (Their website, ironically, is pretty dreadful. But that’s not what they’re selling.)

The tailors who travel aren’t doing the sewing. Their skill is in the measuring, the eye for what will work on a particular body, the ability to guide a client toward the right fabric and cut. The production happens elsewhere, faster and cheaper than a London workshop. But the judgment that makes the suit work is still human, still expert, still essential.

AI-assisted software development works the same way. The production step, the typing, has been accelerated dramatically. The judgment that makes the output useful hasn’t been automated. If anything, it matters more.

What matters more

The developers seeing the largest productivity gains from agentic AI coding tools share certain characteristics. They can decompose a problem into pieces that can be specified clearly. They understand architecture well enough to know when the AI has produced something that will cause problems later. They can write tests that actually validate requirements, not just exercise code paths. They know what good looks like and can recognise when they’re not looking at it.

These are skills of judgment, not skills of production. Requirements clarity. System thinking. Verification strategy. These matter more than ever, because the cost of producing wrong output has dropped. You can generate a lot of code quickly. Generating the right code still requires someone who understands the problem.

Product thinking matters more. Understanding users matters more. UX sensibility matters more. Deployment and operations knowledge matters more, because getting software running is part of the value chain that’s been compressed.

What matters less

Syntax memorisation is nearly worthless when coding with AI. Knowing the exact method signature for a particular API, or the precise incantation for a specific framework, used to be valuable. It saved time. Now the AI knows it better than any human, and retrieves it instantly. Memorising it is like memorising phone numbers when you have a contacts app.

Typing speed is interesting. It actually used to matter more than people realised, but not because two developers writing the same code would finish at different times. It mattered because the developer who could type faster was more likely to add the extra test for an edge case, write the documentation, do the quick refactor. The friction was low enough so they’d be more inclined to do it, which was a good thing and why I encouraged my son to learn to touch type. Slower typists would skip things, not because they didn’t know better, but because the effort felt disproportionate.

But it goes beyond just typing speed. AI removes that kind of friction almost entirely. Adding comprehensive tests, keeping documentation current, refactoring as you go: these things can happen because they’re nearly instant. The AI doesn’t skip the edge case test because it’s tired or rushed. This can actually drive quality up compared to what people produced by hand, because the marginal cost of doing things properly has collapsed.

Boilerplate tolerance, the ability to grind through repetitive setup code without losing focus, used to be a useful trait. Again, AI squashes this to nothing and the results are better for it.

The junior developer question

I hear a persistent concern that junior developers won’t learn to code properly if they rely on AI tools. “How will they learn to code if they don’t write code? They’ll become dependent.” This panic misses the point.

Nobody laments that carpenters have lost the ability to work without power tools. A carpenter with a battery-powered drill isn’t producing less good carpentry than one using a hand brace. They’re faster. The skill is in knowing where to put the hole, not in the manual labour of making it.

Developers using Python don’t typically understand the assembly language their code compiles to, despite that in the early days this was how computers were programmed. Good ones understand the concepts, the mental models, but not the low-level implementation. Nobody considers this a crisis. We moved up an abstraction layer because it made us more productive, and we adjusted what juniors need to learn accordingly.

The same shift is happening now. Juniors don’t need to learn the same curriculum as five years ago. They need to learn enough to supervise effectively, to validate output, to understand when something is wrong and why. They need product thinking, testing strategy, system design, requirements discipline.

It is a different curriculum, not no curriculum. The skills are arguably harder to teach, because they’re about judgment rather than procedure. But that’s a training challenge, not an existential threat. You don’t suggest a surgeon uses blood-letting in 2026 just because key-hole surgery is tricky to learn.

What this means for you

If you’re hiring, the profile changes. Breadth matters more than depth in any single language or framework. Understanding users matters more than raw coding speed. And what matters more than anything is the ability to specify clearly and verify thoroughly, though I would argue those have always been important; they’re just more tangible now.

If you’re developing your existing team, the investment shifts. Process discipline, testing rigour, requirements clarity, architectural thinking. These pay off more than they used to, because they’re the skills that let you get value from dramatically accelerated production.

If you’re worried about your juniors, worry about whether they’re learning judgment, not whether they’re learning syntax.

In the next article, I’ll discuss where AI coding actually goes wrong, why the risks are real and how you can manage them.

Next: AI coding: where it goes wrong

AI Coding Series Index