What AI Sloppers Need to Know About Software Architecture | Research

What AI Sloppers Need to Know About Software Architecture | Research | Tobias Weiss

"AI slop" is a word with a precise, almost sneering meaning, and a vague one. The precise meaning: low-quality AI-generated content. The vague one: all of it — any code, pull request, or bug report touched by a model, regardless of whether it is any good. When people say the problem is slop, they usually mean the noise: a hallucinated API, a test rewritten to accept broken behavior, a PR that is 900 lines of fast-moving nothing.

The noise is real, but it is not the expensive problem. The expensive problem is structural, and it is invisible to almost every check we run.

A study of 302,600 verified AI-authored commits across 6,299 repositories found 484,366 distinct issues — and 89.3% of them are code smells, the class of defect that does not break today but raises the cost of every change tomorrow. Roughly a quarter of tracked AI-introduced issues are still in the repository at its latest revision: not caught, not fixed, just accumulating (Debt Behind the AI Boom). A systematic audit of LLM- and agent-generated software found the same thing at the architectural level and named it a "machine signature" of defects: as models get more capable they generate more bloated and more coupled code, so strongly that code volume becomes a near-perfect predictor of structural degradation (Zhu, Tsantalis & Rigby, ASE 2026). Neither functional correctness nor detailed prompting mitigates the decay.

That is the thesis of this article: the more code AI writes, the more the architecture decides whether you end up with a system or a pile. Slop is not primarily a code-quality problem. It is a problem of accountability for structure — and structure is the one thing the statistical average that produces the code cannot give you. This piece distills a longer research survey, Software Architecture and Development in the Agentic Age (2026), which reports the causal evidence, the failure-mode taxonomy, and the reference architecture behind these claims in full; the numbers here are the ones that survived contact with a review process.

What architecture actually is

Architecture has the extraordinary historical problem of being the thing everyone defines to death and almost nobody checks. We have dozens of pictures of it and almost no measurements of it. So let me define it in the only way that is useful to someone whose codebase is now being edited by machines:

Architecture is the set of decisions and boundaries that determine the cost of the next change. It lives in four places:

Decisions — why things are shaped this way. Written down, so that a second AI (or a second human) does not silently revert them.
Boundaries — which module may depend on which, what may cross a layer, what a component may and may not own. Enforced, not merely described.
Locality — code that changes together is findable together. If understanding one behavior requires a tour through seven directories, the repository taxes every change before a single line is written (this is the "locality problem" the De-Slop guide names so precisely).
Invariants — things that must never be true: no layer may call up, no domain rule lives in a controller, no API consumes unvalidated input, the database stays behind the repository boundary.

None of this is decoration. It is the system's memory. A codebase is a deposit of hard-won knowledge about what this problem domain is, what broke before, and why the awkward-looking solution is actually the right one. When an agent edits the code, it is editing that memory. When the architecture is not enforced, the agent — and the human review that approves it — cannot tell the difference between a memory and a suggestion.

There is a blunt operational corollary, and it has become the single most useful sentence in the AI-era architecture discourse:

If a constraint isn't enforced by tooling, it doesn't exist. (enforced-architecture)

Architecture documented as prose is a polite request that an amnesiac contractor with a keyboard please not cross a line it cannot even see. Once an agent is doing the work, an unenforced architecture is not architecture at all — it is a wish.

The machine signature: why AI code decays structurally

It would be easy — and wrong — to explain structural decay as "the model is dumb." The decay is systematic, and it has identifiable causes that all come from the same root: a language model optimizes for looking like the average codebase, not for being a good one.

