Ich betreibe 15 KI-Klone von mir selbst parallel — Und das ist noch nicht mal meine finale Form

„Aber Opus ist langsamer!" schreit die innere Stimme jedes Entwicklers, der jemals Response-Zeiten gebenchmarkt hat.

Boris' Argument? Die Mathematik funktioniert anders, wenn du menschliche Zeit mit einrechnest:

Sonnet (schnelleres Modell):
Request: 30 Sekunden
× 5 Iterationen (Steuern, Korrigieren)
= 2,5 Minuten + deine Vernunft

Opus (langsameres Modell):
Request: 2 Minuten
× 1 Iteration (macht es beim ersten Mal richtig)
= 2 Minuten + deine Vernunft bleibt intakt

Die Schlüssel-Erkenntnis: Der Flaschenhals ist nicht die AI-Verarbeitungszeit — es ist die menschliche Zeit, die für Steuerung und Korrekturen draufgeht. Opus braucht weniger Händchenhalten, trifft bessere Tool-Entscheidungen und muss generell nicht siebzehn Mal pro Task hören „nein, nicht so".

Es ist wie der Unterschied zwischen einem Junior-Entwickler, der schnell ist, aber ständige Code-Reviews braucht, versus einem Senior, der langsamer ist, aber produktionsreifen Code liefert. Nur dass der Senior eine AI ist und du fünfzehn davon parallel laufen lassen kannst.

CLAUDE.md: Das kollektive Gedächtnis deiner Codebase

Hier wird es wirklich brillant.

Das Claude Code-Team pflegt eine einzige CLAUDE.md-Datei, die in Git eingecheckt ist und zu der das gesamte Team mehrmals pro Woche beiträgt. Stell es dir als lebendes Dokument vor, das jede „mach das nicht"-Lektion festhält, die Claude lernt.

Claude macht Fehler →
Entwickler bemerkt es →
Pattern zu CLAUDE.md hinzufügen →
In Git committen →
Claude liest es in der nächsten Session →
Claude macht diesen Fehler nie wieder

Es ist, als hättest du einen neuen Entwickler, der nie etwas vergisst, was du ihm sagst, und dieses Wissen mit jeder anderen Instanz seiner selbst über Zeit und Raum teilt.

Was gehört in CLAUDE.md?

Boris enthüllte die tatsächlichen Specs: ihre CLAUDE.md hat 2,5k Token und umfasst:

- Häufige Bash-Kommandos
- Code-Style-Konventionen
- UI- und Content-Design-Richtlinien
- Wie man State Management, Logging, Error Handling, Gating und Debugging macht
- Pull Request Template

Das war's. Kein Roman — ein fokussiertes Referenzdokument.

## Projektstruktur
- /src enthält Anwendungscode
- /tests spiegelt /src-Struktur wider

## Häufige Kommandos
- npm run build: Projekt bauen
- npm run test: Test-Suite ausführen
- npm run lint: Linter mit Auto-Fix ausführen

## Unsere Konventionen
- Wir verwenden überall TypeScript Strict Mode
- Bevorzuge const über let, immer
- Funktionsnamen sollten Verben sein

## Dinge, die Claude schon mal falsch gemacht hat
- Verwende keine veralteten APIs (hier ist die Liste...)
- Modifiziere niemals das .claude/ Verzeichnis direkt
- Führe immer Tests aus, bevor du einen Commit vorschlägst

Das Team nutzt sogar eine GitHub Action, um automatisch @.claude während Code-Reviews zu taggen und es zu bitten, die CLAUDE.md basierend auf Patterns in PRs zu aktualisieren. Jedes Code-Review wird zu einer Lernmöglichkeit, die sich über die Zeit potenziert.

Wie ein Beobachter bemerkte: „Jeder Fehler wird zu einer Regel. Je länger das Team zusammenarbeitet, desto intelligenter wird der Agent."

Es ist im Grunde RLHF, aber durchgeführt von deinem gesamten Engineering-Team durch Code-Reviews.

