AI-Autopilot-Freeze: Die Gefahr der Abhängigkeit von Zeitstempeln
Unsere KI-Agenten arbeiten rund um die Uhr (24/7).
Sie wandeln Anforderungen in Aufgaben um. Sie schreiben Code. Sie erstellen Pull Requests. Ein KI-Reviewer genehmigt die Arbeit. Dann mergt das System den Code automatisch.
Eines Morgens stellten wir fest, dass seit drei Tagen keine einzige Aufgabe mehr abgeschlossen worden war.
Das System sah gesund aus. Jede Komponente meldete einen grünen Status. Pläne wurden erstellt. Agenten arbeiteten. Der Reviewer genehmigte. Das Einzige, was fehlte, war der Merge.
Die Ursache war ein von uns selbst entwickelter Freshness-Check.
Wir wollten einen bestimmten Fehler verhindern. Wir wollten keinen Code mergen, wenn ein Reviewer ihn zwar genehmigt, später aber doch Änderungen anfordert. Um dies zu lösen, sagten wir dem System: „Vertraue nur Reviews, die stattgefunden haben, nachdem wir mit dem Warten begonnen haben.“
Diese Logik versagte bei Systemwiederherstellungen.
Wenn das System neu startete oder eine Aufgabe auf einen neuen Server verschob, wurde der Zeitstempel „Warten gestartet“ auf die aktuelle Zeit zurückgesetzt.
Wenn ein Reviewer den Code um 10:00 Uhr genehmigte, das System aber um 10:30 Uhr neu startete, ignorierte das System die Genehmigung von 10:00 Uhr. Es dachte, die Genehmigung sei zu alt.
Die Genehmigung war auf GitHub immer noch vorhanden. Aber unser Code konnte sie nicht sehen. Das System geriet in einen permanenten Deadlock.
Ich habe daraus drei harte Lektionen gelernt:
Behandle den externen Zustand als Snapshot, nicht als Ereignis. Frage nicht: „Ist etwas Neues passiert?“, sondern: „Wie ist der aktuelle Zustand genau jetzt?“ Wenn du den aktuellen Zustand betrachtest, spielen Neustarts keine Rolle.
Setze Zeitstempel während der Wiederherstellung nicht zurück. Wenn du eine „Gestartet am“-Zeit während eines Retries zurücksetzt, löschst du alle Fakten, die vor diesem Moment passiert sind. Setze Zeitstempel nur zurück, wenn sich die eigentliche Arbeit ändert.
Überwache, wo Aufgaben „parken“, nicht nur, ob sie abgeschlossen werden. Ein „Erledigt“-Zähler sagt dir nur, dass du ein Problem hast. Eine Verteilung der Aufgaben nach Schritten sagt dir, wo das Problem liegt. Wir fanden den Fehler, weil wir sahen, dass 28 Aufgaben im Schritt „Warten auf Review“ feststeckten.
Ein laufender Prozess, der einer falschen Regel folgt, wird in einem Health Check niemals auffallen. Er sieht gesund aus, weil er genau so arbeitet, wie er programmiert wurde.
Wenn du automatisierte Systeme baust, achte nicht nur auf Fehler. Achte darauf, wo sich deine Prozesse stauen.
Optional learning community: https://t.me/GyaanSetuAi