Leitfaden zur spezifikationsgesteuerten Entwicklung und agentenbasierten KI-Softwareentwicklung

In diesem Artikel durchlaufen wir einen vollständigen, KI-gestützten Softwareentwicklungs-Workflow – vom KI-generierten Prototyp und der Funktionsspezifikation über die Implementierungsplanung und die Erstellung von GitHub-Issues bis hin zur koordinierten Ausführung durch spezialisierte KI-Agenten. Sie werden sehen, wie KI-Softwareentwicklung, die auf einer spezifikationsgesteuerten Entwicklung basiert, einen strukturierten KI-Softwareentwicklungszyklus schafft, der geschäftliche Vorgaben in unternehmensreife Software umsetzt und dabei Architektur, Qualität und Implementierung unter Kontrolle hält.  

In der ersten Demo-Sitzung unserer Reihe „Vom Prototyp zur Produktion mit Agentic AI“ hat Martin Kaiser, unser Digital Product Designer, einen Prototyp erstellt, indem er denselben Prozess anwandte, den Sie auch bei der Zusammenarbeit mit einem Kunden anwenden würden: Er hat die geschäftlichen Ziele erfasst und die Lösung live entwickelt.  

Ausgehend von diesem Prototyp fand dann die zweite Sitzung statt, in der Michael, der KI-Softwareentwickler bei PRODYNA, die KI-Grundlage für alles schuf, was in diesem Blog noch folgt. Er zeigte, wie man benutzerdefinierte Agenten, die KI-Infrastruktur und das Framework erstellt, das wir nun zur Entwicklung der Anwendung nutzen werden.  

Auf dieser Grundlage werden wir nun diese KI-Grundbausteine und benutzerdefinierten Agenten nutzen, um den Prototyp in eine Software auf Unternehmensniveau umzuwandeln.

Der Prozess der Umwandlung des Prototyps in unternehmensgerechte Software umfasst vier Schritte.

Der erste Schritt ist der Prototyp, der die geschäftliche Absicht hinter der Anwendung widerspiegelt.

Daraus leiten wir dann die Spezifikationen ab. Was wollen wir eigentlich entwickeln? Wir nutzen KI, um diese Spezifikationen zu ermitteln und uns ein klares Bild davon zu verschaffen, was umgesetzt werden muss.

Im nächsten Schritt planen wir die Umsetzung. Wir geben die technischen Details des Technologie-Stacks ein, den wir für die Entwicklung der Anwendung nutzen möchten, sowie die architektonischen Entscheidungen und Rahmenbedingungen.

Wir verbinden die geschäftlichen Ziele und die Spezifikationen mit all diesen technischen Einschränkungen, um einen Implementierungsplan zu erstellen, und gliedern diesen Plan in kleinere Teilaufgaben auf, die wir später an unsere KI-Agenten delegieren können. An dieser Stelle wird die Entwicklung von KI-Software zu einem strukturierten, wiederholbaren Prozess.

Spezifikationsgesteuerte Entwicklung

Phase 0: KI-Infrastruktur

Phase Null ist die Governance-Ebene. Michael hat gezeigt, dass wir mithilfe von benutzerdefinierten Copilot-Anweisungen, benutzerdefinierten Agenten, Hooks und Skills unsere Vorgehensweise bei der Softwareentwicklung kodieren und dieses Wissen der KI zugänglich machen. Das ist die Governance-Ebene.

Phase 1: Spezifikation

Wir werden der KI unseren Prototyp und die User Stories zeigen, die Martin während seines Prototyping-Workshops erstellt hat, und die KI bitten, die geschäftliche Absicht zusammenzufassen.

Der Prototyp enthält viele technische Details. Aus programmiertechnischer Sicht ist er nicht besonders gut strukturiert, da es sich um einen Prototyp handelt – er wurde in kurzer Zeit entwickelt. Aber wir können mithilfe von KI verstehen, was wir eigentlich entwickeln wollen, und daraus die Funktionsspezifikation ableiten.

