Inside Meta's Developer Tooling: How Stacked Diffs and Integrated Systems Transformed Engineering Velocity

Tomas Reimers reveals how Meta's custom developer tools like Phabricator and Herald created integrated workflows years ahead of the industry, and why stacked diffs became essential for unblocking code review bottlenecks.

Meta's internal developer tooling ecosystem demonstrates deep integration that external tools struggle to match, with features like automatic rollout tracking and translation system integration built directly into code review workflows.

Key Takeaways

• Meta's developer tools achieve deep integration impossible with external solutions—code review, CI, deployment, and experimentation results appear in unified interfaces
• Stacked diffs solve the fundamental "blocked on code review" problem by allowing developers to create feature branches off pending changes rather than waiting for approval
• Industry-wide trend toward monorepos driven by collaboration benefits, dependency management, and unified testing, despite GitHub's limited support
• Code ownership approaches vary dramatically—Meta alternated between requiring and removing code owners while Google uses hierarchical folder-based ownership
• AI coding tools will increase code volume significantly, making code review practices and tooling more critical for maintaining quality and collaboration
• Different engineering constraints within organizations justify different practices—mobile teams operate differently than web teams due to deployment cadences
• Engineering metrics like "time waiting in review" and pull request volume provide proxies for velocity but require careful interpretation as signals rather than targets
• Startups face challenges accessing integrated tooling that large companies build internally, creating opportunities for specialized developer tool companies

Timeline Overview

• 00:00–02:00 — Intro: Introduction to Meta's custom internal tooling and Tomas Reimers' background
• 02:00–05:07 — An introduction to Meta's in-house tooling: Overview of Phabricator, Sandcastle, and integrated developer platforms
• 05:07–10:20 — How Meta's integrated tools work and who built the tools: Deep integration examples and development team structure
• 10:20–12:20 — An overview of the rules engine, Herald: Automated code review rules and API deprecation management
• 12:20–14:39 — The stages of code ownership at Facebook and code ownership at Google and GitHub: Evolution of code ownership policies and hierarchical reviewer assignment
• 14:39–16:15 — Tomas's approach to code ownership: Framework based on trust levels and mistake tolerance for different business contexts
• 16:15–18:42 — A case for different constraints within different parts of an organization: How mobile vs web teams require different practices due to deployment cadences
• 18:42–25:01 — The problem that stacked diffs solve for: Addressing code review bottlenecks through branching off pending changes
• 25:01–30:25 — How larger companies drive innovation, and who stacking diffs not for: Why open source development doesn't benefit from stacking due to trust dynamics
• 30:25–35:31 — Monorepos vs. polyrepos and why Facebook is transitioning to a monorepo: Collaboration benefits and dependency management advantages
• 35:31–39:55 — The advantages of monorepos and why GitHub does not support them: Industry trends and GitHub's open source focus limitations
• 39:55–42:15 — AI's impact on software development: Increased code volume creating downstream effects on review, testing, and deployment
• 42:15–45:25 — The problems that AI creates, and possible solutions: Code review becoming more important for alignment checking and knowledge sharing
• 45:25–48:15 — How testing might change and the testing AI coding tools are already capable of: AI's ability to write tests and perform end-to-end validation
• 48:15–53:20 — How developer accountability might be a way to solve bugs and bad AI code: Personal responsibility models like Linux kernel development
• 53:20–57:10 — Why stacking hasn't caught on and Graphite's work: Internal evangelism required for adoption and tooling complexity barriers
• 57:10–1:01:20 — Graphite's origin story: Pivot from mobile release tools to stacked diffs based on market demand
• 1:01:20–1:06:07 — Engineering metrics that matter: Time to merge, waiting time in review, and pull request volume as velocity proxies
• 1:06:07–1:08:41 — Learnings from building a company for developers: Challenges of diverse engineering workflows and tooling integration complexity
• 1:08:41–1:12:41 — Rapid fire round: Favorite tools, programming languages, and book recommendations
• 1:12:41–END — Closing: Summary of key insights and Meta's influence on industry practices

Meta's Integrated Developer Ecosystem

Meta's internal tooling demonstrates a level of integration that external solutions struggle to replicate, creating workflows where code review, deployment, and business metrics exist in unified interfaces.

