Build AI-Generated Code Guardrails: The 6 Checks Anthropic Runs

TL;DR An AI-generated code guardrail is an automated check that sits between an agent’s diff and your main branch, and Anthropic runs six of them before every merge — lint rules, tests, agent-driven end-to-end tests, nightly fuzzing, automated code and security review, and a standing refactor pass. Claude Code creator Boris Cherny says production code written by an agent needs a higher bar than human code, which is the whole case for building AI-generated code guardrails instead of trusting review alone. GitClear’s 2026 analysis of 623 million code changes shows why: block-level duplication is up 81% and refactoring is down 70% since 2023 — exactly the signature of teams skipping these checks.

What Are AI-Generated Code Guardrails?

Guardrails catch the failure modes an agent produces at a different rate than a human does — silent duplication instead of refactoring, a plausible-looking edge case nobody wrote a test for, or reviewer fatigue from a volume of PRs no human team scaled to handle. They aren’t a replacement for review; they’re what makes review sustainable once an agent can produce more diff per day than any team can read by eye.

The line comes from Anthropic’s own head of Claude Code. In September 2026, a developer emailed Cherny asking how to handle “AI slop” on a team where some engineers reviewed every line and others treated the agent as a black box. Cherny’s reply drew the actual distinction: throwaway prototypes can stay black-box if the blast radius is low, but “production code written by Claude should have a higher bar than if it was written by a human.” At Anthropic, he said, that bar is enforced by “lots of lint rules, lots of tests, Claude-driven end to end tests, Claude-powered fuzzers running daily, automated code reviews and security reviews, automated code refactoring, and so on.”

That list is a checklist, not a slogan. Six of those items map cleanly onto tools you can wire into a CI pipeline this week, which is the rest of this post — see also how the Rust project’s LLM policy drew a similar line by banning AI-created code while still allowing AI-reviewed code, a policy-layer complement to the technical guardrails here.

Why AI-Generated Code Needs a Higher Bar Than Human Code

The case for a higher bar isn’t a hunch — it’s in the commit history. GitClear’s 2026 “Maintainability Gap” research tracked eight quality signals across 623 million analyzed code changes from 2023 through 2026, indexed against the AI-assisted coding era, and the pattern is a team quietly trading review discipline for velocity:

• Block-level code duplication is up 81% — from an index value of 40.3 in 2023 to 73.0 year-to-date in 2026.
• Within-commit copy/paste is up 41%, while refactoring line-moves are down 70% over the same window.
• “Moved” (refactored) code fell from 21% of changed lines in 2022 to 3.8% in 2026, while copy/pasted lines rose from 9.4% to 15.7% — developers are now roughly 5× more likely to copy-paste than refactor.
• Error-masking constructs are up 47% — the broad, silence-the-warning kind of fix an agent reaches for when a narrower one requires understanding why something failed.

None of that is a story about AI writing worse code line-for-line. It’s a story about what happens when the volume of code changes faster than the humans reading it — duplication compounds because nobody has time to notice two blocks are now the same thing, and refactoring drops because refactoring requires understanding intent, not just producing output that runs. As GitClear puts it: AI writes that code faster than ever, and the bill arrives when you can least afford it.

The 6-Layer Guardrail Stack Anthropic Actually Runs

Cherny’s list groups into six layers, each catching a failure mode the others don’t. None of these are exotic — most teams already have layers 1 and 2; layers 4 and 6 are the ones GitClear’s numbers say get skipped.

#	Layer	What it catches	Self-hosted option	Managed option	Runs
1	Lint rules	Style drift, banned patterns, obvious correctness bugs	ESLint/Biome, Ruff, Clippy	—	Every commit
2	Unit & integration tests	Logic regressions, broken contracts	Vitest/Jest, pytest, cargo test	—	Every PR
3	Agent-driven e2e tests	Broken user flows a unit test can’t see	Playwright/Cypress, agent-authored specs	—	Every PR
4	Continuous fuzzing	Crashes, panics, malformed-input edge cases	cargo-fuzz, Atheris, jazzer, libFuzzer	Google OSS-Fuzz (free, OSS)	Nightly
5	Automated code + security review	Logic smells, injected vulnerabilities, leaked secrets, vulnerable deps	Semgrep, CodeQL	Claude Code review, Snyk	Every PR
6	Automated refactoring pass	Duplication and churn compounding silently	Scheduled agent pass over a jscpd/cloc-style dup report	—	Weekly/monthly

Layer 5 is the one worth naming precisely: Cherny’s “automated code reviews and security reviews” is the same category of tool this site already covers in depth — Anthropic’s own managed Claude Code review runs multiple agents in parallel against a PR, verifies their own findings against each other, and posts ranked comments back into GitHub, which is exactly the “review quality, not just review speed” problem this guardrail layer exists to solve.

How Do You Roll Out These Guardrails on Your Own Repo?

Add layers in order of blast radius, not in the order Cherny listed them — the goal is that every new check earns trust before the next one starts blocking merges.

1. Turn on lint as a blocking CI check first. If it isn’t blocking today, that’s layer zero — nothing else in this list matters if style and pattern violations still merge.

2. Extend your unit/integration suite to cover the paths the agent touches most. Point coverage tooling at the files with the highest recent commit churn; that’s where an agent has been working hardest and where gaps matter most.

3. Let the agent write its own e2e specs for new flows, with one human sign-off per flow. The agent drafts and maintains the test; a person approves the assertions once, not on every subsequent run.

4. Wire a nightly fuzzing job against one real target, not all of them. Pick your riskiest parser or input handler, run it against cargo-fuzz/Atheris/libFuzzer on a schedule, and expand to a second target only once the first is stable and triaged.

