KI-Agenten die Code schreiben — Hype oder Realität?

Die Diskussion, die nicht endet

Auf LinkedIn sehe ich taeglich zwei Arten von Posts. Die einen zeigen ein 30-Sekunden-Video, in dem ein KI-Agent eine komplette Anwendung baut, mit dem Kommentar “Developers are cooked.” Die anderen schreiben lange Abhandlungen darueber, warum KI niemals echte Softwareentwicklung ersetzen kann. Beide liegen falsch, und die Wahrheit ist — wie so oft — deutlich nuancierter.

Ich arbeite seit ueber einem Jahr taeglich mit KI-Coding-Agenten. Nicht als Experiment, sondern als Teil meines produktiven Workflows. Ich habe damit SaaS-Produkte gebaut, Infrastruktur automatisiert und sogar Atoo Studio selbst zu grossen Teilen mit Unterstuetzung von KI-Agenten entwickelt. Ich habe eine ziemlich gute Vorstellung davon, was funktioniert und was nicht.

Was KI-Agenten gut koennen

Scaffolding und Boilerplate

Der offensichtlichste Anwendungsfall, und der, der am zuverlaessigsten funktioniert. Ein KI-Agent kann in Minuten ein Projekt aufsetzen, das man frueher einen halben Tag lang manuell konfiguriert haette. Projekt-Struktur, Konfigurationsdateien, Build-Pipeline, Basis-Architektur — das alles erledigen Agenten zuverlaessig und schnell.

Ich nutze das taeglich. Wenn ich einen neuen Microservice brauche, beschreibe ich die Grundstruktur und lasse den Agenten scaffolden. Er erstellt die Ordnerstruktur, die Basis-Konfiguration, die Docker-Files, die CI-Pipeline und ein paar Basis-Endpoints. Innerhalb von zehn Minuten habe ich eine laufende Grundstruktur, die frueher einen Vormittag gekostet haette.

Tests schreiben

Tests zu schreiben ist eine Aufgabe, die viele Entwickler nicht gerne machen. KI-Agenten sind hier ueberraschend gut. Man gibt ihnen eine Funktion oder Klasse, und sie schreiben Unit-Tests, die Edge Cases abdecken, die man selbst wahrscheinlich uebersehen haette. Die Tests sind nicht perfekt — manchmal testen sie Implementierungsdetails statt Verhalten — aber als Ausgangspunkt sind sie ausgezeichnet.

Dokumentation

Ein weiterer Bereich, in dem KI-Agenten glaenzen. Code-Dokumentation, API-Dokumentation, README-Dateien, Kommentare — das alles erledigen sie schnell und in guter Qualitaet. Sie koennen sogar existierenden, undokumentierten Code analysieren und nachtraeglich dokumentieren. Das ist Gold wert fuer Legacy-Projekte.

Refactoring und Code-Migration

KI-Agenten sind sehr gut darin, bestehenden Code umzustrukturieren. Eine Klasse aufteilen, eine Funktion vereinfachen, Code von einem Framework zum anderen migrieren — solche Aufgaben erledigen sie zuverlaessig, solange man klare Anweisungen gibt. Ich habe kuerzlich eine Express.js-API zu Hono migriert und dabei einen KI-Agenten die meiste Arbeit machen lassen. Das Ergebnis war sauber und hat auf Anhieb funktioniert.

Bug-Fixing bei klaren Fehlern

Wenn ein Fehler klar reproduzierbar ist und die Ursache im Code liegt — ein Tippfehler, eine falsche Bedingung, ein fehlendes Null-Check — finden KI-Agenten den Fehler oft schneller als ich. Sie koennen Stack-Traces analysieren, den relevanten Code finden und einen Fix vorschlagen. Besonders gut funktioniert das, wenn der Agent Zugriff auf die Fehlermeldung und den relevanten Code-Kontext hat.

Wo KI-Agenten an ihre Grenzen stossen

Komplexe Architektur-Entscheidungen

Soll ich hier Microservices oder einen Monolith verwenden? Wie partitioniere ich meine Datenbank? Welche Konsistenzgarantien brauche ich? Diese Fragen kann ein KI-Agent nicht sinnvoll beantworten, weil sie tiefen Kontext erfordern: Teamgroesse, erwartete Last, Geschaeftsanforderungen, bestehende Infrastruktur, Budget.

Ich habe mehrfach erlebt, wie KI-Agenten bei Architektur-Fragen die “Standard-Antwort” geben — die Loesung, die in den meisten Blog-Posts empfohlen wird. Aber die richtige Architektur-Entscheidung ist fast nie die Standard-Antwort. Sie ist immer kontextabhaengig.

Domaenenspezifische Logik

