Coding-Agenten in der Softwareentwicklung: 5 Erkenntnisse aus KI-gestützten Projekten

Kernthese: Der Engpass im Projekt verschiebt sich.

Coding-Agenten verändern Softwareprojekte spürbar. Sie können Features implementieren, Tests schreiben, Pull Requests vorbereiten, Code analysieren und Dokumentation erstellen. In unseren Projekten sehen wir inzwischen, dass ein erheblicher Teil der eigentlichen Implementierungsarbeit von KI übernommen werden kann.

Die interessantere Veränderung findet für uns aber an einer anderen Stelle statt: Der Engpass im Projekt verschiebt sich.

Wenn Code schneller entsteht, wird umso wichtiger, dass davor die richtigen Probleme verstanden und danach die richtigen Ergebnisse schnell geprüft werden. Anforderungen müssen rechtzeitig geklärt, fachliche Entscheidungen getroffen und neue Funktionen so früh wie möglich durch die späteren Nutzer validiert werden.

In einem aktuellen HMS-Softwareprojekt konnten wir diese Entwicklung über mehrere Monate beobachten. Ausgangspunkt war der Greenfield-Rewrite einer rund 20 Jahre gewachsenen Applikationslandschaft in einer komplexen Fachdomäne. Über die Jahre hatten sich mehrstufige Verarbeitungsprozesse entwickelt, die nur teilweise in der bestehenden Software abgebildet waren und durch Medienbrüche zwischen Anwendungen, Dateien, Excel und E-Mail ergänzt wurden. Deshalb reichte es nicht, vorhandene Anforderungen einfach neu zu implementieren: Zunächst mussten wir verstehen, wie die Prozesse tatsächlich funktionieren und wie sie künftig in einer durchgängigen Anwendung abgebildet werden sollten. Wir sind dabei nicht mit einem fertigen „Agentic-Engineering-Framework“ gestartet. Unser Vorgehen hat sich gemeinsam mit dem Projekt entwickelt. Daraus haben wir fünf Erkenntnisse mitgenommen.

Coding-Agenten beschleunigen die Implementierung von Software, verschieben aber zugleich die Engpässe im Entwicklungsprozess. Aus einem mehrmonatigen HMS-Softwareprojekt lassen sich fünf zentrale Erkenntnisse ableiten: Erstens wird das fachliche Problemverständnis wichtiger, wenn Code schneller entsteht. Zweitens helfen frühe Prototypen, Anforderungen gemeinsam mit Anwendern zu konkretisieren. Drittens sollte sich Agentic Engineering schrittweise aus tatsächlichen Problemen im Projekt entwickeln, statt von Beginn an vollständig geplant zu werden. Viertens müssen Feedback, Tests und fachliche Validierung mit der Implementierungsgeschwindigkeit mithalten, damit die gewonnene Geschwindigkeit tatsächlich in Projektfortschritt mündet. Fünftens verändert sich die Rolle von Software Engineers: Neben technischer Kompetenz werden Domänenverständnis, Kommunikation und die Fähigkeit, KI-generierte Ergebnisse kritisch zu bewerten, immer wichtiger. Unternehmen sollten deshalb nicht nur die Codeerzeugung beschleunigen, sondern den gesamten Entwicklungsprozess vom Problemverständnis bis zur Validierung optimieren.

In klassischen Softwareprojekten war die Implementierung häufig ein wesentlicher begrenzender Faktor. Ein Feature konnte fachlich beschrieben sein – anschließend musste jemand die notwendige Logik entwerfen und den Code schreiben.

Coding-Agenten verändern dieses Verhältnis. Ist eine Aufgabe ausreichend verstanden und das System gut strukturiert, kann die Umsetzung heute sehr schnell gehen.

Damit entsteht allerdings ein neues Problem: Die Implementierung kann schneller werden als die fachliche Klärung davor und die Validierung danach.

Die entscheidenden Fragen:

• Verstehen wir genau genug, welches Problem wir lösen wollen?

• Haben wir mit den richtigen Anwendern gesprochen?

• Sind Sonderfälle geklärt?

• Können die Nutzer das Ergebnis zeitnah testen?

• Wissen wir, woran wir erkennen, dass die Umsetzung tatsächlich richtig ist?

