AI Code Attribution: The Approaches and Where Each One Breaks

"How much of our code is AI-generated?" sounds like a question with a number for an answer. It doesn't have one, and understanding why is more useful than any figure a vendor will quote you.

There are four ways to approach it. Each measures something slightly different, and each fails in a specific, predictable way.

Why is this hard at all?

Because the artefact doesn't carry the information.

A merged pull request contains a diff, an author, a timestamp and a review trail. Nothing in git records whether a line was typed, autocompleted, generated wholesale, or generated and then rewritten. By the time code reaches your repository, provenance has been discarded unless something captured it earlier.

There's a second problem that no method solves cleanly: most AI-assisted code isn't cleanly AI-authored. An engineer accepts a suggestion, renames three variables, restructures a loop and adds error handling. Is that line AI-generated? Every method answers differently, which is why two tools measuring the same repository can report substantially different percentages and both be internally consistent.

The four approaches

IDE telemetry

Capture acceptance events at the source — what the assistant suggested, what the developer accepted.

Measures: suggestion acceptance rate, characters accepted.

Breaks when: accepted code is subsequently edited or deleted, which is common. Acceptance is not survival. It also only sees assistants you've instrumented, so a team using Copilot in the IDE and a separate agent in the terminal reports one and misses the other. And it's per-vendor, so multi-tool environments need multi-tool instrumentation.

Best for: adoption and engagement, not output.

Heuristic detection

Infer AI authorship from characteristics of the code and the commit — patterns, comment style, commit size and timing.

Measures: an estimate.

Breaks when: developers write in styles the heuristic associates with AI, or AI output is edited enough to look human. Accuracy is not independently established, and vendors relying on this approach generally don't publish false positive rates. Treat any figure derived this way as directional.

Best for: rough trend lines where being wrong by a margin doesn't change the decision.

Commit-level provenance

Record authorship at commit time and carry it with the repository — for example, using git notes so the attribution lives alongside the code rather than in a vendor's database.

Measures: which changes were AI-authored, at commit or line granularity, across multiple assistants.

Breaks when: it wasn't instrumented before the code was written. This approach cannot look backwards; it only works from the day you turn it on. It also requires code access, which is a real security review at most organisations.

Best for: organisations that need a defensible number going forward and can accept the access requirement.

Developer surveys

Ask people what proportion of their work involved assistance.

Measures: perceived reliance.

Breaks when: self-report meets estimation. People are poor at quantifying their own workflow, and answers shift with how the question is framed and whether respondents think the answer affects them.

Best for: adoption breadth and sentiment. Not for a percentage anyone will defend in a board meeting.

What should you actually do?

Start from the decision, not the metric. "What percentage of our code is AI-generated" is almost never the real question. The real question is usually one of: is the investment worth renewing, is quality degrading, or where should we add review capacity. Each of those has a cheaper answer than full attribution.

If the question is quality: you don't need attribution. Track review time per change and rework rate, and sample pull requests manually before and after adoption. This gets you a defensible answer using data you already have.

If the question is genuinely provenance: commit-level instrumentation is the only approach that produces a number that survives scrutiny, and it only works forward. Turn it on now if you'll need the number in six months.

Don't compare across methods. A 30% figure from IDE telemetry and a 30% figure from heuristic detection are not the same measurement and shouldn't appear in the same table.

Expect the number to be unstable. Attribution percentages move with tooling changes, team composition and how aggressively developers edit suggestions. A single point-in-time figure has a short shelf life.

Where this is heading

The engineering analytics market has split along this line. Platforms built before 2026 — the established engineering intelligence category — operate on metadata and cannot attribute at the code level. That's an architectural constraint, not a missing feature, and vendors on both sides now frame it as their positioning: metadata platforms present code access as a security advantage, code-level platforms present it as a capability ceiling.

Both framings are marketing. The practical question for a buyer is narrower: do you have a decision that requires provenance, and will you accept a tool reading your source to get it. Most teams answer no to the first, which makes the second moot.

Frequently asked

Can we work out our AI percentage retroactively? Only by heuristic estimation, with unestablished accuracy. Provenance-based methods require instrumentation before the code was written.

Do metadata-based platforms give any AI signal at all? They can show correlated movement — instability, cycle time and rework changing after a rollout. That's useful. It isn't attribution, and shouldn't be presented as it.

Is acceptance rate a good proxy? It's a good adoption metric and a poor output metric. Accepted suggestions get edited and deleted at rates that vary widely by team.

What if we use several assistants? Then per-vendor telemetry undercounts by design. Multi-tool environments need either a vendor-neutral provenance layer or acceptance that the number is partial.