AI Native Rapid Development: der komplette Engineering-Prozess als Agenten-Kette

Die Automatisierung endet beim Coden

Wenn heute von KI in der Softwareentwicklung die Rede ist, ist meist ein einziger Arbeitsschritt gemeint: das Schreiben von Code. Eine Entwicklerin beschreibt eine Funktion, ein Werkzeug liefert den passenden Quelltext. Das funktioniert, und es spart Zeit. Es deckt aber nur den mittleren, sichtbaren Teil der Entwicklung ab.

Softwareentwicklung besteht zum kleineren Teil aus Coden. Davor liegen die Aufnahme der Anforderungen, die Spezifikation, das Datenmodell und die Architektur. Danach folgen Tests, Sicherheitsprüfungen, Auslieferung und Betrieb. Genau diese Teile bleiben beim üblichen KI-Einsatz Handarbeit oder fallen ganz weg.

Das Ergebnis ist ein bekanntes Muster. In wenigen Tagen entsteht ein Prototyp, der in der Vorführung überzeugt. Im Ernstbetrieb bricht er, weil niemand die Anforderungen sauber erfasst, das Datenmodell durchdacht oder die Sicherheit geprüft hat. Der Engpass liegt selten beim Coden. Er liegt bei allem, was das Coden erst tragfähig macht.

Ein durchgängig agentischer Prozess

AI Native Rapid Development, intern kurz AIRD, setzt an dieser Lücke an. Der komplette Engineering-Prozess läuft durchgängig über KI-Agenten: die Aufnahme der Anforderungen, die Spezifikation, die Modellierung, das Einrichten der Architektur, das Anlegen der Tickets, die Umsetzung, die Qualitätssicherung, die Sicherheitsprüfung, die Auslieferung und die Dokumentation. Von der ersten Anforderung bis zum Betriebshandbuch ein zusammenhängender Ablauf.

Ein KI-Agent ist in diesem Zusammenhang ein Programm, das eine klar umrissene Aufgabe eigenständig erledigt und dafür Werkzeuge bedient: Dateien lesen, in ein Ticketsystem schreiben, Tests starten, eine Auslieferung auslösen. Der Unterschied zum reinen Code-Assistenten liegt in der Reichweite. Ein Code-Assistent beschleunigt einen Schritt, AIRD die ganze Kette von der Kundenanforderung bis zur betriebsfähigen Anwendung.

Die Rückkehr des schwergewichtigen Engineerings

Es gab einmal einen sehr gründlichen Weg, Software zu spezifizieren: Lastenheft, Stakeholder-Analyse, Use-Case-getriebenes Design, ein Geschäftsobjektmodell, ein Datenmodell, dokumentierte Architekturentscheidungen. Diese Verfahren waren fachlich gut. Sie hatten einen ökonomischen Nachteil. Ein Mensch saß wochenlang an Dokumenten, bevor eine Zeile Code entstand. Die agile Bewegung hat dieses schwergewichtige Vorgehen aus nachvollziehbarem Grund weitgehend abgeräumt.

Der Grund war nie, dass die Dokumente wertlos gewesen wären. Der Grund war, dass ihre Erstellung zu viel gekostet hat. Dieser Kostenfaktor verändert sich unter KI-Agenten grundlegend. Wenn ein Agent das Datenmodell aus den Anforderungen ableitet und ein Architekturkonzept in Stunden statt in Wochen entsteht, wird die teure Gründlichkeit wieder wirtschaftlich. Eine Ticketspezifikation zu schreiben oder nach jeder Änderung eine Qualitätsprüfung laufen zu lassen, verbraucht Rechenzeit, aber kaum menschliche Arbeitszeit.

Damit dreht sich die Rechnung um. Das klassische, schwergewichtige Engineering, das als überholt galt, wird unter Agenten wieder zum effizientesten Vorgehen. Ein detailliertes Konzept ist kein bürokratischer Ballast. Es ist die beste Vorlage, die ein umsetzender Agent bekommen kann, weil es seine Aufgabe vollständig und widerspruchsfrei beschreibt.

Vier Phasen von der Anforderung zum Betriebshandbuch

Der Ablauf gliedert sich in vier Phasen. Die erste enthält den größten Anteil menschlicher Arbeit, die folgenden drei laufen weitgehend über Agenten.

Phase 1: Requirements Discovery

