Agentic Coding ist zu einem festen Bestandteil des Entwicklungsalltags geworden. KI-Agenten planen, implementieren, testen und dokumentieren Code in kurzer Zeit. Teams orchestrieren spezialisierte Assistenten, statt jede Änderung von Hand zu schreiben. Neben KI-Assistenten wie GitHub Copilot und Chat-Modelle wie ChatGPT treten autonome Agenten, die ganze Entwicklungsschritte übernehmen.

Die Taktzahl steigt, doch der Bedarf an Leitplanken ebenso. Funktional korrekter Code reicht nicht, wenn Sicherheitsvorgaben, Latenzziele, Skalierbarkeit und Architekturkonventionen unbeachtet bleiben. Ohne ausreichendes Kontextwissen entfernen sich Systeme schleichend von ihrer ursprünglichen Architektur, Tests verlieren an Treffsicherheit und technische Schuld wächst.

Wie lassen sich Agenten in bestehende Softwarelandschaften integrieren, wo liegen ihre Grenzen bei nicht-funktionalen Anforderungen? Welche Rollen und Prozesse tragen sie in der Praxis und welche Prüfungen in Pipelines helfen, Tempo und Tragfähigkeit zusammenzubringen? Fragen wie diese beantwortet der vorliegende Artikel.

Von Autovervollständigung zur Architekturverantwortung

Neben GitHub Copilot und den Chatmodellen von Anthropic und OpenAI (ChatGPT) gibt es inzwischen eine neue Klasse von Werkzeugen: autonome Agenten. Sie übernehmen ganze Entwicklungsschritte von der Planung bis zur Integration. Man findet sie heute als IDE-Integrationen, etwa in Visual-Studio-Code-Forks wie Windsurf und Cursor, als Terminal-integrierte Agenten wie Anthropics Claude Code oder OpenAIs Codex sowie als quelloffene Software wie OpenCode.

Diese Agenten entwerfen APIs, orchestrieren Tests-Suites, erkennen Sicherheitslücken oder strukturieren Legacy-Module um, ohne deren Verhalten zu ändern. Teilweise greifen sie dabei auf externe Wissensquellen zu, dokumentieren ihre Entscheidungen und führen selbstständig Korrekturschleifen durch. Dabei entsteht ein neues Arbeitsmodell: Entwicklerinnen und Entwickler interagieren nicht mehr mit einzelnen Tools, sondern orchestrieren ein Team spezialisierter Agenten. Dieser Wandel erfolgt nicht nur auf technischer Ebene, sondern auch in der Art, wie Projekte strukturiert und verantwortet werden.

Diese Entwicklung eröffnet viele Möglichkeiten, aber sie verschiebt auch die Verantwortung. Denn je mehr operative Aufgaben Agenten übernehmen, desto wichtiger wird die Fähigkeit, konzeptionelle Leitplanken zu setzen. Wer entscheidet, ob eine Lösung tragfähig ist? Wer kontrolliert, ob der erzeugte Code zur Zielarchitektur passt? Und was passiert, wenn Agenten sich widersprechen, nicht-funktionale Anforderungen ignorieren oder eigene Annahmen treffen, die fachlich nicht gewünscht sind?

Agentic Coding ist keine lineare Fortsetzung der Automatisierung, sondern eine neue Phase: Entscheidungen verlagern sich, Prozesse beschleunigen sich, Erwartungen verändern sich. Und genau deshalb braucht es einen reflektierten Umgang, und das nicht nur mit den Werkzeugen, sondern mit der Haltung zur Entwicklung selbst.

Wo Agenten an Grenzen stoßen: nicht-funktionale Anforderungen

Agentic Coding zeigt eindrucksvoll, wie weit KI-gestützte Automatisierung inzwischen reicht. KI-Agenten übernehmen funktionale Aufgaben zunehmend zuverlässig: Sie entwerfen eine API, validieren ein Formular, integrieren eine Datenbankabfrage oft schneller als ein Mensch es kann. Die Ergebnisse sind jedoch nicht immer technisch korrekt; erst mit Expertenwissen und der Kontrolle nicht-funktionaler Anforderungen werden sie verlässlich, gut dokumentiert, lauffähig und auch deploybar.

