BlogKI als Entwicklungswerkzeug, nicht als Schlagwort
Die meisten Diskussionen über KI (Künstliche Intelligenz) in der Softwareentwicklung fallen in eines von zwei Lagern: atemlose Begeisterung oder existenzielle Angst. Dieser Artikel ist weder das eine noch das andere. Ich arbeite als freiberuflicher Entwickler mit PHP, Laravel, mobilen Anwendungen (Flutter/Dart), Frontend-Frameworks, C-Programmen und mehr. Im vergangenen Jahr habe ich KI-Agenten in meinen täglichen Workflow integriert, und ich möchte konkret beschreiben, wie das aussieht — was funktioniert, was nicht, und warum.
Die wichtigste Einschränkung, die diesen Workflow prägt, wird im Hype selten erwähnt: KI-Agenten haben begrenzte Kontextfenster. Sie können nicht eine gesamte Codebasis gleichzeitig in ihrem Arbeitsspeicher halten. Das erzwingt eine Disziplin, die sich unabhängig von KI als gute Ingenieurspraxis erweist: Features in kleinere, gut definierte Einheiten aufteilen; vor der Ausführung planen; und iterativ überprüfen statt in einem großen Durchgang.
Im Folgenden wird der spezifische Workflow beschrieben, den ich verwende, die Infrastruktur, auf der er läuft, die Lektionen, die ich aus der Anwendung auf mehrere Technologie-Stacks gelernt habe, und die Fehlermodi, die Sie kennen sollten.
Claude Code und Codex
Mein primärer Planungs- und Implementierungsagent ist Claude Code von Anthropic. Er entwirft Architekturen, schreibt Ausführungspläne, generiert Code und arbeitet Aufgaben systematisch ab. Er übernimmt den konstruktiven Teil: Bei einer klaren Problemstellung und relevantem Kontext erstellt er einen Plan und setzt ihn dann um.
Mein Review-Agent ist Codex von OpenAI. Seine Rolle ist im produktiven Sinne adversarial: Er erhält den von Claude erstellten Plan und sucht nach Lücken, fehlerhaften Annahmen, fehlenden Randfällen und besseren Ansätzen. Die beiden Modelle stammen von verschiedenen Organisationen, wurden mit unterschiedlichen Daten trainiert und haben unterschiedliche Tendenzen und blinde Flecken. Dieser Unterschied ist der Punkt — das eine fängt auf, was das andere übersieht.
Jede Zeile von KI-generiertem Code manuell zu überprüfen, würde den größten Teil des Effizienzgewinns zunichtemachen. Daher wird auch das Review an einen Agenten delegiert. Meine Aufgabe ist es, einzugreifen, wenn die Agenten stecken bleiben, wenn das Ergebnis von der eigentlichen Anforderung abweicht oder wenn Domänenwissen benötigt wird, das keines der beiden Modelle besitzt. Die endgültige Entscheidung, was ausgeliefert wird, liegt immer bei mir.
Planen, überprüfen, iterieren, ausführen
Der konkrete Workflow für jedes Feature oder jede Aufgabe läuft wie folgt ab. Zunächst gebe ich Claude Code eine klare Beschreibung der Aufgabe zusammen mit relevantem Kontext: welche Dateien betroffen sind, welchen Mustern die bestehende Codebasis folgt, was das erwartete Ergebnis sein sollte. Claude erstellt einen Ausführungsplan, der die Architektur, die spezifischen Dateiänderungen und den beabsichtigten Ansatz abdeckt.
Dieser Plan geht zur Überprüfung an Codex. Codex identifiziert Probleme: fehlende Fehlerbehandlung, falsche Annahmen über den bestehenden Code, übermäßig komplexe Abstraktionen, Sicherheitslücken oder Fälle, die der Plan nicht berücksichtigt. Das Feedback von Codex geht zurück an Claude, der den Plan überarbeitet. Diese Schleife läuft typischerweise zwei- bis dreimal, bevor beide Agenten auf etwas Solides konvergieren. Wenn der Plan verschiedene Phasen oder Teilaufgaben enthält, durchläuft jede Phase denselben Review-Zyklus, bevor die nächste beginnt.
Erst wenn der Plan stabil ist, beginnt die Implementierung. Nach der Implementierung werden auch Commits überprüft — je nach Größe und Komplexität der Änderung fängt ein weiterer Agenten-Durchlauf Probleme auf, die durch die Planungsphase geschlüpft sind. Die zentrale Erkenntnis ist, dass das Iterieren an einem Plan weitaus günstiger ist als das Iterieren an geschriebenem Code. Die meisten Probleme tauchen auf, bevor eine einzige Zeile implementiert wird.
Docker, VMs und NFS
KI-Agenten generieren nicht nur Text — sie führen Code aus, installieren Abhängigkeiten, starten Tests und interagieren mit dem Dateisystem. Das auf Ihrem Host-Rechner auszuführen, ist ein Fehler, den Sie nur einmal machen. Mein Setup verwendet Docker-Container, die innerhalb einer virtuellen Maschine laufen. Projektdateien werden den Containern über ein NFS-Mount zugänglich gemacht. Die Agenten arbeiten an der echten Codebasis, ohne direkten Zugriff auf den Host zu haben.
Diese geschichtete Isolation ist in der Praxis wichtig. Wenn ein Agent ein unerwartetes Paket installiert, einen Befehl mit Nebeneffekten ausführt oder Code produziert, der zur Laufzeit lautstark fehlschlägt, ist der Wirkungsbereich auf den Container beschränkt. Die VM-Grenze ist eine zweite Eindämmungsschicht. Container können zwischen Sitzungen sauber neu aufgebaut werden, sodass kein angesammelter Zustand von einer Aufgabe die nächste kontaminiert.
Über mehrere SSH-Sitzungen in die VM ist es unkompliziert, mehrere Agenten parallel auszuführen — verschiedene Agenten für verschiedene Aufgaben oder verschiedene Agenten für verschiedene Projekte gleichzeitig. Das NFS-Setup bedeutet, dass jeder Container dieselben Dateien sieht, ohne Duplizierung oder Synchronisierungsaufwand.
Ein Workflow, viele Stacks
Die Bandbreite der Projekte, auf die ich diesen Workflow anwende, ist breiter als Sie vielleicht erwarten: Websites, Flutter/Dart-Mobilanwendungen, C-Programme, Laravel-Backends, React- und Vue-Frontends, Lernmaterialaufbereitung zum effizienten Durcharbeiten großer Inhaltsmengen und Texterstellung. Die Stacks unterscheiden sich in fast jeder relevanten Hinsicht — Sprache, Laufzeitumgebung, Build-Tools, Testansatz.
Der Plan-Review-Iterate-Workflow ist stack-agnostisch. Die Disziplin liegt im Prozess, nicht in den Werkzeugen. Entscheidend ist, dem Agenten klaren Kontext darüber zu geben, was bereits existiert, was die Aufgabe erfordert und welche Einschränkungen gelten. KI-Agenten bewältigen den Kontextwechsel zwischen Stacks besser als ich anfangs erwartet habe, vorausgesetzt, der Kontext wird explizit bereitgestellt und nicht angenommen.
Die gleiche Docker-in-VM-über-NFS-Infrastruktur unterstützt all diese Stacks mit minimaler Neukonfiguration. Das Container-Image ändert sich; der Workflow nicht.
Warum zwei Modelle besser sind als eines
Die Wirksamkeit des Dual-Agenten-Reviews liegt darin begründet, dass jedes Modell unterschiedliche Trainingsdaten, unterschiedliche Architekturentscheidungen und unterschiedliche Tendenzen in der Problemlösung hat. Claude neigt zu Gründlichkeit und übertechnisiert manchmal Lösungen. Codex ist oft direkter und weist darauf hin, wenn Claude Komplexität hinzugefügt hat, die das Problem nicht erfordert. Das Umgekehrte passiert ebenfalls: Codex kann Randfälle übersehen, die Claude auffängt, wenn die Rollen vertauscht werden.
Die adversariale Dynamik — ein Agent baut, ein anderer sucht aktiv nach Problemen — spiegelt wider, was in einem funktionierenden menschlichen Code-Review-Prozess geschieht. Konkret fängt die Review-Schleife regelmäßig Folgendes auf: fehlende Fehlerbehandlung für unübliche, aber gültige Eingaben, zu großzügige Konfigurationen, falsche Annahmen darüber, wie bestehender Code funktioniert, Abstraktionen, die technisch korrekt, aber schwieriger zu warten sind als eine einfachere Alternative, und Sicherheitsprobleme, die leicht zu übersehen sind, wenn Sie sich auf die Funktionalität konzentrieren.
Dies ist keine Behauptung, dass ein Modell dem anderen überlegen ist. Der Wert liegt in der Kombination. Zwei Agenten mit unterschiedlichen blinden Flecken, in einer expliziten Review-Beziehung, produzieren ein stärkeres Ergebnis als jeder einzelne allein.
Eine naheliegende Frage ist, ob das Hinzufügen eines dritten Agenten die Ergebnisse weiter verbessern würde. In der Praxis nimmt der Ertrag stark ab. Ein dritter Agent, der denselben Plan überprüft, würde entweder einem der beiden bestehenden zustimmen — und keine neue Information hinzufügen — oder eine dritte Meinung einbringen, die einen Schiedsrichter erfordert, was die Konvergenz verlangsamt statt sie zu unterstützen. Zwei Agenten decken bereits die konstruktive und adversariale Rolle über mehrere Review-Runden ab. Die einzige Ausnahme ist das Commit-Review nach der Implementierung, das mit einem anderen Kontext arbeitet (tatsächlicher Code statt eines Plans) und wirklich von einem frischen Blick profitiert. Darüber hinaus erhöht das Stapeln weiterer Agenten auf dieselbe Aufgabe die Token-Kosten und Latenz ohne proportionalen Qualitätsgewinn.
Der Entwickler bleibt im Prozess
Das Delegieren von Planung, Implementierung und Review an KI-Agenten bedeutet nicht, dass der Entwickler verschwindet. Ich bleibe der endgültige Entscheidungsträger für jedes Ergebnis. Die Agenten erstellen Vorschläge; ich entscheide, was committet wird. Diese Unterscheidung ist wichtig.
In der Praxis greife ich an mehreren Stellen ein: wenn Agenten in einer Schleife über denselben Dissens laufen, ohne zu konvergieren, wenn der Plan von der eigentlichen Anforderung abgedriftet ist, wenn eine Entscheidung Domänenwissen oder Geschäftskontext erfordert, den die Agenten nicht haben, und wenn das Ergebnis einfach nicht richtig aussieht, auch wenn ich nicht sofort artikulieren kann warum. Den letzten Punkt sollte man ernst nehmen — Entwickler-Instinkt, der über Jahre der Arbeit an einer Codebasis entstanden ist, ist etwas, das ein Agent nicht hat.
Die Rolle verschiebt sich vom Schreiben jeder Zeile hin zum Lenken, Validieren und Kurskorrigieren. Es ähnelt eher einem Tech Lead mit sehr schnellen Junior-Entwicklern als dem Ersatz durch Automatisierung. Die Effizienz entsteht durch strukturierte Aufsicht, nicht durch deren Abschaffung.
Qualität rein, Qualität raus
Die Qualität dessen, was ein KI-Agent produziert, ist eine direkte Funktion der Qualität dessen, was Sie ihm geben. Vage Aufgabenbeschreibungen produzieren vage Ergebnisse. Eine Anweisung wie „den Authentifizierungsfluss verbessern“ wird etwas produzieren — aber ob es etwas Nützliches ist, hängt vollständig davon ab, welchen Kontext Sie über den bestehenden Ablauf bereitstellen, was konkret verbessert werden soll und welche Einschränkungen gelten.
Guter Kontext umfasst: eine präzise Beschreibung dessen, was getan werden muss, die relevanten Dateipfade, die bereits im Projekt verwendeten Muster, etwaige Einschränkungen (Leistung, Abwärtskompatibilität, Coding-Standards) und wie ein erfolgreiches Ergebnis aussieht. Das Verfassen dieses Kontexts kostet Zeit, aber es ist gut investierte Zeit. Agenten mit klarem Kontext erstellen Pläne, die weniger Überarbeitungszyklen erfordern.
Effektiven Kontext zu schreiben ist eine Fähigkeit, die sich mit der Übung verbessert. Frühe Versuche neigen dazu, unterspezifiziert zu sein, und Sie iterieren mehr. Spätere Versuche sind präziser, und die Plan-Review-Schleife konvergiert schneller. Kontext für einen KI-Agenten zu strukturieren ist eng verwandt mit dem Schreiben eines guten Tickets für einen menschlichen Entwickler: Wenn Sie nicht klar erklären können, was Sie wollen, liegt das Problem nicht am Werkzeug.
Wenn KI sich irrt
KI-Agenten sind nicht unfehlbar, und sie als solche zu behandeln ist der Punkt, an dem Projekte scheitern. Sie halluzinieren — beschreiben selbstsicher APIs oder Bibliotheken, die nicht existieren. Sie bleiben in Schleifen stecken, wenden denselben Fix wiederholt an, wenn er nicht funktioniert. Sie produzieren Code, der plausibel aussieht, aber falsch ist, und sie verteidigen manchmal falsche Ansätze mit scheinbarer Überzeugung.
Häufige Fehlermuster, die ich erlebt habe: Ein Agent versucht wiederholt einen Fix, der die Ursache nicht behebt; ein Agent erfindet eine Funktion oder Methode, die in der verwendeten Bibliothek nicht existiert; ein Agent missversteht die bestehende Codebasis trotz bereitgestelltem Kontext, weil der Kontext unvollständig oder irreführend war. Diese Muster frühzeitig zu erkennen ist wichtig. Wenn das Ergebnis aufhört, Fortschritte zu machen, oder sich im Kreis dreht, ist es kontraproduktiv, die Schleife weiter zu füttern.
Wenn das passiert, ist die richtige Reaktion einzugreifen: den Kontext zurücksetzen, das Problem umformulieren, die Aufgabe in einen kleineren Abschnitt aufteilen, der leichter zu durchdenken ist, oder diesen Teil manchmal einfach manuell erledigen. Wenn das Ergebnis schlicht schlecht ist, werfen Sie es weg und fangen Sie neu an. Sunk-Cost-Denken gilt nicht für generierten Code — es steckt keine Handwerkskunst darin, die es wert wäre, bewahrt zu werden.
Der Planning-First-Workflow reduziert diese Fehler, weil die meisten Probleme während der Planungsphase auftreten, bevor irgendeine Implementierung stattgefunden hat. Ein schlechter Plan ist viel günstiger zu verwerfen als schlechter Code.
KI-Agenten sicher betreiben
KI-Agenten, die Code ausführen, Pakete installieren und ins Dateisystem schreiben, müssen in einer isolierten Umgebung laufen. Das ist nicht optional. Das Docker-in-VM-Setup, das ich verwende, bietet geschichtete Eindämmung: Unerwartetes Verhalten eines Agenten betrifft den Container, nicht den Host. Die VM-Grenze bietet eine zweite Schicht. Selbst wenn innerhalb eines Containers etwas gravierend schiefgeht, bleiben der Host-Rechner und andere Projekte unberührt.
KI-generierter Code kann Sicherheitslücken einführen: SQL-Injection durch unsachgemäß parametrisierte Abfragen, unsichere Standardkonfigurationen, zu weitreichende Datei- oder Netzwerkzugriffe, fehlende Eingabevalidierung. Die Review-Schleife hilft, diese aufzufangen, eliminiert sie aber nicht. Bewusstsein und ein sicherheitsbewusstes abschließendes Review bleiben notwendig.
Eine Praxis, die es wert ist, explizit genannt zu werden: Geben Sie keine sensiblen Zugangsdaten, API-Schlüssel oder Produktionsdaten in KI-Agenten-Kontexte ein, es sei denn, die Umgebung ist ordnungsgemäß gesichert und Sie verstehen, wohin diese Daten gelangen. Der Komfort, einem Agenten vollen Kontext zu geben, ist real, aber das Risiko, dies unvorsichtig zu tun, ebenfalls.
Ein praktisches Werkzeug, kein Ersatz
KI-Agenten sind ein Kraftmultiplikator für Entwickler, die Struktur und Disziplin auf den Prozess anwenden. Das begrenzte Kontextfenster — oft als Einschränkung zitiert — erzwingt tatsächlich eine Disziplin, die unabhängig davon wertvoll ist: sorgfältig planen, in gut abgegrenzten Einheiten arbeiten, vor der Ausführung überprüfen. Das sind gute Ingenieurspraktiken mit oder ohne KI-Beteiligung.
Der in diesem Artikel beschriebene Workflow ist nicht theoretisch. Er wurde auf Websites, Flutter-Mobilanwendungen, C-Programme, Laravel-Backends, React- und Vue-Frontends, Lernmaterialaufbereitung und Texterstellung angewandt. Der Prozess passt sich dem Stack an; der Stack bestimmt nicht den Prozess.
Der Entwickler, der das Problem versteht, den Prozess lenkt und das Ergebnis validiert, ist immer noch derjenige, der das Resultat liefert. KI-Agenten machen das schneller. Sie machen es nicht überflüssig.