Je besser Ihre Spezifikation ist, desto robuster wird der Entwicklungszyklus Ihrer KI-Software.

Dies entspricht den Prinzipien der spezifikationsgesteuerten Entwicklung, bei der eine klar definierte Spezifikation die Umsetzung leitet und sowohl für Ingenieure als auch für KI-Agenten als gemeinsame Referenz dient.

In der KI-Softwareentwicklung ist es die Präzision – und nicht die Eingabe von Prompts –, die den Unterschied zwischen einem erfolgreichen Entwicklungszyklus für KI-Software und unnötigen technischen Schulden ausmacht. Klare Spezifikationen machen die Umsetzung vorhersehbarer, wartbarer und skalierbarer.

Phase 2: Planung und Aufgabenaufteilung

In dieser zweiten Phase tragen wir alle technischen Details ein und erarbeiten auf dieser Grundlage einen Plan, wie wir die vom Unternehmen geforderten Lösungen umsetzen können.  

Anschließend teilen wir dies in kleinere Teilaufgaben auf und legen fest, welcher der benutzerdefinierten Agenten, die wir letzte Woche erstellt haben, für die jeweilige Aufgabe eingesetzt werden soll.  

Zuvor entwickelte Michael maßgeschneiderte Agenten für die Frontend-Entwicklung, die Backend-Entwicklung und das Verfassen von API-Spezifikationen. Diese Agenten sind sehr zielgerichtet und auf die Ausführung bestimmter Aufgaben spezialisiert.

In der Planungsphase identifizieren wir nun die einzelnen Aufgaben und ordnen sie den entsprechenden Agenten zu. Auf diese Weise werden die Aufgaben bei der Ausführung nicht von einem allgemeinen KI-Agenten, sondern von einem Experten ausgeführt. Genau das geschieht in diesem Schritt.  

Wir haben unsere Aufgabenliste. Wir wissen, welcher benutzerdefinierte Agent die jeweilige Aufgabe ausführen soll. Damit kommen wir zur letzten Phase.

Phase 3: Umsetzung des Produkts

Damit kommen wir zur letzten Phase, in der wir über einen Koordinationsagenten verfügen, der alle auszuführenden Aufgaben erfassen, sie in eine logische Reihenfolge bringen und an die entsprechenden Ausführungsagenten delegieren kann. Er hält im Grunde alles zusammen, koordiniert alle Unteragenten und stellt sicher, dass diese die Aufgaben korrekt ausführen.

Wir beginnen auf der linken Seite mit dem von uns erstellten Prototyp des „Product Finder “. Diesen geben wir in den „Spec Agent“ ein. Der „Spec Agent“ erstellt eine Markdown-Datei auf der Grundlage einer vordefinierten Struktur, die festlegt, was wir in einer solchen Spezifikation erwarten, und extrahiert daraus die geschäftliche Absicht.

Als Nächstes haben wir einen Agenten, der sich als sehr, sehr hilfreich erwiesen hat: den Review-Agenten. Seine einzige Aufgabe besteht darin, die soeben erstellte Funktionsspezifikation durchzugehen, sie auf Konsistenz zu prüfen, Lücken und logische Fehler zu identifizieren, Fragen zur Klärung zu stellen, Optimierungsvorschläge zu unterbreiten und die Spezifikation zu verfeinern. Er bietet uns eine zweite Sichtweise auf die Spezifikation und hilft uns so, sie noch weiter zu verfeinern.

Mit dieser Spezifikation übergeben wir das Projekt dann an unseren Planungsagenten. Wie Sie sehen werden, habe ich den Planungsagenten so konzipiert, dass er die Spezifikation prüft, alle Vorgaben und die von uns gewünschten Technologien berücksichtigt, die Arbeit anschließend in Aufgaben unterteilt und für jede davon ein GitHub-Issue erstellt.

