Now that coding agents can inspect code and suggest fixes before a pull request even opens, human code review has to evolve. If an agent already caught the obvious bugs, what is a reviewer actually supposed to do? This post is for developers who care about code quality, team mentorship, and the uniquely human aspects of building software together.
What does code review accomplish?
"Code review" is a generic label for several important jobs:
- Quality Check: Ensuring changes don't introduce bugs or regressions
- Onboarding: Knowledge-sharing to the reviewer about architectural or behavioral shifts
- Mentorship: Providing actionable feedback on system design & team practices
- Pairing: Collaborating to raise the quality bar
- Roadmap Alignment: Orienting the change to move closer to long-term system objectives
Coding agents can already cover much of this: catching obvious bugs, explaining diffs to orient readers, checking adherence to written standards, and sometimes, flagging gaps and edge cases.
Better yet, developers don't have to wait for a pull request to get this feedback. Agents push the benefits of code review directly into the inner development loop.
Agentic Review in the Inner Loop
Here's a workflow I find effective to cross-check code before asking someone to review:
- Make a code change
- Ask a clean-slate "reviewer agent" to evaluate the code
- Ask another agent to repair the issues raised in review
- Ask the reviewer agent to verify the fix
- Repeat as needed
The use of two agents adds overhead, but it increases the odds of catching a problem compared to keeping the review in a single context window. Use a different model for each agent to improve the odds of finding more flaws.
Whether you run these through dedicated interfaces like Google Antigravity, local IDE tooling, or a custom skill, here’s a starting prompt you can adapt for your own AGENTS.md:
As a principal engineer, review the changes in this repository:
1. Have I introduced any bugs, or made an existing bug worse?
2. Do key logical branches have consistent, actionable logging?
3. Are ambiguous decisions documented with inline comments?
4. Do code and comments agree?
5. Do READMEs or documentation need updates?
6. Do we have complete test coverage, including negative test cases?
7. Are new names for variables, types, methods, classes consistent
with surrounding symbols and do they have distinct meaning?
From Individual to Team Review
If developers only use agents locally, quality remains inconsistent. Because everyone is at different stages in adopting and evolving their agent use, there is often no shared baseline or visibility into what checks have actually occurred. Without insight, reviewers have to guess whether the author ran five rounds of agent review or zero.
Teams can standardize this by running agentic reviews and repairs as part of a CI/CD pipeline or review tooling, but an agentic review is prone to being overzealous and wrong. Minimally, teams should maintain shared agent skills or prompts that authors can run before opening a pull request. A commitment to run agentic reviews locally can be part of the social contract of contribution with high trust collaborators.
If these verifications are not standardized, consider attaching a process log to your work to explain what automations and agentic reviews have already been completed. Something short—this is meant to help review the code change, not add to the workload!
### Process Log
[x] Agent Repaired lint & security passstatic analysis findings
[x] Inner loop code review using project AGENTS.mdEdge-case audit
against AGENTS.md, team skill: Consistent Documentation
[x] Documentation consistency skill applied Ran e2e test with manual
review
This kind of practice sets a commonly understood baseline, freeing human reviewers to focus on what the AI is not being set up to replace: like deep domain knowledge & system-level architecture.
Using AI as a Reviewer
With agents sharing reports and feedback to perfect the code at every step of the way, what is the human reviewer's role?
As a reviewer, don't act as a proxy for AI feedback. Instead, use AI to make your own judgement more precise. When you spot a potential issue but aren't sure how to frame it, consult an agent to assess the problem and draft targeted messaging.
I might prompt the agent with something like "This function seems to miss properties of data structure X. What was overlooked, and is it a bug or a future enhancement?" This helps pinpoint the problem quickly and assess whether I want to flag it as a blocker, a follow-up, or leave it as out of scope. (Oh, and the answer to the question "is it a bug or a future enhancement" doesn't matter, the words it produces are a strawman argument that helps kickstart my thought process.)
Agents are also useful to spotlight our biases and blindspots, especially if you seed some initial observations to steer the agent away from what you're already thinking about. Put together some review feedback and then ask an agent "What might I be missing in the code and design trade-offs?".
Once I know I have something actionable to say, I might ask "Draft feedback on this problem". That draft usually provides the actionable technical details that are tedious to look up and write by hand.
AI backs up my instincts with the details I need to quickly pinpoint, verify, and communicate the issue.
Because my teammates are all using coding agents, my reviews increasingly focus on:
- Praise for practices I want to encourage (avoiding generic platitudes)
- Blockers for considerations the AI missed
- Suggestions and future-tagged comments for later improvements
- Broad feedback to request a particular agent skill or tool be applied
I use conventional comments to make any comment's purpose clear and actionable so anyone or any agent can prioritize what to address.
# Conventional Comment Review Feedback Examples
- praise: Thanks for making this private so we can't accidentally
endrun the main package interface
- issue: Anywhere the DB handle could be nil is an error because
the process will lack the required input data
- suggestion: Split testing positive and error outcomes into
different test functions … That simplifies the test logic and
makes it more apparent there's some gaps in the error cases.
- chore: I spotted a few documentation issues, could you run
the Documentation Consistency skill on this change in case
there's a problem?
Agents can improve code and code review, but only with shared expectations. That means deciding & documenting which jobs belong to CI, which belong to agents, and where human attention is actually required—especially when an AI can always find one more to polish.
Tools aside, the goal of code review hasn't changed: help each other ship good work.
As teams adapt to agent-first inner loops, I'm curious where you're drawing the boundaries: How has your team moved from ad-hoc personal AI tricks to an agreed-upon baseline?
Credits
Thanks to Jennifer Davis for help spotlighting the human signal in the review guidance noise.
Thanks to Nim Jayawardena for late draft review and telling me I haven't written myself into confusing corners.
Cover Photo by Ahmer Kalam on Unsplash
Top comments (0)