Agentebasiertes Engineering und der äußere Kreislauf: Wo Antigravity und Agents CLI passen.

Der nächste Schritt in der Entwicklung künstlicher Intelligenz hängt weniger von leistungsstärkeren Modellen ab und mehr von effektiveren Ingenieursystemen. Auf der Sequoia Ascent 2026 beschrieb Andrej Karpathy, wie die Branche vom „Vibe Coding“ zu einem agilen Ingenieurwesen übergeht. In diesem Ansatz erstellen Menschen die Spezifikationen, die Bewertungsschleifen sowie die Sicherheitsmechanismen, während Agenten begrenzte Teile der Implementierung übernehmen.

Der Wandel ist wichtig, weil KI die Disziplin des Softwareengineering nicht ersetzt. Sie verstärkt vielmehr bereits vorhandene Disziplinen. Googles DORA-Forschung sowie entsprechende Plattformrichtlinien deuten in dieselbe Richtung: Organisationen mit soliden ingenieurwissenschaftlichen Grundlagen profitieren mehr von kI-gestützten Arbeitsabläufen als solche mit schwachen Prozessen und unzureichender Überprüfung. Die Einführung von KI-Entwicklungstools ist weit verbreitet, doch das Vertrauen nicht. Der begrenzende Faktor ist nicht mehr das Modell selbst, sondern das umgebende System: Spezifikationen, Bewertungen, der Bereitstellungsprozess sowie eine Governance-Ebene. Agentic Engineering ist die Praxis des Aufbaus dieses Systems.

Was Agentic Engineering bedeutet

Kurz gesagt handelt es sich um eine strukturierte Methode zur durch KI unterstützten Entwicklung, bei der Menschen für die Architektur, Qualität und Korrektheit verantwortlich sind, während Agenten begrenzte Implementierungsaufgaben innerhalb definerter Grenzen erledigen. Karpathy nannte drei Säulen.

Spezifikationen zuerst. Bevor ein Agent Code schreibt, formuliert der Ingenieur das Ziel, die Einschränkungen sowie die Erfolgskriterien in einer maschinenlesbaren Spezifikation. Ein strukturierter Vertrag zwischen Mensch und Agent ersetzt eine vage Anweisung.

Bewertung vor Vertrauen. Ein erfolgreicher Ausführungsversuch sagt nichts über die Zuverlässigkeit aus. Agenten müssen anhand strukturierter Bewertungsdatensätze getestet werden, wobei Metriken sowie Methoden mit KI als Richter verwendet werden, damit die Leistung vor der Bereitstellung wiederholbar ist.

Schutzmechanismen und Sandbox-Umgebungen. Ein Agent sollte sich in einer sicheren Sandbox mit expliziten Berechtigungen, Tool-Hooks sowie Richtlinienkontrollen befinden, damit die Ausführung nicht unüberwacht stattfinden kann. Derzeit schaffen nur 12 Prozent der Pilotprojekte mit Unternehmens-KI-Agenten den Übergang in die Produktion – und die Modelle sind dabei meist nicht der Hauptgrund. Die Infrastrukturmängel liegen in fehlenden Sandbox-Umgebungen, keinem Geheimnis-Scanning sowie keiner Richtlinienkontrolle.

Der Stand der aktuellen Programmierwerkzeuge

Jede ehrliche Bewertung beginnt damit, die Stärken der heutigen KI-Programmierwerkzeuge anzuerkennen – und diese sind beeindruckend.

Sie überzeugen bei arbeitsteiligen Aufgaben im Inneren des Programms: Sie zerlegen Aufgaben, bearbeiten mehrere Dateien, führen lokale Terminalbefehle aus und korrigieren sich selbst bei Compilerfehlern. Sie haben längst die einfache Codegenerierung und Autocomplete-Funktionen hinter sich gelassen.

Die innere Schleife ist jedoch nur die Hälfte davon. Enterprise-Teams fragen nicht mehr, ob ein Agent Code schreiben und bearbeiten kann, denn im Jahr 2026 können das fast alle wichtigen Tools. Die schwierigere Frage ist die äußere Schleife: Wie bewertet, implementiert, überwacht und steuert eine Organisation Agenten, sobald sie den lokalen Terminal eines Entwicklers verlassen haben. Genau da ändert sich die Diskussion. Der strukturelle Unterschied sieht so aus:

