Mein Erfolg lässt sich nicht kopieren

Diesen Beitrag anhören (12 Min.)

Im Februar fragte mich ein Kollege – erfahrener Entwickler, gutes Urteilsvermögen, kein Anfänger – ob er mein Setup haben kann. Er hatte über Wochen zugesehen, wie ich mit Claude Code arbeite, und wollte dasselbe: dieselben Werkzeuge, dieselbe Konfiguration, dieselben Ergebnisse. Ich habe ihm alles gegeben. Die komplette Werkzeugkette. Meine Instruktionsdateien, gewachsen über Monate. Meine Prompt-Sammlung für wiederkehrende Aufgaben, meine Checklisten für Reviews, sogar meine Notizen dazu, welche Aufgaben ich delegiere und welche nicht. Es gab keinen geheimen Rest. Er hatte wirklich alles, was ich habe.

Teil 5 der Serie „Von der Session zum System“ – hier geht es zum Auftakt.

Zwei Wochen später saßen wir beim Kaffee, und er war ernüchtert. Nicht frustriert im Sinne von „das Werkzeug taugt nichts“ – er hatte durchaus brauchbare Momente erlebt. Aber das, was er bei mir gesehen hatte, diese Selbstverständlichkeit, mit der Aufgaben rausgehen und geprüfte Ergebnisse zurückkommen, stellte sich bei ihm nicht ein. Bei ihm lief die KI dreimal in die falsche Richtung, baute Dinge, die er nicht wollte, und er verbrachte mehr Zeit mit Aufräumen als vorher mit Selberschreiben. Sein Satz ist mir geblieben: „Ich habe dein Setup. Warum habe ich nicht deine Ergebnisse?“

Die Frage hat mich länger beschäftigt als jedes Tool-Problem der letzten Monate. Denn die naheliegenden Antworten stimmen alle nicht. Es lag nicht am Modell – wir nutzten dasselbe. Nicht an der Konfiguration – sie war identisch, Datei für Datei. Nicht an mangelnder Erfahrung als Entwickler – er ist mindestens so gut wie ich. Was ihm fehlte, stand in keiner der Dateien, die ich ihm gegeben hatte. Und genau das ist der Punkt, an dem diese Serie den Sprung machen muss: vom Ich zum Team. Bisher habe ich beschrieben, warum der Harness mehr ausmacht als das Modell und was mir an meiner eigenen Arbeitsweise Unbehagen bereitet. Beides war die Perspektive eines Einzelnen. Sobald ein zweiter Mensch ins Spiel kommt, taucht ein Problem auf, das ich vorher nur geahnt hatte: Varianz. Und zwar gleich dreifach.

Erste Ebene: dieselbe Aufgabe, zwei Sessions, zwei Ergebnisse

Die erste Ebene hat noch gar nichts mit meinem Kollegen zu tun. Ich kann sie allein an meinem eigenen Rechner vorführen.

Ich gebe derselben KI dieselbe Aufgabe zweimal – unter weitgehend gleichen sichtbaren Bedingungen: gleicher Prompt, gleiches Repository, gleiche Instruktionsdateien. Session eins entscheidet sich, erst die Tests zu lesen, findet dort ein bestehendes Muster und erweitert es sauber. Session zwei springt direkt in den Produktionscode, hält eine Hilfsfunktion für unbenutzt, räumt sie „bei der Gelegenheit“ mit weg und liefert eine Lösung, die zwar läuft, aber anders geschnitten ist als alles Umliegende. Beide Sessions haben denselben Auftrag bekommen. Beide berichten selbstbewusst, sie seien fertig. Die Ergebnisse unterscheiden sich in Struktur, Stil und Nebenwirkungen.

In meinen Durchläufen unterschieden sich schon frühe Entscheidungen – etwa welche Datei zuerst gelesen wurde oder welches Muster als Vorbild diente. Danach liefen auch die weiteren Schritte auseinander.

Für mich allein ist das handhabbar. Ich habe gelernt, Ergebnisse zu prüfen statt Wege vorzuschreiben, und in Folge 3 habe ich beschrieben, wie viel davon der Harness abfängt: Tools, Feedback-Schleifen, Prüfschritte. Aber schon hier zeigt sich der Fehler, „Best Practices“ mit reproduzierbaren Ergebnissen zu verwechseln: Derselbe Erfolgsfall lässt sich nicht exakt wiederholen. Wenn ich meinem Kollegen zeige, wie großartig eine Session gestern lief, zeige ich ihm einen einzelnen Durchlauf – auch bei mir würde der nächste anders aussehen.

Zweite Ebene: das Wissen, das in keiner Datei steht

Die zweite Ebene ist die, an der mein Kollege tatsächlich gescheitert ist. Und sie ist unangenehmer, weil sie sich als Werkzeugfrage tarnt, aber eine Erfahrungsfrage ist.

