Ich lese es inzwischen jede Woche. Die KI hat diesen Sonderfall nicht bedacht. Die KI hat die Fehlerbehandlung falsch gemacht. Die KI hat schon wieder etwas kaputtgemacht, das vorher lief.

Die Beobachtung stimmt meistens. Die Schlussfolgerung fast nie.

Denn eine KI tut in aller Regel genau das, was man ihr sagt. Was sie nicht kann, ist deine Gedanken lesen und deine Wünsche erraten.

Die Frage, die vor jeder Schuldzuweisung kommt

Bevor du der KI einen Fehler anhängst, beantworte eine einzige Frage ehrlich:

Hast du diese Regel gefordert, und sie wurde nicht umgesetzt? Oder war dein Requirement schlampig, und die KI hat exakt das gebaut, was dort stand?

Fall eins ist ein Werkzeugproblem. Den gibt es, und dann darfst du dich zu Recht aufregen.

Fall zwei ist ein Hausaufgabenproblem. Und Fall zwei ist der häufigere.

Der unangenehme Teil daran: Fall zwei sieht von aussen exakt gleich aus wie Fall eins. Am Ende steht in beiden Fällen ein Ergebnis, das nicht dem entspricht, was du im Kopf hattest. Nur war es in Fall zwei nie irgendwo ausser in deinem Kopf.

Früher hat das jemand für dich aufgefangen

Und hier sind wir am Kern.

Nachlässiges Requirements Engineering ist keine Erfindung des KI-Zeitalters. Es war immer da. Es ist nur nie aufgefallen, weil gute Entwicklerteams es abgefangen haben. Die haben zwar die Augen verdreht, es aber mit ihrer Erfahrung richtig gemacht. Sie haben die fehlende Regel ergänzt, den nicht spezifizierten Sonderfall behandelt und die drei Annahmen mitgedacht, die im Ticket nicht standen.

Diese stille Reparaturschicht war der eigentliche Qualitätsprozess in den meisten Firmen. Nur stand sie in keinem Prozesshandbuch, weil sie in keinem Prozesshandbuch stehen konnte. Sie war in Köpfen.

Genau das kann eine KI nicht. Und ehrlich gesagt: sie muss es auch nicht können.

Stattdessen müssen Requirements Engineers, im Scrum-Sprech Product Owner, endlich anfangen, ihren Job ernst zu nehmen. Ein Ticket, das sich nur mit fünf Jahren ungeschriebenem Hauswissen korrekt umsetzen lässt, ist kein Ticket. Das ist eine Andeutung. Und was dir gerade durch den Kopf schiesst, ist noch lange kein Requirement, auch wenn es sich im Refinement so anfühlt.

Die KI hat diese Lücke nicht erzeugt. Sie hat sie nur sichtbar gemacht.

Human in the Loop ist richtig. Nur nicht aus dem Grund, den du denkst

Die zweite Gruppe, die ich gerade überall lese, sind die, die bei KI alles kontrollieren wollen. Stichwort Human in the Loop.

Der Punkt ist richtig. Aber die Begründung ist fast immer falsch.

Warum kontrolliert der Senior Developer oder der Architekt das Ergebnis? Nicht weil die KI grundsätzlich unzuverlässig wäre. Sondern weil nirgends dokumentiert ist, wie in eurem Haus etwas zu tun ist. Welches Vorgehensmodell gilt. Welche Bibliothek warum verboten ist. Wie ihr Fehler behandelt, wie ihr loggt, was in diesem einen Altsystem niemals angefasst werden darf.

Der Senior prüft gegen einen Standard, den es nur in seinem Kopf gibt. Er ist nicht die Qualitätssicherung. Er ist die Spezifikation.

Und genau deshalb tut es so weh, wenn diese Leute gehen. Sie nehmen nicht Arbeitskraft mit. Sie nehmen den Standard mit.

Human in the Loop als Dauerzustand ist damit kein Qualitätsprozess. Es ist ein Abo auf Personenabhängigkeit.

Die Lösung ist unspektakulär: schreib es auf. Aber richtig

Nicht als Wiki. Ein Wiki wird geschrieben, wenn jemand Zeit hat, und gelesen, wenn jemand verzweifelt ist. Beides passiert selten genug, damit es nie funktioniert.

Sondern als Wissensgraph, der im Team mitläuft und sich permanent selbst ausbaut.

Ich habe damit vor rund drei Monaten angefangen. Inzwischen sind es 196 Markdown-Dateien, versioniert in Git. Ein Fakt pro Datei, untereinander verlinkt, nach Domänen sortiert. Darin steht sehr viel von meinem Vorgehensmodell: wie ich arbeite, was ich nicht will, welche Entscheidung wann aus welchem Grund gefallen ist, welche Annahme sich als falsch herausgestellt hat.

Zwei Dinge machen den Unterschied aus, und beide sind wichtiger als der Inhalt:

Geschrieben wird selbstständig. Claude legt einen neuen Knoten an, wenn etwas Neues gelernt wurde oder wenn ich korrigiert habe. Ohne dass ich jedes Mal daran erinnere. Wissen, dessen Erfassung an einer menschlichen Fleissaufgabe hängt, wird nicht erfasst.

Gelesen wird zuerst. Bei einer neuen Aufgabe liest er zuerst seinen Wissensgraphen und fängt nicht wieder bei Adam und Eva an. Ein Speicher, in den nur geschrieben wird, ist ein Friedhof.

Der Teil, der eure Geschäftsleitung interessieren sollte

Der schönste Nebeneffekt ist einer, über den in der ganzen KI-Diskussion viel zu wenig geredet wird: dieser Graph ist wiederverwendbar, wenn du das KI-Tool austauschst.

Wechselst du von ChatGPT zu Claude oder umgekehrt, weiss das neue Modell ab dem ersten Prompt exakt das, was das alte wusste. Kein Neuaufbau, kein Anlernen, keine sechs Wochen, in denen wieder alles zweimal erklärt wird.

Das ist die eigentliche strategische Erkenntnis für Entscheider: Vergrabt euer Wissen nicht in Chats. Chats sind kein Speicher, sie sind Verkehr. Organisiert es ordentlich in Wissensgraphen, die jeder neue Mitarbeiter und jedes neue KI-Modell mitnutzen kann.

Wer sein Firmenwissen in den Chatverläufen einzelner Mitarbeiter liegen lässt, hat sein Wissensmanagement an einen Anbieter ausgelagert, mit dem er keinen Vertrag darüber hat.

Was sich damit über die Zeit von selbst erledigt

Beides. Die fehlenden Requirements und die Nachkontrolle.

Nicht weil plötzlich alle sauber spezifizieren, sondern weil die KI so viel Kontext bekommt, dass praktisch keine Frage mehr offen bleibt. Der Sonderfall, den du nicht ins Ticket geschrieben hast, steht im Graphen, weil er beim letzten Mal geklärt wurde. Die Regel, die dein Architekt sonst im Review durchgesetzt hätte, greift schon beim Schreiben.

Genau wie beim Senior, der den Gap mit einem Augenrollen ausgeglichen hat. Nur ohne die Abhängigkeit von Einzelpersonen. Und diesmal reproduzierbar.

Die KI macht nicht mehr Fehler als dein Team. Sie macht nur die Fehler sichtbar, die dein Team seit Jahren stillschweigend für dich repariert hat.