Antigravity 2.0: Erste Praxiserfahrungen

Die nahtlose und sichere Integration von KI-Agenten in den Alltag eines Softwareentwicklers ist aktuell eine der größten Herausforderungen für IT-Organisationen. Oft scheitert die Einführung an unklarer Governance und Sicherheitsbedenken. Vor diesem Hintergrund habe ich mich in den vergangenen Wochen privat intensiv mit Google Antigravity (AGY) beschäftigt.

Die Plattform, die im November 2025 zusammen mit den Gemini 3 Modellen vorgestellt wurde, verspricht einen Paradigmenwechsel: weg von reiner Code-Assistenz hin zu einer “Agent-First”-Entwicklungsumgebung.¹ Mit der Version 2.0, die auf der Google I/O 2026 vorgestellt wurde, fokussiert Google das Thema agentische Softwareentwicklung nun noch stärker und veröffentlicht ein auf Enterprise-Bedürfnisse zugeschnittenes Toolset.²

Während mich die Version 1.x in der Praxis noch nicht überzeugen konnte (siehe Details unten), weckte das Release der Version 2.0 aufgrund der angekündigten Änderungen mein besonderes Interesse.

Das neue Antigravity-Ökosystem im Überblick

Um die Neuerungen besser einzuordnen, lohnt sich ein kurzer Blick auf die vier Kernkomponenten des 2.0-Releases und ihren jeweiligen Platz im Werkzeugkasten:

• Antigravity 2.0: Die Standalone-Anwendung dient als zentrales Kontrollzentrum für die Orchestrierung mehrerer parallel arbeitender KI-Agenten.
• Antigravity CLI: Ein leichtgewichtiges Terminal User Interface (TUI) für die direkte Interaktion auf der Kommandozeile, welches das bisherige Gemini CLI ab Juni 2026 ersetzen soll.³
• Antigravity IDE: Eine klassische, auf VS Code basierende IDE, die den Agenten direkt in den täglichen Entwicklungszyklus einbindet und somit ein komfortables Human-in-the-Loop-Setup (HITL) ohne weitere Tools ermöglicht.
• Antigravity SDK: Der strategische Hebel für Unternehmen. Das SDK erlaubt es, Custom-Agenten zu bauen und diese z.B. compliant an interne APIs und Wissensdatenbanken anzubinden.

Praxiserfahrungen: Isolation als Schlüssel (Stand Mai 2026)

Für mich ist Kontrolle und die daraus resultierende Sicherheit im Umgang mit KI-Agenten ein zentrales Thema. Seit Antigravity 2.0 konnte ich Dev Container und WSL2 Umgebungen erstmals so stabil nutzen, dass die Antigravity IDE für meinen privaten Softwareentwicklungsalltag relevant geworden ist. In 1.x waren solche Setups zwar prinzipiell möglich, aber in meiner Praxis nur mit Workarounds nutzbar.⁴ Die Isolation ist aus meiner Sicht ein kritischer Hebel, um AGY Enterprise-ready zu machen.

Durch die strikte Kapselung mittels Dev Container kann der Zugriff des Agenten z.B. auf dedizierte Verzeichnisse eingeschränkt werden. In meinen Tests habe ich das Quellcodeverzeichnis (inklusive Versionskontrolle) als Read-Only gemountet und dem Agenten nur einen spezifischen Scratch-Workspace für Dateiänderungen freigegeben. Das stellte sicher, dass Agenten niemals eigenständig Git-Commits durchführen oder die Historie manipulieren können.

Der folgende Auszug aus meiner devcontainer.json zeigt, wie ich den Agenten-Workspace isoliert habe:

{
  //...
  "mounts": [
    "source=${localWorkspaceFolder}/src,target=/workspace/src,type=bind,consistency=cached,readonly",
    "source=${localWorkspaceFolder}/agent-scratch,target=/workspace/agent-scratch,type=bind,consistency=cached"
  ]
  //...
}

In Kombination mit restriktiven Outbound-Netzwerkregeln wird so das Risiko, dass fehlerhafte Aktionen des Agenten z.B. das Host-System kompromittieren, massiv minimiert.

Human-in-the-Loop

Der isolierte Scratch-Workspace löst auch eine weitere Anforderung: das Human-in-the-Loop-Prinzip (HITL). Änderungen werden niemals blind auf den Quellcode angewendet. Der Entwickler behält die Verantwortung und die Hoheit, womit die Codequalität durch den zwingenden menschlichen Prüfschritt gewahrt bleibt. Um die DevEx (Developer Experience) nicht zu beeinträchtigen, muss der Wechsel zwischen dem isolierten Scratch-Workspace und dem eigentlichen Quellcodeverzeichnis so reibungsarm wie möglich erfolgen. Andernfalls steigt das Risiko, dass Entwickler versuchen, die Isolation zu umgehen, um schneller arbeiten zu können.

Für meine private Entwicklungsarbeit experimentiere ich alternativ mit dem direkten Zugriff des Agenten auf den Git-versionierten Quellcode. Dabei fungiert der obligatorische Git-Workflow aus Diff, Pull Request und Code Review als agiles HITL-Sicherheitsnetz. In meiner privaten Praxis hat sich dieses Vorgehen bislang als robust erwiesen und ermöglicht gleichzeitig eine ausgezeichnete DevEx, da der Agent als eine Art Kollege wahrgenommen wird, dessen Vorschläge man in gewohnter Weise kritisch prüft und bewertet.

Integration in den Enterprise-SDLC

Um agentische Systeme in mittleren bis großen Organisationen zu etablieren, reicht die reine Isolation der Agenten jedoch nicht aus. Der gesamte Software Development Life Cycle (SDLC) muss sich anpassen und skalierbar bleiben. Hier bietet das Antigravity SDK vielversprechendes Potenzial.

Mit dem SDK lassen sich spezialisierte Agenten entwickeln, die z.B. Prüfaufträge gemäß der Coding-Richtlinien oder Sicherheitsanforderungen des Unternehmens durchführen. Diese Agenten können z.B. den Code bereits während der Entstehung auf Schwachstellen untersuchen oder Testfälle generieren. Das führt wahrscheinlich zu einem spürbaren Wandel im Arbeitsalltag: Entwickler verbringen dann weniger Zeit mit der “Code-Produktion” und fokussieren sich mehr auf intelligente Systemarchitektur und das Spec-Driven Development.

Google ist auf dem richtigen Weg

Die hohe Frequenz der Updates und die kontinuierliche Erweiterung der Funktionalitäten zeigen, dass Google das Thema agentische Softwareentwicklung sehr ernst nimmt. Mit Antigravity 2.0 macht Google einen wichtigen Schritt für den Übergang von passiven Copiloten zu aktiven, teilautonomen Entwicklungsagenten. Die Kombination aus isolierten Ausführungsumgebungen und starken HITL-Kontrollmechanismen ist für mich der richtige Weg, um das nötige Vertrauen für den Einsatz in großen IT-Abteilungen aufzubauen.