Ich habe versprochen, dass der zweite Teil vom Unterschied zwischen Website, App und Software handeln wird. Dieser Teil kommt noch.
Ich habe versprochen, dass der zweite Teil vom Unterschied zwischen Website, App und Software handeln wird. Dieser Teil kommt noch. Doch am Wochenende des 1. und 2. August wurde in der App Ptáček ein Fehler gefunden, und der versprochene Unterschied spielte sich statt in einer Tabelle live ab.
Ihn an einem echten Fehler zu zeigen, ist ehrlicher, als ihn an ausgedachten Beispielen zu erklären. Also ändert sich die Reihenfolge.
Es gibt noch einen zweiten Grund. Ich möchte, dass man sieht, wie Entwicklung mit KI wirklich aussieht. Nicht nur die fertige Demo am Ende, sondern auch die Momente, in denen es kaputtgeht, in denen man die Ursache sucht und zweimal einen Schritt zurückgeht, bevor es funktioniert. Vibe Coding wird als Zauberei verkauft. In Wirklichkeit ist es ein Handwerk mit Fehlern, die man behebt.
Was kaputtging und warum Stille schlimmer ist als ein Absturz
Ptáček fragte den Systemkalender alle fünf Minuten, ob etwas ansteht. Das Problem lag darin, wie er fragte. Für jede Anfrage öffnete er eine neue Verbindung und schloss die alte nicht. Nach etwa vier Stunden Laufzeit gab macOS ihm keine weitere Verbindung mehr.
Schlimmer war die zweite Hälfte des Fehlers. Statt einer Fehlermeldung bekam die App eine leere Antwort und wertete sie als gültig. Keine Kalender, keine Termine. Sie löschte auch Überflüge, die sie schon geplant hatte. In den Einstellungen leuchtete dabei grün, dass der Zugriff auf den Kalender funktioniert.
Bei einer App, die ein paar Minuten vor dem Termin über den Bildschirm fliegen soll, ist das besonders unangenehm. Der Mensch verlässt sich auf sie und hört auf, seinen Kalender selbst im Blick zu behalten. Wenn sie dann schweigt, statt zu sagen „ich weiß es nicht“, ist sie schlimmer, als wenn es sie gar nicht gäbe.
Bei einer Erinnerungs-App ist nicht der Absturz der schlimmste Fehler. Am schlimmsten ist die Stille.
Wer es gefunden hat: zwei Audits und eine Korrektur
Für die Ursache habe ich zwei unabhängige Audits eingesetzt. Zwei verschiedene Modelle, jedes mit eigener Aufgabe, beide mit Lesezugriff auf den Code und auf die laufende App. Voneinander wussten sie nichts.
Das erste fand die Ursache direkt im Code: drei Stellen, an denen eine neue Verbindung geöffnet wird, statt die alte wiederzuverwenden. Zugleich schloss es Lösungen aus wie „wir erhöhen das Verbindungslimit“, weil das dasselbe Problem nur hinausschieben würde.
Das zweite bestätigte es mit einem eigenen Befund aus dem Protokoll und korrigierte das erste in einem Punkt.
Die Lehre, die ich daraus ziehe: Ein Audit liefert Ihnen einen unbestätigten Schluss. Zwei unabhängige Audits liefern Einigkeit über die Ursache und dazu eine Korrektur, auf die das erste allein nicht gekommen wäre.
Kein Nutzer war dabei je von dem Fehler betroffen. Unser Testprozess hat ihn am Samstagabend abgefangen, nicht jemand Fremdes am Montagmorgen.
Was behoben wurde: Architektur, kein Flickwerk
Die Korrektur hieß nicht „wir erhöhen das Limit“ und nicht „wir fügen eine Wiederholung der Anfrage hinzu“. Geändert hat sich, wie die App mit dem Kalender spricht.
Eine Verbindung für den ganzen Lauf der App statt einer neuen bei jeder Anfrage. Ein Fehler sieht nie mehr wie Leere aus. Wenn die App etwas nicht weiß, sagt sie „ich weiß es nicht“ und lässt den zuletzt bestätigten Plan gelten, statt Leere als „keine Termine“ zu deuten. Reaktion auf eine Terminänderung innerhalb einer Sekunde statt bis zu fünf Minuten.
Es gibt einen Unterschied zwischen „es leuchtet nicht mehr rot“ und „es passiert nicht mehr“. Das Zweite bedeutet zu verstehen, warum es passierte, und diesen Teil umzuschreiben, nicht ihn zu verdecken.
Karte des Wochenendes: Entwicklung ist keine Gerade
Im Rückblick sieht es aus wie eine saubere Geschichte. Fehler, zwei Audits, Korrektur, fertig. In Wirklichkeit lief es nicht so gerade. Über das Wochenende sind es neunzehn Meilensteine, drei Fehler auf dem Weg und drei Rückschritte, bei denen ein angelaufener Versuch verworfen wurde und man vom letzten funktionierenden Stand neu begann.
Das zeigen Demovideos nie.
Unabhängige Kontrolle und Zahlen: von 7,5 auf 9,2
Nach der Korrektur kam die zweite Kontrollwelle, unabhängig auch von beiden vorherigen Audits.
Zehn Millionen simulierte Kalenderschritte, ohne dass eine einzige Regel verletzt wurde. Eine Million Operationen mit einer einzigen lebenden Verbindung. Genau das, was am Freitag gefehlt hatte. Neunundfünfzig Tests direkt im Code und dazu siebenundsechzig Tests des eigenen QA-Labors. Vierzig von Hand entworfene Szenarien in acht Kategorien.
Dieses Labor erkennt auch eine untergeschobene fehlerhafte Version. Es bekommt absichtlich ein kaputtes Modell und muss selbst NO GO rufen. Wenn es nicht ruft, ist es zu nichts nütze. Tests, die nie etwas finden, sind Dekoration, keine Kontrolle.
Achtzig zu zwanzig und drei Tage
Die App hat zu achtzig Prozent die KI gebaut, die restlichen zwanzig hat ein Mensch gesteuert und kontrolliert. Die Aufgabe, die Entscheidung über das Risiko und das letzte Wort hatte immer der Mensch. Ohne diese Kontrolle wäre das Wochenende anders ausgegangen, denn ein Audit, das selbst nie NO GO sagt, ist zu nichts nütze.
Der Punkt ist nicht, dass Fehler verschwinden. Es verkürzt sich die Zeit zwischen dem Entstehen eines Fehlers und dem Moment, in dem er behoben und belegt ist.
Warum das auch Apple passiert
Die Bibliothek von Apple, die Ptáček zum Lesen des Kalenders nutzt, wurde anders verwendet, als Apple es vorgesehen hatte. Die Dokumentation sagt das in einem einzigen Satz, versteckt zwischen tausend Seiten.
Das passiert auch Apple und Google, Konzernen mit jahrzehntelang eingespielten Prozessen. Der Unterschied liegt nicht darin, ob ein Fehler auftritt, sondern wie schnell Sie ihn finden und beheben.
Drei Fragen an jeden Anbieter
Wie viele Tests liefen, und was ist in ihnen gescheitert? Wenn Ihnen jemand sagt, dass nie etwas gescheitert ist, wurde nicht getestet.
Was läuft weiter? Wer keine Karte der weiteren Tests hat, hat sie nicht gemacht.
Wie groß ist das Vorhaben? Website, App und Anbindung an ein zwanzig Jahre altes Unternehmenssystem sind drei verschiedene Ligen. Das Risiko wächst genauso wie der Preis.
Die Form des Prompts ist immer perfekt. Die Substanz nicht.
KI ist ein Turbo, kein Autopilot. Und ein Turbo ohne Fahrer landet genauso schnell im Graben.
Der Artikel ist ursprünglich auf LinkedIn erschienen. Originalartikel auf LinkedIn
