DEV Community: Kiran Naragund

Cross-Repo Context in AI Code Review: Can Your Coding Agent Understand the Whole System?

Kiran Naragund — Sun, 25 Oct 2026 15:52:51 +0000

Hello Devs 👋

If you use an AI coding agent like Claude Code, Cursor, or Codex, you have probably seen it make changes across several files, run tests, and prepare an implementation in a few minutes. For everyday tasks, that can work really well.

The problem is that most real applications are not contained in one repository. A backend service might depend on a shared library, a frontend might rely on a particular API response, and another service might use the same database schema. A change can look perfectly fine in the repository being edited and still break something downstream.

This raises a question I think more developers should be asking: Can I give my coding agent context from other repositories, so it understands the impact of a change before it starts coding?

The answer is yes, but the tools approach the problem differently. Some focus on giving coding agents better context while they work. Others primarily bring cross-repository understanding into pull request review. That difference matters when choosing a tool.

Why does cross-repo context matter?

Imagine your team has three repositories:

checkout-web
     |
     v
customer-api
     |
     v
payments-service
     |
     v
shared-payment-client

A developer asks an AI agent to rename a field in shared-payment-client. The agent opens the repository, updates the type, and runs the tests. Everything passes.

But payments-service might still use the old field name. The customer API could transform the value before returning it, and the checkout application might have its own interface definition.

The agent has completed the requested change, but it hasn't necessarily completed the engineering task.

This is where local code search reaches its limits. Finding every reference to a symbol inside one repository is useful, but it doesn't tell you which other services depend on that symbol, why a particular API contract exists, or whether a previous pull request introduced a compatibility requirement.

Developers often know these details because they've worked on the system for years. An AI agent may need to discover them from source code, repository relationships, specifications, and engineering history.

Cross-repo context helps an agent understand not just where the code lives, but what depends on it.

What should you look for in a cross-repo tool?

I would separate the problem into two questions.

First, can the coding agent use cross-repository context before and during implementation? For example, can it discover downstream consumers, check API contracts, and find the history behind an existing implementation?

Second, can the review process inspect the completed change across repository boundaries? This is important because even an agent that receives good context can still miss something.

Ideally, you want both. The coding agent should have enough information to make a sensible change, and a separate review step should check whether the resulting code introduces problems elsewhere.

With that in mind, let's look at four tools: Qodo, Augment, Greptile, and CodeRabbit.

1. Qodo: Cross-repo context inside the coding agent and review workflow

Qodo is particularly interesting if you want cross-repository understanding to be part of the coding workflow, rather than something you only discover after opening a pull request.

Its Agentic Toolbox, launched in September 2026, brings Qodo's Context Engine, code review, and organizational standards directly into coding-agent workflows. Through the qodo-codebase-wisdom skill, an agent can investigate repository relationships, pull request history, specifications, and live Git state before deciding how to implement a change.

For example, imagine you ask Claude Code or Codex to change retry handling in a payment service. Before editing the code, the agent can investigate which repositories depend on the affected interface and look for an earlier pull request that explains why certain payment failures must not be retried. That information can influence the implementation plan instead of being discovered after the change has already been written.

The other important part is review. Qodo's qodo-review skill lets the agent request an independent review of committed or uncommitted local changes before opening a pull request. If the review finds a problem, the agent can investigate the finding, make a correction, and request another review during the same workflow.

That gives Qodo two roles: helping the agent understand the system before implementation, and providing a separate quality check after the code is written.

What Qodo 3.0 adds

Qodo 3.0, announced in October 2026, extends this idea beyond the individual coding session. Its Software Map helps teams see how repositories and services relate to each other, making it easier to understand the potential impact of changes across the wider system.

Qodo 3.0 also introduces PR Triage, which organizes pull request work into related work packages and gives reviewers a way to understand the broader scope and blast radius of changes. For deeper review, Qodo can generate a brief for a coding agent that includes repository relationships, potential impact, and review order.

Another important part is that the standards used by the organization can be brought into the coding agent's workflow through the Agentic Toolbox. This connects the context used during implementation with the standards and review process used later.

For teams working across many repositories, this broader workflow is the main distinction. The goal is not just to find related code. It is to connect system understanding, coding standards, implementation, and independent review.

Qodo 3.0 also adds full on-premises and air-gapped deployment options for organizations that need the platform and its codebase context to remain within their own environment.

Qodo is worth considering when you want cross-repo context available to coding agents and connected to an organizational code-quality and governance workflow.

2. Augment: Give coding agents deeper codebase context

Augment approaches the problem from the context-retrieval side.

Its Context Engine builds an understanding of code across repositories, services, and engineering history. Instead of relying only on an agent to search through files and decide which ones matter, it retrieves relevant context for the task.

Augment also offers its Context Engine through MCP, which allows compatible coding agents to access its context capabilities. Its hosted MCP mode is designed to provide context across repositories, making it useful for teams that want to keep using their existing coding agent while improving the information available to it.

Consider a request to investigate a checkout timeout. The relevant implementation might span a frontend, an API, a payment service, and webhook handlers. Augment's approach is to retrieve the relevant pieces and relationships so the agent can investigate the full request path without manually searching every repository from scratch.

The distinction here is that Augment focuses strongly on helping the coding agent find and use relevant codebase context efficiently. It is not simply a pull request reviewer that comments on a diff.

Augment is worth considering when your main problem is helping coding agents navigate large, connected codebases and retrieve the right context during implementation.

3. Greptile: Cross-repo context for pull request review

Greptile is primarily known for AI code review, and its cross-repository capabilities help it review changes with a broader understanding of the codebase.

Its Repo Clusters feature lets teams group related repositories so Greptile can use them as read-only context when reviewing a pull request. Teams can also configure repositories explicitly as additional review context.

Suppose a pull request changes a shared SDK. A review limited to the SDK repository might not catch that another service relies on the previous behavior. With the related repository available as context, Greptile can investigate how the change affects consumers and raise relevant findings during review.

This makes it useful for teams whose main concern is catching cross-repository issues before merging. Greptile also supports sending review findings to coding agents, so developers can use those findings to guide fixes.

The key distinction is the workflow: Greptile's cross-repo context is especially relevant to reviewing pull requests, while Qodo's Agentic Toolbox explicitly brings cross-repository investigation into the coding session before implementation as well as independent local review.

Greptile is worth considering when you want AI pull request reviews to account for related repositories instead of treating every change in isolation.

4. CodeRabbit: Automatically discover related repositories for review

CodeRabbit has also expanded beyond single-repository review. Its Multi-Repo Analysis feature lets reviews use context from related repositories, and its Automatic Repository Linking feature can discover relationships across an organization using signals such as imports, dependency manifests, and shared code patterns.

This addresses a practical problem: manually maintaining a list of related repositories can become difficult as a system grows. Services change, new packages are introduced, and repository relationships evolve over time.

When a pull request changes an API contract, shared type, or database schema, CodeRabbit can explore linked repositories to investigate downstream effects. Its goal is to surface problems that would be easy to miss when reviewing only the repository where the change originated.

That makes CodeRabbit a relevant option for teams that want cross-repository context integrated into their existing pull request review process, particularly when automatic discovery of related repositories is useful.

As with Greptile, the important distinction is to check where the context is available in your workflow. Cross-repository context during PR review is not automatically the same thing as giving your coding agent that context before it starts implementing a task.

CodeRabbit is worth considering when you want related repositories discovered and considered automatically during code review.

Quick comparison: Which tool fits your workflow?

Tool	Main strength	A good fit when
Qodo	Cross-repo context, agentic review, organizational standards, and system-level visibility	You want context before coding and independent review before the PR
Augment	Context retrieval across codebases, services, and history	Your coding agent struggles to find the right information in a large system
Greptile	AI pull request review with related-repository context	You want reviewers to catch downstream impact before merging
CodeRabbit	Multi-repo review with automatic repository linking	You want related repositories discovered and included in PR review

These tools overlap, but they are not interchangeable in every workflow. The best choice depends on whether you primarily need better context during implementation, better cross-repository review, or a more complete system that connects both.

Can I get cross-repo context in my coding agent today?

Yes. You don't necessarily need to replace Claude Code, Cursor, or Codex to do it. The important question is whether the context tool can provide information from repositories outside the agent's current working directory and whether the agent can access that information when planning a change.

For example, with Qodo's Agentic Toolbox, you can ask your coding agent to investigate the system before implementing a task. A useful prompt might be:

Before changing this API:

1. Identify repositories and services that depend on it.
2. Find relevant API contracts and specifications.
3. Check pull request history for previous compatibility decisions.
4. Explain the likely impact of the proposed change.
5. Then suggest an implementation plan.

The point is not to make the agent read every repository. It is to help it identify the repositories and historical context that matter for the task.

You should still verify the results. Repository access, indexing, permissions, and the quality of dependency information all affect what a tool can discover. A cross-repo context system can help surface relationships, but it cannot guarantee that every downstream risk will be found.

How I would evaluate these tools

I wouldn't judge cross-repo context using a small coding task that only touches one service. Most tools can appear effective when the answer is already visible in the current repository.

Instead, I would choose a real change that crosses a service boundary, such as renaming a shared API field, changing a timeout, or modifying a common library.

Ask each tool to identify downstream consumers before implementation. Check whether it finds the relevant repositories, explains why they are connected, and retrieves useful history rather than just returning matching file names.

Then see what happens after the change is written. Does the review identify a compatibility issue? Does it point to the affected code in another repository? Can the coding agent use that finding to fix the problem? And can your team understand why the tool raised the issue?

I'd also test setup and access requirements. Some tools need related repositories configured explicitly, while others offer automatic repository discovery. Your organization's hosting setup, security requirements, and preferred coding agents may narrow the choices further.

The most useful tool is not necessarily the one that returns the most context. It is the one that consistently returns the context that changes the engineering decision.

Final thoughts

Cross-repo context is becoming an important part of AI-assisted development because real software changes rarely stop at repository boundaries. A change to a shared library can affect multiple services, and a passing test suite in one repository doesn't prove that all its consumers will continue to work.

Augment, Greptile, and CodeRabbit each address parts of this problem through codebase context or cross-repository review. Qodo's approach is particularly interesting if you want to bring that understanding into the coding session itself and connect it with independent review, organizational standards, and the wider system view in Qodo 3.0.

For me, the most important distinction is this: Does the tool help the agent understand the impact of a change before it writes the code, or does it mainly help reviewers discover the impact afterward?

A mature workflow needs both. Give the agent relevant system context before implementation, review the actual changes independently, and keep humans responsible for decisions that require engineering judgment.

That's how cross-repo context becomes more than a search feature. It becomes part of how your team builds and reviews software.

👨‍💻 TL;DR

If you're looking for cross-repo context, start by deciding where you need it most.

Qodo: Connects cross-repo understanding with coding-agent workflows, independent review, organizational rules, and Qodo 3.0's Software Map and PR Triage.
Augment: Focuses on supplying coding agents with relevant context across large codebases and repositories.
Greptile: Brings related repositories into AI pull request review.
CodeRabbit: Uses linked and automatically discovered repositories to investigate downstream impact during review.

If you want your coding agent to understand the wider system before it starts changing code, Qodo's Agentic Toolbox is a strong option to evaluate first. If your main goal is to strengthen pull request review across related repositories, compare Greptile and CodeRabbit closely as well.

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

Your AI Agent Changed One Repo. Did It Check What Breaks Outside It?

Kiran Naragund — Mon, 28 Sep 2026 09:30:00 +0000

Hello Devs 👋

One thing I have noticed with AI coding agents is that they are very good at working inside the repository you give them.

You ask the agent to change an API, update a database model, add a field, modify a service, or change some business logic. It searches the code, finds the relevant files, makes the changes, runs some tests, and gives you a result.

