In den letzten Monaten habe ich eine Lawine von „ultimativen Prompts" für Claude Code gesehen, Sammlungen von 30 unverzichtbaren MCPs und Skills, die man angeblich installieren „muss", um mit KI produktiv zu sein. Ich wollte die Gegenthese an meinen eigenen Daten prüfen: Man braucht nichts davon. Man muss die KI genauso behandeln wie ein Team von Ingenieuren.
Also habe ich etwas leicht Meta-Artiges getan: Ich habe Claude Code gebeten, die eigene Historie zu lesen. Jede Claude-Code-Sitzung wird lokal als JSONL in ~/.claude/projects/ gespeichert. Ich habe die KI den kompletten Juli parsen lassen — jeden Prompt, den ich geschrieben habe, jeden Tool-Aufruf, jeden Fehler — und mich bewerten lassen. Ohne Schonung.
Das Ergebnis: 107 Sitzungen in 22 Arbeitstagen, 599 echte Prompts, 14.608 Tool-Aufrufe, 312 MB Transkript. Die Arbeit eines einzigen Menschen — meine — für den Hauptkunden der Firma, ein E-Commerce-Produkt aus den USA, plus die internen Projekte.
Das kurze Urteil: Die Strategie funktioniert. Hier sind die Zahlen, die Prinzipien dahinter und — weil ein Audit, das nur Gutes findet, kein Audit ist — die Stellen, an denen ich genauso danebenliege wie ein schlechter Manager.
Die Zahlen, auf die es ankommt
Von 107 Sitzungen wurden rund 95% mit geliefertem und verifiziertem Ergebnis abgeschlossen — Commit, Deploy, Prüfung auf der echten Umgebung, Ticket weitergezogen. Nur 4-5 Sitzungen wurden wirklich abgebrochen, die meisten aus banalen Gründen (eine, weil ich sie glorreich im falschen Projekt gestartet habe).
Die Korrekturquote — wie oft ich „geht nicht", „falsch", „mach neu" sagen musste — lag bei 8% aller Folgenachrichten. Das absolute Maximum in einer einzelnen Sitzung: 4 Korrekturen. Null Frustrationsschleifen, null Sitzungen, in denen die KI mich im Kreis geführt hat. Dieses Narrativ existiert, aber nicht in meinen Daten.
Und vielleicht meine Lieblingszahl, weil sie nicht von KI handelt, sondern vom Leben: Dieser ganze Monat fand zwischen 9 und 19 Uhr statt, null Sitzungen am Wochenende, zwei Sitzungen nach 21 Uhr im gesamten Monat. Der Output eines kleinen Teams, geliefert von einem Menschen, in einem normalen Arbeitsrhythmus.
Woher kommen diese Ergebnisse? Nicht von speziellen Prompts. Von drei Prinzipien, die jeder erfahrene Ingenieur bereits kennt — weil es die Prinzipien sind, mit denen man mit Menschen arbeitet.
Prinzip 1: Ein guter Prompt ist ein gutes Ticket
Die deutlichste Erkenntnis des Audits betrifft Länge und Struktur der ersten Nachricht einer Sitzung. Die Verteilung ist bimodal, und der Unterschied im Ergebnis ist brutal:
- Prompts unter 120 Zeichen — die Sorte „schauen wir uns das auch noch an" — haben systematisch 2-4 Rückfrage-Runden und blinde Tool-Aufrufe erzeugt, bei denen die KI rät, was ich will.
- Prompts über 700 Zeichen — 19 im ganzen Monat — hatten im Median einen einzigen Prompt pro erledigtem Task. Du schreibst die Spezifikation, du gehst weg, der Task ist fertig.
Was haben diese 19 gemeinsam? Keine Zauberformel. Sie haben exakt die Struktur eines gut geschriebenen Tickets: Datei und Zeile, aktuelles Verhalten, ein konkreter Beleg (eine Bestellnummer, eine Request-ID, eine Logzeile), gewünschtes Verhalten und das Abnahmekriterium. Der effizienteste Task des Monats — ein Bug mit verlorenen E-Mails in einem Lambda-Handler — wurde aus einem einzigen Prompt von ~900 Zeichen gelöst, der all das enthielt: ein Prompt, 75 Tool-Aufrufe, null Korrekturen, Fix in der Produktion.
Umgekehrt begann der teuerste Vorfall des Monats mit einem undefinierten „hier": Ich habe eine Änderung „hier" verlangt, die KI verstand „überall", aktualisierte sämtliche Datensätze in der Produktion, und ein paar Runden später habe ich im Chat zugegeben: „Ich habe die Spezifikation selbst falsch gelesen." Bei einem menschlichen Ingenieur hätte dasselbe vage Ticket denselben Schaden angerichtet — nur hätte ich es beim Demo erfahren, nicht nach zehn Minuten.
Destilliert ist die Regel, die ich ab jetzt anwende, drei Zeilen lang, nicht 700 Zeichen:
WO: exakte Datei / Seite / URL — nicht „hier", nicht „das"
JETZT: was passiert + ein Beleg — ID, Log, Screenshot
WILL: das Abnahmekriterium — woran wir erkennen, dass es fertig ist
Das ist kein Prompt Engineering. Das ist, was ein Lead seit 15 Jahren von jedem Ticket verlangt. Die Fähigkeit existiert bereits in der Branche; sie muss nur auch auf die Maschine angewendet werden.
Prinzip 2: Minimaler Prozess, keine Tool-Sammlung
Mein „AI-Tooling"-Stack ist peinlich kurz: das Terminal, ein über das Chrome-MCP gesteuerter Browser und der Task-Tracker. Das war's. Ich habe keine 15 MCPs installiert, keine Bibliothek von GitHub heruntergeladener Skills. Ich habe über meinen Claude-Code-Workflow im Terminal geschrieben, und im Kern hat sich seitdem fast nichts geändert.
Die Daten bestätigen, dass nichts fehlt: 50% aller Tool-Aufrufe im Juli sind schlichtes Bash — grep, git, curl, cat. Die KI arbeitet mit denselben primitiven Werkzeugen wie jeder Ingenieur im Terminal, und das genügt.
Das einzige MCP, das wirklich zählt, ist der Browser — nicht weil er ausgefeilt wäre, sondern wegen seiner Rolle im Prozess: Verifikation auf der echten Umgebung. Die Anweisung, die in meinen Sitzungen zwanghaft auftaucht, lautet „prüf es mit Chrome auf der echten Umgebung, nicht in der Vorschau". Das Audit identifiziert sie als den direkten Grund für die Abschlussquote von 95%: Nichts gilt als fertig, bevor es dort funktionierend gesehen wurde, wo es tatsächlich läuft.
Anders gesagt: Es fehlen dir keine Tools. Dir fehlt eine „Definition of Done", die du ausnahmslos anwendest.
Prinzip 3: Behandle die KI wie ein Team von Ingenieuren
Hier liegt der Kern. Wenn ich auf meine eigenen Sitzungen schaue, ist alles, was funktioniert, eine alte Praxis der Teamführung, angewendet auf ein „Team", das in Sekunden antwortet:
Design Review vor dem Code. „Mach mir einen Implementierungsplan und sag mir Bescheid" taucht in ~20 Sitzungen im Juli auf. Anzahl der Korrekturen in diesen Sitzungen: null. Kein Zufall — es ist derselbe Grund, aus dem man einen neuen Kollegen nicht in einem unbekannten System Code schreiben lässt, bevor man den Ansatz besprochen hat.
Begrenzter Zugriff, bis das Problem verstanden ist. „READ-ONLY, wir analysieren nur, wir ändern nichts" — systematisch bei Untersuchungen eingesetzt. Produktionsunfälle durch Analysesitzungen: null.
Review, bevor irgendetwas nach außen geht. „Zeig mir den Kommentar, bevor du ihn ins Ticket postest." Genau das, was man von einem Junior verlangt, bevor er dem Kunden antwortet.
Deploy-Disziplin. Commit → Push → Build → Prüfung auf der echten Umgebung → Ticket mit einem kurzen Kommentar nach Verify verschoben. Konsistent in ~60 Ticket-Sitzungen wiederholt.
Und die interessanteste Erkenntnis des Audits, die mich am meisten amüsiert hat: die besten Prompts des Julis habe nicht ich geschrieben. Die Maschine hat sie geschrieben. Wenn eine Sitzung einen Task an eine neue Sitzung delegiert (durch Spawnen von Tasks in separaten Worktrees), hat die automatisch erzeugte Spezifikation im Median ~900 Zeichen und die vollständige Ticket-Struktur — und diese 12 delegierten Sitzungen wurden alle mit einem Median von einem Prompt pro Task abgeschlossen. Die KI hat das Format aus meinem Prozess gelernt und wendet es disziplinierter an als ich. Das untergräbt meine These nicht — es bestätigt sie: Übertragbar ist der Prozess, nicht irgendein „Prompter"-Talent.
Wo ich danebenliege — und warum das beruhigend ist
Ein Audit, das nichts Schlechtes findet, ist Propaganda. Meines hat genug gefunden, und der wirklich beruhigende Teil ist, dass alle meine Fehler mit der KI klassische Fehler der Menschenführung sind:
Mikromanagement. 31% meiner Runden haben weniger als 3 Tool-Aufrufe — also ist ein Drittel der Interaktionen „mach genau diesen kleinen Schritt". Ich habe dieselbe Prozessanweisung („wenn du fertig bist, commit, push, build, verifizieren") über 25 Mal in einem Monat wiederholt, statt sie einmal in CLAUDE.md zu schreiben — das Äquivalent eines einmal geschriebenen Onboardings, nicht bei jedem Task neu aufgesagt. Währenddessen wurde echte Delegation (Agenten, gespawnte Tasks) nur 34 Mal in 107 Sitzungen genutzt.
Vage Tickets. „hamm wir das?" — 14 Zeichen, Tippfehler inklusive — hat 156 Tool-Aufrufe erzeugt, in denen die KI selbst gesucht hat, was ich meinte. Sie hat es gefunden, aber ich habe mit Zeit und Tokens bezahlt. Bei einem Menschen hätte dieselbe Slack-Nachricht ein „worauf beziehst du dich?" und zehn verlorene Minuten erzeugt.
Marathon-Meetings. Eine Sitzung vom 13. Juli: 15 verschiedene Tickets, 41 Prompts, 547 Tool-Aufrufe, fast 18 MB Kontext. Bei Ticket 12 ist der Kontext der ersten 11 reiner Ballast — das Audit zeigt, dass 17% der Datei-Lesevorgänge im Juli erneute Lesevorgänge derselben Datei in derselben Sitzung sind, ein direktes Zeichen für aufgeblähten Kontext. Die richtige Regel ist dieselbe wie bei Menschen: ein Thema, ein Meeting. Ein Ticket, eine Sitzung.
Teure Verifikation. 1.405 Browser-Screenshots in einem Monat — 41% des gesamten Datenvolumens der Sitzungen — von denen die meisten Text „gelesen" haben, der zehnmal billiger aus dem DOM hätte extrahiert werden können. In einer einzigen Sitzung: 127 Screenshots. Die Lektion, ebenso gültig für Berichte, die man von Menschen verlangt: Fordere das billigste Format, das die Frage beantwortet.
Klarstellung: automatisiert bleibt es — nur der Kanal ändert sich
Nach der Veröffentlichung kam eine berechtigte Frage: „Bedeutet die Screenshot-Empfehlung mehr manuelle Verifikation?" Nein — und das gehört ausdrücklich gesagt, weil die Unterscheidung leicht zu übersehen ist.
Die automatisierte Verifikation auf der echten Umgebung steht nicht zur Debatte: Sie ist der direkte Grund für die Abschlussquote von 95% und genau das, was mir erlaubt, einen Task zu delegieren und wegzugehen. Die Empfehlung betrifft nur den Kanal. Ein Screenshot und ein Auslesen des DOM (read_page, Konsole, Netzwerk) sind gleichermaßen automatisiert — sie kosten nur unterschiedlich. Wenn die Prüfung eigentlich textuell ist („Meldung X erscheint", „der Request liefert 200"), beantwortet das DOM dieselbe Frage mit einem Bruchteil des Kontexts. Screenshots bleiben für das, was Augen braucht: Layout, Bilder, Styling.
Und der kontraintuitive Teil: Aufgeblähter Kontext ist der Feind der Parallelität, nicht ihr Freund. Eine Sitzung mit 127 Screenshots füllt ihr Fenster, beginnt Dateien erneut zu lesen (daher die 17% Mehrfach-Lesevorgänge) und stirbt früher. Dieselbe Sitzung, die dort verifiziert, wo es über das DOM geht, lebt länger und lässt Raum, mehr Sitzungen parallel laufen zu lassen. Du verifizierst genauso viel, genauso automatisch — du zahlst den Bildpreis nur dort, wo ein Bild tatsächlich etwas sieht.
Keines dieser Probleme lautet „die KI halluziniert" oder „die KI kann es nicht". Alle handeln davon, wie ich sie führe. Der einzige Unterschied zu einem Team aus Menschen ist die Geschwindigkeit der Feedbackschleife: Meine Führungsfehler zeigen sich in Minuten, nicht erst nach einem Sprint. Was, wenn man darüber nachdenkt, der schnellste Management-Kurs ist, den ich je gemacht habe.
Was ich im August ändere
Das Audit endete mit fünf konkreten Maßnahmen, die ich hier hinterlasse, weil sie für jeden gelten:
- Wiederholte Prozesse kommen in CLAUDE.md, nicht in den Prompt. Einmal geschrieben, immer angewendet, ohne zufällige Abweichungen.
- Die Drei-Zeilen-Regel (WO / JETZT / WILL) für jeden ersten Prompt. Kein „hier", kein „das".
- Ein Ticket = eine Sitzung. Und der umgekehrte Schluss: vier kleine verwandte Tasks sind ein Prompt mit einer Liste, nicht vier Sitzungen.
- Das Repo explizit in der ersten Zeile des Prompts — ich hatte 11 Sitzungen, die im falschen Verzeichnis gestartet wurden, eine davon deswegen komplett verloren.
- Screenshots nur für das, was man mit den Augen prüft (Layout, Kontrast, Bilder). Für Text und Struktur ist die Extraktion aus der Seite zehnmal billiger. Sicherheitsbonus: niemals Screenshots von Admin-Oberflächen mit Geheimnissen.
In einem Monat lasse ich dasselbe Audit über den August laufen und wir sehen, ob sich die Zahlen bewegen. Das ist am Ende der Vorteil daran, dass alles geloggt wird: Die Führung deines KI-Teams ist die erste Führung der Geschichte, die vollständig messbar ist.
Wie immer mein Disclaimer: Ich glaube, dass KI die Zukunft unseres Berufs ist und dass die heutigen Probleme — der aufgeblähte Kontext, die teure Verifikation, der Bedarf an Aufsicht — gelöst werden. Aber der aktuelle Stand verdient es, genau so besprochen zu werden, wie er ist: mit Daten, nicht mit Begeisterung oder Panik. Die Zahlen in diesem Artikel stammen aus dem Audit meiner eigenen Claude-Code-Sitzungen im Juli 2026; die Methode ist im Artikel beschrieben und kann von jedem repliziert werden, der ein Verzeichnis ~/.claude/projects/ und eine freie Stunde hat.