Google zufolge arbeitete Gemini 4 Argon 11 Stunden lang unbeaufsichtigt an der Python-Codebasis des Agent Development Kit (ADK), einem Open-Source-Framework zum Entwickeln und Bereitstellen von Agenten. Dabei entstanden zwei Optimierungen, die Google übernahm: Eine senkte den Aufwand für die Vorbereitung von In-Memory-Sitzungen in langen Sitzungen um etwa 40 Prozent, eine andere beschleunigte kalte Paketimporte um 21 Prozent.
Mit der Aufgabe sollte getestet werden, ob das Modell ein bestehendes Projekt verbessern kann – und nicht, ob es eine App von Grund auf erstellen kann. ADK umfasst rund 205.000 Codezeilen in knapp 800 Quelldateien. Googles Softwareentwickler Bo Yang beschrieb den nächtlichen Lauf in einem Beitrag vom 13. Oktober 2026; auch InfoQ berichtete über die Ergebnisse.
Was hat Argon geändert?
Bei einer Änderung filtert ADK Gesprächsereignisse, bevor sie kopiert werden. Bisher kopierte der In-Memory-Sitzungsdienst das gesamte Gespräch und grenzte es erst danach auf die vom Aufrufer angeforderten Ereignisse ein. Die andere Änderung verzögerte das Laden umfangreicher Pakete, bis sie gebraucht wurden. Ein einfacher Textagent hatte zuvor auch Komponenten für Audio und Video, Tracing und Webserver geladen, obwohl er sie nicht verwendete.
Google zufolge sparte die Verbesserung bei Sitzungen umso mehr Zeit, je länger die Gespräche wurden. In einem Lauf mit 158 Tool-Aufrufen sank der wiederholte Kopieraufwand und damit der Overhead des Frameworks von 65,6 auf 56,1 Sekunden. Das ist die vom Framework benötigte Zeit, nicht die Zeit, die das Modell für die Aufgabe brauchte. Google zufolge beschleunigte das verzögerte Laden außerdem kalte Importe um 21 Prozent; wie viel Zeit dadurch absolut eingespart wurde, geht aus dem Beitrag jedoch nicht hervor.
Um den Lauf anzuleiten, ergänzte das Team projektspezifische Anweisungen in .agents/skills-Dateien und nutzte den /goal-Modus in Google Antigravity, damit die Aufgabe während der Sitzung im Blick blieb. Argon ermittelte Vergleichswerte für vier Arbeitslasten, schlug sechs Optimierungen vor, die sich über 32 Dateien erstreckten, und führte vor Abschluss alle 16.892 Open-Source-Unit-Tests aus.
Warum fielen vier Vorschläge bei der Prüfung durch?
Google übernahm nur zwei der sechs vorgeschlagenen Änderungen. Die übrigen vier lehnte das Unternehmen nach einer Prüfung durch Entwickler ab – unter anderem wegen Bedenken zur Zuverlässigkeit, Wartbarkeit und Kompatibilität oder weil der Geschwindigkeitsgewinn nicht aussagekräftig war. Ein abgelehnter Cache verbesserte einen synthetischen Multi-Agenten-Benchmark um 17 Prozent. Google zufolge hätte er jedoch veraltete Daten zurückgeben können, wenn Python nach einer Garbage Collection dieselbe Speicheradresse erneut verwendet hätte.
Der Lauf zeigt, was Googles Team als nützlich erachtete: Der Agent konnte Änderungen über mehrere Dateien hinweg nachvollziehen und Code für die menschliche Prüfung vorbereiten. Er zeigt nicht, dass der Agent Änderungen ohne Prüfung sicher selbstständig umsetzen und veröffentlichen kann. Laut Googles Bericht hatte ein früherer Versuch Teamkonventionen und Sonderfälle übersehen. Auch beim nächtlichen Lauf mussten die Maintainer entscheiden, welche Vorschläge sicher übernommen werden konnten.
Warum es wichtig ist
Für Softwareteams, die große Python-Projekte warten, deutet das Beispiel darauf hin, dass ein Coding-Agent dabei helfen kann, dateiübergreifend Leistungsverbesserungen zu finden – statt nur eine einzelne Funktion zu bearbeiten. Die Ergebnisse stammen aus Googles eigener Darstellung. Zudem lehnten die Entwickler vier Vorschläge ab; der Lauf belegt daher nicht, dass Teams auf Tests oder Code-Reviews verzichten können.
