developmentL1 Ad-hocCode Review & Quality

Manual review of 100% code

Why relying entirely on human code review creates a quality bottleneck that scales poorly and establishes the baseline every higher maturity level is designed to escape.

·All code is reviewed by a human before merge
·No automated review tooling beyond basic CI checks

·Code review turnaround is tracked (even if slow)
·Team is aware that AI-generated code has higher defect rates (1.7x issues, 2.74x security vulnerabilities)

Evidence

·PR approval records showing human reviewer on every merged PR
·Average review turnaround time in PR analytics

What It Is

Manual review of 100% of code is the baseline state for most engineering teams - every line merged to the main branch has been read and approved by at least one human reviewer. There is no automated quality gate beyond perhaps a basic linter, no AI reviewer, and no policy for selectively skipping or accelerating review based on change risk. Every pull request, regardless of size or complexity, waits in the same queue.

At L1 (Ad-hoc), this process is entirely dependent on reviewer availability and attention. A two-line config change waits behind a 400-line feature PR. A reviewer who is in meetings all morning becomes a bottleneck for three developers. The quality of review varies enormously: a tired reviewer at 5pm catches fewer bugs than the same reviewer fresh at 10am, but the process treats both reviews as equivalent.

The L1 review process typically has no documented standards. What one reviewer calls "bad naming" another ignores. Architecture decisions are enforced through review comments, which means they're only enforced when the reviewer knows about them and has time to write a comment. New team members learn standards from reviewer feedback, which is inconsistent by nature.

This is not a criticism of L1 teams - manual review is where every team starts, and it provides genuine value. Human reviewers catch business logic errors, subtle security issues, and design problems that automated tools still miss. The problem is that 100% manual review doesn't scale. As team size grows, review demand grows linearly while review capacity grows slowly. The bottleneck becomes structural.

Why It Matters

Understanding the limitations of L1 review is essential context for why the maturity matrix progresses the way it does. Every higher level is specifically designed to reduce review burden without sacrificing quality:

L2 introduces AI-assisted review suggestions and linting, so reviewers spend less time on obvious issues
L3 deploys an AI agent as a first-pass reviewer that handles routine checks automatically
L4 introduces auto-merge for Green-rated changes, removing human review from the critical path entirely
L5 has humans review only architectural exceptions - the rare Red cases

At L1, the review bottleneck has compounding costs beyond just wait time. Developers who submit PRs and wait hours for feedback context-switch to other work. When review comments eventually arrive, they have to reload the mental context of the PR, costing additional time. Meanwhile, other PRs have been merged to the branch they branched from, creating merge conflicts that require additional work to resolve.

The other significant cost of L1 is inconsistency. Without automated enforcement, standards exist only in reviewers' heads. This creates two failure modes: (1) important standards are missed in review, allowing problems into the codebase, and (2) reviewers over-enforce personal preferences, creating friction without quality benefit.

Tip

Measure your average PR review turnaround time now, before introducing any AI tooling. This baseline makes it possible to demonstrate the concrete improvement that comes from L2 and L3 investments. Even a rough estimate (median hours from "review requested" to "first review") is more useful than no data.

Getting Started

Moving away from 100% manual review is a gradual process. The first steps don't require AI at all:

Measure your baseline - Track the average time from PR creation to first review and from first review to merge. These are your two most important L1 metrics. Tools like LinearB, DX, or even a simple spreadsheet can capture this.
Size your PRs deliberately - Establish a team norm that PRs should be under 400 lines of changed code. Smaller PRs are reviewed faster, get more thorough review, and have fewer merge conflicts. This alone often cuts review time in half.
Separate trivial from substantive changes - Identify what categories of changes genuinely need thorough review (new features, security-sensitive code, data migrations) versus what is genuinely low-risk (documentation updates, dependency version bumps, config tweaks). Treat them differently.
Establish reviewer rotation - If review requests always go to the same senior developers, they become the bottleneck. Distribute review load more evenly and use senior reviewers for architectural decisions specifically.
Document your standards - Even before introducing AI tooling, write down the things reviewers repeatedly comment about. This is the seed of your CLAUDE.md or .cursorrules file, and it makes AI-assisted review at L2 dramatically more effective.
Introduce a basic linter - Even a default ESLint or Pylint configuration, with CI enforcement, removes the lowest-value review comments (formatting, unused imports, obvious style issues) immediately. This is the first step toward L2.

