The Word for AI's Worst Output Is Slop

Why Your AI Codebase Is Becoming A Swamp

If you have shipped anything with an AI coding agent, you already know the failure mode, even if you have not had a name for it. It is not the dramatic kind. The agent rarely writes code that fails to compile or throws an error on the first run. It is quieter and far more dangerous than that: code that works, passes a glance, and is subtly, structurally wrong. A database call smuggled into a UI component. An error swallowed with a bare catch. A function that grew to a hundred lines because the agent kept bolting on just one more branch. A response cast with as any to make the type checker stop complaining. Each one plausible. Each one a little dishonest. Collectively, they are slop, and slop is what turns a codebase built by agents into a swamp nobody can maintain.

Why Agents Produce Slop in the First Place

Slop is not a bug in the model, it is the model doing exactly what it was built to do. A language model is a machine for producing the plausible next token. Ask it for a function and it will give you the most likely looking function, which is a completely different thing from the most correct one for your architecture. It has no memory of the rule you set three files ago, no stake in the layering you care about, and a deep, eager willingness to make the immediate error go away. Even if away means casting a type into silence or catching an exception into the void.

Left alone on a long task, it gets worse because of context drift. As a task unfolds, the agent slowly loses the thread of the original intent. The rule it followed perfectly at step three is a distant memory by step thirty. It starts improvising its own conventions, and because each individual improvisation is locally reasonable, nothing screams. You end up with a codebase that is internally inconsistent in a hundred small ways. A single clever chatbot, asked to build something large, will always drift into it.

Rules as a Service, Not a Suggestion

The usual attempt to fix this is to write the rules into a prompt, a CLAUDE.md file, or a long system message. It does not work at scale because prompts live in the context window, and the context window is exactly what drifts. A rule you stated at the top is the first casualty of a long conversation.

The Foundry's move is to stop treating rules as words in a prompt and start treating them as a service the agent has to call. It runs as an MCP server, the standard for giving models tools, and it exposes the entire governance rulebook as queryable, immutable physics. Before an agent makes a structural decision, it does not rely on remembering the rule, it asks the Foundry for the rule. The standards are not advice floating in the context, they are ground truth, fetched fresh, that supersede whatever the model was inclined to do.

// Instead of relying on agent memory, force an MCP tool call
async function validateArchitecture(node: Node) {
  const rule = await foundry.queryRule('INWARD_DEPENDENCY_ONLY');
  if (!rule.isSatisfiedBy(node)) {
    throw new Error('Structural violation: Data access in UI component');
  }
}

The Two Guardrails I Felt the Most

Rules that check a finished diff are only half the story. The two mechanisms that changed how the work felt were the ones that fired before the agent was allowed to act.

The first is blast radius analysis. Before any refactor of a shared piece, an agent cannot rely on intuition. It must run a tool that mathematically walks the dependency graph. If the change touches a hub node, it is flagged high risk and every affected module must be named in the plan before a line is written.

The second is the Variance Gate. Every meaningful decision must carry a confidence score, decomposed into honest factors: how certain is the schema, how good is the test coverage, and how risky is the side effect? When the number is low, the agent does not get to press on. It stops and escalates to a human. Some actions, such as deployments or data deletion, always trigger a manual review. This is the guardrail that caught an agent reaching for remote compute it had no business touching and simply refused.

Governance Is What Turns a Fleet Into Leverage

None of this makes the model smarter, and that is the point. It makes the model accountable to an architecture I designed, not one it improvised on the way past. A fleet of ungoverned agents is just a faster way to make a mess. The reason I am willing to put my name on thirty thousand lines I largely did not type is not that the agents were brilliant. It is that they were never allowed to be sloppy. The governance was the product. The code was just what fell out of it.