Gemini 4 Argon Sped Up Google's ADK Overnight: How It Works

10 min read · Last updated: October 24, 2026

Google ran Gemini 4 Argon unattended for 11 hours on its Agent Development Kit (ADK), a Python codebase of over 200,000 lines. The agent proposed six changes and maintainers accepted two. One cut in-memory session preparation overhead by about 40% in long sessions. The other cut cold package import time by 21%.

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The report

• Google Optimizes Agent Development Kit's 200K-line Python Codebase Overnight with Gemini 4 Argon, InfoQ, by Sergio De Simone, October 24, 2026

Key takeaways

• Gemini 4 Argon ran for 11 hours unattended on a codebase of 200K+ lines, about 800 files and nearly 17,000 unit tests.
• 2 changes were accepted and 4 were rejected by human reviewers, so roughly one in three proposals shipped.
• Session preparation got about 40% faster in long sessions. Cold package imports got 21% faster.
• On a 158-turn tool calling run, total time dropped from 65.6 seconds to 56.1 seconds, close to 10 seconds of pure framework overhead removed.
• The setup that made it work: repository rules in .agents/skills files, plus a single /goal prompt that survived context compaction.
• Before finishing, the agent ran all 16,892 open-source unit tests.

What is the Gemini 4 Argon ADK optimization, in one comparison?

The Gemini 4 Argon ADK optimization was Google asking an AI agent to make an existing, large Python framework faster without breaking anything, then leaving it alone overnight. Think of it as hiring a contractor to rewire a house people still live in, instead of building a new house on an empty lot.

That comparison is the whole point of the experiment.

Building on an empty lot is what most AI coding demos show you. A blank folder, a prompt, an app. Google's engineers said they wanted to learn "about how the model handles an existing codebase", which they call a much harder task than "greenfield apps built from an empty folder".

Rewiring an occupied house is different. You can't rip out a wall because one room is slow. Every wire you touch might feed a room you haven't seen yet. And the family living there (in this case, every app already built on ADK) expects the lights to work in the morning.

So the contractor needs three things:

1. A house manual. Where the fuse box is, which walls are load bearing, how this family likes things done.
2. A clear job ticket. What "done" means, and what must not change.
3. Proof. Before and after measurements, and a check that every outlet still works.

Google gave Argon exactly those three things. Here is how.

Why is performance work a hard test for an AI agent?

Performance work is hard for an agent because the slow code is rarely where the slowness shows up. You can't open one file and spot the problem. The agent has to hold a map of how the whole codebase fits together, across a long run, and look away from the symptom to find the cause.

Google's write-up makes a sharp distinction here, and I think it is the most useful line in the whole story.

A profiler will tell you that copying sessions and importing packages take time. What a profiler 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. Argon did that cross-module legwork.

	A profiler	Gemini 4 Argon in this run
Finds where time is spent	Yes	Yes, by setting baselines
Traces every caller and shared reference	No	Yes, across 40 files
Writes the fix	No	Yes
Writes a regression test	No	Yes, required by the prompt
Runs the full test suite	No	Yes, 16,892 tests
Decides whether the fix ships	No	No, human maintainers did

That last row matters. The agent did the legwork. People still made the call.

How did Google set up Gemini 4 Argon? Step by step

Google set up the run in four steps: a short trial run to find gaps, repository rules written as skill files, a single goal prompt pinned with /goal mode, and then 11 hours with nobody watching. Inside the run, the agent followed its own loop of reading, measuring, changing, reviewing and testing.

Here is the order, as the InfoQ report describes it.

Step 1: Run a short trial first

Google did not start with the overnight run. An initial short run showed them what the prompt needed to include so the agent would follow the team's conventions for unit testing and benchmarking.

This is the step most people skip. You learn what your agent gets wrong cheaply, then fix the instructions before the expensive run.

Step 2: Write the house manual as .agents/skills files

Repository-specific guidelines went into .agents/skills files. Google describes them as "like an onboarding guide for a new engineer".

One detail I like: the agent was told to load only the skill it needed for the current task. Loading every guide at once would flood the context window, which is the model's working memory for the run.

Step 3: Write one goal and pin it with /goal

This is the exact prompt Google used, run through Antigravity's /goal mode so the goal was preserved across context compaction (when an agent summarises its own history to free up room on a long run):

/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.

