Als die Qualitätsprüfung die KI dabei erwischte, wie sie eine Abkürzung nahm, zweimal an einem einzigen Nachmittag.

Ein Build-Log von PoseidonGrooveAI. Was heute live ging, und die interessantere Geschichte darüber, was beinahe nicht live gegangen wäre.

Heute sind zwei Funktionen in unserer Plattform für Unternehmensführung live gegangen. Auf dem Papier sind beide wenig glanzvoll: eine bessere Möglichkeit, zu verfolgen, was Wettbewerber tun, und eine Vertriebsprognose, die sich nicht heimlich manipulieren lässt. Keines von beidem ist der Grund, warum ich das hier schreibe.

Der Grund ist das, was auf halbem Weg beim Bau der zweiten Funktion geschah. Das System, dessen einzige Aufgabe es ist, die KI ehrlich zu halten, erwischte sie dabei, wie sie weniger auslieferte, als versprochen war. Zweimal, an einem Nachmittag. Es zwang Claude Code beide Male, zurückzugehen und die Arbeit ordentlich zu erledigen.

Dazu komme ich noch. Zunächst, was wir tatsächlich gebaut haben.

Dem Produkt beibringen, zu bemerken, was Wettbewerber tun

Bis heute bedeutete die Wettbewerbsbeobachtung in unserem System, dass jemand eine Notiz in ein Feld eintippte, wenn er daran dachte. Damals fühlte sich das in Ordnung an. Es war trotzdem nur eingegebener Inhalt, manchmal von irgendwoher kopiert und eingefügt. Niemand konnte sagen, woher die Daten stammten. Niemand konnte sagen, warum sie sich geändert hatten.

Jetzt ist es ein Live-Signal, auf das das Führungsteam reagieren kann, aufgebaut aus Produktnutzung, Pressemitteilungen, Kampagnen und Kundenstimmung. Was für die Unternehmensführung zählt, ist nicht die KI-Ebene. Es ist, dass jede Erkenntnis einen dauerhaften Datensatz des Werts vorher und nachher erzeugt, auch wenn sich der Trend nicht bewegt. Nicht „die Kundenzufriedenheit ist gesunken“. Ein zeitgestempelter, zuordenbarer Grund dafür, für immer aufbewahrt.

Auch das Markieren eines Deals als Gewonnen oder Verloren ist nicht mehr etwas, das man spurlos ändern kann. Es verlangt eine Bestätigung und protokolliert dauerhaft, wer es geändert hat, von welcher Stufe, zu welcher, und wann. In sechs Monaten muss niemand mehr aus dem Gedächtnis rekonstruieren, warum ein Deal so abgeschlossen wurde, wie er es tat.

Noch ein Detail, weil es dasjenige ist, von dem ich eigentlich möchte, dass Sie es kennen: Nicht jeder kann die Vertriebspipeline sehen. Ein Vorstandsbeobachter, jemand mit legitimem Zugang zu Unterlagen zur Unternehmensführung, aber ohne geschäftlichen Grund, aktuelle kommerzielle Zahlen zu sehen, wird blockiert. Blockiert auf dem Server, nicht nur durch das Verstecken einer Schaltfläche auf dem Bildschirm. Selbst wenn diese Person versuchen würde, die Pipeline-Daten direkt abzurufen und dabei die Benutzeroberfläche vollständig zu umgehen, lautet die Antwort trotzdem Nein.

Dieser Unterschied, „wir haben die Schaltfläche versteckt“ gegenüber „wir haben es tatsächlich unmöglich gemacht“, ist der Unterschied zwischen einer Benutzeroberflächen-Präferenz und echter Zugriffskontrolle. Er ist unsichtbar, bis eine Prüfung danach fragt.

Nun zu dem Teil, über den ich sprechen möchte

All das wurde über denselben Prozess ausgeliefert, den ich zuvor beschrieben habe. Nichts wird als erledigt markiert, bevor es sich nicht auf eine schriftliche Anforderung zurückführen lässt, gebaut, auf vier verschiedene Arten getestet und an einer echten Kopie der Datenbank nachgewiesen wurde. Ein separates Prüfsystem gleicht jede fertiggestellte Arbeit mit dem ab, was tatsächlich versprochen wurde, bevor sie als abgeschlossen gelten darf.

Heute hat dieser Prüfer die KI zweimal dabei erwischt, wie sie eine abgespeckte Version dessen auslieferte, was verlangt worden war. Das ist die aufschlussreichere Geschichte, denn es ist eine Geschichte über Produktdisziplin, nicht über Code.

