From Idea to Responsibility: Why AI Coding Needs Engineering Provenance

From AI Coding Agents to Engineering Provenance and Human Responsibility

Over the last few months I have written several times about one change in software engineering.

AI is moving away from this:

Coding Assistant → Code Generation → Human Review

and toward something much more autonomous:

Idea → Agent → Planning → Implementation → AI Review → Testing → Artifact → Human Responsibility

In my presentations I used to describe this as the move from coding to review.

I am no longer sure that this describes the direction correctly.

AI systems can already review code. One model can implement a change, another can review it, and agents can run tests and correct the result. Human review is therefore no longer necessarily the final step of the engineering work.

I described that governance problem in AI Decision-Making: Who’s Responsible When Things Go Wrong? and the engineering side of it in From AI Coding Assistants to Autonomous Engineering Systems, both published on 8 June 2026.

So what remains exclusively human?

Today, legally and organizationally, one element remains central: someone still has to take responsibility for the result.

That is why I would now describe the transition differently:

Not from coding to review, but from idea to responsibility.

The human may perform less and less of the execution between these two points. And even the initial idea may not always remain exclusively human when agents begin proposing tasks and solutions themselves.

And recent research on identifying AI coding agents shows why the path between those two points needs much better evidence than we currently produce.

All sources were checked against their primary publications on 12 August 2026. Links to every source are in the reference section at the end.

If you don’t want to read it, just listen to the podcast on YouTube.

Table of contents:

1. Who actually wrote the code?
2. Agents already leave fingerprints
3. Git identity is not agent identity
4. Git history is necessary, but no longer sufficient
5. The handoff file was already a small provenance experiment
6. Self-evolving agents make this harder
7. Provenance leads to the ownership question
8. From ownership to responsibility and risk
9. From software supply chain to engineering provenance
10. Final thoughts
11. References and evidence mapping
12. My earlier posts this article builds on

1. Who actually wrote the code?

This sounds like an easy question. We have Git. We have authors. We have commits. But AI coding agents increasingly work through normal developer accounts.

A commit says:

Thomas → Commit

while the real engineering process was:

Thomas → Coding Agent → Model → Repository Context → Tools
       → Generated Change → AI Review → Tests → Thomas Approval

And in multi-model engineering, which I described in The Rise of Multi-Model Engineering (31 July 2026), it can become:

Human → Agentic IDE → Orchestration
   ├── Model A → Planning
   ├── Model B → Implementation
   ├── Model C → Review
   └── Model D → Documentation
   → Tools → Artifact → Human Approval

So who wrote the code? The Git author? The agent? The model that implemented it? The model that corrected it? The human who accepted it?

I think we need a different question:

Which systems participated in producing this artifact, what did each of them do, and who finally accepted responsibility for the result?

That is an engineering provenance question.

2. Agents already leave fingerprints

Research shows that agent participation is measurable even when nobody declares it.

Taher A. Ghaleb analysed 33,580 pull requests from five AI coding agents — OpenAI Codex, GitHub Copilot, Devin, Cursor and Claude Code — using 41 features that cover commit messages, pull request structure and code characteristics. The classifier identified the submitting agent with a 97.2% F1-score [1].

The fingerprints are specific per agent. Codex is recognisable mainly through its multiline commit pattern (67.5% feature importance). Claude Code is recognisable through code structure, for example the share of conditional statements (27.2%) [1].

Two things follow from this for daily engineering work.

First: agents do not only generate different code. They interact with software-engineering workflows in recognisably different ways. That matches what I observed while running several agentic IDEs in one project, although my own observation is anecdotal and the study is the empirical evidence.

Second, and more important: this attribution is reconstructed after the fact from behaviour. It is forensics, not documentation.

3. Git identity is not agent identity

A second study makes the gap clearer.

Arsham Khosravani and Audris Mockus ran a detection census across the World of Code infrastructure, which covers more than 180 million Git repositories. They combined four methods: configuration-file scanning, commit-message analysis, author-identity matching and bot-signature lookup [2].

