Die ursprüngliche These war einfach: Manche Entwickler erbringen ungefähr zehnmal so viel Output wie ein durchschnittlicher Kollege. Ob dieses Verhältnis jemals messbar war oder nicht, KI-Tools haben verändert, woraus der Multiplikator besteht und wer ihn erreichen kann.
Woher die Idee stammt
Das Label „10x“ gibt es in der Softwaremythologie schon lange vor großen Sprachmodellen. Es beschrieb Engineers, die tiefes Wissen, schnelle Entscheidungen und die Fähigkeit verbanden, Sackgassen zu vermeiden. Der Vorteil war persönlich und vor allem kognitiv. Wer langsam tippte, aber das richtige mentale Modell hatte, lieferte trotzdem bessere Ergebnisse als jemand, der schnell tippte und mit dem falschen Modell arbeitete.
Die Belege hinter dem ursprünglichen Verhältnis waren dünn. Produktivitätsstudien aus den 1960er und 1980er Jahren zeigten große Unterschiede zwischen Programmierern, aber die Schätzungen variieren erheblich je nachdem, wie Output gemessen und welche Aufgabe verwendet wurde. Die Zahl Zehn blieb haften, weil sie einprägsam war, nicht weil sie präzise war.
Was sich verändert hat
KI-Coding-Tools, Agents und codekundige Assistenten übernehmen heute einen großen Teil der mechanischen Arbeit: Boilerplate, Test-Scaffolding, Dokumentation, Refactoring, die Suche in einer Codebasis. Das verringert den Abstand am unteren Ende. Ein durchschnittlicher Entwickler mit guten Tools arbeitet schneller als ein durchschnittlicher Entwickler ohne sie.
Der praktische Effekt ist, dass reine Tippgeschwindigkeit und Pattern-Recall weniger wichtig sind. Was Entwickler nach wie vor unterscheidet, ist die Qualität ihres Urteilsvermögens: zu wissen, welchem Output man vertrauen kann, welchen man ablehnen sollte und welches Problem von vornherein falsch spezifiziert war. Ein AI-native Engineer ist nicht einfach schneller bei bestehenden Aufgaben; er strukturiert um, welche Aufgaben überhaupt erledigt werden müssen.
Wo der Multiplikator heute liegt
Einige Kategorien von Fähigkeiten sind mit zunehmend besseren Tools wertvoller geworden, nicht weniger:
- Qualität der Spezifikation. KI-Modelle erzeugen Code proportional zur Klarheit der Eingabe. Entwickler, die eine vage Anforderung in eine präzise, testbare Beschreibung zerlegen können, holen aus ihren Tools weit mehr heraus als jene, die das nicht können. Das hängt direkt mit Context Engineering zusammen.
- Prüfung unter Druck. Generierter Code trifft schnell ein und liest sich flüssig. Den subtilen Logikfehler oder die falsche Annahme zu erkennen erfordert dieselbe Fähigkeit wie immer, nur schneller und häufiger angewendet. Siehe how to review AI-generated code.
- Systemdenken. Einzelne Funktionen zu generieren ist einfach. Zu entscheiden, wie Komponenten zusammenpassen, wo Fehlerfälle entstehen und was die Architektur in sechs Monaten an Änderungsaufwand kostet, bleibt eine menschliche Aufgabe.
- Wissen, wann Schluss ist. Zu viel zu bauen ist mit KI-Unterstützung eine neue Fehlerquelle. Wer zehn Abstraktionen erzeugt, wo zwei reichen, baut technische Schulden auf und vervielfacht niemandes Output.
Der Multiplikator ist jetzt eine Frage auf Teamebene
Eine Folge besserer Tools: Außergewöhnliche Wirkung lässt sich kaum noch einer einzelnen Person zuordnen. Ein Engineer, der den Output des ganzen Teams steigert, indem er Prompts verbessert, generierten Code wirksam reviewt oder ein Modell erwischt, das selbstsicher die falsche Antwort geliefert hat, schafft mehr Wert als jemand, der allein einfach schneller liefert.
Die ältere Version von 10x war individuell und größtenteils unsichtbar. Die aktuelle Version zeigt sich eher in der Qualität von Pull Requests, in der Häufigkeit von Vorfällen und darin, wie schnell ein Team einen falschen Weg korrigiert. Sie ist besser ablesbar, was einer der Gründe ist, warum die Einstellung entsprechender Talente gezielter geworden ist.
Was das in der Praxis bedeutet
Wenn Sie einstellen, lautet die Frage nicht mehr, wer den meisten Code produzieren kann. Es geht darum, wer das beste Urteilsvermögen pro Output-Einheit zeigt. Dazu gehört zu wissen, wann ein Modell falsch liegt, wann eine Spezifikation unvollständig ist und wann die einfache Lösung die richtige ist. How to assess an engineer's AI ability zeigt, wie diese Beurteilung aussieht.
Was wir prüfen
Das Auswahlverfahren von Miyagami ist um Urteilsvermögen herum aufgebaut. Kandidaten absolvieren zwei Sessions: ein Fundamentals-Assessment ohne KI-Tools und ein AI-native Assessment mit KI-Tools. Die Kriterien, die heute am besten auf echte Wirkung schließen lassen, sind das Urteilsvermögen nach Risiko, das keine der beiden Sessions auslässt, und Ownership, die alles nach dem Merge umfasst, egal ob ein Mensch oder ein Agent den Code geschrieben hat. Alle Details zu beiden Sessions und zu jedem bewerteten Kriterium finden Sie unter So prüfen wir.
Kurze Antworten
Ist die Idee des 10x Engineers noch glaubwürdig?
Der Produktivitätsunterschied zwischen Entwicklern ist real und dokumentiert, auch wenn das Verhältnis von zehn schon immer eine Annäherung war. KI-Tools haben verschoben, was den Unterschied antreibt: Urteilsvermögen und Systemdenken sind jetzt wichtiger als Geschwindigkeit oder Pattern-Recall.
Können KI-Tools jeden Entwickler zu einem 10x Engineer machen?
Tools heben das Mindestniveau für alle an, beseitigen den Abstand aber nicht. Entwickler mit stärkerem Urteilsvermögen holen mehr aus denselben Tools heraus, erkennen mehr Fehler im generierten Output und treffen bessere Architekturentscheidungen. Der Abstand bleibt bestehen, nur durch andere Fähigkeiten.
Wie erkennt man einen 10x Engineer im Vorstellungsgespräch?
Achten Sie darauf, wie Kandidaten mit Unklarheiten umgehen, generierten Code prüfen und Abwägungen erklären. Reine Coding-Geschwindigkeit ist ein schlechtes Signal. Strukturierte Aufgaben rund um unvollständige Spezifikationen und die Prüfung von KI-Output sind zuverlässiger. Siehe how-to-assess-an-engineers-ai-ability für einen praxisnahen Rahmen.
