KI-Coding macht Akzeptanzkriterien wichtiger, nicht weniger wichtig

Der Engpass liegt jetzt früher im Prozess

KI-Coding verändert die Wirtschaftlichkeit der Softwareentwicklung. Teams können heute Oberflächen, Integrationen, Datenmodelle und Testgerüste deutlich schneller erstellen als früher. Doch Tempo an der Tastatur schafft keine Produktklarheit. Es sorgt nur dafür, dass ein Team unklare Entscheidungen früher in funktionierende Software übersetzt.

Für wachsende Unternehmen ist das ein echtes Risiko. Eine Onboarding-App kann hochwertig gestaltet, mit dem LMS verbunden und mit KI-generierten Inhalten gefüllt sein – und neue Mitarbeitende dennoch enttäuschen. Vielleicht vermittelt sie Fakten über das Unternehmen, aber nicht die Aufgaben, die in der ersten Woche anstehen. Vielleicht gibt sie Führungskräften keine Möglichkeit, Fortschritte zu prüfen. Vielleicht legt sie sensibles Wissen über den falschen Ablauf offen. Schnellere Umsetzung senkt die Kosten solcher Fehler nicht. Sie kann sie sogar erhöhen.

Der Engpass verlagert sich damit in die frühe Produktentwicklung beim KI-Coding. Teams brauchen klarere Definitionen der Lernenden, der zu erledigenden Aufgabe, des Nutzungsmoments, der Verantwortlichen für Inhalte und der Belege dafür, dass ein Ablauf funktioniert. Der Scrum Guide definiert ein Produktziel als den zukünftigen Zustand, der die Planung leitet – aus gutem Grund: Umsetzungsentscheidungen brauchen ein klares Ziel.

Eine Vision eröffnet Optionen, setzt aber keine Grenzen

Breite Produktvisionen sind am Anfang hilfreich. „Ein KI-Produkt zur Content-Erstellung entwickeln“ oder „eine moderne Onboarding-Plattform schaffen“ kann die richtige Diskussion anstoßen. Doch daraus entstehen keine Anweisungen, die ein Umsetzungsteam oder Coding-Agent sicher ausführen kann.

In einer breiten Vision können Dutzende versteckte Entscheidungen stecken. Sollen Führungskräfte bestehende Foliensätze, Richtlinien, Videos oder SCORM-Pakete importieren? Welche Interaktionsformen passen zu einer Sicherheitsanweisung, welche zu einem Sales-Playbook? Dürfen Mitarbeitende einen KI-Assistenten zu unveröffentlichten Unternehmensinformationen befragen? Welche Lerndaten müssen in ein LMS fließen? Wer gibt generierte Inhalte frei, und was passiert, wenn sich das Ausgangsmaterial ändert?

Ohne klare Grenzen wird das Backlog zum Katalog plausibler Features. Das ist keine Produktstrategie für ein LMS, sondern ein System vertagter Entscheidungen. Jedes Feature kann für sich vernünftig klingen, doch als Produkt wird es schwer steuerbar, schwer erklärbar und gerade in den entscheidenden Lernmomenten schwach.

Discovery muss die Arbeit testen, nicht Vorlieben

Die praktische Antwort ist eine kurze, disziplinierte Discovery-Schleife, bevor sich die Architektur verfestigt. Es geht nicht darum, Meinungen zu Features einzusammeln. Es geht darum, Unsicherheit zu reduzieren, die sonst im Produkt festgeschrieben würde.

1. Formuliert eine Produktannahme in operativen Begriffen. Zum Beispiel: Ein neuer Account Executive braucht vor seinem ersten Kundengespräch zur Bedarfsermittlung einen fünfminütigen angeleiteten Ablauf.
2. Befragt die Menschen, die diese Aufgabe ausführen, führen oder unterstützen. Fragt nach dem aktuellen Ablauf, Fehlerquellen, Ausgangsmaterialien und einem Nachweis dafür, dass die Aufgabe kompetent erledigt wurde.
3. Überführt den Ablauf in ein einfaches Mockup. Zeigt Entscheidungspunkte, Inhaltsformat, Feedback-Schleife, Berechtigungen und die Übergabe an eine Führungskraft oder ein System.
4. Führt aufgabenbasierte Tests durch. Gebt Nutzenden ein realistisches Szenario und beobachtet, ob sie die Aufgabe erledigen können – nicht, ob ihnen das Konzept angeblich gefällt.
5. Haltet validierte und verworfene Anforderungen, offene Risiken und die nächste zu testende Annahme fest. Dann beginnt der nächste Durchlauf.

