Tomas Reimers, former Meta engineer and co-founder of Graphite, explains why Meta built its own deeply integrated internal developer tooling instead of using industry-standard solutions like GitHub, and how practices like stacked diffs—now gaining wider adoption—emerged from the unique constraints of large-scale engineering organizations.
Meta’s integrated developer tooling ecosystem
Meta’s internal tools are highly interconnected, forming a seamless workflow from development to deployment:
Sand Castle: Internal CI system (analogous to GitHub Actions or Buildkite).
On Demand: Internal dev boxes for testing.
Land Castle: System for rolling out code to users.
These tools natively share data—e.g., a single diff view shows translation status, feature flag experiment results, rollout progress (1% → 10% of users), and AB test outcomes.
Integration extended beyond code review:
Meta built its own calendar, task system (like Jira/Linear), and translation platform.
Example: If a diff uses an untranslated string, Fabricator blocks deployment until translations exist.
This level of integration is rare outside companies like Google; most firms rely on fragmented third-party tools with superficial integrations.
Herald: Meta’s rules engine for automated code review actions
Herald (later replaced by Butterfly Bot) was a rules engine triggered by events during code review:
Example 1: Automatically comment on PRs using deprecated APIs, suggesting new syntax.
Example 2: Notify maintainers if new call sites are added to a deprecated API.
Example 3: Auto-add specific teams as reviewers or subscribers when sensitive code is modified.
Enabled scalable enforcement of engineering policies without manual oversight.
Code ownership: A shifting philosophy
Meta alternated between requiring and removing code ownership:
Initially required → removed for collaboration → reintroduced for critical systems → later relaxed again.
Contrast with Google’s hierarchical model:
Ownership defined per folder; easy to identify reviewers and contact them directly via file tree navigation.
Tomas’s view: Code ownership depends on business context:
High-trust, low-risk environments → rely on culture.
Low-trust, high-stakes domains (e.g., payments, privacy) → enforce via automation.
Even within one company, different teams (mobile vs. web, payments vs. UI) may need different constraints.
Stacked diffs: Solving the code review bottleneck
Problem: Engineers blocked on review before building next feature; large PRs lead to rubber-stamping.
Solution: Stack diffs—branch off your own unreviewed PR and keep working:
Each small, logical unit (e.g., server → frontend) becomes a separate diff.
Early diffs can merge while later ones are still in review.
Benefits:
Reduces merge conflicts.
Speeds up time-to-merge.
Makes bugs easier to isolate (10-line vs. 2,000-line PR).
Challenges without tooling:
Git rebases become complex when updating base branches.
Reviewers confused if UI doesn’t clearly show stacking relationships.
Why only big companies invented it:
High shipping volume + monorepos + resources to build custom tooling.
Not suited for open source: contributors may disappear, so partial/incomplete work shouldn’t be merged.
Monorepos: Industry trend driven by collaboration needs
Meta’s journey:
Started with emailing zip files → evolved into multiple “poly lith” repos (web, Instagram, mobile, tooling).
Moved toward a single monorepo to unify dependencies, simplify cross-team collaboration, and stabilize CI.
