What "percentage of AI-generated code" is asking
If you have ever been asked in a standup or a due-diligence call "how much of this codebase is AI-generated," you already know the question sounds simple and is not. A repo has no built-in label for where each line came from, so the number people want does not exist until someone defines how to compute it.
Quick Answer
To track the percentage of AI-generated code, measure at the diff level, not the file level: tag each commit or hunk by its source (agent-authored, human-written, or mixed) as the work happens, then roll those tags up into a ratio. Guessing from how code "looks" does not work, because a clean AI diff and a clean human diff are indistinguishable once merged. The reliable methods either capture the split at generation time (editor and CLI telemetry that sees what an agent versus a human typed) or infer it after the fact from commit patterns (size, cadence, and churn), which is weaker but better than nothing. Below: what actually counts as AI-generated, the methods that work, a comparison of the tools that measure pieces of this, and why the percentage alone still will not settle authorship.
There are at least three different things this question can mean, and they produce different numbers from the same codebase. It can mean lines emitted by an agent versus typed by a human, which requires capturing origin at write-time. It can mean commits authored via an agent workflow versus a manual one, which is coarser but derivable from tooling metadata if your agent leaves a trace. Or it can mean the share of the current codebase that traces back to an AI-assisted session at all, even if a human edited it afterward, which is the loosest and most common way teams mean it. Pick one before you measure, because conflating them is how two people arguing about "the AI percentage" end up disagreeing about a number neither has defined the same way.
This is usually the point where teams realize the question was really about risk or attribution, not curiosity. Legal and security teams ask because AI-generated code can carry licensing and quality questions. Engineering leads ask because they want to know where review effort should concentrate. Developers ask because they are being asked to defend their own authorship. The method you pick should match which of these you are answering.
What counts as AI-generated, and what does not
Before any tracking method works, you need a consistent definition, because the edge cases are most of the codebase in practice. A full autocomplete-accepted block from Claude Code or Cursor is the easy case. A human-typed line that was inspired by an AI suggestion two files over is the hard case, and most real codebases in 2026 are dominated by exactly that kind of blend.
A workable line: code is AI-generated if an agent produced the initial content of that hunk, regardless of whether a human edited it afterward, and human-edited-after-generation should be tracked as its own third bucket rather than folded into either side. This matters because a large share of "AI-generated" code in a mature codebase has been substantially reworked by a human, and lumping it in with untouched agent output overstates how much the agent shipped. In practice this three-bucket split (agent-origin untouched, agent-origin edited, human-origin) is more honest than a single number and answers more of the real questions people are asking.
Methods that work, from weakest to strongest
Here is the situation each method is built for: you need a number, and the question is how much you trust it. These four approaches trade effort for reliability, and understanding the trade-off matters more than picking the fanciest one.
- Eyeballing the diff. Looking at a pull request and guessing "this feels AI-written" is the weakest method and the most common one. It is unreliable because clean, idiomatic code looks the same regardless of origin, and you will systematically miss the messy AI output that a human then cleaned up. Use this only as a gut check, never as the reported number.
- AI-detection tools on finished code. Running a detector against the repo after the fact feels rigorous and is not. These tools are trained on stylistic quirks that both sides can defeat, produce false positives on clean human code, and cannot see anything that happened before the file reached its current state. If you have ever had a detector flag a senior engineer's tidy commit as "obviously generated," you have seen why this method fails in both directions.
- Commit and diff pattern inference. This is the first method that gives you something defensible without instrumenting anyone's editor. Large, structurally uniform commits that land in a single burst, especially ones with unusually low iteration afterward, correlate with agent-generated blocks. Diff-churn tools built for this, like GitClear, specialize in exactly this signal: measuring how much of a codebase's recent change is large, uniform, and rapidly superseded, which is a real and growing proxy for AI-authored volume. It is still inference, not observation, so treat the output as a strong estimate rather than a ground truth percentage.
- Capture origin at generation time. This is the only method that observes rather than infers. A lightweight editor extension or an editor-agnostic CLI tracker that sees terminal and agentic sessions (Claude Code, Cursor, Codex) can tag each block of output with its actual source the moment it is written, because it watches the session instead of reading the artifact afterward. This is the layer that makes a three-bucket split possible at all, and it is the one most teams skip because it requires instrumenting the workflow rather than just running a script against the repo.
The first two methods are fast and nearly worthless as evidence. The second two are where a real percentage comes from, and they answer different halves of the question: pattern inference tells you what probably happened across history, and captured telemetry tells you what is happening now, going forward.
A quick comparison of what each tool measures
Reaching for "an AI-code tool" is not specific enough, because the tools in this space measure different slices of the same problem. This table is the fast way to pick the right one for what you are trying to answer.
| Tool type | What it measures | Good for | Blind spot |
|---|---|---|---|
| AI-detection scanner | Statistical guess on finished code | A rough gut check, nothing load-bearing | Gameable both ways, no accountability |
| Diff-churn analysis (e.g. GitClear) | Size, uniformity, and rework rate of recent commits | Codebase-wide historical estimate, code-quality trend | Inference, not observation; cannot attribute to a person |
| Agent token/cost tracker (e.g. Tokscale) | Tokens generated and spent per agent session | Cost control, agent usage volume | Says nothing about whether output was kept, or by whom |
| Origin-capture telemetry | Real-time tag of agent-origin vs human-origin blocks | Accurate, ongoing percentage with attribution | Requires instrumenting the workflow going forward |
Almost always, teams start at the top of this table because it needs no setup, and end up at the bottom once the number needs to survive scrutiny. This is the same shift that shows up across the whole ai-code cluster: cheap signals are available immediately and mean the least, and the useful signal requires capturing the work as it happens.
Why the percentage alone does not settle authorship
Even a clean, well-measured percentage answers a narrower question than people think it does. Knowing that 40 percent of a file's lines originated from an agent does not tell you whether the remaining 60 percent represents deep engineering judgment or a light edit of agent output, and it says nothing about who reviewed, tested, or hardened any of it. A high AI-generated percentage on a well-architected, thoroughly reviewed feature can represent excellent, well-directed use of the tools. A low percentage on a fragile, undertested feature can represent someone typing slowly and not thinking hard.
This is the same reframe that runs through the whole prove-versus-claim question in software right now. A percentage is a claim about volume, not a claim about quality or ownership, and it is easy to over-read it as more than that. If you have ever seen a team celebrate "we're 70 percent AI now" as a productivity win without asking whether the 70 percent shipped and stayed, you have seen this mistake happen live. The number is a starting point for a conversation about where review effort belongs, not a verdict on anyone's contribution. For the deeper version of why volume metrics mislead in the agent era, see prove your code is human-written, not AI.
Where DevClocked fits
If all you need is a one-time, rough sense of how AI-heavy a repo has gotten, a diff-churn scan from a tool like GitClear against your git history is a fast, honest way to get there with no setup, and for a quick audit that is genuinely the right call. If your only question is agent cost and token spend, a tool built for that, like Tokscale, answers it directly and DevClocked would be the wrong tool to reach for.
DevClocked earns its place when you want the ongoing, attributable number rather than a one-time estimate: a running percentage of AI-origin versus human-origin work, tied to a Leverage Score for output per unit of real effort, built from a git baseline crossed with lightweight telemetry from an editor extension and an editor-agnostic CLI that sees terminal and agent sessions across Claude Code, Cursor, and Codex. A model learns the relationship between the commit history and the observed telemetry over time, so the split is calibrated from what happened rather than guessed from the finished diff. That is what turns a static percentage into part of a profile that proves what you shipped, audited to source, instead of a number you compute once and cannot defend six months later.
Common mistakes when tracking this number
Treating an AI-detector score as ground truth is the fastest way to produce a number nobody should trust, since these tools are gameable in both directions and carry no accountability behind the guess. Reporting one blended percentage instead of the three-bucket split (agent-origin untouched, agent-origin edited, human-origin) hides the most useful part of the answer, which is how much generated code survived human scrutiny. And treating a high percentage as automatically good or automatically bad skips the actual question, which is whether the output shipped, held up, and was reviewed by someone who understood it.
Related Guides
- How to measure AI coding productivity: the leverage framework this percentage feeds into.
- How to prove your code is human-written, not AI: why volume alone cannot settle authorship.
- How to prove you wrote the code: the broader provenance playbook.
- Track coding time from git: the calibrated-effort mechanism behind an honest percentage.
