Manual PR review → manual merge

Manual PR review with manual merge is the baseline state for most engineering teams.

·PRs require manual human review and manual merge
·Team capacity is approximately 10 PRs per day or fewer

·Basic CD pipeline exists (even if simple or manually triggered)
·Deploy frequency is at least weekly

Evidence

·PR merge history showing manual approvals
·Deploy logs showing manual trigger or simple CD pipeline

What It Is

Manual PR review with manual merge is the baseline state for most engineering teams. A developer opens a pull request, adds reviewers, waits for approval, and then clicks "Merge" themselves. Every step requires a human to initiate it. There is no policy enforcement, no automation, and no queue. The process lives in the heads and habits of the team, not in the tooling.

At L1, this is not just a tooling choice - it reflects an underlying assumption that merging code is an inherently human judgment call. The reviewer reads the diff, forms an opinion, approves or requests changes, and the author merges when satisfied. This model works when PR volume is low (under 10 per day), the team is small, and the codebase is not yet generating AI-assisted contributions at scale.

The hidden cost of this model only becomes visible under load. When a team starts using AI agents to produce code - even just developers using Copilot or Claude Code - PR volume increases faster than review capacity. A team that previously handled 5-8 PRs per day comfortably starts seeing 20-30, and the manual review-and-merge process becomes a wall. Every PR sits in a queue waiting for a human eye and a human click.

This is the state to understand and escape, not to optimize. Improving review quality within a fully manual process is worthwhile, but it does not address the structural bottleneck. The goal is to understand what's manual, why it's manual, and which parts of it need to stay manual (architectural decisions, sensitive changes) versus which parts can be automated (format checks, policy enforcement, routine merges).

Why It Matters

Baseline diagnosis - most teams don't realize how much of their merge process is manual by default rather than by design; mapping it explicitly reveals the automation opportunities
Review bottleneck is the primary constraint - in AI-assisted teams, code production outpaces human review capacity within weeks of adopting agents; the manual merge model is the first thing to break
Inconsistent enforcement - when merge criteria live in people's heads rather than tooling, what gets merged depends on who's reviewing and what day it is; policy drift is invisible
No throughput ceiling visibility - without measuring how many PRs move through the system, teams don't know they've hit a capacity wall until it starts causing delivery delays
Foundation for automation - understanding the current manual process in detail is the prerequisite for automating it; you can't automate what you haven't mapped

Getting Started

Map your current process explicitly - write down every step from "PR opened" to "code in main." Who does what? What triggers each step? Where do PRs wait? How long does each wait typically take? This map will reveal the bottlenecks you didn't know existed.
Measure baseline PR cycle time - use GitHub Insights, LinearB, or a simple script to pull average time from PR open to merged for the last 30 days. Break it down: time to first review, time to approval, time from approval to merge. This is your L1 baseline.
Count PRs per day - how many PRs does your team merge on a typical day? A typical week? Track this number. It will tell you when you've hit the manual process ceiling.
Identify what the reviewers actually check - interview your reviewers: what do they look for? How much of it is mechanical (formatting, naming, test coverage) versus judgment (architecture, correctness, security)? The mechanical checks are automation candidates.
Define your merge criteria explicitly - write down what "approved and ready to merge" actually means for your team. This is the first step toward codifying it as policy. Even a simple checklist (CI passes, one approval, no unresolved comments) is progress.
Pick one manual step to eliminate - don't try to automate everything at once. Start with the most mechanical step: for most teams, this is "wait for CI to pass before merging." Add a branch protection rule that requires CI green before the merge button is enabled.

6 steps to get from here to the next level

Common Pitfalls

Treating all review as equally valuable. Not all code review is equal. A senior engineer spending 45 minutes reviewing a CSS tweak is waste. An architect spending 5 minutes on a schema migration is leverage. Manual review processes tend to apply the same process to every PR regardless of risk, which burns senior time on low-risk changes and sometimes glosses over high-risk ones. Segmenting PRs by risk level is a necessary precursor to any automation.

Assuming the bottleneck is review quality. Teams at L1 often focus on improving review quality (better checklists, more thorough comments) when the real problem is review throughput. When AI agents produce 20 PRs per day and human reviewers can handle 10, the queue grows regardless of how good the reviews are. Quality improvements don't fix capacity problems.

No visibility into the queue. PRs waiting for review are often invisible. There's no dashboard, no SLA, no alert when a PR has been waiting more than 4 hours. Without visibility, the queue grows silently until someone notices a feature hasn't shipped in two weeks.

Merging manually without a consistent strategy. Some developers merge with squash, some with rebase, some with merge commits. Inconsistent merge strategies produce a noisy git history that makes debugging, bisecting, and reverting harder. This is a small friction at L1 but compounds significantly as volume grows.

Blocking on review for mechanical changes. When a PR is blocked waiting for review but it only touches formatting, test fixtures, or dependency versions, the wait is pure waste. At L1, teams don't have the policy machinery to route these PRs differently, so everything waits in the same queue. Recognizing these patterns now sets up the segmentation you'll need at L2.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team has been using GitHub Copilot for three months and PR volume has quietly doubled. His team lead mentioned that the review queue is "getting a bit long" but hasn't escalated it as a formal problem. Bob's instinct is to add another senior reviewer to the rotation, which would address the symptom but not the cause.

What Bob should do: Bob needs to look at the data before adding headcount to the review queue. He should pull 30-day PR cycle time broken down by stage. If the bottleneck is "time from first review to merge," the problem is throughput, not quality, and the solution is automation, not more reviewers. Bob should use this analysis to frame the L2 investment: a merge queue and basic branch protection rules will do more for delivery velocity than another reviewer in the rotation. The data makes the case for automation credibly.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has been tracking developer satisfaction and sees friction appearing in standup notes: "waiting on review," "PR has been sitting for two days," "merged stale code by mistake." These are symptoms of a manual process under load, but they're scattered across many retros and hard to aggregate into a single narrative.

What Sarah should do: Sarah should set up a simple PR cycle time dashboard - GitHub's built-in Insights view or a free tier of LinearB will show average time-to-merge. Then she should present the trend line to the team: "Our average PR takes X hours to merge and that number is going up." This creates shared visibility and a concrete improvement target. The next step is to identify the single biggest time sink (almost certainly "time waiting for first review") and design a lightweight intervention: a Slack notification when PRs are older than 4 hours with no review, or a daily digest of open PRs. These don't require tooling changes and can be operational within a week.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor already knows the review queue is broken. He's the one being pinged to review PRs at 4pm when he's deep in a coding session, and he's frustrated that 60% of what he reviews is mechanical - formatting issues, missing test cases, wrong variable names - things that should never reach him. He wants to fix it but doesn't have organizational buy-in.

What Victor should do: Victor should build the case empirically. He should keep a tally for one week of what fraction of his reviews catch non-mechanical issues versus mechanical ones. If it's 60-70% mechanical (typical at L1), that data justifies a proposal to automate those checks via CI before PRs reach the review queue. Victor should draft a branch protection rule proposal and a simple linting pipeline addition, then present it as "I want to spend my review time on architectural issues, not formatting - here's how we do that." This reframes automation as respect for senior engineering time, which is the most effective argument at most organizations.

What Victor should do - role-specific action plan