Topics / Engineering practice
What should you check before merging an agent’s change?
Start with the promise the code must preserve. Then inspect the changed scope, executed evidence and remaining gaps, regardless of which coding assistant produced it.
Check the agreement first.
Ask what the change is meant to accomplish and which existing behavior must remain true. A confident implementation summary can leave out compatibility, error handling or customer promises that were not in the prompt.
Illustrative example
A faster importer silently drops bad rows.
The agent improves throughput by skipping invalid input. Tests pass because they use valid rows. If the accepted contract requires an explicit failure with the offending row number, speed has come at the cost of a promised behavior. Review that requirement before judging the optimization.
Use a small acceptance checklist.
- Intent: identify approved changes and preserved requirements.
- Reach: inspect touched components and recorded dependencies; disclose incomplete mappings.
- Evidence: check actual results, inputs and the candidate revision.
- Protection: inspect deleted tests, loosened assertions and changed policies.
- Decision: retain unresolved gaps and the authority to accept them.
Keep code inspection where it can resolve a material concern. Do not let a checklist become a ritual that hides missing behavioral evidence.
Make the context reusable.
Proof’s Software Intent Graph retains requirements and their connections to implementation, hazards and checks. That gives the next agent access to promises omitted from its prompt. Evidence must still be refreshed when its basis changes.
Try the process on one consequential PR. Compare the review effort and unresolved questions before deciding how broadly to deploy it.
Try it on your software
Bring your least comfortable agent-written PR.
We can make the acceptance questions and the evidence behind them concrete.