Der Zwei-Phasen-Workflow: Erst denken, dann shippen

Boris yolot nicht einfach durch seine Prompts. Er hat einen disziplinierten Zwei-Phasen-Ansatz entwickelt:

Phase 1: Plan-Modus (Interaktiv)

[Shift+Tab][Shift+Tab] — wechselt in den Plan-Modus

Du: „Ich brauche OAuth-Authentifizierung"

Claude: „Hier ist mein Plan:
1. passport-oauth2 installieren
2. OAuth-Config-Datei erstellen
3. /auth/login und /auth/callback Routen hinzufügen
4. User-Model für OAuth-Daten aktualisieren
5. Auth-Middleware erstellen
6. Frontend mit Login-Button aktualisieren
7. Tests hinzufügen"

Du: „Sieht gut aus, aber füge auch Refresh-Tokens hinzu"

Claude: *aktualisiert Plan*

Phase 2: Ausführungs-Modus (Autonom)

Sobald der Plan genehmigt ist, wechselt Boris in den Auto-Accept-Modus. Claude führt dann den gesamten Plan aus, oft in einem Zug.

Die Philosophie ist einfach: Investiere Zeit vorab in die Planung, spare viel mehr Zeit bei der Ausführung. Es ist die AI-gestützte Version des Zimmermann-Sprichworts: Zweimal messen, einmal schneiden. Nur hier ist es: Interaktiv planen, autonom coden.

Ein guter Plan ist wirklich wichtig, betont Boris. Und er hat recht — ein gut strukturierter Plan bedeutet, dass Claude Dutzende von Datei-Edits verketten kann, ohne bei jedem Schritt menschliche Intervention zu brauchen.

Slash-Kommandos: Weil Tippen für Leute mit Zeit ist

Boris stellte in den Kommentaren klar: „Skills = Slash-Kommandos, ich verwende sie synonym." Dasselbe, verschiedene Namen.

Boris hat jeden „Inner Loop"-Workflow in Slash-Kommandos automatisiert, die in .claude/commands/ leben:

---
description: Änderungen committen, zu Remote pushen und PR erstellen
---

# Git Status
!`git status --short`

# Aktueller Branch
!`git branch --show-current`

# Letzte Commits
!`git log -5 --oneline`

Basierend auf obigem Git-Status:
1. Änderungen stagen und mit beschreibender Nachricht committen
2. Zu Remote pushen
3. PR mit klarem Titel und Beschreibung erstellen
4. Review von entsprechenden Teammitgliedern anfordern

Die Inline-Bash (diese !-Kommandos) berechnet Kontext vor, sodass Claude nicht fragen muss. Es sieht den Git-Status, kennt den aktuellen Branch, versteht die jüngste Historie — und kann sofort intelligente Entscheidungen treffen.

Boris nutzt /commit-push-pr dutzende Male jeden Tag. Das sind dutzende mehrstufige Git-Workflows, reduziert auf sieben Tastenanschläge.

Andere Kommandos aus seinem Setup:

• /quick-commit — Alles stagen und mit auto-generierter Nachricht committen
• /test-and-fix — Tests ausführen, Fehler beheben, wiederholen bis grün
• /review-changes — Uncommittete Änderungen reviewen und Verbesserungen vorschlagen
• /first-principles — Probleme in fundamentale Wahrheiten zerlegen

Diese sind in Git eingecheckt und teamweit geteilt. Jeder profitiert von den Workflow-Optimierungen aller anderen.

Subagents: Spezialisierte AI-Kollegen

Jenseits von Slash-Kommandos nutzt Boris Subagents — spezialisierte AI-Assistenten mit eigenen System-Prompts, Tool-Zugang und separaten Kontext-Fenstern.

AgentZweckcode-simplifierVereinfacht Code, nachdem Claude fertig istverify-appTestet gründlich, dass die Anwendung korrekt funktioniertcode-architectDesign-Reviews und architektonische Entscheidungenbuild-validatorStellt sicher, dass das Projekt korrekt für Deployment bautoncall-guideHilft bei der Diagnose und Lösung von Produktionsproblemen