For a small application, that might be enough. But real systems are rarely that isolated.

A change in one repository can affect another service, a shared API contract, a frontend application, an SDK, a background worker, or some internal tool that lives somewhere else. The code you are looking at might only be one part of the actual change.

This is where I think AI coding agents still have an interesting problem to solve.

Understanding the repository is not always the same as understanding the system.

The repository in front of the agent is only part of the picture

Imagine you have three repositories.

payments-service
customer-api
checkout-web

The checkout application calls customer-api, and customer-api communicates with payments-service.

Now someone asks an AI coding agent:

Update the payment response to include the transaction status.

The agent opens payments-service.
It finds the response model.
It adds the field.
The tests pass.

At first glance, everything looks fine.

But what if another repository depends on the exact shape of that response?

Maybe customer-api transforms the response before sending it to the frontend.
Maybe checkout-web has its own TypeScript interface.
Maybe an internal reporting service expects a particular field to have a specific value.

The change might still be perfectly valid inside payments-service.

The problem is that the agent may not know what happens outside that repository.

This is one of those things that is easy for a developer who has worked on the system for a few years. You remember that the payment service is connected to another service. You remember an old migration that changed the API contract. You might even remember the pull request where the current behavior was introduced.

An AI agent does not automatically have that memory.

Searching the code is not the same as understanding dependencies

This is why I don't think simply giving an agent a better search tool completely solves the problem.

The agent can search for:

TransactionStatus

It can find references in the current repository.
It can search for API routes.
It can inspect imports.
It can look through tests.

All of that is useful.

But there is a difference between asking:

Where is this function used?

and asking:

What systems depend on the behavior I'm about to change?

The second question requires more context.

Sometimes that context is spread across repositories. Sometimes it is in pull request history. Sometimes it is in specifications or documentation. Sometimes the reason behind a strange piece of code is buried in an old engineering decision.

That history matters more than we sometimes realize.

The weird code might have a reason

I've seen this happen many times in normal development.

You open a piece of code and think:

Why are we doing this?
This looks unnecessary.

Then someone points you to an old pull request.

And suddenly the code makes sense.

Maybe the service used to return a different value.
Maybe another system had a compatibility problem.
Maybe a customer integration depended on the current behavior.
Maybe someone intentionally avoided a seemingly cleaner implementation because it caused a production issue.

Without that history, an AI coding agent can make a change that looks better locally but removes an important compatibility decision.

This is one reason codebase context should include more than the current files.

The history of the code can be part of the context too.

This becomes more important with AI-generated changes

Before AI coding agents became common, a developer usually had to spend some time understanding the change before making it.

That did not make developers perfect. We still missed dependencies and introduced bugs.

But there was a natural amount of friction in the process.

You had to find the repository.
You had to understand the service.
You had to search for usages.
You had to talk to another developer.
You might look through old pull requests.

Now an AI agent can make a surprisingly large change in a short amount of time.

That is useful.

But it also means the cost of skipping context can become easier to overlook.

If an agent can modify 20 files in a few minutes, we need better ways to answer a simple question:

What else could this change affect?

This is where cross-repository context becomes useful

Qodo has been working on this problem through its Context Engine.

The idea is not just to search the repository where the agent is currently working. Qodo's tooling can use repository relationships, pull request history, specifications, and live Git state to help understand how a change fits into the wider system. Its Agentic Toolbox brings that capability directly into coding-agent workflows.

For example, imagine the developer asks:

Change the customer ID format in the payments service.

Instead of immediately editing the model, a context-aware workflow could first investigate questions such as:

Which repositories consume this value?

Where is the API contract defined?

Are there related pull requests?

Does another service transform this ID?

Are there tests in another repository?

Has this field caused compatibility issues before?

Those questions are much closer to how an experienced engineer would approach the change.

The important part is that the developer doesn't have to manually discover every connection first.

A practical example

Let's say your company has this setup:

checkout-web
      ↓
order-api
      ↓
payment-service
      ↓
payment-provider

You ask your coding agent to change the payment timeout from 10 seconds to 30 seconds.

Inside payment-service, the change is tiny.

10 seconds → 30 seconds

The tests pass. But there might be a timeout in order-api that is still set to 15 seconds.

So the payment service can wait for 30 seconds, but the API sitting in front of it will give up after 15.

The code change is correct inside one repository. The system behavior is still wrong.

This is the kind of problem that is difficult to catch if your review only looks at the changed repository.

A cross-repository view can surface the mismatch before the change reaches production.

AI agents need context before they start coding

There is another part of this that I find important.

We often think about AI review as something that happens after the code is written.

The agent generates the code. Then another tool reviews it.That is useful, but there is also value in giving the agent better context before implementation starts.

Suppose the agent discovers:

The timeout in payment-service is 30 seconds,
but order-api currently has a 15 second timeout.

The existing timeout was introduced in PR #482
because requests longer than 15 seconds were considered failed
by the checkout workflow.

That changes the implementation conversation.

The agent might now ask whether the upstream timeout should also change instead of blindly modifying one number.

That is a much better use of AI than simply asking it to generate code faster.

The agent is helping you understand the system before changing it.

This is also where independent review helps

Even with good context, I wouldn't assume the coding agent will always make the right decision.

The same agent that writes the code is still working toward the requested task.

Having an independent review step gives you another perspective.

Qodo's Agentic Toolbox includes a qodo-review skill that can review committed and uncommitted local changes before a pull request is opened. The review can be run inside the coding-agent workflow rather than waiting until the PR already exists.

So the workflow can become something like:

Developer describes the change
        ↓
Agent investigates the wider system
        ↓
Agent checks related history and dependencies
        ↓
Agent implements the change
        ↓
Tests run
        ↓
Independent review
        ↓
Agent investigates findings
        ↓
Developer reviews the remaining decisions
        ↓
Pull request

I like this workflow because it doesn't try to remove the developer from the process.

The agent handles more of the investigation and implementation work, while the developer still makes the decisions that require actual system knowledge.

The biggest change is not faster coding

It is tempting to measure AI coding agents by how quickly they produce code.

How many files can they modify?

How quickly can they finish a task?

How many tests can they generate?

Those are useful measurements, but they don't tell the whole story.

If the agent changes one repository in five minutes but misses an important dependency in another repository, the speed doesn't really help.

The more useful question is:

Can the agent understand enough of the system to make a safe change?

That changes how I think about AI coding tools.

The goal isn't simply to give an agent access to more code.

The goal is to give it the right context for the change it is making.

You don't need every repository connected to everything

There is also a practical limit here.

I don't think the answer is to dump your entire company's source code into every AI coding session.

That would create its own problems.

Most tasks only need a relevant slice of the system.

If you're changing the payment API, you probably need the services that consume that API, the relevant specifications, related tests, and some history around the behavior.

You probably don't need every unrelated repository in the organization.

That is why dependency mapping and contextual retrieval are interesting. The useful question is not:

Give the agent all our code.

It is:

Show the agent the parts of the system that matter for this change.

That is a much more practical approach.

What I would check before trusting an AI agent with cross-repo changes

If your team is starting to use AI agents for larger changes, I would test this with a few real tasks rather than judging the tool from a simple CRUD example.

Give the agent a change that crosses a service boundary.

Ask it to identify affected repositories before writing code.

See whether it finds the relevant API consumers.

Check whether it can find previous decisions from pull request history.

Then intentionally give it a task where changing one repository without changing another would create a problem.

That will tell you much more about the quality of its context than a simple code-generation benchmark.

I would also check whether the tool clearly explains why it thinks another repository is affected. Developers need to be able to verify the reasoning instead of simply trusting a list of files produced by an agent.

Final Thoughts

AI coding agents are getting very good at working inside a repository.

The next problem is understanding what that repository is connected to.

A small change can cross service boundaries, API contracts, shared libraries, databases, and old compatibility decisions. Those relationships are often not obvious from the files that the developer has open.

That's why I think context is becoming just as important as code generation.

Qodo's current Agentic Toolbox is an example of this direction. It brings cross-repository context, pull request history, specifications, organizational rules, and independent review into the coding-agent workflow.

For me, the interesting question is no longer only:

"Can the AI write this code?"

It is:

"Does the AI understand enough of the system to know what this change might break?"

That is a much harder problem, and probably a more important one as coding agents start handling larger engineering tasks.

👨‍💻 TL;DR

AI coding agents can understand the repository they're working in, but real applications often span multiple repositories and services.

A safe agentic workflow needs more than file search. It needs relevant dependencies, API relationships, previous decisions, specifications, and the ability to review the actual change before it reaches a pull request.

The direction is moving from:

"AI writes code."

to:

"AI understands the system, writes the change, checks the impact, and gets another review before we merge it."

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

Can Claude Code and Cursor actually enforce your org rules and coding standards?

Kiran Naragund — Sun, 27 Sep 2026 13:44:59 +0000

Hello Devs 👋

One of the first things many teams do after adopting an AI coding agent is create a rules file.

If you're using Claude Code, you might have a CLAUDE.md file. If you're using Cursor, you might have .cursor/rules. You put things in there like naming conventions, architecture guidelines, security requirements, testing expectations, and things the agent should avoid.

That sounds like a good way to keep AI-generated code consistent with the way your team works.

But after using these tools for a while, there is a question that becomes more important:

Are these rules actually being enforced, or are we simply giving the AI another set of instructions to read?

That difference matters a lot when you have multiple developers, multiple repositories, and multiple AI coding tools being used across the same organization.

Rules files are useful, but they are still instructions

Claude Code and Cursor both give developers ways to provide persistent instructions to the coding agent.

Claude Code uses CLAUDE.md for things like project conventions, architecture notes, coding standards, and common workflows. Cursor has Project Rules under .cursor/rules, where teams can keep rules that are applied to the agent based on the configured scope and conditions.

For a small project, this can work really well.

Imagine your team has a rule like this:

- All API calls must have an explicit timeout.

- Never log access tokens, passwords, or personal customer data.

- Database mutations must be idempotent.

- Run the relevant tests before opening a pull request.

You give these rules to Claude Code or Cursor, and the agent can use them while working on the code.

The problem starts when you ask a slightly different question: what happens when the agent doesn't follow one of them?

The rules file itself doesn't necessarily stop the code from being written. It doesn't behave like a compiler error or a CI check. The model can misunderstand a rule, forget part of it, or simply produce code that violates it.

That doesn't make CLAUDE.md or Cursor Rules useless. They are actually very useful for giving the agent the context it needs. But there is a difference between guiding an agent and proving that the resulting code follows the standard.

That distinction becomes much more important as a team grows.

The problem gets bigger across repositories

Let's say your organization has 40 repositories.

The payment service has one set of rules. The frontend has another. The internal platform has another. Some rules are shared, while others only apply to certain services.

Now imagine your security team introduces a new requirement:

Do not write sensitive customer information to application logs.

Someone has to make sure that requirement reaches the repositories where it matters.

Maybe you update CLAUDE.md.

Maybe someone updates Cursor Rules.

Maybe another team has a different instruction file.

And six months later, you have slightly different versions of the same rule spread across different repositories.

This is one of the problems with treating Markdown instruction files as the complete governance system. They are great for giving an agent local context, but they don't automatically give an organization a central place to define, manage, update, and check its standards.

This is also where different AI coding agents can make the problem more complicated. Your developers might use Claude Code, Cursor, Codex, or another agent depending on the project and their personal workflow.

You don't really want your engineering standard to depend on which AI tool happened to write the code.

So what does "enforcement" actually mean?

I think this is where the terminology gets confusing.

There are several different levels of enforcement.

At the first level, you have instructions. You tell the coding agent what your organization expects through files such as CLAUDE.md or .cursor/rules.

