Der Report, der fünf Tage lang log und nie einen Fehler meldete

Jeden Morgen schickt mir ein Assistent, den ich selbst gebaut habe, ein kurzes Briefing: was heute ansteht, worauf ich achten muss, was eine Antwort braucht. Fünf Morgen hintereinander begann es mit irgendeiner Variante von “nichts geplant, freier Tag zu Hause”. Ich war die ganze Zeit unterwegs, mit vollem Terminkalender. Das Briefing war fröhlich, selbstsicher und komplett falsch, und nirgendwo im System ging ein einziger Alarm los.

Kurz gefasst

• Ein automatisierter Tagesbericht lief fünf Tage lang “erfolgreich” durch und produzierte dabei klammheimlich Unsinn: Eine Datenquelle lieferte “Erfolg, keine Ergebnisse” statt eines Fehlers, also sah nichts kaputt aus.
• “Lief ohne Fehler” ist nicht dasselbe wie “hat funktioniert”. Prüfe auf die leere Antwort, nicht nur auf den Absturz.
• Gib einer KI den Kontext drumherum und lass sie interpretieren, statt eine starre Regel fest zu verdrahten.

Der Bericht, der gut aussah

Das Briefing ist ein langweiliges, nützliches kleines Ding. Es liest ein paar Quellen, eine davon mein Kalender, und landet jeden Morgen, ohne dass ich etwas tun muss. Es lag monatelang richtig. Das ist die erste stille Falle der Automatisierung: Etwas, das lange genug zuverlässig war, wird unsichtbar, und man hört auf, ausgerechnet das eine Ergebnis zu prüfen, dem man zu vertrauen beschlossen hat.

Als es mir also erzählte, meine Tage seien leer, zuckte ich mit den Schultern und nahm an, ich hätte vergessen, etwas in den Kalender einzutragen. Die ehrliche Version ist weniger schmeichelhaft: Ich vertraute meinem eigenen Code, weil er sich nicht beschwerte. Keine roten Logs, kein Absturz, kein Alarm. Der Job beendete sich jeden Morgen sauber, und so weit jedes Dashboard reichte, war alles in Ordnung.

Was tatsächlich kaputtging

Ein paar Tage zuvor hatte eine völlig unzusammenhängende Änderung am darunterliegenden System genau das Teil lahmgelegt, das meinen Kalender ausliest. Es schlug nicht fehl. Es lieferte “Erfolg, null Ereignisse” zurück. Eine leere Antwort mit einem Daumen-hoch obendrauf. Für den Rest des Programms ist das von einem wirklich leeren Kalender nicht zu unterscheiden: heute keine Termine, super, freier Tag, schreib das so hin.

Ein Werkzeug, das “Erfolg, keine Daten” zurückgibt, ist gefährlicher als eines, das abstürzt. Der Absturz fällt auf. Dem leeren Erfolg wird geglaubt.

Das ist das Problem der stillen Fehler, und es lauert überall dort, wo automatisiert wird. Laute Fehler werden gesehen und behoben. Teuer werden die leisen, bei denen eine Komponente etwas technisch Korrektes und vollkommen Falsches zurückreicht und jede Schicht darüber nickt und es als Tatsache weiterreicht.

Warum es niemandem auffiel

Zwei Gründe, und beide beißen auch echte Teams.

Erstens habe ich nie auf den leeren Fall geprüft. Mein Code fragte “ist das Auslesen des Kalenders fehlgeschlagen?”, und die Antwort war immer nein, weil ein leerer Erfolg kein Fehlschlag ist. Die Frage, die ich hätte stellen müssen, lautet: “Ergibt dieses Ergebnis überhaupt Sinn?” Null Termine an fünf Werktagen in Folge sind kein normaler Wert; sie sind ein Zeichen dafür, dass der Sensor kaputt ist. Ich hatte Logik geschrieben, um den Absturz abzufangen, und nichts, um den Unsinn abzufangen.

Zweitens war der Bericht zu starr, um misstrauisch zu sein. Er entschied “freier Tag” anhand eines einzigen Feldes: Gibt es heute, am exakten Datum, einen Termin, ja oder nein. Diese eine schmale Regel hatte keine Möglichkeit zu bemerken, dass die Woche drumherum voller Reisen war. Sie las nicht die Situation. Sie las ein Kästchen, und das Kästchen war zufällig leer.

Die Lösung, in zwei Teilen

Teil eins: das Schweigen laut machen. Ein leeres Ergebnis aus diesem Kalender-Lesevorgang gilt jetzt standardmäßig als verdächtig. Wenn die Daten unplausibel aussehen, eine volle Arbeitswoche ohne einen einzigen Eintrag, sagt der Bericht das laut, anstatt es zu einem ordentlichen Satz glattzubügeln. Das Ziel war nie, etwas zu bauen, das nicht fehlschlagen kann, sondern so fehlzuschlagen, dass ich es auch sehe.

Teil zwei: aufhören, Urteilsvermögen als Regel zu kodieren. Statt dem Bericht ein einzelnes Ja-Nein-Feld zu füttern, übergebe ich dem Assistenten jetzt ein Fenster der umliegenden Tage und lasse ihn die Woche so lesen, wie ein Mensch es täte. “Gestern weg, heute nichts, morgen weg” liest sich als “immer noch auf Reisen”, nicht als “freier Tag zu Hause”. Je angestrengter du jeden Sonderfall in starre Logik gießt, desto brüchiger wird das Ganze. Gib dem Modell den echten Kontext und eine klare Frage, und du bekommst ein Urteil statt eines Nachschlagens.

Was ich anders machen würde

Ich hätte die Prüfung auf den verdächtigen Leerwert schon am ersten Tag geschrieben. Sie kostet etwa zehn Minuten, und sie ist die nützlichste Gewohnheit, die ich in jeder Automatisierung kenne. Lege von vornherein fest, wie ein unmögliches-aber-gültiges Ergebnis aussieht, und bring das System dazu, in dem Moment laut zu werden, in dem es eines sieht. Nicht “gab es einen Fehler”, sondern “ist diese Antwort überhaupt plausibel”. Falsche Antworten mit Erfolgsabzeichen sitzen einfach da und sehen so lange gesund aus, wie du sie lässt.

Die Manager-Version dieser Lektion hat nichts mit Kalendern zu tun. Jeder automatisierte Bericht, jedes Dashboard, jede KI-Zusammenfassung, auf die sich dein Team stützt, kann genau das tun, was meiner getan hat: weiterlaufen, weiter gesund aussehen und dir still Zahlen liefern, die nach irgendeiner vorgelagerten Änderung, die niemand damit in Verbindung brachte, ins Sinnlose abgedriftet sind. “Die Pipeline lief” ist nicht “die Pipeline lag richtig”. Die Frage an denjenigen, dem eine wiederkehrende automatisierte Ausgabe gehört, lautet nicht “läuft sie?”. Sie lautet “woran würden wir merken, dass sie angefangen hat, uns anzulügen?”.

Also hier die eine zum Durchkauen: Welcher eine automatisierte Bericht, den dein Team jede Woche liest, wird von niemandem mehr gegengeprüft? Genau der ist am ehesten gerade jetzt still im Unrecht.