Google Optimizes Agent Development Kit's 200K-line Python Codebase Overnight with Gemini 4 Argon
Google explained how an 11 hour unattended run of Gemini 4 Argon produced two accepted optimizations for Google Agent Development Kit's codebase, reducing in memory session preparation overhead by about 40% in long sessions and cold package import time by 21%. By Sergio De Simone

Google explained how an 11-hour unattended run of Gemini 4 Argon produced two accepted optimizations for Google Agent Development Kit's codebase, reducing in-memory session-preparation overhead by about 40% in long sessions and cold package import time by 21%.
One of the goals of Google engineers' was to learn "about how the model handles an existing codebase", a much harder task than creating "greenfield apps built from an empty folder", they say. To test this, they focused on optimizing the performance of their own Agent Development Kit (ADK), a codebase spanning over 200k lines of code across approximately 800 files and including nearly 17,000 unit tests.
Performance work is a hard test for a model because you can't just open one file and spot the slowdown. You have to look orthogonally to where the symptom appears and hold a map of how the entire codebase fits together over a long run.
After an initial, short run helped them identify what the prompt needed to include to ensure the agent followed the team's conventions for unit testing and benchmarking, Google engineers specified repository-specific guidelines through .agents/skills files, "like an onboarding guide for a new engineer". The agent was instructed to load only the required skill for the task, to avoid flooding the context window. Finally they came up with the following prompt, where they used Antigravity's
/goal
mode to ensure the goal was preserved across context compaction:
/goal Make ADK add no noticeable overhead to any agent: at startup, in long sessions, in multi-agent and workflow setups. Keep what the model receives and the public API unchanged, and back each change with a test that would catch a regression. Open one pull request against main that the ADK maintainers would approve, with before and after numbers in its description. Don't merge it.
On task completion, Google explains, Argon's logs showed that the agent had read the repository guidelines, established performance baselines, proposed optimizations, reviewed its own changes, and ran all 16,892 open-source unit tests before finishing.
More importantly, Argon did the cross-module legwork a profiler can't do for you. A profiler will tell you that copying sessions and importing packages take time. What it won't do is trace every caller, mock target, and shared reference across 40 files so that speeding up those paths doesn't break existing apps.
The two optimizations finally accepted into the codebase improved how the ADK handled session history by filtering events before copying them and introduced lazy loading to prevent heavy packages from being imported until needed.
These changes made in-memory session preparation and package import faster by 40% and 21%, respectively. These tasks are not particularly expensive compared with the overall duration of an agent run, Google notes that the ADK supports multi-tool interactions spanning dozens or even hundreds of iterations, allowing these small performance gains to compound:
On a single LLM call that takes seconds, a human won't feel 28 ms or 78 ms. Across 158 internal turns of tool calling interactions, however, those copies compound: removing them cuts the full 158-turn run from 65.6 seconds to 56.1 seconds (nearly 10 seconds of pure framework overhead).
While Google's experience with Gemini 4 Argon optimizing the ADK codebase demonstrates AI agents' ability to modify existing codebases successfully, their effectiveness remains currently limited by the time and effort required for post-coding tasks, including PR review, debugging, and testing. Google's findings confirm this trend, with Argon producing 4 modifications that were rejected upon developer review because of concerns about reliability, maintainability, compatibility, or measurable performance benefits.
Originally published on
InfoQ
Keep reading





