Manual PR review → manual merge

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

• 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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.