Warum gute Softwareentwicklung mit KI nicht beim Coding beginnt, sondern beim Verstehen der Anforderungen.
KI kann heute erstaunlich viel Code erzeugen. Was früher Stunden oder Tage gedauert hat, lässt sich teilweise in Minuten implementieren. Doch damit entsteht ein Problem, das durch immer leistungsfähigere KI-Modelle allein nicht verschwindet:
Woher weiß die KI eigentlich, was der Mensch wirklich möchte?
Ein Coding-Agent kann eine Anforderung technisch korrekt umsetzen und trotzdem eine Software entwickeln, die am eigentlichen Bedarf vorbeigeht.
Das Problem liegt dann nicht unbedingt im Code. Es liegt in der Übersetzung zwischen menschlicher Vorstellung und technischer Umsetzung.
Menschen denken in Problemen, nicht in User Stories
Wer eine Softwareidee hat, denkt normalerweise nicht in Datenmodellen, Schnittstellen, Fehlerfällen und Akzeptanzkriterien.
Ein Nutzer sagt beispielsweise:
„Ich möchte, dass meine Kunden automatisch benachrichtigt werden, wenn sich der Status ihrer Bestellung ändert.“
Das klingt zunächst eindeutig. Für die Implementierung bleiben aber zahlreiche Fragen offen.
Welche Statusänderungen sollen eine Benachrichtigung auslösen? Über welchen Kanal sollen Kunden informiert werden? Was passiert, wenn die Benachrichtigung nicht zugestellt werden kann? Dürfen Kunden die Benachrichtigungen deaktivieren? Und wie wird verhindert, dass sie bei mehrfachen Statusänderungen unnötig viele Nachrichten erhalten?
Ein menschliches Entwicklungsteam würde solche Fragen idealerweise mit dem Auftraggeber klären. In der Praxis geschieht das allerdings nicht immer vollständig.
Bei KI-gestützter Entwicklung kann dieses Problem noch deutlicher werden: Ein Coding-Agent ist in der Lage, fehlende Vorgaben durch eigene Annahmen zu ersetzen und auf dieser Grundlage sehr schnell eine scheinbar fertige Lösung zu produzieren.
Schneller Code ist kein Fortschritt, wenn er das falsche Problem löst.
Der Business Analyst als Gesprächspartner
Genau hier setzt PAUL an.
Bei PAUL beginnt Softwareentwicklung nicht damit, dass ein Nutzer einen möglichst perfekten Prompt formulieren muss. Stattdessen spricht er mit einem spezialisierten KI-Agenten: dem Business Analysten.
Dessen Aufgabe ist es, die fachlichen Vorstellungen des Nutzers zu verstehen und gemeinsam mit ihm so weit zu konkretisieren, dass daraus umsetzbare Anforderungen entstehen.
Dabei geht es nicht darum, jede denkbare technische Einzelheit abzufragen.
Der Business Analyst soll vielmehr erkennen, welche Informationen für die spätere Umsetzung tatsächlich wichtig sind, welche fachlichen Entscheidungen noch fehlen und wo Widersprüche bestehen.
Der Nutzer bleibt Experte für seine fachlichen Anforderungen. Der Business Analyst unterstützt ihn dabei, dieses Wissen für die Softwareentwicklung nutzbar zu machen.
Aus einem Gespräch werden umsetzbare Jira-Tickets
Aus der geklärten Anforderung erstellt PAUL strukturierte Jira-Tickets.
Diese beschreiben nicht nur eine gewünschte Funktion, sondern schaffen die Grundlage für deren technische Umsetzung und spätere Überprüfung.
Dazu gehören insbesondere das fachliche Ziel, das erwartete Verhalten und geeignete Akzeptanzkriterien.
Eine Anforderung wie „Kunden automatisch benachrichtigen“ kann dadurch zu einer überprüfbaren Beschreibung werden, in der festgelegt ist, wann eine Nachricht verschickt werden soll, welche Informationen sie enthält und welche Ausnahmen berücksichtigt werden müssen.
PAUL orientiert sich dabei an etablierten Konzepten der agilen Anforderungsarbeit. Entscheidend ist allerdings nicht, ob ein Ticket formal besonders schön geschrieben ist.
Entscheidend ist, ob ein nachgelagerter KI-Agent daraus möglichst genau die Software entwickeln kann, die der Nutzer beabsichtigt hat.
Anforderungen werden mehrfach überprüft
Mit der Erstellung eines Jira-Tickets endet die fachliche Qualitätssicherung bei PAUL nicht.
Der Softwarearchitekt prüft die Anforderungen erneut, bevor er daraus eine technische Planung ableitet.
Anschließend überprüft auch der Developer die Vorgaben, bevor er mit der Implementierung beginnt.
Stellen diese Agenten Unklarheiten oder Widersprüche fest, können sie über Jira-Tickets eine Konkretisierung anfordern.
Damit muss ein Agent nicht einfach raten, wenn eine Vorgabe unvollständig ist. Der Entwicklungsprozess enthält bereits Mechanismen, um offene Fragen sichtbar zu machen und klären zu lassen.
Die verschiedenen Prüfungen betrachten dieselbe Anforderung aus unterschiedlichen Perspektiven: aus fachlicher, architektonischer und implementierungstechnischer Sicht.
Das garantiert keine fehlerfreie Software. Es reduziert aber das Risiko, dass eine missverstandene Anforderung unbemerkt durch den gesamten Entwicklungsprozess läuft.
Warum das wichtiger wird, je besser KI programmieren kann
Wenn die technische Implementierung immer schneller wird, gewinnen andere Fragen an Bedeutung.
Ist das fachliche Ziel richtig verstanden worden? Sind die Anforderungen widerspruchsfrei? Wurden wichtige Randfälle berücksichtigt? Und lässt sich anschließend überprüfen, ob die entwickelte Software den ursprünglichen Bedarf erfüllt?
Ein immer leistungsfähigerer Coding-Agent kann diese Fragen nicht allein dadurch beantworten, dass er besseren Code schreibt.
PAUL setzt deshalb bereits vor der Implementierung an.
Der Mensch beschreibt, was er erreichen möchte. Der Business Analyst hilft dabei, daraus präzise Anforderungen zu entwickeln. Der Architekt übernimmt die technische Planung. Der Developer setzt diese um.
Die eigentliche Leistung besteht darin, dass der Nutzer nicht selbst zum Experten für KI-Prompts oder Softwarearchitektur werden muss.
Idee rein, Software raus
Unser Anspruch bei PAUL lautet: „Idee rein, Software raus.“
Dahinter steckt mehr als die automatische Generierung von Quellcode.
Damit aus einer Idee tatsächlich die gewünschte Software werden kann, muss zunächst verstanden werden, was der Nutzer erreichen möchte.
Der Business Analyst übernimmt bei PAUL eine zentrale Rolle in diesem Prozess.
Denn Softwareentwicklung beginnt nicht mit der ersten Zeile Code.
Sie beginnt mit der richtigen Vorstellung davon, was die Software leisten soll.
Im zweiten Teil zeigen wir, wie die spezialisierten KI-Agenten von PAUL ihre Arbeit über Jira koordinieren, Anforderungen gegenseitig prüfen und Implementierungsfehler automatisch korrigieren.