The current consensus on keeping AI-generated code on track is better inputs: more detailed specs, better prompts, richer instructions. Spec-driven development is good practice. It is also one side of a two-sided coin, and it is the side you can live without.
That argument comes from Cameron Barre, a working engineer since 2013 and creator of the open-source domain-specific language Grain. This post explains why specs cannot stop architectural drift on their own, and what can.
Agents pattern-match on the codebase they are in
Coding agents are trained on all the code on the internet. That code reflects how the industry builds software, which means enormous variance in what “good” looks like.
Inside your codebase, the agent pattern-matches on what it finds. If the system uses complicated object-oriented patterns in one place, hundreds of relational tables with risky migrations in another, and a legacy hotspot where old habits were never cleaned up, the agent has nothing uniform to latch onto. It averages across the inconsistency.
The result is familiar. Something gets stood up fast. After a couple of weeks, progress stalls. Day-to-day variance in how the agent chooses to build things accumulates until the system falls apart. That is what people call slop.
Barre’s summary: whatever you dislike about your codebase, imagine it times ten. AI replicates existing habits at the speed of multiple engineers working at once.
Why instructions cannot constrain a probabilistic system
The clearest illustration is the production database that an agent dropped. The team almost certainly told the agent not to do anything destructive. Instructions were not enough.
Agents make decisions on probabilities. Instructions shift the probabilities. They do not structurally limit what the agent can do. Over a system that lives five or ten years, variance compounds. The spec can stay coherent while the code underneath it keeps changing shape.
So specs and prompts are necessary. They are not sufficient for uniformity in the underlying architecture of long-lived systems.
The floor: a constrained decision space
Barre’s fix is to give the agent a floor. A floor is something you cannot easily go beneath. In software terms, it is a constrained set of primitives, a grammar, that defines the only valid way to assemble the system.
The floor prevents architectural drift. It does not prevent product and domain drift. That is where the spec comes back in. Once the architecture cannot drift, specs have more room to do their job at the product level.
The two sides of the coin:
- The floor constrains how the whole application is put together. It limits the blast radius of small code-quality issues to individual function bodies, where they do not compound into system-level problems.
- The spec constrains what the application does for the business and the domain.
Most teams have invested only in the second.
Grain as a worked example
Grain is Barre’s executable version of event modeling, a product design methodology by Adam Dymitruk with a small, fixed set of primitives that can express any information system. Grain’s grammar is those primitives, so the only valid approach to building a system with it is the constrained one.
Barre does not claim the ideas are new. His argument is that the ideas needed to make AI software production reliable have existed for 20 years. The industry is catching up.
What matters for engineering leaders is the property, not the tool. A system built on a small set of composable primitives, each with one job, becomes more self-descriptive as it matures. That hones the agent in on the correct way to do things.
What changes when the floor is in place
Barre is rebuilding a $10M company’s finance application this way with a team of two, doing the work of three to five people per day. Three consequences stand out.
Smaller, cheaper models become viable
As the system matured, the team moved from a frontier model to Claude Code with a mid-tier model, and found it performed well. A small model asked to explain a complex part of the domain came back with a correct answer. When a system has low novelty and uniform structure, less firepower is needed. That reduces cost.
Long-lived systems tolerate changing requirements
The event-sourced, immutable paradigm underneath makes the system tolerant to specifications that change over years, and supports automated debugging and verification.
Accountability becomes possible
Barre refuses to take accountability for code he cannot look under the hood of and understand exactly how it is constructed. Generating code without a uniform architecture underneath is, in his words, an un-risk-mitigated way to work. The floor is what makes accountability for AI-generated systems possible.
What this means for teams with existing systems
Barre operates in greenfield and legacy-conversion work, and is candid that he does not have every answer for large legacy estates. But the principle transfers.
Before pointing agents at an existing system, you need to know what the architecture actually is, where the patterns are consistent, and where they are not. That knowledge rarely exists as a document. It has to be extracted from the code.
That extraction is what Swimm’s deterministic analysis produces: a verified map of dependencies, entry points, data flows, and cross-repo relationships. It is the foundation for defining the floor an agent can work within, and for Swimm’s API-first architecture offering, which turns embedded business logic into reusable services around one source of truth.
Swimm is a product-enabled service company. We combine deterministic analysis for accuracy, AI for scale, and SMEs to catch what tools miss. Book a 30-minute scoping call to talk through where your system’s architecture stands.
FAQ
Is spec-driven development enough to control AI-generated code?
No. Specs and prompts guide what the system does, but they cannot structurally constrain a probabilistic agent. Over a long-lived system, architectural variance compounds. A constrained architecture is the other half of the solution.
Why does AI-generated code drift over time?
Agents pattern-match on the codebase they are in and on the variance in their training data. Each change can take a slightly different approach. Without a uniform architecture, those small differences accumulate into an incoherent system.
What is an architectural floor for coding agents?
A constrained set of primitives that defines the only valid way to assemble the system. It prevents architectural drift and limits the blast radius of small code-quality issues, leaving specs to handle product and domain drift.
Does better architecture let you use smaller AI models?
Yes, in practice. A uniform, self-descriptive system with low novelty needs less model capability. Teams have moved from frontier models to mid-tier models on such systems without losing performance, which reduces cost.
How does this apply to legacy systems?
You first need to know what the architecture actually is, which usually means extracting it from the code. That verified understanding is the basis for defining a floor and for separating business logic into consistent, reusable services.