Hello Devs 👋
I have been thinking about something that has changed quite a bit with AI coding agents.
A developer can now give a task to Claude Code, Codex, Cursor, or another coding agent and get a working implementation back without writing every line manually.
That's great for productivity.
But there is a small problem.
Who reviews the code before the PR?
The usual workflow still looks something like this:
Developer gives task to AI agent
↓
Agent writes code
↓
Agent runs tests
↓
Pull request is created
↓
AI reviews PR
↓
Human reviews PR
The review is still happening after most of the work is already done.
This is where the idea of shift-left code review becomes interesting.
Instead of waiting for the PR, what if the coding agent could get its changes reviewed while it is still working?
That's the idea behind Qodo's new Agentic Toolbox, launched on September 9.
The toolbox lets coding agents use Qodo for codebase context, team rules, independent code review, and finding resolution directly from the coding session. Qodo's review can run against committed and uncommitted local changes before a PR exists.
And I think there is an important detail here:
Qodo isn't trying to be the agent that writes the code. It can act as the reviewer for the agent that does.
We've been hearing "shift left" in software development for years.
The basic idea is simple.
Find problems earlier.
Instead of finding a bug in production, find it during testing.
Instead of finding a security issue during release, find it during development.
Instead of finding a problem during a code review, find it before the PR is opened.
With AI coding agents, that last part becomes more important.
An agent can make a lot of changes very quickly.
If we let it write code for 20 minutes and only then send everything to a reviewer, we are still using an old review workflow with a new type of developer.
That's why I think the more interesting question is not:
"Can AI review AI-generated code?"
It is:
"Can we put an independent review step directly into the coding agent's workflow?"
There is an obvious question here.
If Claude Code writes the code, can't we simply ask Claude Code to review it?
Yes, we can.
And sometimes that's useful.
But there is a difference between asking the same agent:
"Now review what you just wrote."
and sending the change to a separate review system.
The agent that wrote the code already has a certain approach in mind.
It may think:
"I implemented the requirement, the tests pass, so we're good."
An independent reviewer starts from a different position.
It can look at the change and ask:
Qodo describes this as an independent review, where the coding agent builds while Qodo acts as a separate quality counterpart.
That's the part I find useful.
The goal isn't to make the coding agent smarter at everything.
It's to give it a second pair of eyes before the work gets to the PR.
With the Agentic Toolbox, Qodo provides a set of skills that coding agents can call when they need them.
Some of the important ones are:
qodo-codebase-wisdom`` get-qodo-rules``qodo-review`` qodo-review-resolver
These cover different parts of the workflow, from understanding the codebase to rules and reviewing local changes.
So a coding task can become something like this:
Understand the codebase
↓
Check the relevant rules
↓
Implement the change
↓
Run tests
↓
Qodo reviews the local changes
↓
Agent gets findings
↓
Agent fixes safe issues
↓
Review again
↓
Open PR
This is a much tighter feedback loop.
And importantly, the PR doesn't have to be the starting point for code review anymore.
Imagine I ask a coding agent:
"Update the payment service so temporary failures retry up to three times."
A normal coding agent might search for the retry logic, change the implementation, run the tests, and tell me it's ready.
But there may be more to the change.
Maybe another service uses the same interface.
Maybe the payment service has a rule that every outbound request needs a timeout.
Maybe retries need an idempotency key.
Maybe the team already decided in an older PR that certain payment failures must never be retried.
This is the kind of context that isn't always obvious from the task description.
Qodo's Agentic Toolbox can let the coding agent investigate related repositories, PR history, specifications, and live Git state before it changes the code.
So the agent can first ask questions such as:
"Which services depend on this interface?"
or:
"Have we changed this retry behavior before?"
That gives the agent a better starting point.
There is another part of this that I think is easy to overlook.
Most companies already have coding rules.
They might be documented in:
AGENTS.md
CLAUDE.md
README.md
CONTRIBUTING.md
or somewhere in an internal engineering wiki.
The problem is that developers don't always remember all of them, and AI agents definitely don't automatically know your organization's internal rules.
With Qodo's Agentic Toolbox, the agent can retrieve relevant global, workspace, and repository rules before implementation begins.
For example, imagine your team has rules like:
Payment APIs must use idempotency keys.
External requests must have explicit timeouts.
Sensitive customer data must never be logged.
Changes to shared interfaces require compatibility checks.
Instead of discovering these rules during PR review, the agent can get them before writing the first version of the code.
That's a much better place to enforce them.
Once the agent has finished the implementation, it doesn't necessarily need to open the PR immediately.
It can ask Qodo to review the changes that currently exist in the local workspace.
That can include committed and uncommitted changes. Qodo's review engine returns structured findings back into the coding session.
For example, the agent might get:
Finding 1
The retry loop can continue indefinitely
Severity: High
Finding 2
The payment request does not include an idempotency key
Severity: High
Finding 3
This error is being written to logs with customer data
Severity: Medium
Now the agent has something concrete to work with.
Instead of me copying comments from a PR back into the coding session, the findings are already available to the agent.
I can tell it:
"Fix anything you can resolve safely. Leave anything that needs a product or architecture decision for me."
The agent can make the safe fixes and leave the decisions that need a human.
That's the part of this workflow that I like.
It doesn't try to remove the developer from the process.
It tries to reduce the amount of basic cleanup the developer has to do.
One thing I wouldn't lose in all of this is the word independent.
If the same coding agent writes the code and decides whether the code is good, we haven't really created a second review step.
We've just added another prompt.
An independent reviewer gives us a different check.
Think about a human developer.
If I write a feature, I might look at my own code and think:
"This makes sense."
Then another developer looks at it and asks:
"Why are we doing this here?"
"What happens when this value is null?"
"Doesn't another service depend on this?"
That's why code review exists in the first place.
The goal isn't only to catch syntax errors.
It's to catch things the original author didn't think about.
The same idea makes sense with AI-generated code.
This is where the workflow becomes different from a traditional PR review.
Normally:
AI reviewer
↓
PR comment
↓
Developer reads comment
↓
Developer goes back to IDE
↓
Developer changes code
↓
Push again
↓
Reviewer checks again
With the Agentic Toolbox, the coding agent can receive the Qodo findings directly in its session.
So the loop can be:
Agent writes code
↓
Qodo reviews local changes
↓
Finding comes back
↓
Agent investigates
↓
Agent fixes it
↓
Qodo reviews again
Qodo calls this a way to bring review earlier into the coding workflow. The same review engine can run before the PR and then continue into the normal PR review process.
That means the review isn't a separate activity bolted onto the end.
It becomes part of the development loop.
I don't think shift-left review means:
"Let the AI review everything and don't bother looking at the PR."
That's not the point.
There are still decisions that an AI agent shouldn't make on its own.
For example:
Those are different from:
"You forgot to add the required timeout."
"This retry loop has no upper limit."
The idea is to let the agent handle more of the obvious engineering feedback while humans focus on the parts that actually require judgment.
Qodo describes this as moving toward human oversight rather than asking people to inspect every line of every AI-generated change.
This workflow isn't really about replacing the coding agent.
That's important.
If you're already comfortable with Claude Code, Codex, Kiro, or another MCP-compatible coding agent, the idea is to let that agent call Qodo when it needs codebase context, rules, review, or issue resolution.
For example, with Codex, Qodo announced a plugin on the same September 9 launch date that connects Codex to Qodo's codebase intelligence, organizational rules, and review capabilities. Codex can ask Qodo to review local changes and receive findings in the same session.
So you don't have to think of this as:
Qodo vs Claude Code
Qodo vs Codex
It's closer to:
Claude Code / Codex / Kiro
+
Qodo
The coding agent does the implementation.
Qodo provides the context, rules, and independent quality check.
I think this becomes much more useful when the repository gets bigger.
If I'm working on a small personal project, I can probably understand the whole thing myself.
But in a large organization, an agent might be changing one service inside a system with dozens or hundreds of repositories.
The changed code may have consumers somewhere else.
There may be an old PR explaining why something was implemented in a strange way.
There may be an organization-wide rule that doesn't exist in the repository.
This is where Qodo's Context Engine becomes part of the workflow.
The Agentic Toolbox can bring repository relationships, PR history, specifications, and live Git state into the coding session.
So before making a change, the agent can ask:
"What else could this break?"
That's a much better question than simply:
"Does this file compile?"
When people talk about AI coding agents, most conversations focus on how quickly they can generate code.
I'm more interested in what happens after that.
If agents are going to write more of our code, then the engineering process around those agents needs to change too.
We probably don't want this:
AI generates a lot of code
↓
Human reads everything
↓
Human finds obvious problems
↓
AI fixes them
↓
Human reviews again
That doesn't scale very well.
A better workflow could be:
Agent understands the system
↓
Agent loads the relevant rules
↓
Agent writes the code
↓
Independent reviewer checks it
↓
Agent fixes safe issues
↓
Human reviews important decisions
That's what I understand as the real idea behind shift-left code review for coding agents.
It's not simply moving the review button somewhere else.
It's making quality part of the coding process instead of something that starts after the coding process is finished.
I wouldn't turn this on for every repository on day one.
I'd start with one project where developers are already using coding agents.
Give the agent a real task.
Something that touches enough of the codebase to make context useful.
Then try a workflow like:
"Understand the affected services and dependencies first."
Then:
"Check the rules that apply to this repository."
"Implement the change."
And before opening the PR:
"Review my local changes and fix anything you can safely resolve."
The important thing is to see what happens in practice.
Those answers will tell you much more than a feature list.
For a long time, the pull request has been the natural place where code review happens.
That's not going away.
But with coding agents writing more code, I don't think the PR should be the first quality check anymore.
The agent has already made the change by that point.
If we can check the local changes first, fix the obvious problems, and then send a cleaner PR to the team, everyone benefits.
The developer gets faster feedback.
The reviewer gets a cleaner change.
The team gets fewer repeated comments.
And the coding agent gets a feedback loop instead of just generating code and hoping it passes review.
That's the part of Qodo's Agentic Toolbox that I find most interesting.
The coding agent writes the code. Qodo gets a chance to review it before the rest of the team ever sees the PR.
That is a pretty practical version of shift-left code review.
If you're experimenting with coding agents, Qodo's Agentic Toolbox documentation is a good place to start. The current workflow covers codebase questions, team rules, local review, and resolving findings from an open PR.
Qodo has also published its Codex integration details, which is useful if you're already using Codex and want to see how the review step fits into the same coding session.
AI coding agents have made writing code much faster.
Now I think we're starting to see the next problem: how do we make sure the code is good before it gets pushed into the normal review process?
That's where shifting code review left makes sense.
Instead of waiting for the PR, give the agent access to the right context, the team's rules, and an independent reviewer.
Let it catch and fix the things it can.
Then let humans spend their time on the things that actually need human judgment.
The PR still matters.
It's just no longer the first place where quality should happen.
Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