Ich habe das teure Software-Engineering zurückgeholt – weil KI es billig macht
Der Markt automatisiert bei der KI-Softwareentwicklung meist nur einen Schritt: das Schreiben von Code. Dieser Artikel beschreibt einen Ansatz, bei dem der gesamte Engineering-Prozess über KI-Agenten läuft – von der ersten Anforderung bis zum Betriebshandbuch.
Der Einsatz von künstlicher Intelligenz in der Softwareentwicklung beschränkt sich in der gängigen Praxis häufig immer noch auf einen einzigen Arbeitsschritt: das Schreiben von Code. Ein umfassenderer Ansatz automatisiert hingegen den gesamten Entwicklungsprozess und bringt dabei ein gründliches, aufwendiges Engineering-Verfahren zurück, das die Branche vor Jahren als zu teuer und zu langsam verworfen hatte. Dieser Ansatz trägt den Namen AI Native Rapid Development, intern abgekürzt als AIRD, und wird bei meimberg.digital und form4.
Der Markt automatisiert nur einen Schritt
Wenn heute von Softwareentwicklung mit KI die Rede ist, ist damit fast ausschließlich das Erzeugen von Code gemeint. Ein Entwickler beschreibt eine Aufgabe in einem Werkzeug, und dieses liefert Code zurück. Dieser Vorgang ist real und nützlich, deckt jedoch nur einen Ausschnitt des Gesamtprozesses ab.
Softwareentwicklung besteht nicht allein aus dem Codieren. Das Codieren ist der sichtbare Teil in der Mitte. Davor liegen die Anforderungen, die Spezifikation, das Datenmodell und die Architektur. Danach folgen Tests, Sicherheitsprüfungen, Auslieferung und Betrieb. Genau diese vor- und nachgelagerten Teile bleiben beim üblichen KI-Einsatz Handarbeit oder entfallen ganz.
Die Folge ist bekannt: Innerhalb weniger Tage entsteht ein beeindruckender Prototyp, der im Ernstbetrieb auseinanderfällt, weil niemand die Anforderungen sauber erfasst, die Datenstruktur durchdacht oder die Architektur und die Sicherheit geprüft hat. Ein schneller Anfang mündet in Stillstand. Diese Sorge begleitet die meisten, die sich dem Thema nähern, und sie ist berechtigt.
Der ganze Prozess läuft agentisch
Das Neue am AIRD-Ansatz ist nicht die Geschwindigkeit beim Codieren, sondern die Breite der Automatisierung. Der komplette Engineering-Prozess läuft durchgängig über KI-Agenten. Dazu gehören das Codieren ebenso wie die Aufnahme der Anforderungen, die Spezifikation, die Modellierung, das Einrichten der Architektur, das Anlegen der Tickets, die Qualitätssicherung, die Sicherheitsprüfung, die Auslieferung und die Dokumentation, von der ersten Anforderung bis zum Betriebshandbuch.
Ein KI-Agent ist dabei ein Automatisierungswerkzeug, das eine klar umrissene Aufgabe eigenständig erledigt und dafür weitere Werkzeuge bedient (i. d. R über MCP, APIs oder CLI-Wrapper): Dateien lesen, ins Ticketsystem schreiben oder Tests starten. Viele dieser Aufgaben verursachen kaum noch Kosten. Das Schreiben einer Ticketspezifikation oder das Durchführen einer Qualitätsprüfung nach jeder Änderung verbraucht Rechenzeit (und Tokens), aber fast keine menschliche Arbeitszeit. Genau dieser Umstand verändert die wirtschaftliche Grundlage des Verfahrens.
Das teure Engineering ist wieder bezahlbar
Es existierte einmal ein sehr gründlicher Weg, Software zu spezifizieren: Lastenheft, Stakeholder-Analyse, Use-Case-getriebenes Design, ein Geschäftsobjektmodell, ein Datenmodell und dokumentierte Architekturentscheidungen. Diese Verfahren waren fachlich gut, hatten aber einen entscheidenden Nachteil: Sie waren teuer und langsam und in ihrer Komplexität über die Product-Lifetime schwer zu managen. Ein Mensch arbeitete wochenlang an Dokumenten, bevor die erste Zeile Code entstand. Die agile Bewegung hat diese Praxis aus nachvollziehbaren Gründen weitgehend abgeschafft.
Der Grund für die Abschaffung war nie, dass diese Dokumente wertlos gewesen wären, sondern dass ihre Erstellung zu viel kostete. Genau dieser Kostenfaktor ist unter dem Einsatz von Agenten verschwunden. Wenn ein Agent das Datenmodell aus den Anforderungen ableitet und ein Architekturkonzept in Stunden statt in Wochen entsteht, wird die aufwendige Gründlichkeit wieder bezahlbar.
Damit ist das klassische, schwergewichtige Engineering unter Agenten erneut das effizienteste Vorgehen. Ein detailliertes Konzept ist kein bürokratischer Ballast, sondern die beste Vorlage, die ein umsetzender Agent erhalten kann.
Die vier Phasen
Der Ablauf im AIRD gliedert sich in vier Phasen. Die erste enthält den größten Anteil menschlicher Arbeit, die letzten drei laufen weitgehend über Agenten.
Phase 1: Anforderungen aufnehmen und verstehen
Zu Beginn liefert der Kunde sämtliches vorhandenes Material: Konzepte, Screenshots, Datenmodelle, alte Verträge, E-Mails und im Zweifel den Zugang zum Altsystem. Dieser unsortierte Bestand kommt vollständig in ein zentrales Repository.
Daraus entsteht zunächst gemeinsam mit dem Kunden ein Vision-Statement, das den Kern des Vorhabens in ein bis zwei Sätzen festhält. Anschließend wird eine Baseline erstellt: Die Rohdokumente werden gesichtet, Dubletten entfernt, Widersprüche markiert und das Wesentliche vom Historischen und Veralteten getrennt. Das Ergebnis ist ein konsistentes Ausgangsset.
Es folgt der wichtigste Termin des Projekts: ein intensiver Workshop von drei bis fünf Stunden mit den fachlich relevanten Beteiligten, darunter Personen für die Geschäftsprozesse, die Technik und bei Bedarf die Bedienoberfläche. Ziel ist es, den gesamten Umfang im Detail durchzusprechen, etwa die Zusammenhänge der Daten, das Verhalten beim Löschen eines Datensatzes und seltene, aber wichtige Fälle. Das Gespräch wird vollständig aufgezeichnet und in Text umgewandelt. Nach diesem Workshop sind erfahrungsgemäß rund 90 Prozent aller Anforderungen fixiert. Diese Phase ist die eine Stelle, an der echte menschliche Arbeit erforderlich bleibt, denn die Qualität der Fragen bestimmt die Qualität des gesamten weiteren Prozesses.
Phase 2: Spezifikation und Engineering mit Volve
Das Herzstück des Verfahrens bildet ein eigenes Tool namens Volve, das den klassischen Requirements- und Engineering-Prozess als Kette von Agenten abbildet. Ich und wir nutzen dieses Tool, es lässt sich aber genauso gut mit gut durchdachten Agent-Playbooks durchführen.
Zunächst erfolgt das Seeding: Alle Ergebnisse aus Phase 1, also Transkripte, Notizen und kuratierte Dokumente, gelangen als Rohmaterial in Volve. Der erste Agent konsolidiert diesen Bestand zu einer strukturierten Wissensbasis, ohne informationstragende Inhalte zu kürzen. Anschließend führt ein Agent eine automatische Lücken- und Widerspruchsanalyse durch und erzeugt eine Liste konkreter Fragen, die das menschliche Team beantwortet. Aus den Antworten und dem Rohmaterial entsteht ein finales Seed inklusive der dokumentierten Entscheidungen.
Danach läuft der eigentliche Engineering-Workflow, gegliedert in fünf bis acht Stages. Jede Stage liefert ein Artefakt, das in die nächste einfließt:
funktionale und nicht-funktionale Anforderungen im Charakter eines Lastenhefts
sauber definierte und spezifizierte Use Cases
ein Geschäftsobjektmodell und daraus ein Datenmodell für die Speicherung
ein Maskeninventar mit textuellen Wireframes für die Oberfläche
die Service-Spezifikation als Beschreibung der 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 sind als Architekturregeln und dokumentierte Architekturentscheidungen hinterlegt. Über alle Stages hinweg prüfen Review-Schleifen jedes Artefakt gegen die Anforderungen; bei Bedarf schaut ein Mensch darüber.
Am Ende steht ein Implementierungskonzept von (in A4-Dimensionen gedacht) 150 bis 200 Seiten, aufgeteilt in typischerweise 10 bis 20 Epics und 100 bis 250 User Stories, aus dem sich direkt entwickeln lässt.
Phase 3: Implementierung
Aus dem Konzept erzeugt das System die Tickets, oft 100 - 200 oder mehr, direkt im Ticketsystem. Die Agenten setzen diese nacheinander um. Die Qualitätssicherung ist von Anfang an Teil des Ablaufs und kein abschließender Schritt: Unit-Tests, 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 agiert auf der Aufsichtsebene, der Betreuungsaufwand ist gering.
Das Ergebnis trifft die Anforderungen genau und übertrifft sie im Detail oft, weil die Agenten gängige Best Practices von selbst ergänzen, etwa eine sinnvolle Passwort-Regel oder einen Hover-Effekt an passender Stelle. Am Ende dieser Phase liegt eine Software 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. Am Ende steht Version 1.0.
Volve als System im Hintergrund
Volve ist der Motor von Phase 2. Es handelt sich nicht um ein verkäufliches Werkzeug, und niemand außerhalb muss es bedienen können. Es belegt, dass sich der gesamte Engineering-Prozess agentisch abbilden lässt und am Ende ein Konzept entsteht, aus dem produktionsreife Software hervorgeht. Für den Kunden bleibt Volve unsichtbar; sichtbar ist allein das Ergebnis.
Produktionsreife ab der ersten Lieferung
Der zentrale Vertrauensfaktor bei KI-gestützter Softwareentwicklung ist die Frage, ob das Ergebnis im Ernstbetrieb standhält. 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
Diese Bestandteile sind kein optionaler Zusatz, sondern Teil jeder Lieferung. Das Qualitätsniveau während der Entwicklung liegt dabei über dem, was reine Handarbeit erreicht, weil eine Maschine jeden einzelnen Schritt prüfen kann. Beim Menschen verbleibt das Urteil über Architektur, Sicherheit und die Frage, ob das Richtige entsteht.
Geringe Belastung für den Kunden
Für den Kunden bleibt der Aufwand gering. Er stellt das vorhandene Material bereit, nimmt an einem Workshop ohne Vor- und Nachbereitung teil und erhält einige Wochen später produktionsreife Software zu einem Bruchteil der Kosten klassischer Individualentwicklung. Die vollständige Gründlichkeit – Lastenheft, Datenmodell, Architekturentscheidungen und Tests – läuft im Hintergrund ab. Sie ist der Grund für die Belastbarkeit des Ergebnisses, liegt aber nicht als Last beim Kunden.
Einordnung
Der Markt hat bislang einen einzelnen Schritt automatisiert und bezeichnet dies als KI-Softwareentwicklung. Der beschriebene Ansatz automatisiert stattdessen den gesamten Prozess und holt dabei die aufwendige Sorgfalt zurück, die unter Agenten wieder bezahlbar geworden ist. Geschwindigkeit war nie das eigentliche Problem. Die Kombination aus Gründlichkeit und Geschwindigkeit war früher wirtschaftlich nicht darstellbar – unter dem Einsatz von Agenten ist sie es. Die vollständige Methode ist erstmals in einem Artikel auf meimberg.io dokumentiert.
&w=3840&q=75)