Ich habe aufgehört, KI-Workflows zu bauen. Ich baue jetzt einen Burggraben. Claude Code erledigte die Arbeit.

9 min read

23:42 Uhr, auf dem Heimweg vom Abendessen, kurzer Blick ins Postfach. Scheiße. Infisical down. Während ich noch fluche, sieben Minuten später die zweite Mail: „[INFRA] Infisical is back up."

Da hat es klick gemacht. Ich hatte einen Stack gebaut, der lebt.

TLDR. Alle haben Panik, dass KI ihren Job vernichtet. Währenddessen verwandelt eine Handvoll Builder, die in Systemen denken, dieselbe Technologie in einen entscheidenden Vorteil. Kein Workflow. Kein Assistent. Ein Stack, der lebt, der sich selbst repariert, der sich selbst bereichert, während sie schlafen. Sechs Monate Aufholbedarf für jeden, der das kopieren will.

Sechs Monate täglich mit Claude Code programmiert, und am Ende hatte ich etwas, das kein Workflow mehr ist. Kein verbessertes n8n-Setup. Kein Assistent, der Code für mich schreibt. Keine weitere Agent-Demo. Ich hatte etwas Komplexeres gebaut. Es repariert sich selbst. Es bereichert sich selbst. Es lernt meine Muster. Und das Ding? Das kann niemand an einem Wochenende kopieren.

Ich habe gut geschlafen.

Zwei Entwickler an Schreibtischen: einer in Panik zwischen Fehlermeldungen, einer entspannt beim Betrachten automatisch gelöster Warnungen. Kontrast zwischen manuellen und automatisierten Systemen.
Ein Dev schwitzt. Ein Dev schläft. Automatisierung gewinnt.

Das erste Mal, als ich es sich selbst heilen sah

Outlook email inbox showing infrastructure alerts triggering Claude Code self-healing automation workflow
Infrastruktur-Alerts lösen automatisch Claude Code aus, um Service-Probleme zu diagnostizieren und zu beheben.

Der Monitor hat das Timeout erkannt. Ein Trigger, den ich vor Monaten verdrahtet hatte, feuerte ab, öffnete eine Claude Code-Session mit den Logs des fehlerhaften Services als Kontext, und der Agent übernahm. Logs gelesen. Einen hängenden-aber-nicht-abgestürzten Container entdeckt. Neugestartet. Grün bestätigt. Lösungs-E-Mail verschickt.

Vor sechs Monaten hätte derselbe Vorfall meinen Abend ruiniert. Kaffee. Panik. Eine Stunde herausfinden, warum der Secret Manager unglücklich ist, zwanzig Minuten mehr herausfinden, welcher Container der eigentliche Übeltäter ist, zehn Minuten Reue beim Eintippen des docker restart-Befehls in die falsche Terminal-Session.

Danach passierte es immer wieder. Gleiches Muster. Trigger feuert, Agent untersucht, Fix wird angewendet, ich lese später davon. Wenn man das ein paar Mal laufen sieht, nennt man das, was man hat, nicht mehr ein „Setup".

Was ich tatsächlich in 6 Monaten gebaut habe

Ich habe mich nicht an Tag eins hingesetzt und das architektiert. Ich habe einfach Tag für Tag weiter Zeug für mein E-Commerce-Setup gebaut, mit Claude Code als einziger IDE, die ich öffne.

Die aktuelle Oberfläche:

Eine Produktkatalog-Ingestion-Pipeline, die jeden Morgen aus dem CSV-Feed eines Distributors zieht, das Chaos normalisiert (verschiedene Anbieter, verschiedene Feldnamen, Preise in drei Währungen, Gewichte in zwei Einheiten, und ein Lieferant, der irgendwie immer noch Windows-1252-Encoding in 2026 verwendet), und die bereinigten Zeilen in WooCommerce schiebt.

Konkurrenz-Preis-Scraper, ein halbes Dutzend davon, jeder verfolgt eine spezifische Teilmenge von SKUs über rivalisierende Storefronts. Sie handhaben die WAFs, sortieren veraltete Daten aus und füttern ein Dashboard, das ich tatsächlich anschaue.

Social Content-Generierung für Threads und Instagram, verknüpft mit Produktlaunches. Das System zieht jede neue SKU, entwirft Copy-Varianten, generiert das Promo-Video und reiht alles in eine Partner-API für die Terminplanung ein.

Trend-Dashboards. Inventory-Monitoring. Order-Pipeline-Integration. Partner-API-Webhooks. Transkription bei Lieferantengesprächen (ja, ich nehme sie auf, mit Einverständnis, beruhigt euch). Und die Infra-Schicht darunter: Docker, Reverse Proxies, Secret Rotation, Backup Jobs, Alerting.

