What is a pull request & why is it important for code reviews?

Pull requests are a core part of software development as it stands today. But are they still going to be three years from now?

Initially, pull requests were a way to protect source code. That's still true, but now the trust part of that is even higher as teams move agentic. On most engineering teams right now, PR cycle times are getting longer and longer as the backlog of PRs written by AI coding agents grows.

A good PR process helps you scale speed and trust at the same time. The only problem: a "traditional" PR system no longer allows this to happen.

So what are pull requests, why does your team (still) need them, and what should they look like moving forward? We'll get into all of that, just keep scrolling.

What is a pull request?

A pull request (PR) is a request for someone on your team to pull, or adopt, your code changes made on a branch into the main branch or codebase.

"Pull requests" is the term standardized by GitHub (Bitbucket also uses this term). They're also sometimes called merge requests (i.e., on GitLab). In general, they work like this:

• A developer opens a ticket or a feature request or similar to work on.
• The developer creates a "branch," or a separate copy of the relevant code to work on without making immediate changes to the source code.
• Changes are saved to that branch.
• The developer who made the changes submits a pull request on the source code management platform (i.e., GitHub, Bitbucket)
• Another team member, such as a senior developer or a project manager, will perform a code review, leave comments for changes, and eventually approve the pull request.
• When the PR is approved, the new code is adopted (or merged) into the source code.

Push vs. pull request

The difference between a push and a pull request can be confusing, as these terms are both used when moving commits. Why is it called a pull request when you're pushing your changes to the cloud?

A pull request is a request for another developer to pull your code changes into the main codebase.

A push (especially in the Git universe, i.e. the git push command) allows you to push your code from your local repo to the cloud or a remote server.

Basically, you first push your commit to the cloud, where it updates the branch history and shares your commit with your team. Then, you submit a pull request to request those pushed changes be pulled, or merged, into the main branch.

Traditional PR process vs. agentic PRs

As AI becomes more a part of the SDLC, many engineering teams are also realizing they need to shift from a traditional PR process to an agentic pull request process. Here's what that looks like:

The traditional PR process is very developer-led, and not very scalable. It's high-trust, but low-velocity, and requires lots of hands-on work from developers.

The problem now is that pull requests are becoming a bottleneck. As AI writes code faster than ever, pairing that with a traditional PR process stifles the velocity that AI coding creates. Many engineering leaders are already seeing this in long PR cycle times.

An agentic PR process lets you continue to scale. However, agentic PR processes can reduce trust and security of your codebase if it's not handled well. For example, one common problem is having the same AI model coding and reviewing that code.

It seems obvious when written out, but having the same agent code and reviewing that code is an example of a fox guarding the henhouse. You don't have the same developer code and then approve that pull request (it's why pull requests exist in the first place!) So you shouldn't let an AI model do so either.

A good agentic PR process includes multiple models, one that codes, one that reviews, and ideally, an agent that can read, learn, and understand your entire codebase like your team does. That's how you actually scale and create an agentic process that scales velocity and trust.

How to create a pull request

How to create a pull request varies depending on the source code management tool you're using (i.e. GitLab, Bitbucket, etc.). In general, the process is something like:

1. Push your commit to the cloud.
2. Find and click the "new pull request" (or similar) button.
3. Select the source branch (where you wrote your new code) and the destination branch (where you want your code to be pulled into).
4. Set a title and description for your pull request: that is, explain what changes you made and why.
5. Then, click "Create pull request." In some cases, you might also need to manually assign a reviewer as well.

The exact steps vary depending on your source code management tool, but general best practices for managing pull requests within an engineering team are relatively standard:

• Set and follow standard naming conventions for each branch. For example, at Greptile, we use {first_name}/{branch-name}. But the exact naming convention is less important than making sure everyone is using the same conventions. Set your own, document them, and enforce them.
• Enforce a standard PR template. Your PR should serve as a change log documentation for your code, not just a generic "fixed bug" comment. A good PR template includes the type of change (i.e., new feature, bug fix, etc.), a description of what was changed and why, a link to the original ticket, a description of any testing done, and any risks.
• Get a green light from automated CI/CD testing before creating a PR. Your team should never be pushing PRs that haven't passed a linter, CI/CD testing, automated security scans, etc. Human reviewers should not be wasting time fixing style issues. Use an automated code checker for that, then push the PR once the automated code review is clean.
• Create a system for what needs to be reviewed and how. A clean system or code review checklist ensures quality across the board without wasting your dev team's time on unnecessarily thorough reviews. Keep a system in place for review comments, too, with labels for critical comments vs. nits.
• Keep PRs small when possible. A general rule of thumb is to keep a single PR to around 200-400 (or less) lines of change. This makes it easier to review thoroughly and keep your development process moving. We've found (counterintuitively) that while larger PRs tend to get merged faster, that's likely the result of teams getting lazier with larger PRs and/or large PRs needing more critical, urgent review (i.e., higher decay speed, increased blockers).