Stell sie dir als spezialisierte Experten vor, die du für spezifische Tasks hinzuziehen kannst. Der code-simplifier läuft nach jedem Feature, um Komplexität zu reduzieren. Der verify-app-Agent hat detaillierte Anweisungen zum End-to-End-Testen von Claude Code.

Der Hauptunterschied zu Slash-Kommandos: Subagents haben ihr eigenes Kontext-Fenster, sodass sie deine Hauptkonversation nicht verschmutzen. Sie sind wirklich separate Arbeiter, die spezifische Jobs erledigen.

Hooks: Die ultimative Automatisierungsebene

Claude Code unterstützt Hooks — automatisierte Aktionen, die an spezifischen Punkten im Workflow laufen. Boris nutzt einen PostToolUse-Hook zur automatischen Code-Formatierung:

{
"hooks": {
"PostToolUse": [{
"matcher": "Edit|Write",
"hooks": [{
"type": "command",
"command": "npx prettier --write \"$CLAUDE_FILE_PATH\""
}]
}]
}
}

Jedes Mal, wenn Claude eine Datei editiert oder schreibt, formatiert Prettier sie automatisch. Das fängt die letzten 10% der Formatierungsprobleme ab und verhindert CI-Fehler ohne jede menschliche Intervention.

Ohne Hook:

Claude schreibt Code → Push zu PR → CI scheitert an Formatierung →
Formatierung reparieren → Nochmal pushen → CI erfolgreich

Mit Hook:

Claude schreibt Code → Hook formatiert → Push zu PR → CI erfolgreich ✓

Es ist der Unterschied zwischen dem Aufräumen nach deinem Roboterstaubsauger und einem Roboter, der nach sich selbst aufräumt.

Das Berechtigungssystem: Sicherheit ohne Reibung

Boris vermeidet explizit --dangerously-skip-permissions. Stattdessen nutzt er /permissions, um spezifische sichere Kommandos vorab zu erlauben:

{
"permissions": {
"allowedTools": {
"Bash": {
"allowedCommands": [
"git status",
"git diff",
"git commit",
"npm test",
"npm run build",
"npm run lint"
]
},
"Edit": { "allowed": true },
"Read": { "allowed": true }
}
}
}

Das gibt dir die Bequemlichkeit der automatischen Genehmigung für Operationen, von denen du weißt, dass sie sicher sind, während du trotzdem explizite Berechtigung für alles Ungewöhnliche benötigst. Es ist, als würdest du deiner AI einen Satz Hausschlüssel geben statt die Atomraketen-Startcodes.

MCP-Integration: Claudes Verbindung zu allem

Claude Code nutzt MCP (Model Context Protocol), um sich mit externen Tools zu verbinden. Boris' Setup umfasst:

• Slack — Updates posten, Benachrichtigungen, Konversationen durchsuchen
• BigQuery — Analytics-Queries über bq CLI ausführen
• Sentry — Error-Logs direkt abrufen
• iOS/Android-Simulatoren — für Mobile-App-Verifikation (ja, es gibt MCPs dafür)

{
"mcpServers": {
"slack": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-slack"],
"env": {
"SLACK_BOT_TOKEN": "xoxb-...",
"SLACK_TEAM_ID": "T..."
}
}
}
}

Jetzt kann Claude Dinge wie diese machen:

> Deploy to staging and notify the team in #deployments

