Manual review of 100% code

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.

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.

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

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

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.