In one snapshot, the combined methods identified 850,157 Claude Code commits. Bot-account lookup alone — the signal most adoption studies rely on — found only 28,154 of them, about 3.3%. The authors describe this as a 30-fold relative-recall gap and conclude that single-signal estimates are biased low by at least this factor [2].

Across snapshots from December 2024 to April 2026, commit-attributed agents were producing more than 320,000 commits per month by the April 2026 snapshot. Claude Code leads with 886,122 commits across 17,295 projects [2].

They also compared their commit-based census with the pull-request-based AIDev dataset and found that the two channels capture almost disjoint agent populations: Codex dominates the pull request channel but is nearly absent from the commit channel [2].

This is the practical point. The human Git account no longer describes the production process, and no single signal repairs that.

4. Git history is necessary, but no longer sufficient

Git tells us who committed, what changed, and when.

Agentic engineering also needs to answer: which agent participated, in which configuration, with which model, which context, which tools, which actions, which AI reviews, which tests, and which human approved the result.

I would call this additional layer engineering provenance.

My earlier traceability model was roughly:

Requirement → Feature → Task → Issue → Implementation → Commit → Test → Human Approval

I now think the implementation step itself needs traceability inside it:

Requirement → Task
   ┌─────────────────────────────────┐
   │ ENGINEERING PROVENANCE          │
   │ Human → Agent → Model(s)        │
   │ → Context → Tools → Actions     │
   │ → AI Review                     │
   └─────────────────────────────────┘
   → Artifact → Tests → Human Approval → Responsibility

5. The handoff file was already a small provenance experiment

This connects directly to my own practical work.

In Coordinating Multiple Agentic IDEs with a Shared Handoff File (20 June 2026) I used one shared docs/HANDOFF.md file across GitHub Copilot, OpenAI Codex, Claude Code and IBM Bob in a single local-first Python project. In that experiment Codex and Claude Code carried most of the implementation, Copilot supported inline, and IBM Bob ran a dedicated architecture-review pass.

My goal at the time was practical: reduce context loss, record what had been done, document decisions, and transfer state to the next agent.

Agent A → Task → Changes → Decisions → Handoff → Agent B

Looking at it now, I see a second effect I did not plan.

The handoff file is a very simple provenance artifact. It is not an audit system. But it shows the principle: when several AI systems participate in engineering, explicit state transfer also produces evidence about how the artifact was created.

6. Self-evolving agents make this harder

There is a further dimension.

A survey published on 4 August 2026 describes self-evolving coding agents: agents that improve future behaviour by updating their framework, memory, skills, tools, models or collaboration structures based on previous coding interactions and software-specific feedback [3].

If that is the direction, then recording the agent name is not enough. “Claude Code” or “Coding Agent X” describes a product, not a state.

We would also need to know: which state of the agent produced this result?

That affects reproducibility, debugging, security, auditability and governance — and potentially the evidence needed when questions about responsibility or ownership arise.

To be precise about what the source supports: the survey describes what can evolve. The conclusion that provenance must therefore capture agent state is my interpretation, not a finding of the paper.

7. Provenance leads to the ownership question

Provenance is not only a technical question. It leads directly to intellectual property.

If we cannot reconstruct how code was created and what the human actually contributed, it also becomes harder to determine which rights can safely be claimed for the resulting artifact.

Copyright. In Part 2 of its report on copyright and artificial intelligence, released on 29 January 2025, the U.S. Copyright Office concluded that outputs of generative AI can be protected only where a human author has determined sufficient expressive elements. Using AI to assist in the creative process does not by itself remove protection, and human arrangement or modification can create protectable authorship. But according to the Office’s analysis, providing prompts alone does not give the user enough control over the expressive result [4].

Now imagine a normal agentic workflow:

Human → Requirement → Agent → Model → 10,000 generated lines
      → AI Review → Human accepts pull request

How much human authorship exists in those 10,000 lines?

I do not think there is a universal answer that can safely be applied across jurisdictions and every development scenario today. That uncertainty is itself the point.

