---
title: >-
  Meta (Facebook): Getafix automated patch suggestion and validation for
  null-dereference bugs
slug: meta-getafix
stable_id: bd5333cfd5519472
company: Meta (Facebook)
function_code: software_engineering
pattern_codes:
  - creator_to_judge
  - straight_through_processing
evidence_strength: verified
publication_tier: showcase
freshness: current
reviewed_at: '2026-08-23'
updated_at: '2026-08-22'
source_quality_summary: 1 primary; publication outcomes are verified.
caveat_summary: >-
  This is a scoped backlog experiment inside one codebase (Instagram), not a
  company-wide production acceptance rate. 'Successfully automatically patched' means
  the patch was compilable and the analyser no longer emitted the warning; whether human
  review subsequently landed every one of the 1,077 patches is not separately quantified
  in the source. The lift is Meta-defined and Meta-measured; it captures whether a bug
  is fixed at all, not who authored the final landed patch. Meta explicitly attributes
  the additional fixes to displaying Getafix suggestions, but the source does not
  decompose the effect into 'engineer accepted the patch verbatim' vs 'engineer used it
  as inspiration'. Meta-measured; the source does not disaggregate SapFix's total volume
  or per-crash acceptance rate. 'About half' i
collections:
  - human-still-decides
  - queue-eliminated
bundle_version: 1.0.0
bundle_fingerprint: sha256:c23c6cc2b88153d008ea8fda928f632ce0011fc2d4c5036672a16e5d895bab93
canonical_url: https://brianletort.ai/transformations/meta-getafix
---

# Meta (Facebook): Getafix automated patch suggestion and validation for null-dereference bugs

Routine static-analysis bugs can receive machine-proposed patches behind compilation and analyzer-clean gates.

Function: Software engineering. Patterns: Creator to judge; Straight-through processing. Evidence: verified.

Freshness: current. Reviewed: 2026-08-23. Updated: 2026-08-22.


Source quality: 1 primary; publication outcomes are verified.

## Before