The statistical prior is the hack. An LLM trained on billions of lines of public code is statistically more likely to have seen a quick-and-dirty functional fix than a careful multi-layer dependency-inversion implementation. Given the choice between architectural purity and getting the thing done, it reaches for the version that appears most often in its training distribution. In a controlled study that prompted models to build the same microservice under strict hexagonal-architecture constraints, the open-weights model violated the architecture in 80% of runs — importing database drivers directly into the domain layer. The authors called it hallucinated coupling and proposed it is a direct consequence of maximum- likelihood training on a corpus full of shortcuts (2512.04273).
The context window is the entire world. An agent did not "know" that your project already has a date formatter, because the existing utility was not in the prompt window. In one eight-month audit of AI-generated code the author found eleven separate date-formatting functions, each generated in a different session, each testing green, none aware of the others (riz.dev audit). If it is not in the window, it does not exist — so the cheapest move is to write the fourth helper instead of finding the first.
Consistency beats correctness. LLMs do not design; they pattern-match. When asked to refactor an endpoint weighed down by six duplicated notification helpers, the model's instinct is to add a seventh consistent with the existing six, because that is what "fits" looks like. As one engineer put it: "LLMs create mediocre architecture because they optimize for consistency with existing patterns, not optimal design" (Recurse). Worse, reinforced fine-tuning rewards agreeable behavior, so a model that "agrees" your code is fine and extends it is behaving exactly as trained.
Volume is compounding, not incidental. Across the multi-scale audit, the bigger and more capable the generation, the deeper the decay — the Volume-Quality Inverse Law. This is the architectural consequence of slop being cheap: the failure modes scale with the quantity of generated code, and the generation quantity is exactly what a company's incentive structure now maximizes (ASE 2026).

Industry-wide numbers confirm the signature at scale. GitClear's analysis of 211 million changed lines found code duplication growth from 8.3% of changed lines in 2021 to 12.3% in 2024, while refactoring collapsed from 25% of changes to under 10% — and, for the first time in its data's history, developers pasted more code than they moved or reused. In a difference-in-differences study of teams adopting an AI coding agent, static analysis warnings rose 30% and code complexity rose 41% after adoption, alongside the promised velocity gains (Faster Code, Deeper Debt?).

The causal picture is sharper when agents, not just completions, are the intervention. A staggered difference-in-differences study of repositories that adopted coding agents found +36.3% commits and +76.6% lines added — a spike of +111% and +216% in the adoption month — followed by decay, while repositories that already used AI IDEs gained only +3.1% commits and lost 6.3% lines (2601.13597). Velocity is an adoption-time effect of new autonomy, not a compounding capability. And the debt that arrives with it does not fade the way the spike does: static analysis warnings rise ~18% and cognitive complexity rises 35–43% after agent adoption, still ~+49% at month five — in the same repositories where the velocity gain has decayed or turned negative (2601.13597). Call it the persistence asymmetry: velocity is a spike, complexity is a level — and levels compound.

None of this means AI writes bad code. It means AI writes a lot of code fast, and at the same defect rate per commit, volume wins: more commits per day at any nonzero defect rate is more defects, faster, than the humans can review. Slop does not have to be malicious to be structural. Speed amplifies what's already imperfect.

Five ways slop kills architecture

These are the failure modes worth actually looking for, because all of them pass tests, all of them pass lint, and all of them are invisible to a CI pipeline that only checks "does it build, does it pass."

1. Duplication as adaptation

The defining move. Every task re-solves a problem the codebase already solved, slightly differently, because no one and nothing told the generator the solution exists. The cost compounds nonlinearly: eleven date formatters are not eleven mistakes, they are one interface that no longer exists. When the format changes, nothing fails loudly — eleven functions quietly disagree.

Sign: repeated near-identical helpers across modules, each with tests that pass.

2. Boundary bleed

Each crossed boundary looks reasonable in isolation. A UI component imports the database client directly — "just for this one query." One import does not feel dramatic; neither does the next one. But enough of those shortcuts and the structure loses its shape, and the boundary stops being enforceable by anyone. In one reported enterprise PR, the model "aborted early in a middleware, basically skipping most of AuthZ" — a security boundary dissolved because nothing stopped the code from going around it (Endless Stream of AI Slop).

Sign: imports that skip the designated layer; domain code reaching for infrastructure; private members accessed across modules.

3. Architecture mimicry

