Why this exists

Most teams skip the RFC. The code ships, the Slack thread scrolls off, the original author rotates teams, and the reasoning is gone. What remains is a finished sentence with no paragraph behind it — every future maintainer has to guess at the why. Reverse documentation treats the codebase as the artifact and works backward to the design conversation that should have produced it.

What you get back

  • An RFC reconstructed from the code as it actually exists — goals, non-goals, proposed design, rollout.
  • Simulated review comments from skeptical staff engineers, each pointed at a specific decision the code reveals.
  • The objections raised during review and how they were resolved — including the ones that lost.
  • The specific tradeoffs the implementation makes visible: what was bought, what was paid, what was deferred.

When to reach for this pattern

Onboarding a new engineer into a system nobody wants to explain. Preparing for a major rewrite and needing to surface the constraints before you delete them. Documenting a service whose original authors are gone. Teaching architecture by example, using a real codebase as the textbook instead of a toy one.