Google reports Rust rewrite gains with unchanged tests Google reports Rust rewrite gains with unchanged tests

The first port was slower

Google says its libgav1 port initially ran about four times slower. Profiling and further optimization then put it ahead of the original implementation. The rewrite workflow schedules modules after their dependencies compile, keeping the original tests intact. That separates two jobs: preserving behavior and improving execution.

Teamwork predates these results

Google described Teamwork’s orchestration design on August 27. The framework assigns different patterns to different tasks, rather than sending every problem to an identical group of agents. Work that separates cleanly can use parallel implementers and critics. Tightly connected code can instead follow repeated implementation, testing and revision. Agent numbers can change during a run as the task develops. Humans retain responsibility for the objective and final acceptance. This is a workflow specification, not simply a larger collection of model responses. Its practical purpose is to turn candidate generation and criticism into an organized process, with explicit criteria for work moving forward. The August release made the preview available on paid plans.

A migration is also a measurement problem

Earlier engineering examples show why the distinction matters. In its October 13 Argon announcement, Google described a scientific Fortran codebase rewritten into Rust and reported a 1.8-fold performance improvement. The same announcement described a separate YouTube comments project driven by production profiles. There, the model identified redundant emoji rendering and proposed targeted optimizations. These are different routes to a faster program: changing a codebase’s implementation language, or removing expensive work inside an existing service. A migration headline alone does not identify which part of an improvement came from language choice, implementation changes or the workload used to measure it.

Rust has a broader delivery case

Google’s Android team had already published a separate account of Rust adoption on November 13, 2025. Its analysis compared first-party Rust and C++ changes, grouping similar change sizes and drawing from overlapping developer populations. Google reported less review time for Rust and fewer rollbacks for medium and large changes. Those measurements concern shipping and maintaining software, not merely the speed of one program. They also explain why a rewrite can have value beyond a benchmark result: revisions, reviews and reversions consume engineering time. The Android evidence comes from a different codebase and development process than the new agent campaigns.

The acceptance test has more than one job

Consider a hypothetical decoder migration. Replaying a fixed set of video inputs can compare the old and new outputs. Timing those same inputs measures another property. A replacement can pass the first check while taking too long for its intended workload. Keeping the checks separate makes that outcome visible. It also leaves a clear record of what changed between the first working replacement and the optimized version.