Blind Burn: Was passiert, wenn KI schneller baut als Sie verfolgen können

Neulich habe ich versucht, alles aufzulisten, was auf meinen Servern läuft. Nicht weil etwas kaputt war. Einfach nur um es zu wissen.

Ich konnte es nicht.

Da sind Crontabs auf den VPS-Maschinen. Geplante Workflows in n8n. Supabase pg_cron Jobs, die alle sechs Stunden feuern. Convex scheduled functions, die ich im Februar eingerichtet und seitdem vergessen habe. GitHub Actions, die auf Events triggern, an die ich mich kaum noch erinnere. API-Calls, die stündlich an Services gehen, von denen ich nicht mal sicher bin, ob ich sie noch brauche. Alles mit Claude Code gebaut. Alles läuft einwandfrei.

Und ich, der Typ, der das Flugzeug gebaut hat, kann dir nicht sagen, was im Frachtraum liegt.

Vor zwei Wochen hat Addy Osmani (der Google-Engineer hinter Chrome DevTools, Lighthouse und Core Web Vitals) etwas Ähnlichem einen Namen gegeben. Er nannte es comprehension debt: die wachsende Kluft zwischen dem, was deine Codebase enthält, und dem, was tatsächlich ein Mensch versteht. Sein Artikel ging überall viral. Es ging um Code. Hier geht es um das, was läuft. Denn Code-Schulden sitzen in deinem Repo und warten. Die Infrastruktur-Version wartet nicht. Sie rechnet dir stündlich ab. Ich nenne es blind burn.

AI baut schnell. Deine Karte wird nicht aktualisiert.

Claude Code ist absurd gut darin, Dinge zu bauen. Du beschreibst einen Workflow, es baut den Workflow. Du fragst nach einem Cron Job, du bekommst einen Cron Job. Du sagst "automatisiere die Distributor-Feed-Synchronisation", und zwanzig Minuten später gibt es eine geplante Pipeline, die Produktdaten von drei Vertriebskanälen holt, transformiert und weiterleitet.

Es funktioniert. Du machst weiter. Das ist die Falle.

Jedes "bau mir einen Workflow" fügt eine geplante Aufgabe hinzu, die du in drei Wochen vergessen wirst. Jedes "füge einen Cron für das Inventory-Update hinzu" ist eine weitere Zeile in einer Crontab, die du nie wieder lesen wirst. Ich habe Claude Code zu meinem n8n-Architekten gemacht vor ein paar Monaten. Jeder Workflow, den es gebaut hat (gute, solide), fügte geplante Trigger zu einem Labyrinth hinzu, das ich nicht mehr kartographiert habe.

Und ich fühlte mich die ganze Zeit produktiv. Das ist der Teil, der dich erwischt. Du faulst nicht rum. Du lieferst. Du baust echte Dinge, die in der Produktion funktionieren. Du erschaffst nur zufällig auch einen Friedhof aus Timern, Triggern und Cron-Einträgen, die niemand jemals wieder überprüfen wird.

Gib es zu, du machst dasselbe.

Um das klarzustellen: Das Tool ist nicht das Problem. Claude Code macht genau das, was du verlangst, und macht es gut. Das Problem bin ich, der keine Karte führt. Und ich habe keine geführt, weil sich Kartographie wie Zeitverschwendung anfühlt, wenn du mit 100x-Geschwindigkeit baust.

Ist es nicht.

Was blind burn tatsächlich kostet

Osmanis Konzept ist scharf. Teams shippen AI-generierten Code schneller, als ihn jemand lesen kann. Tests bestehen, PRs sehen sauber aus, und die Kluft zwischen "deployed" und "verstanden" wächst in der Stille.

Aber Code-Schulden sind träge. Sie sitzen in deinem Repo, sind hässlich und inert, warten darauf, dass sie jemand anfasst. Die Infrastruktur-Version hat eine laufende Uhr.