Nachdem der Planungsbeauftragte seine Arbeit abgeschlossen hat, haben wir eine lange Liste von GitHub-Issues, die wir umsetzen müssen, um die in der Spezifikation definierten Geschäftsanforderungen zu erfüllen.

Schließlich übergeben wir alles an unsere Ausführungs-Engine– unseren Orchestrierungsagenten. Wir weisen ihn an, alle Aufgaben für diese bestimmte Funktion zu erfassen, sie in die richtige Reihenfolge zu bringen und mit der Umsetzung zu beginnen, indem er Unteragenten erstellt, die die eigentliche Arbeit erledigen. Diese Unteragenten sind Experten für die Umsetzung ihrer jeweiligen Aufgaben.

Dies hat mehrere Vorteile. Erstens können Sie die Arbeit parallelisieren. Wenn Sie über voneinander unabhängige Aufgaben verfügen, ist es kein Problem, alle Agenten parallel zu starten und den Prozess zu beschleunigen.

Ein weiterer sehr wichtiger Aspekt ist, dass diese spezialisierten Unteragenten ihren eigenen Kontext haben. Sie wissen nicht alles, was zu tun ist. Sie konzentrieren sich ausschließlich auf eine bestimmte Aufgabe mit sehr klaren Anweisungen. Ihr Kontextfenster ist sehr, sehr stark auf die eigentliche Aufgabe ausgerichtet, und das hilft dabei, die Umsetzung zu steuern.

Ein sehr wichtiger Aspekt ist dabei: Für jeden der Unteragenten muss ein klar definierter Kontext vorliegen.  

Um zu sehen, wie das in der Praxis funktioniert, wechseln wir zu Visual Studio Code.

Die Demo-Anwendung: KI-Softwareentwicklung in der Praxis

Um den Arbeitsablauf zu veranschaulichen, beginne ich mit einer einfachen Anwendung, an der wir weiterarbeiten können. Die Anwendung läuft bereits und zeigt eine Liste von Produkten an.

Wir haben ein fiktives Unternehmen namens KLEB mit etwa 700 bis 800 verschiedenen Klebstoffprodukten. Diese weisen unterschiedliche Eigenschaften, unterschiedliche Materialarten und unterschiedliche Anwendungsbereiche auf.

Das Ziel ist es, eine Fachanwendung zu entwickeln, mit der sich all diese Produkte schnell filtern, durchsuchen und vergleichen lassen. Das ist der Anwendungsfall.

Zum jetzigen Zeitpunkt wurde lediglich die Startseite umgesetzt. Funktionen wie „Vergleichen“ und die Produktdetailseiten müssen noch implementiert werden.

Es handelt sich bereits um eine dreischichtige Anwendung. Wir haben unser Frontend, bei dem es sich um eine Single-Page-Anwendung handelt. Wir haben unser Backend mit einer in Java geschriebenen REST-API, und wir haben eine Persistenzschicht.

Für die lokale Entwicklung nutzt die Anwendung SQLite. Im Produktivbetrieb kommt ein ORM-Mapper mit einer PostgreSQL-Datenbank zum Einsatz. Dies ist ein sehr gängiger Technologie-Stack.

Wenn wir uns das Projekt ansehen, können wir bereits den generierten Code erkennen.

Wir verfügen bereits über unsere OpenAPI-Spezifikation. Diese wurde nach demselben Verfahren generiert, das wir auch für die übrigen Funktionen anwenden werden. Hier dient die Spezifikation nicht nur als Dokumentation – sie steuert direkt die Implementierung, was den Kerngedanken hinter der spezifikationsgesteuerten Entwicklung (Spec-Driven Development) ausmacht. Die Backend-Implementierung in Java ist klar in Domänen unterteilt und befolgt alle in den spezialisierten Agenten definierten Architekturregeln.