At the next level, you can have automated checks. Linters, tests, SAST tools, type checkers, and other CI checks can catch specific classes of violations.

Then you have review and policy checks, where a system examines the actual change and checks it against broader engineering standards.

Finally, you can have hard merge gates, where a pull request cannot merge until required checks pass.

These things are related, but they aren't interchangeable.

A rule inside a Markdown file doesn't automatically become a hard policy gate.

That's an important point when talking about AI coding agents because it's easy to say that an agent "enforces" a rule when what it really does is receive that rule as context.

Where Claude Code and Cursor fit

I wouldn't look at Claude Code or Cursor rules as a replacement for your engineering governance system.

Their main job is to make the coding agent understand how you want it to work.

For example, if your project prefers a particular service structure, error-handling pattern, testing approach, or naming convention, putting that information where the agent can consistently access it is useful.

Instead of repeatedly telling the agent:

Don't create a new database abstraction.
Use the existing repository pattern.
Add tests for the service layer.
Never log request headers.

you can put those expectations into the project's rules.

That saves a lot of repetition and gives the agent more context before it starts making changes.

Cursor's current rules system also supports different ways of applying rules, including rules that are always applied, automatically attached based on context, requested by the agent, or manually invoked. Claude Code similarly loads project-level CLAUDE.md instructions into its working context.

So yes, these tools can make an agent much more consistent.

But consistency is not the same thing as independent verification.

What happens when the agent writes the wrong code?

Consider a fairly normal task.

You ask the agent:

Add retry handling to the payment API.

Retry transient failures up to three times with exponential backoff.
Do not retry permanent failures.

Your organization has a few additional standards:

Payment operations must be idempotent.

External requests require explicit timeouts.

Sensitive payment information must not appear in logs.

Claude Code or Cursor can receive those rules and use them while implementing the change.

The agent might even write a very good implementation.

But what if it accidentally forgets the idempotency requirement?

Or it adds retries around an operation that isn't safe to repeat?

Or it logs the response body while debugging an error?

The agent may not catch its own mistake.

This is one reason I think it's useful to separate the coding agent from the reviewer.

The coding agent is responsible for getting the task done. Another system can then look at the resulting change and ask whether it actually follows the standards.

That gives you a workflow closer to:

Developer request
       ↓
Coding agent
       ↓
Code + tests
       ↓
Independent review
       ↓
Fix findings
       ↓
Pull request
       ↓
Human review / CI

rather than expecting the same generation step to be both the writer and the final judge.

This is where Qodo's Agentic Toolbox becomes interesting

Qodo launched its Agentic Toolbox recently, and one of the pieces that caught my attention is the way it connects organizational rules with coding agents.

Instead of keeping your standards only inside the configuration of a particular coding tool, Qodo can provide applicable organizational rules to the agent through its get-qodo-rules skill. It also has qodo-manage-standards for managing rules, while qodo-review can independently review local committed or uncommitted changes before a pull request is opened.

That gives you two different parts of the workflow.

First, the agent gets the standards before it starts implementing the change.

Then, after the code has been written, Qodo can review the actual changes against those standards.

For example, the workflow could look something like this:

Developer:
"Add retry handling to the payment service."

        ↓

Agent gets applicable organization rules

        ↓

Agent checks the existing codebase
and implements the change

        ↓

Tests run

        ↓

Qodo reviews the local changes

        ↓

Findings are returned to the coding session

        ↓

Agent fixes safe issues

        ↓

Developer reviews the remaining decisions

That is a different approach from simply adding more instructions to CLAUDE.md.

The goal isn't to replace CLAUDE.md or Cursor Rules. Those files are still useful. The idea is to have organizational standards that can be shared with the agent and then checked independently against the code that was produced.

Qodo's current rules system is designed around that broader lifecycle, including managing rules, their scope, severity, and activation rather than treating them as plain text sitting in a repository.

But this still doesn't mean every rule becomes a hard gate

This is an important distinction.

If your organization has a rule saying:

All production database migrations require approval
from the database team.

an AI review tool can identify a migration and flag the requirement.

But that doesn't necessarily mean the AI tool itself should be the final authority that blocks the merge.

For some requirements, you want CI or repository permissions to be the final gate.

For example:

No secrets in source code
        ↓
Secret scanner
        ↓
CI failure
        ↓
Merge blocked

For other requirements, automated review is more appropriate:

Avoid unnecessary database calls
        ↓
AI code review
        ↓
Finding + explanation
        ↓
Developer decides how to fix it

And some things are still better handled by a human:

Should this architectural change
be made at all?

An AI agent can provide useful context, but that doesn't mean it should make the organizational decision.

So when I say "enforce coding standards," I would be careful about what that means. For me, a good engineering setup combines agent instructions, automated checks, AI review, CI gates, and human review rather than expecting one Markdown file or one AI tool to handle everything.

How I would test this in a real team

If you're already using Claude Code or Cursor, you don't need to immediately replace anything.

I'd start with a small experiment.

Pick five rules that actually matter to your team. Don't choose 50 rules just because you can. Pick things where violations have caused real problems before.

For example:

1. Every external HTTP request needs a timeout.
2. Payment mutations must be idempotent.
3. Never log authentication tokens.
4. New service methods require unit tests.
5. Do not introduce a new dependency without approval.

Put those rules into your existing agent configuration.

Then give the agent a few tasks where those rules matter.

Don't just check whether the generated code looks good. Intentionally create scenarios where it could violate one of the rules.

Then ask:

Did the agent see the rule?
Did it understand the rule correctly?
Did it actually follow the rule?
Could another developer use a different coding agent and get the same standards?
Can you detect a violation after the code is generated?
Can you tell which rule was violated and why?
Can CI or another policy check block serious violations?

Those answers tell you much more about your organization's AI governance than simply having a CLAUDE.md or .cursor/rules directory.

The real goal is not more rules

I think teams can easily fall into the trap of creating huge rule files.

Every time an AI agent makes a mistake, someone adds another sentence to CLAUDE.md.

After a few months, you end up with hundreds of lines explaining every mistake an agent has ever made.

That doesn't necessarily make the system better.

The better question is whether the standards are clear, relevant, discoverable, and actually checked when they matter.

Your coding agent should know the rules before it writes code.

Your review system should be able to check the resulting change.

And your CI or repository controls should handle the things that genuinely need a hard gate.

That combination is much more useful than simply giving an AI agent a very long instruction file and hoping it remembers everything.

Final Thoughts

So, can Claude Code and Cursor enforce your organization's coding standards?

They can apply and follow rules very effectively as part of the coding workflow, but their rule files should not be confused with a complete organizational enforcement system.

CLAUDE.md and Cursor Rules are useful because they put your team's knowledge directly in front of the coding agent. The next step is making those standards consistent across repositories and coding tools, and then independently checking the code that comes out of the process.

That's the part I find more interesting about Qodo's current Agentic Toolbox. It connects organizational standards with the coding agent before implementation and adds an independent review step after the code is written.

For teams adopting AI coding agents seriously, I think that's the direction worth looking at: don't just teach the agent your rules. Build a workflow where those rules can also be checked.

👨‍💻 TL;DR

Claude Code and Cursor both give you good ways to provide coding standards to AI agents through files such as CLAUDE.md and .cursor/rules.

That's useful, but an instruction is not automatically a hard enforcement mechanism.

A more complete setup looks like this:

Rules → Agent → Code → Independent Review → CI/Policy Gates → Human Review

Qodo's Agentic Toolbox fits into that workflow by bringing organizational rules into the coding session and allowing Qodo to independently review local changes before the pull request.

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

Shift Left Code Review: How Qodo Turns Your Coding Agent Into Its Own First Reviewer

Kiran Naragund — Mon, 14 Sep 2026 05:32:40 +0000

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.

What Does “Shift Left” Mean Here?

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?"

The Problem With Letting the Same Agent Review Its Own Code

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:

What could break?
What requirement was missed?
Is there a security problem?
Does this follow the team's rules?
Are there edge cases?
Did this change affect something outside the files being edited?

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.

What the New Qodo Workflow Looks Like

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 loading 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.

Let's Take a Simple Example

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.

Rules Should Come Before the Code

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.

Then Comes the Interesting Part: Review the Local Changes

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.

Why Independent Review Matters

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?"

or:

"What happens when this value is null?"

or:

"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.

What Happens When the Review Finds Something?

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.

This Doesn't Mean Humans Stop Reviewing PRs

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:

Should we change the architecture?
Is this behavior acceptable for customers?
Should this migration happen now?
Is this security tradeoff okay?
Does this design fit the product?
Is this technical debt worth taking on?

Those are different from:

"You forgot to add the required timeout."

or:

"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.

What About Cursor and Claude Code?

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

or:

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.

Where This Gets Really Useful

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?"

The Real Shift Is Bigger Than Code Review

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.

How I'd Try This in a Real Project

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."

Then:

"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.

Does the agent find useful issues?
Does it understand the repository?
Does it follow the team's rules?
Does it avoid wasting time fixing low-value comments?
Does it know when to stop and ask the developer?

Those answers will tell you much more than a feature list.

A Small Change in Where We Think About Review

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.

📚 Want to Read More?

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.

Final Thoughts

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!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

Self-Hosted and On-Prem AI Code Review: What Actually Works for Enterprise Teams?

Kiran Naragund — Sun, 13 Sep 2026 11:24:49 +0000

Hello Devs 👋

AI code review is getting pretty normal these days. You open a PR, an AI reviewer looks at the changes, and a few seconds later you have comments about bugs, security issues, missing tests, or things that could break.

But this gets more complicated when you work in an enterprise environment.

Your code may be sitting in a private GitHub Enterprise, GitLab, or Bitbucket setup. Your security team may not allow source code to leave your network. You may have strict data residency rules, internal model requirements, or even an air-gapped environment.

So the question isn't just:

"Which AI code review tool is the best?"

It becomes:

"Which one can actually work inside our environment without making the setup painful?"

I started looking at this from that angle, especially with Qodo, Greptile, and CodeRabbit.

There is also a good reason to look at this now.

On September 9, Qodo launched its Agentic Toolbox, which brings codebase context, organizational rules, and Qodo's review capabilities directly into coding agents such as Claude Code, Codex, Kiro, and other agent-based tools.

That caught my attention because AI code review is slowly moving beyond the PR.

The coding agent is now writing a lot of the code. So why should we wait until the PR is created before checking it?

Let's get into it.

First, What Does Self-Hosted Actually Mean?

This sounds like a simple question, but it isn't.

When a vendor says "self-hosted," I don't think we should immediately assume that everything runs inside our network.

There are a few different things to check.

Where does the review service run?
Where is the code indexed?
Where are prompts and findings stored?
Where does the AI model run?
Does the system need access to an external model API?
Does it need outbound internet access?
Can it work in an air-gapped environment?
Who manages upgrades?

These questions matter a lot more than the "self-hosted" label on the website.

For example, Qodo's current on-prem architecture runs its services inside the customer's infrastructure using Kubernetes. It also has a Context Engine that can provide deeper codebase information.

Greptile has a self-hosted setup based around Docker and also documents support for air-gapped environments and custom LLM configurations.

CodeRabbit also offers self-hosting for enterprise customers.

So yes, all three can fit into the enterprise self-hosted conversation.

But the interesting part starts after that.

Qodo vs Greptile vs CodeRabbit

I don't want to turn this into one of those comparison tables where every tool gets a green checkmark.

In my experience, enterprise teams usually have a few very different problems.

Team might mainly care about keeping source code inside its network.
Another might care more about understanding dependencies across hundreds of repositories.
Another might already have a strong PR workflow and simply want an AI reviewer that can fit into it.

So let's look at these tools from that point of view.

Qodo

Qodo's enterprise story goes beyond just running an AI reviewer inside your infrastructure.

