Agentic Coding in der Praxis: Warum KI ohne Quality Gates kein Entwicklungskonzept ist

Was bedeutet Agentic Coding?

Agentic Coding ist keine automatische Code-Vervollständigung durch KI. Es geht nicht darum, dass eine Entwicklungsumgebung ein paar Zeilen Code ergänzt oder Methoden vorschlägt.

Der Anspruch ist deutlich größer: Ein Coding Agent soll komplexere Arbeitsaufgaben auf Basis einer Zielvorgabe umsetzen. Er analysiert bestehenden Code, verändert Dateien, ergänzt Tests, schlägt Refactorings vor und arbeitet sich teilweise durch mehrere Schichten einer Anwendung.

Das kann enorm beschleunigen. Es kann aber genauso schnell gefährlich werden.

Ohne klare Leitplanken arbeitet ein Agent schnell auf Basis falscher Annahmen oder fachlicher Missverständnisse. Die Folgen sind oft unkontrolliert breite Änderungen, neue Bugs in ehemals stabilen Bereichen und Code, der später schwer wartbar ist.

Ein Coding Agent ist damit kein Ersatz für fachliches Verständnis. Er ist ein Werkzeug, das klare Führung braucht.

Daraus folgt eine einfache Regel: Ein Coding Agent braucht keine maximale Freiheit, sondern klare Grenzen, kleine Aufgabenpakete und konsequente Prüfung.

Der Entwickler bleibt verantwortlich

Ein guter KI-Workflow beginnt nicht beim Prompt. Der Prompt ist nur die Oberfläche. Entscheidend ist, ob das Team fachlich, technisch und organisatorisch weiß, was der Agent überhaupt tun soll.

Dazu gehören klare Architekturvorgaben, nachvollziehbare Projektregeln und ein gemeinsames Verständnis der gewünschten Funktionalität. Genau hier werden Dateien wie eine AGENTS.md interessant. Sie können festhalten, welche Schichten genutzt werden sollen, welche Patterns erwünscht sind, welche Regeln für Tests gelten und welche Bereiche der Anwendung besonders vorsichtig behandelt werden müssen.

Ohne solche Leitplanken wird der Agent schnell zum Generator von Code, der auf den ersten Blick plausibel aussieht, aber nicht sauber in das System passt.

Besonders Legacy-Systeme stellen hier hohe Anforderungen. Altlasten, Sonderfälle und gewachsene Fachlogik brauchen klare Führung und saubere Absicherung. Ein Agent kann solche Zusammenhänge nicht zuverlässig nur aus dem vorhandenen Code ableiten. Deshalb müssen sie durch Vorgaben, Dokumentation, Tests und Reviews abgesichert werden.

Damit verschiebt sich die Rolle des Entwicklers deutlich.

Es reicht nicht mehr aus, nur schnell Code schreiben zu können. Wichtiger werden Architekturverständnis, fachliche Klarheit, Testdenken, Review-Fähigkeit und die Fähigkeit, Aufgaben präzise zu schneiden. Der Entwickler muss dem Agenten nicht jeden Handgriff erklären, aber er muss Ziel, Grenzen und Qualitätsmaßstab klar vorgeben.

Besonders für Junior-Entwickler verschiebt sich dadurch der Schwerpunkt. Früher war viel Lernzeit mit dem reinen Schreiben von Code verbunden. Das bleibt wichtig, aber es reicht nicht mehr. Wer mit KI arbeitet, muss lernen, Anforderungen zu verstehen, Ergebnisse kritisch zu prüfen, Tests zu bewerten und Architekturentscheidungen nachzuvollziehen. Ein Junior, der nur Prompts absetzt, aber den erzeugten Code nicht bewerten kann, wird schnell abhängig vom Werkzeug.

Gleichzeitig steigt die Bedeutung von erfahrenen Entwicklern und Architekten. Ihre Aufgabe ist nicht nur, selbst gute Lösungen zu bauen. Sie müssen Leitplanken setzen, Wissen teilen, Reviews ernst nehmen und jüngere Entwickler befähigen. Mentoring wird damit wertvoller, nicht weniger wichtig.

Einzelkämpfer und Inselwissen werden in diesem Umfeld zum Risiko. Wenn nur eine Person weiß, warum eine bestimmte Architekturregel existiert oder warum ein Modul besonders vorsichtig geändert werden muss, kann ein Agent diese Information nicht zuverlässig berücksichtigen. Wissen muss aus den Köpfen heraus und in Regeln, Dokumentation, Tests und gemeinsame Reviews überführt werden.