Denn funktional heißt nicht belastbar. Denn sobald Anforderungen ins Spiel kommen, die über das reine „Was soll die Software tun“ hinausgehen – etwa wie schnell sie reagieren muss, wie sicher oder wartbar sie sein soll – entstehen neue Lücken. Genau hier beginnt der Bereich der nicht-funktionalen Anforderungen und mit ihm die typischen Schwächen heutiger Agenten.

Nicht-funktionale Anforderungen beschreiben das „Wie“ eines Systems: Wie performant soll ein Service unter Last reagieren? Wie sicher sind Schnittstellen gegen Angriffe geschützt? Wie skalierbar ist ein neues Modul, wenn sich das Geschäftsmodell ändert? Welche Architekturkonventionen gilt es einzuhalten, um langfristig wartbare Systeme zu erhalten?

Solche Anforderungen sind selten direkt aus einem Prompt ableitbar. Sie sind oft implizit, kontextabhängig, unternehmensspezifisch und dynamisch. Viele Entscheidungen in einer Software haben kausale Abhängigkeiten, beispielsweise weil ein anderes Team Vorgaben gemacht oder eine bestimmte Lösung gewählt hat. Oft entstehen Anforderungen auch erst im Verlauf: Skalierbarkeit wird erst wichtig, wenn die Nutzerzahlen wachsen; Latenzanforderungen, wenn Echtzeitfunktionen kommen. Solche Zusammenhänge lassen sich kaum in einen kurzen Prompt pressen. Agenten, die nur lokal operieren (also auf einzelne Dateien oder Tasks fokussiert sind), haben keinen Blick für diese übergeordneten Aspekte.

Beispiel: Risiko statt Produktivität

Ein Beispiel: Ein Agent generiert eine neue REST-API in Rekordzeit, inklusive Tests und Dokumentation. Technisch korrekt, syntaktisch sauber, aber ohne Einbindung in bestehende Sicherheitsmechanismen, ohne Logging-Konzept und ohne Rücksicht auf Latenz oder Skalierbarkeit. Was auf den ersten Blick nach Produktivität aussieht, wird auf Systemebene schnell zum Risiko.

Ähnlich verhält es sich mit Architekturentscheidungen. Agenten arbeiten kontextbezogen, aber nur mit den Informationen, die sie zur Verfügung haben. Ob ein Modul in eine bestehende Schichtenarchitektur passt, ob bestehende Regeln verletzt werden oder ob zyklische Abhängigkeiten entstehen, bleibt ohne zusätzliche Kontrollmechanismen häufig unbemerkt. Fehlentscheidungen schleichen sich nicht ein, sondern sie skalieren sofort.

Ein Agent kann eine Methode korrekt implementieren, aber nicht erkennen, dass sie in einem sicherheitskritischen Pfad liegt. Er kann Tests schreiben, aber nicht bewerten, ob sie die geschäftskritische Logik tatsächlich absichern. Er kann den Code umstrukturieren, ohne zu wissen, dass er damit einen regulatorischen Rahmen berührt.

In der Praxis führt das zu einem paradoxen Effekt: Systeme entstehen schneller, wirken auf den ersten Blick vollständig und erzeugen dennoch technische Schuld, weil zentrale Qualitätsmerkmale fehlen.

Auch in puncto Testabdeckung zeigt sich ein wiederkehrendes Muster: Es entstehen zwar viele Tests, aber nicht zwingend die richtigen. Oft werden triviale Fälle abgedeckt, während Randbedingungen, Fehlerpfade oder geschäftskritische Logik unberücksichtigt bleiben. Die Illusion von Testabdeckung ersetzt keine belastbare Qualitätsstrategie.

Zusätzlich entstehen neue Herausforderungen auf der Metaebene: Wer kontrolliert den Output? Welche Rolle spielt menschliches Review, wenn Agenten Dutzende Commits pro Stunde erzeugen? Welche Metriken helfen bei der Bewertung? Und wie lässt sich verhindern, dass technische Schuld nicht nur bestehen bleibt, sondern automatisiert weiterwächst?