What this leaderboard cannot see
The fastest way to misuse this site is to read a number as a total. Every measurement here is a floor, and the gap between the floor and the truth is large. Publishing the ranking without publishing the gap would be the dishonest version of this project, so here is the gap.
1. Private code is invisible
Only public repositories are read. For most professional developers that excludes nearly everything they do. A staff engineer shipping AI-assisted work daily inside a company appears here only through weekend side projects, if at all. The ranking is a ranking of public AI-assisted output.
2. Inline completion leaves no trace
The dominant way people use AI to write code is accepting suggestions in the editor. Those commits are authored by the developer and look exactly like hand-written ones, because they largely are: the developer typed the prompt, read the suggestion and took responsibility for it. No honest method detects that from git history, and this one does not try.
The consequence is uncomfortable and worth stating plainly: the tool with the most users is among the smallest numbers here.
3. Attribution is opt-in
Every trailer-writing tool can be told not to write one, and teams turn it off for reasons that have nothing to do with hiding: noisy messages, changelog tooling that chokes on trailers, review conventions. A developer who disables attribution vanishes from this data while doing identical work.
This makes the ranking partly a measure of disclosure culture. Communities that consider the trailer good manners are over-represented against communities that consider it noise.
4. History gets rewritten
Squash merges are the default in a great many repositories, and squashing collapses a branch into a single commit whose message rarely carries the trailers from the commits beneath it. Rebases, amends and message linting do the same. The work happened; the evidence did not survive the merge.
5. The scan is incomplete
Coverage is the most fixable blind spot and currently the largest. Repositories are scanned progressively, so a developer whose main project is still queued ranks below where they belong, or does not appear. That figure is published on the coverage page and moves every day.
Every bias points the same way
None of these five can inflate a count. Every one of them removes work that happened. That is the single most useful property of this dataset: when a number here says a developer shipped 400 AI-assisted commits, the true figure is at least that, and the error bar runs in one direction only.
So what is it good for
Three things, and not much else.
Existence proof at scale. Whatever else is arguable, a large volume of AI-assisted commits is landing in public repositories, and it can be counted rather than surveyed.
Comparison within a convention. Two developers who both leave trailers on, in similarly scanned repositories, are fairly comparable to each other.
Tracking a signature over time. How a single tool’s detected volume moves month over month is meaningful, because the bias stays roughly constant even though its size is unknown.
What it is not good for: ranking engineers, comparing tools by market share, or inferring anything at all about code quality. If you see this data used for any of those, it is being used wrong, and we would rather say so ourselves than have it pointed out later.