Entscheidend ist nicht, möglichst schnell Code erzeugen zu lassen. Entscheidend ist, den Agenten so zu führen, dass am Ende wartbare, geprüfte und fachlich richtige Software entsteht.

Aufgaben müssen überschaubar zugeschnitten werden

Große Aufgaben autonom durch einen Coding Agenten umsetzen zu lassen, schlägt mit hoher Wahrscheinlichkeit fehl. Nicht zwingend, weil der Agent keinen Code erzeugen kann, sondern weil das Ergebnis schnell unüberschaubar wird.

Wenn ein Agent zu viele Dateien, Schichten und fachliche Regeln gleichzeitig verändert, wird die Bewertung schwierig. Selbst für erfahrene Entwickler oder Architekten ist dann kaum noch sauber nachvollziehbar, welche Entscheidung warum getroffen wurde und ob alle Nebenwirkungen erkannt wurden.

Deshalb müssen Aufgaben klein, klar und fachlich abgrenzbar zugeschnitten werden.

Ein guter Task umfasst im Idealfall nur eine kleine fachliche Einheit. Zum Beispiel die Authentifizierung für eine externe API, eine Validierungsregel, einen Mapper, einen konkreten Endpunkt oder eine einzelne Service-Funktion. Solche Aufgaben lassen sich beschreiben, testen und im Review sauber bewerten.

Als grobe Leitplanke gilt: Ein Agenten-Task sollte nicht mehr als zwei bis drei klar zusammenhängende Funktionalitäten umfassen. In vielen Fällen ist es sinnvoll, den Umfang auf wenige Klassen zu begrenzen, zum Beispiel auf maximal fünf geänderte oder neu erzeugte Klassen inklusive passender Testabdeckung.

Es geht nicht um eine harte Grenze. Es geht um Prüfbarkeit. Je kleiner der Task, desto einfacher ist die fachliche Abnahme. Je größer der Task, desto höher ist die Gefahr, dass Fehler, Seiteneffekte oder Architekturbrüche übersehen werden.

So entsteht kein unkontrollierter API-Adapter, sondern ein abgrenzbarer Baustein. Die Lösung kann fachlich geprüft, technisch getestet und später kontrolliert erweitert werden.

Große Umbauten oder vollständige Integrationen sollten deshalb nicht als ein einziger Agentenlauf umgesetzt werden. Sie gehören in eine Reihe kleiner, kontrollierter Aufgaben mit Review, Testabdeckung und klarer Abnahme.

Red, Green, Refactor - als Denkmodell für Agentic Coding

Aus dem Test Driven Development ist ein ähnliches Prinzip bekannt: Red, Green, Refactor.

Bei TDD wird zuerst ein Test geschrieben. Dieser Test beschreibt ein gewünschtes Verhalten, das der Code noch nicht erfüllt. Der Test ist also rot. Danach wird nur so viel Code geschrieben, bis dieser Test erfolgreich ist. Das ist die grüne Phase. Anschließend wird der Code verbessert, ohne das getestete Verhalten wieder zu verändern. Das ist Refactoring.

Für Nicht-Entwickler bedeutet das vereinfacht:

Zuerst ist klar, was erreicht werden soll. Die fertige Funktion gibt es aber noch nicht. Danach wird eine kleine erste Lösung gebaut. Anschließend wird diese Lösung verbessert, ohne das gewünschte Ergebnis wieder kaputt zu machen.

Dieses Prinzip ist kein fertiges Rezept für Agentic Coding. Es ist aber ein gutes Denkmodell.

Auch ein Coding Agent sollte nicht sofort die große Gesamtlösung bauen. Erst wird das Ziel geklärt. Dann entsteht ein kleiner, prüfbarer Baustein. Danach wird der Code bewertet, verbessert und sauber in die bestehende Anwendung eingepasst.

• Red bedeutet beim Agentic Coding: Ziel, fachliche Erwartung, Grenzen und Abnahmekriterien sind klar. Es ist beschrieben, woran eine richtige Lösung erkannt wird.
• Green bedeutet: Der Agent erzeugt eine erste funktionierende Umsetzung in begrenztem Umfang. Nicht das komplette Modul, nicht die ganze Integration, sondern einen kleinen Baustein.
• Review bedeutet: Der Entwickler prüft, ob das Ergebnis fachlich stimmt, zur Architektur passt und keine unnötigen Nebenwirkungen erzeugt.
• Refactor bedeutet: Der entstandene Code wird nicht einfach akzeptiert, nur weil er läuft. Er wird vereinfacht, lesbarer gemacht und besser in die vorhandene Struktur eingepasst.
• Quality Gate bedeutet: Tests, Code Style, statische Analyse und manuelle Abnahme entscheiden, ob die Änderung wirklich übernommen wird.