Spezialisierte KI-Agenten

Zusammenfassend lässt sich sagen, dass wir einen Backend-Entwickler haben, der auf die Erstellung von Java-Backends mit Spring Boot spezialisiert ist.

Es gibt einen klar definierten Tech-Stack, an den man sich halten muss. Außerdem gibt es eine Reihe von Architekturregeln, die bei der Implementierung des Backends, der Anwendungsstruktur und allem, was damit zusammenhängt, beachtet werden müssen. Dabei handelt es sich um sehr detaillierte Informationen. In der Regel findet man diese in einem Entwicklerhandbuch. In diesem Fall haben wir sie in einem Markdown-Dokument zusammengefasst, das dem Mitarbeiter jederzeit zur Verfügung steht.  

Das ist einer der Vorteile beim Einsatz von KI-Agenten. Sie lesen immer die Dokumentation. Sie können sie sehr gut lesen und sich gut daran erinnern.

Im Grunde liest der KI-Agent jeden Morgen, wenn ein Entwickler mit der Arbeit beginnt, die gesamte Entwicklerdokumentation von Neuem durch. Das ist also Agent Nummer eins.

Als Nächstes haben wir einen speziellen Frontend-Agenten. Er ist mehr oder weniger genauso aufgebaut, enthält jedoch alle Regeln, die für die Frontend-Entwicklung gelten.

Außerdem verfügen wir über einen Spezialisten für die Erstellung von OpenAPI-Spezifikationen, wodurch wir das Backend und das Frontend mithilfe einer gemeinsamen OpenAPI-Spezifikation voneinander entkoppeln können.

Erstellung der Funktionsspezifikation: Der „Spec Writer Agent“

Funktionsspezifikation (in diesem Zusammenhang) = ein strukturiertes Dokument, das beschreibt, was das System leisten muss (Umfang, Akteure, Voraussetzungen, funktionale Anforderungen, API-Interaktionen und Abnahmekriterien), ohne dabei spekulative technische Implementierungsentscheidungen einzubeziehen.

Ich nutze meinen Spezifikations-Agenten. Er weiß genau, was zu tun ist. Er soll weder Code noch Tests noch sonst etwas schreiben. Er ist ausschließlich für das Verfassen von Spezifikationen gedacht. Außerdem weiß er, wo er die Informationen herholen muss, da ich ihm mitgeteilt habe, wo sich unser Prototyp-Repository befindet.

Wenn ich eine neue Sitzung eröffne, kann ich unseren Spezifikationsverfasser auswählen und ihm mitteilen, welche Spezifikation er erstellen soll.

Im Prototyp haben wir fünf User Stories. Diese werden wir als Ausgangspunkt für die Erstellung der Spezifikationen nutzen. Für drei davon habe ich das bereits erledigt. Die erste befasst sich mit der Anwendung insgesamt und dem Layout. Die zweite konzentriert sich auf komplexere Filterfunktionen. Wir haben die Produktdetailseite, und die vierte betrifft die Vergleichsfunktion.

Ich öffne kurz den Spec-Agent und gebe folgende Eingabe ein: „Schreibe die Spezifikation für 04-compare-feature.md.“

Nun überprüft der Agent das Prototyp-Repository und lädt den Inhalt mithilfe von GitHub MCP. Ich habe den Prototyp nicht lokal ausgecheckt oder Ähnliches. Das Tool läuft tatsächlich über den MCP-Server, stellt eine Verbindung zu GitHub her, greift auf das Repository zu und lädt alle erforderlichen Informationen.

Dies ist ein sehr häufiges Muster. Bei Kundenprojekten stellen wir oft fest, dass User Stories, Spezifikationen und zugehörige Dokumentation in der Regel in verschiedenen Systemen gespeichert sind.

