DEV Community

Paulo Victor Leite Lima Gomes
Paulo Victor Leite Lima Gomes

Posted on

review and verification: making agent code mergeable

#agents #ai #productivity #softwareengineering

This is part 4 of a 5-post series on professional agentic coding for senior engineers.

Agent-written code should pass a stronger bar, not a weaker one.

That sounds obvious.

In practice, teams do the opposite.

The agent writes a diff quickly. The diff looks coherent. The human skims. The PR ships.

Then production explains what the review missed.

The fix is not to distrust agents blindly. The fix is to make verification explicit.

tests before trust

For a bug fix, ask for a regression test first when practical.

Before changing production code, add a failing test that reproduces expired sessions returning 500.
Run only that test and show the failure.
Then implement the fix.
Then rerun the test and the focused auth suite.
Enter fullscreen mode Exit fullscreen mode

This is not only about correctness. It also teaches the agent the target behavior.

Without a failing test, the agent may fix a nearby problem and still miss the actual one.

focused checks first

Do not start with the entire CI pipeline if the feedback loop is slow.

Start focused:

  • changed package tests
  • changed file tests
  • typecheck for changed package
  • lint for touched files
  • UI screenshot or Playwright spec for the changed screen

Then broaden:

  • full package test suite
  • full typecheck
  • build
  • integration tests
  • PR checks

This mirrors how senior engineers work manually.

Fast feedback first. Wider confidence later.

require evidence in the final summary

A useful agent final summary includes:

  • files changed
  • behavior changed
  • commands run
  • outputs or pass/fail state
  • checks not run and why
  • remaining risks

Bad:

Done. I fixed it.
Enter fullscreen mode Exit fullscreen mode

Good:

Changed:
- src/auth/session.ts
- tests/auth/session.test.ts

Verification:
- npm test -- tests/auth/session.test.ts: passed
- npm run typecheck: passed

Risk:
- Did not run full integration suite because local database is unavailable.
Enter fullscreen mode Exit fullscreen mode

This is the minimum useful handoff.

fresh-context review

The writer agent should not be the only reviewer.

Use fresh context.

Codex has /review, which can inspect uncommitted changes, a branch diff, or a commit and report prioritized findings without changing the working tree.

Claude Code can use a separate reviewer session or a review-focused subagent.

GitHub Copilot can review PRs too, but do not confuse automated review with approval. It is one input.

Good Codex pattern:

/review
Review the branch diff against main.
Prioritize correctness, regressions, missing tests, and security issues.
Do not suggest style-only changes unless they hide a real risk.
Enter fullscreen mode Exit fullscreen mode

Good Claude pattern:

Use a fresh reviewer subagent.
Review the diff for auth/security risks only.
Return file/line references, severity, and suggested fixes.
Do not modify files.
Enter fullscreen mode Exit fullscreen mode

The key is independence. The reviewer should not be carrying the implementation plan in its head.

compare against product intent

Agent code can pass tests and still be wrong.

Maybe the test asserted the wrong behavior.

Maybe the implementation solves a technical symptom but violates product expectations.

Maybe the API now behaves correctly for one client and breaks another.

Senior review is where product intent comes back into the room.

Ask:

  • Does this solve the user-visible problem?
  • Does it preserve existing contracts?
  • Does it create a migration or rollout risk?
  • Does it make observability better or worse?
  • Are failure modes clearer?
  • Can support explain this behavior?

Agents are good at local code changes. Senior engineers are supposed to see the system.

be careful with workflow changes

GitHub's Copilot docs warn about reviewing Copilot output and being careful with generated changes. This is especially important when the PR touches workflows, permissions, or automation.

Do not casually approve agent changes to:

  • GitHub Actions workflows
  • deployment scripts
  • secrets handling
  • auth middleware
  • database migrations
  • package-lock-level dependency changes

Those are high-leverage files.

The agent may be right.

Read them anyway.

bad practice: writer self-certification

The most common bad pattern:

Implement the fix and tell me if it looks good.
Enter fullscreen mode Exit fullscreen mode

Of course it will say it looks good.

You asked the author.

Better:

Implement the fix, run the focused tests, then stop.
After that, I will run a fresh-context review.
Enter fullscreen mode Exit fullscreen mode

Or:

After implementation, spawn a read-only reviewer subagent to inspect the diff for correctness and missing tests.
Enter fullscreen mode Exit fullscreen mode

Make review a separate step.

checklist

Before merging agent-written code:

  • Is there a regression test when practical?
  • Did focused tests pass?
  • Did typecheck/lint/build run where relevant?
  • Did a fresh-context review happen?
  • Are the final commands and results visible?
  • Are skipped checks explicitly explained?
  • Did a human compare the diff to product intent?

If the answer is no, the PR is not ready.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

Top comments (0)