Jeder verwaiste Cron Job ist eine Mikro-Rechnung. Jeder vergessene API-Timer ist Bandbreite auf deiner Karte. Jede geplante Funktion, die in einen Service feuert, den du letzten Monat deprecated hast, ist Compute, das dir berechnet wird, während du schläfst. Das ist blind burn. Es kündigt sich nicht an. Es akkumuliert, wie ein Abo, das du vergessen hast zu kündigen, außer dass es vierzig davon sind.

Die Signale tauchen auf. @cmd_alt_ecs auf X, vor ein paar Wochen: 60+ Cron Jobs, $50 pro Tag für Agents, die nichts Nützliches mehr machen. @Tahseen_Rahman: 15 autonome Crons liefen zwei Monate, der Bottleneck wurde um 3 Uhr morgens selbstheilend. @aleks_blanche, vielleicht der schärfste Take: "ohne Control Plane hast du keine Agents. Du hast Automatisierungs-Schulden."

Osmani spricht über Enterprise-Teams mit Dutzenden von Ingenieuren. Meine Größenordnung ist indie: eine Person, ein paar VPS-Boxen. Aber der Mechanismus ist identisch. Die Geschwindigkeit der Produktion überholt die Geschwindigkeit des Verstehens. Der Unterschied? In einem Unternehmen erwischt es irgendwann jemand. Wenn du solo bist, auditiert niemand dein Chaos für dich.

Monitoring beantwortet die falsche Frage

Also richtest du Cronitor ein. Oder Better Stack. Oder Healthchecks.io. Gut für dich. Du weißt jetzt, ob ein Job gelaufen ist.

Du weißt immer noch nicht, ob er existieren sollte.

Es ist, als hättest du eine Quittung für jeden Kauf, den du letztes Jahr gemacht hast, aber keine Ahnung, ob du noch etwas davon benutzt. Monitoring verfolgt die Ausführung. Was du brauchst, ist Sichtbarkeit in den Zweck. Ob der Job noch Sinn macht. Ob er etwas anderes dupliziert. Ob die API, die er aufruft, überhaupt noch nützliche Daten zurückgibt oder nur 200 OKs an einen Endpoint, den niemand mehr wartet.

Diese Frage ("sollte dieser Job existieren?") erfordert Kontext, den nur du hast. Oder hattest, vor sechs Monaten, bevor du vierzehn weitere Automatisierungen verschifft und aufgehört hast, darüber nachzudenken.

Keine SaaS wird dir das beantworten.

Was ich gebaut habe, um meinen eigenen Ecommerce-Stack wieder zu sehen

Also habe ich ein Control Panel gebaut. Keine SaaS. Kein Side Project für ProductHunt. Ein Überlebens-Tool, für eine WooCommerce-Pipeline, die außer Kontrolle geraten ist, weil Claude Code zu gut in seinem Job ist.

Das erste, was es mir gibt: eine wöchentliche Kalenderansicht aller geplanten Jobs über alle Systeme hinweg. Keine Liste im Terminal. Ein visuelles Raster, das zeigt, was wann feuert, farbkodiert nach Typ (Produktindexierung, Distributor-Feed-Sync, Preisüberwachung, Bestellabgleich, Inventory-Updates, Partner-API-Calls). Ein Blick und ich sehe die Probleme. Der 16-Uhr-Block, wo sechs Syndication-Jobs alle um dasselbe API-Kontingent kämpfen. Der Donnerstagmorgen-Cluster, der keinen Sinn mehr macht, weil ich die Upstream-Datenquelle vor zwei Monaten gekillt habe. Die Dienstag-Lücke, wo zwischen 8 und 14 nichts läuft, was entweder in Ordnung ist oder ein kaputtes Trigger, das ich nie bemerkt habe.

Zweites: ein API-Kosten-Tracker. Jeder externe Call, jeder Provider, jeder Dollar. Letzter Monat: $14,46 gesamt über 598 API-Calls bei drei Providern. Keine erschreckende Zahl. Aber der Wert ist nicht die Summe. Der Wert ist zu sehen, dass ein Provider 68% des Budgets für eine Aufgabe frisst, die ich lokal handhaben könnte. Und es zu erwischen, bevor es driftet, nicht danach.

