Review AI-generated code with execution evidence
A diff shows what changed. It does not show which tests ran, what failed, or what the agent tried to access. Review the code together with execution records collected outside the agent.
A diff does not record execution
Suppose an agent changes authentication code and reports: “Added token refresh, wrote regression tests, and all tests pass.” The diff can confirm the code and test files. It cannot confirm that the full suite ran or passed.
A diff also cannot show an install script reading outside the workspace, a command killed by a resource limit, a refused network destination, or a browser error. These events may leave no file change.
Code review therefore needs two kinds of information: repository state and execution records.
Use each record for the question it can answer
| Record | Answers | Does not prove |
|---|---|---|
| Diff against the pinned base | What files changed | Which commands ran |
| Host-observed process exit | Which launched command ended, and how | Every command typed inside an interactive shell |
| Boundary refusal | Which file, socket, destination, or limit was denied | Why the workload attempted it |
| Box-claimed browser or shell event | What the instrumented component reported | That the component reported everything honestly |
| Agent summary | What the agent intended and believes it completed | That its claims are correct |
Do not merge these sources into one unlabeled log. host-observed means h5i recorded an event from outside the box. box-claimed means a component inside the box reported it. Both can be useful, but they support different conclusions.
Store evidence outside the workload's write access
An external observation loses its value if the agent can edit it afterwards. h5i stores ingested receipts outside every filesystem path granted to the box. The workload can submit detailed records, but it cannot rewrite host-observed exits or earlier ingested history without escaping the sandbox.
This is protection from the box, not from the host owner. A person who controls the machine can alter local files. h5i receipts are not third-party signatures, timestamps, or notarized audit records.
Keep failures and refused actions
Retaining only the final successful test run removes useful context. An earlier failure may show what the agent fixed—or that it weakened an assertion until the test passed.
Refused actions also matter. A request to a telemetry host may be harmless, while an attempt to read a credential directory may require investigation. The record should state what was refused without assigning intent.
Report missing evidence explicitly
An empty browser-error list can mean that no errors occurred, no browser ran, or browser collection failed. An empty network section can mean no connections were refused or that the selected isolation tier does not report them.
Use distinct states such as empty and unavailable. Missing observation must not appear as a successful result.
Review in this order
- Check the resolved policy and isolation tier.
- Read refused actions, failed commands, and resource-limit events.
- Confirm that the required build and test commands have observed results.
- Read browser errors and other box-claimed records, including unavailable sections.
- Review the diff against its pinned base.
- Compare the agent's summary with the records above.
This order prevents a confident summary from becoming the evidence against which everything else is interpreted.
What h5i exports
review/
├── patch.diff # file changes against the pinned base
├── report.md # execution and browser records for review
└── receipt.json # events, observer labels, policy digestThe bundle does not approve the patch. It gives the reviewer the code change, the policy applied to the run, and the available execution records in one place.
Sources and further reading
- Receipt fields and observer labels.
- Export bundle contents and limits.
- Review a pull request by running it in a detached box.
Questions that come up
Is an h5i receipt tamper-proof?
Why keep agent-reported records at all?
Review a pull request by running it
Read the report in an evidence-first order.
Put the record beside the patch
Export both, then review each artifact for the question it can actually answer.