Alles auf ein paar VPS. Alles inkrementell gebaut. Alles täglich mit Claude Code im Gespräch.

Gestern ist es jeden zweiten Tag kaputt gegangen. Heute funktioniert es neun von zehn Tagen.

Ich führe nichts davon mehr manuell aus. Ich öffne nicht mal die meisten Dashboards. Ich sehe nur die Digests reinkommen, schaue kurz drüber und ignoriere sie entweder oder schiebe einen Screenshot an Claude Code, wenn etwas komisch aussieht.

Ein Workflow macht das nicht. Ein Workflow sitzt da, bis man ihn auslöst.

Warum das ein Burggraben ist, kein Workflow

Claude Code debugging session displaying error screenshot with agent debug output and proposed fix solution
Claude Code Agent analysiert Error-Screenshot und generiert Debug-Output mit Fix-Vorschlag.

Es gibt einen scharfen Artikel auf Medium vom Februar mit dem Titel „AI Killed the Feature Moat". Das Argument: 2026 kann jeder mit Cursor und einem Wochenende deine Features klonen. Die Burggräben, die überleben, sind nicht funktional. Es sind Dinge wie SEO, Brand, Geschmack, Geschwindigkeit, Daten, Vertrauen. Sechs Kategorien. Und der Artikel nennt drei Eigenschaften, die sie alle teilen: Zeitabhängigkeit, Erfahrungsabhängigkeit, Widerstand gegen Replikation.

Das ist der Business-Level-Frame. Ich will diese drei Eigenschaften stehlen und auf den Operator herunterzoomen.

Was ich gebaut habe, ist kein Business-Burggraben. Es schützt mich nicht vor Konkurrenten, die meine Kunden wollen. Es ist ein persönlicher Burggraben. Es schützt meine Fähigkeit, mehr zu shippen, schneller, mit weniger Stress als die Version von mir vor sechs Monaten. Die Asymmetrie ist intern, nicht extern. Für einen Solo ist das die einzige Asymmetrie, die täglich zählt.

Drei Eigenschaften machen einen persönlichen Stack zu einem Burggraben statt zu einem Workflow. Ich nenne das ganze Ding den Stack That Lives. STL. Ja, ich weiß, ich bin schlecht im Benennen.

Co-Evolution

Das ist der Teil, den ich nicht erwartet hatte.

Nach drei Monaten bemerkte ich, dass Claude Code Fixes vorschlug, die zu meinem Stil passten, ohne dass ich danach gefragt hatte. Eine Namenskonvention, die ich in irgendeinem Wegwerf-Commit Wochen zuvor gesetzt hatte, tauchte immer wieder in neuem Code auf. Eine spezifische Art, wie ich Fehler behandle (früh returnen, strukturiert loggen, niemals stumm werfen), wurde spontan reproduziert. Ich hatte es nicht in eine CLAUDE.md geschrieben. Es war einfach in der Codebase, in den Mustern, in der Commit-History. Das Modell hat es aufgegriffen, indem es da war.

Nach genug Monaten davon hören sich die Vorschläge nicht mehr wie generischer AI-Output an. Sie fangen an, sich wie eine Erweiterung der eigenen Entscheidungshistorie anzufühlen. Keine Magie. Nur Gradientenabstieg über die eigenen Entscheidungen, akkumuliert.

Diese Co-Evolution funktioniert besser mit einfachen, beobachtbaren Tools. Ein Grund, warum ich CLI-first gegangen bin, anstatt einen Wald von MCP-Servern aufzustellen: CLIs hinterlassen eine Spur. Jeder Befehl in der Shell-History. Jede Flag im Commit. Der Agent sieht, was gestern funktioniert hat, und verkettet dieselben Muster morgen. Ich bin tief darauf eingegangen, warum CLIs MCP für Agents schlagen anderswo. Kurze Version: einfache Tools, die komponieren, schlagen glänzende Tools, die abstrahieren.

Selbstverstärkung

Jeder Scraper-Lauf fügt Zeilen zu einer privaten Datenbank hinzu. Jeder Konkurrenz-Preischeck bereichert meine Sicht auf den Markt. Jedes Produkt, das ich aufnehme, jeder Social Post, der shippt, jedes Lieferantengespräch, das ich transkribiere, alles stapelt sich. Nach sechs Monaten habe ich ein Korpus von Entscheidungen, Snapshots und Mustern, das nirgendwo anders existiert.

Das ist der Teil, den niemand an einem Wochenende nachbauen kann.