In unserem Fall stammen die Informationen aus dem Prototyp-Repository, auf das wir über GitHub MCP direkt zugreifen können. Wir könnten den Agenten aber genauso gut auf Confluence oder Jira verweisen, je nachdem, wo die benötigten Informationen gespeichert sind. Wir müssen dem „Spec Writer“-Agenten lediglich mitteilen, wo er die Geschäftsabsicht ermitteln kann und wo er sie findet.

Daran können wir erkennen, dass das Programm die in der ersten Sitzung definierte Vergleichsfunktion gefunden hat und nun mit dem Verfassen der Spezifikation beginnt. In Kürze sollten wir die funktionale Spezifikation für die Vergleichsfunktion vorliegen haben.  

Der Agent sollte nicht raten müssen. Er sollte genau wissen, wo er suchen muss.

An dieser Stelle sei angemerkt, dass ich den Agenten ausdrücklich angewiesen habe, keine technischen Informationen aus den User Stories zu übernehmen. Bei Figma Make enthalten die User Stories viele React- und Tailwind-spezifische Informationen, sodass sie eine Mischung aus technischen und funktionalen Spezifikationen darstellen. Aus diesem Grund habe ich den Agenten ausdrücklich angewiesen, keine technischen Annahmen zu treffen und die Spezifikation rein funktional zu halten.  

Wir haben die User Story, den Umfang (was dazu gehört und was nicht), die Akteure, die Voraussetzungen sowie eine umfassende Liste der funktionalen Anforderungen, die jeweils mit einer eigenen ID versehen sind.

Diese Struktur habe ich dem für die Erstellung der Spezifikationen zuständigen Mitarbeiter zur Verfügung gestellt. Da dieser Mitarbeiter weiß, wie wir bei PRODYNA Spezifikationen verfassen, folgt diese stets derselben Struktur und ist durchgängig einheitlich gestaltet.

Wir haben noch einige weitere Informationen zur Benutzeroberfläche. Außerdem liegen uns die API-Anforderungen, die Interaktionsabläufe und die Abnahmekriterien vor. Wir können also sogar anhand all dieser Informationen Tests durchführen.  

Und los geht’s. Wir haben nun eine Funktionsspezifikation für unsere Vergleichsfunktion.

Überprüfung der Spezifikation: Der Review-Agent

Sobald die Funktionsspezifikation fertiggestellt ist, besteht der nächste Schritt darin, sie zu überprüfen, bevor mit der Umsetzungsplanung fortgefahren wird.

Ich starte den Überprüfungsagenten mit dem Befehl: „FS-04 überprüfen.“

Der Prüfer analysiert die Spezifikation, ermittelt Unstimmigkeiten, fehlende Informationen und Annahmen und schlägt Verbesserungen vor, bevor mit der Umsetzung begonnen wird.  

Während der ersten Überprüfungsrunde meldet der Agent mehrere Beanstandungen. Ich antworte mit der Aufforderung: „Bitte behebe zunächst die ersten Beanstandungen und zeige mir dann den Rest.“ Der Agent geht die Beanstandungen durch, berücksichtigt das Feedback und überarbeitet die Spezifikation, um sie klarer zu gestalten. Nach Abschluss der Überprüfung meldet er insgesamt 10 Beanstandungen: 1 Blocker, 5 schwerwiegende und 4 geringfügige.

Sobald diese Ergebnisse berücksichtigt wurden, ist die Spezifikation bereit für die Umsetzungsplanung.

Wir sehen die Meldung: „Die Spezifikation ist bereit für die Umsetzungsplanung, wobei eine Maßnahme zu verfolgen ist.“ Ich werde den Vorschlag annehmen, und damit sind wir hier fertig. Der Überprüfungsprozess für FS-04 ist abgeschlossen.

Implementierungsplanung: Der Spec-Planner-Agent

Der nächste Schritt ist die Umsetzungsplanung. Ich nutze den Spezifikationsplaner. Das habe ich bereits für Funktion Nummer zwei getan, und nun werde ich es für die Produktdetailseite tun. Ich werde dem Spezifikationsplaner folgende Eingabe geben: „FS-03 planen.“

