Agent-native source control needs a better handoff, not just a better diff

Agent-native source control needs a better handoff, not just a better diff

When an agent hands me a code change, I want more than an explanation of the files it edited. I want to know which decision authorised the work, which revision was tested, and exactly what I am being asked to accept.

That is the part of agent-native source control I find most interesting: making the relationship between intent, implementation and evidence inspectable. A prettier diff helps. A diff with no trustworthy account of why it exists still leaves the reviewer reconstructing the assignment.

OpenAI’s 4 November announcement that it plans to acquire Pierre gives that question a timely context. The acquisition is pending customary closing conditions, including regulatory approvals; the companies remain separate until closing. OpenAI says Pierre’s Trees and Diffs libraries already support file browsing and change review in Codex. Its stated ambition is to connect shipped code with people’s decisions.

The design below is my proposed handoff contract, not an announced Pierre or Codex feature.

Keep the familiar branch. Change what arrives with it.

Two days earlier, OpenAI described Pando, its internal Git backend. The engineering account is about serving many concurrent writers and readers while retaining Git protocol and client compatibility. OpenAI reports substantial improvements in its own environment. That does not establish that another team needs a new source-control backend.

It does suggest a useful distinction. Storage infrastructure helps a branch exist and move reliably. Review infrastructure helps a person decide whether that branch deserves to become part of the product.

I would start improving the second without waiting for a platform migration. Keep branches, commits and pull requests. Attach a small, versioned evidence packet to each agent-produced change. Let repository policy enforce the parts that can be checked mechanically, while leaving the product and engineering decision with a named reviewer.

The packet should answer five questions: what decision, which branch, what evidence, what uncertainty, and whose acceptance?

A worked change: prevent duplicate export jobs

Consider a fictional reporting product. A customer double-clicks “Export” while the first request is slow. Two expensive export jobs start. The agreed intervention is to make repeated requests with the same operation identifier return the existing job, not create another one.

The decision record should be narrower than “improve exports”:

Preserve one export job per customer and operation identifier. A repeated request returns the existing job. Do not change the export format, billing policy or retention period. The product owner accepts the behaviour; the service maintainer accepts the implementation.

That record needs a stable identifier and revision. Link the original issue, the observed failure, the relevant constraints and the owner. If the agent discovers that the current API cannot carry an operation identifier, it has found a decision to reopen, not permission to redesign the whole export service.

This makes scope review concrete. A reviewer can identify an unrelated billing change without having to infer whether the agent thought it was helpful.

Bind evidence to the code that actually ran

The branch section should record the repository, base commit, candidate commit and any dependencies on other changes. A branch name alone is not enough: branches move.

The evidence section should identify the commands, environment and results for that candidate. For this example, I would expect tests covering an initial request, a repeated request, two concurrent requests, and isolation between customers. Each test answers a specific part of the contract. A screenshot of a successful export cannot prove that concurrent requests are safe.

A compact handoff template might look like this:

Decision: EXPORT-17, revision 3
Scope: one job per customer + operation identifier
Repository / base / candidate: exact recorded references
Changed surfaces: request handler, job lookup, tests
Evidence: CI run URL, commands, environment, test results
Known gap: retry after worker failure needs owner decision
Review requested: maintainer correctness + product behaviour
Deployment authority: separate; not granted by this review

The reference values are populated by the workflow, not invented by the agent’s summary. A failed command belongs in the evidence too. “Not run because the integration database was unavailable” is more useful than a vague claim that testing is complete.

If a new commit arrives after the checks, the packet becomes stale. The system should mark it as needing refresh rather than retaining a reassuring green summary beside different code.

Make the reviewer’s question explicit

An agent can describe its own implementation fluently. That is not independent evidence that the implementation is correct.

I would separate the agent’s account from the reviewer’s work. The agent explains its reasoning, alternatives and known gaps. Automated checks supply reproducible results. The human reviewer evaluates the change against the decision and probes assumptions the tests may share with the implementation.

For the export example, the maintainer might ask whether the uniqueness rule is enforced atomically in storage. The product owner might ask what the customer sees when the existing job has failed. Both questions matter, but they are different approvals.

A useful review screen opens with the requested decision and unresolved risks, not a wall of generated prose. Evidence links should be close to the relevant claim. “Concurrent requests produce one job” should link to the corresponding test, not merely to the repository’s homepage.

Treat review as a receipt, not a conversation mood

After review, save a receipt identifying the accepted candidate, decision revision, evidence packet, reviewer and disposition. Dispositions should include accepted, changes requested and blocked pending a decision.

A conversational “looks good” can help collaboration, but it should not silently approve later commits. Nor should code acceptance imply permission to deploy, migrate production data or alter customer entitlements. Those are separate actions with their own authority.

If the base branch changes before merge, rerun the relevant checks on the integrated candidate. If resolving a conflict changes behaviour, request renewed review. Otherwise the receipt proves approval of a version that no longer exists in the form being shipped.

Retention matters as well. Keep enough evidence to investigate a later regression, but do not put secrets, customer payloads or unrestricted test recordings into a broadly readable pull request. Link controlled artefacts where necessary.

Try the contract before buying the interface

I would pilot this on one change type with a clear acceptance boundary, such as export reliability fixes. Add the packet to the pull-request template and require exact candidate references in CI output. Then inspect whether reviewers can answer the five questions without opening the original agent conversation.

Measure missing evidence, stale test receipts, reopened decisions and clarification requests. Do not declare success because the agent fills every field. The fields are useful only if they reduce uncertainty at acceptance.

Pierre’s work and OpenAI’s Git engineering point toward richer infrastructure around agent-produced code. My immediate requirement is smaller and more demanding: every proposed change should carry a traceable account of the decision it implements and the evidence supporting it.

That is a handoff worth improving, regardless of which editor or Git host wins.