Zu Beginn liefert der Kunde alles vorhandene Material: Konzepte, Screenshots, Datenmodelle, Verträge, E-Mails, im Zweifel den Zugang zum Altsystem. Dieses unsortierte Ausgangsmaterial kommt vollständig in ein zentrales Repository. Daraus entsteht zuerst ein Vision-Statement, ein oder zwei Sätze zum Kern des Vorhabens, und anschließend eine bereinigte Baseline: Dubletten entfernt, Widersprüche markiert, Wesentliches vom Veralteten getrennt.

Der wichtigste Termin des Projekts ist ein Workshop von drei bis fünf Stunden mit den fachlich richtigen Personen. Jemand, der die Geschäftsprozesse kennt, jemand für die Technik, bei Bedarf jemand für die Bedienoberfläche. Ziel ist, den gesamten Umfang durchzusprechen, bis in die Randfälle hinein: Wie hängen die Daten zusammen, was geschieht beim Löschen eines Datensatzes, welche seltenen Fälle sind trotzdem geschäftskritisch. Der Termin wird vollständig aufgezeichnet und transkribiert, damit kein beiläufiger Halbsatz verloren geht. Erfahrungsgemäß sind nach diesem Workshop rund 90 Prozent aller Anforderungen fixiert. Diese Phase ist die Stelle, an der die Qualität des gesamten Rests entschieden wird.

Phase 2: Spezifikation und Engineering mit Volve

Das Herzstück übernimmt ein eigenes System mit dem Namen Volve. Es bildet den klassischen Requirements- und Engineering-Prozess als Kette von Agenten ab.

Am Anfang steht das Seeding. Das gesamte Material aus Phase 1, Transkripte, Notizen, kuratierte Dokumente, kommt als Rohstoff in Volve. Ein erster Agent konsolidiert diesen Bestand zu einer strukturierten Wissensbasis, ohne informationstragende Inhalte zu kürzen. Danach folgt eine automatische Lücken- und Widerspruchsanalyse: Ein Agent liest die konsolidierte Basis, sucht nach fehlenden Angaben und inneren Widersprüchen und erzeugt eine Liste konkreter Fragen an das menschliche Team. Aus den Antworten entsteht ein finales Seed samt dokumentierter Entscheidungen.

Darauf setzt der eigentliche Engineering-Workflow auf, gegliedert in typischerweise fünf bis acht Stages. Jede Stage liefert ein Artefakt, das die nächste speist:

• funktionale und nicht-funktionale Anforderungen im Charakter eines Lastenhefts
• Use Cases, sauber definiert und spezifiziert
• ein Geschäftsobjektmodell und daraus ein Datenmodell für die Persistenz
• ein Maskeninventar mit textuellen Wireframes für die Oberfläche
• die Service-Spezifikation, also die Geschäftslogik
• die Architektur

In der Architektur-Stage greifen erprobte Vorlagen, etwa ein Stack aus React und Supabase, inklusive Container-Konfiguration, Auslieferungs-Pipeline, Caching und Sicherheit. Die Entscheidungen liegen als Architekturregeln und als dokumentierte Architekturentscheidungen (ADRs) vor, statt bei jedem Projekt neu getroffen zu werden. Über alle Stages hinweg laufen Review-Schleifen, in denen Agenten jedes Artefakt gegen die Anforderungen prüfen; bei Bedarf schaut ein Mensch darüber. Am Ende steht ein Implementierungskonzept von 150 bis 200 Seiten, aufgeteilt in typischerweise 10 bis 20 Epics und 100 bis 250 User Stories. Ein vollständiger, in sich konsistenter Plan, aus dem sich direkt entwickeln lässt.

Phase 3: Implementierung mit durchgängiger Qualitätssicherung

Aus dem Konzept erzeugt das System die Tickets, oft an die zweihundert, direkt im Ticketsystem. Die Agenten setzen sie nacheinander um. Die Qualitätssicherung ist von Beginn an Teil des Ablaufs und kein nachgelagerter Schritt: Unit- und End-to-End-Tests, ein Abgleich gegen die Requirements, Sicherheitsprüfungen, ein Linter für sauberen Code und eine funktionierende Auslieferungs-Pipeline auf einem stabilen Betriebs-Stack. Der Mensch arbeitet hier auf der Aufsichtsebene, der laufende Betreuungsaufwand ist gering.

Das Ergebnis trifft die Anforderungen genau und übertrifft sie im Detail häufig, weil die Agenten gängige Best Practices von sich aus ergänzen, etwa eine sinnvolle Passwort-Regel oder einen Hover-Effekt an der richtigen Stelle, die im Konzept nicht ausdrücklich standen. Am Ende dieser Phase liegt eine Anwendung in Version 0.9 vor, dazu die vollständige Dokumentation und ein Betriebshandbuch.