Der Planer analysiert die Produktdetailseite und erarbeitet einen Umsetzungsplan. Möglicherweise müssen wir neue Frontend-Komponenten implementieren. Möglicherweise benötigen wir neue Backend-Endpunkte, um alle Details zu laden. All dies wird in GitHub-Issues aufgeschlüsselt.  

Umsetzungsplan (Agenten-Workflow) = eine sequenzielle Aufgliederung der Arbeit in testbare Einheiten, die jeweils spezialisierten Agenten zugewiesen sind und über explizite Abnahmekriterien sowie Abhängigkeiten verfügen.

Der Planer hat bereits eine Reihe verschiedener Aufgaben ausgearbeitet.  

Zuvor habe ich einige Implementierungsphasen für den Planer-Agenten definiert:

Dies ist der allgemeine Implementierungsprozess.

Der Planer wird nun die Spezifikation durchgehen, die Umsetzungsaufgaben festlegen und diese in verschiedene Phasen einteilen.

Die erste Phase beginnt mit der Arbeit an der API. Anschließend gehen wir zur Backend-Implementierung über. Sobald die Implementierung abgeschlossen ist, stehen Überprüfungsaufgaben an, um alles, was wir entwickelt haben, noch einmal durchzugehen. Dabei legen wir auch fest, welcher Agent für die jeweilige Aufgabe eingesetzt werden soll.  

Der Planer erstellt die GitHub-Issues, woraus sich ein vollständiger Satz von Umsetzungsaufgaben ergibt.

Wir haben nun 21 Aufgaben in acht Phasen, die alle mit GitHub synchronisiert sind.

Der Planer berichtet: „21 Aufgaben in 8 Phasen, die alle mit GitHub-Issues synchronisiert sind. Der Plan kann nun über den Spec-Executor-Agenten (FS-03) ausgeführt werden.“

Durchführung der Implementierung: Der Spec-Executor-Agent

Bei der Umsetzung geht es nicht um Improvisation. Es wird ein vorab festgelegter Plan umgesetzt.

Ich starte eine neue Sitzung mit dem Spec-Executor und gebe ihm den Befehl: „FS-02 implementieren.“

Der Agent ruft alle GitHub-Issues ab, die sich auf diese Spezifikation beziehen.

Der Spec-Executor ermittelt zunächst die Reihenfolge, in der die Aufgaben ausgeführt werden sollen. In diesem Fall stellt er fest, dass die grundlegenden Arbeiten am Frontend abgeschlossen sein müssen, bevor mit den übrigen Implementierungsaufgaben begonnen werden kann.

Als Nächstes wechsle ich zum Implementierungsantrag für FS-02 und beginne mit der Umsetzung der Funktion.

Spezialisierte KI-Agenten im Einsatz  

Ich sagte dem Orchestrierungsagenten: „Sobald du alle Aufgaben geladen hast, starte für jede Aufgabe einen Unteragenten.“ Genau das ist auch passiert. Jede Aufgabe wurde nun als eigener Unteragent gestartet.

Die Unteragenten können jedes Modell verwenden, das ich ihnen zuweise.

Das ist wirklich hilfreich, da man einen bestimmten Agenten individuell anpassen und ihn mit einem Modell verknüpfen kann, das eine bestimmte Aufgabe besonders gut bewältigt.

Anstatt zu versuchen, alles auf einmal zu lösen, löst jeder Agent ein klar definiertes Problem.

Beispielsweise eignen sich die GPT-5-Codex-Modelle sehr gut für die unkomplizierte Umsetzung. Sie sind in der Lage, sich auf das Ziel zu konzentrieren und auf ein klar definiertes Ziel hinzuarbeiten.

