How Much of Our Code Is AI-Written?
HOW MUCH IS AI-WRITTEN?
Hover or focus to flip ↻Commit trailers, bot accounts, co-author lines: how to measure your AI-authored code share with explicit signals instead of detector guesses.
TL;DR: You cannot measure the AI-written share of your codebase by asking a detector to squint at style, and you cannot measure it by asking developers to remember. You measure it with explicit signals declared at commit time and counted deterministically forever after: commit trailers, bot and agent accounts, co-author lines. It's the least glamorous convention your team can adopt this week, and it's the difference between an AI strategy with receipts and one with anecdotes.
Why the question is suddenly load-bearing
"How much of our code is AI-written?" used to be trivia. Now it's the denominator under every serious question a leadership team asks about AI: are the tools earning their seats, is quality moving, is churn concentrated in generated code, did review keep up with volume?
And the denominator is large. The Stack Overflow 2024 survey found 76% of developers using or planning to use AI tools in their development process, up from 70% the prior year, while trust stayed conspicuously partial: 43% trust the accuracy of AI output, and 30.4% distrust it. A workforce that mostly uses the tools and only partly trusts them is exactly the workforce that should be measuring.
The uncomfortable part: most orgs answering this question today are guessing. The guesses come in two flavors, and both fail in measurable ways.
Why detectors and surveys both fail
ML fingerprinting guesses. Style-based "AI detectors" estimate whether code looks generated. But generated code is trained to look like human code, assisted code is human-edited, and human code increasingly imitates assistant idioms. The output is a probability, and a probability is not an audit trail. There is one legitimate use: a clearly labeled estimate ("our model estimates roughly a third of merged lines were AI-assisted") reported as an estimate, never quoted as a hard fact. And never, under any circumstances, pointed at an individual developer as an accusation. The moment a guess becomes a personnel data point, you've built a lie detector out of a language model.
Self-report misremembers. Asking developers what share of their work was AI-assisted seems safer. But the strongest evidence in the field says perception fails precisely here: in METR's randomized trial, experienced developers estimated AI made them 20% faster while measurement showed them 19% slower. If experts can't perceive the sign of AI's effect on their own work, their recollection of its share is not a measurement instrument.
The way out of both failures is the same: stop inferring after the fact and start declaring at commit time.
The explicit signals that actually work
Three conventions, all cheap, all deterministic, all queryable with plain git log:
1. Commit trailers
One agreed line in the commit message - Assisted-by: <tool> or an equivalent trailer - added whenever a commit contains meaningful AI-generated content. Trailers are machine-parseable, survive rebases and squashes if your merge convention preserves messages, and cost a few seconds per commit. Many tools can append them automatically. This single habit converts "how much?" from a debate into a query.
2. Bot and agent accounts
Autonomous work should never ship under a human's name. Give every agent and bot its own account, and its commits attribute themselves - no trailer required, no ambiguity possible. This matters double as agents take on whole tasks rather than autocompletes; the guardrail side of that story is in AI agents in your repo.
3. Co-author lines
Co-Authored-By: lines are a long-standing git convention that several AI tools already emit. If your tools write them, count them; if your platform surfaces them, you get attribution for free. They're weaker than trailers only because their presence depends on the tool's defaults rather than your policy.
Layer the three and you get a defensible statement: "N% of merged lines over the last quarter carried an explicit AI-assistance signal." That number is honest about what it is: a floor rather than an exact share, because unmarked assisted commits exist. A floor you can defend beats a point estimate you can't.
What to do when history is unmarked
Most teams adopt conventions after months of unmarked AI use. Don't retro-guess the history; you'll be laundering detector estimates into your baseline. Instead:
- Draw a line and measure forward. Attribution starts at the convention's start date; the trend from that day is clean.
- Use repo-wide trends for the past. You can't split old code into AI and human, but you can read what the era did to the whole repo. GitClear's 623-million-change dataset shows what those trend lines look like at industry scale: duplication up 81%, refactoring line-moves down about 70%, two-week churn up 15%. Your own duplication, churn, and refactor curves across the adoption boundary tell the local version of that story without needing per-commit labels.
- Treat adoption boundaries as natural experiments. Tool rolled out in March? Compare the quarters either side. It's cruder than attribution, but every input is a fact.
What the share is actually for
The AI-written share is a denominator. On its own, 20% or 60% means nothing; paired with outcomes, it means everything:
- Churn split. Is short-window rework higher in assisted commits than unassisted ones? That's the question AI code churn exists to answer, and it's unanswerable without attribution.
- Review pressure. Did review coverage hold as the assisted share climbed, or did volume outrun the reviewers?
- ROI. Every term in an honest AI ROI calculation, gains and costs alike, divides by how much assisted work actually shipped.
- Slop early warning. If duplication is climbing, attribution tells you whether it tracks the assisted share - the diagnostic thread that runs through AI slop code.
And one bright line, worth writing into policy: attribution measures work, never worth. The share of a person's commits that carried AI assistance is not a performance signal and not a proxy for skill in either direction. The moment attribution data feeds an individual ranking, developers will rationally stop marking commits, and your measurement dies of its own misuse. Keep the receipts about the system, and the system will keep giving you receipts.
Start the trailer convention this week. In a quarter, you'll be the only team in the room whose answer to "how much of our code does AI write?" starts with a number instead of a shrug.
Frequently asked
Can an AI detector tell me which code is AI-written?
Not reliably enough to act on. Style-based fingerprinting produces probabilistic guesses, and generated code increasingly looks like the codebase it was trained to match. A detector estimate can be reported as a labeled estimate, but it can never be quoted as a fact, and it must never be pointed at an individual.
What's the cheapest way to start attributing AI-assisted code?
A commit trailer convention (one agreed line like 'Assisted-by:' in the commit message) plus distinct accounts for bots and agents. Both cost minutes to adopt, work with every git host, and turn every future measurement from a guess into a query.
Is a high AI-authored share good or bad?
Neither, on its own. The share is a denominator, not a verdict. It becomes informative when paired with outcomes: churn, review coverage, and defect flow in assisted versus unassisted work. A high share with flat churn is adoption working; a high share with climbing rework is the early invoice.
Why measure the AI share at all?
Because every downstream question (is the tool worth the seats, is churn concentrated in generated code, did review keep up) divides by it. Without a defensible denominator, ROI claims and quality worries are both just narrative.