Benefits of pull requests

Pull requests are beneficial for a number of reasons, most importantly:

• Pull requests improve code quality. By implementing PRs, your team has a clear process for finding and fixing bugs, errors, style flaws, and so on early, before code hits production and while it's still easy to fix.
• Protects the source code. By branching code to edit and pulling it back once approved, you improve source code management and quality, keeping potential errors and clunky changes out of your source code while devs are working.
• Introduce automated testing and checks. Automated code review tools can help find and catch bugs, style issues, and security flaws before a merge, protecting source code and improving quality, while also saving your team time.
• Improve collaboration and codebase understanding. PRs create a record of changes (and why they were made) and give your team a chance to discuss, collaborate, and develop best practices for your codebase. Plus, new hires can review old PRs to better understand your codebase and why changes have been made.

The problem is that retaining these benefits in an age of agentic or AI coding often creates one of two problems:

1. PRs create a bottleneck, with human reviewers (time consuming and costly) slowing down the velocity of AI-written code, or
2. You scale velocity with AI code review, but lose trust in your codebase as lots of common AI code errors get missed and sneak through to prod

So, how do you automate pull requests in a way that avoids both of these issues?

How to automate pull requests

In 2026, code is no longer the bottleneck for most engineering teams: pull requests are. For example: at Atlassian, a team with over 6,000 engineers, coding is now roughly just 15% of how they spend their time; the rest of their time is spent on new bottlenecks: including validation and review. [1]

The solution isn't to get rid of pull requests, nor is it to waste your entire team's time spending all day reviewing PRs. Instead, you need to automate pull requests in a way that builds both trust and velocity.

