DEV Community: Kiran Naragund

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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ 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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ 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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ 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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ 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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ 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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ 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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ Open-Source Contributor ✦ Email for Collabs :)

Wiring AI Code Review into a Bitbucket + Jira Workflow

Kiran Naragund — Sun, 21 Jun 2026 19:02:11 +0000

Hello Devs 👋

If your team uses Bitbucket + Jira, your workflow probably looks something like this:

Pick a Jira ticket
Create a branch
Push code
Open a pull request
Get reviews
Merge and close the ticket

Pretty straightforward.

But as projects start growing and more developers join the team, things slowly become messy.

You start seeing situations like:

PRs with very little context
Requirements getting missed during implementation
The same review comments appearing repeatedly
Tickets marked as "done" while edge cases are still missing

Most discussions around AI code review focus heavily on GitHub workflows.

But many teams still work inside Bitbucket + Jira every day.

So I wanted to understand something:

Where does AI code review actually fit into this workflow?

Not just PR summaries. Not just generated comments..

Can it actually help developers during day-to-day work?

Let's get into it 🚀

Why Bitbucket + Jira Workflows Feel Different

Bitbucket and Jira already integrate really well.

You can:

Link branches directly to Jira tickets
Connect pull requests to issues
Track development progress automatically
Trigger CI/CD workflows

The problem usually is not integration.

The harder part is making sure implementation actually matches what the ticket intended.

Review discussions often become:

Did we update all affected services?
Does this fully match the Jira requirement?
Are tests missing?
Could this change affect something else?

Human reviewers catch a lot of this. But not always.

That's where AI review starts becoming interesting. Not as a replacement for reviews. More like an additional validation layer.

A Simple Bitbucket + Jira Workflow

Let’s take a basic example.

Step 1: Create a Jira ticket

Example:

PAY-142

"Add coupon validation for premium users"

Step 2: Create a linked branch

Something like:

feature/PAY-142-coupon-validation

Bitbucket automatically links the branch with Jira.

Step 3: Implement the change

You add something like:

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

Looks fine.

PR opens successfully.

Tests pass.

Everything seems okay.

Step 4: Review the PR

Normally reviewers look at:

Code quality
Naming
Logic
Tests

AI reviewers can add another layer:

Did related files also need updates?
Are edge cases missing?
Does the implementation fully match the ticket?
Could this affect shared services?

Instead of replacing reviews, it helps fill small gaps.

Where I Found Qodo Interesting

While exploring AI review tools for this workflow, one thing I noticed with Qodo was that it tries to review more than just the changed lines inside a pull request.

Instead of focusing only on the PR diff, it attempts to understand:

Related files
Existing code patterns
Dependencies
Previous review context

For example:

Imagine the Jira ticket says:

Add audit logging for payment updates

Implementation:

updatePayment();

The code works.

Tests pass.

PR gets approved.

Everything looks fine.

Except logging was never added.

Traditional checks may not catch that.

A reviewer might miss it too.

In larger projects, where a single Jira ticket touches multiple files or services, having another layer looking for missing pieces can be useful.

I liked this because it felt less like:

"Here's a random AI suggestion"

and more like:

"Something related to this change might be missing"

That context becomes more useful as projects grow.

SonarQube vs AI Review in This Workflow

SonarQube still has an important role.

It helps with:

✅ Security checks
✅ Code smells
✅ Quality gates
✅ Coverage rules

But SonarQube mainly answers:

Is something technically wrong?
AI review often tries to answer:
Does this implementation make sense in context?

Both solve different problems.

📚 Want to Read More?

If you want to learn more about AI-assisted reviews and workflows, Qodo has a learning hub with some useful resources.

A few interesting ones:

What is AI Code Review
Good starting point if you want to understand how AI review works and what it tries to catch.
Reviewing AI Generated Code
Covers common mistakes and patterns teams see when reviewing AI-written code.
AI Code Review Tools Comparison
Useful if you want to compare approaches and understand where different tools fit.

🏁 Final Thoughts

AI code review is not replacing Jira workflows or human reviewers.

It adds another layer between:

Ticket → Code → Pull Request

For Bitbucket + Jira teams, that can help reduce:

Missing requirements
Repeated review comments
Small issues that become larger problems later

Most discussions online focus on GitHub.

But for teams already using Bitbucket and Jira every day, there is still a lot of value in adding AI review to the workflow.

👨‍💻 TL;DR

✅ Jira tracks requirements
✅ Bitbucket manages code changes
✅ AI review adds another validation layer
✅ Useful when PRs affect multiple files or services

