A line of code in a repository now has more than one possible origin. A person may have typed it, the completion mechanism may have suggested it, or an agent may have written it whole from a task stated in a conversation. Authorship attribution splits the contribution into exactly those three categories and adds to each what ordinary revision history does not carry: which model produced the fragment and which dialogue it came out of. On top of that the commit view shows a contribution breakdown: the shares of Composer, of each agent model and of human edits.
The naive view is especially natural here, because the tool that answers "who wrote this" has existed for decades and works. Revision history names the commit author, the message, the date - and that was enough for exactly as long as the commit author and the origin of the line were the same entity. While text was typed by hand there was no need to tell those two apart: they coincided by definition, and the whole construction of code review grew on that coincidence.
It breaks the moment the coincidence disappears. The commit author now means whoever submitted the change, not whoever produced it. Human, agent and completion land in the history under one name and with equal weight, although they have to be trusted differently: behind a hand-typed line stands an understanding of the task, behind an accepted suggestion a quick glance, behind an agent fragment the wording of an assignment that the history did not keep at all. A review that does not tell those three cases apart spends the same attention on everything and spends none extra where it is needed most.
So attribution is built in layers, and it is worth separating them once by origin - what sits on the machine and what is requested on demand. Below is that map: the category of the line and the model live in the attribution data, which is cached locally for speed, while opening files and commits fetches data from the server; the author, the commit message and the relative timestamp are shown inline; hovering adds the machine co-authorship marker, the conversation summary and commit statistics; the contribution shares are shown by the commit view; the full conversation is not served at all, only its summary.
Two rows of that map are the entire difference from ordinary revision history. The model name says what exactly produced the fragment, and the conversation summary says why. A commit message is written after the fact and describes the author's intent as remembered; the conversation summary records the assignment the code was actually written from. For a review those are different things: the first can be rewritten in hindsight and fitted to the result, the second is tied to what happened.
| Layer | What it shows | Where it comes from |
|---|---|---|
| The category of the line | Human, completion or agent | Attribution data, cached on the machine |
| The model | Which model produced the fragment | Attribution data, cached on the machine |
| The conversation summary | Which dialogue the code came out of | Fetched from the server on demand |
| The commit author and message | Ordinary fields of revision history | Fetched from the server on demand |
| The relative timestamp | When the line appeared | Fetched from the server on demand |
| Contribution shares | The split between sources across the commit | Shown in the commit view |
| The full conversation | Not shown, only the summary | Not available from attribution |
Turning this on is not a personal setting. The feature is available on the enterprise plan, and a team administrator opens it in the team settings; before that members do not have it, however hard they look. A version control repository with tracked changes is required - without history there is nothing to attribute. The rest is local: the editor decorations are toggled with a command from the palette, and a separate per-file blame view opens from the context menu. The line itself carries the author, the commit message and the relative timestamp, while hovering adds the machine co-authorship marker and the conversation summary.
The privacy side comes down to two reservations, and both are worth saying out loud before enabling. First: what is served is a summary rather than the whole conversation, so attribution does not turn the repository history into an archive of every dialogue the team ever had. Second: part of the data does travel to the server on demand rather than living entirely on the machine, and the local cache exists for speed rather than for isolation. The decision to enable is made by the organization for everyone at once, which is the right level for such a decision, but it also means an individual does not choose whether their work is attributed.
The price is twofold. The first part is technical and small: the decorations take room in the editor, part of the data is fetched over the network, and on a large file hovering does not answer instantly. The second part is more serious. Contribution shares are a number, and numbers in organizations start living lives of their own: they get rolled into reports, compared between people and turned into a metric. Attribution answers the question of where a line came from and says nothing about its quality, difficulty or value; trying to derive productivity from it creates a direct incentive to hand-type what the agent would have done faster and better.
Attribution is justified in two kinds of work. In review - to distribute attention: a fragment written whole by an agent from a short assignment is read differently from a line typed by a person who held the entire context in mind. In audit - to answer the question of origin after the fact, when months later someone works out where a piece in the codebase came from and on what grounds. Whether it works is checked with one run on known material: take a file where you remember exactly what you typed by hand and what the agent did, open the per-file blame view and check both categories, then hover over an agent line and make sure the conversation summary refers to that very assignment and not to a neighboring one.
The typical failures are predictable. Expecting decorations where the administrator never enabled the feature, and looking for the cause in the editor. Trying to attribute code that is not in the version control history. Reading a contribution share as an evaluation of a person rather than a sign of a line's origin. Treating the conversation summary as the full transcript and building an incident review on it. And taking attribution as a replacement for review: it says where a line came from, not whether it is correct.