Agentic Coding: Der nächste blinde Fleck in der IT-Strategie

Wer heute noch über KI-Assistenten im Entwicklungsumfeld diskutiert, hat das Fenster für die strategisch relevante Frage bereits verpasst. Die Frage ist nicht mehr: Nutzen wir KI? Die Frage ist: Auf welcher Abstraktionsebene arbeiten unsere Entwickler – und wer entscheidet das eigentlich?

These #1

„GitHub Copilot war das Aufwärmen. Was jetzt kommt, verändert nicht das Werkzeug – es verändert die Rolle des Entwicklers. Und die meisten IT-Entscheider haben das noch nicht auf dem Radar."

Ich entwickle seit über dreißig Jahren Software – Anwendungsentwicklung, Datawarehouse, ETL-Architekturen, DWH-Modellierung, später als CIO mit Verantwortung für 85 Mitarbeiter und 15 Millionen Euro IT-Budget. Ich habe jede Technologiewelle miterlebt. Und ich sage: Was gerade passiert, ist keine inkrementelle Verbesserung.

Google Antigravity und Claude Code sind nicht bessere Code-Editoren. Sie sind der Anfang einer neuen Entwicklerrolle: vom Implementierer zum Orchestrierer. Wer das als Hype abtut, irrt – und wird das in zwei Jahren teuer bezahlen.

Was sich wirklich verändert – und warum es niemand laut sagt

Der Unterschied zwischen einem KI-Assistenten und einem KI-Agenten ist nicht graduell. Er ist kategorial.

❌ KI-Assistent (gestern)

• Schlägt Code vor – Entwickler entscheidet und tippt
• Eine Aufgabe zur Zeit, im Kontext des Editors
• Kein Verständnis für Projektziele
• Kein Testen, kein Validieren
• Entwickler bleibt Implementierer

✓ KI-Agent (heute)

• Plant, implementiert, testet, validiert – autonom
• Mehrere parallele Aufgaben gleichzeitig
• Versteht Projektziel aus natürlichsprachiger Beschreibung
• Browser-Agent validiert Ergebnisse visuell
• Entwickler wird zum Orchestrierer

Das klingt nach Feature-Marketing. Es ist keins. Der Unterschied ist erfahrbar – und er verändert, wie Teams strukturiert, wie Aufwände kalkuliert und wie Software-Qualität definiert wird.

These #2

„Agentic Coding amplifies what's already there. Wer gute Prozesse hat, wird schneller. Wer schlechte Prozesse hat, wird schneller schlecht. Der Tool-Einsatz ist die falsche Frage – die richtige ist: Sind wir bereit dafür?"

Google Antigravity: Was es ist – und was es nicht ist

Antigravity ist Googles agent-first IDE, erschienen im November 2025, entwickelt vom ehemaligen Windsurf-Team (Übernahme für 2,4 Milliarden Dollar). Kein Experiment – eine strategische Ansage.

Kernidee: Du beschreibst, was gebaut werden soll. Der Agent plant, implementiert, testet und validiert – inklusive Browser-Automatisierung. Du siehst einen Screenshot des Ergebnisses, bevor du den Editor öffnest. Mehrere Agenten arbeiten parallel.

💬Für jemanden, der jahrelang Entwicklungsteams geführt hat: Es fühlt sich an wie das Delegieren an ein kleines Team – nicht wie das Bedienen eines Tools. Das ist kein Zufall. Das ist das Design.

Was Antigravity nicht ist: ein ausgereiftes Enterprise-Tool. Public Preview bedeutet: kein Google Workspace-Account, Rate Limits, begrenzte Langzeiterfahrung. Und: Code verlässt die eigene Infrastruktur. Für alles mit sensiblem IP oder Kundendaten ist das eine bewusste Entscheidung, die vor dem Einsatz getroffen werden muss.