As always, tools help, but good reviews still need humans.

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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ Open-Source Contributor ✦ Email for Collabs :)

From MVP to Production: Tools That Grow With Your SaaS 🚀

Kiran Naragund — Mon, 16 Mar 2026 03:20:09 +0000

Hello Devs 👋

Building a SaaS product is thrilling. But moving from your first MVP to a reliable production service takes more than code. You need scalable infrastructure for things like auth, billing, emails, uploads, observability, and execution intelligence. Building all of this from scratch slows you down and introduces risk.

That’s why many SaaS teams use proven tools and SDKs that solve real infrastructure problems so they can focus on the core product.

In this article you’ll get for each tool:

A clear description of what it does
Key features
Why it’s useful for SaaS
A simple getting-started guide
Links to official docs and websites

Let’s level up your SaaS stack 👇

What’s an SDK?

A software development kit (SDK) is a bundled set of tools that helps you integrate functionality or services into your application without building them from scratch.

SDKs often include:

Prewritten code libraries
APIs and interface definitions
Documentation and examples
Debugging or testing helpers

Using SDKs helps you:

Save time
Avoid reinventing the wheel
Reduce bugs
Build consistently across environments

Whether you need authentication, payments, emails, or production intelligence, well-chosen SDKs drastically speed up development.

Hud: Runtime Production Intelligence That Scales With You

Hud is a runtime code sensor that captures real production execution behavior and brings that context where engineers actually work in their IDEs and code review workflows. It continuously collects function-level execution data, detects issues like regressions or errors, surfaces root causes, and powers production-aware development with or without AI assists.

Unlike typical SDKs that provide discrete functions (like auth or payments), Hud is an intelligence layer. It does not change your business logic. Instead, it observes how that logic behaves under production traffic and delivers real execution insights back into your development loop.

Why It Matters

Most SaaS teams face a gap between:

What code looks like in source
How it actually runs under real customer load

This gap grows as you scale and adopt AI-assisted coding tools. Code suggestions and refactors that look valid in staging may fail in production because they lack real execution context.

Hud fills this gap by:

Giving function behavior signals from production
Detecting regressions or errors automatically
Pinpointing exact root causes
Feeding runtime context into supported IDEs
Enabling safer, production-aware AI coding workflows (MCP server)

In short, Hud helps you move from reactive debugging to proactive production confidence.

Key Features

Function-Level Execution Data: Hud captures how each function behaves in production: invocation counts, durations, error signals, and behavioral trends.
IDE Integration: Runtime summaries appear inside supported editors like VS Code and JetBrains. You get real behavior context without leaving your code.
Automated Issue Detection: Hud flags behavioral changes after deploys, new errors, and performance regressions with root cause context.
Production-Aware AI Coding: Hud’s MCP server streams production signals into AI assistants like Copilot or Cursor so generated suggestions align with how your code runs.
Minimal Overhead & Zero Config: It installs fast and runs safely in production without heavy configuration.

Why SaaS Teams Use It

Hud is not just another monitoring tool. It becomes valuable when:

Your app has real production traffic
Issues only show up after deploy
You use AI-assisted coding tools
You want deeper insight than logs or traces can provide

Beginner teams focused on MVPs usually do not need this yet. But once you have real users and production complexity, Hud helps teams catch issues early, fix them quickly, and build with confidence.

How to Get Started

Here is a simple guide to set up Hud in a Node.js app.

1. Create a Hud Account

First, sign up at hud.io and create your workspace. After signup you’ll get API keys for your project.

👉 Visit: https://hud.io

2. Install the Hud SDK

In your project directory, install the Hud package:

npm install hud-sdk

This installs the lightweight sensor that captures runtime behavior.

3. Initialize Hud Early in Your App

Hud works best when it starts before your application logic. So import and initialize it early in your main file.

Create a file named hud-init.js:

const hud = require("hud-sdk/setup");

hud.register({ includeModules: [] });

hud.initSession(process.env.HUD_API_KEY, "my-service");

Then, change your start script so this file loads first:

node --require ./hud-init.js index.js

Or import it at the top of your entry file:

import "./hud-init.js";
// ...rest of your app

4. Open Your IDE Extension

Install the Hud extension in your IDE (VS Code, JetBrains, or Cursor). This lets you see real production behavior right next to your code.

VS Code: Install from here
JetBrains IDEs: Install from here

Now you’ll see runtime summaries and signals directly in your editor.

5. Deploy and Watch Production