Nichts davon macht die anderen Tools schlechter. Als Engine für die Ausführung in der inneren Schleife gehören sie weiterhin zu den besten verfügbaren Lösungen. Doch Codegenerierung ist nur der Ausgangspunkt, und Tools, die für den lokalen Terminal eines Entwicklers optimiert sind, sind nicht von vornherein dafür konzipiert, den gesamten Lebenszyklus der äußeren Schleife zu verwalten. Um im Jahr 2026 erfolgreich zu sein, reicht es nicht aus, fähige Agenten zu erstellen – es braucht auch Infrastruktur zur Bewertung, Implementierung und Steuerung dieser Agenten in der Produktion.

Agents CLI als Einstiegspunkt

Googles Ansatz basiert auf einer einzigen Gestaltungsentscheidung. Agents CLI soll mit jedem Code-Assistenten zusammenarbeiten, und das ist eine Stärke der Architektur, keine Schwäche. Bei der Installation werden sieben Kernfähigkeiten hinzugefügt, die auf dem Agent Development Kit (ADK) beruhen und Bereiche wie Projektstrukturierung, Bewertung, Scoring mit LLMs als Urteilsinstanz, Laufzeitkonfiguration, Deployment in Cloud Run sowie Observabilität über Cloud Trace umfassen. Ein Nutzer von Claude Code oder Cursor kann agents-cli scaffold, agents-cli eval und agents-cli deploy etwa genauso leicht verwenden wie ein Nutzer von Antigravity.

Das ist beabsichtigt. Google konkurriert nicht auf der Ebene der Code-Generierung. Das Unternehmen setzt darauf, dass der Wert des agilen Engineerings vom Frontend, wo Code geschrieben wird, in das Backend verlagert wird – dorthin, wo Agenten ausgeführt, überwacht und gesteuert werden. Unabhängig davon, welches Frontend ein Entwickler wählt, führen die CLI-Befehle immer zum selben Ziel:

• agents-cli deployt Ziele wie Cloud Run, GKE oder Agent Engine, die allesamt zu GCP gehören.
• agents-cli observe sendet Telemetriedaten an Cloud Trace und BigQuery, ebenfalls Teil von GCP.
• agents-cli publish registriert Agenten im Agent Registry, ebenfalls ein GCP-Dienst.
• Auch die Governance-Schicht mit Model Armor, Agent Identity und Policy Gates läuft auf GCP.

Die CLI ist somit der Einstiegspunkt, und GCP ist das Endziel. Jeder Code-Assistent, der sie verwendet, wird zu einem GCP-Klienten für den Produktivlebenszyklus. Deshalb stärkt „Es funktioniert auch mit Cursor“ die Strategie anstatt sie zu untergraben: Google benötigt nicht, dass jemand den Editor wechselt, sondern nur, dass die Produktion auf GCP läuft – und die CLI macht diesen Weg für alle Tools so reibungslos wie möglich.

Drei konzentrische Schichten

Das Google-Ekosystem ist in drei verschachtelte Ebenen gegliedert. Jede Ebene fügt weitere Funktionen hinzu, ohne dass bestehende Tools aufgegeben werden müssen.

Die innerste Ebene ist Agents CLI, kompatibel mit Cursor, Claude Code, Codex, Copilot, Antigravity oder allen anderen Tools, die Skill-Integration unterstützen. Sie bietet eine standardisierte Methode zum Aufbau von Projekten (agents-cli scaffold), eine strukturierte Bewertung durch einen LLM-Juror (agents-cli eval), die Bereitstellung auf Cloud Run oder GKE mit einem einzigen Befehl (agents-cli deploy) sowie eine automatische Einrichtung der Cloud Trace-Überwachung (agents-cli observe). Es fehlen jedoch Multi-Agent-Orchestrierung, persistente Kontextverwaltung sowie eingebaute Überprüfungsmechanismen. Der Vorteil für Nutzer: Sie können ihren Lieblingseditor beibehalten, einen wiederholbaren Weg vom Prototyp bis zur Produktion nutzen und akzeptieren, dass die Produktion auf GCP abläuft.