Ohne diese Reihenfolge wird schnell laufender Code mit einer guten Lösung verwechselt.

Aus KI-generiertem Code wird erst dann ein belastbares Ergebnis, wenn er in kleinen Schritten entsteht, geprüft wird und bewusst abgenommen wird.

Saubere Schleifen statt blinder Code-Generierung

Ein Coding Agent sollte nicht in einem großen Lauf möglichst viel Code erzeugen. Das wird schnell unübersichtlich und schwer prüfbar.

Besser sind kurze Schleifen: Aufgabe geben, Ergebnis prüfen, gezielt nacharbeiten lassen, erneut prüfen.

Der Agent liefert damit nicht die fertige Gesamtlösung, sondern einen kontrollierbaren Zwischenschritt. Genau das ist wichtig. Denn nur was überschaubar bleibt, kann im Review sauber bewertet werden.

Zuerst erzeugt der Agent nur den OAuth2-Token-Service für eine externe API. Nicht den kompletten API-Client. Nicht alle Endpunkte. Nur diesen einen Baustein.

Danach wird geprüft:

• Wird der richtige OAuth2-Flow verwendet?
• Kommen Zugangsdaten aus der Konfiguration und nicht aus dem Code?
• Wird ein gültiges Token wiederverwendet?
• Wird ein abgelaufenes Token erneuert?
• Werden Fehlerantworten sauber behandelt?

Erst wenn dieser Baustein passt, folgt der nächste Schritt. Zum Beispiel Tests ergänzen, einen einzelnen Endpunkt anbinden oder die Fehlerbehandlung verbessern.

So bleibt die Änderung klein genug, um sie zu verstehen. Fehler fallen früher auf. Architekturabweichungen werden korrigiert, bevor sie sich durch mehrere Schichten ziehen.

Die Zeitersparnis entsteht dabei nicht durch weniger Kontrolle. Sie entsteht vor allem dadurch, dass der Agent die mechanische Tipparbeit übernimmt. Datenobjekte, Tests, wiederkehrende Service-Strukturen oder einfache Adapter müssen nicht mehr vollständig von Hand geschrieben werden.

Gleichzeitig helfen konsequente Leitlinien dabei, menschliche Abkürzungen zu vermeiden. Wenn Tests, Struktur, Fehlerbehandlung und Code Style fest zum Auftrag gehören, wird weniger "schnell mal eben" gebaut. Der Agent arbeitet dann nicht nur schneller, sondern auch gleichmäßiger entlang der definierten Regeln.

Der Vorteil liegt also nicht darin, dem Agenten möglichst viel Freiheit zu geben. Der Vorteil liegt darin, Tipparbeit zu reduzieren, Standards konsequenter einzuhalten und trotzdem die fachliche Kontrolle zu behalten.

Tests sind Pflicht, aber nicht automatisch Qualität

KI-generierter Code ohne Tests ist schwer zu bewerten. Er kann plausibel aussehen, aber fachlich falsch oder technisch instabil sein. Deshalb sollte Agentic Coding immer mit einem klaren Testanspruch verbunden werden.

Der Agent kann hier Zeit sparen. Er kann Unit Tests ergänzen, bestehende Testfälle erweitern oder Randfälle sichtbar machen. Viele Teststrukturen sind wiederkehrend und lassen sich gut auf Basis klarer Vorgaben erstellen.

Trotzdem gilt: Ein Test ist nur dann wertvoll, wenn er das richtige Verhalten prüft.

Ein Test, der nur den erzeugten Code bestätigt, verbessert die Qualität nicht. Er macht eine falsche Annahme höchstens stabiler. Deshalb müssen Tests fachlich geprüft werden. Sie müssen relevante Regeln, Fehlerfälle und Grenzfälle absichern.

Testabdeckung ist also kein Selbstzweck. Sie ist ein Quality Gate. Aber nur, wenn sie sinnvoll geschnitten ist und wirklich das gewünschte Verhalten absichert.

Abnahmekriterien für KI-generierten Code

Damit Agentic Coding zuverlässig funktioniert, braucht jede Aufgabe klare Abnahmekriterien. Diese Kriterien sollten vor der Umsetzung festgelegt werden. Sie beschreiben, wann eine Änderung wirklich fertig ist und nicht nur "irgendwie läuft".