Jetzt denk an den Typ mit $50 pro Tag. Andere Größenordnung, dieselbe Blindheit. Seine Jobs fingen nicht teuer an. Sie akkumulierten. Ohne Dashboard werden aus $2 $10 werden $50 und du siehst nie die Kurve, weil es keine Kurve gibt, die du anschauen könntest. Nur eine Kreditkartenabrechnung am Monatsende und ein vages Gefühl, dass etwas nicht stimmt.

Ich hatte dieses Gefühl wochenlang, bevor ich das Panel gebaut habe. Meine Frau hätte es Intuition genannt. Ich nenne es, meine Hetzner-Rechnung mit einem zugekniffenen Auge anzuschauen, wie das Gewicht nach Weihnachten zu checken. 😬

Niemand verkauft Verständnis DEINES Systems. Du musst es selbst bauen.

Das Control Tower Framework: Vier Regeln, um nicht mehr blind zu fliegen

Nachdem ich mein eigenes Chaos aufgeräumt hatte, destillierte ich den Ansatz in vier Prinzipien.

Regel 1: Inventarisiere alles an einem Ort. Crontabs auf VPS. n8n geplante Workflows. Supabase pg_cron. Convex scheduled functions. GitHub Actions. App-Level-Timer. Alles, eine Liste. Ein Job, der nicht in deinem Inventar ist, existiert nicht für dich. Er existiert für deine Rechnung, allerdings. Und deine Rechnung hat ein besseres Gedächtnis als du.

Regel 2: Visualisiere nach Zeit, nicht nach Tool. Eine Liste von Cron Jobs pro Maschine ist nutzlos, um Probleme zu erkennen. Du brauchst einen Wochenkalender, der zeigt, WANN Dinge feuern, nicht eine Tabelle von WO sie leben. Zeit ist die Achse, die Kollisionen, Lücken und Zombies enthüllt. Tools kollidieren nicht miteinander. Schedules schon.

Regel 3: Verfolge Kosten pro Job, auch grob. Wie viele API-Calls triggert dieser Job? Wie viel Compute frisst er? Wenn du nicht grob schätzen kannst, was ein Job kostet, kannst du nicht entscheiden, ob es sich lohnt, ihn laufen zu lassen. Die Zahl muss nicht präzise sein. Sie muss existieren. Null Sichtbarkeit ist, wie aus $2/Tag $50 werden.

Regel 4: Auditiere vierteljährlich. Drei Fragen pro Job. Läuft er noch? Dient er noch einem Zweck? Kann jemand (also du) erklären, warum er erstellt wurde? Ein "Nein" und der Job ist ein Zombie. Kill ihn. Tote Crons schicken keine Rechnungen.

Dieselbe Spec-First-Disziplin, die ich bei Code mit Prompt Contracts anwende (definiere den Vertrag, bevor du AI ausführen lässt), funktioniert für Infrastruktur. Spezifiziere, was laufen soll. Verfolge, was läuft. Diff die beiden.

Deine Infra verdient dieselbe Sorgfalt wie deine Codebase.

Wahrscheinlich mehr. Es ist der Teil, der dir Geld berechnet.

Der nächste Bottleneck ist nicht das Bauen, sondern das Verstehen dessen, was du bereits gebaut hast

Nächstes Jahr wird jeder Claude Code haben. Jeder wird wissen, wie man automatisiert. Und wir werden anfangen, von den ersten AI-Burnouts zu hören. Nicht menschliche. Infrastruktur-Burnouts. Die blind burns.

Der nächste Wettbewerbsvorteil wird nicht sein, schneller zu bauen. Es wird sein, zu verstehen, was du bereits gebaut hast.

AI gab dir die Konstruktions-Superkräfte. Die Verständnis-Superkräfte liegen bei dir.

Quellen

Addy Osmani, Comprehension Debt: The Hidden Cost of AI-Generated Code (Medium, März 2026)

(*) Das Cover ist AI-generiert. Die Server im Bild verstehen sich selbst besser als ich meine verstehe.