Pierre Diffs and the Human Side of Agent Code Review

When a coding agent produces a change in minutes, the next hard problem is deciding whether that change deserves to ship. That decision still belongs to people who can connect the patch to the system, the intended behavior and the evidence behind it.

On November 4, OpenAI announced an agreement to acquire Pierre Computer, the company behind Code Storage and the open-source Diffs and Trees libraries. OpenAI says those libraries already power parts of file browsing and change review in the Codex app. The acquisition has not closed: it remains subject to customary conditions, including regulatory approvals, and the companies remain independent until closing.

The announcement is interesting to me because it puts attention on an often overlooked part of the agent workflow: the moment a person has to understand what changed.

A diff is an interface for reasoning

Pierre’s open-source repository identifies Diffs and Trees as its projects. Diffs presents changes, while Trees provides file-tree navigation. OpenAI says Diffs also has an edit mode that lets a reviewer correct a line while reviewing it.

Those tools address a real usability problem. A reviewer needs to orient themselves in a repository, distinguish changed lines from surrounding context, and move between a patch and the files it affects. A clear interface can make those actions easier. It cannot determine by itself whether a payment authorization is correct, whether an edge case is tested, or whether an agent accidentally crossed a boundary.

A conceptual review flow linking the change, supporting evidence and the human decision.

Parallel agents change the review queue

If several agents work at once, the bottleneck can move from producing code to understanding multiple proposed changes. I would start by keeping each change small enough to explain, with its purpose, constraints and relevant test results close to the patch. When the change touches authorization, data migration or other consequential behavior, the reviewer also needs the assumptions and failure cases—not just a green test indicator.

A useful review interface should help answer three questions:

  1. What changed? Read the patch and its surrounding code together.
  2. Why is it safe? Inspect the relevant tests, evidence and assumptions; a passing build is not proof of every property.
  3. Who decides? Give the reviewer a clear way to accept, request changes or reject the proposal.

Those are workflow recommendations, not claims that Pierre’s libraries automatically provide each piece of evidence. The project provides building blocks; the team using them decides how to assemble a review process.

Open source and the next question

OpenAI says Pierre’s open-source projects will remain open source and that it intends to continue contributing. The company also says Code Storage customers can continue using it after the acquisition closes while features are brought into Codex. Those are announced plans; details may change, and the transaction has not yet closed.

I am interested less in treating a faster diff as a verdict and more in what a good diff makes possible: a reviewer who can see the change, follow its consequences, and ask for evidence before it becomes production code.

Sources

Sources reviewed on November 6, 2026. Follow jpalanco.com for more notes on AI, engineering and open-source tools.

Blog

Let's talk security

Talks, press or partnerships: get in touch.