Its on-prem deployment supports running Qodo components inside the customer's environment, with GitHub, GitLab, and Bitbucket integrations. Qodo also supports different model setups, including external model providers and self-hosted models.

The part I find more interesting is the context.

In a large company, a PR is rarely just about the files changed in that PR.

Let's say I change a shared API. The actual flow might look something like this:

Service A
   ↓
Shared API
   ↓
Service B
   ↓
Service C
   ↓
Database

My PR might only change Service A. But Service B and Service C might depend on the same API. This is where repository context becomes useful.

Qodo's Context Engine is designed to work with things like repository relationships, dependencies, PR history, specs, and live Git state. The goal is to give the reviewer more information than just the current diff.

Another thing worth mentioning is rules.

Most teams already have rules for how code should be written. Some are in documentation. Some are in repository files. Some are just things senior developers know after working on the project for a few years.

Keeping those rules in one place and making them available to both developers and AI tools is becoming more important.

And this is where the new Agentic Toolbox launch makes Qodo more interesting.

With the toolbox, coding agents can ask Qodo for codebase information, retrieve team rules, review their own local changes, and work through findings before creating a PR.

So instead of:

Agent writes code
      ↓
Agent opens PR
      ↓
AI reviews PR
      ↓
Developer fixes issues

You can get closer to:

Agent understands codebase
      ↓
Agent gets team rules
      ↓
Agent writes code
      ↓
Qodo reviews the changes
      ↓
Agent fixes findings
      ↓
PR is opened

For teams using coding agents heavily, that is a pretty useful shift.

Greptile

Greptile is another interesting option if your main requirement is an AI reviewer that understands the wider codebase and can run in your own environment.

Greptile offers self-hosted deployment and documents support for air-gapped environments. It also supports custom LLM configurations, which can be useful when your company already has an approved model setup.

One thing Greptile focuses on is building a knowledge graph of the codebase.

The idea is that the reviewer should understand relationships between files, functions, classes, and other parts of the repository instead of looking at every PR as a completely separate piece of code.

It can also use existing instruction files such as CLAUDE.md, AGENTS.md, and Cursor rules.

I like this approach because most development teams already have some of these files.

If your repository has something like:

AGENTS.md
CLAUDE.md
.cursor/
docs/
.github/

those files already contain useful information about how developers are expected to work.

So during an evaluation, I would definitely test how well the tool uses that existing context.

Greptile makes a lot of sense if your main use case is:

"We want an AI code reviewer that understands our codebase and can run in our environment."

That's a pretty reasonable requirement.

CodeRabbit

CodeRabbit is probably the most familiar model for teams that think about AI code review mainly in terms of pull requests.

The workflow is easy to understand:

Developer creates PR
       ↓
CodeRabbit reviews it
       ↓
Comments and findings appear
       ↓
Developer fixes them

For a lot of teams, that's exactly what they need.

CodeRabbit also has an Enterprise offering with self-hosting, RBAC, SSO, audit logging, API access, and other enterprise features.

The self-hosted option is useful for companies that don't want their source code and review data going through a shared SaaS environment.

So if your team already has a PR-based development process and doesn't want to change much, CodeRabbit is definitely worth evaluating.

But there is another question I would ask today:

What happens before the PR?

That's becoming more important because coding agents are now creating a lot more code.

If Claude Code, Cursor, Codex, or another agent writes the implementation, waiting until the PR is opened to start reviewing it may be a little late.

The Part Most Enterprise Teams Miss

When I hear "we need self-hosted AI code review," I would not start by asking which product has the best AI.

I'd start with the infrastructure team.

Ask them what actually needs to stay inside the network.

For example:

Source code
Repository index
PR data
Review findings
Logs
Embeddings
LLM requests
Model inference

These don't necessarily live in the same place.

You might have the review application running inside your VPC while still sending model requests to an external provider.

That may be perfectly fine for one company.

It may be completely unacceptable for another.

Qodo's documentation, for example, describes support for external providers such as OpenAI, Anthropic, Vertex AI, and AWS Bedrock, as well as self-hosted LLM options.

Greptile also documents custom LLM configuration for self-hosted deployments.

This is why I would always ask:

Where does the code live?

and separately:

Where does the model see the code?

Those are two different questions.

Self-Hosted Also Means More Work

There is another thing worth remembering.

Self-hosting gives you more control, but it also gives you more responsibility.

If you deploy one of these systems yourself, someone has to manage the infrastructure.

That can include:

Kubernetes or containers
Networking
Secrets
Certificates
Storage
Git authentication
Model access
Monitoring
Upgrades
Backups

For example, Qodo's on-prem documentation has Kubernetes and infrastructure requirements that a platform team needs to plan for.

That's not necessarily a problem.

If you're a large organization, you may already have all of this infrastructure.

But if your team is expecting:

"Let's self-host this and forget about it."

That's probably not how it will work.

I would actually include the deployment effort as part of the POC.

Don't just ask the vendor to show you a demo.

Have your own platform team install it.

That's when you'll find the real problems.

Test Codebase Context, Not Just Bug Finding

Another mistake I've seen with AI code review evaluations is testing with very simple PRs.

For example:

def add(a, b):
    return a + b

Then someone changes it to:

def add(a, b, c):
    return a + b + c

and asks three tools which one finds the problem.

That's not a very useful enterprise test.

Instead, give the tools something that looks like a real change in your organization.

For example, change a shared API contract.

Then check:

Does it find the callers?
Does it understand the dependency?
Does it notice compatibility issues?
Does it use the repository's rules?
Does it understand previous changes?
Does it explain why the change could be risky?

This tells you much more about the tool.

Qodo and Greptile both put significant emphasis on broader repository context, although they approach it differently.

What About Coding Agents?

This is probably the biggest reason I wanted to write this article now.

The way we write software is changing.

A few years ago, the normal flow was:

Developer
   ↓
Writes code
   ↓
Opens PR
   ↓
AI reviews PR
   ↓
Human reviews PR

Now we increasingly have:

Developer
   ↓
Gives task to coding agent
   ↓
Agent explores code
   ↓
Agent writes code
   ↓
Agent runs tests
   ↓
Agent opens PR
   ↓
AI reviews PR
   ↓
Human reviews PR

The agent is doing more of the actual implementation.

So I think code review also needs to move earlier.

This is the idea behind Qodo's Agentic Toolbox.

The toolbox gives coding agents access to Qodo's codebase context, rules, review capabilities, and finding resolution. The agent can review committed or uncommitted changes before the PR exists and fix issues during the same session.

For example, instead of telling your agent:

"Implement this feature."

you can have a workflow closer to:

"Understand the service, check our rules, implement the change, review your local changes, and fix any issues you find."

That's a very different workflow from simply adding an AI bot to the PR.

And I think this is where enterprise code review is heading.

So Which One Would I Pick?

Honestly, it depends on what problem you're trying to solve.

If the main requirement is self-hosted AI code review, all three are worth putting through a real POC.

If you want a strong codebase-aware review experience with enterprise deployment, Greptile is worth looking at.

If you already have a strong PR-focused workflow and want to add AI review without changing the process too much, CodeRabbit makes sense to evaluate.

If you're looking at the bigger picture, where code review, repository context, engineering rules, governance, and coding agents all need to work together, I'd put Qodo high on the list.

The Agentic Toolbox makes that last part especially interesting because Qodo is not only thinking about the PR anymore. Its tools can be used directly by coding agents while they are working on the code.

What I'd Check During a POC

If I were evaluating these tools for an enterprise team, I'd keep the test pretty simple.

Take one real repository.

Then take one change that touches a shared component.

Run the same change through each tool.

I'd look at five things:

1. Deployment

How hard was it to get running inside our environment?

2. Data flow

What leaves the network, and when?

3. Context

Does the reviewer understand the code around the PR?

4. Rules

Can it follow our actual engineering standards?

5. Developer workflow

Does it give useful feedback at the right time, or does it just add more comments to the PR?

And if your developers are already using coding agents, I'd add one more test:

Can the agent use the review system before opening the PR?

That's becoming a pretty important question.

Final Thoughts

Self-hosted AI code review isn't just about putting an AI reviewer behind your firewall.

There are a lot more pieces involved.

You need to think about where your source code goes, where the repository index lives, which model is being used, how the system connects to your Git provider, who operates it, and how much context the reviewer actually has.

Qodo, Greptile, and CodeRabbit are all interesting options, but they solve the problem from slightly different angles.

For me, the bigger change is what is happening around coding agents.

When an agent can write hundreds of lines of code in a session, waiting for a PR reviewer to find basic problems isn't always the best workflow.

I'd rather have the agent understand the codebase, read the team's rules, write the code, review its own changes, fix obvious findings, and then open the PR.

Humans still get the final say.

But hopefully, by the time the PR reaches us, we're reviewing the things that actually need human judgment instead of spending our time finding problems an agent could have caught five minutes earlier.

That's where I think enterprise AI code review is heading.

And the September 9 launch of Qodo's Agentic Toolbox is a good example of that shift, from AI reviewing code after it's written to AI quality checks becoming part of the coding workflow itself.

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

Best AI Code Review Tools for GitHub in 2026

Kiran Naragund — Sun, 02 Aug 2026 09:42:38 +0000

Hello Devs 👋

AI coding assistants have dramatically accelerated code generation.

Whether you're using Cursor, GitHub Copilot, Claude Code, or Windsurf, writing code is faster than ever. The challenge is that code review hasn't improved at the same pace.

Teams are shipping larger pull requests, reviewing more AI-generated code, and spending increasing amounts of time validating whether changes are actually correct, maintainable, and aligned with existing architecture.

That's exactly why AI code review tools have become a key part of modern GitHub workflows.

The problem is that not all AI review tools solve the same problem.

Some generate pull request summaries.
Some focus on security and compliance.
Some extend traditional static analysis.

Others attempt to understand repository-wide context and review changes the way an experienced teammate would.

If you're evaluating AI code review tools for GitHub, here's a practical comparison of the most widely discussed options in 2026.

⚡ Quick Verdict

Qodo stands out for teams that need automated pull request reviews with repository-wide context, not just diff analysis.

The GitHub integration is straightforward, reviews run automatically on pull requests, and the platform focuses on understanding dependencies, related files, and existing code patterns across the repository.

For small projects, lightweight review tools may be sufficient.

For larger codebases, AI-generated code, and complex pull requests, context-aware review becomes significantly more valuable.

What Makes a Good GitHub AI Review Tool?

Before comparing tools, it's worth defining what actually matters.

For most engineering teams, four factors determine whether an AI review tool provides real value.

1. Integration

Reviews should appear where developers already work, directly inside GitHub pull requests.

Nobody wants another dashboard, notification stream, or workflow to manage.

2. Review Quality

Useful reviews surface meaningful issues, not just more comments.

The goal isn't volume. It's identifying problems developers would otherwise miss.

3. Context Awareness

The best reviewers understand how changes affect the rest of the codebase.

Looking only at modified lines is often insufficient for complex systems.

4. Setup and Maintenance

Developers adopt tools faster when setup takes minutes, not weeks.

The best solutions require minimal configuration and ongoing maintenance.

1. Qodo

Qodo automates code reviews inside GitHub while analyzing changes in repository context.

What I Liked

Qodo's biggest strength is understanding code beyond the pull request diff.

Instead of evaluating only modified files, it attempts to understand:

Related files
Dependencies
Existing implementation patterns
Historical review context

This becomes particularly useful when a pull request spans multiple services, modules, or shared components.

Many bugs are not introduced within the changed file itself. They're caused by missing updates elsewhere in the system.

Context-aware analysis helps identify those issues before they reach production.

GitHub Integration

Getting started is simple:

Install the GitHub app
Grant repository access
Select repositories