Once Hud is running in production, it starts collecting and sending runtime data automatically. You can view function performance, errors, and trends in the Hud dashboard or directly in your IDE.

Watch this quick demo video for better understanding 👇

Official Links

Documentation: https://docs.hud.io/docs/welcome
Website: https://hud.io
Install & Setup Guide: https://docs.hud.io/docs/installation-guide

Clerk: Authentication Without Building It Yourself

Clerk helps you handle authentication and user management without building everything from scratch. It takes care of users, sessions, and tokens, so your backend can trust who is making a request.

Instead of writing your own auth logic, you can use Clerk to verify users securely on the backend and protect your APIs.

Key Features

Secure user authentication
Session and token management
Easy backend verification
Works well with Node.js APIs
Dashboard to manage users

Why It’s Useful for SaaS

Every SaaS backend needs to know:

Who the user is
Whether the request is authenticated
Whether the session is valid

Doing this yourself is time-consuming and risky.

Clerk helps you:

Secure your backend APIs quickly
Avoid common auth mistakes
Scale user management as your SaaS grows
Spend less time on security setup

How to Get Started (Backend Setup – Node.js)

1. Create a Clerk Account

👉 Website: https://clerk.com

2. Install the Clerk Backend SDK

In your backend project, install Clerk:

npm install @clerk/clerk-sdk-node

3. Add Environment Variables

Add your Clerk secret key to your environment variables:

CLERK_SECRET_KEY=your_secret_key

4. Protect Backend Routes

Use Clerk middleware to protect your API routes.

import express from "express";
import { ClerkExpressRequireAuth } from "@clerk/clerk-sdk-node";

const app = express();

// Public route
app.get("/public", (req, res) => {
  res.json({ message: "Anyone can access this" });
});

// Protected route
app.get(
  "/api/dashboard",
  ClerkExpressRequireAuth(),
  (req, res) => {
    res.json({
      message: "Authenticated request",
      userId: req.auth.userId,
    });
  }
);

app.listen(3000, () => {
  console.log("Server running on port 3000");
});

Now, only authenticated users can access /api/dashboard.

5. Access User Information on the Backend

Once authenticated, you can safely access user data.

app.get(
  "/api/profile",
  ClerkExpressRequireAuth(),
  (req, res) => {
    res.json({
      userId: req.auth.userId,
      sessionId: req.auth.sessionId,
    });
  }
);

This makes it easy to link users to your database records.

Frontend Configuration (Quick Note)

Once your backend is protected, you’ll need to:

Add Clerk to your frontend (React, Next.js, etc.)
Send the authentication token with API requests

Clerk provides ready-made frontend SDKs and UI components to handle login and signup easily.

👉 Frontend setup docs: https://clerk.com/docs

Official Links

Documentation: https://clerk.com/docs

Website: https://clerk.com

Stripe: Payments and Subscriptions for Your SaaS

Stripe helps you handle payments and subscriptions without building complex billing logic yourself. It takes care of card payments, retries, invoices, and many edge cases that are hard to get right.

For a SaaS backend, Stripe is mainly used to:

Create subscriptions
Charge customers
Listen to payment events using webhooks

Key Features

One-time payments and subscriptions
Secure payment handling
Webhooks for billing events
Customer and invoice management
Widely used and well-documented

Why It’s Useful for SaaS

Almost every SaaS needs billing. Writing your own payment system is risky and slow.

Stripe helps you:

Start charging users quickly
Avoid payment and security issues
Handle upgrades, downgrades, and cancellations
Keep your backend in sync with payment status

How to Get Started (Backend Setup – Node.js)

Below is a simple backend setup using Node.js.

1. Create a Stripe Account

👉 Website: https://stripe.com

2. Install the Stripe SDK

Install Stripe in your backend project:

npm install stripe

3. Add Environment Variables

Add your Stripe secret key to your environment variables:

STRIPE_SECRET_KEY=your_secret_key

4. Initialize Stripe in Your Backend

Create a Stripe client that you can reuse in your app.

import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY, {
  apiVersion: "2026-01-28",
});

export default stripe;

5. Create a Customer

When a user signs up for your SaaS, create a Stripe customer.

const customer = await stripe.customers.create({
  email: "user@email.com",
});

Store the customer.id in your database and link it to the user.

6. Create a Subscription

Use Stripe Checkout or create subscriptions directly from the backend.

const subscription = await stripe.subscriptions.create({
  customer: customer.id,
  items: [
    { price: "price_id_here" },
  ],
});

This starts billing the customer based on your pricing plan.

7. Handle Webhooks

Webhooks tell your backend when something changes, like:

Payment success
Payment failure
Subscription canceled

Create a webhook endpoint:

import express from "express";
import bodyParser from "body-parser";

const app = express();

app.post(
  "/webhook",
  bodyParser.raw({ type: "application/json" }),
  (req, res) => {
    const event = JSON.parse(req.body);

    if (event.type === "invoice.payment_succeeded") {
      console.log("Payment successful");
    }

    if (event.type === "customer.subscription.deleted") {
      console.log("Subscription canceled");
    }

    res.json({ received: true });
  }
);

NOTE: This is just a demo and getting started code, please refer the documentation and implement according to your application needs.

Use webhooks to:

Enable or disable features
Update subscription status in your database

Frontend Configuration (Quick Note)

On the frontend, you’ll usually:

Redirect users to Stripe Checkout
Or collect payment details using Stripe Elements

Stripe provides ready-made frontend tools so you don’t need to handle card data yourself.

👉 Frontend docs: https://stripe.com/docs/payments/checkout

Official Links

Backend Documentation: https://stripe.com/docs/api
Website: https://stripe.com/
Checkout Guide: https://stripe.com/docs/payments/checkout
Webhooks Guide: https://stripe.com/docs/webhooks

Resend: Send Transactional Emails Without the Complexity

Resend helps you send transactional emails from your backend easily and reliably.
This includes emails like:

Welcome emails
Login or magic link emails
Payment or subscription notifications

Instead of managing SMTP servers or complex email setup, Resend gives you a simple API that works well for SaaS products.

Key Features

Simple email-sending API
High email deliverability
Support for HTML and React email templates
Works well with Node.js backends
Minimal setup and clear logs

Why It’s Useful for SaaS

Every SaaS needs emails, but email infrastructure is often painful.

Resend helps you:

Send emails quickly without SMTP setup
Avoid common delivery issues
Keep email logic simple and clean
Focus on product logic instead of email servers

It’s especially useful for early-stage SaaS and MVPs.

How to Get Started (Backend Setup – Node.js)

Below is a simple backend setup using Node.js.

1. Create a Resend Account

👉 Website: https://resend.com

2. Install the Resend SDK

Install Resend in your backend project:

npm install resend

3. Add Environment Variables

Add your Resend API key to your environment variables:

RESEND_API_KEY=your_api_key

4. Send Your First Email

Create a Resend client and send an email from your backend.

import { Resend } from "resend";

const resend = new Resend(process.env.RESEND_API_KEY);

await resend.emails.send({
  from: "SaaS App <noreply@yourdomain.com>",
  to: ["user@email.com"],
  subject: "Welcome to our app",
  html: "<p>Thanks for signing up!</p>",
});

That’s it, your email is sent.

Frontend Configuration (Quick Note)

Resend is mostly used on the backend.
On the frontend, you usually just trigger backend APIs that send emails.

If you want nicer emails, Resend also supports React-based email templates.

👉 Email templates docs: https://resend.com/docs/dashboard/templates/introduction

Official Links

Documentation: https://resend.com/docs/introduction
Website: https://resend.com
Get Started: https://resend.com/docs/send-with-nodejs

UploadThing: Better file uploads

UploadThing helps you handle file uploads in your SaaS without building complex upload logic.
It takes care of file handling, storage, and validation so you don’t have to manage servers or storage APIs directly.

It works especially well with Next.js backends, but the idea stays the same: secure uploads with very little code.

Key Features

Simple and secure file uploads
File size and type validation
No custom storage setup needed
Works well with modern backend frameworks
Clean API and good developer experience

Why It’s Useful for SaaS

Many SaaS products need file uploads:

Profile pictures
Documents
Reports
Media files

Building uploads yourself takes time and is easy to get wrong.

UploadThing helps you:

Add uploads quickly
Avoid storage and security issues
Keep backend code simple
Focus on product features

How to Get Started (Backend Setup: Next.js / Node.js)

Below is a simple backend setup using Next.js API routes.

1. Create an UploadThing Account

👉 Website: https://uploadthing.com

2. Install the UploadThing SDK

Install UploadThing in your project:

npm install uploadthing

3. Add Environment Variables

Add your UploadThing API key to your environment variables:

UPLOADTHING_SECRET=your_secret_key
UPLOADTHING_APP_ID=your_app_id

4. Create an Upload Router (Backend)

Create a backend upload handler to define what files are allowed.

import { createUploadthing } from "uploadthing/next";

const f = createUploadthing();

