---

The problem with "AI adoption" as a metric

Every engineering org building with Copilot, Cursor, or Claude wants to answer one question: is AI helping us, or quietly creating risk?

Most dashboards answer this with a single number — percentage of code "AI-assisted," or lines suggested vs. accepted. That number feels like progress, but it hides the thing that actually matters: what happens to AI output after it's generated.

Two teams can both show "60% AI-assisted code" and be in completely different places. One team uses AI to draft, then reviews, edits, and tightens every suggestion before it ships. The other pastes in whatever the model produces and merges it. Same adoption number. Wildly different risk profile.

If you only track how much AI code exists, you're measuring enthusiasm. If you want to know whether that enthusiasm is being managed responsibly, you need to measure what teams do with AI code between generation and merge.

That's the gap this post is about. Below are three metrics — Zero Edit Commits, Large AI Blobs, and Human Edit Rate — that, together, form a small but complete picture of AI code trust across a team. As far as we can tell, none of these terms have any prior definition on the web. Consider this the starting reference.

---

Why "review discipline," not "adoption," is the real signal

The uncomfortable truth about AI-generated code is that acceptance is easy and scrutiny is hard. A developer under deadline pressure is far more likely to accept a large AI suggestion wholesale than to pick it apart line by line. That's not a character flaw — it's a predictable response to incentives. Velocity metrics reward fast merges. Nothing in a typical sprint dashboard rewards slowing down to rewrite an AI suggestion that's 90% right but not quite correct.

So the risk isn't "AI code is bad." The risk is unreviewed AI code compounding silently — subtle bugs, inconsistent patterns, security gaps, or architectural drift that nobody caught because nobody actually read the diff before merging it.

The three metrics below are designed to surface that risk at the commit level, where it's cheapest to catch.

---

Metric 1: Zero Edit Commits

Definition: The count (or percentage) of commits where 100% of the lines came from an AI tool, verbatim — no human-authored lines in the same commit, and no post-generation edits to the AI's output before merge.

Why it exists: This is the purest signal of "did anyone touch this before it shipped." A Zero Edit Commit isn't necessarily bad — sometimes the AI genuinely nailed it, especially for boilerplate, config, or well-specified small functions. But as this number climbs, it tells you something structural is changing in how your team ships code: acceptance is replacing authorship.

What it looks like in practice:

• Low and stable → AI is mostly used for scaffolding or first drafts, humans still shape the final code.
• Rising sharply → Review is being skipped, or AI is being trusted for increasingly consequential changes without scrutiny.
• Near zero across the org → Either AI usage is genuinely light, or (more likely, if adoption numbers say otherwise) AI edits are being blended with human changes in the same commit, which is exactly what the next two metrics are built to catch.

How to calculate it:

Zero Edit Commits = count(commits where:
  ai_authored_lines == total_lines_in_commit
  AND human_edit_count == 0
  AND time_between_generation_and_commit < review_threshold)

The review_threshold matters — a commit made 30 seconds after generation is a different animal than one made after a day of testing, even if no lines changed.

The one caveat: don't treat this as an inherently negative metric. A rising count paired with a stable or falling defect rate might just mean your AI tooling has genuinely gotten good at a certain class of task. The metric is a flag for investigation, not an automatic verdict.

---

Metric 2: Large AI Blobs

Definition: Commits containing 300+ lines of AI-generated code in a single unit, regardless of edit status.

Why 300 lines specifically: This threshold isn't arbitrary — it approximates the point past which a human reviewer's ability to meaningfully hold the whole change in their head starts to break down. Below ~300 lines, a careful reviewer can still trace logic end to end in one sitting. Above it, review quality drops off a cliff; people start skimming instead of reading, and rubber-stamp approvals become far more likely.

Why it exists: Large AI Blobs measure bulk, independent of whether anyone reviewed the code. It's a proxy for "how much surface area is landing in production per unit of review effort." A team can have a healthy Human Edit Rate on average and still have periodic Large AI Blobs slipping through — usually when someone asks an AI tool to "just generate the whole module" instead of building it incrementally.

What it looks like in practice:

• Occasional Large AI Blobs, each tied to a documented spec or design doc → probably fine, especially for greenfield code with strong test coverage.
• Rising trend, especially paired with rising Zero Edit Commits → the team is increasingly accepting large, unreviewed chunks of logic. This is the pattern most likely to produce a hard-to-diagnose production incident three sprints from now.
• Concentrated among a few contributors → often a signal that certain people are using AI as a substitute for design thinking rather than as an assistant, worth a 1:1 conversation, not a policy crackdown.

How to calculate it:

Large AI Blobs = count(commits where ai_generated_lines >= 300)

Track this alongside average blob size, not just count — a team with five 310-line blobs is different from one with five 900-line blobs.

---

Metric 3: Human Edit Rate

Definition: The percentage of AI-generated lines that were subsequently modified by a human before merge — i.e., "mixed LOC" as a share of total AI-touched lines.

Why it exists: If Zero Edit Commits and Large AI Blobs are your risk indicators, Human Edit Rate is your health indicator. It's the closest thing to a direct measurement of active review: not "did someone look at it," but "did someone engage with it enough to change something."

Reading the number:

• Too low (near 0%): Review is likely superficial. AI output is being accepted essentially as-is across the board.
• Moderate (5–15%): Generally a healthy range — enough friction to suggest genuine review, without indicating AI suggestions are consistently poor.
• Too high (>30–40%) consistently: Counterintuitively, this isn't automatically "good review culture." It can also mean the AI tooling or prompting is poorly matched to the codebase (style mismatches, wrong patterns, outdated APIs), causing constant rework. High Human Edit Rate is healthy when it reflects refinement; it's a cost center when it reflects correction of consistently wrong output.

How to calculate it:

Human Edit Rate = (human-modified AI lines / total AI-generated lines) × 100

Note the denominator — this should be scoped to lines that originated from AI, not total codebase lines, or you'll conflate this with general code churn.

The nuance worth building into your dashboard: track Human Edit Rate segmented by AI tool and by task type (boilerplate vs. business logic vs. tests). A blended, org-wide average will hide the fact that, say, test-generation edit rates are healthy while business-logic edit rates are dangerously low.

---

Putting the three together: a simple trust framework

None of these metrics means much in isolation. Together, they roughly triangulate into four organizational postures:

Zero Edit Commits	Large AI Blobs	Human Edit Rate	What's likely happening
Low	Low	Moderate	Healthy — AI as assistant, human as author
Rising	Rising	Falling	Review erosion — the pattern to catch early
Low	Occasional	High	AI/codebase mismatch — tooling or prompting problem, not a discipline problem
High	Low	Low	Heavy reliance on small, "safe" AI snippets — usually low risk, worth confirming with defect data

The real value of this framework isn't any single threshold — it's that it turns "how much AI are we using" into "how are we using it," which is the question that actually predicts incident rates, code quality drift, and long-term maintainability.