Drei KIs, eine Edge Function: wie ich Drift bei paralleler KI-Arbeit strukturell verhindere
Ich lasse mehrere KIs parallel an meinem Code arbeiten. Das spart Zeit, solange sich die Arbeitsbereiche nicht überschneiden. Bei Edge Functions haben sie sich überschnitten — und das hat mich mehr Stunden gekostet, als mir lieb ist.
Der Auslöser war unspektakulär. Drei KIs arbeiteten gleichzeitig am selben Themengebiet, und alle drei fassten dabei Edge Functions an. Sie committeten parallel, teilweise ohne das klar zu melden. Was dabei entstand, war Drift.
Drift, kurz erklärt
Drift heißt: Mehrere Stände, die eigentlich übereinstimmen sollten, laufen unbemerkt auseinander. Hier waren es drei — der Stand im Repo, der Stand in der Datenbank und das, was die einzelne KI für den aktuellen Stand hielt. Jeder Commit ohne Abgleich vergrößert die Lücke.
Bei normalem Anwendungscode merkt man so etwas schnell. Bei Edge Functions, die eng an Migrationen hängen, merkt man es erst, wenn etwas nicht mehr deployt oder sich seltsam verhält.
Edge Functions sind migrationskritisch — das war mir nicht präsent
Das ist der eigentliche Lerneffekt. Ich hatte Edge Functions im Kopf als Code, der irgendwo läuft — entkoppelt, harmlos, parallelisierbar. Tatsächlich hängen sie bei mir am Migrationsstand der Datenbank, und wenn mehrere Akteure gleichzeitig daran arbeiten und deployen, ohne den aktuellen Stand zu kennen, überschreibt einer die Annahmen des anderen.
Das Tückische war nicht der Fehler selbst, sondern die Suche danach. Wir hatten zu dem Zeitpunkt schon einiges umgebaut. Es hätte alles sein können. Genau das frisst Zeit: nicht das Beheben, sondern das Eingrenzen, wenn die Ursache hinter zwanzig anderen Änderungen liegt. Dass ich es trotzdem zügig finden und einkreisen konnte, lag daran, dass ich beim Durchgehen die Parallelität als Muster erkannt habe — drei Akteure, eine Ressource, kein Abgleich.
Die Lösung: ein deterministischer Workflow mit echtem Gate
Ich habe daraufhin einen Workflow gebaut, der dieses Muster strukturell unmöglich macht. Vier Bausteine.
Erst den Stand holen, dann arbeiten. Bevor eine KI eine Edge Function anfasst, zieht sie den aktuellen Stand aus der Datenbank und arbeitet gegen diesen Stand — nicht gegen ihre Annahme von vor zehn Minuten. Das allein nimmt dem Drift die Grundlage.
Ein Gate vor dem Deploy. Kein Edge-Function-Deployment passiert mehr stillschweigend. Vor dem Deploy steht eine explizite Rückfrage: Soll das jetzt wirklich deployt werden? Ich werde informiert und bekomme an dieser Stelle echte Entscheidungspunkte, statt nach dem Commit vor vollendeten Tatsachen zu stehen.
Atomares Claiming über eine fortlaufende Nummer. Das ist der Kern. Wer an einer Edge Function arbeiten will, muss sich in der Tabelle eine Nummer ziehen. Pro Nummer kann nur genau eine Row geclaimt werden. Ist die Nummer vergeben, zieht man die nächste. Damit ist physisch ausgeschlossen, dass zwei Akteure denselben Slot belegen — und nebenbei sieht jeder sofort, ob gerade etwas parallel läuft oder ob die Bahn frei ist.
Jeder Schritt ist prüfbar. Der Ablauf ist deterministisch zerlegt. Ich kann an jedem einzelnen Schritt nachsehen, was passiert ist und warum — statt am Ende ein Ergebnis zu haben, dessen Zustandekommen ich nicht mehr rekonstruieren kann.
Was ich mitnehme
Der teure Teil war nicht der Bug. Der teure Teil war, dass drei kompetente Akteure ohne Koordination an derselben kritischen Ressource arbeiteten — und dass ich die Ressource für unkritischer gehalten hatte, als sie ist. Parallelität bei KI-Agenten ist ein Gewinn, solange klar geregelt ist, wer wann was anfassen darf. Sobald eine Ressource migrationskritisch ist, braucht sie genau das: einen aktuellen Stand vor der Arbeit, ein Gate vor der Wirkung, und einen Mechanismus, der gleichzeitigen Zugriff ausschließt statt darauf zu hoffen.
Fazit
Ich habe das atomare Claiming nicht gebaut, weil es elegant ist, sondern weil ein verlorener Nachmittag mir gezeigt hat, wo bei paralleler KI-Arbeit die scharfe Kante liegt. Die Regel dahinter ist simpel genug, um sie überall anzuwenden: Hol dir den Stand, zieh dir den Slot, frag vor dem Deploy. Drei Schritte, die einen Drift verhindern, dessen Suche teurer ist als jede Vorsichtsmaßnahme.
Mehrere KIs nebeneinander laufen zu lassen, ohne genau diese Koordination, ist exakt der Fehlerfall, den die KI-Orchestrierung in der boostN-App ausschließen soll — und der Evergreen-Leitfaden zum parallelen Arbeiten mit KI zeigt das größere Muster dahinter.
Entdecke mehr
Datenbank-Unfälle mit KI: Regel-Konflikte, Worktree-Kollisionen und was wirklich schützt
Warum Migrationen trotz Sandbox durchrutschen, wie man sich in Worktrees selbst die DB abschießt — und welche Schicht das Problem strukturell löst.
BlogKI-Workflows per Keyword: Wie wir wiederkehrende Abläufe erzwingbar machen
Ein getipptes Keyword löst bei uns einen festen KI-Ablauf aus — und jeder Schritt muss committet werden, bevor der nächste kommt. Warum das der Trick ist.
BlogMulti-AI-Orchestrierung ohne API-Kosten: warum dein bestehendes Abo reicht
Headless-Agenten auf dem eigenen Rechner, gespeist aus deinem vorhandenen Abo statt aus einer API-Rechnung — wie boostN viele Modelle orchestriert.