After setup, reviews run automatically whenever pull requests are opened or updated.

Best For

Medium and large engineering teams
Teams reviewing AI-generated code
Multi-service architectures
Complex repositories
Teams prioritizing review quality over comment volume

2. CodeRabbit

CodeRabbit is popular for delivering AI-powered pull request feedback with minimal setup.

What I Liked

Quick installation
Helpful pull request summaries
Easy adoption
Good developer experience

For many teams, it's one of the fastest ways to introduce AI reviews into GitHub workflows.

Where It Can Struggle

Most feedback is generated from the pull request diff, with limited repository-wide context.

For smaller applications, this approach often works well.

As systems grow more interconnected, diff-only reviews can miss architectural dependencies, downstream effects, and implementation consistency across services.

Best For

Small engineering teams
Startups
Simpler repositories
Teams looking for lightweight AI review assistance

3. SonarQube

SonarQube focuses on code quality and security analysis rather than AI-driven review workflows.

Although it's frequently mentioned alongside AI review tools, its primary purpose is different.

What It Does Well

Security scanning
Vulnerability detection
Technical debt tracking
Code smells
Test coverage reporting
Quality gates

What It's Not Trying To Do

SonarQube excels at enforcing quality standards, security rules, and maintainability checks.

It is not designed to provide contextual pull request feedback or repository-level reasoning in the same way dedicated AI review platforms do.

Think of it as a powerful quality enforcement platform rather than an AI reviewer.

Best For

Enterprise engineering teams
Security-focused organizations
Compliance requirements
Governance-heavy development environments

4. GitHub Copilot Code Review

GitHub continues expanding Copilot's review capabilities directly within the GitHub platform.

For teams already invested in the GitHub ecosystem, this creates a seamless experience with no additional tooling required.

What I Liked

Native GitHub integration
Familiar developer workflow
No additional platform management
Convenient for existing Copilot users

Current Limitations

Review suggestions are primarily pull request focused and less repository-aware than dedicated review platforms.

For simple reviews, this is often enough.

Teams requiring deeper architectural understanding, broader repository context, or more advanced automation may still benefit from specialized review tools.

Best For

Existing GitHub Copilot customers
Small teams
Lightweight review assistance
GitHub-first development workflows

Which Tool Should You Choose?

The right tool depends on how your team reviews, ships, and maintains code.

Choose Qodo if:

You review large pull requests
Multiple services interact with each other
AI-generated code is becoming common
Repository-wide context matters
You want deeper review feedback

Choose CodeRabbit if:

You want lightweight AI reviews
Your repositories are relatively straightforward
Fast adoption is a priority
Pull request summaries are important

Choose SonarQube if:

Security is a primary concern
Compliance requirements exist
You need quality gates
Static analysis is a core requirement

Choose GitHub Copilot Review if:

You're already using Copilot
You want basic review assistance
Keeping everything inside GitHub is important

📚 Want to Learn More?

If you're evaluating AI code reviews, these resources provide deeper technical guidance and practical examples.

What is AI Code Review

A practical introduction to how AI review systems work and the types of issues they can identify.

Reviewing AI-Generated Code

Useful for teams increasingly relying on Cursor, Copilot, Claude Code, and other AI coding assistants.

AI Code Review Tools Comparison

A deeper comparison of review approaches, workflows, strengths, and tradeoffs.

Final Thoughts

Not all AI code review tools solve the same problem.

Some focus on pull request summaries.
Some focus on security.
Some focus on static analysis.

Others focus on understanding how a change fits into the broader codebase.

For GitHub teams, the best choice depends on the bottlenecks you're trying to eliminate.

If your team is reviewing increasing volumes of AI-generated code, context awareness and review quality often matter far more than the number of comments an AI tool can generate.

The most valuable reviewers aren't the ones that comment the most.

They're the ones that catch issues developers would have otherwise missed.

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

What "Context-Aware Code Review" Actually Means🤔

Kiran Naragund — Sat, 01 Aug 2026 13:27:33 +0000

Hello Devs 👋

If you've looked at AI code review tools recently, you've probably seen the term "context-aware code review" everywhere.

Every tool seems to use it.

Some talk about repository awareness. Others mention codebase understanding. A few claim they understand architecture and engineering best practices.

After spending some time reading docs, testing different tools, and comparing how they review pull requests, I realized something:

Most of us don't really know what "context-aware" means.

The term gets thrown around so often that it's hard to tell whether a tool actually understands your codebase or is simply reviewing the diff and calling it context.

So I wanted to dig into what context actually means in code review and why it matters.

Most Reviews Start With The Diff

Whether the review is done by a human or an AI tool, the starting point is usually the same.

The pull request diff.

Reviewers look at what changed, which files were modified, what code was added or removed, and whether tests were updated.

AI review tools generally work the same way. They receive the diff and generate feedback based on the changes.

For a lot of pull requests, that's completely fine.

If you're fixing a typo, updating a utility function, or cleaning up some code, the diff often contains everything needed to review the change.

The problem starts when the change affects behavior outside the files being modified.

That's where context becomes important.

A Simple Example

Let's say a pull request contains this line:

updatePaymentStatus(paymentId, status);

Looking only at the diff, nothing seems wrong.

The code compiles.
Tests pass.
No obvious issues stand out.

But imagine a few things are true:

The payment service is supposed to publish an event whenever the status changes.
Audit logs are required for compliance reasons.
Similar update flows also update metadata fields.
Another service depends on a specific side effect.

None of that information exists in the diff.

If you're familiar with the system, you might catch the issue immediately.

If you're not, you'll probably need to search the repository, look at similar implementations, and understand how this piece fits into the larger application.

That's context.

So What Does "Context" Actually Mean?

When people talk about context-aware code review, they're usually talking about information that exists outside the pull request itself.

The exact definition varies between tools, but it generally falls into a few categories.

Repository Context

This is probably the most common type.

Instead of looking only at the modified files, a tool also examines surrounding code.

For example, if you're changing a service method, it might inspect:

Related services
Shared utilities
Existing implementations
Similar patterns elsewhere in the repository

A diff-only review doesn't usually do this.

It sees the change.

A context-aware review tries to understand where that change lives.

Historical Context

Sometimes the most important information isn't in the code.

It's in previous decisions.

Every team develops conventions over time. Some patterns become standard because they've worked well. Others exist because someone got burned by a production issue three years ago.

Historical context can include:

Previous pull requests
Review comments
Team conventions
Accepted implementation patterns

Experienced engineers naturally use this information when reviewing code.

A truly context-aware tool should be able to leverage some of it as well.

Dependency Context

Modern systems are connected in ways that aren't always obvious.

A small change in one service can impact shared libraries, downstream systems, APIs, or external integrations.

This becomes even more important in organizations with multiple repositories and distributed architectures.

A pull request can look perfectly fine inside its own repository while still creating problems somewhere else.

That's why dependency awareness matters.

Architectural Context

This is probably the hardest problem to solve.

Most mature systems have architectural rules that aren't explicitly written in every file.

Maybe services aren't supposed to access certain domains directly.

Maybe events are required for specific workflows.

Maybe security checks must happen before certain operations.

A review tool that understands architecture should be able to recognize when a change violates those expectations.

That's much harder than checking syntax or spotting a bug pattern.

How Can You Tell If A Tool Is Actually Context-Aware?

This is the question I started asking whenever I evaluated a new review tool.

Instead of looking at marketing claims, I focused on what the feedback actually looked like.

One thing I noticed is that good review comments usually explain why something matters.

For example:

Consider updating this implementation.

That's technically feedback, but it's not very useful.

Compare that with:

Similar update flows publish an event after status changes. This implementation does not appear to do that, which could lead to inconsistent downstream behavior.

The second comment demonstrates awareness of patterns outside the modified code.

That's a much stronger signal that the tool understands context.

Another thing I look for is whether the tool can connect changes to code that wasn't modified.

Many tools only analyze changed files.

There's nothing wrong with that.

But if a tool claims to understand context, I expect it to reference related parts of the codebase when they're relevant.

I also pay attention to whether the feedback reflects team conventions.

Every engineering team develops its own standards around logging, testing, security, error handling, and observability.

The best review feedback feels specific to the project.

The worst feedback feels like generic advice copied from a programming textbook.

Why This Matters More Than Ever

The way we write code is changing.

Many teams now use tools like Cursor, GitHub Copilot, Claude Code, and other AI coding assistants every day.

That means more code is being generated faster than ever.

As a result, review workload keeps increasing.

Reviewers aren't just checking code quality anymore.

They're increasingly responsible for understanding how generated code fits into existing systems, patterns, and architectural decisions.

That's where context becomes valuable.

Not because AI replaces human reviewers.

Because modern codebases are becoming too large and interconnected to reason about from a single pull request alone.

Where Qodo Fits In

One thing I found interesting about Qodo's approach is its focus on gathering context before generating feedback.

Instead of looking only at changed lines, it attempts to understand related files, repository structure, dependencies, previous review activity, and existing code patterns.

The goal isn't to generate more comments.

The goal is to generate comments that are actually relevant to the change being reviewed.

Whether any tool succeeds at that should ultimately be judged by developers using it in real projects.

But personally, I think this is a much better way to evaluate AI review tools than asking whether they use AI or how many comments they generate.

Checkout Qodo here: https://www.qodo.ai

Final Thoughts

"Context-aware code review" has become one of those terms that everyone uses but rarely defines.

Some tools are mostly diff reviewers.

Others try to understand repository structure, dependencies, historical decisions, and architectural patterns before generating feedback.

Neither approach is automatically better.

The important thing is understanding what kind of context a tool actually uses and where its feedback comes from.

Because in my experience, the biggest production issues are rarely hidden in the syntax.

They're usually hidden in the context surrounding the change.

And that's exactly the part that's easiest to miss when you're only looking at a diff.

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

BrowserAct Hit #1 on Product Hunt, So I Decided to Test It 🧙‍♂️

Kiran Naragund — Sun, 05 Jul 2026 10:14:20 +0000

Hello Devs 👋

Over the last few months, AI agents have been evolving very quickly. We are no longer building simple chatbots that answer questions. Today, agents browse websites, execute workflows, monitor dashboards, interact with SaaS platforms, and perform actions that previously required manual work.

Recently, BrowserAct reached the top position on Product Hunt, which immediately caught my attention. Products often receive attention during launch periods, but reaching the number one spot usually means people see a real problem being solved rather than just another feature release.

That made me curious.

Why are developers and AI builders paying attention to BrowserAct? Is it simply another browser automation tool, or is there something different about it?

Instead of reading documentation and feature lists, I decided to test it myself and understand what problem it is trying to solve.

In this article I will walk through what BrowserAct is, the problem it addresses, how to install it locally, and some hands-on examples using real workflows.

What is BrowserAct?

BrowserAct is a browser automation CLI built specifically for AI agents.

Traditional browser automation tools usually focus on opening pages, clicking buttons, and extracting information from websites. That works well for simple tasks, but AI agents often require more than basic automation. Real websites contain authentication flows, dynamic rendering, browser fingerprint checks, session management, and situations where human intervention becomes necessary.

BrowserAct attempts to solve these challenges by treating the browser as an execution environment for agents rather than as a temporary browser window.

Some of its capabilities include:

Browser session persistence
Browser identity isolation
Human handoff support
Parallel browser sessions
Anti-detection browser environments
Reusable workflows and skills

What Problem Is BrowserAct Trying To Solve?

After building and testing AI agents, I have noticed that many workflows do not fail because of the language model.

The model usually knows what it needs to do.

The problem starts when the workflow enters a browser.

For example, consider an AI agent that monitors competitor pricing. On paper the task sounds straightforward. Open a website, extract information, generate a report, and send the output.

Reality usually looks different.

