AI Coding Won't Stop Breaking Your Code—Here's the Three-Stage Fix
Teams burning velocity on AI-generated regressions are treating a governance problem as a model problem. Tightening CI, writing specs before prompts, and isolating agent roles costs less than the rework from trusting probabilistic output on production code.
AI coding tools produce code that gets messier over time, and the root cause is structural: models generate by probability, not by understanding cause and effect. Errors are not occasional bugs but an ineliminable property of the system. The fix is not a better prompt or a stronger model; it is a staged governance framework that escalates constraints as a project matures. Vibe Coding lets the model run freely during the 0-to-1 prototype phase, with only a causal-chain discussion and a collaboration spec set upfront. Once the MVP is validated and changes start breaking unrelated features, Spec-driven development locks intent, context, and process into living documents that act as AI's onboarding material for every fresh session. When documentation alone can no longer keep the project stable, Harness engineering layers on hard enforcement—CI gates, generator-evaluator loops, role-isolated agents, and automated verification—that AI cannot bypass. The upgrade signal is blunt: when the current layer stops working, move up. Don't pile on governance too early, and don't delay it once complexity demands it.
The framework reframes AI coding failures as a governance maturity problem rather than a model capability problem, which shifts investment from chasing stronger models to building tighter processes.
Calling every new AI session 'day one' and re-onboarding it with a spec is a cheap, high-impact practice that most teams overlook; they instead burn tokens fighting context pollution in long conversations.
The recommendation to refactor the MVP before applying Spec or Harness is underappreciated—governance layered onto unstructured code inherits the chaos it's meant to fix.
Harness engineering formalizes what senior engineers already do instinctively (strict CI, role separation, automated checks) but makes it explicit and non-optional for AI-generated code, where the failure rate is higher and less predictable.
EARS notation for acceptance criteria is a small, concrete technique that bridges the gap between human intent and machine-executable tests; its adoption could reduce the 'it runs but it's wrong' failure mode significantly.