An agent proposed six overnight changes to a 205,000-line codebase. Engineers kept two. That is the result
Google ran Gemini 4 Argon unattended for 11 hours on its Agent Development Kit. Two changes shipped, four were rightly rejected, and a first run without repository rules broke a public schema.
Listen to this article · 5 min
AI-generated narration of the full article.
Most reports of coding agents on large codebases describe what the agent produced. Google’s account of an overnight run on its Agent Development Kit is more useful, because it spends as much time on what the engineers threw away.
The setup, published on October 13: Gemini 4 Argon, running in Google Antigravity, worked unattended for 11 hours starting at 9:11 p.m. on google/adk-python, about 205,000 lines across nearly 800 files with close to 17,000 unit tests. The goal was to find and remove cross-file performance overhead in startup, long sessions and multi-agent setups, without changing model inputs or the public API, and to open one unmerged pull request with before-and-after numbers.
The first attempt is the instructive one
Before the overnight run, the team tried a two-hour round with no repository guidelines. The agent spent about 70 minutes measuring before editing, which is good practice, and it found real bottlenecks. It also changed a public JSON schema through an authentication model hook, missed edge cases in mock events, ran only 216 nearby tests and left benchmark numbers out of its pull request.
None of those are reasoning failures. They are the mistakes a capable new engineer makes in a codebase whose unwritten rules nobody has told them. The second round fixed that in two ways: maintainer guidelines stored in the repository as .agents/skills, each a short index pointing to reference files loaded on demand (the agent read 12 of them before editing), and a goal mode that keeps the objective pinned across context compactions. In round two the agent followed conventions, ran a baseline across four workloads with 30 runs each and ran the full suite before finishing.
Six proposals, two merges
| Proposal | Outcome | Reason |
|---|---|---|
| Filter session history before copying | Merged | About 40% less pre-model overhead in long in-memory sessions |
| Lazy-load heavy packages | Merged | 21% faster cold import, with patchable module attributes kept |
| Multi-agent event cache | Rejected | 17% on a synthetic test, but could return stale data across sessions |
| Telemetry check | Rejected | Read a private library attribute that could break on upgrade |
| History formatting rewrite | Rejected | Harder to read, no end-to-end gain on the holdout benchmark |
| Workflow replay index | Rejected | Added state complexity that helped only synthetic tests |
The merged change touched 22 files, added 17 test functions and landed on main with the note “Argon generated these changes.” Results were measured on an independent holdout benchmark the agent never saw, as medians of 6 to 12 runs, with byte-identical model requests before and after. A 158-turn tool-calling run dropped from 65.6 to 56.1 seconds. Time to first request in a new process stayed flat, because the deferred modules now load on the first turn.
The lazy-loading change shows the kind of work agents do well. Simply removing top-level imports broke 25 internal Google test targets that patch module attributes directly. The fix used lazy accessors that keep attributes patchable, a cross-module detail a profiler would not reveal.
What transfers to an enterprise codebase
The team’s own summary is “the agent explores, the maintainer subtracts.” Three lessons follow for engineering leaders planning long-running coding agents.
Write the rules down before the run. Most of round one’s errors came from conventions that lived in maintainers’ heads. Repository skills are cheap to write and reusable by every agent and every new hire. In regulated codebases, this is also where you encode what an agent must never touch.
Separate the agent’s benchmark from yours. The rejected event cache looked like a 17% gain on a synthetic benchmark. A holdout benchmark the agent cannot see is the code equivalent of proof coming from outside the model: it stops the agent from optimizing the test.
Budget for review as the main cost. Six proposals in one night is cheap to generate. Judging stale-data risk in a cache, upgrade risk in a private attribute and readability in a core path took experienced maintainers. A two-in-six acceptance rate is not a weakness of the run; it is what a working review looks like. An agent program that measures success by proposals generated will reward exactly the four changes this team rejected. Measure accepted changes, with their evidence, as we argued for agent-authored changes in general.
The case is Google’s own repository, its own tooling and its own engineers, and the gains apply to specific ADK operations. It is not evidence that overnight agents lower development cost in general. It is good evidence of how to run one so that what reaches main deserves to be there.