Patents. On 28 November 2025 the USPTO published its Revised Inventorship Guidance for AI-Assisted Inventions and rescinded its February 2024 guidance in full. The revised guidance says that no separate inventorship standard applies to AI-assisted inventions, that only natural persons can be named as inventors, and that AI systems are treated as tools comparable to laboratory equipment, software or research databases. The Pannu joint-inventorship factors are no longer applied to the AI question; they remain relevant only for joint inventorship between multiple humans [5].

Two things are worth noting here. The 2024 guidance is outdated, so older articles built on it should be treated with care. And this is examination guidance, not binding law — courts or legislation may still set the controlling rules [5].

So there is a real tension. Technically, an AI system can contribute more and more of the solution. Legally, inventorship and authorship still look for the human contribution.

That makes provenance relevant for a question that used to be trivial:

What did the human actually contribute?

8. From ownership to responsibility and risk

The chain therefore becomes longer than “who generated this code”:

Who contributed? → What was generated? → What was human-authored?
→ Which systems were involved? → Who reviewed it? → Who approved it?
→ Who owns the resulting rights? → Who accepts the resulting risk?

I want to be careful here. The exact legal answers differ between copyright, patents, contracts, employment relationships, licences and jurisdictions. Provenance does not solve ownership or liability. It does not automatically transfer or limit risk either.

But without provenance, answering those questions becomes harder, because the evidence about how the artifact was produced simply does not exist.

This is also where my privacy post from 28 May 2026 connects. There I argued that repository access, operational context, telemetry, logging and routing turned privacy into a structural choice inside the development environment. Provenance uses the same layer — but for a different purpose: not to limit what the tool sees, but to record what the tool did.

9. From software supply chain to engineering provenance

Software engineering already records part of its supply chain: dependencies, builds, SBOMs, CI/CD, signatures, artifacts.

AI adds a second chain:

Idea → Human / Agent → Agent State → Model(s) → Context → Tools → Actions
→ AI Review → Artifact → Human Decision → Responsibility / Risk

I do not know whether this should become another formal Bill of Materials. Maybe it should not. Standards create their own cost.

But I increasingly believe that some machine-readable provenance record will become necessary — not for more bureaucracy, but because otherwise we will own software without being able to reconstruct how it was really created.

10. Final thoughts

The fingerprinting research started with a technical question: can we identify which AI coding agent created a pull request? The answer is: surprisingly well, and mostly from behaviour rather than from declared identity [1] [2].

For me that leads to a bigger engineering question.

Why should we have to reconstruct this afterwards at all?

A trustworthy engineering environment should record it while the work happens. And once we record it, provenance connects several discussions that are usually treated separately:

Privacy → Traceability → Agent Identity → Model Provenance
→ Intellectual Property → Human Accountability → Risk

AI can now participate in almost everything between idea and responsibility. It can plan, implement, test, review, correct, document, and even propose what should be done next.

But our legal and organizational systems remain human-centered exactly at the points where inventorship, authorship, approval and accountability are assigned [4] [5].

That creates a strange situation. The human performs less and less of the execution, while remaining the point at which rights, accountability and risk have to be resolved.

This is why engineering provenance may become much more than an audit feature. It could become the evidence that connects three things: what the human intended, what the AI actually did, and what the human finally accepted responsibility for.

I think that is one of the central engineering questions of autonomous software development.

11. References and evidence mapping

[1] Agent fingerprinting Taher A. Ghaleb, Fingerprinting AI Coding Agents on GitHub, arXiv:2601.17406, 24 January 2026. Accepted at the 23rd International Conference on Mining Software Repositories (MSR ’26). 🔗 https://arxiv.org/abs/2601.17406

Used for: 33,580 analysed pull requests; five agents (Codex, Copilot, Devin, Cursor, Claude Code); 41 features; 97.2% F1-score; Codex multiline commit pattern 67.5%; Claude Code conditional-statement structure 27.2%. Supports sections 1, 2 and 10.

A follow-up paper by the same author, AgenTag: Attribution of AI Coding Agents from Behavioral Fingerprints (arXiv:2608.00966, August 2026), continues this line of work. 🔗 https://arxiv.org/abs/2608.00966

[2] Large-scale agent detection Arsham Khosravani and Audris Mockus, Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories, arXiv:2606.24429, 23 June 2026. 🔗 https://arxiv.org/abs/2606.24429

