Coding-Agenten

Zur Erinnerung: Ein Agent im hier gemeinten Sinne ist ein Sprachmodell, das wiederholt Werkzeuge aufruft, die Ergebnisse verarbeitet und so schrittweise auf ein Ziel hinarbeitet. Bei Coding-Agenten sind diese Werkzeuge der Compiler, die Testsuite, das Dateisystem und das Terminal. Der Agent schreibt also nicht nur Code, sondern führt ihn aus, prüft das Ergebnis und korrigiert sich selbst. Damit unterscheidet er sich grundlegend von der Autovervollständigung, wie sie GitHub Copilot bekannt gemacht hat: Heutige Coding-Agenten planen Änderungen über mehrere Dateien hinweg, führen Tests durch und iterieren eigenständig.

Von der IDE-Erweiterung zum eigenständigen Werkzeug. Die Landschaft lässt sich grob in drei Ansätze unterteilen. CLI-basierte Agenten wie Claude Code (code.claude.com) und OpenAI Codex (openai.com) arbeiten in erster Linie im Terminal, lesen die Codebasis, editieren Dateien und führen Befehle aus. Agentenerweiterte IDEs wie Cursor (cursor.com) betten den Agenten in die gewohnte grafische Entwicklungsumgebung ein. Einen dritten Ansatz verfolgt Google Antigravity: Statt einem einzelnen Agenten orchestriert es mehrere parallele Agenten über eine „Mission Control“-Oberfläche (codelabs.developers.google.com).

Viele aktuelle Coding-Agenten bieten einen vorgeschalteten Planungs- oder Analysemodus bzw. restriktive Freigabekonfigurationen, bevor sie Änderungen ausführen. Inzwischen existieren auch Cloud-Varianten, die autonom auf einem Server arbeiten und am Ende einen Pull Request öffnen – der Agent wird damit zum eigenständigen Beitragenden im Versionskontrollsystem (github.blog). Ein Vorteil gegenüber reinen Chat-Anwendungen: Compiler und Testsuiten liefern objektive Rückmeldung, an der die Agentenschleife sich verankern kann.

Neben den kommerziellen Angeboten wächst ein Open-Source-Ökosystem. Aider (aider.chat) ist ein Terminal-Agent mit tiefer Git-Integration, der mit beliebigen Sprachmodellen arbeitet – auch lokal betriebenen. OpenHands (openhands.dev), hervorgegangen aus dem Forschungsprojekt OpenDevin, verfolgt einen stärker autonomen Ansatz mit Sandbox-Isolation in Docker-Containern. OpenCode (github.com) unterstützt laut Dokumentation über 75 Modellanbieter und zählt auf GitHub inzwischen über 100.000 Sterne. Diese Werkzeuge erlauben es, Agenten mit selbst gehosteten Modellen zu betreiben – relevant für Organisationen mit hohen Anforderungen an die Datenhoheit.

Berechtigungen, Sandboxing und Policy-Dateien. Was Coding-Agenten besonders interessant macht, ist die Entstehung einer neuen Steuerungsebene. Typischerweise kommen abgestufte Berechtigungssysteme zum Einsatz: Lesezugriffe erfolgen ohne Rückfrage, Dateiveränderungen erfordern eine Freigabe, Shell-Befehle können pro Projektverzeichnis dauerhaft erlaubt werden (code.claude.com). Daneben existieren verschiedene Modi, etwa ein reiner Analysemodus oder ein expliziter Modus zur Umgehung aller Berechtigungen – mit entsprechender Warnung.

Dabei entsteht eine neue Klasse agentenbezogener Repository-Dateien: teils Kontext- und Instruktionsdateien wie CLAUDE.md, AGENTS.md oder projektbezogene Cursor Rules, teils operative Steuerungsmechanismen wie Hooks, Permission-Policies und Tool-Registrierungen. Hinzu kommen Privacy-Einstellungen mit architekturellen Folgen (cursor.com) und URL-Allowlists für den Browser-Zugriff (codelabs.developers.google.com).