Opus-Modelle, insbesondere Opus 4.6, sind kreativer. Deshalb eignen sie sich besonders gut für das Verfassen von Spezifikationen. So kann ich je nach Agenten verschiedene Modelle auswählen.  

Jeder spezialisierte Agent konzentriert sich auf seine eigene Aufgabe, während der Koordinationsagent die gesamte Implementierung koordiniert. Dadurch bleibt der gesamte Implementierungsprozess strukturiert, konsistent und skalierbar.

Je nach Komplexität der Implementierung kann dieser Vorgang einige Zeit in Anspruch nehmen – unter Umständen sogar mehrere Stunden. Am Ende des Tages verfügen Sie dann über ein funktionsfähiges Produkt.

Skalierung von Systemen durch agentenbasierte Softwareentwicklung

Wir begannen mit einem KI-generierten Prototyp und entwickelten ihn von Haftnotizen und Wireframes zu einem funktionsfähigen Prototyp weiter.  

Anschließend haben wir die KI-Infrastruktur – unser KI-Betriebssystem – mit maßgeschneiderten Agenten, Governance-Mechanismen und wiederverwendbaren KI-Primitiven aufgebaut.  

Anschließend haben wir die geschäftlichen Vorgaben in funktionale Spezifikationen umgesetzt, diese überprüft und verfeinert, die Umsetzung geplant, GitHub-Issues erstellt und die Ausführung mithilfe spezialisierter KI-Agenten koordiniert.

Dieser durchgängige Prozess veranschaulicht, wie die spezifikationsgesteuerte Entwicklung die Grundlage für einen strukturierten Lebenszyklus der KI-Softwareentwicklung bildet und es Teams ermöglicht, Software auf Unternehmensniveau auf konsistente, skalierbare und wartbare Weise zu entwickeln.

Wenn Sie diesen strukturierten Prozess umsetzen, erzielen Sie in der Regel Folgendes:

• deutlichere Rückverfolgbarkeit der Anforderungen (Spezifikationen mit Umfang und Abnahmekriterien)
• weniger Überraschungen während der Umsetzung (durch die Überprüfung werden Probleme frühzeitig erkannt)
• Konsequente Einhaltung der Architektur (spezielle Agenten sorgen für die Durchsetzung der Regeln)
• Schnellere Iteration durch Delegierung und parallele Ausführung
• verbesserte Zuverlässigkeit durch Orchestrierung und Qualitätskontrollen

Vor allem aber schaffen Sie einen wiederholbaren Weg vom Prototyp zum produktionsreifen Produkt – anstatt die Logik jedes Mal manuell neu zu erstellen, wenn sich ein Prototyp als wertvoll erweist.

KI beschleunigt die Softwareentwicklung, doch die Einsatzreife in Unternehmen erfordert Disziplin: Anforderungen müssen über klar definierte Schnittstellen ermittelt, validiert, geplant und umgesetzt werden. Der hier beschriebene „Agentic“-Lebenszyklus – Prototyp → Funktionsspezifikation → Überprüfung → Planung → koordinierte Umsetzung – macht aus KI nicht nur ein Werkzeug, sondern einen Prozess.

Wenn Sie eine Erkenntnis mitnehmen möchten, dann diese: Erfolgreiche KI-Softwareentwicklung ist Orchestrierung, keine Improvisation. Wenn geschäftliche Ziele in KI-lesbare Spezifikationen strukturiert und die Umsetzung an spezialisierte, kontextorientierte Agenten delegiert wird, verlassen Sie sich nicht mehr auf den Zufall bei den Modellergebnissen – Sie entwickeln ein System, das Ergebnisse liefert.

Letztendlich geht es bei der agentenbasierten Softwareentwicklung darum, jedem Agenten eine klar definierte Verantwortung innerhalb eines strukturierten Entwicklungsprozesses zuzuweisen, damit Software vorhersehbar, konsistent und im Unternehmensmaßstab entwickelt werden kann.