The website might require authentication. Content may be rendered dynamically. Session state may expire. Security checks can appear unexpectedly. Browser fingerprints may trigger additional verification.

At this point the issue is no longer intelligence.

The issue becomes execution.

BrowserAct seems designed around that exact problem.

Getting Started with BrowserAct

Getting started with BrowserAct is straightforward, and it can fit naturally into both command-line workflows and AI agent environments.

Depending on how you plan to use it, there are two common installation approaches.

1. Install Through an AI Agent (Recommended for Agent Workflows)

If you're using an AI coding agent or an environment that supports skills and tool integrations, BrowserAct can be installed directly as a skill.

npx skills add browser-act/skills --skill browser-act

This allows the agent to invoke BrowserAct capabilities directly inside larger workflows. Instead of writing custom browser automation logic every time, the agent can use BrowserAct whenever browser interaction becomes necessary.

For example, an agent can:

Open websites
Navigate between pages
Handle login flows
Fill forms
Extract structured content
Continue browser-based workflows

This approach is useful when BrowserAct becomes part of a broader AI system rather than a standalone browser tool.

2. Install BrowserAct CLI Directly

If you prefer working directly from the terminal, BrowserAct also provides a CLI installation option.

uv tool install browser-act-cli --python 3.12

After installation, authenticate your local environment:

browser-act auth login

browser-act auth poll

You can also directly configure an API key:

browser-act auth set YOUR_API_KEY

Once authentication is complete, BrowserAct is ready to execute browser workflows locally.

Rather than jumping directly into advanced workflows, I wanted to verify that the installation was working correctly and understand the basic command flow.

The first thing I checked was the browser profiles available on my system.

browser-act browser list-profiles

The output lists available browser profiles that BrowserAct can use during execution. These profiles become useful when creating isolated browser environments, preserving state across sessions, or reusing existing login contexts.

Next, I created a browser using my existing Chrome profile.

browser create \
-- type chrome \
-- source-profile \
local_profile_182885126174998716 \
-- name "browseract" \
-- desc "testing-browseract"

BrowserAct automatically imports available browser state such as cookies and local storage data.

Now that the browser environment was ready, I wanted to test a simple content extraction workflow.

First Test: Extracting Website Content

For the first test, I used BrowserAct's stealth-extract command on a simple website.

browser-act stealth-extract https://example.com --content-type markdown

Output:

# Example Domain

This domain is for use in documentation examples without needing permission.