export const uploadRouter = {
  fileUploader: f({
    image: { maxFileSize: "2MB" },
    pdf: { maxFileSize: "4MB" },
  }).onUploadComplete(({ file }) => {
    console.log("File uploaded:", file.url);
  }),
};

This controls:

Allowed file types
File size limits
What happens after upload

5. Expose the Upload Endpoint

Export your router so your app can use it.

import { createNextRouteHandler } from "uploadthing/next";
import { uploadRouter } from "./uploadRouter";

export const { GET, POST } =
  createNextRouteHandler({
    router: uploadRouter,
  });

Frontend Configuration (Quick Note)

On the frontend, you’ll:

Use UploadThing’s UI helpers
Connect them to your backend upload route

UploadThing provides ready-made components to make this easy.

👉 Frontend docs: https://docs.uploadthing.com

Official Links

Documentation: https://docs.uploadthing.com
Website: https://uploadthing.com

That's It.🙏

Building a SaaS that grows from MVP to production means choosing tools that scale with you. From authentication and billing to production intelligence and observability, these SDKs help you deliver value faster and more confidently.

If you find this guide useful, please like and share. Someone else building a SaaS might benefit too 💖

Connect with me on X, GitHub, LinkedIn

Kiran NaragundFollow

Tech Writer and Moderator @DEV ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ Open-Source Contributor ✦ Email for Collabs :)

Enterprise AI Code Review in Real World Teams

Kiran Naragund — Thu, 26 Feb 2026 16:06:08 +0000

Hello Devs 👋

If you’ve only worked in small teams, adding AI code review feels almost trivial.

Install a tool.
Connect your repo.
Merge a PR and watch the comments roll in.

That is usually enough to get started.

Enterprise environments are a completely different story.

When you have:

300, 1,000, or even 10,000 developers contributing daily
Dozens or hundreds of repositories with different ownership models
Shared internal libraries that power half the company
Compliance requirements that are audited regularly
Multiple DevOps platforms coexisting across departments

AI review stops being a productivity experiment you try for a sprint.

It becomes an architectural decision that affects how the entire engineering organization works.

Let’s talk about what actually matters from a developer perspective.

What Changes in Enterprise Environments?

As developers, we usually think in very practical terms:

Does this comment actually help me improve the code?
Is this feedback technically accurate?
Is it going to slow me down while I am trying to ship?

At enterprise scale, the questions expand:

Will this behave consistently across all our repositories?
Is our proprietary code safe in the process?
Does this scale without flooding PRs with noise?
Can it enforce standards in a consistent and predictable way?

These are fundamentally different concerns compared to startup level tooling decisions. What works for 15 engineers does not automatically work for 1,500.

Multi Repo Reality

Most large companies are not running a single mono repo.

You will typically see:

A shared SDK repository used by multiple teams
Several microservices owned by different groups
Infrastructure as code repositories
Internal tooling and automation projects

Now imagine this scenario.

You change a shared interface in Repo A. That interface is consumed by 12 services spread across 8 other repositories.

A diff only review inside a single repo will not understand the blast radius. It cannot see how that change might ripple across dependent systems.

This is one of the biggest gaps I have noticed in many AI review tools.

They evaluate the pull request in isolation. Enterprises need tools that understand the system as a whole, not just the file that changed.

Platform Fragmentation Is Real

In large organizations, standardization is often aspirational rather than real. You will frequently find:

Azure DevOps in one department
Bitbucket in another
GitHub for open source initiatives
GitLab in specific regions or subsidiaries

If an AI review tool works well on only one platform, you are left with two uncomfortable options:

Fragment your tooling and accept inconsistent behavior
Force a company wide migration, which is rarely smooth or politically simple

From a developer perspective, consistency matters a lot. You do not want different review logic depending on which repository you happen to be working in that week.

Security and Deployment Constraints

This is where enterprise environments differ the most.

Many companies require:

SOC 2 compliance
On prem deployment options
Air gapped environments
Strict data retention and governance policies

If a tool requires sending proprietary code to an external service without clear controls, security teams will block it immediately.

As developers, we do not always see those conversations happening in the background. But they directly determine which tools we are even allowed to evaluate.

Comparing Tool Categories

Static Analysis Platforms

Example: SonarQube

What it does well:

Security scanning
Detecting code smells
Enforcing coverage thresholds
Providing compliance dashboards

Where it fits:

Baseline quality enforcement
Highly regulated environments

Where it does not help much:

Architectural reasoning
Cross repo impact awareness
Contextual AI style suggestions

It is reliable and predictable, but rule based.