• Phabricator (code review) integrates deeply with Sandcastle (CI), OnDemand (dev boxes), and Landcastle (deployment) to create seamless developer workflows
• Translation systems built into code review prevent deploying untranslated strings, with automatic blocking until internationalization requirements are met
• Deployed diffs display rollout status directly in the review interface, showing progression from employee testing to percentage-based user rollouts
• A/B test results and feature flag data appear alongside code changes, allowing developers to track business impact from the same interface used for code review
• Herald rules engine (later Butterflybot) enables automated responses to code events, such as posting deprecation warnings when developers use outdated APIs
• Task management systems integrate with pull requests in ways impossible with external tool combinations, creating unified project tracking

This integration level requires significant investment but eliminates context switching and provides holistic views of code changes from development through business impact measurement.

Stacked Diffs: Solving the Code Review Bottleneck

Stacked diffs address a fundamental productivity problem in software development—developers getting blocked waiting for code review approval before continuing work.

• Traditional workflows require creating feature branches off main and waiting for merge approval before starting dependent work
• Stacked diffs allow branching off pending changes, enabling continuous development while previous changes undergo review
• Reviewers receive smaller, more focused pull requests instead of monolithic features that accumulate multiple changes
• The approach mirrors natural development order—building server endpoints before frontend integration, with reviews following the same logical sequence
• When earlier changes require updates, abstraction boundaries typically remain stable, allowing dependent changes to continue without major conflicts
• Meta's tooling handles complex rebasing automatically, removing the manual git operations that make stacking intimidating for most developers
• Benefits include reduced merge conflicts, faster identification of problematic changes, and improved reviewer engagement with smaller change sets

The practice requires both client-side tooling for branch management and host platform support for displaying stacked relationships clearly.

The Monorepo Migration Trend

Large technology companies increasingly adopt monorepos despite GitHub's limited support, driven by collaboration and dependency management benefits.

• Meta began with email-based zip file sharing before evolving through multiple repository structures toward unified monorepos
• Single repositories enable atomic changes across service boundaries, eliminating coordination overhead between dependent systems
• Testing becomes more reliable when all dependencies exist in the same versioned state rather than across multiple repositories with different version combinations
• End-to-end testing simplifies significantly when services can be built and tested together rather than pulling dependencies from separate repositories
• Monorepos enable consistent engineering practices and tool deployment across entire organizations rather than per-repository variation
• Meta's journey includes consolidating separate repositories for web, Instagram, mobile apps, and tooling into unified structures
• The trend reflects companies prioritizing internal collaboration over open source development patterns that favor independent repositories

Industry adoption suggests monorepos provide significant advantages for internal development that outweigh the tooling complexity they introduce.

Code Ownership Evolution

Code ownership approaches vary dramatically across companies and evolve based on organizational needs, trust levels, and compliance requirements.

• Meta alternated between requiring code owners, removing them for collaborative culture, reintroducing them, and removing them again based on changing organizational priorities
• Google implements hierarchical ownership where folders define reviewers, making it easy to identify appropriate people for specific code areas
• GitHub's code owners feature provides basic functionality but lacks the sophisticated hierarchical and conditional logic that internal systems support
• Effective code ownership balances mistake tolerance with trust levels—highly regulated environments require strict approval processes while innovative teams benefit from flexible approaches
• Different code areas within the same company justify different ownership models—privacy-related code requires stricter controls than experimental features
• The optimal approach depends on business constraints, team distribution, and the nature of the code being developed rather than one-size-fits-all policies

Organizations must balance collaboration efficiency with appropriate oversight based on their specific contexts and risk profiles.

AI's Impact on Development Workflows

AI coding tools will fundamentally change software development by dramatically increasing code volume, creating downstream effects on review, testing, and deployment processes.

• AI enables developers to generate code faster than ever before, leading to higher pull request volumes and larger change sets
• "Vibe coding" emerges where developers prompt AI without carefully reading generated code before submitting for review
• Traditional code review mechanics become more important as reviewers must catch issues that authors didn't notice in AI-generated code
• Code review purpose shifts from mechanical bug-catching toward alignment checking and knowledge sharing as AI handles basic correctness
• AI tools can write tests automatically in some cases, potentially handling end-to-end testing that previously required manual QA processes
• The volume increase requires better tooling and processes to handle review throughput without compromising quality
• Companies adopting AI tools without improving review processes risk accumulating technical debt and reducing system reliability

