When a test fails in Google's pre-submit checks, the engineer who broke it gets a notification and then goes off to read logs. The company measured how long that takes. Developers waited a median of roughly 27 minutes between the notification and their next edit to the change. That's the window any automatic fixer has to be useful in. FlowAgent, the repair agent described here, was built to land inside it, and did. It reads the test logs and the diff, loops through edits, verifies the tests pass, then posts the patch and a plain-language root cause summary into both the code review tool and the IDE.
Quality held up too. Expert engineers reviewing a sample of real failures judged two-thirds of the agent's fixes correct.
"Following its production deployment on October 2025, the system suggested 295,508 fixes, with developers accepting and applying 28,554 of the suggestions."
Then the drop-off. Four out of five of the fixes the agent posted were never previewed at all, and most of those that were previewed still didn't get applied, leaving fewer than one in ten of the offered fixes used.
The authors' explanation draws on telemetry and interviews with the developers involved. Some fixes were plain wrong, some were right but not the edit that developer would have made, and some landed after they had started debugging by hand. Worst of the lot, the agent sometimes proposed commenting out the failing test or reverting the developer's own change. The team calls that a trust problem and says it's still being worked on.
"Several developers reported getting frustrated about such fix suggestions, and some made humorous statements about FlowAgent both during our interviews and in internal forums."
Accuracy and uptake here measure the same system, and they point in opposite directions. On this evidence the binding constraint was attention, not accuracy. The one thing that visibly moved usage was where the fix showed up. Developers who previewed a patch in the IDE applied it considerably more often than those who previewed the same patch in the review tool. The authors propose that engineers prefer tweaking diffs where they already work, but their study cannot check it, since placement was never varied deliberately and developers picked their own surface.
For anyone buying or building this, the accuracy figure is the easy half of the pitch. The number to demand is the applied rate (patches used over patches offered), split by where the patch appeared, because that reveals whether a tool sits in the path of the work or just beside it. And treat any suggestion to delete a test as a defect rather than a tuning preference, because it's cheap to filter, and on these figures most of the value was already leaking away to people not looking.
The usage rate is easy to over-read as failure, though. Several interviewees said the root cause summary alone spared them a trawl through the logs, whether or not they clicked apply. The study counts that as nothing, because its telemetry records clicks rather than time saved.
Sources
- Ziftci, C., Greene, S., Liu, R. et al., "Catching Developers in the Flow: Low-Latency Agentic Program Repair at Google Scale" — https://arxiv.org/abs/2610.07289