← In the News

Google's /teamwork agents port code against the original, unmodified tests

Advancing science & engineering with Antigravity's /teamwork · Vahab Mirrokni, Google Fellow and VP, Google Research · Google Research blog, November 13, 2026

Machine-readable Download Markdown

Google Research describes /teamwork, a multi-agent mode in its Antigravity tool, as partitioning context by construction: each agent receives only the files and tools for its step, coordinators hand work to fresh successors, and critics and auditors check results "from clean contexts without the original producer's reasoning." Candidate solutions are checked by what Google calls falsifiers, such as the Lean 4 proof checker, unmodified software test suites, execution simulators and hardware counters.

For code migrations the post names the failure directly: "Large code migrations fail when agents stub out dependencies or alter tests to make a broken port pass." Google's answer is a rewrite pattern, which it says is soon to be available in Antigravity, that schedules each module only after its dependencies compile and links every leaf module against the original, unmodified test suite. Google reports that a two-week campaign on Gemini 4 Argon finished a Rust port of the Zircon microkernel from an initial 25%, adding about 800,000 lines of safe Rust that pass all kernel unit tests and boot on arm64 hardware. A port of libgav1, Google's AV1 decoder, to around 170,000 lines of Rust reached 100% bit-exact parity on a conformance suite; it started about 4x slower than the C++, and Google says it ended 20 to 30% faster once the agents had profiling tools. The post also says a long campaign studied past run trajectories and changed /boost, the packaged coding loop, to handle tightly coupled code in sequential stages rather than parallel splits.

These are Google's own results, and the post links no code or run logs for the ports.

Why it matters: When agents port or refactor code, the test suite is the part they must not be able to edit. Google's pattern makes that a scheduling rule: a module is tested against the original suite once its dependencies compile, and Google says this is what stopped the stubbing and test editing. Starting critics without the producer's reasoning is a cheap change for any harness that already runs a reviewer agent. Treat the Zircon and libgav1 figures as Google's claims until code or logs appear.