Chapter 19: Critique: Google’s Code Review Tool
seg tooling code-review critique developer-tools static-analysis
Status: Notes complete
Overview
Chapter 19 examines Critique, Google’s internal code review tool, as a case study in how tooling can either amplify or undermine engineering process at scale. The chapter bridges the conceptual coverage of code review in Chapter 9 and the practical tooling reality that makes those concepts work across tens of thousands of engineers.
The central thesis is that a code review tool is not a neutral medium — its design choices actively shape review behavior. A tool that surfaces the right information at the right time, integrates tightly with automated analysis, and reduces noise in notifications produces better reviews. A tool that buries context, separates analysis from review, or floods reviewers with low-signal notifications produces worse ones. Critique’s design is therefore not incidental; every major design decision embodies an opinion about what good code review looks like.
The chapter also highlights Critique’s deep integration with the rest of Google’s developer infrastructure: the build system (Blaze), the static analysis platform (Tricorder), the presubmit infrastructure, and the code search tool (Kythe/CodeSearch). This tight coupling is itself a lesson — code review tools that operate in isolation from the rest of the developer toolchain miss most of their potential value.
Core Concepts
Critique: Google’s internal web-based code review tool, used for reviewing Change Lists (CLs) before they are submitted to the main repository. Critique manages the entire CL lifecycle from creation through submission.
Change List (CL): A proposed code change submitted for review. The unit of work in Google’s review process.
LGTM (Looks Good To Me): The approval signal a reviewer sends to indicate that they are satisfied with a CL’s correctness and design.
Approval scoring: The compound review state a CL must achieve before it can be submitted — requires LGTM, owner approval, and readability approval from appropriately certified reviewers.
Tricorder: Google’s static analysis platform. Runs a broad set of analyzers on CLs and surfaces results directly inside Critique, so reviewers see automated analysis findings alongside human comments.
Presubmit checks: Automated checks (style, tests, analysis) that run before a CL is sent to human reviewers, catching mechanical issues without consuming reviewer time.
Code Review Tooling Principles
The chapter opens by asking what properties a code review tool should have. Google’s experience with Critique — and with the tools it replaced — identifies several non-negotiable qualities:
What Makes a Good Code Review Tool
| Property | Why It Matters |
|---|---|
| Tight integration with analysis | Automated findings surfaced in the review context catch issues without extra steps; separated tools get ignored |
| Low-noise notifications | Review tools that over-notify train reviewers to ignore notifications; signal-to-noise ratio is critical |
| Clear review state | Both author and reviewer must always know the current state of a CL — who has the ball |
| Context-preserving diffing | The diff must show enough surrounding code for reviewers to understand changes in context |
| Fast and responsive UX | Slow tools create friction that reduces review quality; reviewers rushed by slow tools do shallower reviews |
| Inline commenting | Comments must be anchored to specific lines; floating comments lose context and create confusion |
| History and audit trail | Every comment, revision, and approval must be permanently recorded for accountability and future reference |
The overriding principle is that the tool must make code review faster and more thorough simultaneously — these are not in tension if the design is right. Friction that does not produce quality improvement is pure waste.
The End-to-End Code Review Flow in Critique
Critique structures the review process as a series of distinct stages. The chapter covers each stage’s mechanics and design rationale.
Stage 1: Create a Change
When an author creates a CL, Critique immediately performs several functions:
Diffing and rendering: Critique computes and displays a diff of the change against the base revision. The diff renderer is designed to give reviewers enough context — showing surrounding unchanged lines — to understand the change without requiring them to navigate to the file. Reviewers can switch between side-by-side and unified diff views.
Analysis results surface immediately: Tricorder and other automated analyzers run on the change as soon as it is created. Their findings appear in the diff view at the relevant lines, not in a separate report. This is a deliberate UX decision: if analysis results are separated from the review UI, reviewers must context-switch to read them and then mentally map findings back to the code. Inline surfacing eliminates this friction.
Tight tool integration at creation time: The build system reports whether the change compiles and whether existing tests pass. This information is visible to the author before they even request review, creating a natural checkpoint. Sending a CL for review that fails to compile is considered a norm violation — Critique’s UI makes it hard to do accidentally.
Suggested fixes: For analysis findings that have clear automated remediations, Critique surfaces one-click suggested fixes directly in the diff. This dramatically reduces the cost of acting on analysis findings — the reviewer or author does not need to figure out the fix; they simply approve it.
Stage 2: Request Review
After creating the CL, the author selects reviewers. Critique provides tooling to assist with reviewer selection:
- Ownership-based suggestions: The tool analyzes the files changed and suggests reviewers based on code ownership declarations (OWNERS files). This removes the cognitive load of knowing who to ask.
- Reviewer load balancing: The system can indicate reviewer workload, helping authors avoid piling reviews onto already-overloaded engineers.
- CC and optional reviewers: Authors can CC additional engineers who should be aware of the change without being required to approve it.
Once reviewers are requested, Critique transitions into a state tracking mode — making it clear to all parties whose turn it is.
Stages 3 and 4: Understanding and Commenting on a Change
The review interaction is the heart of Critique’s UX. Design decisions here have the highest leverage on review quality.
Commenting UX: All comments are inline — anchored to specific lines in the diff. Critique distinguishes between:
- Draft comments: Comments the reviewer has written but not yet published. This allows a reviewer to compose a full set of comments before sending them all at once, rather than sending one comment at a time and notifying the author repeatedly.
- Published comments: Visible to all parties. Once published, comments enter the review record permanently.
The draft comment model is significant: it means the author receives one coherent batch of feedback per review round rather than a stream of individual pings. This reduces the author’s context-switching cost substantially.
Understanding state: Critique maintains explicit review state for every reviewer on a CL:
- Unreviewed: Reviewer has not yet engaged
- Reviewing: Reviewer has the CL open and is actively working through it
- Reviewed: Reviewer has completed their pass
This state is visible to the author. If a reviewer has been in “Reviewing” state for a long time without posting comments, the author can see this and potentially follow up. The visibility of state is itself a social accountability mechanism.
Navigating a large CL: For CLs that touch many files, Critique provides file tree navigation, filtering by comment state (files with unresolved comments, files not yet reviewed), and the ability to mark individual files as reviewed. This allows reviewers to work through large CLs systematically without losing their place.
Resolving vs. acknowledging comments: Authors can mark reviewer comments as:
- Done: The change was made
- Acknowledged: The comment was noted but no change was made (with explanation)
This closing the loop mechanism ensures comments do not silently accumulate without response.
Stage 5: Change Approvals — Scoring a Change
Critique implements Google’s three-gate approval system (introduced in Chapter 9) as explicit review state:
| Approval Gate | Signal | Who Can Grant It |
|---|---|---|
| LGTM | Correctness and design look good | Any reviewer with familiarity with the code |
| Owner approval | Change is appropriate for this codebase | A designated OWNER of the affected code paths |
| Readability approval | Code follows idiomatic language conventions | An engineer certified in language readability |
Critique makes the current approval state of a CL explicit and visible at all times — a dashboard-style summary shows which approvals have been granted and which are still needed. Neither the author nor any reviewer needs to mentally track approval status; the tool maintains it.
Combined approvals: A single reviewer may satisfy multiple approval gates. A code owner who also has readability certification for the language can provide both owner approval and readability approval with a single LGTM. Critique tracks this automatically based on the reviewer’s certifications and ownership declarations.
Approval withdrawal: If the author makes significant changes after an LGTM is granted, the LGTM is automatically retracted, requiring re-review. This prevents a common anti-pattern where an author makes a “small fix” after receiving approval without the reviewer seeing the updated change.
Stage 6: Committing a Change
Once all required approvals are in place and all presubmit checks pass, the CL can be submitted (committed to the repository). Critique’s submit flow includes:
Final presubmit gate: Immediately before submission, Critique runs a final round of automated checks. This catches cases where checks that passed earlier have since been broken by other changes in the repository.
Post-commit tracking: After submission, Critique retains the full record of the CL — all comments, all revisions, all approval signals, and the final submitted diff. This permanent record serves several purposes:
- Debugging: Engineers investigating regressions can review what changed and why
- Knowledge: The comments and discussion in a CL contain design rationale that may not be captured anywhere else
- Accountability: Who approved what is permanently on record
Revert workflow: Critique also supports reverts — submitting a CL that undoes a previous change. Revert CLs are treated as normal CLs for approval purposes (they still need LGTM, owner approval, etc.), though the urgency of fixing a production incident sometimes accelerates this process.
Notifications: Reducing Noise, Surfacing Signal
Critique’s notification system is designed around a single insight: over-notification destroys the value of notifications. If engineers receive notifications for every comment, every revision, every automated finding, they will learn to ignore them — and then miss the notifications that actually matter.
Notification Design Principles
Who has the ball?: The most important notification is “it’s your turn.” Critique’s notification model is built around action-required transitions:
- Author is notified when a reviewer posts comments or sends approval/rejection
- Reviewers are notified when the author has updated the CL and re-requested review
- Idle notifications (e.g., “reviewer has been looking at your CL for 2 hours”) are avoided
Batching: Comments are batched at the review round level. A reviewer posting five draft comments publishes them all at once; the author receives one notification, not five.
Configurable suppression: Engineers can configure which types of events generate notifications, for which CLs (ones they authored, ones they are reviewing, ones they are CC’d on), and via which channel (email, internal notification system).
Automated finding notifications: Tricorder and presubmit findings are presented in the UI but do not generate separate notifications by default. The reviewer sees them when they open the CL — they do not receive a separate ping for each analyzer finding.
The net effect of these design choices is that notifications from Critique are high-signal: when you receive one, it almost always means something actionable. This is a property the authors call noise reduction as a design goal, not an afterthought.
Integration with Tricorder and Other Tools
Critique’s tight integration with Google’s broader developer infrastructure is a defining characteristic. The book treats this integration as a key design lesson rather than a feature list.
Tricorder Integration
Tricorder is Google’s static analysis platform. Rather than running as a separate tool that produces a separate report, Tricorder is integrated directly into Critique’s diff view:
- Analyzer findings appear as inline comments in the exact lines they pertain to
- Findings are distinguishable from human comments by visual styling — reviewers always know whether they are reading a human or automated observation
- One-click suggested fixes: When Tricorder has a confident automated fix, a button in the finding allows the author or reviewer to apply it directly. This is the lowest-friction path from finding to resolution.
- Findings can be dismissed with feedback (e.g., “not useful,” “false positive”), which trains the analyzer over time
Why Inline Integration Matters
The alternative — running analysis separately and linking to a report — fails in practice. Engineers context-switch out of the review, open the report, read findings without seeing the code, and then mentally reconnect findings to the review. In practice, the disconnect in context causes most findings to be ignored.
Critique’s inline approach eliminates the context switch entirely. The reviewer reads the diff and sees both human and automated observations in the same view. The cognitive path from “seeing a finding” to “acting on it” is as short as possible.
Build System Integration
Critique shows build and test status directly on the CL:
- Does the CL compile against the current repository state?
- Do existing tests pass?
- Does the change introduce new test failures?
This information is visible to both author and reviewer. An author who sends a CL for review with failing tests is making a visible mistake. The tool does not prevent this, but it makes the state transparent.
CodeSearch Integration
Comments in Critique can link to specific lines in Google’s CodeSearch (code navigation tool). This allows reviewers to provide context (“see how this is done in [file] at [line]”) without requiring the author to separately search for it.
Analysis While Editing and Browsing Code
The chapter notes that Critique’s analysis integration is not limited to the review stage. Google’s broader toolchain provides analysis feedback at multiple points in the development cycle:
- Editor integration: Some analyzers run in engineers’ development environments (IDE plugins, editor integrations) providing immediate feedback while writing code
- Code browsing: Analysis results are available in CodeSearch when engineers browse the repository, not only when they create or review a CL
- Presubmit stage: Analysis runs before review is even requested, giving authors a chance to fix issues before consuming reviewer time
This layered approach — analysis at edit time, at presubmit, at review time, and at browsing time — means that by the time a CL reaches human reviewers, the most mechanical issues have already been addressed by automated tools. Human reviewers can focus on design, correctness, and context-specific judgment.
Anti-patterns Avoided by Critique’s Design
Several of Critique’s design choices are explicit responses to failure modes observed in other code review systems:
| Anti-pattern | How Critique Addresses It |
|---|---|
| Analysis results ignored | Tricorder findings are inline in the diff, not in a separate report |
| Approval state confusion | Three-gate approval status is explicitly displayed at all times |
| LGTM after large changes | Approvals auto-retract when the CL is significantly updated |
| Reviewer notification fatigue | Comments are batched; analyzer findings don’t generate extra notifications |
| Losing review context in large CLs | Per-file review state, filtering by comment state, file tree navigation |
| No post-commit record | All comments and approvals are permanently archived |
| Unknown reviewer load | Critique surfaces reviewer workload to assist with reviewer selection |
TL;DRs
- Trust and communication are core to the code review process. A tool can enhance communication and cause a faster code review process, but it cannot replace trust.
- Tight integration with other developer tools is key to making code review more efficient and effective.
- Code review tools should minimize friction to enable fast review cycles. When designed properly, they can improve code quality by increasing the efficiency of the review process.
- Static analysis results should be integrated directly into the code review tool so that they are visible to both author and reviewer in context.
- Notifications should be signal, not noise. Design notification systems to trigger on actionable events and batch low-priority information.
- The approval state of a change must be explicit and visible at all times to both author and reviewer.
- Code review tools should support post-commit tracking so that the reasoning behind changes remains discoverable long after submission.
Key Takeaways
- Critique structures the CL lifecycle as six explicit stages — create, request, understand/comment, approve, commit — each with its own tooling designed to reduce friction at that stage.
- Inline surfacing of automated analysis is the most important integration decision: Tricorder findings appear directly in the diff at the relevant lines, eliminating the context-switch that causes findings in separate reports to be ignored.
- The three-gate approval system (LGTM, owner approval, readability approval) is enforced by the tool and displayed as explicit state — reviewers and authors always know what approvals are still needed.
- Automatic LGTM retraction when an author makes significant post-approval changes prevents the anti-pattern of sneak changes that reviewers never see.
- Draft comments allow reviewers to compose a full review before publishing, so authors receive one coherent batch of feedback per round rather than a stream of interruptions.
- Notification design is a first-class concern: Critique batches notifications at the review-round level and does not generate separate notifications for automated findings, preserving the high signal-to-noise ratio that makes notifications actionable.
- Post-commit record preservation makes CLs a permanent knowledge artifact — the discussion, rationale, and design decisions in a CL are discoverable long after the code is submitted.
- Reviewer selection tooling (ownership-based suggestions, workload visibility) removes a significant cognitive burden and reduces the tendency to assign reviews to whoever is most familiar rather than most appropriate.
- Suggested fixes from automated analysis lower the cost of acting on findings to a single click — the lowest-friction path from detection to remediation.
- Tool design encodes process values: every major design decision in Critique embeds an opinion about what good code review looks like; tooling is never neutral with respect to behavior.
Related Resources
- ch09-code-review — The process-level treatment of code review at Google; Chapter 19 is the tooling complement to Chapter 9’s process discussion
- ch20-static-analysis — Tricorder, the static analysis platform integrated into Critique, is covered in depth in Chapter 20
- ch17-code-search — CodeSearch integration with Critique for navigation and cross-reference in review comments
- DDIA Chapter 1 — Maintainability as a system property; Critique’s post-commit record is one of the primary mechanisms for maintaining comprehensibility over time
Last Updated: 2026-06-02