• Menschliches Review: Ein Entwickler prüft, ob die Lösung fachlich korrekt ist und zur Architektur passt.
• Automatisierte Tests: Unit Tests, Integration Tests oder fachliche Tests sichern das gewünschte Verhalten ab.
• Code Style: Formatierung, Namenskonventionen und Projektstandards müssen eingehalten werden.
• Quality Rules: Statische Analyse, Komplexitätsgrenzen, Security Checks und technische Regeln dürfen nicht verletzt werden.
• Saubere Abgrenzung: Die Änderung löst genau die beschriebene Aufgabe und baut nicht nebenbei weitere Funktionen um.
• Manuelle Abnahme: Die Funktion wird bewusst getestet und nicht nur aufgrund grüner Tests akzeptiert.

Diese Kriterien sind kein Papierkram. Sie verhindern, dass schnell erzeugter Code ungeprüft in stabile Systeme wandert.

Architekturvorgaben müssen explizit sein

Architekturvorgaben dürfen beim Einsatz von Coding Agenten nicht unausgesprochen bleiben. Der Agent muss wissen, welche Schichten genutzt werden, wo Geschäftslogik liegen darf, wie Datenobjekte aufgebaut werden und welche Abhängigkeiten erlaubt sind.

Ohne solche Regeln entstehen schnell Lösungen, die kurzfristig funktionieren, aber langfristig schwer wartbar sind. Geschäftslogik landet im Controller, Datenbankzugriffe verteilen sich über mehrere Stellen oder bestehende Patterns werden ungewollt umgangen.

Hilfreich sind klare Projektregeln. Diese können in einer Entwicklerdokumentation, in einer AGENTS.md, in Pull-Request-Vorlagen oder direkt in Architekturtests festgehalten werden.

Wichtig ist dabei nicht die Form der Dokumentation. Wichtig ist, dass die Regeln für Mensch und Agent sichtbar sind und im Review auch eingefordert werden.

Code Review bleibt Pflicht

Auch wenn ein Agent Tests schreibt und die Pipeline grün ist, ersetzt das kein menschliches Review.

Automatisierte Prüfungen erkennen viele technische Probleme, aber nicht jede fachliche Schwäche. Sie bewerten auch nicht zuverlässig, ob eine Lösung zur langfristigen Produktstrategie passt.

Im Review sollte deshalb nicht nur gefragt werden, ob der Code funktioniert.

• Ist die Änderung verständlich?
• Passt sie zur Architektur?
• Ist die Lösung unnötig komplex?
• Werden bestehende Konzepte respektiert?
• Ist das Feature sauber abgegrenzt oder wurde nur eine schnelle Sonderlösung gebaut?

Gerade bei KI-generiertem Code ist diese Prüfung wichtig, weil Agenten häufig überzeugend wirkende Lösungen erzeugen. Gute Lesbarkeit darf aber nicht mit guter Architektur verwechselt werden.

Fazit: weniger Tipparbeit, mehr Verantwortung

Der praktische Vorteil von Agentic Coding ist einfach: weniger Tipparbeit, mehr Zeit für Struktur, Review und fachliche Entscheidungen.

Datenobjekte, Tests, einfache Adapter, Migrationsschritte, Refactoring-Vorschläge oder wiederkehrende Code-Strukturen lassen sich mit einem Agenten deutlich schneller vorbereiten. Genau hier entsteht Geschwindigkeit.

Diese Geschwindigkeit ist aber nur dann ein Vorteil, wenn sie geführt wird. Ohne klare Aufgaben, Tests, Reviews und Abnahmekriterien entsteht schnell Code, der kurzfristig beeindruckt und langfristig Probleme verursacht.

Der Entwickler wird durch KI nicht unwichtig. Seine Rolle verschiebt sich stärker in Richtung Architektur, Aufgabenklärung, Qualitätssicherung und Abnahme. Gerade in Legacy-Systemen, bei Modernisierungen oder beim Aufbau sauberer Schnittstellen ist diese Verantwortung entscheidend.

Agentic Coding ist damit kein Ersatz für Software Engineering. Es ist ein Werkzeug, das Software Engineering beschleunigen kann, wenn der Prozess stimmt.

Gute KI-gestützte Entwicklung bedeutet nicht:

"Der Agent macht das schon."

Gute KI-gestützte Entwicklung bedeutet:

"Der Agent arbeitet innerhalb klarer fachlicher und technischer Leitplanken."