Jedes Tool, das die Agents CLI verwendet, benötigt eine Cloud-Schicht, da dort die Agenten tatsächlich ausgeführt werden. Sie besteht aus:

• Cloud Run, GKE sowie der Agent-Plattform für skalierbares, verwaltetes Hosting
• Cloud Trace zur vollständigen Verfolgung des Ausführungspfades mit OTel-konformen Telemetriedaten
• BigQuery Agent Analytics für Dashboards zu einer gesamten Flotte von eingesetzten Agenten
• Agent Registry, ein zentrales Katalogsystem zur Verwaltung, Versionierung und gemeinsamen Nutzung von Agenten
• Model Armor, das Datenlecks verhindert und unsichere Inhalte filtert
• Agent Identity mit kryptografischen IDs, die an überprüfbare menschliche Identitäten oder Service-Prinzipale gebunden sind
• Das Agent2Agent (A2A)-Protokoll zur Kommunikation zwischen Agenten bei der Koordination einer Flotte

Der Grund dafür ist, dass eigenständige Code-Assistenten in der Regel auf externe Cloud-Infrastrukturen für die Produktivumsetzung, Überwachbarkeit und Verwaltung angewiesen sind und keinen integrierten Unternehmens-Runtime bieten. Das ist ein struktureller Aspekt und kein Wettbewerbsaspekt. Claude Code konkurriert nicht mit Cloud Run, da sich die beiden auf unterschiedlichen Ebenen befinden.

Was Antigravity hinzufügt

Falls jeder Subagenten und Kontextdateien hat – was unterscheidet dann Antigravity? Die Antwort liegt nicht in einer einzigen Funktion, sondern in der vertikalen Integration mit der Produktivumgebung.

Die Subagenten in Claude Code arbeiten innerhalb der Terminalumgebung: Sie schreiben Code, führen Tests durch und erzeugen Ausgaben. Das Bereitstellen dieses Codes, das Echtzeit-Überwachen, die Verwaltung einer Flotte von Agenten sowie die Koordination der Agenten über verschiedene Dienste obliegen dem Benutzer, denn Claude Code weiß nichts über die Cloud Run-Instanzen, den Observability-Pipeline oder die geltenden Governance-Richtlinien. Es handelt sich dabei um ein Entwicklungswerkzeug. Die Subagenten von Antigravity können mehr:

• Bereitstellen direkt in Cloud Run, GKE oder die Agentenplattform über die Agents CLI – schließlich handelt es sich dabei um ein eigenständiges Tool und kein Drittanbieter-Plugin.
• Telemetriedaten aus Cloud Trace abfragen, während man debuggt – Antigravity kann schließlich GCP-Observability-Daten lesen.
• Fertige Agenten im Agent Registry registrieren, da die Veröffentlichung ein integrierter Workflow ist.
• Sich über das A2A-Protokoll mit den bereitgestellten Agenten koordinieren, da die Kommunikationsschicht zum selben Ökosystem gehört.

Claude Code’s Subagenten sind leistungsstarke Entwicklungstools, während die von Antigravity solche Tools sind, die sich des Produktionsumfelds bewusst sind, da sie denselben Anbieterstack teilen. Es werden vier Fähigkeiten genannt, die derzeit von anderen Tools nicht erreicht werden:

1. Mehrschichtige Kontinuität: Der Kontext eines Agenten erstreckt sich über die Desktop-IDE, die CLI, das SDK für programmatische Nutzung sowie die verwaltete API. Ein Workflow kann in der IDE beginnen, im Terminal fortgesetzt werden und von CI/CD aus ausgelöst werden. Claude Code ist hauptsächlich im Terminal aktiv, während Cursor sich auf die IDE konzentriert.
2. Integration der First-Party-Agenten in die CLI: Funktionen wie Scaffold, Eval, Deploy und Observe wurden gemeinsam mit Antigravity entwickelt, sodass der Agent die CLI nativ kennt und Lebenszykluskommandos ohne zusätzliche Prompt-Engineering-Anpassungen verknüpfen kann.