5. Turn on automated code + security review on every PR, tuned to high-severity only at first. Whether that’s Claude Code review, Semgrep, or CodeQL, start narrow so the signal-to-noise ratio earns trust before you widen the rule set.

6. Schedule a weekly duplication/churn report and route it to a real backlog. A jscpd or GitClear-style report that nobody reads is not a guardrail; it has to land as a ticket, not an email.

7. Re-measure your own churn and duplication numbers quarterly against the GitClear baseline above. If your copy-paste line is rising faster than your refactor line, you’re missing a guardrail — not writing more code.

What Breaks If You Skip a Guardrail Layer?

Each layer has a specific, traceable failure mode when it’s missing — this isn’t a generic “be careful” warning.

• Skip lint, and style drift becomes a review-time argument instead of a pre-merge non-issue, burning the reviewer attention every other layer here is trying to protect.

• Skip tests, and regressions ship silently until a user finds them — the oldest failure mode in software, just arriving faster now that diffs arrive faster.

• Skip agent-driven e2e tests, and a flow can be individually-correct-but-collectively-broken — every unit passes while the user-facing path never actually worked, exactly the gap unit tests can’t see by design.

• Skip continuous fuzzing, and the crashes an agent’s plausible-looking code hides show up in production instead of a nightly job — this is the layer behind incidents like a fabricated CVE report weaponizing “AI slop” trust and a malicious build script slipped into a package registry, where the bug that mattered was never in the diff a human read, it was in the input nobody tried.

• Skip automated review, and an injected vulnerability or leaked secret rides through on a PR volume no human reviewer can keep pace with — the exact approval-fatigue failure mode this site has written about separately.

• Skip the refactor pass, and GitClear’s numbers become your numbers — duplication compounds quietly because nobody’s job is to notice two blocks converged, until the “bill” GitClear describes arrives as a maintainability crisis nobody budgeted for.

How Much Does This Guardrail Stack Actually Cost?

Raw CI compute is the cheap part. At GitHub’s 2026 Linux runner rate of $0.006/minute, here’s a mid-size repo’s incremental monthly bill for the layers most teams don’t already run:

Layer	Assumed monthly volume	Minutes	Monthly compute cost
Nightly fuzzing	30 min/run × 30 nights	900	$5.40
Automated PR review	5 min/PR × 300 PRs	1,500	$9.00
Weekly duplication report	15 min/run × ~4.3 weeks	65	$0.39
Total raw compute	—	2,465	≈ $14.79/month

Lint and unit/integration tests aren’t in that table because most teams already run them — they’re not incremental cost, they’re the baseline. The number that actually matters isn’t the ~$15 of runner time; it’s whatever subscription sits on top of it. A managed reviewer or SAST platform (Claude Code review, Semgrep, Snyk) bills separately from the compute, and that license is the real line item to budget — the CI minutes were never where the money was.

FAQ

Do I need all six guardrail layers from day one?

No — start with the layer you’re weakest on today, which for most teams is either continuous fuzzing or a duplication report, since lint and tests usually already exist. Add one layer, let it run for two weeks so people trust its failures, then add the next. Bolting on all six at once just means nobody has time to triage the new noise.

What’s different about an agent-driven end-to-end test versus a normal one?

A normal e2e test is written once by a human and only updated when someone remembers to. An agent-driven one is regenerated by the same agent that changed the feature, so its assertions track current behavior instead of drifting stale behind it. The catch is that an agent will happily assert whatever the code currently does, bug included — so a human still signs off the assertions the first time a flow is added.

How does nightly fuzzing catch bugs that tests and code review miss?

Tests and reviewers check the inputs someone thought to write down; a fuzzer generates the inputs nobody thought of, and keeps running long after everyone went home. Coverage-guided fuzzers like cargo-fuzz or Atheris mutate inputs against the paths your existing tests already exercise, which is exactly where parsing and boundary-condition bugs hide. Running it nightly instead of per-PR is what makes it affordable — fuzzing needs sustained wall-clock time to find anything, not a five-minute CI window.

Does automated code review replace a human reviewer?

No, and treating it that way is the failure mode Boris Cherny’s own reply warns against — a human still has to hold the merge bar; an automated reviewer just changes what they spend their attention on. It’s good at flagging the mechanical stuff — an injected secret, a missing null check, a dependency with a known CVE — freeing the human to judge the one thing a model can’t: whether this is the right thing to build at all.

What does this guardrail stack actually cost to run?

The CI compute itself is cheap — at GitHub’s 2026 Linux runner rate, a nightly fuzzing job plus per-PR automated review on a mid-size repo runs under $15 a month in raw minutes. The real cost is the tooling layer on top of that compute: a managed reviewer or a SAST platform carries its own subscription, and that’s the number to actually budget for, not the runner time.

What’s the single highest-leverage guardrail to add first?

For a codebase already shipping AI-written PRs, it’s automated code and security review on every PR — the layer that catches an injected vulnerability or a duplicated block before a human ever sees the diff, and the one GitClear’s numbers say most teams are currently skipping. Fuzzing finds more exotic bugs, but review is what stops the everyday copy-paste-instead-of-refactor pattern that’s already inflating industry-wide churn.

Sources

• A quote from Boris Cherny — Simon Willison, September 2026
• The Maintainability Gap: 2026 AI Code Quality Research — GitClear
• Coming soon: simpler pricing for GitHub Actions — GitHub Changelog

If your team already has an AI writing policy for the prose side of the house, the same accountability principle applies here: guardrails don’t replace a human holding the bar, they just decide what that human spends their limited attention on. For the broader landscape of how agents are actually shipping code in production, see the AI Coding Agents & DX hub.