Phase 4: Feinschliff zur Version 1.0

Es verbleiben die zwei bis fünf Prozent, die im ersten Durchlauf nicht erfasst wurden. Ein kurzer, fokussierter Workshop nimmt die offenen Punkte auf, Entscheidungen werden protokolliert, ein schlankes Implementierungskonzept entsteht, Tickets werden erzeugt und umgesetzt. Dieser Durchlauf ist deutlich schlanker als der erste. Am Ende steht die Version 1.0.

Volve als Agenten-Kette

Volve ist der Motor von Phase 2 und für den Kunden nicht sichtbar. Es ist kein Produkt, das vertrieben wird, und niemand außerhalb muss es bedienen können. Seine Funktion ist der Nachweis, dass der Anspruch trägt: dass sich der Requirements- und Engineering-Prozess als durchgehende Agenten-Kette abbilden lässt und am Ende ein Konzept steht, aus dem produktionsreife Software entsteht. Der Kunde sieht das Ergebnis, nicht die Mechanik dahinter.

Produktionsreife im Lieferumfang

Der wunde Punkt bei allem, was KI und Software verbindet, ist das Vertrauen in den Ernstbetrieb. Die Antwort liegt im Lieferumfang. Automatisierte Tests, die gegen die Anforderungen prüfen. Sicherheitschecks nach jeder Änderung. Eine vollständige Dokumentation. Ein Betriebshandbuch. Eine saubere Auslieferung, getrennt nach Test- und Produktivumgebung, mit abgesichertem Server und strengen Zugriffsregeln auf die Datenbank. Das ist fester Bestandteil jeder Lieferung, keine Zusatzoption.

Das Prüfniveau während der Entwicklung liegt dabei über dem der reinen Handarbeit, weil eine Maschine jeden einzelnen Schritt prüfen kann, was ein Mensch bei zweihundert Tickets nicht durchhält. Für den Kunden bleibt der Aufwand gering: Material übergeben, an einem Workshop teilnehmen, wenige Wochen später eine produktionsreife Anwendung erhalten, zu einem Bruchteil der Kosten klassischer Individualentwicklung. Die Gründlichkeit im Hintergrund ist der Grund, warum das Ergebnis hält, ohne als Last beim Kunden zu liegen.

Grenzen und menschliches Urteil

Die Methode hat klare Voraussetzungen und ebenso klare Grenzen. Sie ist so gut wie ihr Input. Bleibt der Workshop oberflächlich oder fehlen die fachlich richtigen Köpfe, erzeugt die Agenten-Kette schnell und zuverlässig das Falsche. Die Lücken- und Widerspruchsanalyse findet innere Inkonsistenzen, sie ersetzt aber kein fachliches Wissen, das im Raum schlicht nicht vorhanden war.

Auch das Urteil bleibt beim Menschen. Ein Agent setzt eine Architekturvorgabe zuverlässig um, er entscheidet aber nicht, ob sie für den konkreten Fall die richtige ist. Ob die tragenden Sicherheitsannahmen stimmen, ob das Datenmodell den Geschäftsprozess wirklich trifft, ob überhaupt das Richtige entsteht, sind Fragen, die eine fachliche Bewertung verlangen. Deshalb sitzen an den Übergängen Review-Punkte, an denen ein Mensch abnimmt.

Das Verfahren eignet sich am besten für abgrenzbare Individualsoftware mit einem beschreibbaren Funktionsumfang: die Ablösung einer nicht mehr wartbaren Anwendung, eine Neuentwicklung mit klarem Ziel, eine Fachanwendung ohne passendes Standardprodukt. Bei ergebnisoffener Produktexploration, in der die Anforderungen erst durch Ausprobieren am Markt entstehen, spielt der Vorlauf aus Phase 1 und 2 seine Stärke nur eingeschränkt aus, weil sich schwer spezifizieren lässt, was noch niemand kennt.

Einordnung

Der verbreitete KI-Einsatz automatisiert einen einzelnen Schritt und nennt das KI-Softwareentwicklung. AIRD automatisiert die gesamte Kette und holt dabei die gründliche Sorgfalt zurück, die unter Agenten wieder wirtschaftlich ist. Schnelligkeit war in der Entwicklung selten das eigentliche Problem. Gründlichkeit und Tempo zugleich waren lange nicht zu bezahlen. Unter durchgängig agentischen Prozessen verschiebt sich diese Grenze, und die Frage verlagert sich vom Coden zurück auf das, was gute Software immer entschieden hat: die richtigen Anforderungen und die richtigen Entscheidungen.