AI coding agents made code generation cheap. Make review the scarce resource.

An agent can now hand you a multi-file patch faster than you can understand it. That changes the bottleneck. The question is no longer just whether Claude Code, Codex, Cursor, or Copilot can make an edit. It is whether your team can establish what the edit does, what it leaves untouched, and whether it is safe to merge.

A recent guide to agent harnesses argues that instructions, tool access, boundaries, and feedback loops often matter more to the result than switching models.^[1] I would add one more component: a review contract. It tells the agent what evidence to leave behind and tells the human exactly what they must still verify.

Define the review contract before the task

Consider a request to prevent double-booking in an appointment service. “Fix the bug” permits many plausible implementations: an application-level check, a database constraint, a transaction change, or some combination. It does not tell the agent which behavior must remain stable or how a reviewer will recognize success.

Give the agent a brief that names the invariant and the evidence you expect. For example:

Task: Prevent two confirmed appointments for the same clinician and slot.
Scope: API, database migration, and relevant tests only.
Preserve: Existing cancellation and rescheduling behavior.
Evidence: Add a test for concurrent booking attempts; run the
backend test suite and report the exact command and result.
Before finishing: Summarize changed files, migration risk, and
anything you could not verify. Do not open a PR or deploy.

This is not a demand for a persuasive summary. It is a way to make omissions visible. If the agent cannot run the concurrency test, the result is “not verified,” not “probably fixed.” If it changes the frontend despite the stated scope, the unexpected change becomes a review question rather than something hidden in a large diff.

Give the agent a reproducible workspace

The harness guide recommends short, current repository instructions that identify the project and its real setup, test, and check commands.^[1] Treat that file as a map, not as a substitute for access control. An instruction that says “don’t touch production” does not remove production credentials from the agent’s environment.

For a consequential change, I prefer a disposable branch or worktree with only the permissions the task needs. This command creates a separate checkout from the current commit; use a fresh branch name and path for each task:

git worktree add -b agent/appointment-fix ../appointment-fix HEAD

In that checkout, give the agent the approved task brief and repository commands. Keep deployment credentials and unrelated writable directories out of reach. If tests require services, document how to start a local test instance rather than quietly giving the agent access to a shared environment.

That setup also makes parallel agents less confusing. A 2026 tool comparison describes workflows that run agents in separate worktrees, but parallelism only helps if each result can be inspected and merged independently.^[2] Two agents editing the same checkout produce activity, not reliable evidence.

Review the patch in layers, not as one giant approval

Editors are putting more attention on granular inspection of AI-generated changes; an October report describes hunk-level review features across several coding environments.^[4] Hunk-by-hunk controls are useful, but an appealing diff can still encode the wrong invariant. Review the behavior first, then the implementation, then the incidental changes.

Start with the task brief and the agent’s claimed test results. Check whether the new test actually fails for the original bug and whether it exercises two competing bookings, not merely two sequential requests. Then inspect the migration and transaction boundaries. Finally, look for unrelated formatting, dependency, or configuration changes.

These Git commands provide a quick local inspection pass before you stage anything:

git status --short
git diff --stat
git diff --check
git diff -- path/to/relevant/test_file.py

Use paths from your repository, and read the full diff before accepting a change. git diff --check catches whitespace errors; it does not validate concurrency behavior. A passing test suite likewise says only that the tests you ran passed in that environment. Neither should be reported as proof that the entire feature is correct.

Separate agent claims from independent evidence

Tool rankings can help you decide what to trial, but they cannot certify a particular patch. For example, cubic reports bug-rate comparisons drawn from AI-written code it reviewed and notes that newer model defaults have relatively little data so far.^[5] That is useful context for evaluating tools, not a reason to skip your own acceptance checks.

For each agent-produced patch, I want three distinct records: what the agent says it changed, what commands actually ran, and what a reviewer independently checked. A command transcript is better than a bare “tests pass” claim; a reviewer running the relevant test in a clean checkout is stronger still. Where that is impractical, name the limitation in the PR.

This approach works across terminal agents and editor agents. Their interfaces differ, but the merge decision rests on the same questions: Did the patch preserve the stated behavior? Do the tests exercise the failure? Are the permissions, migration, and rollback implications understood? The review contract makes those questions part of the workflow before generated code arrives.

Key takeaways

• Specify the invariant, scope, and required evidence before delegating.
• Use a separate workspace and task-sized permissions; instructions alone are not a security boundary.
• Review behavioral tests and risky changes before polishing the rest of the diff.
• Record what ran and what remains unverified; never turn an agent’s claim into a test result.

References

1. The Harness Matters More Than the Model: Building an End-to-End Setup for AI Coding Agents — https://medium.com/@mahimarnab/the-harness-matters-more-than-the-model-building-an-end-to-end-setup-for-ai-coding-agents-bfb36a7a6b7c
2. Best AI Coding Tools and Agents (2026): Complete Comparison — https://superset.sh/compare/best-ai-coding-agents-2026
3. AI Code Review Tools: 4 Editors, 46% Trust Gap (2026) — https://tech-insider.org/ai-code-review-editors-trust-gap-2026
4. Best AI coding tools and agents, with Bug Bench data — https://www.cubic.dev/blog/best-ai-coding-tools

Generated by AI · OpenAI · gpt-6-sol