The Harness Problem: Why AI Code Drifts Without Boundaries

Generative systems fail at the seams where structure is missing, not where the model is weakest. A language model writing code in a vacuum produces plausible fragments that drift; the failure mode is ambiguity, not stupidity. Naming the pattern matters because the same shape keeps showing up wherever teams ship machine output into production: the bottleneck is not the model's ceiling, it is the boundary the system hands it.

That is why the argument from software engineering author Martin Fowler lands as a category, not a tip. His site's lead paragraph says LLMs need "clear boundaries," with abstractions and DSLs acting as a "strong harness." Read plainly: a domain-specific language — a small, problem-shaped notation narrower than a general programming language — gives the model something specific to push against, so its speed becomes useful output instead of confident guessing.

Name a narrow problem area. Build a small, structured notation for it. Let the model write and revise inside that notation, with tests and feedback catching the drift. Speed stops being the risk; the harness carries it.

The trade is honest. A DSL is not a perfect specification, and Fowler's site is explicit that design is discovered through implementation — the first spec is a hypothesis, not a blueprint. The win is not certainty; it is that every iteration lands inside a shape the team can read, test, and correct. Teams shipping AI-generated code are not really negotiating with the model. They are choosing what boundaries to hand it.