Die Architektur? Klar. Jeder mit drei Monaten und einer Kreditkarte kann die Architektur klonen. Docker, Scraper, Claude Code in einer Schleife, Monitoring-Stack. Nichts davon ist geheim. Die Blog-Posts existieren. Die Repos existieren.

Aber die Daten gehören mir. Sechs Monate diszipliniertes Scraping in meinen Verticals. Sechs Monate Produktlaunch-Ergebnisse verknüpft mit spezifischen Copy-Varianten. Sechs Monate davon, welche Lieferanten sauber liefern und welche Müll in ihre Feeds einbetten. Sechs Monate Materie, die sich mit einer Sekunde pro Sekunde ansammelt, egal wie reich der Konkurrent ist.

Die Architektur ist die Tasse. Die Daten sind das, was in der Tasse ist. Eine schickere Tasse zu kaufen holt einen nicht auf.

Selbstheilung (Zwei Geschmacksrichtungen)

Geschmacksrichtung eins ist voll automatisch. Abschnitt 1 ist bereits passiert, ihr habt es gelesen. Monitoring fängt einen Fehler ab, Claude Code untersucht, Fix wird angewendet, ich bekomme die E-Mail. Kein Drama.

Geschmacksrichtung zwei ist minimaler menschlicher Trigger. Ich schiebe einen Screenshot eines Fehlers an eine Claude Code-Session, drei Zeilen Kontext, und es läuft. Liest Logs, geht den Dependency-Tree ab, schlägt einen Fix vor oder wendet einen an. In manchen Fällen wird es ein bisschen VPS-Ressource bereitstellen, wenn das Problem kapazitätsbezogen ist. (Noch nicht Routine für mich. Ich bin vorsichtig mit dem „Apply"-Button bei Infra-Änderungen.)

Hector Flores hat früher dieses Jahr ein Enterprise-Selbstheilungs-Setup demonstriert, Azure MCP plus agentic AI, und berichtete von 70% der Produktionsvorfälle, die ohne menschliche Berührung gelöst wurden. Das ist eine voll besetzte Umgebung mit Platform Engineers und SRE im Bereitschaftsdienst. Ich bin ein Typ mit ein paar VPS und einem Claude Code-Abonnement. Ich bin nicht bei 70% für jede Vorfallsklasse. Aber bei den Arten von Fehlern, die früher meine Wochenenden ruiniert haben (hängende Container, abgelaufene Token, kaputte Cron Jobs, volle Festplatten), bin ich ziemlich nah dran. Anderes Setup, ähnliche Kurve.

Die Contract-Schicht unter all dem ist das, was Selbstheilung zuverlässig statt selbstzerstörerisch macht. Ich bin tief auf den vertragsbasierten Ansatz eingegangen, den ich jetzt um jede Claude Code-Session lege früher. Ohne das lässt man ein LLM die Prod-Infra um 23 Uhr umschreiben. Autsch.

Drei Eigenschaften. Zeitabhängigkeit, Erfahrungsabhängigkeit, Widerstand gegen Replikation. Der ursprüngliche Frame waren SaaS-Burggräben. Sie mappen genauso sauber auf einen einzelnen Operator mit ein paar Servern und einem Abonnement.

Das ist der Unterschied zwischen einem Workflow und einem Stack That Lives.

Vom Operator zum Fahrer

Eine Metapher für Nicht-Devs, die das lesen.

Gehen. Das ist ChatGPT in 2023. Du bist das Betriebssystem. Du tippst alles. Jeden Gedanken, jeden Prompt, jede Neuformulierung. Das Modell sitzt da und wartet. Du bewegst die Welt, indem du deine Finger bewegst.

Radfahren. Da sind die meisten Leute jetzt. Du fügst einen Agent hinzu. Du fütterst ihn mit Inputs, er produziert Outputs, du fügst sie von Hand zusammen. Schneller als Gehen. Immer noch sehr du, der lenkt und in die Pedale tritt.

Autofahren. Da bin ich nach sechs Monaten. Du baust das Auto um dich herum. Die Infra ist das Chassis. Die Agents sind der Motor. Die Daten sind der Treibstoff. Du hast einen Kofferraum (die Assets, die du angesammelt hast). Du hast Beifahrersitze (Sub-Agents, die spezifische Aufgaben erledigen). Und kritisch, du hast Tempomat. Du kannst für Strecken die Hände vom Lenkrad nehmen. Nicht um auszusteigen. Um weiter zu kommen mit weniger von dir in der Schleife.

Karpathy hat Mitte 2025 eine andere Metapher populär gemacht. LLM ist eine CPU, Context Window ist RAM, du bist das OS. Technisch sauber. Ich habe es selbst zitiert. Aber es wirft den Builder als Nervensystem. Du als OS bedeutet, du kannst niemals schlafen.

Die Auto-Metapher öffnet eine andere Frage: was passiert, wenn du aufhörst zu fahren? Parkst es. Schaltest es aus. Gehst ins Bett. Mit dem OS-Framing kannst du nicht. Mit dem Auto-Framing musst du fragen, ob das System ohne dich läuft.

Das ist der Reifetest. Nicht „wie clever ist dein Prompt". Nicht „wie viele MCP-Server hast du". Es ist: was passiert um 23:42 Uhr, wenn etwas kaputt geht und du am Esstisch sitzt?

Im Februar 2026 hat Karpathy selbst das Framing verschoben. Er postete, dass Vibe Coding passé sei und schlug stattdessen agentic engineering vor, definiert grob als Orchestrierung von Agents, die den Code machen, anstatt ihn direkt selbst zu tippen. Das ist eine echte Verschiebung. Vibe Coding ging darum, schnell zu tippen und dem Modell zu vertrauen. Agentic Engineering geht darum, Gerüste um das Modell zu bauen, damit es Jobs ausführen kann.

Ich würde noch eine Schicht obendrauf legen. Vibe Coding (Feb 2025) → agentic engineering (Feb 2026) → Infrastruktur-Level-Stacks, die deine Abwesenheit überleben (jetzt). Verschiedene Anliegen, gestapelt. Vibe Coding bringt dir ein Feature. Agentic Engineering bringt dir ein Projekt. Der Stack That Lives bringt dir einen Dienstagabend, wo das System seine eigenen Ausfälle handhabt, während du das Abendessen beendest.

Was in diesem Übergang stirbt

Zeit, ehrlich zu sein über das, was man aufgibt.

Das Große: erschöpfendes Code-Verständnis.

Sechs Monate inkrementelle Claude Code-Arbeit bedeutet, es gibt Ecken meines Systems, die ich nicht mehr Zeile für Zeile lese. Ich weiß, was sie tun. Ich erinnere mich nicht immer genau wie. Die Funktionssignatur ist vertraut, der Test läuft durch, die Logs sehen richtig aus, aber wenn du mich bitten würdest, die Implementierung aus dem Gedächtnis an die Tafel zu schreiben, würde ich fummel. Manche Dateien habe ich buchstäblich nie von Hand geöffnet.

Das hat mich früher erschreckt. Jetzt behandle ich es als Eintrittspreis.

Du tauschst Minute-für-Minute-Kontrolle gegen Zeit. Du tauschst lokale Lesbarkeit gegen globale zeitliche Asymmetrie. Für einen Solo ist dieser Tausch generell positiv. Du musst dich nicht wirklich an jede Zeile erinnern. Du brauchst das System, um weiterzulaufen, während du schläfst. Für ein Team ist es schwieriger. Geteiltes Verständnis erodiert, wenn niemand den Code vollständig besitzt, und diese Erosion zeigt sich in Onboarding-Schmerzen sechs Monate später. (Wenn du ein Engineering-Team leitest und dieser Absatz dich zucken ließ, liegst du nicht falsch. Anderer Tradeoff. Anderes Spiel.)

Es gibt einen kleineren Vorbehalt: Plattformrisiko. Der ganze Stack läuft auf Hostinger VPS-Instanzen. Solide für mich, aber wie jede Cloud-Sache, jemand anderes Computer. Wenn Hostinger morgen ihre Preise verdreifacht, oder ihre TOS umschreibt, um Scraper zu verbieten, oder einfach eine schlechte Woche hat, wackelt das System. Die Verteidigung ist Datenportabilität. Halte die Infra-Schicht dünn und die Logik-Schicht fett. Wenn die Infra feindlich wird, migrierst du das Chassis. Motor und Daten fahren mit.

Das ist der Tausch. Weniger Kontrolle, mehr Zeit. Weniger lokale Lesbarkeit, mehr zusammengesetzte Asymmetrie. Dein Konkurrent kann die Architektur in drei bis vier Monaten kopieren. Dein Konkurrent kann sechs Monate deiner spezifischen Daten und deiner spezifischen Entscheidungshistorie nicht kopieren. Nicht an einem Wochenende. Nicht in einem Quartal. Und wenn du weitermachst, auch nicht in einem Jahr.

Der Tausch ist der Burggraben.


Vor sechs Monaten hätte ein Ausfall um 23:42 Uhr meinen Abend zerstört.

Heute Abend: Abendessen.

Der Stack That Lives.


Quellen

Dieser Artikel kann Affiliate-Links enthalten. Ich erhalte möglicherweise eine kleine Provision, wenn du über sie kaufst. Für dich ändert sich nichts, der Preis ist derselbe, und es hilft, meine Arbeit zu unterstützen.