AI-assisted development is not an equaliser. It is leverage. Leverage amplifies what is already there, in either direction.

In the mid-2000s I was building CRM systems for the NHS under Microsoft’s engineering standards. Eighty percent unit test coverage was the gate you passed before proceeding, not a target you aimed for when time allowed. Nobody debated whether that was reasonable. The people who set those standards had built systems at scale, watched them fail, and knew precisely what the difference between a system that holds and one that doesn’t looks like in practice.

That discipline is hard to sustain in large organisations, even today, not because the standards don’t exist but because the reasoning behind them doesn’t always travel with them. A team that has never built through a serious production failure, or whose institutional memory of one hasn’t reached them, experiences a quality gate as an obstacle rather than a safeguard. The standard is doing its job. The escalation tells you something about the team, not the process.

Part of what gets lost in that transmission is the definition of done. There is a version of done that means the demo worked and the stakeholders nodded. There is another version that means the system will handle what production actually throws at it, be maintainable by someone who didn’t write it, and run without incidents for years. These are not points on a spectrum. They are different things, and conflating them is where the debt accumulates silently until it doesn’t.

The software craftsmanship movement spent years making this argument. Clean code, test coverage, architectural discipline: these are not constraints on velocity, they are the reason velocity is sustainable. The argument was correct, and this article does not revisit it. What has changed is the stakes.

The value that AI-assisted development compresses toward zero is writing code, and faster than most organisations are accounting for. A capable model can produce syntactically correct, readable, functionally plausible code across most common problem domains. What it cannot supply is the judgment to know whether that code is right. Whether the edge cases will be handled. Whether the architecture will hold. Whether the test coverage reflects genuine understanding of failure modes or just passes the checker. Among other things.

That judgment comes from having built things properly and watched them fail. It is built, not awarded. Engineers who have it can now direct a machine to produce quality output at a speed that was not previously possible. Engineers who lack it can now produce plausible-looking failures faster than ever before.

That accumulated judgment and the daily practice of working with AI tools are not as separate as they might seem. The discipline that made the 80% gate non-negotiable is exactly what makes directing a model effective: clear constraints, a precise definition of done, and the ability to recognise output that is plausible but wrong.

Working this way also exercises that judgment rather than replacing it. The correction loop that consumes so much AI-assisted development time has a specific cause: output generated, reviewed without clear criteria, sent back, regenerated. These tools surface the judgment gap faster than anything before them, which is useful information if you know how to read it.

The revaluation here is specific. People with genuine analytical ability and the intellectual honesty to recognise what they do not yet know will learn good engineering practice, with or without formal training. That has always been true. What AI changes is the premium on each type of contribution: the value of producing syntax has collapsed, and the value of knowing what good looks like has increased sharply.

For senior leaders thinking about where AI delivers returns, this matters. The productivity gains are real but they are not uniform across your engineering population. You are not buying acceleration for everyone equally. You are buying leverage, and leverage amplifies what is already there in either direction. In the hands of engineers with deep quality instincts, that leverage is remarkable. In the hands of teams that have never internalised what done actually means, it produces more of the same problems, faster.

The question is not how quickly you can put these tools in front of your teams. It is what those teams will do with them.