Kontext, der GCP kennt. Agenten können Cloud Trace-Daten, Einträge aus dem Agent Registry sowie Deployment-Metadaten in ihren Arbeitskontext einbeziehen, sodass ein Agent, der ein Produktionsproblem aufspürt, Telemetriedaten lesen, die Konfiguration des eingesetzten Agenten überprüfen und in einer Sitzung Lösungen vorschlagen kann.

Unternehmensweite Auffindbarkeit. Viele benutzerdefinierte Agenten bleiben hinter privaten Endpoint-URLs isoliert, sind nur für ihre Ersteller erreichbar und erfordern manuell geteilte Anmeldeinformationen. Ein natives Veröffentlichungspipeline löst dieses Problem: Wenn man der CLI anweist, einen Agenten bei Gemini Enterprise zu registrieren, ruft dies den Befehl agents-cli publish auf, wodurch der Agent als sicheres, auffindbares Tool innerhalb der Gemini Enterprise-App in der gesamten Organisation sichtbar wird. Ein natives IAM-System steuert den Zugriff, und Teams können es nutzen, ohne eigene Infrastruktur bereitzustellen.

Vergleich der Ökosysteme

Zur Veranschaulichung zeigt die folgende Tabelle, an welchen Stellen die Tools äquivalent sind und wo sie voneinander abweichen.

In der oberen Hälfte des Vergleichs konvergieren die drei Ökosysteme architektonisch – mit guter Codegenerierung, paralleler Orchestrierung von Subagenten sowie verwalteten Cloud-Sandboxen für langlaufende Aufgaben. In der unteren Hälfte behauptet Google einen zusätzlichen Unternehmenswert. Während konkurrierende Plattformen Code, Daten und Anmeldeinformationen in proprietäre Drittanbieter-Runtimes verschieben, ermöglicht Google es einer Organisation, Agenten innerhalb ihres eigenen Google Cloud-Umfelds mithilfe von Agent Runtime, Agent Identity, Model Armor und Agent Registry auszuführen, zu identifizieren, zu authentifizieren, zu verwalten und zu überwachen. Diese Trennung zeigt sich in der Praxis: GCP-eigene Telemetriedaten, eine einheitliche Deployment-Lösung für vier Ebenen sowie standardmäßige Governance-Funktionen für Modelle.

Ehrlich gesagt nähert sich die lokale Fähigkeit zum inneren Loop an einem Gleichgewicht an, während in der Infrastruktursschicht eine Lücke durch fehlende vertikale Integration entsteht.

Wie man sich entscheidet

Das Entscheidungsframework für Führungskräfte und Ingenieure ist einfach. Ein Team, das sich hauptsächlich darauf konzentriert, den inneren Loop zu beschleunigen, sollte weiterhin seine aktuellen Tools verwenden. Claude Code, Cursor und Copilot sind hervorragend und verbessern sich monatlich weiter. Für ihre Lebenszyklusfunktionen kann Agents CLI hinzugefügt werden, wobei die Bereitstellung auf GCP erfolgen kann, sobald das Team bereit ist.

Organisationen, die von kI-gestütztem Programmieren zu agentgesteuerten Workflows wechseln, haben andere Anforderungen. Flottenmanagement, qualitätsorientierte Bewertung, Regulierungsanforderungen in bestimmten Branchen sowie Koordination mehrerer Agenten erfordern eine andere Architektur – Google gehört zu den wenigen Anbietern, die einen vertikal integrierten Stack von Programmieragenten über Bewertung, Bereitstellung, Überwachbarkeit bis hin zu Governance anbieten.

Der Fall hängt nicht von der Überlegenheit des Modells ab, da die Modelle zusammenwachsen. Er hängt vielmehr von der Integration in die Infrastruktur ab: vom Abstand zwischen dem Schreiben von Agentencode und dem Betrieb von Agentenflotten in der Produktion. Google hat diesen Abstand stärker verringert als jeder andere, unabhängig davon, mit welchem Editor ein Team beginnt.