1. **Static-analysis or automated test-generation tool** — Reports a bug or crash against a specific line of code. (control: Analyser rules define what counts as a bug.)
2. **Facebook engineer** — Reads the report and context, then manually authors a patch such as a null check or annotation. (control: Engineer's own judgement and lint-rule guidance; routine remediation competes for time with higher-complexity work.)
3. **Facebook engineer and reviewer** — Compiles, runs tests, and either lands the patch or iterates. (control: Human review and existing test suite.)
4. **Engineering leadership** — Accumulates static-analysis findings because routine remediation loses priority to feature work. (control: No dedicated capability for closing a backlog at scale.)

## After

1. **Static-analysis or automated test-generation tool** — Reports a bug against a specific line and forwards its metadata to Getafix. (control: Same analyser rules.)
2. **Getafix** — Selects a fix pattern using hierarchical clustering and anti-unification mined from thousands of past human patches; instantiates the pattern using the blamed variable and surrounding code context; produces a candidate patch. (control: Pattern-ranking strategy: more specific patterns beat more general ones for a given context; unmodified surrounding code is included as pattern context, which restricts application to plausible sites.)
3. **Automated validation** — Compiles the patch and reruns the analyzer; Sapienz cases also rerun the crash-triggering test. (control: Only fixes that are compilable and analyser-clean (and, for Sapienz, test-passing) are surfaced.)
4. **Facebook engineer** — Reviews the proposed patch in the code-review portal and accepts, rejects, or replaces it. (control: Human review remains the acceptance gate; complex or rejected cases stay in the human exception path.)

## Decision rights

Meta engineering sets which analyser patterns Getafix may attempt (initially Infer null-method-call and related null-pointer patterns) and the pattern-ranking strategy. Getafix decides whether to attempt a patch for a given bug and which specific patch to propose; the human engineer decides whether the surfaced patch lands. For the Instagram null-method-call backlog experiment, Meta expanded Getafix's authority to attempt patches on the full ~2,000-bug set and reports the automated success rate at each gate.

## Exception path

For a given bug: Getafix may decline to attempt a patch (about 40% of Instagram null-method-call bugs); an attempted patch may fail automated validation (compile or analyser-clean check) and is discarded; an engineer may reject a validated patch during code review; Getafix also flows candidate patches into SapFix, which retries against test outcomes. In every case the engineer remains the last reviewer, and non-null-dereference patterns remain out of scope.

## Outcomes

- **Instagram null-method-call backlog: proportion of bugs successfully auto-patched** (verified): Prior to Getafix, none of the ~2,000 Instagram null-method-call bugs in the backlog had an automatically-generated, validated patch offered against them. → Getafix attempted patches for about 60% of the ~2,000 null-method-call bugs; about 90% of attempted patches passed automated validation (compilable and Infer no longer emitted the warning); overall, 1,077 bugs (approximately 53%) were successfully auto-patched.. This is a scoped backlog experiment inside one codebase (Instagram), not a company-wide production acceptance rate. 'Successfully automatically patched' means the patch was compilable and the analyser no longer emitted the warning; whether human review subsequently landed every one of the 1,077 patches is not separately quantified in the source.
- **Fix rate on return-not-nullable and field-not-nullable Infer bugs after Getafix suggestions were displayed alongside the bug reports** (verified): Prior to displaying Getafix suggestions: 56% of return-not-nullable and 51% of field-not-nullable Infer bugs were being fixed. → After Getafix suggestions were displayed: 62% of return-not-nullable and 59% of field-not-nullable bugs were fixed; Meta attributes a 'couple of hundred' additional fixes over the prior three months to the display of the auto-fixes.. The lift is Meta-defined and Meta-measured; it captures whether a bug is fixed at all, not who authored the final landed patch. Meta explicitly attributes the additional fixes to displaying Getafix suggestions, but the source does not decompose the effect into 'engineer accepted the patch verbatim' vs 'engineer used it as inspiration'.
- **Share of SapFix's valid fix candidates supplied by Getafix** (verified): Under a purely engineer-authored patch flow, Getafix supplies 0% of SapFix's fix candidates. → Over the months preceding the 2018-11-06 disclosure, Getafix provided 'about half of the fix candidates that SapFix uses and considers valid' (all tests passed); of all Getafix-supplied candidates to SapFix, approximately 80% pass all tests.. Meta-measured; the source does not disaggregate SapFix's total volume or per-crash acceptance rate. 'About half' is stated verbatim in the primary source.

## Executive lesson

The instructive part is the layering of gates. Getafix does not hand engineers every candidate; it hands them only the ones that already compile and satisfy the analyser (and, via SapFix, pass the failing test). That is what makes reviewer-role work economically — the engineer never spends time on a proposal that would fail the basic checks a compiler and analyser can already run. It is also honest about scope: the 53% headline is a bounded Instagram backlog result, and the smaller +6-point / +8-point production lifts on return-not-nullable and field-not-nullable are what actually run at Facebook scale.

## Anti-pattern

Reporting the Instagram 53% as if it were a company-wide production auto-fix acceptance rate. It is a bounded backlog experiment on one bug pattern in one codebase; the production-scale signal is the +6-percentage-point fix-rate lift on return-not-nullable and +8 on field-not-nullable when suggestions are shown. Conflating the two overstates the case exactly where a skeptical reader will check.

## Questions for leaders

- Which bug patterns in our codebase are common enough that mining past patches would yield reusable fix templates?
- What is our equivalent of the compile-plus-analyser-clean gate that would let a proposed patch reach an engineer only if it already passes the cheap checks?
- What is the scope discipline that stops the auto-fixer from attempting a pattern it does not understand?
- How do we separate backlog remediation from feature-time remediation so the auto-fixer is measured against the right baseline?
- How do we report our results — as an experiment on a defined subset, or as a company-wide acceptance rate — and would we survive the skeptical read?

## Sources

- [Getafix: How Facebook tools learn to fix bugs automatically](https://engineering.fb.com/2018/11/06/developer-tools/getafix-how-facebook-tools-learn-to-fix-bugs-automatically/) — Engineering at Meta (Facebook)