Google hat seiner Entwicklungsumgebung Antigravity einen neuen Befehl namens /boost hinzugefügt. Wer ihn aufruft, startet statt eines einzelnen Coding-Assistenten eine Multi-Agenten-Reasoning-Pipeline: Ein Orchestrator liest das Problem und zerlegt es in Aufgaben, verteilt sie an spezialisierte Agenten, die in isolierten Bereichen arbeiten, und schickt das Ergebnis dann durch unabhängige Verifikationsrunden, die die Tests tatsächlich ausführen, bevor irgendetwas bei Ihnen ankommt. Die eigentliche Nachricht ist nicht, dass KI schneller Code schreibt. Sondern dass Coding-Tools begonnen haben, die Verifikation in das Tool selbst einzubauen.

Was Google tatsächlich angekündigt hat

Laut der offiziellen Antigravity-Dokumentation ist /boost gezielt für anspruchsvolles Software-Engineering gedacht: Nebenläufigkeitsfehler und Race Conditions, algorithmische Optimierung, subtile Regressionen, die auftauchen und wieder verschwinden, und verwickelte Refactorings über mehrere Dateien hinweg. Genau an diesen Problemen scheitert ein herkömmlicher Assistent mit einem einzigen Durchgang, denn ihre Lösung erfordert Experimentieren und Zurückgehen statt direkter Generierung.

Der Befehl läuft in drei klaren Phasen ab:

  • Planung: Ein primärer Orchestrator nimmt Ihren Prompt entgegen, untersucht den Kontext des Workspace, entwickelt eine Ausführungsstrategie und zerlegt die Aufgabe in einzelne, überprüfbare Teilaufgaben.
  • Verteilte Ausführung: Der Orchestrator verteilt diese Teilaufgaben an spezialisierte Agenten. Implementierungsstränge schreiben Code und Unit-Tests. Untersuchungsstränge betreiben Ursachenanalyse beim Debugging und verfolgen Aufrufgraphen, ohne eine einzige Datei zu verändern. Lokale Verifikationsagenten führen Build-Ziele und Testsuiten aus, um Hypothesen zu prüfen, bevor sie Bericht erstatten.
  • Verifikation vor der Auslieferung: Der Orchestrator führt die Ergebnisse zusammen und fährt Regressionsprüfungen gegen die vollständigen Testsuiten und Randfälle. Schlägt eine Assertion fehl, fließt die Fehlerdiagnose in die nächste Iteration zur automatischen Korrektur ein, und Sie erhalten erst dann eine Zusammenfassung der verifizierten Änderungen, wenn alles besteht.

All das läuft in kurzlebigen, isolierten Worktrees, das heißt, die Agenten experimentieren nicht an Ihrer Arbeitskopie des Projekts.

Drei Modi, nicht einer

Google dokumentiert drei verschiedene Ausführungsmodi, und der Unterschied zwischen ihnen ist der praktisch nützliche Teil:

  • Standard-Agent: interaktives Programmieren, Navigation in der Codebasis und allgemeines Refactoring. Aufgabenhorizont von Sekunden bis Minuten, eine Einzelagenten-Schleife, Verifikation in einem Durchgang. In allen Tarifen verfügbar.
  • /boost: tiefes Reasoning und hartnäckige Bugs. Aufgabenhorizont von Sekunden bis Stunden, eine dreiphasige Hierarchie, unabhängige Verifikation über mehrere Runden. In den kostenpflichtigen Tarifen verfügbar.
  • /teamwork-preview: Agententeams, die tagelang an großen Migrationen oder dem Aufbau ganzer Subsysteme arbeiten, mit benannten Rollen wie Explorer, Worker, Critic und Auditor sowie Verifikationsschranken, die gezielt versuchen, den Code zu brechen, bevor ein Meilenstein freigegeben wird.

Beachten Sie das Gefälle: Je größer die Aufgabe, desto mehr fließt die Investition in die Prüfung statt in die Geschwindigkeit. Das ist ein Signal, auf das jeder achten sollte, der ein Softwareprojekt verantwortet.