Teams must prepare for higher code volumes by investing in review tooling, testing automation, and processes that maintain quality standards.

Engineering Constraints Drive Different Practices

Different parts of organizations face varying constraints that justify different engineering practices, even within the same company culture.

• Mobile teams rarely hold pagers because deployment cycles through app stores prevent immediate fixes, while web teams require immediate response capabilities
• Payment processing systems demand different reliability standards than experimental consumer features, affecting code review requirements
• Time zone distribution creates different collaboration patterns—distributed teams need different review processes than co-located teams
• Compliance requirements vary by product area, with privacy-sensitive code requiring stricter oversight than general application features
• Startup-like initiatives within large companies benefit from different practices than established product lines with millions of users
• Engineering constraints include deployment frequency, mistake tolerance, regulatory requirements, and team distribution patterns

Recognizing these differences allows organizations to optimize practices for specific contexts rather than applying uniform policies that may hinder some teams.

Engineering Metrics as Velocity Proxies

Effective engineering metrics provide signals about team velocity and bottlenecks while recognizing that all metrics are proxies rather than direct measurements.

• Pull request volume indicates overall development activity but doesn't capture code quality or feature complexity
• Time to merge reveals review bottlenecks but varies based on change complexity and reviewer availability
• "Time waiting in review" isolates delays caused by review processes from time spent addressing feedback
• Focus time measurements attempt to capture uninterrupted development periods but prove difficult to measure accurately
• Metrics help identify outliers and patterns rather than providing absolute measures of productivity or quality
• The best metrics account for different team contexts—distributed teams naturally have longer review cycles than co-located teams
• Gaming metrics becomes problematic when teams optimize for measurements rather than actual productivity improvements

Organizations should use metrics to identify problems and track improvements rather than as performance evaluation tools.

Common Questions

Q: What makes Meta's developer tooling different from external solutions?
A: Deep integration across the entire development lifecycle—code review, CI, deployment, and business metrics exist in unified interfaces rather than separate systems requiring manual correlation.

Q: Why don't more companies use stacked diffs?
A: Git complexity and lack of platform support make stacking intimidating, while companies like Meta invested significant resources in internal tooling to handle the technical challenges automatically.

Q: When should companies consider monorepos?
A: When coordination overhead between repositories slows development, teams need atomic changes across service boundaries, or consistent tooling deployment becomes important—typically after reaching 100+ developers.

Q: How will AI change code review practices?
A: Reviews will shift from mechanical correctness checking toward alignment verification and knowledge sharing, while volume increases require better tooling and processes to maintain quality.

Q: What engineering metrics actually matter?
A: Time to merge, time waiting in review, and pull request volume provide useful signals, but all metrics are proxies that should identify problems rather than measure absolute productivity.

Conclusion

Meta's developer tooling ecosystem reveals how significant investment in integrated systems can create competitive advantages through improved developer velocity and reduced friction. The deep integration between code review, deployment, and business metrics demonstrates possibilities beyond what external tool combinations currently provide.

Tomas Reimers' insights show how practices developed at large technology companies eventually influence broader industry adoption. Stacked diffs, monorepos, and sophisticated code review processes represent solutions to scaling challenges that more companies will face as AI tools increase development velocity.

The transition from traditional development workflows to AI-assisted coding requires rethinking fundamental practices around code review, testing, and deployment. Organizations that proactively adapt their tooling and processes will better handle the increased code volume while maintaining quality standards.

Practical Implications

• Invest in integrated development tooling that reduces context switching between code review, deployment tracking, and business metrics
• Consider stacked diffs for teams frequently blocked on code review, but ensure proper tooling support for managing complex git operations
• Evaluate monorepo adoption based on coordination overhead and dependency management challenges rather than following industry trends blindly
• Develop code ownership policies that match organizational constraints—trust levels, mistake tolerance, and compliance requirements
• Prepare for AI-driven code volume increases by strengthening review processes and investing in automated testing capabilities
• Recognize that different teams within organizations may require different practices based on their specific constraints and risk profiles
• Use engineering metrics as signals for identifying bottlenecks rather than absolute measures of productivity or team performance
• Build internal tooling capabilities or partner with specialized vendors to achieve integration levels that improve developer experience
• Establish review practices that emphasize alignment checking and knowledge sharing as AI handles mechanical correctness verification
• Create feedback loops that help teams understand the business impact of their technical work through integrated dashboards and metrics