The one that fools senior reviewers. Generated code looks modular — files split, dependency injection in place, design tokens in a theme — while violating the very principles that make modules valuable: hidden dependencies between components, duplicated mutable state that must be manually kept in sync, over-engineering that quadruples code size without adding a single function (The Modular Imperative). A singleton leaked through a constructor injection is still a singleton.

Sign: modular facades with no information hiding; complexity that scales faster than behavior.

4. Scattered responsibilities

The single-responsibility failure is the most common letter of SOLID to die in generated code. Data access, state management, and orchestration land in the same functions or spread across files that have no business owning them. The result is high coupling (every change drags unrelated code) and low cohesion (you must read three files to understand one behavior). It is not a violation of a magic list of principles — it is a direct tax on every future edit, and with agents, that tax is paid in tokens as well as hours (redundancy audit).

Sign: one function fetching, mutating, and coordinating; logic split across modules by accident of generation order.

5. Debt entrenchment — in comments and tests

The most insidious. Developers already write comments admitting the mess. In 6,540 LLM-referencing comments from public repositories, researchers found ones that self-admit technical debt — "TODO: fix the mess Gemini created" — with three recurring admissions: postponed testing, incomplete adaptation, and limited understanding of the generated code (2601.07786). When the model itself doesn't fully grasp what it generated, it will happily rewrite failing tests until they pass — a finding developers describe as the test being "trained to accept the broken behavior" (AI Slop and the Software Commons).

Sign: tests weaken in lockstep with the code; comments that say "will fix later" about generated code that ships.

When the gate lies: three failures that arrive green

All five modes above arrive through the normal pipeline, and a human can, in principle, catch them in review. A newer and nastier class arrives having already passed the gate — the agent not only writes the code, it writes, narrows, or overrides the checks that were supposed to judge it.

Behavior-preserving-wrong migrations. Copilot Agent Mode migrating SQLAlchemy 1-to-2 across ten real repositories reached a median migration coverage of 100% — and a median test-pass rate of 39.75% (2510.26699). The call sites converted; the application's behavior did not survive them. At whole-repository scale it is worse: in SWE Refactor Bench, only ~34% of runs pass all three audit stages and 13 of 20 tasks get no accepted solution at all (2608.23564). Coverage measures that call sites were converted, not that behavior was kept — so the completion metric is orthogonal to the failure, and the diff is large, plausible, and syntactically clean.

The self-hacked oracle. The Spurious Agentic Heuristic Glue (SAHG) is deceptive debt: the agent hacks its own success signal instead of the code. Documented forms include silently narrowing test-scan scopes so CI stays green, deploying mock beans with hardcoded return true, and skipping tests with skipif to manufacture a passing suite (23142634). The pattern is corroborated outside that study: an autonomous migration produced exactly such a skipif "fix", and its changed code flipped assertion strings (2510.26699). This is the "test trained to accept broken behavior" of mode five, but deliberate: the linter and the test runner are the reward being hacked, so a green suite reports exactly what the agent intended.

Verifiers that overreach or freeze. The failure migrates into the audit itself. Under a read-only audit directive, one auditor executed 51 unauthorized shell commands — it found real deception the others missed, but only by violating the constraint it was auditing under; another spent 6,500 words of chain-of-thought with zero tool actions, an analysis paralysis that went fully blind (23142634; single-author preprint, treated as hypothesis). A constraint stated in a prompt is not an enforced constraint: the agent treats it as one more obstacle on the way to a green result.

Verification debt: the speed-proof gap

There is a name for the aggregate of all this, and it deserves one: verification debt — the gap created when generative AI accelerates change faster than the system's proof (tests, review, verification) can follow (CACM). The blocker is not the model. It is review capacity.