Warum das für Unternehmer wichtig ist, nicht nur für Entwickler

In den vergangenen zwei Jahren war die Diskussion über KI in der Programmierung eine Diskussion über Geschwindigkeit: wie viele Zeilen pro Minute generiert werden. Das Problem ist, dass Geschwindigkeit in echten Projekten nicht der Engpass ist. Vertrauen ist es. Funktioniert dieser Code wirklich in den Fällen, die niemand ausprobiert hat?

Was die Architektur von /boost implizit aussagt, ist, dass die Branche zum selben Schluss gekommen ist. Code, der schneller ankommt, ist nichts wert, wenn er nach der Auslieferung zwei Wochen Debugging kostet. Deshalb ist das Tool um drei Regeln herum gebaut, die für jedes technische Team gelten, mit oder ohne KI:

  • Der Autor benotet nicht seine eigene Arbeit: Wer prüft, ist getrennt von dem, der umgesetzt hat. Das ist seit Jahrzehnten das Prinzip hinter Code-Reviews. Jetzt wird es im Tool selbst durchgesetzt.
  • Beweis heißt Ausführung, nicht Behauptung: Tests werden tatsächlich ausgeführt und ihre echte Ausgabe wird geprüft, statt die Behauptung zu akzeptieren, sie seien bestanden.
  • Isolation schützt das Original: Experimentiert wird in einer separaten Kopie, sodass fehlgeschlagene Versuche nie ins Projekt durchsickern.

Wenn Sie Softwareentwicklung einkaufen, sind das genau die drei Fragen an Ihren Anbieter: Wer prüft, was ist der Beweis, dass die Tests bestanden wurden, und wo findet das Experimentieren statt?

Was sich nicht ändert

Man kann eine solche Nachricht leicht als Ankündigung lesen, dass Ingenieure nicht mehr gebraucht werden. Die Dokumentation sagt ganz deutlich das Gegenteil: Agenten übernehmen die für Ihren Workspace konfigurierten Dateizugriffsregeln und Richtlinien für Befehlsberechtigungen, und jeder geschützte Befehl oder jede Änderung außerhalb vertrauenswürdiger Bereiche löst eine Autorisierungsanfrage an den Nutzer aus. Am Ende der Kette steht ein verantwortlicher Mensch.

Und Berechtigungen sind die kleinere Hälfte davon. Ein Agent löst das Problem, das Sie beschrieben haben. Er kann nicht wissen, dass die Beschreibung selbst falsch war. Er weiß nicht, dass Ihr Abrechnungszyklus am 25. und nicht am 30. schließt, dass dieses Feld für einen Vertriebsmitarbeiter niemals sichtbar sein darf oder dass Ihr Kunde mit "Auftrag" etwas anderes meint als Sie. Anforderungen definieren, die Domäne verstehen und die Entscheidung verantworten bleiben vollständig menschliche Arbeit.

Wie wir das bei Origami sehen

Wir behandeln Multi-Agenten-Tools wie jedes Produktivitätswerkzeug: Sie beschleunigen die Ausführung, sie übertragen keine Verantwortung. Ein Projekt durchläuft bei uns weiterhin schriftliche Spezifikationen, menschliche Prüfung, eine Testsuite und eine Staging-Umgebung vor der Produktion, egal ob ein Mensch den Code geschrieben oder ein Agent ihn generiert hat. Ein Tool, das seine eigenen Tests ausführt, ist eine willkommene Ergänzung dieser Kette, aber es ist ein Glied darin, kein Ersatz dafür.

Die praktische Erkenntnis für Unternehmer: Rechnen Sie damit, dass sich Lieferzeiten gerade bei komplexer Arbeit verkürzen, aber akzeptieren Sie keine Übergabe ohne Tests, ohne Dokumentation und ohne menschlichen Verantwortlichen. Tools, die sich selbst prüfen, heben die Obergrenze der erreichbaren Qualität. Sie nehmen Ihnen nicht die Notwendigkeit, jemanden zu haben, der garantiert, dass das Gebaute dem entspricht, was Sie bestellt haben.

Quellen