[Learn more](https://iana.org/domains/example)

The result was returned as clean markdown without writing selectors, parsing HTML, or creating custom scraping logic.

Next, I wanted to see how BrowserAct handled an interactive browser session.

Second Test: Opening a Browser Session

I opened a browser session using the browser profile I created earlier.

browser-act \
--session first-test \
browser open \
chrome_local_102863481715294440 \
https://github.com

The output returned details about the active session:

session_name=first-test
browser_type=chrome
url=https://github.com/
title=GitHub

At this point, the browser was active and ready for interaction.

Inspecting Page State

One of the interesting parts of BrowserAct is that it does not expose raw HTML directly. Instead, it generates a structured view of interactive elements that agents can work with.

browser-act \
--session first-test \
state

--session first-test \
state" width="800" height="423">

This allows interactions to happen using element references rather than manually creating CSS selectors.

To test this further, I clicked search button:

browser-act \
--session first-test \
click 6

--session first-test \
click 6" width="799" height="424">

At this point, I had completed a complete workflow:

Create Browser → Open Session → Inspect → Input → Click → Navigate

without writing a browser automation script.

Third Test: Using BrowserAct with an AI Agent

After testing BrowserAct directly through the CLI, I wanted to see how it behaved inside an actual AI agent workflow.

For this experiment, I used Codex as the agent runtime.

One advantage of BrowserAct is that it does not need to live as a standalone tool. We can instruct the agent to invoke BrowserAct whenever browser interaction becomes necessary. That includes opening websites, clicking buttons, handling login flows, extracting structured content, or interacting with dynamic pages.

To test this, I asked the agent to install BrowserAct and use it as part of its workflow.

Here is the prompt I provided:

Set up BrowserAct for me. 
Read the BrowserAct skill first: https://github.com/browser-act/skills/blob/main/browser-act/SKILL.md
Install or update the browser-act skill, then verify it works. 
Use BrowserAct when I need an AI agent to browse, click, fill forms,
handle login flows, solve CAPTCHAs, bypass bot detection, or extract structured data from websites. 
After setup, open this repository in my browser: https://github.com/browser-act/skills 
If I am logged in to GitHub, 
ask me whether you should star it for me as a quick demo that browser interaction works. 
Only click the star if I explicitly say yes.

After receiving the instructions, the agent started executing the workflow automatically.

The workflow looked something like this:

Agent starts
        ↓
Installs BrowserAct skill
        ↓
Verifies installation
        ↓
Opens GitHub repository
        ↓
Checks authentication state
        ↓
Requests confirmation
        ↓
Performs browser action

The interesting part was watching the agent use BrowserAct as a tool rather than relying on static instructions. Browser actions became part of the execution process instead of separate manual steps.

After receiving confirmation, the agent completed the task successfully and starred the repository.

Although starring a GitHub repository is a simple action, it demonstrates an important capability. The agent was able to open a real website, maintain browser state, interact with UI elements, and complete an action inside an authenticated environment.

This feels much closer to real-world AI workflows than isolated browser automation scripts.

Fourth Test: Human Handoff with an AI Agent

One feature that interested me most was human handoff.

Many automation workflows eventually reach a point where the process cannot continue without human participation. Common examples include OTP verification, QR login, enterprise SSO approval, and security confirmations.

To test this behavior, I used Codex together with BrowserAct and created a workflow that required OTP verification.

My objective was straightforward:

Let the agent open the login page
Enter the email automatically
Pause when OTP is required
Preserve browser state
Resume execution after human input

I provided the following prompt to the agent:

Use BrowserAct for this workflow. 

Open: https://practice.expandtesting.com/otp-login 

Actions: 
1. Launch BrowserAct 
2. Open the website 
3. Continue the login workflow 
4. If human interaction becomes necessary for OTP, preserve browser state and use BrowserAct's collaboration capability 
5. Resume execution after collaboration completes

The agent launched BrowserAct, created a browser session, and navigated to the login page.

When the workflow reached the authentication stage, BrowserAct detected that human interaction was required and generated a collaboration link.

I opened the collaboration link and completed the login process manually.

Once authentication finished, control automatically returned to the agent without restarting the browser session.

The interesting part was that the browser state remained active throughout the interruption. The agent paused execution, handed control to a human when necessary, and then continued from the exact same session once the required action had been completed.

For production workflows involving authentication, verification, or approval steps, this feels significantly more practical than forcing complete automation.

Fifth Test: Running Multiple Browser Sessions

Another scenario I wanted to test was running multiple independent browser sessions.

Long-running AI systems rarely perform a single task. They may monitor dashboards, analyze feedback, review customer activity, and collect information simultaneously.

I created several browser sessions locally.

browser-act --session reviews browser open chrome_local_102863481715294440 https://reddit.com

browser-act --session ops browser open chrome_local_102863481715294440 https://status.openai.com

browser-act --session community browser open chrome_local_102863481715294440 https://dev.to

I then listed active sessions:

browser-act session list

The output showed multiple active sessions operating independently.

This separation becomes useful because each workflow maintains its own execution state while avoiding interference with other tasks.

Final Thoughts

After spending some time testing BrowserAct, I understand why it attracted attention during its Product Hunt launch.

The value does not come from simply opening browsers and clicking buttons.

The interesting part is treating the browser as an execution layer for AI agents and handling the problems that appear in real environments.

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

The Code Review Metrics No One Is Tracking..

Kiran Naragund — Mon, 29 Jun 2026 17:09:37 +0000

Hello Devs 👋

When teams talk about engineering metrics, the conversation usually moves toward speed. We often look at things like pull request turnaround time, lead time, deployment frequency, and how quickly changes move through the system.

These are useful metrics because they tell us how efficiently work is flowing through the development process. But after spending time on larger projects and working across different teams, I started noticing that speed alone doesn't always tell the full story.

I've seen teams merge pull requests quickly and still spend a lot of time later dealing with repeated issues, hotfixes, and bugs that somehow escaped review. I've also seen teams with slower review cycles that ended up having fewer production issues because they consistently caught missing pieces earlier.

That made me think about whether we sometimes focus too much on how fast reviews move and not enough on whether reviews are actually helping improve code quality.

Let's get into it 🚀

⚡ Quick Verdict

Qodo is probably one of the better options if your goal is not just measuring review speed but understanding review quality across a team. Instead of only showing statistics around pull request activity, it tries to surface patterns that are easy to miss during day-to-day development. Things like recurring issues, repeated review findings, critical problems appearing across repositories, and whether developers are actually resolving suggestions start becoming visible.

That becomes more useful as projects grow because the challenge usually changes over time. In smaller projects, the focus is often on moving code quickly. In larger systems with more developers and more pull requests, the bigger challenge becomes understanding whether the same problems keep appearing repeatedly and slowly affecting quality.

The Problem With Looking Only at PR Velocity

Let's imagine two teams.

Team A has an average review time of around 15 minutes. Pull requests move quickly, deployments happen frequently, and every dashboard looks healthy.

Team B takes closer to 40 minutes on average to review pull requests. From the outside it initially looks like Team B is moving more slowly.

But after a few months, a different picture starts appearing.

Team A repeatedly runs into missing edge cases, production fixes, and review discussions that seem strangely familiar. Reviewers continue asking for missing tests, validation updates, and similar changes over and over again.

Team B, despite taking longer during reviews, catches many of these issues before code reaches production.

At that point the discussion becomes less about "Which team reviews faster?" and more about "Which team is preventing problems from repeating?"

That difference is important because pull request speed by itself doesn't tell us whether reviews are actually doing their job.

Metrics I Think Teams Ignore Too Often

I don't think these replace DORA metrics or existing engineering metrics. I think they help explain the things happening underneath them.

Repeated Review Comments

Most teams eventually start seeing the same comments appear repeatedly in reviews.

Things like:

Missing test coverage

Validation missing

Logging not updated

Missing null handling

If reviewers repeatedly ask for the same fixes, there is usually something deeper happening. It often means team standards are unclear, patterns are not consistently enforced, or reviewers are spending time doing repetitive work that could probably be automated.

Over time this also creates review fatigue because developers and reviewers start seeing the same discussions repeatedly.

Resolution Rate

This was one of the more interesting things I started thinking about.

Detecting issues isn't necessarily difficult. Most tools can generate findings and suggestions. The more important question is whether developers actually resolve them.

Let's imagine your team detected 150 review findings this month. That initially sounds useful.

But then imagine that only 50 of those findings actually got resolved.

Now the discussion changes. Instead of asking how many issues were found, you start asking whether developers trust the findings enough to act on them. If suggestions consistently get ignored, then the issue may not be lack of detection. The issue might be noise.

Average Findings Per Pull Request

This metric becomes interesting when you stop looking at it as a fixed number and start looking at trends.

Let's say your average findings per pull request increased from 1.4 to 4.8 over a few months.

That increase by itself doesn't automatically mean quality became worse.

Maybe AI-generated code started becoming part of the workflow. Maybe more developers joined the project. Maybe complexity increased as new services were added.

The actual number isn't usually the important part. The trend and the reasons behind it tend to reveal much more.

Critical Findings Across Repositories

Some issues never fail CI and never break builds.

Examples might include:

Missing authorization checks
Dependency-related risks
Missing audit logging
Breaking changes in shared services

If you see one isolated issue, it may not look important.

But if similar issues repeatedly appear across repositories and teams, they stop feeling like isolated bugs. At that point they start looking more like process problems or architectural patterns that need attention.

What Made Me Think About This

Recently I was reading about Qodo's Findings page and the idea behind it caught my attention.

Most review feedback today lives inside pull requests. Someone opens a PR, reviewers leave comments, fixes get pushed, and eventually the pull request gets merged. After that, the conversation mostly disappears.

The problem with that workflow is that patterns disappear too.

The Findings page tries to look across repositories and over longer periods of time by surfacing things like recurring findings, critical issues, resolution trends, and repeated review patterns.

What I found interesting wasn't really the feature itself. It was the way it changes the perspective.

If the same validation issue appears in thirty pull requests over two months, that no longer feels like an individual PR issue. It starts feeling like a signal that something larger is happening in the team's workflow.

You can read more about monitoing organization-wide pull request findings here: https://docs.qodo.ai/governance/view-all-findings-in-organization

A Practical Example

Let's imagine your team created 150 pull requests over the last month.

The dashboard initially looks healthy because review time is improving, deployment frequency has increased, and pull requests are moving smoothly.

But when you start looking deeper, you notice that 42 pull requests had missing test coverage, 28 repeated similar validation problems, and dependency-related risks kept appearing across multiple repositories.

The conversation naturally becomes more useful because people stop asking why reviews are slow and start asking why the same problems continue appearing repeatedly.

That usually leads to more meaningful improvements because now the focus shifts from speed alone toward improving the development process itself.

📚 Want to Read More?

If you want to explore this area further, Qodo has a learning hub with a few useful resources around AI-assisted review workflows and code quality.

Some good starting points are:

What is AI Code Review
A good introduction to how AI review works and the kinds of problems it tries to catch.

Reviewing AI-generated Code
Covers common patterns and mistakes teams are seeing as AI-generated code becomes more common.

AI Code Review Tools Comparison
Useful if you want to understand how different approaches and tools compare.

Final Thoughts

Metrics like deployment frequency and lead time still matter and they will continue to matter. But they don't always explain why teams repeatedly run into certain problems.

As development teams generate more code and AI continues increasing review volume, understanding review quality probably becomes more important too.

Questions around recurring findings, issue resolution, and repeated patterns often tell a more complete story than review speed alone because they reveal the hidden work that teams keep paying for repeatedly.

A fast pull request is useful, but a healthy review process is usually much more valuable over time.

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

AI Can Generate Code Faster. The Bigger Challenge Is Reviewing It 😐

Kiran Naragund — Sat, 27 Jun 2026 18:46:30 +0000

Hello Devs 👋

AI coding assistants have changed the way many teams build software. Tasks like generating components, creating tests, writing boilerplate, or handling repetitive refactors can now happen in minutes instead of hours.

The productivity gain is real and that part is easy to notice.

What becomes interesting after using these tools for a while is that a different bottleneck starts appearing. Code generation becomes faster, but the review process often stays the same.

Teams can generate hundreds of lines of code within minutes, but someone still has to answer important questions:

Does this actually solve the requirement?
Are edge cases covered?
Will this introduce side effects?
Does it align with existing patterns?

The speed of writing code has changed. The need for confidence has not.

That is where I think the conversation around AI-assisted development is starting to shift.

The challenge is becoming less about generating code and more about making sure the generated code is actually safe to ship.

The Problem With Reviewing AI-Generated Code Like Regular Code

Imagine asking an AI coding assistant to implement coupon validation for premium users.

Add coupon validation for premium users and create tests

A few seconds later you get:

if(user.isPremium){
   applyCoupon();
}

Nothing immediately looks wrong. The code is clean, there are no syntax issues, tests may pass, and the implementation appears complete.

But pull request reviews usually go beyond reading diffs.

Reviewers start asking questions such as:

What happens if the coupon has expired?
Does this affect payment calculations?
Should audit logs be updated?
Are there services depending on this behavior?

This is where AI-generated code becomes interesting.

It can often be functionally correct while still missing important implementation details. Research around larger AI-generated projects has also shown that functional correctness does not necessarily translate into maintainable system design. Teams still encounter duplicated logic, complexity growth, weak exception handling, and architectural inconsistencies.

Eventually humans catch these issues.

The question becomes:

Can we catch them earlier?

A Different Workflow: Cursor Builds, Qodo Reviews

One thing I found interesting is thinking about AI code generation and AI review as two separate responsibilities.

Instead of treating generation and validation as the same problem, Qodo positions itself as a quality layer across the development workflow.

The process becomes something like:

Generate → Review → Push → Review Again → Ship

Rather than:

Generate → Push → Hope the PR catches everything

Step 1: Feed standards before code gets generated

AI assistants work from context. If they do not know your architecture patterns, naming conventions, or domain rules, they fall back to generic assumptions.

Qodo introduces a shared rule system(agent-skills) that can provide those standards before generation starts. The same rules used later in reviews can also guide code generation itself. That means expectations stay consistent throughout the workflow instead of changing between development and review.

Step 2: Review locally before code leaves the IDE

Most review feedback arrives after a pull request is opened.

By then developers have often switched context and mentally moved on from the implementation.

One thing Qodo does differently is shifting review earlier into development itself. Local changes can be reviewed directly inside the IDE before they ever reach a repository.

That means issues such as:

Missing tests
Duplicated logic
Potential bugs
Violations of team standards

can surface while the implementation is still fresh in your head. Qodo describes this as a shift-left review approach where quality checks happen before PR discussions even begin.

Step 3: Review pull requests with full context

Traditional PR reviews usually focus on changed lines.

The challenge is that code changes rarely live in isolation.

Qodo's review system attempts to include broader context such as repository history, related code, dependencies, and organizational standards when evaluating a pull request. Multiple review agents then focus on different concerns like duplicated logic, breaking changes, critical bugs, and rule enforcement.

That changes the type of feedback you receive.

Instead of:

Variable naming could improve

You may get something closer to:

This update changes payment behavior but related audit handling appears missing

The feedback becomes more focused on intent and impact rather than surface-level observations.

AI Review Is Not Replacing Human Review

I do not think AI review replaces engineers.

Human reviewers still understand business decisions, architecture trade-offs, and product context in ways AI systems currently struggle with.

Where AI review becomes useful is reducing repetitive work and helping teams focus attention where it matters.

It can surface missing pieces, highlight risks, and point out areas worth investigating.

The role feels less like replacing code review and more like adding another layer of verification.

Final Thoughts

AI has already changed how quickly code gets written.

The next challenge is making sure quality scales with that speed.

What stood out to me is that Qodo is not trying to become another code generator. The idea seems closer to becoming a quality layer that sits alongside development and review workflows.

Cursor builds.

Qodo reviews.

That separation actually feels natural.

Because as teams generate more code with AI, confidence in what gets shipped becomes just as important as speed.

Resources & Getting Started

If you want to explore the workflow further, here are a few useful resources from Qodo:

Get started with Qodo:
Qodo Platform

Documentation and setup guides:
Qodo Documentation

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

Best AI Code Review Tools for Catching Breaking Changes 🔥

Kiran Naragund — Mon, 22 Jun 2026 19:51:45 +0000

Hello Devs 👋

Most code review tools are good at finding syntax problems, style issues, and missing test cases. The harder problem is finding changes that look harmless in a pull request but later break another service, API consumer, or application.

A renamed field, a modified function signature, or a small schema change can easily pass review. The code itself still works, but the impact shows up after deployment.

This is where AI code review becomes more interesting. Instead of looking only at the current file, some tools can understand context and identify changes that might affect other parts of the system.

⚡ Quick Verdict

Qodo is the best AI code review tool for catching breaking changes and reviewing high impact pull requests. It can fit naturally into GitHub workflows, analyze pull requests with more repository context, and focus on changes that can affect downstream systems.

For teams dealing with shared APIs, AI generated code, or larger codebases with multiple dependencies, this becomes useful because the review is not only checking code quality. It is also asking whether the change can break something after deployment.

That becomes even more useful when using a focused Breaking Changes agent that reviews things like API contracts, function signatures, interface changes, and backward compatibility.

What actually counts as a breaking change?

Breaking changes usually happen when code changes affect consumers outside the current file or service.

Common examples include:

Function signature changes
Removed or renamed fields
API response updates
Database schema modifications
Shared library changes
Interface updates

For example:

Before:

{
   "name": "John",
   "email": "john@example.com"
}

After:

{
   "fullName": "John",
   "email": "john@example.com"
}

The change itself looks small and clean. During review, many developers would approve this without a second thought.

The issue starts when another service still expects the name field. The code passes review, deployments succeed, and then suddenly downstream systems start failing.

Traditional review tools often miss this because there is no syntax problem. The problem is the impact of the change.

1. Qodo

Qodo becomes interesting because it can focus on pull request reasoning instead of leaving generic comments on every file.

Many AI review systems give suggestions around naming, formatting, or code cleanup. Those suggestions are useful, but they do not always help with production risks.

A focused Breaking Changes agent could instead ask questions like:

Did an API contract change?
Did a function signature change?
Did a shared interface change?
Can dependent services fail?
Is backward compatibility affected?

For example:

Before:

getUser(id)

After:

getUser(userId, includeMetadata = false)

The code still works and tests might still pass.

A Breaking Changes agent could still flag this and warn that consumers may still rely on the previous function signature. This creates more useful feedback because it focuses on downstream impact rather than only code style.

Best for:

Teams working with shared APIs, larger repositories, AI generated code, and pull requests where breaking downstream systems is a bigger concern.

2. GitHub Copilot

GitHub Copilot has already become part of many developer workflows and provides pull request summaries, code explanations, and development assistance.

It works well when teams want a broad coding assistant inside GitHub.

The limitation for this use case is that Copilot focuses more on overall developer productivity than specialized breaking change analysis.

Best for:

Teams looking for general AI assistance and coding productivity.

3. CodeRabbit

CodeRabbit automates pull request reviews and generates comments around changes.

The setup process is simple and the pull request summaries can help teams handling a large number of reviews.

Sometimes broader review systems generate many suggestions and comments. Over time developers can start ignoring reviews if too much low value feedback appears.

Best for:

Teams wanting automated pull request reviews with minimal setup.

4. Amazon CodeGuru Reviewer

Amazon CodeGuru Reviewer focuses more on code quality, performance, and security recommendations.

It can identify inefficient code patterns and suggest improvements across applications running in AWS environments.

Its focus is usually broader code quality analysis rather than contract awareness or downstream impact detection.

Best for:

AWS teams focused on performance and quality improvements.

5. SonarQube

SonarQube has been a common choice for static analysis and code quality checks for years. With newer AI related capabilities and integrations, teams are using it alongside AI workflows.

It performs well for identifying maintainability issues, security risks, and technical debt.

Breaking changes can still require additional context because static analysis alone may not understand the impact across multiple systems.

Best for:

Teams that already rely heavily on code quality gates and static analysis.

6. Snyk Code

Snyk Code mainly focuses on security analysis and code scanning.

For development teams where security and review happen together, it can become part of the pull request workflow.

While it is not designed specifically for breaking change detection, it helps catch risks that could eventually create larger issues in production.

Best for:

Security focused development teams.

Learning resources worth checking

If you want to go deeper into AI code review, Qodo also has a learning hub with practical articles around the topic. Some useful pieces include:

What is AI code review, which explains how AI reviews work and what they can actually detect
Reviewing AI generated code, which covers common patterns and mistakes developers often miss

These resources are useful if you want to understand not just the tools, but also the review process itself.

Final thoughts

When reviewing pull requests, the question is usually not whether AI can explain code better. The more useful question is whether the change can create problems after deployment.

A tool that creates twenty comments is not always more valuable than a tool that catches one issue that could break production.

For catching breaking changes, fewer and more relevant signals usually provide more value than large amounts of feedback.

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)

