Google’s FlowAgent races the developer’s next code edit

Google’s FlowAgent has supplied AI repairs on hundreds of thousands of proposed code changes, placing suggestions inside the tools developers already use. Its design targets a short interval: a test has failed, the author still remembers the change, and a useful patch must arrive before work moves on. The paper was posted on 5 October and accepted for the ASE 2026 software-engineering conference.[1][2]

The task is pre-submit repair. Google’s wider test system checks a proposed change before it enters the shared repository, sometimes finding failures beyond the tests a developer ran locally. FlowAgent investigates eligible failures, edits code in a sandbox and uses build and test feedback to revise its candidate. An internal Gemini 2.5 Pro model powers the loop, capped at 100 tool calls and 30 minutes.[2]

A repair can pass its tests and still miss the intent

Correctness was evaluated separately. Three experienced developers reviewed repairs for 195 randomly selected test failures from 37 teams and agreed that 131 were correct: 67.18%. They assessed whether the proposed change matched both the failure and the intended code change. That judged sample should not be treated as the correctness rate of every deployed suggestion.[2]

The paper gives concrete examples of rejected suggestions: ignoring a test, swallowing an assertion inside error handling or changing an assertion in a way that was close but not exact. A successful test run can therefore be an incomplete check. Other developers understood a useful fix from its preview and typed it themselves, so application counts also miss some assistance.[2]

Latency decides whether a candidate survives

The median interval from failure notification to a developer’s next edit was 27.48 minutes in the authors’ workflow analysis. FlowAgent took a median 9.85 minutes to obtain a successful fix, rising to 25.83 minutes at the 90th percentile. These measure different events and do not establish a corresponding amount of time saved.[2]

The timing constraint has a visible cost. Post-execution filters discarded 126,310 candidates because the developer had already modified or submitted the change. Earlier filters also exclude known flaky tests, build failures, automated changes and oversized edits. The system deliberately attempts a narrower set of failures rather than posting every possible patch.[2]

The study’s distinctive evidence is the connection between repair quality and the moment a developer can use it. A technically plausible patch that arrives after the next edit may create conflict; a well-timed explanation can help even when its patch is never applied. FlowAgent’s telemetry makes those different outcomes visible.[2]

Report an error or suggest a correction