In unserem Projekt hat sich deshalb auch die Arbeit im Team verschoben. Kapazität, die ursprünglich stärker für klassische Backend-Entwicklung vorgesehen war, fließt inzwischen stärker in Requirements Engineering, Abstimmung und fachliche Klärung.

Das ist keine Nebentätigkeit rund um die eigentliche Softwareentwicklung. Sie wird zunehmend zu einem zentralen Teil davon.

Eine zweite Veränderung betrifft die Frage, wann wir Software zeigen.

Früher war ein aufwendig gebauter Prototyp eine Investition, die sich nicht für jede Fragestellung gelohnt hat. Mit KI-Unterstützung können wir heute wesentlich früher einen konkreten Ablauf, ein Interface oder eine erste funktionierende Variante herstellen.

Im Projekt haben wir diese Möglichkeit schon in einer frühen Phase genutzt. Statt ausschließlich vorhandene Anforderungen zu übernehmen, haben wir zunächst Prozesse mit den Anwendern betrachtet und diskutiert, wie die zukünftige Anwendung tatsächlich aussehen könnte. Erste Entwürfe und Prototypen machten diese Gespräche deutlich konkreter.

Das hat einen wichtigen Effekt: Über eine abstrakte Anforderung lässt sich lange diskutieren. Sobald ein Nutzer einen konkreten Ablauf vor sich sieht, kommen andere Fragen auf.

Fehlt ein Schritt? Ist die Reihenfolge sinnvoll? Welche Information braucht der Anwender an dieser Stelle wirklich? Was passiert bei einem Sonderfall?

Aus dem Prototyp wird damit ein Instrument zur Anforderungserhebung.

Für uns bedeutet das: Wir wollen Nutzerfeedback möglichst weit nach vorne ziehen. Nicht erst nach Monaten eine nahezu fertige Anwendung präsentieren, sondern früh etwas zeigen, Reaktionen beobachten und die nächsten Schritte daraus ableiten.

Das funktioniert besonders gut, wenn Power User nicht nur über die Anwendung sprechen, sondern sie mit realistischen Fällen ausprobieren können. So kommen Informationen ans Licht, die in Tickets oder Prozessbeschreibungen häufig fehlen.

Zu Beginn des Projekts hatten wir keinen vollständig definierten agentischen Entwicklungsprozess.

Wir haben zunächst mit einfachen Instructions für den Coding-Assistenten gearbeitet. Im Laufe der Entwicklung wurden Unterschiede sichtbar: Schnittstellen wurden unterschiedlich umgesetzt, Architekturentscheidungen mussten häufiger erklärt werden oder bestimmte Schritte wiederholten sich bei jedem Pull Request.

Aus diesen Problemen entstanden nach und nach zusätzliche Bausteine.

Architekturbeschreibungen wurden für den Agenten verfügbar gemacht. Bereits vorhandene Architecture Decision Records wurden stärker in den Entwicklungsprozess eingebunden. Für größere Änderungen etablierte sich ein Ablauf aus Planung, Implementierung und Tests. Wiederkehrende Arbeiten wie Pull-Request-Beschreibungen oder Code Reviews bekamen eigene Prompts. Später kamen weitere Werkzeuge und Integrationen hinzu.

Das Entscheidende daran ist für uns weniger ein bestimmtes Tool als das Vorgehen dahinter: Wir automatisieren dort, wo im echten Projekt wiederholt Reibung entsteht.

Wenn wir einem Agenten dieselbe Architekturregel mehrfach erklären müssen, sollte diese Information dauerhaft verfügbar sein. Wenn ein Review immer wieder auf dieselbe Art von Problem stößt, kann die Prüfung Teil des Review-Prozesses werden. Wenn ein manueller Schritt häufig vorkommt und wenig fachliche Entscheidung benötigt, lohnt sich die Automatisierung.

So wächst der agentische Entwicklungsprozess mit dem Projekt.

Das ist aus unserer Sicht oft sinnvoller, als zu Beginn viel Zeit in einen vermeintlich perfekten Agentic-Engineering-Stack zu investieren, dessen tatsächliche Anforderungen noch gar nicht bekannt sind.

Wenn die Umsetzung deutlich schneller wird, entsteht leicht ein neuer Stau an anderer Stelle: Features sind technisch fertig, warten aber auf fachliches Feedback, Tests oder Freigaben.

