Why AI-Generated Code Needs Tolerances, Not Just Trust

The Real Problem With Prompting Instead of Directing

A growing number of teams treat AI coding tools as an oracle: describe a feature, accept whatever comes back, move on. This works for a weekend prototype. It breaks down once a product has real users, because code nobody reviewed still has to be maintained by somebody. The failure is not a tool problem, it is a discipline gap in how AI output gets directed and checked before it ships.

The industry has started naming this gap. Early 'vibe coding' meant describing an outcome in plain language and iterating by feel, with little attention paid to the generated code itself. It produced real products fast, and it also produced a measurable drop in trust: broad developer surveys have shown confidence in AI-generated code falling meaningfully year over year, as teams discovered that output which looked fine at a glance often was not. The more useful framing now emerging: writing precise instructions and reviewing what comes back is itself an engineering skill, not an afterthought.

Why AI Output Needs Tolerances, Not Just Trust

Traditional software tooling is deterministic: the same input reliably produces the same output. AI code generation is not. That shift matters more than any increase in abstraction, because it changes what 'correct' means. Other engineering disciplines already have a vocabulary for this: structural engineers work with tolerances, explicit margins for how far a result can vary before it becomes a problem. Software teams adopting AI generation need the equivalent: a clear sense of how much variance is acceptable in a given part of the system, with stricter review where the tolerance is small, such as authentication, payments or anything touching user data.

Small, Reviewable Steps Beat Big-Bang Generation

In practice, this means treating every AI-generated change the way a careful team treats a pull request from a highly productive but unproven contributor: reviewed line by line before it merges, never taken on trust because it compiled. Three habits make this manageable. First, define the actual outcome before writing a single prompt, in terms specific enough that success is unambiguous. Second, give the AI one narrow task at a time rather than an entire feature in one pass, so each step stays small enough to verify. Third, review and test each step before moving to the next, rather than stacking untested changes on top of each other. None of this requires new tooling. It requires treating direction and review as the real engineering work, with generation as the fast but unreliable part.

Refactoring Matters More as AI Writes More Code

AI tools are already genuinely useful for one brownfield task: mapping how data flows through an existing, unfamiliar codebase, which speeds up legacy modernisation work. They are markedly weaker at tasks established IDE tooling already automates reliably, such as safely renaming a class across a project. That gap points to where the real work still sits: as more code gets generated quickly, more of it will be functionally correct but structurally messy, and refactoring, the discipline of making small, behaviour-preserving improvements, becomes the mechanism that keeps it maintainable. Current AI tools cannot be trusted to do this unsupervised. Pairing generation with deliberate, human-directed refactoring is what turns fast output into a codebase a team can still work in six months later.

For teams building a product meant to last, the takeaway is simple: AI changes how fast code gets written, not the standard it must meet before it ships. Direction, small verifiable steps and ongoing refactoring keep a fast-moving codebase from turning into one nobody, including the AI, can safely change.