Oossa

Gemini 4 Argon cut ADK overhead in an 11-hour coding run

Google says the coding agent found two useful optimizations in its 205,000-line Python framework. Four other proposals were rejected in review.

By Published by Oossa: 2 min read

Rahul Mishra · Unsplash

Google says Gemini 4 Argon spent 11 hours working unattended on the Python codebase for its Agent Development Kit (ADK), an open-source framework for building and deploying agents. The run produced two optimizations that Google accepted: one cut in-memory session preparation overhead by about 40% in long sessions, and another made cold package imports 21% faster.

The task tested whether the model could improve an existing project, rather than build an app from scratch. ADK has roughly 205,000 lines of code across nearly 800 source files. Google’s software engineer Bo Yang described the overnight run in a post dated October 13, 2026; InfoQ also reported the results.

What did Argon change?

One change made ADK filter conversation events before copying them. Previously, the in-memory session service copied the full conversation before narrowing it to the events a caller requested. The other change delayed loading heavy packages until they were needed. A basic text agent had been importing components for audio and video, tracing, and web servers even when it did not use them.

Google says the session improvement saved time as conversations grew. In one 158-turn tool-calling run, removing the repeated copying reduced framework overhead from 65.6 seconds to 56.1 seconds. Those are seconds spent by the framework, not the time for the model to do the task. Google also says the lazy-loading change sped up cold imports by 21%, but the post does not give an absolute time saved for imports.

To guide the run, the team added repository-specific instructions in .agents/skills files and used /goal mode in Google Antigravity to keep the task in view as the session continued. Argon measured baselines across four workloads, proposed six optimizations across 32 files, and ran all 16,892 open-source unit tests before finishing.

Why did four proposals fail review?

Google accepted only two of the six proposed changes. It rejected the other four after developer review over concerns including reliability, maintainability, compatibility, or whether a speed gain was meaningful. One rejected cache improved a synthetic multi-agent benchmark by 17%, but Google said it could return stale data if Python reused a memory address after garbage collection.

The run shows what Google’s team found useful: the agent could trace changes across files and prepare code for human review. It does not show that the agent can safely make and ship changes without that review. Google’s account says an earlier attempt missed team conventions and edge cases, while the overnight run still needed maintainers to decide which proposals were safe to keep.

Why it matters

For software teams maintaining large Python projects, the example suggests a coding agent can help find performance fixes across files, not just edit one function. Google’s results are its own account, and its engineers still rejected four proposals, so the run does not establish that teams can skip testing or code review.

Was this article useful?
Share

Read next

Oossa · Newsletter

The week in AI, explained

Every Monday: the stories worth knowing, in plain language. Free, no spam.