{"id":5884,"date":"2026-07-13T07:06:37","date_gmt":"2026-07-13T07:06:37","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=5884"},"modified":"2026-07-13T07:06:39","modified_gmt":"2026-07-13T07:06:39","slug":"how-an-anti-slop-registry-stops-ai-generated-code-from-violating-your-engineering-standards","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/how-an-anti-slop-registry-stops-ai-generated-code-from-violating-your-engineering-standards\/","title":{"rendered":"How an Anti-Slop Registry Stops AI-Generated Code from Violating Your Engineering Standards"},"content":{"rendered":"\n

AI writes compilable code that passes linting rules and reads cleanly (most of the time). Ironically, that\u2019s also the root of the problem. The code looks right, so it goes through AI review without much hassle, and three weeks later you\u2019re debugging a partial-write bug because an agent decided to write directly to the users<\/code> table. \ud83d\ude04<\/p>\n\n\n\n

There\u2019s a name for that kind of output, and it\u2019s \u201cslop\u201d. I\u2019m not talking about broken code here, just code that ignores the standards your team has spent years defining and learning. And since an AI agent can produce slop faster than any human can flag it, it accumulates at a rate your review process was never designed to absorb.<\/p>\n\n\n\n

In this article, we\u2019ll elaborate on what AI slop is, why your current guardrails miss it, and how Verify<\/a> uses invariants to verify (pun intended) AI-generated code against your standards at the same speed your assistants produce it.<\/p>\n\n\n\n

TL;DR<\/strong> The best way to keep AI-generated code from violating your engineering standards is to verify every change against those standards automatically, before it gets merged. An anti-slop registry can help you out with this. Think of it as a catalog of invariants or the standing rules every change must respect. They are applied automatically to every matching change, so violations are caught before a human even opens the diff. This way, you\u2019ll stop shipping AI slop without adding review headcount.<\/p>\n\n\n\n

What “Slop” Actually Means<\/h2>\n\n\n\n

Slop is not the same thing as a syntax error. Your tooling already does a good job at catching those. Slop is the set of choices an AI agent has made that are technically valid but logically wrong.<\/p>\n\n\n\n

For instance, it\u2019s a handler that skips the authentication middleware because the agent didn\u2019t know it was mandatory. Or maybe it\u2019s logging done with print<\/code> instead of the structured logger every other service uses. Or it\u2019s an error path that returns cleanly but never emits the metrics counter your dashboards depend on.<\/p>\n\n\n\n

None of these will necessarily fail a test or trip a linter. However, a senior engineer would flag each of them in a review. In fact, they\u2019ve probably flagged them more than once.<\/p>\n\n\n\n

Why Existing Guardrails Miss It<\/h2>\n\n\n\n

Now, you\u2019re probably thinking, \u201cI already have guardrails. How come they don\u2019t stop slop?\u201d Here\u2019s why it happens.<\/p>\n\n\n\n

Linters Spot Syntax and Known Anti-Patterns<\/h3>\n\n\n\n

Linters were never meant to encode “writes to the users table must go through UserRepository<\/code>.” That sort of rule lives in your team’s collective memory, not in a config file, and writing a custom rule for every convention your team holds is a project nobody has time for.<\/p>\n\n\n\n

Human Reviews Catch a Lot, but Not Everything<\/h3>\n\n\n\n

The first PR of the day goes well. By the tenth, your energy levels have dropped, your focus has become fuzzier, and things start to get approved in a blur. Our cognitive bandwidth simply doesn\u2019t scale with the volume of code AI can produce. Maybe we will evolve eventually, but as of now, we haven\u2019t. \ud83d\ude05<\/p>\n\n\n\n

AI Review Reads the Diff and Comments<\/h3>\n\n\n\n

AI review does help at the margins, but it has no external reference point for what your team requires. It\u2019s simply one model checking the output of another model.<\/p>\n\n\n\n

The common thread here is that none of these tools hold a durable, team-defined record of what every change must respect. However, that kind of record is what an anti-slop registry provides.<\/p>\n\n\n\n

Registry As a Catalog of Invariants<\/h2>\n\n\n\n

In Verify<\/a>, there\u2019s an invariant catalog<\/a> that works as an anti-slop registry. These invariants are basically rules defined by the team, and they apply to every matching change.<\/p>\n\n\n\n

Though they may seem similar to acceptance criteria, the distinction between the two is actually very simple:<\/p>\n\n\n\n