Als wir seine ernüchternden zwei Wochen durchgesprochen haben, fiel mir auf: Er hat dieselben Dinge getan wie ich – nur an anderen Stellen. Er hat delegiert, aber die falschen Aufgaben. Er hat geprüft, aber das Falsche angeschaut. Er hat abgebrochen, aber zu spät. Drei Beispiele aus unserem Gespräch:

Er gab der KI eine Aufgabe, die ich nie im Ganzen delegieren würde – eine Änderung quer durch drei Module mit unklarer Fachlogik – und wunderte sich über das Chaos. Ich hätte sie vorher in drei prüfbare Häppchen geschnitten. Dieser Zuschnitt steht in keinem meiner Prompts, ich mache ihn im Kopf, bevor ich überhaupt tippe.
Er las die Erklärungen der KI und fand sie überzeugend. Ich lese die Erklärungen kaum noch – ich schaue auf das Diff, die Tests und die Stellen, an denen erfahrungsgemäß unerwünschte Nebenwirkungen auftreten. Wo man hinschaut, ist Urteilskraft, keine Konfiguration.
Er ließ eine Session dreimal nachbessern, ehe er aufgab. Ich breche nach dem ersten gescheiterten Nachbesserungsversuch ab und formuliere die Aufgabe neu, denn ich habe gelernt: Wenn die Richtung einmal falsch ist, wird Nachsteuern teurer als Neustarten. Auch das steht nirgends – diese Abbruchregel stammt aus wiederholten Fehlversuchen.

Aufgabenzuschnitt, Prüfblick, Abbruchinstinkt – das ist implizites Wissen im klassischen Sinn. Man erwirbt es durch Reibung, nicht durch Lektüre. Meine Instruktionsdateien sind das Sediment dieses Wissens, aber sie sind nicht das Wissen selbst. Sie sagen der KI, was sie tun soll. Sie sagen meinem Kollegen nicht, was er tun soll, während die KI arbeitet.

Die METR-Studie vom Sommer 2025 hat einen verwandten Effekt messbar gemacht: Bei erfahrenen Open-Source-Entwicklern dauerten Aufgaben mit frühen 2025er-KI-Werkzeugen im Mittel 19 Prozent länger – obwohl die Teilnehmenden einen Zeitgewinn erwarteten. Man kann über die Übertragbarkeit der Studie streiten, die Bedingungen waren speziell. Aber der belegte Befund passt zu dem, was ich bei meinem Kollegen gesehen habe: Erwarteter Zeitgewinn und gemessene Bearbeitungszeit können auseinanderliegen.

Dritte Ebene: es gibt keinen identischen Durchlauf

Die dritte Ebene wird gern übersehen, weil sie so banal klingt: Mein Kollege arbeitet an anderen Aufgaben als ich.

Nicht grundsätzlich anders – gleiche Firma, verwandte Systeme, ähnlicher Stack. Aber seine konkrete Aufgabe an einem konkreten Dienstag ist nie meine konkrete Aufgabe. Sein Modul hat eine andere Geschichte, andere Altlasten, andere ungeschriebene Konventionen. Seine Bugs sitzen an anderen Stellen. Selbst wenn er meine Urteilskraft hätte und die Session-Lotterie zu seinen Gunsten ausginge: Er könnte meinen Erfolg trotzdem nicht reproduzieren, weil es den Versuchsaufbau „gleiche Aufgabe“ in echter Arbeit schlicht nicht gibt.

Das unterscheidet KI-Werkzeuge fundamental von fast allem, was wir vorher im Team eingeführt haben. Formatter und CI-Pipelines zielen unter gleicher Version, Konfiguration und Umgebung auf reproduzierbare Ausführung; eine Framework-API stellt denselben Vertrag bereit. Bei diesen Werkzeugen gilt: Einer findet die gute Konfiguration, alle übernehmen sie, alle haben den Nutzen. Genau dieses Muster haben wir alle im Kopf, wenn wir „Setup teilen“ sagen – und genau dieses Muster greift hier nicht. Der Nutzen einer KI-Session entsteht aus dem Zusammenspiel von Aufgabe, Kontext, Person und Zufall. Drei dieser vier Faktoren sind bei jedem Teammitglied andere.

Was Organisationen daraus regelmäßig falsch schließen

Auf Organisationsebene können diese Unterschiede zu falschen Produktivitätsannahmen führen. Denn aus der Einzelbeobachtung „bei Mike funktioniert das“ liegen drei Fehlschlüsse nahe.

Der erste Fehlschluss: Lizenz gekauft heißt Team produktiv. Ein Konzern beschafft für alle Entwickler Zugänge, verbucht das als „KI-Adoption“ und erwartet den Produktivitätssprung, den die Power-User im Pilotprojekt gezeigt haben. Aber die Power-User waren ja gerade deshalb schnell, weil sie über Monate implizites Wissen aufgebaut haben. Die Lizenz kauft das Werkzeug, nicht die zweite Ebene. Der DORA-Report 2025 bringt es auf eine Formel, die ich seither ständig zitiere: KI verstärkt, was da ist. Teams mit guten Feedback-Schleifen und sauberer Architektur werden besser, Teams mit schwachen Prozessen bekommen ihre Schwächen verstärkt zurück.