Genau das verändert die Taktung im Projekt. Ein schneller Coding-Agent bringt wenig, wenn Anforderungen erst nach mehreren Wochen geklärt werden oder Nutzer neue Funktionen erst spät ausprobieren können. Die Geschwindigkeit vor und nach der Implementierung muss deshalb mitwachsen.

In unserem Projekt haben wir versucht, diese Schleifen bewusst kurz zu halten. Power User wurden früh eingebunden, konnten eigene Dateien mitbringen und neue Funktionen in einer realistischen Umgebung ausprobieren. Das Feedback floss direkt in die weitere Entwicklung ein.

Dasselbe gilt für die technische Seite. Reviews und Tests müssen mit dem höheren Änderungsdurchsatz Schritt halten. Wiederkehrende Review-Aufgaben haben wir deshalb ebenfalls unterstützt und automatisiert, damit nicht ausgerechnet die Qualitätssicherung zum neuen Engpass wird.

Für KI-gestützte Projekte heißt das: Nicht nur die Zeit von der Spezifikation zum Code zählt. Entscheidend ist die gesamte Schleife vom Problemverständnis über die Umsetzung bis zur fachlichen und technischen Validierung.

Je kürzer diese Schleife wird, desto besser lässt sich die zusätzliche Umsetzungsgeschwindigkeit tatsächlich in Projektfortschritt übersetzen.

Die vielleicht wichtigste Veränderung betrifft die Rolle der Entwickler selbst.

Wenn ein Agent große Teile der Implementierung übernimmt, reicht die Fähigkeit, Anforderungen zuverlässig in Code zu übersetzen, als Differenzierungsmerkmal immer weniger aus.

Wichtiger wird, das Problem hinter der Anforderung zu verstehen.

Ein Software Ingenieur muss mit Anwendern sprechen können, Prozesse hinterfragen, fachliche Zusammenhänge verstehen und erkennen, wenn eine vermeintlich eindeutige Anforderung das eigentliche Problem noch nicht trifft. Gleichzeitig braucht er weiterhin genug technisches Verständnis, um Architekturentscheidungen zu treffen und die Ergebnisse eines Coding-Agenten beurteilen zu können.

Diese Kombination wird aus unserer Sicht entscheidend.

Denn die KI kann nur mit dem Kontext arbeiten, den das Projekt bereitstellt. Wenn Anforderungen unklar sind, automatisiert sie Unklarheit. Wenn die Architektur keine Orientierung bietet, produziert sie schneller Inkonsistenzen. Wenn niemand überprüfen kann, ob das Ergebnis fachlich richtig ist, hilft auch eine sehr schnelle Implementierung wenig.

Der Hebel guter Software Ingenieure wird dadurch größer: Sie können sich stärker mit dem System, der Domäne und dem eigentlichen Kundenproblem beschäftigen und gleichzeitig einen großen Teil der Umsetzung durch Agenten erledigen lassen.

Aus einem einzelnen Projekt lässt sich noch keine universelle Methode ableiten. Einige Muster halten wir aber für so relevant, dass wir sie auch in weiteren Projekten gezielt überprüfen.

Wir wollen fachliches Verständnis und direkten Nutzerkontakt früh im Projekt aufbauen. Wir wollen Prototypen nutzen, um Anforderungen schneller zu konkretisieren. Agentische Entwicklungsabläufe sollen anhand tatsächlicher Reibungspunkte wachsen. Vor allem müssen Feedback, Tests und fachliche Validierung mit der Geschwindigkeit der Codeerzeugung mithalten. Und die gewonnene Kapazität sollte nicht ausschließlich dazu dienen, noch mehr Code zu produzieren.

Interessanter ist die Frage, wo sie im gesamten Entwicklungsprozess den größten Nutzen erzeugt.

In unserem Projekt war die Antwort überraschend deutlich: mehr Zeit für Requirements Engineering, mehr Austausch mit den späteren Nutzern und vor allem schnellere Schleifen zwischen einer Idee, ihrer Umsetzung und einem Ergebnis, das tatsächlich ausprobiert und validiert werden kann.

Coding-Agenten machen Software Engineering damit nicht überflüssig. Si verschieben den Schwerpunkt von “Wie setzen wir das um?” zunehmend hinzu “Was sollten wir eigentlich bauen?”, “Warum?” und “Woran erkennen wir, dass es richtig ist?” 

Für anspruchsvolle Softwareprojekte könnte genau darin ihr größter Effekt liefen.