Think of it as a guardrail. It keeps you within boundaries, but it does not actively review your design decisions.

Security Focused Platforms

Example: GitHub Advanced Security

Strong for:

Secret scanning
Dependency vulnerability detection
Improving overall security posture

Limitations:

Deeply centered around GitHub
Primarily focused on security, not full PR workflow
Does not reason about broader architecture

It protects you from known vulnerabilities.
It does not holistically improve pull request quality.

Lightweight AI PR Assistants

Example: CodeRabbit

Pros:

Very quick setup
Clear PR summaries
Useful for smaller, self contained repositories

Cons at scale:

Diff only analysis
Limited contextual awareness
Can become noisy in complex systems
Fewer governance controls

For a 20 developer team, this can be more than enough.

For a 1,000 developer organization with shared dependencies and layered architecture, it often falls short.

Context Aware Enterprise AI Review

Example: Qodo

This category aims to address:

Multi repo indexing
Dependency awareness
Cross repo impact detection
Custom rule enforcement
Flexible deployment models

From a developer standpoint, the real questions are simple:

Does it understand more than just my diff?
Are the suggestions precise and actionable?
Does it reduce back and forth during review?
Do engineers actually accept the suggestions?

If developers ignore the comments, the tool slowly fades into background noise. Adoption is earned, not mandated.

What Developers in Enterprises Actually Care About

When I talk to engineers in large organizations, their concerns are very pragmatic:

Is this going to slow my PR down?
Am I going to waste time dismissing false positives?
Does it understand our internal patterns and conventions?
Will it block my merge for the wrong reasons?

At enterprise scale, trust becomes everything.

A high acceptance rate matters more than impressive sounding AI explanations.

Precision beats volume.

A tool that leaves five accurate comments is more valuable than one that leaves fifty generic ones.

A Simple Enterprise Checklist

If I were evaluating AI code review in a large organization, here is what I would personally verify:

✅ Works consistently across Azure DevOps, Bitbucket, GitHub, and GitLab
✅ Understands multi repo dependencies and shared libraries
✅ Supports cloud, on prem, or air gapped deployment
✅ Demonstrates strong security posture and compliance certifications
✅ Allows custom rules aligned with team specific standards
✅ Shows real developer adoption, not forced usage metrics
✅ Scales beyond 100 developers without overwhelming PRs

If a tool fails two or three of these, it will likely struggle during enterprise rollout.

At the end of the day, AI code review in large organizations is not about adding more comments to pull requests. It is about building a system that developers trust, security teams approve, and architecture teams can rely on long term.

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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ Open-Source Contributor ✦ Email for Collabs :)

Can AI Code Review Actually Improve DORA Metrics?

Kiran Naragund — Thu, 19 Feb 2026 16:01:06 +0000

Hello Devs 👋

We talk a lot about AI speeding up coding.

You’ve probably seen numbers like:

"AI increases developer productivity by 25 to 35 percent."

Honestly that feels true, and multiple surveys and reports do show developers reporting significant boosts in productivity and time saved on routine tasks due to generative AI tooling. For example, large industry surveys show more than 80 percent of developers saying AI improved their individual productivity, and real-world telemetry showing task completion rising significantly with AI assistance.

Autocomplete feels better. Boilerplate goes faster. Refactoring can take fewer keystrokes.

But here’s something I’ve been thinking about lately:

If we are writing code faster, are we reviewing it faster too?

Because if review becomes the bottleneck, DORA metrics won’t improve. They might even get worse.

Let’s break this down in simple terms.

First, What Are DORA Metrics?

The DevOps Research and Assessment program defined four key engineering metrics:

Deployment Frequency
Lead Time for Changes
Change Failure Rate
Time to Restore Service

These metrics basically answer:

How often do you ship?
How long does it take to ship?
How often does it break?
How fast do you fix it?

If AI code review truly helps engineering performance, we should see positive movement across these.

Read more about DORA here 👉 https://getdx.com/blog/dora-metrics

The AI Code Review Paradox

Recent industry data suggests something surprising: teams with high AI adoption often see code review time increase sharply, even as code output rises. In Faros AI’s 2025 data, code review time grew by around ~91 percent as the volume and size of pull requests (PRs) increased.

That raises a question:

Why would review take longer when code is written faster?

Possibilities:

More PRs are being created
Larger diff sizes requiring deeper review
"AI-generated but needs cleanup" code is common
Reviewers double-check AI output carefully given trust concerns

So while coding accelerates, review capacity does not automatically scale to match.

That’s the paradox.

Let’s Connect AI Review to Each DORA Metric