Read it like a job ticket. It has a target (no noticeable overhead), three places to look (startup, long sessions, multi-agent and workflow setups), two things that must not change (what the model receives, the public API), a proof requirement (a regression test for every change, plus before and after numbers) and a hard stop (don't merge).

Step 4: Let it run, then read the logs

When the task finished, Argon's logs showed it had:

1. Read the repository guidelines.
2. Established performance baselines.
3. Proposed optimizations.
4. Reviewed its own changes.
5. Run all 16,892 open-source unit tests.

That is the same loop a careful senior engineer follows. The difference is that it ran for 11 hours without a coffee break.

What did Gemini 4 Argon actually change in ADK?

Argon's two accepted changes were simple ideas applied carefully. First, ADK now filters session events before copying them, instead of copying the whole history. Second, heavy packages are loaded lazily, so they are only imported when something actually needs them. Together they made in-memory session preparation about 40% faster and cold imports 21% faster.

Change	What it does	Result
Filter before copy	Filters session events before copying history	About 40% less in-memory session-preparation overhead in long sessions
Lazy loading	Delays importing heavy packages until they are needed	21% faster cold package import

Neither idea is new. What made them hard was doing them inside a 200K-line framework without changing the public API or what the model receives.

Do a few milliseconds really matter?

A few milliseconds per call do not matter on their own, but they compound across long agent runs. Google notes that a human won't feel 28 ms or 78 ms on a single model call that takes seconds. Across 158 internal tool calling turns, removing those copies cut the full run from 65.6 seconds to 56.1 seconds.

That is about 14% of the total run time, and all of it was framework overhead, not model thinking time.

This is why the goal named "long sessions" and "multi-agent and workflow setups". ADK supports multi-tool interactions that run for dozens or even hundreds of iterations. A cost that is invisible once becomes a real number when you pay it 158 times.

If you build agents yourself, remember this. Measure the framework, not just the model. If you are newer to agents, my explainer on what OpenClaw is and how personal AI agents work covers the basics of that loop.

A small example: what the two patterns look like in Python

Here is a minimal sketch of both patterns. This is my illustration, not ADK's code. The InfoQ report does not publish the actual diff, so treat this as the shape of the idea.

Pattern 1: filter before you copy.

import copy

# Before: copy the entire history, then throw most of it away
def prepare_session_slow(events, wanted):
    history = copy.deepcopy(events)
    return [e for e in history if e["type"] in wanted]

# After: decide what you need first, then copy only that
def prepare_session_fast(events, wanted):
    return [copy.deepcopy(e) for e in events if e["type"] in wanted]

In a long session, events grows every turn. The slow version pays to copy all of it, every time. The fast version only pays for what it keeps.

Pattern 2: lazy loading a heavy package.

# mypackage/__init__.py
import importlib

_LAZY = {"heavy_tools": "mypackage.heavy_tools"}

def __getattr__(name):
    if name in _LAZY:
        module = importlib.import_module(_LAZY[name])
        globals()[name] = module
        return module
    raise AttributeError(f"module {__name__!r} has no attribute {name!r}")

Python calls a module-level __getattr__ only when a name is not found the normal way. So import mypackage stays fast, and heavy_tools loads the first time someone touches mypackage.heavy_tools.

The hard part, and the part Argon was credited for, is not writing these ten lines. It is checking every caller, every test mock and every shared reference that might quietly depend on the old behaviour. Lazy loading in particular can break a test that patches a module which is no longer imported up front.

Why were four of the changes rejected?

Four of Argon's six proposed changes were rejected in developer review over concerns about reliability, maintainability, compatibility, or whether the performance gain was measurable. Only two shipped. The run shows agents can now change large existing codebases, but review, debugging and testing still decide what actually lands.

I don't read that as failure. One in three on unattended performance work in a 200K-line codebase is a useful night's work, as long as a human reviews it the next morning.

But it does tell you where the bottleneck has moved. The InfoQ report puts it plainly: agents' effectiveness is currently limited by the time and effort of post-coding tasks, including PR review, debugging and testing. Writing the code was the cheap part. Someone still had to read four rejected changes and say no to each one.

When should you run an AI agent overnight on your codebase, and when not?

Run an agent unattended when the goal is measurable, the test suite is large and trusted, and a human will review every change before it merges. Avoid it when you can't measure success, your tests are thin, or the agent would be allowed to merge on its own.

Use it when	Avoid it when
Success is a number (milliseconds, import time)	Success is a judgement call ("make it cleaner")
You have a big test suite you trust (ADK had nearly 17,000)	Your tests are thin, so "all green" proves little
Your conventions are written down, like .agents/skills	Your rules live in one senior engineer's head
The prompt forbids changing the public API	Any behaviour change is acceptable
The agent opens a PR and stops	The agent can merge to main
You did a short trial run first	You go straight to an 11-hour run

The part I'd copy from Google is not the model. It is the setup. Short trial, written rules, one precise goal, proof required, no merge rights. That works with whichever agent you use. If you are still choosing one, my ranking of AI coding tools in 2026 and the Cursor vs Claude Code comparison are good places to start.

FAQ

What is Gemini 4 Argon?

Gemini 4 Argon is the Google model that ran this 11-hour unattended optimization of the Agent Development Kit codebase. In this run it read the repository guidelines, set performance baselines, proposed changes, reviewed its own work and ran 16,892 unit tests. The InfoQ report does not cover its pricing or availability.

What is Google's Agent Development Kit (ADK)?

ADK is Google's framework for building AI agents. Its codebase spans over 200,000 lines of Python across about 800 files, with nearly 17,000 unit tests. It supports multi-tool interactions that run for dozens or even hundreds of iterations, which is why small per-turn overheads add up.

What are .agents/skills files?

They are repository-specific instruction files that tell an agent how a codebase works, such as the team's conventions for unit tests and benchmarks. Google compared them to an onboarding guide for a new engineer. The agent was told to load only the skill relevant to the current task, so the context window stays clear.

Did the AI merge its own changes?

No. The prompt explicitly said to open one pull request against main and not merge it. Human maintainers reviewed the work, accepted two optimizations and rejected four over reliability, maintainability, compatibility or unclear performance benefits.

Pick one slow path in your own codebase, write down the number you want to beat, and give an agent a goal with a "don't merge" line this week. While it runs, the free tools on Art of Code can handle the small stuff, and if you're wondering what this means for your job, read will AI replace developers.

Written by Adithya Guttha, Founder of Art of Code.