⚠️Sicherheitshinweis: Im Vollautonomie-Modus gab es frühe Berichte über destruktive Terminalbefehle. Review-driven Development ist kein Nice-to-have – es ist die einzige vertretbare Betriebsweise in professionellen Umgebungen.

Der direkte Vergleich: Antigravity vs. Claude Code

Der härteste Konkurrent kommt von Anthropic. Claude Code ist terminal-first, developer-controlled – und läuft dort, wo erfahrene Entwickler bereits arbeiten. Kein neues UI, kein Paradigmenwechsel nötig. Dafür: explizite Freigabe vor jeder Dateiänderung, ~30% weniger Rework als Cursor laut unabhängigen Analysen.

Die eigentliche Pointe:

Es ist keine Entweder-oder-Entscheidung. Antigravity unterstützt Claude-Modelle nativ. Wer Claude Opus 4.5 innerhalb von Antigravity wählt, kombiniert Googles Multi-Agenten-Architektur mit Anthropics Modellqualität – braucht aber einen Claude API-Key.

n8n-Nutzer aufgepasst: der unterschätzte Hebel

Wer n8n als Automatisierungsrückgrat betreibt, hat über das n8n-MCP-Protokoll einen dritten Spieler im Raum. Claude Code kann damit direkt n8n-Workflows generieren, validieren und deployen – Zugriff auf alle 1.200+ Nodes, ohne manuelle Konfiguration. Antigravity hat dieselbe Integration, Claude Code ist aktuell tiefer eingebettet.

Und: n8n mit Ollama ist nochmal eine andere Kategorie – lokale LLM-Inferenz, on-premise, DSGVO-konform, kein Cloud-Coding-Agent. Die Abgrenzung ist wichtig:

n8n + Ollama

• Lokale KI-Automatisierung ohne Cloud
• DSGVO-konform, kein Code verlässt die Infra
• Für Workflows und Prozessautomatisierung

Antigravity / Claude Code + n8n MCP

• Software bauen und Systeme entwickeln
• n8n-Workflows KI-generiert und validiert
• Für Entwicklung, nicht nur Automatisierung

Die strategische Frage, die IT-Entscheider jetzt stellen müssen

These #3

„Nicht das Tool entscheidet über den Erfolg von Agentic Development. Es entscheiden die Anforderungsqualität, die Dokumentationsreife und der Review-Prozess des Teams. Wer hier schwach ist, sollte diese Tools noch nicht einsetzen."

Drei Fragen, die vor dem Einsatz beantwortet sein müssen:

🔴Wie gut sind unsere Anforderungen formuliert? Agenten führen aus, was beschrieben wird – nicht was gemeint ist. Schwache Requirements führen zu schnell falschem Code.

🟡Wie sauber ist unsere Codebasis dokumentiert? Beide Tools amplify what's already there. Undokumentierte Systeme werden mit KI-Agenten schneller legacy.

🟢Wie reif ist unser Review-Prozess? Review-driven Development ist die einzige vertretbare Betriebsweise. Wer keinen Review-Prozess hat, schafft ihn zuerst.

Mein Fazit nach dreißig Jahren und einigen Wochen Antigravity

Jede Technologiewelle hatte zwei Gruppen: die, die früh verstanden haben, was sich strukturell verändert – und die, die auf das nächste Tool gewartet haben, bis der Markt die Entscheidung für sie getroffen hatte.

Agentic Coding ist keine Spielerei für Entwickler, die Zeit haben. Es ist eine strukturelle Verschiebung in der Frage, wie Software entsteht – und wer daran beteiligt ist. IT-Entscheider, die das ignorieren, werden in zwei Jahren erklären müssen, warum ihre Teams langsamer sind als die der Konkurrenz.

Das Tool ist nicht das Problem. Die Frage ist, ob die Organisation bereit ist, auf einer anderen Abstraktionsebene zu denken. Und diese Frage stellt sich jetzt.

Gerd Kopp - gerd@gerds-it.de - Februar 2026