After an AI coding agent modifies your code, the most common question is:
“Can you check if there are any bugs?”
This isn’t wrong.
But the scope is too broad.
Reviewers might end up listing:
Naming issues.
Formatting problems.
Some general suggestions.
Meanwhile, the truly critical problems might not be explicitly asked about.
Today, we’ll learn just one method.
Before opening a Pull Request after AI changes the code:
Always split the review into three columns.
Impact Scope.
Rule Conflicts.
Unresolved Risks.
First Column: Impact Scope
Don’t first ask:
“Are these lines of code well written?”
Instead, ask first:
“Who else will be affected by my changes here?”
This is the Blast Radius.
For example, a coding agent modifies:
The Response Format of the login API.
All tests within this repository pass successfully.
But another repository, such as:
The mobile app,
Admin dashboard,
Or billing service,
might still rely on the original format.
If the reviewer only looks at the current diff,
it may be difficult to notice.
Qodo’s Codebase Context leverages repository, PR history, specifications, live git state, and cross-repository relationships to help analyze such impacts.
So always ask in the first column:
Which other files, services, interfaces, or repositories might this change impact?
Second Column: Rule Conflicts
Then ask:
“Does this change violate any existing rules?”
For example, the team may already have rules such as:
No direct modifications to production databases.
Certain APIs must remain backward compatible.
Sensitive data cannot be logged.
Payment processes cannot automatically retry.
Some directories must avoid adding new dependencies.
The code itself might:
Run fine.
Pass tests.
But still violate the company’s engineering policies.
Qodo Agentic Toolbox’s Get Rules and Rule Enforcement features bring organizational, repository, and scope-specific rules into the agent workflow.
So always ask in the second column:
Does this change conflict with current engineering rules, specifications, or existing design decisions?
Third Column: Unresolved Risks
The third column is the most important.
Don’t ask AI to:
“Fix all problems it finds by itself.”
Some issues can definitely be fixed right away, like:
Missing obvious error handling.
Lacking a critical validation.
Omitting a corresponding test.
But other issues are not simple “bug fixes.”
They require:
Decision making.
For example:
Should backward compatibility for the old API be broken?
Can the refund logic be changed this time?
Should retry be allowed to cause different production behavior?
Should data retention methods be altered?
If the agent chooses what seems like a reasonable answer on its own,
it might be technically correct,
but could be wrong from a business standpoint.
So always ask in the third column:
Which issues can’t be safely resolved automatically and require human decisions?
Putting all three columns together forms a simple review prompt
For example:
“First, review the current local changes without opening a PR. Split results into three groups: 1) Which other files, services, interfaces, or repositories might be impacted; 2) Any violations of current engineering rules or specifications; 3) Issues affecting production behavior, data, permissions, or architecture that require human decision. Clearly fixable issues can be proposed for fixes; decision-related issues should be paused without a final automated decision.”
You don’t have to always input this prompt verbatim.
The key thing to remember is:
Impact Scope → Rule Conflicts → Unresolved Risks.
Why not ask AI to fix first?
Because review and fixing are two different stages.
For example, if a reviewer finds:
Payment retries without an idempotency key,
that’s a relatively clear technical risk.
The agent can propose a fix.
But if the reviewer finds:
The requirements don’t specify how many automatic retry attempts are allowed on failed payments,
this is not just a missing line of code,
it’s a:
Requirement that hasn’t been decided yet.
It’s best to pause and consult with a human.
Qodo’s official Agentic Toolbox examples follow a similar boundary:
let the agent handle safely manageable problems,
and leave production-impacting decisions to developer review.
Put “Impact Scope” first, not last
Many people review code by:
First looking for syntax issues,
Then bugs,
And only later considering:
Whether other features might break.
For agent-written code, reverse this order.
A coding agent might change:
Ten files in a few minutes,
Add a new interface,
Adjust configs,
And add a suite of tests.
Each file might individually look reasonable.
The actual issue might lie:
Between files,
Between services,
Or even:
Between repositories.
So starting with the blast radius question
is usually more valuable than starting with coding style.
“Passing tests” doesn’t override these three columns
Suppose the agent reports:
All tests passed.
Great.
But this only proves:
The tests currently executed did not fail.
It does not automatically prove:
Other repositories weren’t affected.
No company rules were violated.
The requirements are sound.
No important tests were missing.
Production and local environments are identical.
The correct sequence is more like:
Agent modifies code.
Run relevant tests.
Conduct the three-column review.
Address clearly fixable findings.
Leave unresolved risks to humans.
Then open the PR.
Not:
Green tests → deploy immediately.
Why is Qodo particularly suitable before opening a PR?
Because the Agentic Toolbox Reviewer can check:
Committed changes,
Uncommitted changes,
And even new untracked files.
That is, it can review the code still in your current working tree.
This is different from discovering issues only after opening the PR.
The goal now becomes:
Spot issues while the author still has context in their mind.
If problems can be fixed at the local stage,
there’s no need for:
Reviewer comments,
A second commit,
And another review cycle.
But pre-PR review does not replace the formal PR review
This is another common misunderstanding.
Qodo itself clearly distinguishes between:
Local/pre-PR review,
And actual pull request review.
The purpose of the former is:
To let the author fix obvious problems before opening the PR.
The latter still includes:
Team discussions,
Approvals,
Merge control,
And final version validation after pushing.
So pre-PR review is:
An additional early layer,
Not:
A removal of the later layer.
Today, just remember this one thing
Next time Claude Code, Codex, Kiro, or another coding agent finishes a feature,
Don’t immediately say:
“Open a PR.”
Do a review first.
And don’t just ask:
“Are there any bugs?”
Always ask for:
1. Impact Scope
Which files, services, interfaces, dependencies, or repositories might be impacted?
2. Rule Conflicts
Are there violations of current team rules, specifications, security policies, or existing designs?
3. Unresolved Risks
Which issues cannot be safely decided by AI and require human input?
Then proceed accordingly.
Among the first two columns,
clear, low-risk, verifiable issues
can be fixed by the agent.
The third column,
involving production behavior, permissions, data, business rules, or architecture trade-offs,
should be handled by humans.
The real value is not just adding another AI saying “LGTM”
If the coding agent says:
“Done.”
And the reviewer agent says:
“Looks good.”
Two AIs agreeing
does not mean you have two versions of the truth.
The real value comes from the second agent:
Asking different questions than the first.
The first agent’s task is:
To implement the feature.
The second reviewer’s task should be:
Identifying:
Who is affected,
What rules are violated,
And which issues require decisions it can’t make itself.
Different roles:
The second layer of review really makes a difference.
So today’s one-minute tip is just one sentence:
After AI modifies code, before opening a PR, don’t just ask “Are there bugs?” Instead, split the review into Impact Scope, Rule Conflicts, and Unresolved Risks.
If the third column contains answers,
don’t let AI guess by itself.
That’s when humans need to step in.
Today, progress a bit more with AI.
Learn one AI skill every day.
Save a little time every day.
Improve a little every day.
SasaDaily, growing with you.