Claude: [Führt Deployment aus]
Claude: [Nutzt Slack MCP Server]
Claude: [Postet in #deployments Channel]
✓ Deployment abgeschlossen, Team benachrichtigt

Die .mcp.json-Datei ist in Git eingecheckt. Das ganze Team bekommt diese Integrationen automatisch.

Die Ralph Wiggum-Methode: Für wenn du AI brauchst, die einfach nicht aufgibt

Für sehr lang laufende Tasks nutzt Boris etwas namens Ralph Wiggum Plugin. Benannt nach der Simpsons-Figur, die fröhlich trotz aller Hindernisse durchhält, erstellt es eine iterative Schleife, die Claude am Laufen hält, bis ein Task tatsächlich abgeschlossen ist.

Das Konzept:

Iteration 1:
Claude: [Implementiert Basic API]
Claude: [Versucht zu beenden]
Stop Hook: [Tests schlagen fehl - Exit blockieren]
Stop Hook: [Denselben Prompt zurückfüttern]

Iteration 2:
Claude: [Sieht Test-Fehler]
Claude: [Behebt Bugs]
Claude: [Versucht zu beenden]
Stop Hook: [Einige Tests schlagen noch fehl - Exit blockieren]

Iteration 3:
Claude: [Behebt verbleibende Bugs]
Claude: [Alle Tests erfolgreich]
Claude: [Gibt COMPLETE aus]
Stop Hook: [Completion Promise erkannt - Exit erlauben]
✓ Fertig!

Für diese lang laufenden autonomen Sessions nutzt Boris entweder --permission-mode=dontAsk oder --dangerously-skip-permissions — aber nur in sandboxed, isolierten Umgebungen.

Die goldene Regel: Gib Claude eine Verifikationsschleife

Hier ist Boris' wichtigster Tipp, und er hat ihn für den Schluss aufgehoben:

Gib Claude eine Möglichkeit, seine Arbeit zu verifizieren. Wenn Claude diese Feedback-Schleife hat, wird es die Qualität des Endergebnisses um das 2–3-fache steigern.

Das ist die Geheimzutat, die alles andere zum Funktionieren bringt.

Ohne Verifikation:

Claude schreibt Code → Pusht zu PR →
CI scheitert → Bugs in Produktion →
Manuelles Debugging erforderlich

Mit Verifikation:

Claude schreibt Code → Testet es →
Sieht Fehler → Behebt sie →
Testet erneut → Iteriert bis erfolgreich →
Hochwertiger Code

Verifikation sieht für jede Domäne anders aus:

• CLI-Tools: Kommando ausführen, Output prüfen
• APIs: Requests machen, Responses verifizieren
• UI: Claudes Chrome-Extension für visuelles Testen nutzen
• Backend: Test-Suite ausführen, Coverage prüfen
• Mobile Apps: iOS/Android-Simulator-MCPs zum Testen auf Gerät nutzen iteriert, bis der Code funktioniert und die UX sich gut anfühlt.

Investiere darin, Verifikation bombensicher zu machen. Es ist die einzelne Verbesserung mit dem höchsten Hebel, die du für AI-unterstützte Entwicklung machen kannst.

Der Full Stack: Alles zusammen

Hier ist Boris' komplettes Setup in einer Ansicht:

1. 15+ Parallele Sessions — Terminal, Web, iOS
2. Opus 4.5 + Extended Thinking — Bestes Modell, insgesamt schneller
3. Team CLAUDE.md — Geteilte Wissensbasis, versionskontrolliert
4. GitHub Action — Auto-Update CLAUDE.md aus PRs
5. Plan-Modus → Auto-Accept — Zwei-Phasen-Workflow
6. Slash-Kommandos — Wiederholte Workflows automatisieren
7. Subagents — Spezialisierte AI-Assistenten
8. PostToolUse Hook — Code automatisch formatieren
9. Intelligente Berechtigungen — Sichere Kommandos vorab erlauben
10. MCP-Integration — Verbindung zu Slack, BigQuery, Sentry
11. Ralph Wiggum — Iterative Schleifen für lange Tasks
12. Verifikation — Am wichtigsten: Feedback-Schleifen überall

Was das für den Rest von uns bedeutet

Die Reaktion auf Boris' Thread war… intensiv.

„Wenn du nicht die Claude Code Best Practices direkt von seinem Erfinder liest, bist du als Programmierer im Rückstand," schrieb ein Branchenbeobachter.

„Das ist potenziell ihr ChatGPT-Moment," erklärte ein anderer.

Die Aufregung entspringt einem Paradox: Boris' Workflow ist überraschend einfach, ermöglicht es aber einem einzelnen Menschen, mit der Output-Kapazität einer kleinen Engineering-Abteilung zu operieren.

In den letzten dreißig Tagen landete Boris 259 PRs — 497 Commits, 40k Zeilen hinzugefügt, 38k Zeilen entfernt. Jede einzelne Zeile wurde von Claude Code + Opus 4.5 geschrieben.

Das ist kein Workflow. Das ist ein Kraftmultiplikator.

Loslegen (ohne das Haus abzubrennen)

Du musst nicht alles auf einmal implementieren. Fang klein an:

1. Erstelle eine CLAUDE.md — Dokumentiere die Konventionen deines Projekts
2. Richte ein Slash-Kommando ein — Automatisiere etwas, was du täglich machst
3. Füge Verifikation hinzu — Gib Claude eine Möglichkeit, seine Arbeit zu testen
4. Konfiguriere Berechtigungen — Erlaube sichere Kommandos vorab
5. Füge einen Hook hinzu — Code beim Speichern automatisch formatieren

Dann iteriere. Füge mehr Slash-Kommandos hinzu, wenn Patterns entstehen. Erstelle Subagents für spezialisierte Tasks. Erweitere deine MCP-Integrationen.

Das Ziel ist nicht, Boris' Setup zu kopieren — es ist, deine eigene zusammengesetzte Lernmaschine zu bauen, die jeden Tag besser wird.

Die Fehlerrate, über die niemand spricht

Als gefragt wurde, welchen Prozentsatz der Sessions er abbricht, antwortete Boris: „Vielleicht so 10–20%?"

Selbst der Erfinder von Claude Code hat keine 100%ige Erfolgsrate. Manche Sessions funktionieren einfach nicht. Das ist normal. Die Produktivitätsgewinne kommen von den 80%, die es tun.

Abschließende Gedanken

Was Boris demonstriert hat, ist nicht nur ein Produktivitäts-Hack. Es ist ein Blick in ein völlig anderes Modell der Softwareentwicklung.

Jahrelang bedeutete „AI Coding" Autocomplete — eine schnellere Art zu tippen. Was Boris zeigt, ist, dass AI jetzt als Betriebssystem für Arbeit selbst funktionieren kann.

„Lies das, wenn du bereits Ingenieur bist und mehr Power willst," fasste ein Kommentator zusammen.

Die Tools, um menschlichen Output um das 5-fache zu multiplizieren, sind da. Sie erfordern nur die Bereitschaft, aufzuhören, AI als Assistenten zu betrachten, und anzufangen, es als Belegschaft zu behandeln.

Die Programmierer, die diesen mentalen Sprung zuerst machen, werden nicht nur produktiver sein. Sie werden ein völlig anderes Spiel spielen.

Und alle anderen werden immer noch tippen.

Ursprünglich basierend auf Boris Chernys Twitter-Thread. Boris ist der Erfinder und Leiter von Claude Code bei Anthropic.

Ressourcen

• Claude Code Dokumentation
• Slash Commands Referenz
• Subagents Guide
• Hooks Guide
• MCP Dokumentation
• Ralph Wiggum Plugin
• Claude Chrome Extension
• Boris' Config (Community Repo)

Falls dir diese Aufschlüsselung gefallen hat, klatsche 50 Mal und folge für mehr Deep Dives in AI-gestützte Entwicklung. Deine Dopamin-Rezeptoren werden es dir danken.

Wie man 15 KI-Agenten parallel betreibt, ohne den Überblick zu verlieren: Mein wöchentlicher Newsletter zeigt echte Produktions-Workflows von Entwicklern, die Grenzen verschieben.

→ Newsletter-Willkommenskit holen