Gemeinsam ist diesen Dateien, dass sie nicht nur dokumentieren, sondern das Verhalten des Systems steuern. Das Management des Inhalts dieser Dateien und des Kontexts, den ein Coding-Agent „sieht“, ist mindestens genauso wichtig wie die Qualität des verwendeten Sprachmodells. Inzwischen werden Sprachmodelle nicht nur für das Programmieren an sich, sondern auch für das agentische „Terminal Coding“ optimiert. Neben den sog. Frontier-Modellen, zu denen aktuell etwa OpenAI GPT 5.4 oder Claude Sonnet/Opus 4.6 zählen, gibt es zahlreiche weitere, auch außerhalb des US-Ökosystems: etwa MiniMax und GLM von Z.ai.  

Für das agentische Coding optimierte Modelle wissen, in welcher Umgebung sie betrieben werden, welche Tools ihnen zur Verfügung stehen und welchen Einschränkungen ihre Ausführung unterliegt. Dabei geht es nicht nur um Kommandozeilenbefehle, sondern auch um Tools, die die Ausführungsumgebung („Harness“) direkt anbietet, etwa das Einlesen und gezielte Verändern von Dateien, das Durchsuchen von Verzeichnissen sowie das Starten und Überwachen von Hintergrundprozessen und „Sub-Agenten“. Dieses Wissen vermeidet Missverständnisse und reduziert Reibungspunkte. 

Die im Code-Repository abgelegten Steuerungsdateien sind zwar nur harmlose Textdateien; sie erzeugen aber eine neue Angriffsfläche. Dies zeigte im Februar 2026 eine Untersuchung von Check Point Research: Die Forscher beschrieben, wie manipulierte Konfigurationsdateien in einem Repository dazu führen konnten, dass beim Öffnen eines Projekts Shell-Befehle ausgeführt und API-Schlüssel über umgeleitete Endpunkte exfiltriert wurden – noch bevor der Freigabedialog erschien (blog.checkpoint.com). Die Schwachstellen wurden vor der Veröffentlichung behoben. Sie verdeutlichen aber, was der Titel dieser Folge meint: Repository-Konfiguration kann heute Codeausführung bedeuten.

Das Model Context Protocol. Damit Coding-Agenten mit externen Werkzeugen kommunizieren können, wird oft das Model Context Protocol (MCP) verwendet. MCP definiert als offener Standard, wie KI-Anwendungen auf Datenquellen und Werkzeuge zugreifen, und nutzt ein Client-Host-Server-Modell (modelcontextprotocol.io).

Die Kehrseite: MCP-Server von Drittanbietern bergen Prompt-Injection-Risiken (code.claude.com). MCP-Server sind stark modularisiert, kombinierbar und leicht nutzbar – und natürlich gibt es nachlässige oder böswillige Anbieter. 

Das britische National Cyber Security Centre (NCSC) argumentiert, dass Prompt Injection nicht wie SQL Injection behandelt werden sollte – als behebbare Schwachstellenklasse. Stattdessen sei das Sprachmodell ein „inherently confusable deputy“: ein System, das Anweisungen und Daten nicht zuverlässig unterscheiden kann (ncsc.gov.uk). Das Restrisiko ist damit endemisch; der Fokus muss auf der Begrenzung der Auswirkungen liegen.

Browser als Ausführungsoberfläche. Die Integration von Browsern in Coding-Agenten schließt die Agentenschleife: bauen, ausführen, im Browser verifizieren, auf Basis von Konsolen- und Netzwerkfehlern debuggen. Beispiele sind Claude in Chrome (support.claude.com) und Google Antigravity (theverge.com). Webseiten sind dabei ebenfalls Prompt-Injection-Vektoren; URL-Allowlists dienen als Gegenmaßnahme.

