Wer entscheidet über die Geschäftsregeln im KI-generierten Code?

Die Funktion zur Adressänderung ist fertig, alle Tests laufen erfolgreich durch. Trotzdem weist die operative Leitung auf eine Bestellung hin, deren Adresse sich noch ändern lässt: „Im Lager stellen sie diese Bestellung bereits zusammen.“

In diesem hypothetischen System wartet die Anwendung auf eine Meldung aus dem Lager, bevor sie den Bestellstatus auf „in Vorbereitung“ setzt. An diesen Status hat der Entwickler die Adressänderung gebunden. Für die operative Leitung beginnt die Vorbereitung dagegen, sobald die Beschäftigten im Lager die Waren zusammenstellen, also kommissionieren. Kommt die Meldung verspätet an, kann der Kunde noch eine neue Adresse eingeben, obwohl die Arbeit längst begonnen hat.

Der KI-generierte Code setzt die Anweisung um. Erst jetzt fällt auf, dass Entwicklung und Betrieb unter „Vorbereitung hat begonnen“ unterschiedliche Zeitpunkte verstehen. Das Team muss erneut über das Verhalten einer Funktion entscheiden, die es bereits für fertig hielt.

Mehr Code mit KI zu erzeugen reicht deshalb nicht aus, um mehr nutzbare Software bereitzustellen. Das Team muss sich über den beabsichtigten Geschäftsablauf einig sein, ihn in Akzeptanzkriterien fassen und den Code an der aktuell gültigen Entscheidung ausrichten. Dazu gehört auch, dass jemand offene Fragen verbindlich entscheiden darf.

Eine frühere Sperre nimmt dem Kunden Zeit

Der Betrieb will vermeiden, dass eine neue Adresse zusätzliche Korrekturarbeit an einer Sendung verursacht, während das Lager schon mit der alten Adresse arbeitet. Das Produktteam möchte Kunden dagegen Änderungen bis zum Beginn der Vorbereitung erlauben. Beide Anliegen sind nachvollziehbar.

Der Entwickler könnte vorschlagen, Adressänderungen bereits zu sperren, wenn die Bestellung an das Lager übermittelt wird. Damit entfiele das Warten auf die verspätete Meldung. Nach der Übermittlung wartet die Bestellung in diesem System jedoch zunächst auf die Kommissionierung. Die Sperre würde also schon greifen, bevor jemand die Waren anfasst.

Der technische Fix verkürzt damit den Zeitraum für eine Adressänderung. Eine Statusprüfung lässt sich womöglich leicht ändern; die Einschränkung trifft aber den Kunden. Mit Beschwerden müssen sich Produktteam und Betrieb befassen. Wer den Code prüft, kann den Befund deshalb nicht mit „Statusprüfung korrigieren“ erledigen. Die zuständigen Personen müssen erkennen können, welches Verhalten sich für Kunden ändern würde.

Das Team hat eine Wahl: Es kann das Zusammenspiel von Lager und Anwendung ändern, um den bisherigen Zeitraum zu erhalten, oder die frühere Sperre akzeptieren. Die Entwicklung erläutert, was sich technisch umsetzen lässt. Welche Folge akzeptabel ist, entscheidet die Person, die zwischen den Anliegen von Produktteam und Betrieb abwägen darf.

Angenommen, das Team wählt für die erste Version die frühere Sperre. Aus dem mehrdeutigen „bis zum Beginn der Vorbereitung“ wird ein konkretes Akzeptanzkriterium: Nach Übermittlung der Bestellung an das Lager weist die Anwendung Adressänderungen zurück und zeigt dem Kunden an, dass keine Änderung mehr möglich ist. Die Tests prüfen dieses Verhalten. Das Team legt außerdem fest, wer Abweichungen zwischen Kundenansicht und Lagerablauf im laufenden Betrieb untersucht.

Die Begründung muss auch beim nächsten Umbau auffindbar sein

Wer später nur den Code sieht, könnte die Sperre für überflüssig halten, solange die Kommissionierung noch nicht begonnen hat. Ohne die Begründung könnte ein Entwickler bei einer vermeintlichen Verbesserung das ursprüngliche Problem zurückbringen. Dasselbe Risiko entsteht, wenn die Begründung in einer neuen Anweisung an die KI fehlt.

Deshalb muss sich nachlesen lassen, warum die Entscheidung getroffen wurde, für welchen Bestellablauf sie gilt und wer über eine Änderung entscheidet. Steht das bereits im zugehörigen Ticket, braucht es keine Kopie in einem weiteren Dokument. Code und Tests können auf diesen Eintrag verweisen. Ändert sich der Lagerablauf so, dass die frühe Sperre überflüssig wird, prüft das Team die Entscheidung erneut.

Wei Zhang und Jessie Jie Xia behandeln Prompts in Structured-Prompt-Driven Development als Eingaben für die Entwicklung, die zusammen mit dem Code versioniert und geprüft werden. Der Vorschlag stammt aus der Praxis der internen IT-Teams von Thoughtworks; ein kleines Abrechnungssystem dient als Beispiel. Der Beitrag enthält keine unabhängigen Vergleiche, die Aussagen über die Auswirkungen auf Geschwindigkeit, Qualität, Zuverlässigkeit, Kosten oder ROI stützen.

Für das Adressbeispiel ist daran der Gedanke nützlich, den vereinbarten fachlichen Zweck für spätere Codegenerierung verfügbar zu halten. Der Eintrag muss dafür aktuell bleiben. Entscheidet sich das Unternehmen für ein anderes Verhalten, müssen Anweisung, Akzeptanzkriterien, Tests und Code dieser Entscheidung folgen. Eine alte Entscheidung in Git zu speichern klärt noch nicht, welche bei der nächsten Änderung gilt.

Lohnt sich der Aufwand für die Entscheidungsnotizen?

Zusätzliche Einträge und Freigaben verursachen Arbeit. Ob sie sich lohnen, lässt sich etwa daran prüfen, ob das Team bei der nächsten Änderung den Grund für eine Regel leichter findet und weniger Nacharbeit durch Missverständnisse entsteht. Ebenso wichtig: Verbringen die Beteiligten ihre Prüfzeit mit dem Code oder warten sie auf jemanden, der entscheiden darf?

Das sind mögliche Prüfpunkte, keine belegten Verbesserungen. Der Aufwand für das Schreiben und Aktualisieren der Einträge gehört in die Betrachtung. Bei vergleichbaren Aufgaben lassen sich außerdem Fehler im laufenden Betrieb und notwendige Rücknahmen von Änderungen beobachten. Haben sich das Team oder die Art der Aufgaben verändert, lässt sich ein Unterschied schwerer allein auf die neue Dokumentationspraxis zurückführen.

Bei der Bestellung vom Anfang kann das Team nun erklären, warum die Adresse gesperrt wird, weshalb Kunden weniger Zeit bleibt und wann es die Entscheidung neu prüfen sollte. Wer die Funktion übernimmt, weiß, welches Verhalten erhalten bleiben muss. Neben funktionierendem Code gibt das Team damit auch das Verständnis weiter, was die Funktion leisten soll und warum sie so arbeitet.