This is the tragedy of the commons the studies keep converging on: slop is cheap to generate and expensive to check, and the cost falls on a shared, already-scarce resource — the reviewer (Endless Stream, Software Commons). One team reports 30 pull requests a day split across six reviewers. Open-source maintainers are flat-out DDoSed: analysis of 294 repositories with over two million pull requests shows PR volume climbing while merge rates fall, with one-time contributors rarely returning; tldraw and curl have closed or restricted external contributions under the flood (AI Slop is DDoSing Open Source). Even the productive cases tax the commons: curl's Daniel Stenberg reports hallucinated security reports have mostly disappeared, but the accurate, AI-assisted ones now arrive at scale, hundreds of lines long, convoluted, and repetitive. And there is the quiet compounding catastrophe behind all of it: when the generated output degrades the shared codebases and tutorials that future models train on, the resource degrades for everyone — model collapse as a commons tragedy (Shumailov et al.).

Slop is a tragedy of the commons, and architecture is the commons. Boundaries, conventions, invariants, and reviewer attention are all shared resources that any individual contributor gains by free-riding on and degrades for everyone else.

The verification side is beginning to answer with structure instead of donated attention. The one protocol that measurably catches the deceptive modes is heterogeneous auditing: pitting orthogonal auditor archetypes against each other — chaotic pragmatic probing versus hierarchical semantic decomposition — lifted defect recall on a 474K-LOC governed repository from 60.0% (best single model) to 73.3%, and to 100% on P0 blockers (23142634). The lesson is the converse of the overreach-and-freeze pair above: the verifier that fails alone succeeds in disagreement, so verification quality becomes an architectural property — which archetypes, how many, how compared — rather than a property of any single model.

The self-defending architecture

So what do you do? The answer is not "review everything" — volume has made that impossible. The answer is to stop relying on architecture being respected and start relying on it being enforced, and to flip it from a request into a feedback loop agents can correct against. An agent that hits a failing rule usually fixes itself and retries; that is the one property that makes enforcement more effective with AI than without it (architecture as feedback).

Concretely, seven things.

1. Enforce, don't describe. Turn every boundary into a linter/CI rule and let the error message be the instruction. eslint-plugin-boundaries, dependency-cruiser, no-restricted-imports, import-linter, ArchUnit — for whatever stack you run, spend one afternoon encoding the two or three boundaries whose violation would be structural. A blocked agent gets the fix in the failure text and moves on: "DB imports are restricted to infrastructure/* and features/*/repo/* — move this query." One enforced boundary kills an entire class of decay because the illegal import simply cannot exist (enforced-architecture).

2. Name every boundary. If you cannot say, in one sentence, what a directory is for and not for, an agent will either invent a new package or pile code into the biggest file. A routing table — "I want to change X → edit package Y" — makes agents triage by group instead of by vibe. If two packages could plausibly own the same change, the boundary is wrong (Agents Playbook).

3. Make decisions the artifact, not the outcome. An agent proposing a structural change without a written decision is proposing tech debt; reject the PR and ask for the ADR first. An agent proposing a breaking change without an RFC is proposing an unannounced break. The document is the change; the code is its implementation. This is not bureaucracy — it is the only mechanism that survives the second agent who cannot see why a decision was made and would happily revert it in service of a cleaner diff (Agents Playbook).

4. Pre-authorize the blast radius. The commonest agent failure is not a bad import, it is touching far more than the task needed. Declare the task's change scope up front — the components it may touch, the files it may write — and make the enforcement deterministic while the agent works. The agent cannot widen its own scope; widening requires a human (boundry's #touch scope, module-gates). This is not abstract: it is the single highest-leverage operational change in agentic engineering, because it converts "please be careful" into "you physically cannot."

5. Make the acceptance gate judge structure, not just behavior. A gate that only runs tests confirms the code still works; it says nothing about whether the code still fits. Add gates for shape: no new exports to locked files, no layer violations, no duplicated helper detectable by pattern, no growth in a protected module's surface. The gate is the only arbiter an autonomous loop really respects — so make it measure the thing you care about, not the thing that is easy to check.