🔥7 Tools Every AI Agent Developer Should Know in 2026

Kiran Naragund — Mon, 22 Jun 2026 06:38:55 +0000

Hello Devs👋

A year ago, most AI projects were glorified chatbots.

Today, we're building agents that browse websites, execute workflows, analyze data, monitor systems, interact with SaaS products, and collaborate with humans.

The challenge is no longer getting an LLM to answer questions. The challenge is giving AI agents reliable access to the real world.

After experimenting with dozens of frameworks and platforms, I've found that successful AI agents usually rely on a small set of tools that solve very specific problems:

Reasoning
Memory
Browser interaction
Workflow orchestration
Observability
Knowledge retrieval
Human collaboration

If you're building AI agents in 2026, these are seven tools worth knowing.

1. BrowserAct

Most AI agents fail when they leave the comfort of APIs and enter the browser.

Modern websites are full of:

Dynamic content
Login flows
CAPTCHA challenges
Anti-bot systems
Multi-step workflows

This is where BrowserAct becomes interesting.

BrowserAct is a browser automation CLI built for AI agents. It gives agents real browser control, anti-detection browser environments, human handoff when automation gets stuck, parallel sessions that do not interfere with each other, and independent browser identities for multi-account workflows.

Instead of simply opening pages and clicking buttons, it helps agents operate inside real-world browser environments while supporting:

Anti-detection browser profiles
Session management
Human handoff
Parallel browser tasks
Multi-account isolation
Reusable browser skills

I tested a simple BrowserAct workflow locally first.

Installing BrowserAct:

uv tool install browser-act-cli --python 3.12

To run my local browser, I listed the available browser profiles.

browser-act browser list-profiles

I then created a browser using my existing Chrome profile.

Now, Im going to extract the content from the website example.com

browser-act stealth-extract https://example.com --content-type markdown

Using BrowserAct with an AI Agent

I'm using Codex as the agent runtime for this experiment.

We can instruct the agent to use browser-act whenever browser interaction is required, such as opening pages, clicking buttons, handling login flows, or extracting structured data.

Here is my Agent prompt.

Set up BrowserAct for me. Read the BrowserAct skill first: [https://github.com/browser-act/skills/tree/main/browser-act](https://github.com/browser-act/skills/blob/main/browser-act/SKILL.md)/SKILL.md Install or update the browser-act skill, then verify it works. Use BrowserAct when I need an AI agent to browse, click, fill forms, handle login flows, solve CAPTCHAs, bypass bot detection, or extract structured data from websites. After setup, open this repository in my browser: https://github.com/browser-act/skills If I am logged in to GitHub, ask me whether you should star it for me as a quick demo that browser interaction works. Only click the star if I explicitly say yes.

Here is how the agent executed the workflow:

The agent successfully completed the task and starred the repository after receiving explicit confirmation.

While starring a repository is simple, the important part is that the agent successfully opened a real website, preserved browser state, interacted with UI elements, and completed an action inside an authenticated session.

Real Use Case: Competitor Monitoring Agent

Imagine building an agent that monitors competitor pricing across multiple ecommerce platforms.

A simple scraper often breaks because:

Pages require login
Content is dynamically rendered
Risk-control systems trigger
Browser fingerprints get flagged

With BrowserAct, the workflow becomes:

The key advantage is that browser identity, cookies, proxies, and session state remain isolated and reusable.

Real Use Case: Human Handoff

Every automation eventually encounters a step that requires a human.

Examples:

QR code login
SMS verification
Enterprise SSO approval
Security confirmation

Most automation tools simply fail at this point.

BrowserAct keeps the browser session alive and allows a human to complete the required action. Once verification is finished, the agent continues from the same session instead of restarting the workflow.

This sounds simple, but it solves one of the most common production bottlenecks in browser-based agents.

Testing Human Handoff with an AI Agent

To see how BrowserAct handles real interruptions, I tested the workflow using Codex as the AI agent runtime.

The goal was simple: let the agent handle the login process automatically, pause when human input becomes necessary, and then continue from the same browser session.

Here is the prompt I gave the agent:

Use BrowserAct for this workflow.

Open:
https://practice.expandtesting.com/otp-login

Actions:

1. Launch BrowserAct
2. Open the OTP login page
3. Fill the email field with:
   practice@expandtesting.com
4. Continue the login flow
5. If OTP verification is required:

   - Preserve browser state
   - Pause execution
   - Ask me for the OTP code
   - Wait for my response

6. After I provide the OTP:
   - Resume from the same session
   - Complete login
   - Confirm success

Do not restart the browser session if human input is needed.

Here is the Agent executions

Agent creating a browser session called expandtesting_otp_login for the execution
The agent entered the email automatically and paused at the OTP step while preserving the browser session.
After I provided the OTP, the agent resumed execution and completed authentication successfully.

What stood out here was not the OTP itself.

The interesting part was that the browser session remained active throughout the interruption. The workflow continued from the existing state instead of restarting the login process from the beginning.

Real Use Case: Multi-Agent Operations

Suppose you're running:

Customer support monitoring
Order review
Feedback analysis
Dashboard reporting

Instead of forcing everything into one browser session, BrowserAct allows each task to run independently while maintaining the required account state.

To understand how BrowserAct handles parallel workflows, I created multiple independent browser sessions locally.

Start separate browser sessions:

browser-act --session reviews browser open chrome_local_102863481715294440 https://reddit.com

browser-act --session ops browser open chrome_local_102863481715294440 https://status.openai.com

browser-act --session dev-community browser open chrome_local_102863481715294440 https://dev.to

Checking active browser sessions:

browser-act session list

Output:

The active session list showed that each workflow was isolated even though the browser profile remained shared.

This separation matters for long-running AI systems because browser state, cookies, and task execution stay independent and avoid cross-workflow interference.

For teams building agents that interact heavily with web applications, BrowserAct fills a gap that traditional browser automation tools were never designed to solve.

GitHub Repo:
https://github.com/browser-act/skills

2. LangGraph by LangChain

Reasoning alone is rarely enough for production agents.

As agents become more capable, you quickly run into problems like:

Multi-step workflows
Long-running tasks
Human approvals
State persistence
Multi-agent coordination

This is where LangGraph becomes useful.

LangGraph is designed specifically for building stateful AI agents that operate through graph-based workflows rather than simple request-response loops.

Instead of forcing everything into a single prompt, it allows developers to define controlled execution paths while still preserving agent flexibility.

Key capabilities:

Stateful workflows
Human-in-the-loop checkpoints
Durable execution
Multi-agent coordination
Retry and recovery handling
Streaming execution

Real Use Case: Customer Support Agent

Imagine a support agent handling enterprise tickets:

Read ticket details
Retrieve account information
Check documentation
Escalate complex issues
Request human approval when needed
Return a final response

Without orchestration, these workflows become messy very quickly.

LangGraph helps structure the decision flow while preserving memory and state.

Repository / Docs:

https://docs.langchain.com/oss/python/langgraph/overview

3. Mem0 by Mem0

Most agents have terrible memory.

They either:

Forget previous interactions
Stuff everything into context windows
Waste tokens repeatedly
Lose long-term user preferences

Mem0 solves this problem by acting as a persistent memory layer for AI agents.

Rather than replaying full conversations every time, it extracts useful information, stores it, and retrieves only what matters.

Key capabilities:

Persistent long-term memory
Automatic memory extraction
Memory compression
Cross-session recall
User preference tracking
Reduced token usage

Real Use Case: AI Personal Assistant

Imagine an assistant helping a user over several months.

Instead of repeatedly asking:

"What programming language do you use?"
"What projects are you working on?"
"What are your preferences?"

The agent remembers previous interactions and becomes more useful over time.

This makes interactions feel less like chatting with a stateless model and more like working with an actual assistant.

4. n8n

Building an AI agent is one thing.

Connecting it to the rest of your stack is a completely different challenge.

Agents rarely operate in isolation. They usually need to:

Trigger workflows
Update databases
Send emails
Connect with SaaS products
Call APIs
Execute scheduled tasks

This is where n8n becomes useful.

n8n is a workflow automation platform that helps AI agents interact with external systems through visual workflows and programmable logic.

Instead of writing custom integrations for every service, developers can connect agents to hundreds of tools while keeping workflows manageable.

Key capabilities:

Visual workflow builder
AI agent integrations
Self-hosted deployment
API connectivity
Scheduled workflows
Large integration ecosystem

Real Use Case: Lead Qualification Agent

Imagine an AI sales agent processing incoming leads:

Read lead information
Analyze qualification criteria
Update CRM records
Send personalized emails
Create support tickets
Notify sales teams

Without workflow orchestration, every integration requires additional code and maintenance.

n8n helps coordinate these actions while keeping the workflow transparent and easy to modify.

Link / Docs:

https://n8n.io/

5. Langfuse

AI agents become difficult to debug once they move into production.

When something goes wrong, questions appear quickly:

Why did the agent fail?
Which prompt caused the issue?
Which tool produced incorrect output?
Why did token usage suddenly increase?
Why did response quality drop?

This is where Langfuse becomes useful.

Langfuse is an observability platform designed for LLM applications and AI agents.

Instead of guessing what happened during execution, developers can inspect traces, prompts, model outputs, evaluations, and performance metrics.

Key capabilities:

Request tracing
Prompt debugging
Agent evaluation
Cost monitoring
Performance analytics
Session replay

Real Use Case: Production Agent Debugging

Imagine a customer support agent that suddenly starts returning poor responses.

A typical debugging workflow might look like:

Open execution traces
Inspect prompts
Review tool outputs
Analyze model decisions
Compare successful runs
Identify failure patterns

Without observability, debugging often becomes trial and error.

Langfuse helps developers understand what actually happened during execution.

Link / Docs:

https://langfuse.com

6. Qdrant

Many AI agents become significantly more useful when they can access external knowledge.

The challenge is that agents often need to work with:

Documentation
Internal knowledge bases
PDFs
Support tickets
Research data
Large collections of text

This is where Qdrant becomes useful.

Qdrant is a vector database designed for semantic search and retrieval workflows.

Instead of relying only on the model's built-in knowledge, developers can store embeddings and retrieve relevant information dynamically.

Key capabilities:

Vector search
Hybrid search
Metadata filtering
Scalable retrieval
Fast indexing
Production deployment support

Real Use Case: Internal Knowledge Assistant

Imagine building an AI assistant for a company.

The workflow could look like:

User asks a question
Generate embeddings
Search relevant documents
Retrieve matching information
Add context to the prompt
Generate a final answer

Without retrieval systems, the model depends only on what it already knows.

Qdrant helps agents access updated information and organization-specific knowledge.

Link / Docs:

https://qdrant.tech

7. HumanLayer

No matter how capable AI agents become, some decisions still require human involvement.

Examples include:

Financial approvals
Sensitive actions
Escalations
Security checks
Compliance reviews
Critical business decisions

This is where HumanLayer becomes useful.

HumanLayer is designed to add human approval and collaboration workflows into AI agents.

Instead of allowing agents to operate without oversight, developers can introduce checkpoints where humans review and approve actions before execution continues.

Key capabilities:

Human approval workflows
Slack integration
Escalation handling
Human checkpoints
Agent collaboration
Action gating

Real Use Case: Financial Approval Agent

Imagine an AI agent responsible for preparing payment requests:

Gather payment information
Validate transaction details
Generate recommendations
Send approval request
Wait for human confirmation
Execute approved actions

Without human collaboration layers, agents may perform actions that require oversight.

HumanLayer helps agents safely involve people when decisions become sensitive.

Link / Docs:

https://humanlayer.dev

Thank You!!🙏

Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Senior Software Engineer ✦ Open-Source Contributor ✦ Email for Collabs :)