Used for: coverage of more than 180 million Git repositories in World of Code; four detection methods; 850,157 Claude Code commits in one snapshot versus 28,154 via bot-account lookup (3.3%, a 30× relative-recall gap); more than 320,000 agent commits per month by the April 2026 snapshot; 886,122 Claude Code commits across 17,295 projects; near-disjoint agent populations in the commit channel and the pull request channel. Supports section 3.

[3] Self-evolving coding agents Hao Zhou, Haichuan Hu, Ye Shang, Quanjun Zhang, Self-Evolving Coding Agents, arXiv:2608.03392, 4 August 2026. 🔗 https://arxiv.org/abs/2608.03392

Used for: definition of self-evolving coding agents; framework, memory, skills, tools, models and collaboration structures as objects that can evolve from previous coding interactions and software feedback. Supports section 6. The conclusion that provenance must identify the state of an agent is my interpretation, not a claim of the survey.

[4] Copyright and generative AI U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability, released 29 January 2025. 🔗 https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf 🔗 Announcement: https://www.copyright.gov/newsnet/2025/1060.html

Used for: protection depends on a human author determining sufficient expressive elements; AI assistance does not bar copyrightability; human arrangement or modification can create protectable authorship; prompts alone do not provide sufficient control under current technology. Supports section 7. This source does not establish a universal ownership rule for AI-generated software across jurisdictions. The application to source code is my engineering and risk interpretation.

[5] AI-assisted inventions and inventorship U.S. Patent and Trademark Office, Revised Inventorship Guidance for AI-Assisted Inventions, published in the Federal Register on 28 November 2025 (Docket No. PTO-P-2025-0014). 🔗 https://www.federalregister.gov/documents/2025/11/28/2025-21457/revised-inventorship-guidance-for-ai-assisted-inventions 🔗 USPTO alert: https://www.uspto.gov/subscription-center/2025/revised-inventorship-guidance-ai-assisted-inventions

Used for: rescission of the February 2024 guidance in full; no separate inventorship standard for AI-assisted inventions; only natural persons can be inventors; AI treated as a tool; Pannu factors withdrawn for the AI question and reserved for joint inventorship between humans. Supports section 7. Note that this is USPTO examination guidance, not binding law. The idea that provenance can serve as evidence of the human contribution is my interpretation.

12. My earlier posts this article builds on

• AI Coding Assistants, Agentic IDEs, and Privacy: From Chatbots to Operational Systems — 28 May 2026. Repository access, operational context, telemetry, logging and routing as structural choices.
• From AI Coding Assistants to Autonomous Engineering Systems — 8 June 2026. Controlled, traceable and reviewable engineering instead of pure generation.
• AI Decision-Making: Who’s Responsible When Things Go Wrong? — 8 June 2026. The review gap and governance as the steering wheel.
• Coordinating Multiple Agentic IDEs with a Shared Handoff File — 20 June 2026. The docs/HANDOFF.md experiment across Copilot, Codex, Claude Code and IBM Bob.
• The Rise of Multi-Model Engineering: Is IBM Bob Already Built for the Next Phase? — 31 July 2026. Orchestration across several models in one workflow.

Separating evidence from interpretation

The research supports these statements: agent activity is hard to identify through Git identity alone; agents leave measurable behavioural fingerprints; simple bot detection underestimates agent participation by a large factor; coding agents can evolve their own capabilities and state; and current U.S. copyright and patent frameworks continue to require a relevant human contribution.

From those findings I derive the broader argument:

Agent Attribution → Engineering Provenance → Human Contribution
→ Intellectual Property → Accountability → Risk

That final chain is my interpretation. It is not a legal conclusion and it is not established by any of the sources above.

Note: This post reflects my own ideas and experience. AI was used as a writing and thinking aid to structure and check the arguments, not to define them.

#AIEngineering, #AgenticAI, #CodingAgents, #EngineeringProvenance, #SoftwareEngineering, #AIGovernance, #AIAccountability, #HumanInTheLoop, #MultiModelAI, #ResponsibleAI