Dass die Risiken real sind, zeigen Sicherheitsanalysen des Perplexity-Browsers Comet: Forscher beschrieben, wie indirekte Prompt Injection über manipulierte Webinhalte die Browser-KI zur Datenexfiltration aus verbundenen Diensten veranlassen konnte (time.com).

Unabhängig davon verklagte Amazon Perplexity 2025 wegen Comets automatisiertem Einkaufsverhalten; im März 2026 erließ ein US-Bundesgericht eine einstweilige Verfügung, die Comet den Zugriff auf Amazon untersagt – das Berufungsgericht setzte den Vollzug wenige Tage später vorläufig aus (geekwire.com). Einer der ersten großen Gerichtsfälle zu agentischem Commerce. 

Agentisches Browsen fordert bestehende Plattformmodelle heraus. Die Reaktion der IT-Branche ist nicht mehr nur eine technische, sondern wird oft von politischen und juristischen Schritten begleitet.

Einordnung und Ausblick. Der eigentliche Wandel liegt in der Entstehung einer neuen Steuerungsebene: Berechtigungssysteme, Sandboxes, Policy-Dateien, Werkzeugregistrierungen und die Auditierbarkeit agentischer Arbeit über Pull Requests und Artefakte.

Dabei ist Skepsis angebracht – auch gegenüber den Produktivitätsversprechen. Eine randomisierte Studie von METR ergab 2025, dass erfahrene Open-Source-Entwickler mit KI-Werkzeugen 19 % langsamer arbeiteten – obwohl sie selbst glaubten, 20 % schneller gewesen zu sein (metr.org). Das ist ein einzelner Datenpunkt in einem sich rasant entwickelnden Feld; neuere Werkzeuge dürften anders abschneiden. Aber die Diskrepanz zwischen Selbsteinschätzung und Messung sollte vorsichtig stimmen. Und die Check-Point-Ergebnisse zeigen: Agenten machen Entwicklerinnen und Entwickler zu Betreibern von Systemen, deren Konfigurationsdateien Codeausführung auslösen können.

In der Entwicklung zeigt sich auch ein Spannungsfeld zwischen Offenheit und Abhängigkeit. MCP als Interoperabilitätsstandard könnte Bindungen an einzelne Anbieter reduzieren; gleichzeitig vergrößert ein offenes Protokoll die Angriffsfläche. Viele verbreitete Angebote liegen preislich zwischen 20 und 200 US-Dollar pro Monat und Person; hinzu kommen je nach Produkt nutzungsabhängige Token-Kosten, die schwer vorhersagbar sind. 

Da die großen Anbieter Quellcode über US-Cloud-Infrastruktur verarbeiten, stellt sich für europäische Organisationen außerdem eine Souveränitätsfrage. Open-Source-Agenten mit lokal betriebenen Modellen sind derzeit die klarste Option für maximale Daten- und Betriebshoheit – sind den Frontier-Modellen aber oft noch unterlegen. 

Agentisches Coding rüttelt an den Grundfesten der Softwaretechnik. Bei allem Enthusiasmus ist ein verantwortungsvoller Umgang wichtig. Am Ende sind es Informatikerinnen und Informatiker, die das Ergebnis verantworten müssen.

Das bedeutet nicht unbedingt, dass jede automatisch generierte Zeile Code von einem Menschen überprüft worden sein muss – das wird in Zukunft kaum mehr zu leisten sein. Es braucht stattdessen gut benutzbare Test- und Reviewverfahren, damit wir unsere neuen Werkzeuge ohne Gefahr für andere verwenden können. 

Diesen Beitrag haben Burkhard Hoppenstedt (Hochschule für Wirtschaft und Umwelt Nürtingen-Geislingen) und Dominik Herrmann (Otto-Friedrich-Universität Bamberg) geschrieben.

Der Text erschien zuerst in unserem Newsletter GI-Radar. Alle Ausgaben gibt es hier zum Nachlesen. Sie haben auch einen Vorschlag für ein Thema? Wir freuen uns über Ihre Nachricht an redaktion@gi-radar.de.