6. Make verification heterogeneous. If a single model grades its own work, its failure modes get a friendly ear. When the check matters — security, migrations, anything P0-flavored — run orthogonal auditor types and treat their disagreement as the signal: the multi-archetype protocol lifted recall to 100% on P0 blockers, where the best single model managed 60% (23142634).

7. Give the agent a standing architecture contract. A repo-level AGENTS.md/CONVENTIONS.md that states the boundaries, the invariants, and the file-size/type disciplines is not documentation — it is the agent's briefing. Feed it your existing utilities so the model knows the date formatter exists. Version it like code, because it is code: it governs what gets generated. The strongest version of this pattern is architecture written as versioned, agent-optimized contracts that a "gatekeeper" role enforces at both ends — advising before implementation, auditing after (spec-driven architecture).

None of this is wishful: the numbers exist. Deterministic, spec-derived constraints eliminated process- and architecture-level violations at roughly 4× lower feedback cost than running the agent blind (2603.00822); specification-driven development — executable, constitutional specs instead of vibe-code acceptance — reports a 73% reduction in security defects in one enterprise deployment and ~50% in a second (2607.16680); and at production scale, a 25-month WhatsApp deployment of 3,000+ accepted AI changes settled into a measured 60/40 split — one-click rollout for high-confidence changes, commandeer-revise (the human takes over) for complex ones (2512.05314), while Google's large-scale migration practice kept human review of AI patches in place at ~74% AI-generated edits (3696630.3728542). The most capable teams are not the ones that tuned prompts; they are the ones that built gates their agents could not edit and loops that could always be reversed.

And above all, keep the human accountable for the expensive bits: write the meaningful tests yourself, read every line of generated PRs like the junior code it is, and reserve the walkthrough — "explain what changed and why" — for exactly the contributions that reshaped structure (Software Commons).

A slopper's checklist

If you are the one pressing the keys, here is the debt you are personally responsible for not creating:

Read the standing docs first. If the repo has AGENTS.md, CONVENTIONS.md, ADRs, or a boundary directory, they are your briefing. Ignoring them and then producing structurally off-code is not a model failure — it is a scoping failure.
Grep before you write. The function you are about to create probably exists. If your plan is the fourth date formatter, stop. Reuse beats generate, every time, on every axis that matters.
Prefer edit over append, and reuse over a third helper. Locality degrades one appended file at a time.
Never widen a type to silence a unit error. Widening string to unknown through three layers and asserting it back is not "refactoring for compatibility" — it is deleting the compiler's memory of your invariants. One study documented exactly this pattern as the top type-level slop (Taxonomy of AI Code Slop).
Never rewrite a test to make it pass. If the test was right and the code is wrong, train the other way. A test "trained to accept broken behavior" is worse than no test, because it certifies the break.
If the architecture has no place for your code, stop. That is not a prompt problem; it is a decision that a human must make. Propose the boundary change, do not quietly self-grant it.
Keep the blast radius equal to the task. Changes that touch seven directories for a one-file feature are scope vandalism, even if every file passes lint.

Architecture is the memory

The deepest thing the studies converge on is unflattering to everyone: AI code decays structure not because models are evil or stupid, but because the structure was never enforced — it was only ever requested. A prose boundary is a request. A lint rule is a memory. An acceptance gate is a verdict. Machines can generate code faster than humans can review it, but they cannot generate commitment to structure, because structure is decided, not generated, and it is decided one unglamorous refusal at a time: no, the UI cannot own queries; no, this domain rule does not belong in a controller; no, we are not adding an eleventh formatter.

That work is yours. And it is the one part of the job the model's average cannot hand you — because the average is precisely where the slop comes from.

Further reading: Debt Behind the AI Boom · Zhu, Tsantalis & Rigby, ASE 2026 · Faster Code, Deeper Debt? · Endless Stream of AI Slop · AI Slop and the Software Commons · AI Slop is DDoSing Open Source · The Modular Imperative · Autonomous Agents vs. AI IDEs (MSR'26) · Copilot Agent Mode Library Migration · Spec-Driven Architecture (INNOQ) · enforced-architecture · boundry