Instead of looking at tools, let’s think logically.

1️⃣ Deployment Frequency

If reviews are faster, PRs merge faster.

If PRs merge faster, deployments can happen more often.

AI review can help by:

Giving instant feedback on PR creation
Catching obvious issues before a human reviewer steps in
Reducing back-and-forth cycles

But this only works if:

The feedback is accurate
Developers trust it

If it’s noisy, it slows things down instead.

2️⃣ Lead Time for Changes

Lead time = commit → production.

Where does most delay happen?

Usually:

Waiting for review
Fixing issues after review
CI failures

If AI review catches issues immediately inside the PR, it can reduce:

Rework cycles
Manual review load
Idle waiting time

Some organizations estimate meaningful time savings per PR when review insights trigger faster fixes, which compounds across a team.

3️⃣ Change Failure Rate

This measures how often deployments lead to failures.

Quality matters here.

Data from several sources shows that larger PRs and heavier reliance on AI-generated content can increase bug rates unless issues are caught before merge. In the Faros dataset, bug rates rose slightly even as output increased.

If review catches high-severity issues earlier:

Fewer production incidents
Fewer hotfixes
Less rollback stress

But false positives or poor insight quality don’t help. High-signal detection does.

4️⃣ Time to Restore Service

This one is indirect.

Better code quality means fewer incidents, and thus less firefighting.

AI alone doesn’t magically accelerate incident resolution, but it can prevent some incidents in the first place, easing the load on on-call teams.

Where Different Tools Fit

Now let’s look at tools categories:

Diff-First AI Review Tools

These look mainly at what changed in the PR.

Examples include lightweight PR assistants and AI summaries.

Pros:

Fast feedback
Easy setup
Helpful for small changes

Cons:

Limited context
Can miss architectural issues
Sometimes noisy

If developers start ignoring comments, DORA does not improve.

Static Analysis Tools

Rule-based analyzers like SonarQube catch security bugs, code smells, and other structural issues.

Pros:

Strong baseline quality checks
Good compliance signals

Cons:

Rule-based rather than contextual
Doesn’t inherently reduce review friction unless integrated deeply

Context-Aware AI Review

More advanced systems tools, like Qodo, try to analyze broader context beyond just the diff.

The idea is:

Understand surrounding files
Recognize patterns in your codebase
Provide more precise suggestions

If precision is high and developers trust it, this can meaningfully reduce review cycles.

If not, it becomes another notification stream to ignore.

What the Data Suggests

Here’s what current reports indicate:

High AI adoption can increase review time if processes don’t adapt, because PR volume and size grow faster than review capacity.
Developers widely report productivity improvements from AI while expressing mixed confidence in AI-generated code.
Survey data shows many developers remain cautious about trusting AI output and often verify it manually.

The key insight for me:

AI code generation alone does not improve DORA metrics.

AI review maturity does.

My Honest Take

If you are:

Writing more code because of AI
Creating more PRs
Increasing review load

Then you need to scale review alongside generation.

Otherwise:

Deployment frequency stalls
Lead time increases
Review fatigue grows

AI code review can improve DORA metrics.

But only if:

It integrates directly into your PR workflow
It provides high-signal feedback
Developers actually trust it

Without trust, metrics don’t move.

And that’s the part most discussions skip.

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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ Open-Source Contributor ✦ Email for Collabs :)

Setting Up AI Code Review in Bitbucket: A Practical Guide and Comparison⚖️

Kiran Naragund — Sun, 15 Feb 2026 06:53:25 +0000

Hello Devs 👋

If your team uses Bitbucket and you’re exploring AI code review tools, you might have noticed that many discussions online focus on GitHub. But Bitbucket is widely used too especially companies deep in the Atlassian ecosystem, and the experience with AI review tools varies a lot depending on platform support.

In this post, we’ll cover:

How tools integrate with Bitbucket
Setup complexity and time to value
Review quality you can expect
A comparison of Qodo, SonarQube, and CodeRabbit

Let’s get started 🚀

Bitbucket + AI Code Review: What You Should Know

Most Bitbucket teams use one of these:

Bitbucket Cloud
Bitbucket Data Center (self-hosted)
Bitbucket Pipelines for CI/CD

A good AI review tool should:

Support Bitbucket Cloud (minimum)
Ideally support Data Center too
Fit directly into your Pull Request workflow

There are usually 2 integration styles:

✅ Native Integration

You install the app from the marketplace, grant workspace access, and it comments directly on PRs using official APIs.

🔁 Webhook / API Setup

