The interesting question is no longer "can the agent produce a diff?"
It can. Sometimes the diff is useful. Sometimes it is a confident mess. Either way, that is not the hard part anymore.
The messy part is what happens between the prompt and the diff.
What did the agent read? What did it skip? Which files did it decide were relevant? Which commands failed? Did it verify the change, or did it just reach a plausible stopping point? How much context did the harness pour into the model before the actual work started? Did anything leave the local machine that should not have?
If the answer is "check the transcript," the workflow is still immature.
A transcript is not a receipt. It is a box of parts.
The final diff hides the run
Code review is already a lossy activity. A human opens a pull request and tries to reconstruct intent from a patch, commit message, test output, and maybe a comment from the author.
Agents make that worse because they can do a lot of invisible wandering before the patch appears.
That wandering matters.
A small final diff can come from a focused run that read the right files, checked the call sites, ran the relevant tests, and stopped at the requested boundary. The same small diff can also come from a noisy run that scanned half the repo, ignored a failing command, picked the first pattern that looked familiar, and got lucky.
Those two runs do not deserve the same level of trust.
The diff alone cannot tell them apart.
So I keep coming back to receipts. Not in the compliance theater sense. I mean a practical artifact a reviewer can scan before deciding whether the next action is safe.
For coding agents, a useful receipt should answer boring questions:
- what task was attempted
- which files were read
- which files were edited
- which commands ran
- which failures happened
- what verification passed
- what verification was skipped
- what external tools or services were involved
- what the run probably cost
- where a human approval is needed next
None of this is glamorous. Good. The agent ecosystem has enough magic demos. It needs more boring evidence.
A session map is better than a transcript wall
Mindwalk is a useful signal because it treats an agent run as something you should be able to inspect spatially, not just scroll through.
The project turns Claude Code and Codex session logs into a local visual replay of how the agent moved through a repository. I do not think every team needs a 3D map. Most probably do not.
The useful part is the framing: raw logs are too low level to show whether the agent understood the task boundary.
That is the pain.
If an agent claims it fixed a bug in a billing module, I do not only want to see the billing diff. I want to know whether it read the data model, checked the route that calls it, noticed the feature flag, ran the right test, and avoided unrelated code. I want to see the footprint.
Footprint is a better review concept than "chat history."
Chat history preserves words. Footprint preserves shape.
It tells you whether the run stayed small, whether it touched surprising areas, whether the agent kept retrying the same dead end, and whether the final change matches the path it took to get there.
That kind of artifact fits real teams because review time is finite. Nobody wants to read a thousand-line transcript just to decide whether a three-line patch is sane.
Cost is part of the receipt
There is another receipt most teams are still missing: the cost receipt.
The Systima token-overhead writeup is useful because it measures agent behavior at the API boundary instead of hand-waving about "agents are expensive." The exact numbers belong to the captured setup, so I would not turn them into universal constants. But the lesson travels.
Agent cost is not just model pricing.
It is harness architecture. Instruction files. Tool schemas. MCP servers. Subagents. Extended thinking. Cache behavior. Baseline context that gets loaded before the useful work even starts.
That means cost is partly a product and workflow design problem.
A team can make an agent run expensive before the agent has made a single good decision. Add more global instructions. Add more tools. Add broad MCP access. Split work into subagents without a clear handoff. Suddenly the run feels powerful, but every request drags a larger invisible machine behind it.
Cost observability belongs next to work observability.
If a run produces a patch, the reviewer should be able to see more than "the tests passed." They should also be able to see whether the workflow burned a suspicious amount of context to get there.
Sometimes that cost is justified. A risky migration may deserve a big context window and several verification passes. A typo fix does not.
Without a cost receipt, you cannot tell whether your agent workflow is getting better or just getting more expensive.
The community already feels the review problem
The Hacker News discussion around token overhead did what these threads usually do: some people argued about exact tool behavior, some defended the workflow, and some pointed at the bigger operational issue.
That bigger issue is reviewability.
Developers are worried that agents cost money. They are more worried that agents produce work faster than humans can safely understand it.
That is a nastier bottleneck.
If generation gets cheaper but review gets harder, the team did not really gain much. It just moved the queue. Now the expensive part is human attention, and the artifact sitting in front of the reviewer is bigger, noisier, and less explainable than before.
"Autonomy" gets slippery here.
An autonomous run that leaves weak evidence is not obviously better than a smaller run with clean receipts. In many engineering teams, the smaller run is the better workflow. It is easier to approve, easier to reject, easier to rerun, and easier to teach.
The goal is not to ban agents from doing real work. The goal is to make every unit of agent work reviewable enough that a human can make the next decision without performing archaeology.
The receipt should be designed into the workflow
Receipts do not appear by accident. You have to design the workflow to produce them.
Start with scope.
Before the agent runs, the task should have a boundary: the files or subsystem likely in play, the actions allowed, and the point where it must ask for approval. This does not need to be fancy. A short plan is better than a giant prompt full of policy language nobody reads.
Then capture reads and writes separately.
Edited files are obvious because Git shows them. Read files are easier to lose, but they matter. A reviewer wants to know whether the agent looked at the test, the interface, the migration, the docs, or only the file it changed.
Capture commands and failures.
A green final test is helpful. A failed test that the agent ignored is also helpful, just in a different way. Failure history tells you what the agent tried and what it may have misunderstood.
Capture skipped verification.
This is one of the most useful pieces. If the agent says "I could not run the integration tests because Docker was unavailable," that is a receipt. The reviewer can decide what to do next. If the agent quietly omits that detail, the patch looks more complete than it is.
Capture external boundaries.
The Grok Build CLI wire-level analysis is a good reminder that agent review goes beyond code changes. Developers increasingly want to know what a tool sends, stores, uploads, or exposes. Even if your team is not doing security research, the question is now normal: what left the machine?
That does not mean every article needs to become a privacy teardown. It means the receipt should name external tool use clearly enough that reviewers are not guessing.
Raw logs are not enough
A predictable objection is: "We already have logs."
Maybe. But logs are usually written for machines, debugging, or vendor support. A receipt is written for the reviewer.
That difference matters.
A useful receipt compresses the run without hiding the parts a reviewer cares about. It should not dump every token. It should not pretend the agent had a coherent plan if it did not. It should not smooth over failed commands because the final patch looks fine.
I want receipts that are a little rude, honestly.
"Read 37 files for a one-line change."
"Skipped tests because dependency install failed."
"Used three subagents and only one produced relevant output."
"Sent repository metadata to an external service."
"Changed two files outside the requested scope."
Those lines are uncomfortable. Good. They make the next approval easier.
The better agent workflow is smaller
There is a version of agent tooling that keeps chasing bigger runs.
More autonomy. More tools. More background tasks. More subagents. More context. More "just let it cook."
Some work really does need that. But for day-to-day engineering, I suspect the better default is smaller and more inspectable.
Ask the agent to do one bounded thing. Make it show the footprint. Make it report cost and verification. Approve the next step only when the receipt is good.
That sounds slower than full autonomy until you account for review debt.
A giant unreviewable run can feel fast in the moment and then steal the afternoon from everyone who has to understand it. A smaller run with a clean receipt may look less impressive, but it keeps the human in a position to make good decisions.
That is the product test for coding agents now.
Not "can it act?"
Can it leave enough evidence that a responsible human can approve what happens next?
If yes, the agent belongs in the workflow.
If no, you are not buying autonomy. You are buying a mystery that occasionally compiles.
Source notes
Top comments (0)