Wenn ich ein Abrechnungssystem fuer die oesterreichische Sozialversicherung baue, dann brauche ich detailliertes Wissen ueber Beitragsgruppen, Bemessungsgrundlagen und Sozialversicherungsrecht. Ein KI-Agent hat dieses Wissen nicht — oder schlimmer, er hat ungefaehres Wissen und gibt zuversichtliche, aber falsche Antworten.

Je spezifischer die Domaene, desto weniger nuetzlich sind KI-Agenten. In generischen Web-Anwendungen sind sie Rockstars. In hochspezialisierten Fachdomaenen sind sie bestenfalls ein Assistent, der angeleitet werden muss.

Sicherheitskritischer Code

Authentifizierung, Autorisierung, Verschluesselung, Input-Validierung — das sind Bereiche, in denen ich KI-generierten Code mit besonderer Vorsicht behandle. Nicht weil KI-Agenten prinzipiell schlechten Sicherheitscode schreiben, sondern weil die Konsequenzen von Fehlern hier besonders hoch sind.

Ich habe gesehen, wie KI-Agenten JWT-Implementierungen vorgeschlagen haben, die technisch funktionieren, aber Sicherheitsluecken enthalten. Oder SQL-Queries, die zwar parameterisiert aussehen, aber in bestimmten Edge Cases anfaellig fuer Injection sind. Diese Fehler sind subtil und fallen nur jemandem auf, der sich mit Sicherheit auskennt.

Langfristige Konsistenz

Bei einem einzelnen Feature sind KI-Agenten gut. Aber bei einem Projekt, das ueber Monate waechst, wird es schwierig. Der Agent hat keinen Langzeit-Kontext. Er weiss nicht, warum eine bestimmte Entscheidung vor drei Monaten getroffen wurde. Er sieht nicht das grosse Bild.

Das fuehrt dazu, dass KI-generierter Code in grossen Projekten manchmal inkonsistent wird. Unterschiedliche Namenskonventionen, verschiedene Fehlerbehandlungs-Strategien, redundante Abstraktionen. Das alles laesst sich durch gutes Review abfangen, aber es erfordert Aufmerksamkeit.

Die Luecke zwischen Demo und Produktion

Die meisten beeindruckenden KI-Coding-Demos haben etwas gemeinsam: Sie zeigen Greenfield-Projekte. Ein neues Projekt von Null, eine einzelne Datei, ein isoliertes Feature. In diesem Kontext sind KI-Agenten tatsaechlich beeindruckend.

Die Realitaet sieht anders aus. Die meisten professionellen Entwickler arbeiten an bestehenden Codebasen. Sie muessen mit Legacy-Code umgehen, bestehende Architekturen respektieren, sich an Coding-Standards halten und mit Team-Konventionen arbeiten. In diesem Kontext sind KI-Agenten weniger beeindruckend, aber immer noch nuetzlich — wenn man weiss, wie man sie einsetzt.

Mein praktischer Workflow

Mein Workflow hat sich in den letzten Monaten zu einem Muster eingependelt, das gut funktioniert.

Fuer neue Features starte ich mit einer klaren Beschreibung dessen, was ich will, inklusive Kontext ueber die bestehende Architektur. Der Agent erstellt einen ersten Entwurf. Ich reviewe, gebe Feedback, und der Agent iteriert. Nach zwei bis drei Runden habe ich in der Regel brauchbaren Code, den ich dann feinschleife.

Fuer Bug-Fixes gebe ich dem Agenten den Stack-Trace, den relevanten Code und eine Beschreibung des erwarteten Verhaltens. In geschaetzt 70% der Faelle findet er den Bug und schlaegt einen korrekten Fix vor.

Fuer Refactoring beschreibe ich, was ich aendern will und warum. Der Agent fuehrt das Refactoring durch, und ich pruefe, ob nichts kaputt gegangen ist.

Fuer Architektur-Entscheidungen nutze ich KI als Sparringspartner, nicht als Entscheider. Ich diskutiere Trade-offs, lasse mir Alternativen aufzeigen und bilde mir dann meine eigene Meinung.

Fazit: Weder Hype noch Enttaeuschung

KI-Coding-Agenten sind ein maechniges Werkzeug, das die Produktivitaet signifikant steigern kann. Aber sie sind kein Ersatz fuer Entwickler-Kompetenz. Sie verstaerken, was da ist: Gute Entwickler werden mit KI-Agenten noch produktiver. Schlechte Entwickler produzieren mit KI-Agenten mehr schlechten Code, schneller.

Die narrative “KI ersetzt Entwickler” ist Unsinn. Die Realitaet ist: KI veraendert, was wir als Entwickler tun, und wie wir es tun. Und das ist weniger dramatisch und gleichzeitig tiefgreifender, als die Schlagzeilen vermuten lassen.