Source: Claude by Anthropic — Jason Clinton, Deputy CISO — 2026-07-21
Summary
Anthropic's Deputy CISO Jason Clinton describes how the company's security engineering practice adapted as its own engineers went from writing code by hand to shipping roughly 8x as much code per quarter as they did in 2021-2025 — with Claude now authoring about 80% of what gets merged into Anthropic's own codebase. The piece frames the shift as a change in what the security team actually monitors: instead of reviewing individual human-written diffs, the job becomes managing risk tiers, narrow-scoped reviewer agents, isolated agent identities, and release gates that sit between an agent's proposed change and production. The core argument is that security has to move from "monitoring bugs" to "monitoring loops" — since a single review step no longer catches everything when both the writer and a chunk of the reviewing is done by the same class of system.
Key Takeaways
- Anthropic's engineers now ship roughly 8x the code per quarter compared to the 2021-2025 baseline, and Claude authors around 80% of the code that gets merged into production.
- The write/review split isn't one-shot: one Claude instance writes the code, a second, separately-scoped Claude instance audits it specifically for security issues, before a human makes the final merge call — layered AI review rather than a single pass.
- Agent identities are isolated per task/scope rather than sharing one broad credential, so a compromised or misbehaving agent instance has a narrow blast radius instead of standing access to everything a human engineer could touch.
- Changes are bucketed into risk tiers, and higher-risk changes get proportionally more scrutiny (narrower reviewers, more gates) rather than applying one uniform review bar to every diff regardless of what it touches.
- Release gates specifically for agent-authored changes exist as a separate checkpoint from ordinary CI/CD — the assumption isn't "trust the agent's output because a human glanced at it," it's an explicit gate keyed to how the change was produced.
- The framing shift Clinton describes: as authorship volume outpaces what humans can individually diff-review, the security team's job moves from catching bugs in specific PRs to monitoring whether the surrounding loop (agent writes, agent reviews, gate enforces, human approves) is behaving correctly at scale.
Reel Script
Hook (18s, ~40 words): Anthropic's own engineers now ship eight times more code per quarter than they did a few years ago, and Claude writes about 80% of what actually gets merged. That's not a productivity stat — it's a security problem nobody had to solve before.
Core Concept (80s, ~180 words): Here's the actual shift: when one engineer writes one pull request, a human reviewer can read the whole diff and catch most problems. When an AI is authoring 80% of merged code, at 8x the previous volume, no human team can read every line at the same depth — the math just doesn't work anymore. So Anthropic's security team stopped trying to review every diff like it's 2022, and instead built a system around risk tiers: not every change gets the same scrutiny, only the changes that touch sensitive surfaces get the heavy gates. They also give each agent instance its own narrow identity for a task, instead of one shared credential that can touch everything — think of it like handing out a hotel keycard scoped to one room instead of a master key, so if one agent session goes wrong, the damage is contained to what that one task actually needed to touch. The philosophy Clinton states directly: the job stopped being "find the bug in this PR" and became "make sure the process that writes and checks PRs is sound."
Hands-On (60s, ~135 words): The concrete mechanism is a layered pipeline, not a single approval click. One Claude instance writes the change. A second, separately-scoped Claude instance reviews that change specifically hunting for security issues — not general code quality, security specifically. Only after that AI-vs-AI pass does a human engineer make the final call to merge. On top of that, agent-authored changes pass through release gates that don't exist for the general CI pipeline — an extra checkpoint that exists purely because of how the code was produced, not what it does. Stack those three things — narrow per-task agent identities, tiered risk scoring, and a write-then-audit-then-human-approve chain — and you get a pipeline built to scale review capacity roughly in line with how much authorship volume scaled.
Takeaway (25s, ~55 words): If your team is letting agents write meaningful chunks of production code, a single human "LGTM" on every PR won't scale past a certain volume — you need tiered risk and a second automated reviewer before a human ever looks at it. Go audit whether your current review gate actually scales with your agent's output, not just your headcount.