Zwei oder drei Durchläufe reichen oft, um eine belastbare erste Produktgrenze zu ziehen. Das Ergebnis ist konkret: eine zentrale Persona, ein priorisiertes MVP, getestete Kernabläufe, dokumentierte technische Risiken und Anforderungen an die Lerntechnologie, mit denen ein Umsetzungsteam arbeiten kann. Das ist besonders für Startups wichtig, in denen die Qualität des Onboardings nicht davon abhängen darf, welche Führungskraft in dieser Woche Zeit hat, das Unternehmen zu erklären.

Akzeptanzkriterien werden zur Steuerungsebene

Akzeptanzkriterien in der KI-Entwicklung machen aus der Produktabsicht eine überprüfbare Vereinbarung. Sie sagen Entwicklern oder Agenten, was erfüllt sein muss, wenn die Arbeit abgeschlossen ist. Gleichzeitig zeigen sie, was das Team noch nicht entschieden hat.

Schwaches Kriterium: „Nutzende können KI-Lerninhalte erstellen.“ Stärkeres Kriterium: „Ein Learning Manager kann aus einem freigegebenen Richtliniendokument ein dreistufiges Onboarding-Modul erstellen, jeden generierten Abschnitt vor der Veröffentlichung bearbeiten, das Modul einer benannten Kohorte zuweisen und den Abschlussstatus einsehen, ohne das Quelldokument Lernenden außerhalb dieser Kohorte zugänglich zu machen.“

Die stärkere Version definiert den Nutzer, den Ablauf, die Inhaltsquelle, den menschlichen Kontrollpunkt, die Berechtigungsgrenze und das messbare Ergebnis. Sie gibt der KI-gestützten Softwareentwicklung hilfreiche Leitplanken und macht Tests möglich. Das NIST Generative AI Profile weist darauf hin, dass generative KI zusätzliche menschliche Prüfung, Dokumentation und Managementaufsicht erfordern kann. Genau deshalb darf Governance nicht als vages Zukunftsthema behandelt werden.

Bei der Entwicklung mit KI-Agenten sollten Kriterien mehr als nur den Idealfall abdecken. Dazu gehören Rollen und Berechtigungen, leere Zustände, Fehlerbehandlung, Audit-Anforderungen, Inhaltsversionierung, Datenaufbewahrung, Barrierefreiheit, fehlgeschlagene Integrationen und die Bedingungen, unter denen die Funktion nicht aktiv werden darf. Ein Agent kann viele Wege zur Umsetzung erzeugen. Akzeptanzkriterien begrenzen diese Wege auf denjenigen, den das Produkt verantwortungsvoll tragen kann.

Konzeption und Umsetzung gehören in ein System

App-Learning beginnt vor dem Entwicklungsauftrag. Gemeinsam mit dem Produktteam definieren wir Personas, Lernabläufe, Inhaltsformate, technische Rahmenbedingungen und messbare Akzeptanzkriterien. Erst dann setzen wir KI dort ein, wo sie die Umsetzung beschleunigt: bei Prototypen, Entwicklung, Testerstellung, Content-Prozessen und Weiterentwicklung.

Diese Reihenfolge ist wichtig, denn ein Lernprodukt ist keine Sammlung von Oberflächen. Es schafft die Grundlage dafür, dass Menschen handlungsfähig sind: was sie wissen, tun, üben, nachweisen und erneut aufgreifen müssen, während sich das Unternehmen verändert. Eine klare Definition schützt das Unternehmen davor, ein schnelles, aber irrelevantes Tool zu bauen. Sie gibt Entwicklern und KI-Agenten zudem den Kontext, den sie für verlässlichen Nutzen statt nur plausibel wirkender Ergebnisse brauchen.

Am meisten von KI-Coding profitieren nicht die Teams mit den längsten Prompts. Es sind die Teams, die weniger offene Produktentscheidungen haben, ihre Lernabläufe früh testen und vor Beginn der Softwaregenerierung festlegen, wann die Arbeit erledigt ist.