# Mein Erfolg lässt sich nicht kopieren

URL: https://www.mikebild.dev/de/blog/mein-erfolg-laesst-sich-nicht-kopieren/

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](https://www.mikebild.dev/de/blog/von-der-session-zum-system-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](https://www.mikebild.dev/de/blog/harness-macht-den-unterschied/) und [was mir an meiner eigenen Arbeitsweise Unbehagen bereitet](https://www.mikebild.dev/de/blog/was-ich-kritisch-sehe/). 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

Fangen wir bei der Ebene an, die noch gar nichts mit meinem Kollegen zu tun hat. Ich kann sie allein an meinem eigenen Rechner vorführen.

Ich gebe derselben KI dieselbe Aufgabe zweimal – 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.

Das ist keine Fehlfunktion, das ist die Natur der Sache. Diese Systeme arbeiten nicht deterministisch, und die Abweichungen summieren sich: Eine früh getroffene kleine Entscheidung – welche Datei zuerst gelesen wird, welches Muster als Vorbild dient – lenkt alles Weitere. Wer je zwei Wanderer mit derselben Wegbeschreibung losgeschickt hat, kennt das Prinzip: Eine einzige andere Abzweigung am Anfang, und sie kommen an verschiedenen Orten an.

Für mich allein ist das handhabbar. Ich habe gelernt, Ergebnisse zu prüfen statt Wege vorzuschreiben, und in [Folge 3](https://www.mikebild.dev/de/blog/harness-macht-den-unterschied/) habe ich beschrieben, wie viel davon der Harness abfängt: Werkzeuge, Feedback-Schleifen, Prüfschritte. Aber schon hier gerät jeder ins Rutschen, der „Best Practices" verteilen will: Selbst der Erfolgsfall lässt sich nicht wiederholen. Wenn ich meinem Kollegen zeige, wie großartig eine Session gestern lief, zeige ich ihm einen Durchlauf, den es so nie wieder geben wird – nicht einmal bei mir.

## 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äß gepfuscht wird. 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 – es ist eine Abbruchheuristik aus dutzenden verbrannten Stunden.

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](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) hat einen verwandten Effekt messbar gemacht: Erfahrene Open-Source-Entwickler waren mit KI-Unterstützung im Schnitt 19 Prozent *langsamer* – und glaubten hinterher trotzdem, schneller gewesen zu sein. Man kann über die Übertragbarkeit der Studie streiten, die Bedingungen waren speziell. Aber die Kernbotschaft passt exakt zu dem, was ich bei meinem Kollegen gesehen habe: Das Gefühl von Produktivität und die tatsächliche Produktivität gehen auseinander, und der Unterschied zwischen beiden liegt nicht im Werkzeug, sondern in der Person, die es bedient – in ihrer Fähigkeit, den eigenen Arbeitsfluss ehrlich zu beurteilen.

## 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. Ein Formatter verhält sich bei jedem gleich. Eine CI-Pipeline läuft für jeden gleich. Ein Framework hat für jeden dieselbe API. 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 im Zusammenspiel aus Aufgabe, Kontext, Person und Zufall. Drei dieser vier Faktoren sind bei jedem Teammitglied andere.

## Was Organisationen daraus regelmäßig falsch schließen

Jetzt wird es teuer. Denn aus der Einzelbeobachtung „bei Mike funktioniert das" werden in Organisationen verlässlich drei Fehlschlüsse gezogen, und ich habe alle drei in freier Wildbahn gesehen – in Gesprächen mit anderen Teams, auf Konferenzfluren, in Strategiefolien.

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](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) 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 beschleunigt zurück – mehr Durchsatz, weniger Stabilität.

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](https://survey.stackoverflow.co/2025/ai/) zeigt die Folgen im Großen: 84 Prozent der Entwickler nutzen KI-Werkzeuge, aber das Vertrauen sinkt, und die meistgenannte Frustration ist Code, der „fast richtig" ist. Fast richtig zu erkennen ist exakt die Fähigkeit, die sich nicht per Datei verteilen lässt.

Der dritte Fehlschluss: Was beim Piloten klappt, skaliert linear. Tut es nicht, wegen aller drei Varianz-Ebenen gleichzeitig. Der Pilot hatte motivierte Power-User (Personen-Varianz), ausgewählte, gut schneidbare Aufgaben (Aufgaben-Varianz) und die stille Auslese der Erfolgsgeschichten – die missratenen Sessions schaffen es selten in die Management-Präsentation (Session-Varianz). Wer daraus eine Hochrechnung für 200 Entwickler baut, rechnet mit einem Durchschnitt, den es nie gab.

Ich formuliere es zugespitzt, weil ich den Satz in [Folge 4](https://www.mikebild.dev/de/blog/was-ich-kritisch-sehe/) schon einmal gebraucht habe und er hier erst richtig zündet: Die Erfolgsgeschichten der Einzelnen sind echt, und sie sind trotzdem kein Bauplan. Mein Erfolg ist keine Eigenschaft meines Setups. Er ist eine Eigenschaft von mir mit meinem Setup an meinen Aufgaben – und davon lässt sich nur der kleinste Teil kopieren.

## Die Varianz ist auch eine Lernquelle

Das klingt jetzt düsterer, als ich es meine. Denn dieselbe Varianz, die das Kopieren verhindert, ist das ehrlichste Diagnosewerkzeug, das ein Team bekommen kann.

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.

Ethan Mollick hat früh dafür geworben, [KI-Einführung als Gemeinschaftsaufgabe zu denken](https://www.oneusefulthing.org/p/innovation-through-prompting) – jeder Nutzer ist faktisch in einer Forschungsrolle, und Organisationen brauchen Orte, an denen diese Einzelerfahrungen zusammenfließen. Meine Ergänzung nach diesem Februar: Nicht die Prompts sind das Wertvolle, das dort zusammenfließt. 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

- [METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
- [Google Cloud: Announcing the 2025 DORA Report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
- [Stack Overflow Developer Survey 2025: AI](https://survey.stackoverflow.co/2025/ai/)
- [Ethan Mollick: Innovation through Prompting](https://www.oneusefulthing.org/p/innovation-through-prompting)