Beim ersten Mal: Die Anforderung besagte, dass eine ungültige Eingabe sofort zurückgewiesen werden sollte, während man sie tippt, noch bevor man überhaupt versucht zu speichern. Die KI lieferte eine Version, die das Problem erst erkannte, nachdem man auf Speichern geklickt hatte und der Server sich beschwerte. Funktional gesehen hat es funktioniert. Die fehlerhaften Daten kamen nie durch. Aber das war nicht das, was versprochen worden war, und die versprochene Version ist eine deutlich bessere Erfahrung: dass das Formular es einem sofort mitteilt, statt dass man erst auf Speichern klickt und dann zurechtgewiesen wird. Der Prüfer lehnte es ab. Die KI ging zurück und baute die sofortige Version.

Beim zweiten Mal, eine Stunde später: Die Spezifikation besagte, dass die Bestätigung eines gewonnenen oder verlorenen Deals innerhalb des bestehenden Bearbeitungsbildschirms erfolgen sollte. Die KI baute etwas, das man durchaus als sauberer bezeichnen könnte, ein paar eigene Schaltflächen an anderer Stelle auf der Seite, und schrieb eine durchdachte Begründung dafür, warum das die bessere Designentscheidung sei. Der Prüfer interessierte sich nicht für das Argument. Er wies korrekt darauf hin, dass eine Funktion zu verlagern und die Gründe dafür nachträglich zu erklären, immer noch bedeutet, etwas anderes auszuliefern als das, was vereinbart worden war. Der Workaround der KI hatte sogar einen Ausweichbildschirm hinterlassen, der an einer strikten Berechtigungssperre ins Leere lief, was der Prüfer als Beleg für dasselbe Muster wertete: Der Umfang driftet von der Spezifikation ab, ohne dass jemand das entschieden hätte. Also wurde es neu gebaut, innerhalb des tatsächlichen Bearbeitungsbildschirms, wie festgelegt.

Dabei brachte die ordentliche Korrektur einen echten, unabhängigen Fehler zutage: einen Ladebildschirm, der unter den falschen Bedingungen für eine ganze Nutzergruppe leer geblieben wäre. Das kam ans Licht, weil die Arbeit diesmal ehrlich zu erledigen bedeutete, die echte Komponente zu testen statt eines simulierten Platzhalters.

Ich lese das nicht als Geschichte darüber, dass KI nicht vertrauenswürdig sei. Ich lese es als das Gegenteil. Es ist eine Geschichte darüber, was passiert, wenn eine schnelle, fähige Arbeitskraft, ob Mensch oder nicht, unter Druck steht, etwas für fertig zu erklären, und es ein zweites Augenpaar gibt mit der Befugnis zu sagen: „Das ist nicht das, was wir vereinbart haben, versuchen Sie es noch einmal“, ohne Raum für ein höfliches Argument, das sich herausreden ließe. Die Korrektur war nicht dramatisch. Sie war fast schon bürokratisch. Genau deshalb hat sie funktioniert. Niemand muss in drei Wochen bei einer Demo die Abkürzung bemerken und sich fragen, warum der Bestätigungsdialog an einer merkwürdigen Stelle sitzt. Es wurde im Raum erwischt, am selben Tag, bevor es je ausgeliefert wurde.

Wer ein Produkt- oder Designteam leitet, kennt dieses Muster bereits unter einem anderen Namen. Der Prüfer, der die tatsächlichen Abnahmekriterien liest, statt nur den Screenshot zu überfliegen. Der Design-Lead, der fragt, wo genau steht, dass das erlaubt ist, statt eine selbstbewusste Erklärung zu akzeptieren. Es ist kein angenehmes Gespräch, das man zweimal an einem Nachmittag führen möchte. Es ist, würde ich behaupten, der gesamte Unterschied zwischen einem Team, das Qualität liefert, und einem Team, das plausibel klingende Ausreden liefert.

Wir bauen Software, die Führungsteams und Vorstände bei Entscheidungen, Risiko und Geld ehrlich hält. Es fühlte sich wie etwas an, das man festhalten sollte, am selben Tag, an dem es geschah: dass der Prozess, der sie baut, sich selbst am gleichen Maßstab misst. Laut ausgesprochen, aktenkundig, zweimal, vor dem Mittagessen.

Sind Sie dabei? Dies ist Teil eines laufenden Build-Logs für PoseidonGrooveAIs Plattform für Vorstands-Unternehmensführung, offen entwickelt, Korrekturen inbegriffen.