AI vs Human Code Attribution: How to Split Credit Accurately (2026)

What attribution is really asking

Most people reach for attribution at an awkward moment. A client wants to know how much of the build was "really you." A manager wants an honest read on how the team ships now that agents write half the code. Or you are looking at your own project and cannot answer a simple question: how much of this did I drive, and how much did Claude Code or Cursor hand me? The word "attribution" makes it sound like a licensing footnote, but the real request underneath is trust. Someone needs to know whose judgment the code represents.

That is why the naive version of the question leads nowhere. "What percentage is AI?" treats code as a bag of lines to be sorted by origin, when the thing people care about is decisions, not characters. An agent can generate ninety percent of the characters in a feature while you make one hundred percent of the calls that made it correct: the schema, the failure handling, the payment edge case it kept getting wrong. In practice the character count and the credit rarely line up, and pretending they do is where attribution goes wrong first.

So attribution has two layers, and it helps to keep them apart. There is authorship, meaning who or what emitted a given line, and there is agency, meaning who decided that line should exist and be shipped. This is the split that matters, and it is why finished code is the wrong place to look for the answer.

Why you cannot recover attribution from the finished diff

If you have ever tried to reconstruct who wrote what after a feature is already merged, you have hit the wall this section is about. The instinct is to open the diff, or reach for an AI-detection tool, and infer origin from the code. It does not work, and it fails for a structural reason rather than a missing feature.

Finished code carries no reliable trace of how it came to exist. The same tidy, idiomatic function could be typed by a careful engineer or emitted by an agent prompted for clean style, and there is nothing in the bytes to separate them. AI-code detectors that lean on statistical tells are easy to fool and routinely flag genuine human work as machine-made, which is the exact failure that makes them unsafe to build a claim on. You will often see someone confidently label a clean module "obviously generated" when the author wrote every line by hand. Reading origin off the artifact is inspecting the one thing that no longer contains the information.

This is the same reason git commits do not prove the underlying work. A commit records a state of the tree, not the path taken to reach it. An agent can produce a large, plausible commit in seconds, and a one-line commit can follow an hour of you reasoning through a race condition. Commit size stopped mapping to effort the moment agents could write big diffs fast, so any attribution built on lines-changed inherits that broken assumption. The record you need is the process that produced it, not the snapshot.

The methods people try, ranked by what they prove

These are the approaches teams and individuals reach for when they need to split AI from human contribution, and they differ enormously in how much weight they can bear. The first two feel rigorous and prove almost nothing. The last one is unglamorous and is the only one that holds up.

The pattern in that table is the whole point. Every method above the last one tries to reconstruct attribution after the work is done, from an artifact that does not hold the answer, and each one degrades the more AI you use. This is why the reliable approaches all share one property: they record the split at the moment of writing, not by guessing later. Attribution is a capture problem, not an analysis problem.

Two of those rows name real tools worth understanding, because they solve adjacent problems and get mistaken for attribution. Churn-and-diff analytics in the GitClear mould are genuinely good at team-level code-quality trends, but they read the repository as snapshots and cannot tell you who steered a given change. Token trackers in the Tokscale mould measure how much your agents ran and what they cost, which is the input side, not the output side. Both are useful. Neither answers "who drove this." Don't confuse agent spend or diff churn with a real authorship split.

What a defensible split looks like

Here is the practical shape of an attribution you could put in front of a skeptical client and have it hold. It has three properties, and if you have ever had a contribution claim quietly doubted, you will recognise why each one matters.

First, it is captured as the work happens. The record notes which stretches were agent generation, which were you reviewing and rewriting, and which were the slow decision work that produces no lines at all. That means a lightweight tracker observing real activity, not a form you fill in afterward from memory. Second, it separates authorship from agency: it can show that an agent emitted a block and that you rejected most of its first three attempts before shipping the fourth, which is the difference between "AI wrote it" and "AI drafted it under my direction." Third, it is traceable to source, so the split is not a number you assert but one anyone can follow back to the commits and sessions that produced it.

This is where DevClocked's approach comes in. DevClocked leads with leverage and output: it measures what you and your AI coding agents shipped, not hours in an editor. Under the hood it combines a git baseline, a benchmark inferred from commit history that needs no per-editor plugin, with telemetry, the real activity events captured by a lightweight editor extension and an editor-agnostic CLI that covers agentic tools like Claude Code, Codex, and Cursor. An algorithm learns the relationship between the two over time. The git baseline alone is only an approximation and drifts the more AI you use, which is exactly why the telemetry layer exists: it observes the agent-versus-human split as it occurs instead of inferring it from a diff that has already erased it. The result is a record of AI-generated share and human-driven work that is calibrated, not guessed.

Where DevClocked fits (and where it does not)

Be honest about the cases where you do not need any of this. If you are a solo developer building for yourself and no one is questioning your work, attribution is a non-problem: keep using AI freely and ship. If your goal is only a rough sense of how much your agents run, a token tracker is a simpler tool, use one. And if your team wants aggregate code-quality trends rather than per-person authorship, churn analytics answer that better than a personal attribution record does. None of those situations need a captured split.

The case where DevClocked wins is narrow and real: when someone else needs to trust your specific contribution and "trust me" is not enough. A freelancer proving to a client that the judgment on a build was theirs, a developer showing a recruiter that they drove work rather than prompted it, a founder demonstrating to an investor that the team is shipping and not just spending tokens. In each of those, the value is that it is provable and human-driven, audited to source. That is the same reason the underlying argument keeps recurring across this whole topic: the signals people used to trust, a commit graph, a clean diff, a confident "I built this," are claims about the work.

Common mistakes

The most common mistake is treating attribution as a defensive act, as if the point were to prove you did not use AI. That framing lost. In 2026 using Claude Code or Cursor is the default way serious people ship, and denying it reads as either dishonesty or inexperience. The stronger move is to show your share proudly: yes an agent wrote much of it, and here is exactly what I drove.

The second mistake is attributing after the fact. Every time you reconstruct a split from memory or from the finished repo, you are estimating, and everyone in the room knows it. Capture beats recall, always, and it is the single decision that turns attribution from an argument into a record.

The third is confusing measures of input with measures of output. Token spend, agent run counts, and lines generated all describe what went into the work. Attribution is about what came out and who is accountable for it. Keep those straight and most of the confusion in this topic disappears.

Related Guides

• How to measure AI coding productivity: the pillar this sits under
• How to prove your code is human-written, not AI: the authorship version of this question
• How to track AI-generated code percentage: the calibrated split, in practice
• How to prove you wrote the code: provenance and audited-to-source basics
• Why git commits do not equal actual work: why the finished diff cannot carry attribution