1. Start with automated review. Standard automated pull request tools, like linters, static analysis, and SAST tools can run automatically at the pull request stage. Your team can set up rules for what tests have to run and pass before a PR can be merged.
2. Turn on auto-merge for low-risk PRs. Developers can turn on auto-merge in GitHub, allowing a PR to automatically merge once CI testing has run and passed. That is: if your linters and automated testing tools fix (or don't find any) major errors, the PR will auto-merge into the main branch.
3. Implement automated AI code review for agentic PRs. AI code review agents, like Greptile, help automate validation and provide a layer of independent review for human- and AI-written code. These can run automatically once a PR is opened, leaving comments and suggestions, or even implementing auto-fixes alongside your coding agents. This gives PRs a first-pass before a human developer has to get involved.
4. Use greplooping. Greplooping allows Greptile to work directly with your coding agent to review, iterate, and fix PRs until it hits a 5/5 confidence score and is ready to merge. At that point, it may just need a quick review from a senior dev before merging, saving your team time while still documenting context, issues, changes, and rationale.

The future of pull requests for engineering teams

As engineering constraints shift, so do the responsibilities of engineering leadership. The challenge is no longer just speeding up coding, but designing engineering systems that allow velocity and trust to scale together.

Consider the data:

• Teams using coding agents merge five times more pull requests each week compared to teams who don't. [2]
• The share of AI agent-generated changes reaching commits without manual review has increased more than 5x since the start of 2026. [3]
• But AI-generated and reviewed code is brittle: A review of 300,000+ AI-generated commits tracked across 6,000+ repos found 105,364 AI-introduced bugs still unresolved in production codebases. [4]

And these bugs have real consequences. At Amazon, for example, an AI agent directed an engineer to an outdated wiki, contributing to a six-hour production outage that led to over 6.3 million lost orders, which cost an estimated $150 million in lost revenue [5].

Teams who scale without scaling trust are getting backed into brittle, complex codebases that are becoming more and more costly to fix and validate.

The faster code scales, the more important pull requests (or some form of repeated, systemized code review) become.

But once you start automating your pull requests, how do you make sure you're still running a PR and code review workflow that scales trust and speed?

Best practices for PR workflows in an agentic era

• Score PRs automatically based on the level of review needed: route developer attention to the changes that actually need it
• Find ways to avoid review fatigue: cut the noise so critical comments don't get ignored
• Make sure AI tools have context: give reviewers your whole codebase, not just the diff
• Codify judgment, not just patterned rules: capture what your team knows, not only what a linter can check
• Catch bugs that don't show up in the diff by running sandbox testing: run the code, don't just read it

The best practices for PRs today double down on the importance of code review without losing velocity. Things like:

Score PRs automatically based on the level of review needed

The team at Coinbase solved for this by scoring every PR against a security risk framework. This analyzes whether an agent can approve it alone, whether it needs a human review, or even multiple human reviewers. [6]

This practice ensures that all code is reviewed with the level of scrutiny it actually needs: preventing wasted time on low-risk changes, while protecting the integrity of your codebase. In short: you route developer attention to where it's needed the most.

Find ways to avoid review fatigue

One of the biggest issues with most automated code review tools is noise.

Without context or a sense of what's relevant to your team, code checkers find every possible or potential error, leaving a trail of irrelevant comments for your devs, who eventually start ignoring all of it, missing critical errors in the process. Instead, set up and adjust your code review tools to:

• Surface only actionable reviews. For example, security testing tools shouldn't find every possible security error, but only the ones that are actually reachable in prod.

• Assign PRs to relevant reviewers. Assigning PRs automatically to the most relevant reviewer (i.e., based on ownership, knowledge, availability, time zone, etc.) can reduce fatigue while distributing workloads more evenly as a result.

  Uber has done this with their Code Inbox tool. [7] Code Inbox routes PRs intelligently, by surfacing actionable reviews and assigning them to the most relevant reviewer. It also creates a Risk Profile of each change and routes PRs accordingly, making sure the riskier changes are routed directly to the right developer for review.

• Eliminate or reduce noise whenever possible. Set up custom rules for your code review tools based on your codebase, don't just use the defaults. Use "low noise" settings when possible. Find tools that will flag and rank errors based on importance so that your team can filter by critical and must-fix issues.

• Use code review tools that actually learn your codebase. Generic code review suggestions are going to create a lot of noise and eventually get ignored. Code review tools (like Greptile) that actually learn your codebase, create a full index, and understand how your code works together surface more bugs, and more importantly, more relevant bugs. Greptile also learns from your team: watching and codifying what you change, what you comment on, how you implement fixes, and more to create stronger reviews that match how your team works.

Make sure AI tools have context

Context is absolutely crucial within an agentic process to improve the PR cycle. If you're using AI tools to do code review or review PRs, you need to be giving them context on your codebase.

If you don't, tools will spit back generic suggestions, lots of irrelevant reviews, and create lots of noise, leading to review fatigue and eventually getting ignored by your team. Context, on the other hand, allows AI code reviewers to:

• Understand how a proposed change would work with your entire codebase, not just the branched code (preventing AI code that breaks something else in your codebase in the process).
• Only surface critical changes. For example, a security issue that's unreachable in prod code doesn't need to be commented on.
• Avoid commenting on style changes or best practices that aren't in line with how your team works or your specific codebase.

Codify judgment, not just patterned rules

Judgment is the key piece of pull requests today, not just a pattern of rules. Most linters and static analysis tools can do a great job of implementing rules. Style issues, formatting errors, validated inputs: all of that can and should be caught by a machine.

Instead, you need to codify your team's knowledge and judgment around your codebase, things like which files are fragile, which patterns are likely to break, where your known vulnerabilities are. Codifying this kind of judgment within an AI tool gives your team speed and velocity without losing the knowledge and trust that comes with a code review by a senior dev.

As Linear's Head of Product Nan Yu put it, the right shape for this is less a static document and something closer to agent memory, a running catalog of patterns and intentions, with a clear trigger to escalate to a human reviewer when something genuinely new shows up. [8]

This is exactly how we've built Greptile. It builds a full index of your repo, and continues with rules learned over time, house standards learned from your team, and the ability to consider the intent behind a change (not just what the diff does). Greptile pays attention to your reactions, tags, and what gets merged to learn your team and your judgment. This way, code reviews get faster and more relevant over time.

Catch bugs that don't show up in the diff by running sandbox testing

An agentic PR process needs to mirror (and improve) the traditional pull request process. That is: human reviewers don't just read the diff, they actually test and run code to catch errors that only show up at runtime.

An AI code reviewer should do the same.

That's why we built Greptile with TREX. TREX spins up a sandbox for each PR it reviews, running and testing code in a sandbox environment to catch runtime errors that can't be found by tools just reading the diff. Then it gives your devs screenshots, logs, scripts, videos, and more so they can quickly review and understand exactly what happened and what errors occurred (and how to fix them).

Maintaining understanding as you automate PRs is crucial

Automating more of your code review and PR process is crucial if you want to scale speed and velocity. But for strong, trustworthy codebases that are maintainable in the long run, you can't automate away understanding.

As Moshe Sambol, VP of customer solutions at Lightrun, told American Banker [9]:

Automating PRs with AI code review requires documentation and evidence of how the system works together, not just if the code works. AI code review needs to generate artifacts to give developers and reviewers understanding, and quickly.

This is another reason why Greptile's TREX is a crucial element for modern code review. A person or downstream agent can look at exactly what happened and confirm it. That's how you maintain understanding and mental models of your codebase on your team without having to write every line of code by hand.

The agentic era calls for rethinking traditional pull request workflows

It's clear that traditional pull request and code review workflows are due for a change:

• PR cycles are getting longer. Agentic coding isn't saving developers time, it's just shifting their bottlenecks from coding to reviewing.
• The traditional PR process is no longer an easy way to maintain code quality and workflow speed.
• Humans aren't the only ones writing code, so they can't be the only ones reviewing it either. The speed of AI code needs to be matched by AI code review, or else your PR cycle times are only going to continue to lengthen.
• Engineering leadership has to shift the focus and incentives: velocity and trust need to be scaled together.

The way all of this comes together is with AI code review and PR tools that will support an agentic workflow and improve your PR cycle times, while shipping code you can trust.

Greptile is one way to do this. Use Greptile during the PR process, or use it directly within your CLI: either way, you get the benefits. With Greptile, teams are able to scale speed and trust:

• Podium reviews 8,400+ code changes a week faster and more effectively, with Greptile catching everything from critical configuration issues to easy-to-miss human errors that would have caused confusion down the line.
• Vouch reduced review time by 85% while still improving their overall codebase quality.
• Gumloop relies on Greptile's "auto-fix" feature to review and ship 15k+ PRs while still maintaining rapid development cycles.

Whether you're an enterprise team like Podium, a growing, medium-sized team with a complex monorepo, like Vouch, or a small, fast-moving team like Gumloop, Greptile can learn your codebase and your team and help you future-proof your pull request process.

See how Greptile will work for your team today →

Footnotes:

[1] Taroon Mandhana, Chris Kasten, and Ryan Sokol. "How Intuit, DoorDash, and Atlassian are adopting AI coding." Cursor Compile '26, June 2026.

[2] Linear pull request data via Gergely Orosz, "Slow Down to Speed Up," The Pragmatic Engineer, June 2026. newsletter.pragmaticengineer.com/p/slow-down-to-speed-up

[3] Cursor unsupervised commit data. cursor.com/insights

[4] Liu, Y., Widyasari, R., Zhao, Y., Irsan, I.C., Chen, J., and Lo, D. "Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild." arXiv:2603.28592, April 2026. arxiv.org/abs/2603.28592

[5] Greptile report analyzing Amazon revenue estimate based on Q1 2025 online stores segment revenue ($57.4B ÷ 90 days ÷ 24 hours × 6 hours). Amazon Q1 2025 earnings release. ir.aboutamazon.com/news-release/news-release-details/2026/Amazon-com-Announces-Fourth-Quarter-Results/

[6] Greptile report citing Chintan Turakhia. Interview conducted by Daksh Gupta, Greptile, 2026.

[7] Greptile report, "Software Validation for AI-Augmented Engineering Teams," 2026.

[8] Nan Yu, Head of Product, Linear. x.com/thenanyu/status/2081121226265633159

[9] Moshe Sambol, Vice President of Customer Solutions, Lightrun, quoted in American Banker. americanbanker.com/news/pressure-fomo-some-big-banks-are-rolling-ai-out-too-fast