Der zweite Fehlschluss: Prompt-Bibliothek teilen ist ein Rollout. Das war mein eigener Irrtum mit dem Kollegen, nur in klein. Prompts und Instruktionsdateien sind Sediment – nützlich, aber tot ohne die Praxis, aus der sie entstanden sind. Eine geteilte Prompt-Sammlung ohne geteilte Urteilskraft produziert Leute, die überzeugende Erklärungen lesen statt Diffs zu prüfen. Die Stack-Overflow-Umfrage 2025 zeigt die Folgen im Großen: KI-Werkzeuge werden breit genutzt, aber das Vertrauen bleibt begrenzt, und eine häufig genannte Frustration ist Code, der „fast richtig“ ist. Fast richtig zu erkennen ist exakt die Fähigkeit, die sich nicht allein per Datei verteilen lässt.

Der dritte Fehlschluss: Was beim Piloten klappt, skaliert linear. Tut es nicht, wegen aller drei Varianz-Ebenen gleichzeitig. Ein Pilot kann motivierte Power-User enthalten (Personen-Varianz), ausgewählte, gut schneidbare Aufgaben (Aufgaben-Varianz) und selektiv berichtete Erfolgsgeschichten – missratene Sessions können in der Management-Präsentation fehlen (Session-Varianz). Wer daraus eine Hochrechnung für 200 Entwickler baut, kann mit einem nicht repräsentativen Durchschnitt rechnen.

Ich formuliere es zugespitzt, weil ich den Satz in Folge 4 schon einmal gebraucht habe und er hier die organisatorische Konsequenz beschreibt: Die Erfolgsgeschichten der Einzelnen sind echt, und sie sind trotzdem kein Bauplan. Werkzeuge, Tests, Konventionen und Abnahmekriterien lassen sich kopieren. Mein konkretes Ergebnis entsteht zusätzlich aus Aufgabe, Kontext, Prüfblick und Sessionverlauf. Diesen Teil überträgt keine Setup-Datei.

Die Varianz ist auch eine Lernquelle

Das klingt jetzt düsterer, als ich es meine. Denn dieselbe Varianz, die das Kopieren verhindert, ist eine brauchbare Diagnosequelle für ein Team.

Als mein Kollege und ich seine zwei Wochen seziert haben, ist etwas Bemerkenswertes passiert: Ich musste zum ersten Mal aussprechen, warum ich Aufgaben so schneide, wie ich sie schneide. Warum ich Erklärungen ignoriere und Diffs lese. Warum ich nach einem gescheiterten Nachbesserungsversuch abbreche. Das war implizites Wissen, das ich selbst nicht als Wissen wahrgenommen hatte – für mich war es einfach „wie man das halt macht“. Erst der Unterschied zwischen seiner Arbeitsweise und meiner hat es sichtbar gemacht. Genau dort, wo zwei Leute dasselbe verschieden machen, liegt das implizite Wissen offen zutage. Man muss nur hinschauen, statt die Differenz als Versagen des Langsameren abzutun.

Meine Schlussfolgerung nach diesem Februar: Wenn Einzelerfahrungen im Team zusammenfließen sollen, sind nicht die Prompts das Wertvolle. Es sind die Unterschiede. Zwei Entwickler, dieselbe Aufgabenklasse, verschiedene Ergebnisse – das ist kein Ärgernis, das ist ein Befund. Jede dieser Differenzen zeigt auf eine unausgesprochene Regel, eine Heuristik, ein Stück Urteilskraft, das bislang nur in einem Kopf existierte.

Mein Kollege arbeitet übrigens weiter mit dem Setup – inzwischen mit eigenen Instruktionsdateien, die sich von meinen zunehmend unterscheiden, und mit deutlich besseren Ergebnissen. Nicht weil er mich jetzt besser kopiert, sondern weil er aufgehört hat, es zu versuchen. Was er von mir übernommen hat, sind nicht die Dateien. Es sind die Fragen, die er sich vor jeder Delegation stellt.

Und damit stehe ich vor der Konsequenz, die sich jedes Team an dieser Stelle vornimmt, meines eingeschlossen: Wenn das entscheidende Wissen implizit ist, dann machen wir es eben explizit. Wir setzen uns hin, sprechen die Regeln aus, die bisher nur in Köpfen existierten, und schreiben sie auf – in genau die Dateien, die die KI bei jeder Session liest. Aufgabenzuschnitt, Prüfregeln, Abbruchkriterien, alles rein. Das muss doch reichen. Warum es das nicht tut – und warum die KI sich an unsere sorgfältig aufgeschriebenen Regeln erstaunlich selektiv hält – davon handelt die nächste Folge.

Weiterführende Quellen

Wie fandest du diesen Beitrag?