You generate tokens, connect via webhook, and the tool listens for PR events.

Both work, but the difference is how much setup and maintenance you deal with.

What I Look For in an AI Review Tool

When evaluating tools for Bitbucket teams, I focused on four things:

🔌 Integration Requirements

How easy is it to connect to Bitbucket Cloud or Data Center?

🧰 Setup Complexity

How long until you get value?
Is there heavy configuration?

🧠 Review Quality

Is the feedback useful?
Is it noisy?
Does it understand context?
Or does it only analyze diffs?

🔁 Ongoing Maintenance

Do I need to constantly tune rules and tokens?

🧩 Qodo: Context-Aware AI Reviews

Qodo supports Bitbucket integration and provides official setup documentation for both Cloud and Data Center.

Integration & Setup

Bitbucket Cloud

Sign in to Qodo.
Install the Bitbucket app.
Grant workspace access.
Select repositories.

That’s it.

Once connected, Qodo starts reviewing pull requests automatically.

Bitbucket Data Center

Upload plugin/app
Configure authentication tokens
Connect repositories

It works well if you’re self-hosted and have admin access.

Bitbucket Pipelines

You can trigger Qodo in CI using Bitbucket Pipelines.

Important:
PR comments come from the app integration, not directly from pipelines.

What You Get

Native PR comments
Multi-repo support
Team-level workflow integration

Review Quality

Qodo builds context from:

Your codebase
PR history
Related files

Not just the diff.

This usually means:

Higher signal
Less random noise
Better architectural feedback

Setup Complexity

Medium.

It’s mostly a one-time setup if you have workspace admin access.

🧩 SonarQube: Static Analysis Inside Bitbucket

SonarQube is a well-known static analysis tool. It integrates cleanly with Bitbucket.

But important thing is:

It’s not AI code review.
It’s static analysis.

Integration & Setup

Install SonarQube (Cloud or self-hosted).
Connect Bitbucket repositories.
Add analysis step in Bitbucket Pipelines.
Configure Quality Gates.

Once configured, it:

Decorates PRs with issues
Fails builds if quality gates fail
Tracks coverage and duplication

Review Quality

Excellent for:

Security scanning
Code smells
Technical debt
Coverage metrics

But it does not:

Reason about architecture
Explain design trade-offs
Provide AI-style improvement suggestions

Setup Complexity

Medium.

You need CI configuration. After that, it runs consistently.

🧩 CodeRabbit: Fast PR Feedback

CodeRabbit supports Bitbucket Cloud and focuses on quick PR reviews.

Integration & Setup

Create a Bitbucket service account.
Generate an API token.
Connect CodeRabbit to workspace.
Webhook is installed automatically.
It starts reviewing PRs right away.

What You Get

PR summaries
Inline comments
Basic customization options

Where It Struggles

CodeRabbit is mostly diff-first.

It focuses on what changed in the PR.
In simple projects, that works well.
In complex systems with interdependencies, it can:
Miss deeper architectural issues
Produce noisy suggestions

Setup Complexity

Low to Medium.

Token + webhook setup takes a few minutes.

Side-by-Side Comparision

Tool	Bitbucket Support	Setup Effort	Review Style	Best For
Qodo	Cloud & Data Center	Medium	Context-aware AI	Larger teams & complex codebases
SonarQube	Cloud & Server	Medium	Static analysis	Compliance & quality gates
CodeRabbit	Cloud	Low-Medium	Diff-first AI	Small teams & quick feedback

🛠 Quick Setup Summary

Qodo + Bitbucket

Install Bitbucket app
Grant workspace access
Select repos
Optional: Add Pipeline triggers
Open PR → Get AI feedback

SonarQube + Bitbucket

Deploy SonarQube
Connect repos
Add Pipeline step
Configure Quality Gates
PRs get decorated with analysis

CodeRabbit + Bitbucket

Create service account
Generate API token
Connect workspace
Webhook installs automatically
PRs get inline feedback

🏁 Final Thoughts

All the three tools bring value. But they solve different problems:

Qodo → deeper, context-aware AI review
SonarQube → strict quality & compliance checks
CodeRabbit → fast, lightweight PR feedback

There’s no single best tool.

The right choice depends on:

Team size
Codebase complexity
How deep you want reviews to go
Whether you need compliance gates

If you’re running serious workloads on Bitbucket, AI review absolutely helps but only if the tool fits your workflow.

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 ✦ Full-Stack Developer ✦ Mentor @Exercism ✦ Open-Source Contributor ✦ Email for Collabs :)