Der Moment, in dem Vibe Coding nicht mehr skalierte
Im Februar 2025 postete Andrej Karpathy auf X etwas, das wie ein Witz aussah. Er beschrieb „Vibe Coding" als das Akzeptieren von allem, was ein LLM produzierte, ohne es wirklich zu lesen. „Ich sehe nur Sachen, sage Sachen, führe Sachen aus und kopiere Sachen", schrieb er, „und meistens funktioniert es."
Es funktionierte tatsächlich meistens. Etwa ein Jahr lang.
Bis Ende 2025 begann die Branche, die Rechnung zu sehen. Forrester-Untersuchungen, die 2025 veröffentlicht wurden, ergaben, dass Code mit erheblicher KI-Beteiligung etwa die 1,7-fache Rate an schwerwiegenden Problemen aufwies. Separate Audits von Sicherheitsfirmen bezifferten den Anteil des KI-generierten Codes mit Sicherheitslücken auf zwischen 40 und 62 Prozent, abhängig vom Prompt-Stil und der Sprache. Modelle halluzinieren APIs, überspringen die Eingabevalidierung, geben Geheimnisse in Logs preis und rufen selbstbewusst Funktionen auf, die nicht existieren.
Was zerbrach, war die Annahme, dass ein einziger Prompt und ein einziges Kontextfenster eine echte Codebasis tragen könnten. Repositories wurden größer. Konventionen wurden spezifischer. Seiteneffekte (Migrationen, Deployments, kostenpflichtige API-Aufrufe) wurden gefährlicher. Der Workflow, der sich bei einer Greenfield-App magisch anfühlte, brach zusammen, sobald man ihn auf einen Dienst mit fünf Jahren eingebackener Entscheidungen richtete.
Die Risse zeigten sich auf drei Arten. Modelle vergaßen mitten in einer Session die Projektkonventionen und führten Muster wieder ein, die das Team monatelang gelöscht hatte. Lange Sessions sammelten so viel irrelevanten Kontext an, dass das Modell anfing, die eigentliche Aufgabe zu ignorieren. Agents führten fröhlich zerstörerische Befehle aus, weil nichts sie daran hinderte. Ein Prompt, der „nicht auf main pushen" sagte, funktionierte etwa 95 Prozent der Zeit, was eine andere Art ist zu sagen, dass er in 1 von 20 Sessions fehlschlug.
Bis Ende 2025 hatte jedes ernsthafte Team, das Claude Code, Cursor oder ähnliche Werkzeuge verwendete, eine Version desselben Gerüsts um das Modell herum gebaut. Niemand hatte bisher einen Namen dafür.
Karpathys Umbenennung in Agentic Engineering
Im Februar 2026 postete Karpathy erneut. Der neue Begriff lautete „Agentic Engineering".
Vibe Coding, argumentierte er, beschrieb den Spielzeugmodus. Agentic Engineering beschrieb, was die Leute, die tatsächlich auslieferten, taten: projektspezifische Kontextdateien schreiben, enge Skills definieren, Subagents für isolierte Arbeit erzeugen und Tool-Nutzung durch deterministische Hooks absichern. Das Modell macht weiterhin das Tippen. Der Mensch macht das Engineering des Systems, in dem das Modell läuft.
Die Werkzeuge reiften zwischen den beiden Posts. Anthropics Claude Code Best Practices dokumentierte die CLAUDE.md-Konvention und das Subagent-Pattern. Building Agents with the Claude Agent SDK legte die Agent-Schleife und die Rolle der Hooks dar. Skills erschienen im Oktober 2025: kleine Markdown-Dateien, die der Agent nur lädt, wenn die Aufgabe sie auslöst. Cursor 2.0 lieferte Background Agents in Cloud-VMs mit Git-Worktree-Isolation und bis zu acht parallelen Agents aus.
Martin Fowlers „Context Engineering for Coding Agents" fasste das Prinzip zusammen, das all dies verband. Die Aufgabe ist nicht mehr Prompt Engineering, das eine Textfolge optimierte. Die Aufgabe ist Context Engineering: zu entscheiden, was das Modell sieht, wann es es sieht und was es damit tun darf.
Das ist nicht spezifisch für Anthropic. Cursor nennt sie Rules und Background Agents. GitHub Copilot verwendet eine AGENTS.md-Konvention. Gemini CLI verwendet GEMINI.md. Die Namen unterscheiden sich. Die Form nicht.
Die vier Säulen des Agentic Engineering
Bevor wir tief in die einzelnen Säulen einsteigen, hilft es, sie nebeneinander zu sehen. Sie sehen ähnlich aus (es sind alles „Dinge, die Sie dem Agent geben"), aber sie lösen unterschiedliche Probleme.
| Säule | Was sie speichert | Wann sie geladen wird | Fehlerbild bei Abwesenheit |
|---|---|---|---|
| CLAUDE.md | Immer wahrer Projektkontext: Stack, Konventionen, Befehle, harte Regeln | Jede Session, automatisch | Modell erfindet Konventionen neu, vergisst den Paketmanager, führt npm install in einem Yarn-Repo aus |
| Skills | Prozedurales Wissen für enge Aufgaben (Rebase, Schema-Migration, Stripe-Review) | Bei Bedarf, wenn die Aufgabe zur Skill-Beschreibung passt | Modell improvisiert domänenspezifische Schritte und bringt die Reihenfolge durcheinander |
| Subagents | Ein frisches Kontextfenster plus ein System-Prompt für eine einzelne Rolle | Wenn der Hauptagent eine definierte Aufgabe delegiert | Hauptkontext wird durch Nebenquests verschmutzt; ein schlechter Tool-Aufruf beschädigt die gesamte Session |
| Hooks | Shell-Befehle, die bei Tool-Ereignissen ausgelöst werden (PreToolUse, PostToolUse, Stop) | Deterministisch, jedes Mal, wenn der Trigger feuert | Riskante Befehle laufen ungeprüft; Formatter läuft nie; der „immer X tun"-Prompt schlägt stillschweigend fehl |
Das Muster: CLAUDE.md ist, was das Modell weiß. Skills sind, was das Modell nachschlagen kann. Subagents sind, wen das Modell sonst noch fragen kann. Hooks sind, was das Modell nicht vermeiden kann.
Jede Säule existiert, weil die anderen drei dieses spezifische Fehlerbild nicht lösen können.
CLAUDE.md: Die hinweisende Schicht
CLAUDE.md (oder AGENTS.md oder GEMINI.md, je nach Ihrem Werkzeug) ist eine Markdown-Datei im Wurzelverzeichnis Ihres Repos. Der Agent liest sie zu Beginn jeder Session und behandelt sie als Hintergrundkontext.
Es ist kein Speicher im Sinne eines Consumer-Produkts. Es ist die Datei, die Sie, der Mensch, schreiben, um dem Agent zu sagen, was er gelernt hätte, wenn er ein Jahr lang im Team gewesen wäre.
Was hineingehört:
- Stack und Versionen: „Next.js 16 App Router, React 19, Yarn 1.22 (npm verboten), Node 22."
- Repo-Layout: welches Verzeichnis was macht.
- Befehle:
yarn dev,yarn test,yarn build:ci, mit Hinweisen, welcher sicher auszuführen ist. - Harte Regeln: „Niemals direkt auf
mainpushen. Immer einen Feature-Branch erstellen." - Style-Konventionen: Tab-Breite, Lint-Regeln, die beißen, Namenskonventionen.
- Domain-Abkürzungen: Glossarbegriffe, die spezifisch für Ihr Produkt sind.
Was nicht hineingehört: Schritt-für-Schritt-Anleitungen für gelegentliche Aufgaben (die gehören in Skills), lange Referenzdokumente (das Modell überfliegt, verlinken Sie stattdessen) und alles Geheime (CLAUDE.md-Inhalt wird in den Kontext geladen, und Kontext kann zurückzitiert werden).
Die Falle, in die die meisten Teams tappen, ist die Alles-Bagel-CLAUDE.md. Eine 4.000-Zeilen-Datei mit jedem Codierungsstandard und jeder Architekturentscheidung. Das Modell lädt all das bei jeder Aufgabe und beginnt, die relevanten 5 Prozent genauso zu behandeln wie die irrelevanten 95 Prozent. Die Token-Kosten steigen. Die Einhaltung spezifischer Regeln sinkt.
Eine gute CLAUDE.md ist näher an einem Haftnotizzettel als an einem Wiki. Streben Sie einen Bildschirm wesentlichen Kontextes an. Wenn Sie merken, dass Sie einen Abschnitt schreiben, der mit „Wenn Sie X machen..." beginnt, dann will X wahrscheinlich ein Skill sein. CLAUDE.md ist für „immer wahr". Skills sind für „wahr wenn".
Skills: Just-in-time-Wissensdateien
Skills sind kleine Markdown-Dateien (typischerweise unter 200 Zeilen), die der Agent nur lädt, wenn die Aufgabe passt. Jedes Skill hat einen Namen, eine Beschreibung und einen Körper. Die Beschreibung ist das, was der Agent zuerst liest, um zu entscheiden, ob er das vollständige Skill einbeziehen soll.
Anthropic lieferte Skills Ende 2025 als erstklassiges Konzept aus. Sie legen eine Skill-Datei in ein bekanntes Verzeichnis; ihr Frontmatter beschreibt, wann sie zu verwenden ist. Beim Planen einer Aufgabe scannt der Agent die verfügbaren Skill-Beschreibungen und lädt alle, deren Beschreibung passt.
Gute Skill-Beispiele:
rebase-cleanly: wie man aufdeveloprebased, Konfliktlösungsregeln, was zu tun ist, wenn Tests nach dem Rebase fehlschlagen.review-stripe-integration: Checkliste für Änderungen, die Stripe-Webhooks, Idempotenzschlüssel, Preis-IDs betreffen.add-shadcn-component: die genauen Befehle und Importkonventionen zum Hinzufügen einer shadcn/ui-Komponente zu diesem Repo.debug-flaky-test: die bevorzugte Vorgehensweise des Teams, wenn ein CI-Test sporadisch ist.
Jedes ist prozedural und eng. Jedes wäre zu viel Detail, um in CLAUDE.md zu wohnen, ist aber zu wichtig, um es dem Allgemeinwissen des Modells zu überlassen.
Das mentale Modell: CLAUDE.md ist Ihr Kollege, der dem neuen Mitarbeiter am ersten Tag die Grundlagen erklärt. Ein Skill ist das Runbook, das sie dem neuen Mitarbeiter aushändigen, wenn ein Stripe-Webhook um 2 Uhr morgens ausfällt. Sie lernen das Runbook nicht auswendig; Sie lesen es, wenn Sie es brauchen.
Skills lassen sich kombinieren. Der Agent kann drei Skills in einer Aufgabe laden („eine neue API-Route hinzufügen" plus „Eingabe mit Zod validieren" plus „einen Vitest-Test schreiben"), ohne dass Sie die Kombination im Voraus vorhersagen.
Skill-Beschreibungen sind wichtiger, als Sie denken würden. Vage Beschreibungen („hilfreich für Code-Dinge") werden entweder nie ausgelöst oder bei allem ausgelöst. Schreiben Sie Beschreibungen, die die Situation benennen: „Verwenden, wenn der Benutzer darum bittet, einen Branch zu rebasen, Merge-Konflikte zu lösen oder die Commit-Historie zu bereinigen."
Subagents: Isolierte Kontext-Worker
Ein Subagent ist ein Agent, den der Hauptagent aufrufen kann. Er hat seinen eigenen System-Prompt, sein eigenes Kontextfenster und seine eigenen Tool-Berechtigungen. Wenn er fertig ist, gibt er ein Ergebnis an den Hauptagent zurück. Dann verschwindet er.
Die naive Lesart ist „Subagents sind für Parallelität". Das ist ein Teil davon (Cursor 2.0 wirbt mit bis zu acht parallelen Background Agents), aber Parallelität ist nicht der Hauptnutzen. Der Hauptnutzen ist Kontextisolation.
Drei Muster, bei denen sich Subagents lohnen:
1. Der Researcher. Sie möchten, dass der Agent 200 Dateien durchsucht und zusammenfasst, was er findet. Wenn der Hauptagent das tut, landen alle 200 Dateien im Hauptkontext, obwohl Sie nur drei Sätze Zusammenfassung brauchten. Ein Research-Subagent liest die 200 Dateien, fasst zusammen und gibt einen Absatz zurück. Der Hauptkontext bleibt sauber.
2. Der Reviewer. Vor einem Commit möchten Sie einen frischen Blick auf den Diff. Ein Reviewer-Subagent lädt ein „Code Review"-Skill, liest den Diff ohne anderen Kontext und meldet Probleme. Da er keine Erinnerung an die Implementierungsdebatte hat, die der Hauptagent mit Ihnen geführt hat, kann er Probleme nicht wegrationalisieren.
3. Die riskante Operation. Ein Migrationsskript. Ein Massen-Rename. Eine Schemaänderung. Der Agent plant und führt sie in Isolation aus und meldet sich zurück. Wenn etwas schiefgeht, ist der Schaden im Kontext des Subagents enthalten.
Es gibt echte Kosten. Jeder Subagent ist ein weiterer Modellaufruf und ein weiteres Kontextfenster. Sie fügen Koordinationskomplexität hinzu. Ein Team, das für jede Aufgabe einen Subagent erzeugt, verbrennt Tokens und verlangsamt sich selbst.
Die Faustregel: Erzeugen Sie einen Subagent, wenn eines von drei Dingen zutrifft. (1) Die Aufgabe würde viel Müll in den Hauptkontext kippen. (2) Die Aufgabe profitiert von einer frischen Perspektive. (3) Die Aufgabe ist riskant und Sie wollen sie sandboxen. Andernfalls arbeiten Sie weiter in der Hauptsession.
Open-Source-Sammlungen wie VoltAgents awesome-claude-code-subagents katalogisieren Hunderte vorgefertigter Subagents. Die meisten Teams kommen am besten mit drei oder vier individuell auf ihre Codebasis abgestimmten Subagents zurecht, anstatt mit Dutzenden generischer.
Hooks: Deterministische Leitplanken
Hooks sind der Teil des Stacks, aus dem sich das Modell nicht herausreden kann. Sie sind Shell-Befehle, die mit Tool-Ereignissen verdrahtet sind. Wenn das Ereignis feuert, läuft der Befehl. Das Modell hat kein Mitspracherecht.
Die kanonischen Ereignisse:
- PreToolUse: feuert vor einem Tool-Aufruf. Kann den Aufruf blockieren.
- PostToolUse: feuert nach einem Tool-Aufruf. Nützlich für Formatter, Validatoren, Seiteneffekte.
- Stop: feuert, wenn der Agent eine Runde beendet. Nützlich für Benachrichtigungen.
- Notification: feuert bei bestimmten Agent-Nachrichten.
Warum Hooks Prompts bei der Sicherheit schlagen: Prompts sind probabilistisch. Selbst eine klare Anweisung wie „niemals rm -rf ausführen" wird gelegentlich fehlschlagen, weil das Modell Mustervervollständigung betreibt. Ein Hook, der den Befehl nach rm -rf durchsucht und mit Nicht-Null beendet, bevor die Shell ihn sieht, wird in null Prozent der Fälle fehlschlagen. Es ist eine Regex, kein Vibe.
Drei Hooks, die es wert sind, vorhanden zu sein:
pre-bash-guard (PreToolUse auf Bash). Liest den Befehl, blockiert gefährliche Muster: rm -rf /, git push --force gegen geschützte Branches, DROP TABLE, direkte Überschreibungen von .env*-Dateien. Ein 30-Zeilen-Shell-Skript bewahrt Sie vor Katastrophen, die Prompts nicht zuverlässig verhindern können.
post-edit-prettier (PostToolUse auf Edit/Write). Nachdem der Agent eine .ts- oder .tsx-Datei bearbeitet hat, Prettier ausführen. Es deterministisch abzufangen hält den Stil über die Session hinweg konsistent.
notify-on-stop (Stop). Wenn der Agent eine lang laufende Aufgabe beendet, eine macOS-Benachrichtigung oder einen Slack-Ping auslösen. Lebensqualität, aber es ändert, wie Sie arbeiten: Sie können den Agent zehn Minuten laufen lassen und müssen ihn nicht beaufsichtigen.
Es gibt geringe Performance-Kosten. Jeder Hook ist ein Prozess-Spawn. In der Praxis ist dies im Vergleich zur eigenen Latenz des Modells nicht wahrnehmbar, und die Determiniertheit ist es wert.
Die mentale Verschiebung: Hören Sie auf, Sicherheit als etwas zu betrachten, worum Sie das Modell bitten. Beginnen Sie, Sicherheit als etwas zu betrachten, das die Umgebung erzwingt, genauso wie eine CI-Pipeline Tests erzwingt. Das Modell ist ein schneller Junior. Hooks sind der Pre-Commit-Hook, den der Junior nicht deaktivieren kann.
Wie sich die vier Säulen zusammenfügen
So sieht das Setup eines echten Teams in Prosa aus.
Das Repo hat eine CLAUDE.md im Wurzelverzeichnis. Etwa 80 Zeilen. Sie listet den Stack auf (Next.js 16, React 19, Yarn, Node 22), das Verzeichnislayout, den Test-Befehl, die Deploy-Regel und ein Glossar von fünf Domänenbegriffen.
In .claude/skills/ sechs Skill-Dateien: rebase-cleanly.md, add-api-route.md, review-stripe.md, debug-firestore.md, write-deep-dive.md, sql-migration.md. Jede ist 80 bis 150 Zeilen.
In .claude/subagents/ drei. Ein reviewer läuft vor Commits und meldet Diff-Probleme. Ein researcher wird aufgerufen, wenn der Hauptagent mehr als zehn Dateien lesen muss. Ein test-runner wird aufgerufen, wenn ein Test beim ersten Versuch fehlschlägt; er isoliert den Fehler, ohne den Hauptkontext zu verschmutzen.
In .claude/hooks/ vier. pre-bash-guard.sh blockiert gefährliche Befehle. pre-edit-env-guard.sh blockiert Änderungen an .env.local. post-edit-prettier.sh führt Prettier nach Änderungen an .ts/.tsx-Dateien aus. notification.sh pingt auf macOS, wenn eine lange Aufgabe beendet ist.
Eine normale Session: Der Entwickler bittet den Agent, „eine neue API-Route hinzuzufügen, die Benutzer-Lesezeichen zurückgibt". Der Agent liest CLAUDE.md, passt zum Skill add-api-route und lädt es, schreibt die Datei. Der Post-Edit-Hook führt Prettier aus. Er schreibt einen Test, Prettier läuft erneut. Er bittet den Reviewer-Subagent, den Diff zu prüfen. Der Reviewer markiert fehlende Eingabevalidierung; der Hauptagent fügt sie hinzu. Der Entwickler bittet zu committen. Der Pre-Bash-Hook prüft den Branch und erlaubt den Commit. Der Stop-Hook pingt den Entwickler.
Kein Teil dieses Flows brauchte einen langen Prompt. Der Prompt war „eine neue API-Route hinzufügen, die Benutzer-Lesezeichen zurückgibt". Alles andere war in die Umgebung verdrahtet.
Anti-Patterns, die Entwickler immer wieder ausliefern
Einige Muster, die zu vermeiden sind, abgeleitet von Teams, die diesen Stack schlecht eingeführt haben.
Das Eine-Riesen-CLAUDE.md. Manche Teams behandeln CLAUDE.md als Müllhalde für jede Entscheidung der letzten drei Jahre. Das Ergebnis ist eine 5.000-Zeilen-Datei, die das Modell lädt, aber nicht verinnerlicht. Die Regel, kein npm zu verwenden, landet zwischen zwei Seiten Architekturbegründung, und das Modell greift die Begründung auf und vergisst die Regel. Halten Sie CLAUDE.md knapp.
Die Wette ohne Hooks. Manche Teams überspringen Hooks vollständig und verlassen sich auf Prompts, um den Agent sicher zu halten. Das funktioniert die meiste Zeit, was genau das Problem ist. Die meiste Zeit ist nicht gut genug für rm -rf oder git push --force. Wenn die Konsequenz „Ich habe eine Stunde Arbeit verloren" ist, sind Prompts in Ordnung. Wenn die Konsequenz „Ich habe eine Produktionstabelle gelöscht" ist, brauchen Sie einen Hook.
Subagent-Wildwuchs. Manche Teams bauen einen Subagent für jede denkbare Rolle. Researcher, Reviewer, Planner, Summarizer, Namer, Refactorer, Documenter, Tester. Jeder ist eine weitere Datei zu pflegen, ein weiterer Token-Verbrauch, ein weiterer Koordinationsaufwand. Teams, die mit Subagents Erfolg haben, neigen dazu, drei bis fünf zu haben, jeder mit einer klaren Aufgabe. Nicht zwanzig.
Skill-als-Dokumentationsmüllhalde. Ein Skill ist kein Ort für Ihre alten Wiki-Seiten. Wenn ein Skill 800 Zeilen hat, lädt das Modell jedes Mal 800 Zeilen, wenn es ausgelöst wird. Wenn Ihr Skill lang ist, sind es wahrscheinlich zwei Skills.
Skills wie CLAUDE.md behandeln. Immer wahren Kontext in ein Skill zu packen, bedeutet, dass es nur manchmal lädt. Die teamweite Regel „niemals npm verwenden" gehört in CLAUDE.md, weil sie für jede Aufgabe gilt.
Hooks, die den Agent zehn Sekunden lang blockieren. Ein Hook, der bei jeder Änderung eine vollständige Test-Suite ausführt, macht den Agent unbrauchbar. Hooks sollten schnell sein. Die teuren Prüfungen gehören in CI.
Das praktische Setup, das Sie diese Woche einführen können
Wenn Sie bis hierher gelesen haben und einen Ausgangspunkt wollen, hier ist die schlanke Version. Ein Senior Engineer kann das an einem Tag aufsetzen, und es reicht aus, um Agentic Coding deutlich zuverlässiger zu machen als die Vibe-Coding-Voreinstellung.
CLAUDE.md (etwa 50 Zeilen). Stack und Versionen. Paketmanager (und welcher niemals zu verwenden ist). Top-Level-Verzeichnisse. Die fünf harten Regeln (nicht auf main pushen, .env.local nicht anfassen, diese Testbefehle verwenden). Eine kurze Liste von Domänenbegriffen. Widerstehen Sie dem Drang, mehr hinzuzufügen.
Zwei Skills. rebase-cleanly.md (die Rebase-Schritte Ihres Teams, maximal 80 Zeilen) und review-changes.md (Ihre Code-Review-Checkliste, maximal 100 Zeilen).
Ein Reviewer-Subagent. Lädt review-changes.md, liest den Diff, meldet Probleme. Wird vor Commits aufgerufen.
Drei Hooks. PreToolUse auf Bash blockiert rm -rf, git push --force gegen geschützte Branches und Änderungen an .env*-Dateien. PostToolUse auf Edit/Write führt Prettier auf bearbeiteten .ts/.tsx-Dateien aus. Stop löst eine macOS-Benachrichtigung aus, wenn der Agent fertig ist.
Das ist alles. CLAUDE.md plus zwei Skills plus ein Subagent plus drei Hooks. Ein Ordner mit vielleicht acht Dateien, alle unter Versionskontrolle, alle vom Rest des Teams überprüfbar.
Sie werden iterieren. Nach einer Woche werden Sie Aufgaben bemerken, die der Agent immer wieder vermurkst, und sie als neue Skills kodifizieren. Sie werden Kategorien schlechter Befehle sehen und sie zum Pre-Bash-Guard hinzufügen. Sie werden den Moment erkennen, in dem ein Researcher-Subagent Ihren Hauptkontext sauber gehalten hätte, und einen hinzufügen. Die vier Säulen sind die Form. Der Inhalt gehört Ihnen.
Der Wechsel von Vibe Coding zu Agentic Engineering ist kein Sprung in der Cleverness. Es ist ein Schritt in Richtung operativer Disziplin. Sie behandeln den Agent so, wie Sie jedes andere System behandeln würden, das in der Produktion läuft: mit Konventionen, Leitplanken und Isolation zwischen Belangen. Weniger Magie, mehr Engineering und ein Workflow, der über den ersten Monat hinaus skaliert.
Häufig gestellte Fragen
Ist das spezifisch für Claude Code oder gilt es auch für Cursor und andere Agents?
Die Säulen gelten werkzeugübergreifend; die Namen unterscheiden sich. Cursor verwendet „Rules"-Dateien und „Background Agents". GitHub Copilot verwendet AGENTS.md. Gemini CLI verwendet GEMINI.md. Hooks sind noch nicht universell (Claude Code hat die ausgereifteste Implementierung), aber die meisten Werkzeuge haben ein Äquivalent. Das mentale Modell (Kontextschicht, On-Demand-Wissen, isolierte Worker, deterministische Wächter) lässt sich verallgemeinern, auch wenn die Implementierung sich unterscheidet.
Was ist der Unterschied zwischen einem Skill und allem in CLAUDE.md zu packen?
Das Laden. CLAUDE.md lädt zu Beginn jeder Session. Skills laden nur, wenn ihre Beschreibung zur Aufgabe passt. Wenn Sie prozedurales Wissen für zehn verschiedene Aufgaben in CLAUDE.md packen, lädt das Modell all das bei jeder Aufgabe, der Kontext füllt sich mit überwiegend irrelevantem Inhalt, und die Einhaltung spezifischer Regeln sinkt. Skills halten CLAUDE.md knapp und halten prozedurale Details bei Bedarf verfügbar.
Wann sollte ich einen Subagent erstellen, statt nur einen längeren Prompt zu verwenden?
Drei Bedingungen drängen Sie zu einem Subagent. (1) Die Aufgabe würde viel Inhalt in den Hauptkontext kippen. (2) Sie wollen eine frische Perspektive, die die angesammelte Argumentation des Hauptagents nicht verfälschen kann. (3) Die Aufgabe ist riskant und Sie wollen sie sandboxen. Andernfalls ist ein längerer Prompt oder ein Skill normalerweise das bessere Werkzeug. Subagents kosten Tokens und Koordination.
Verlangsamen Hooks den Agent?
Jeder Hook ist ein Prozess-Spawn, also fügt er Millisekunden bis Sekunden hinzu, abhängig davon, was er tut. In der Praxis wird das von der eigenen Latenz des Modells in den Schatten gestellt. Lange Hooks (eine vollständige Test-Suite bei jeder Änderung ausführen) lassen den Agent träge wirken; die gehören in CI. Eine gute Regel: PreToolUse-Hooks sollten im Normalfall unter 200ms beenden; PostToolUse-Hooks wie Formatter können ein bis zwei Sekunden brauchen, ohne dass es jemand bemerkt.
Sollte ich meine CLAUDE.md ins Repo committen?
Ja, fast immer. CLAUDE.md ist ein Team-Artefakt: Sie kodiert die Konventionen, denen jeder (Mensch oder Agent) folgen sollte. Sie zu committen bedeutet, dass die Agents des gesamten Teams aus demselben Kontext arbeiten, und die Datei wird wie jeder andere Code überprüft. Das Einzige, was Sie lokal behalten könnten, sind entwicklerspezifische Berechtigungseinstellungen (Claude Code unterstützt dafür eine settings.local.json).
Schlussgedanken
Karpathys zwei Posts, ein Jahr auseinander, umfassen sauber, was 2025 mit KI-Coding passiert ist. Der erste war die Erlaubnis zu spielen. Der zweite war die ankommende Rechnung. Vibe Coding war als Entdeckungsmodus nützlich: Es lehrte die Menschen, was diese Modelle leisten können, ohne sie zuerst ein SDK lernen zu lassen. Es war nicht dafür ausgelegt, ausgeliefert zu werden.
Was es ersetzt, ist für jeden erkennbar, der an echten Systemen gearbeitet hat. Sie schreiben die Invarianten auf (CLAUDE.md). Sie verpacken die Prozeduren (Skills). Sie lagern isolierte Worker für riskante oder kontextlastige Aufgaben aus (Subagents). Sie installieren Leitplanken an den Grenzen (Hooks). Nichts davon ist exotisch. Es ist dieselbe operative Disziplin, die ein Hobbyprojekt von einem Dienst unterscheidet, der am Montagmorgen läuft, ohne dass jemand auf Abruf ist.
Was mich an den Setups funktionierender Teams überrascht, ist, wie klein sie sind. Acht Dateien. Vielleicht insgesamt tausend Zeilen. Ein Reviewer-Subagent. Drei Hooks. Das reicht, um ein Modell, das gelegentlich Ihre Datenbank fallen lässt, in einen Teamkollegen zu verwandeln, der das nicht tut. Die Hebelwirkung liegt nicht im Volumen. Sie liegt darin, die richtige Invariante in die richtige Säule zu setzen.
Wenn Sie sich Mitte 2026 noch im reinen Vibe-Coding-Modus befinden, sind Sie nicht im Rückstand. Sie sind in der Phase, in der der Großteil des Produktivitätsgewinns daraus kommt, das Modell langweilig zu machen: vorhersehbarer, eingeschränkter, überprüfbarer. Weniger Magie, mit Absicht. Das ist die Arbeit.