Incremental Rewrite Granularity

The insight that the risk and cost of a rewrite scale with the unit of change — full- system rewrites are riskiest, microservice extraction is safer, and function-level FFI/boundary rewrites are safer still, because the smallest unit preserves the existing contract, tests, and interfaces while swapping only the internals.

Also known as: ffi refactoring, function-level rewrite, granularity of rewrite, foreign function interface refactoring

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (3)

• Presentation: Maximizing Success with Limited Time, Resources, and Energy: Lessons from Startup Engineering David Gudeman · 2026-09-22 source ↗ Reader 🖥️
  A resource-constrained startup should bet on a managed platform (Firebase/GCP/Cloud Run) that lets it ship a working product immediately and evolve incrementally into a production-grade system without ever rewriting from scratch, and should architect its frontend as a thin reactive subscriber to the backend database rather than duplicating state client-side — because engineering time spent on infrastructure or state-synchronization busywork is time not spent learning what users actually want.
• Bun Rewrites 535K Lines of Zig into Rust in Four Months, Eliminates Numerous Memory Leaks Bruno Couriol · 2026-09-20 source ↗ Reader 🖥️
  A single domain expert, directing dozens of parallel adversarial-review AI agents against a mechanical (behavior-preserving) porting process anchored to an extensive pre-existing test suite, rewrote a 535K-line production codebase into a memory-safer language in months instead of a year and shipped measurable bug and memory-leak reductions — but critics dispute whether passing that same test suite ever was, or could be, sufficient proof that a million lines of largely unreviewed AI-generated code are actually safe.
• Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase Lily Mara · 2026-09-10 source ↗ Reader 🖥️
  Rewriting an existing system for performance is safer and more tractable at the individual-function level — via a C FFI boundary connecting a fast language (Rust) to the existing slow one (Python, via PyO3) — than at the whole-system or even microservice level, because the smaller unit of change lets teams keep the old implementation, tests, and process contracts intact while swapping only the internals that are actually the aggregate cost driver.

Propositions touching this concept (3)

By publication month, oldest first (extraction month when no publication date is known).

2026-09

• explicitFFI refactoring — rewriting at the individual-function level and connecting old and new code via the C FFI — is a viable unit of migration that is more fine-grained than microservice extraction.
  Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase · p3
• explicitThe bug-introduction risk is lower for function-level FFI refactoring than for a full system rewrite because the change is more constrained/scoped.
  Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase · p5
• explicitBecause FFI refactoring preserves the existing function/HTTP contract, existing test suites (pytest, integration tests against the HTTP handler) continue to validate the new implementation with no additional service to stand up, and dependency injection or property-based testing can directly compare old vs. new implementations.
  Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase · p9

Open gaps (7)

• incompleteThe piece never addresses whether this specific implementer/reviewer/fixer workflow generalizes beyond an unusually well-suited case: a codebase with a mature, language-independent test suite, and its original author personally available to direct 64 parallel agents. No second example is offered.
  Bun Rewrites 535K Lines of Zig into Rust in Four Months, Eliminates Numerous Memory Leaks — read next: Look for an independently reported large-scale AI rewrite of a codebase with a weaker test suite, or without the original author directing it, to see whether the risk profile holds.
• uninformedThe $165,000 token cost is reported 'at API pricing' without noting whether this reflects a subsidized internal rate (Bun/Anthropic are commonly owned), nor is any counterfactual maintenance-cost comparison offered for continuing to hand-fix the original Zig memory bugs over time.
  Bun Rewrites 535K Lines of Zig into Rust in Four Months, Eliminates Numerous Memory Leaks — read next: See the companion gap already recorded on the same underlying event in extract-pragmatic-engineer-anthropic-building-software#g3.
• illogicalThe talk asserts the bug-introduction risk is lower at function scale than for a full rewrite (proposition p5) but never actually demonstrates this — no comparative data, incident rates, or even an anecdote of a bug this technique introduced. The claim rests entirely on 'smaller scope, therefore safer' intuition, which the talk does not test against the possibility that FFI boundaries introduce their own novel bug class (memory/lifetime mismatches, GIL misuse, silent numeric divergence as actually shown) that a same-language refactor would not.
  Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase — read next: Read practitioner postmortems specifically about FFI-boundary bugs (use-after-free across a Python/Rust boundary, GIL deadlocks, ABI mismatches) to test whether 'smaller unit of change' actually implies 'lower risk' once the risk profile of the boundary itself is counted.
• uninformedDeployment and dev-environment complexity are named as costs but never quantified or walked through concretely (e.g. what a CI pipeline that cross-compiles Rust wheels for every supported OS/architecture actually looks like, how long that adds to build times, what happens when a contributor's machine can't match a required target triple).
  Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase — read next: Read maturin/PyO3's own packaging documentation and case studies (e.g. cryptography, polars, pydantic-core) on multi-platform wheel-building pain, to fill in the concrete operational cost this talk only names in the abstract.
• incompleteNo discussion of data-consistency or transactional trade-offs once multiple write paths exist (the REST endpoint he recommends, plus the client writes Firestore rules technically still permit and he only discourages rather than disables). No treatment of what happens under concurrent writes or partial failures.
  Presentation: Maximizing Success with Limited Time, Resources, and Energy: Lessons from Startup Engineering — read next: Sources on Firestore/Firebase data-modeling and consistency guarantees, or on CQRS/command-endpoint patterns for NoSQL reactive databases.
• incompleteBets the company's entire stack on Google's platform for up to a decade without ever naming vendor lock-in or Google's own history of deprecating developer products as a risk to weigh against the velocity gains.
  Presentation: Maximizing Success with Limited Time, Resources, and Energy: Lessons from Startup Engineering — read next: Vendor lock-in / platform-risk analyses for cloud-native startups; Google's product-deprecation track record.
• illogicalThe 'critical feature that turned out unused' anecdote is used to justify 'just build it and move on,' but the same evidence equally supports the opposite lesson — instrument usage or validate demand before building — which he never considers as an alternative.
  Presentation: Maximizing Success with Limited Time, Resources, and Energy: Lessons from Startup Engineering — read next: Lean/validate-before-build literature (e.g. Lean Startup) as a counter-framework to his 'ship fast, don't argue' heuristic.