6 steps to get from here to the next level

Common Pitfalls

Treating all PRs as equal. A 2-line bug fix and a 600-line feature implementation are not equal risk. At L1, both go through the same review process. This wastes reviewer attention on trivial changes while potentially giving complex changes insufficient scrutiny because reviewers are fatigued or rushing.

Allowing review to be the only quality gate. If the only check before merge is human review, then everything that slips past reviewers ships. There are no automated checks catching the class of issues that automation is better at than humans: consistent formatting, obvious null pointer dereferences, failing tests, import cycles.

No standards documentation. Review quality depends entirely on what the reviewer happens to know and care about. Two reviewers will give dramatically different feedback on the same PR. This creates unpredictable quality and breeds frustration when developers get conflicting feedback from different reviewers.

Reviewer overload from not scaling. As the team grows, new developers submit more PRs but the pool of senior reviewers grows slowly. Senior engineers end up spending 2-3 hours per day reviewing code instead of designing or building. This is a real career and retention issue, not just a throughput issue.

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

How Different Roles See It

BobHead of Engineering

Bob's team of 50 engineers has a review SLA of "24 hours," but in practice PRs often wait 2-3 days. Senior engineers complain about review load. Junior developers complain about slow feedback. Deployment frequency is limited because code sits in review queues rather than flowing to production.

What Bob should do: Bob needs to recognize that 100% manual review is a structural problem, not a process discipline problem. Telling engineers to "review faster" or "submit smaller PRs" is a band-aid. Bob's real move is to invest in tools that reduce review burden: a shared linter configuration (this week, free), then an AI review tool like CodeRabbit or GitHub Copilot Reviews (this month). The goal is not to eliminate human review - it's to make human reviewers faster and more effective by handling the routine checks automatically. Bob should present this as "enabling senior engineers to do higher-value work" rather than "replacing review," because that's accurate.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah is tracking PR cycle time as part of her developer productivity metrics. The data shows that the median PR spends 18 hours in review before merging. Her dashboard shows this is the single biggest contributor to long cycle times. Her stakeholders want to know what she's going to do about it.

What Sarah should do: The 18-hour review time is a solvable problem, but not by adding more reviewers. The solution is reducing the review surface area through automation. Sarah should propose a two-step investment: (1) deploy a shared linter configuration with CI enforcement, which eliminates style-related review comments immediately, and (2) trial an AI review tool (CodeRabbit has a free tier) on one team for 30 days. The expected outcome is a 30-50% reduction in review time for that team. If that experiment succeeds, Sarah has the business case to roll out to all teams.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has been the primary reviewer for 60-70% of the team's PRs because he's the one who knows the codebase best. He's spending 3 hours a day reviewing code and is frustrated that he can't make progress on his own architectural work. He's seen AI review tools mentioned in conference talks but doesn't know which ones are worth the time to evaluate.

What Victor should do: Victor should immediately evaluate CodeRabbit or GitHub Copilot Reviews by enabling one of them on the repository. The specific tool matters less than getting the data: does an AI first pass catch the kinds of issues Victor is currently catching? If the AI handles 60% of what Victor would have commented on, that's 60% less time in review. Victor should also recognize that being the only reviewer for 70% of PRs is a bus-factor problem - the solution isn't to review faster, it's to document the standards he's applying so that other reviewers (human and AI) can apply them consistently.

What Victor should do - role-specific action plan