The VS Code co-author incident asks the right question. But nobody's answered it yet.

You probably saw the VS Code 1.117 story: "Co-authored-by: Copilot" silently added to commits by default, including for code that Copilot never wrote. Microsoft reverted it in 1.119. Good.

But the revert is the wrong ending to the right story.

The developer anger was about consent and accuracy — both valid. What did not get picked up in the discourse was the architectural question underneath: even when Copilot does write code, a git trailer tells you almost nothing useful. It does not carry the prompt, the model version, the temperature, the insertion timing, the correlation confidence, or any risk context. It just says "an AI tool existed in this editor."

That is not an audit trail.

I have been building LineageLens to capture provenance at insertion time — before the diff ever hits git. Each insertion generates a structured record with roughly 40 fields: four timestamps, the full prompt body, the raw model response, 10 named capability slots indicating what was captured versus what went missing, a correlation confidence score, and the tool/provider/model that generated the code.

The design constraint is simple: everything that matters about a generation event either exists at insertion time or it never exists. By the time you are in a commit message, the prompt is gone. The model parameters are gone. The timing relationship is gone.

Here is what I would like to know from other makers: has anyone built or shipped tools where this level of capture was part of the requirement? Or is the market genuinely still satisfied with commit-time labels?

39 views

Add a comment

Replies

Best

the point about insertion-time capture stands out to me. Once code has been edited, reviewed, and committed, it becomes very difficult to reconstruct how it was originally generated or influnced

 Exactly. Once code passes through edits, reviews, and commits, much of the original generation context becomes difficult—or impossible—to recover reliably. That’s why I’ve started thinking about provenance as an insertion-time problem rather than a commit-time problem.

I don’t think commit-time labels are enough once AI-generated code becomes part of real engineering workflows. The useful audit trail has to exist closer to the generation event: prompt, model, context, confidence, timing, and what the developer changed after. Otherwise you only know that AI was nearby, not what actually influenced the code.

 That’s very close to how I see it. A commit can tell you what changed, but understanding what influenced the change requires evidence from much earlier in the workflow. Without that insertion-time context, provenance starts looking more like attribution than traceability.

 Exactly. Attribution answers “was AI involved?” but traceability answers “how did this code get here and what should we trust about it?” That second question is the one teams will actually need once AI-assisted code becomes normal in production workflows.

 I think that distinction is exactly where the conversation is headed. “Was AI involved?” is useful for disclosure, but “how did this artifact come into existence?” is ultimately the question teams will need to answer during audits, debugging, and incident reviews.

Once AI becomes part of normal development workflows, traceability starts mattering as much as attribution.

One thing I find compelling is the idea of capturing information before it gets lost. In many systems, the most valuable metadata only exists briefly and is never recorded

 I think that’s the key architectural constraint. Some of the most valuable metadata in AI workflows exists only briefly during generation and then disappears entirely unless captured intentionally. Once that window closes, there often isn’t a reliable reconstruction path.

I think most developers don't care about this level of provenance today, but enterprises eventually will.

A simple "generated by AI" label is enough for personal projects, but if AI-generated code becomes part of compliance, security reviews, or legal investigations, people will want much more context than a git trailer can provide.

 I think that's probably the transition we're heading toward. A lightweight AI attribution label may be sufficient for individual workflows today, but enterprise environments tend to ask much harder questions: which model generated this, under what context, who reviewed it, and can the evidence still be verified later?

Once AI-generated code enters compliance or security processes, provenance starts looking less like metadata and more like operational evidence.

Drop your comments below about this incident!!