Published on AskGenAI | June 2026
Google manages one of the largest codebases in the world — billions of lines of code across thousands of projects, with tens of thousands of engineers contributing daily. How do they maintain code quality at this scale? The answer lies in their publicly shared Engineering Practices, specifically their legendary Code Review Guidelines.
In this article, we’ll break down the core principles from Google’s eng-practices repository and explore how you can apply them to your AI engineering projects — whether you’re building MCP servers, RAG pipelines, or LangGraph agents.
What Is Google’s Engineering Practices?
Google’s Engineering Practices is a collection of best practices developed over decades of building and maintaining software at massive scale. Currently, it focuses primarily on code review — what Google considers the single most effective quality control mechanism.
The documentation is split into two complementary guides:
| Guide | Audience | Purpose |
|---|---|---|
| The Code Reviewer’s Guide | Reviewers | How to review code effectively |
| The Change Author’s Guide | Developers | How to write code that passes review smoothly |
Google’s Core Philosophy: Code Health Over Perfection
The single most important principle in Google’s code review system is this:
“Reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system, even if the CL isn’t perfect.”
Key insight: There is no “perfect” code — only better code. Google’s culture explicitly rejects perfectionism in favor of continuous improvement.
This principle has profound implications:
- Don’t block progress for minor polish
- Don’t approve degradation — even small shortcuts compound over time
- Balance speed and quality — both matter, but neither should dominate
The Standard of Code Review: Three Trade-offs
Google’s review standard balances three competing priorities:
1. Developer Progress
Developers must be able to ship improvements. If reviews are too strict, engineers stop making improvements entirely.
2. Code Health Maintenance
Reviewers must ensure the codebase doesn’t degrade over time. This is especially critical under deadline pressure when teams feel pressured to take shortcuts.
3. Consistency & Ownership
Reviewers have ownership over the code they review. They ensure the codebase stays consistent, maintainable, and aligned with team standards.
The resolution? Approve when the change improves code health overall. Leave “Nit:” comments for polish that can be addressed later.
Speed of Code Reviews: Google’s Team Velocity Secret
Google optimizes for team velocity, not individual developer speed. Here’s why fast reviews matter:
What Happens When Reviews Are Slow?
| Problem | Impact |
|---|---|
| Team velocity decreases | Features and bug fixes delayed by days or weeks |
| Developer frustration | Complaints about “strict” reviewers (usually actually about slow reviews) |
| Code health degrades | Pressure to accept lower-quality code; discourages refactoring |
Google’s Speed Guidelines
- Respond within one business day — maximum acceptable delay
- Don’t interrupt focused coding — wait for natural breakpoints (after lunch, meetings, etc.)
- Fast responses matter more than fast overall process — even if a CL takes multiple rounds, quick per-round responses reduce frustration
Pro Tip: “LGTM With Comments”
When confident the developer will address remaining minor issues, approve with comments rather than waiting for another round. This is especially valuable for cross-time-zone teams.
Writing Small CLs: The Developer’s Superpower
Google calls changes “CLs” (Changelists) — what most teams call PRs or patches. Their #1 advice to developers:
Write small, self-contained CLs.
Why Small CLs Win
| Benefit | Explanation |
|---|---|
| Reviewed faster | Easier to find 5 minutes multiple times than 30 minutes once |
| Reviewed more thoroughly | Large changes lead to fatigue; important points get missed |
| Fewer bugs | Fewer changes = easier to reason about impact |
| Less wasted work | If direction is wrong, you haven’t invested weeks |
| Easier to merge | Fewer conflicts, simpler rollback |
| Better design | Easier to polish details of a small change |
What Counts as “Small”?
- One self-contained change — addresses just one thing
- ~100 lines is usually reasonable; 1,000 lines is usually too large
- Includes related tests — tests are part of the change, not separate
- Reviewer can understand everything from the CL, description, and existing codebase
Splitting Strategies
| Strategy | When to Use |
|---|---|
| Stacking | Build next CL on top of current one while waiting for review |
| Split by files | Different files need different reviewers |
| Horizontal splitting | Separate layers (API, service, model) |
| Vertical splitting | Separate features (e.g., multiplication vs. division in a calculator) |
| Separate refactoring | Move/rename classes in one CL; fix bugs in another |
How to Write Code Review Comments
Google’s comment guidelines emphasize kindness, clarity, and teaching:
The Golden Rules
- Be kind — comment on the code, never the developer
- Explain your reasoning — help them understand why
- Balance guidance with autonomy — point out problems, let them decide solutions
- Encourage simplification — suggest clearer code or comments instead of explanations
Comment Examples
| Bad | Good |
|---|---|
| “Why did you use threads here when there’s obviously no benefit?” | “The concurrency model here adds complexity without performance benefit. Single-threaded would be simpler.” |
Labeling Comment Severity
| Label | Meaning |
|---|---|
| Nit: | Minor polish — technically should do it, but won’t hugely impact things |
| Optional / Consider: | Good idea, but not strictly required |
| FYI: | For future consideration — not expected in this CL |
Accepting Explanations
If you ask a developer to explain code you don’t understand, the right response is usually: rewrite the code more clearly. Explanations in review tools don’t help future readers — only code comments or simplified code do.
Handling Pushback and Conflicts
Even with clear guidelines, disagreements happen. Google’s escalation path:
- Developer and reviewer discuss — based on the documented guidelines
- Face-to-face or video call — if comments aren’t resolving it
- Escalate — to tech lead, maintainer, or engineering manager
- Never let a CL sit idle — due to unresolved disagreements
Mentoring Through Code Review
Code review isn’t just quality control — it’s Google’s primary teaching mechanism:
- Share knowledge about languages, frameworks, and design principles
- Prefix educational comments with “Nit:” if not critical
- Celebrate what developers do well — reinforcement works better than criticism alone
How to Apply Google’s Practices to AI Engineering
These principles are especially relevant for AI engineering teams working on:
| AI Domain | Application |
|---|---|
| MCP Server Development | Small CLs for each tool/endpoint; thorough review of protocol implementations |
| RAG Pipelines | Review data flow, embedding logic, and retrieval accuracy separately |
| LangGraph / LangChain | Review agent logic, state management, and tool integration in focused changes |
| CrewAI / Multi-Agent Systems | Small CLs for each agent role; careful review of inter-agent communication |
| AI Interview Prep | Use Google’s comment labeling (Nit:, Optional, FYI) when reviewing practice code |
Key Takeaways for Your Team
- Approve improvements, not perfection — keep momentum while protecting code health
- Review fast, review kind — speed reduces frustration; kindness builds culture
- Write small CLs — the #1 predictor of smooth reviews
- Explain your reasoning — comments should teach, not just dictate
- Label comment severity — help authors prioritize effectively
- Use code review for mentoring — it’s your most powerful teaching tool
Resources
- Google’s Engineering Practices GitHub Repository
- The Code Reviewer’s Guide
- The CL Author’s Guide
- Google’s Code Review Training (internal)
What are your team’s code review practices? Share your experiences or ask questions about implementing Google’s guidelines in your AI engineering workflow on AskGenAI.
This article is based on Google’s publicly available Engineering Practices documentation, licensed under CC-By 3.0.