Vierzig Jahre lang war der 10X-Engineer ein Argument, keine Beobachtung. Studien stellten zehnfache Unterschiede zwischen Programmierern bei derselben Aufgabe fest, die Methodik wurde jahrzehntelang diskutiert, und der Begriff wurde größtenteils zu einer Umschreibung für „stellen Sie Leute wie mich ein“. Alle stritten darüber, ob diese Person existiert, aber alle waren sich einig, was gemessen werden sollte: Output.
Setzen Sie drei Engineers auf dasselbe Backlog an und beobachten Sie sie einen Vormittag lang. Der erste nutzt KI überhaupt nicht. Ein guter Engineer, liest alles selbst, schreibt alles selbst. Der zweite hat einen Agenten in einem Fenster offen: Prompt eingeben, warten, lesen, erneut prompten. Der dritte hat vier Git-Worktrees offen, in jedem einen Agenten: einer arbeitet an einem Feature, einer an einem Bug, einer reviewed einen Pull Request, einer schreibt End-to-End-Tests, und der dritte wechselt zwischen ihnen und prüft, was jeder produziert hat. Bis zum Mittag hat der dritte erledigt, woran der erste bis Donnerstag sitzen wird.
Der nächste 10X-Engineer ist der dritte. Was er tut: Er nimmt ein vages Ticket, macht daraus eine ausgelieferte Änderung, für die er geradestehen kann, und setzt Agenten ein, um den Teil zu komprimieren, der früher reines Tippen war. Zwei Fähigkeiten machen das möglich: die Grundlagen, die schon immer gefragt waren, und Agent-Skills, die es vor drei Jahren noch nicht gab.
Das Offensichtliche muss ebenfalls ausgesprochen werden, und das Whitepaper, auf dem dieser Artikel basiert, formuliert es klar: KI hat manche Entwickler schlechter gemacht. Der zweite Entwickler in der Szene vom Morgen produziert mehr als noch vor zwei Jahren und versteht dabei manchmal weniger davon.
Die Zahlen dahinter stammen aus unserer eigenen Projektarbeit. Bei Miyagami-Projekten werden heute 80 bis 90 Prozent des Produktionscodes von einem Modell geschrieben, und ein Projekt, das 2024 noch zehn Entwickler benötigte, läuft heute mit vier Entwicklern. Dazu sind wir nicht durch ein Pilotprojekt gelangt, es ist das Ergebnis von zwei Jahren Kundenprojekten, und genau deshalb ist es heute wichtiger denn je, die richtigen Entwickler einzustellen. Wenn vier Personen das leisten, was zehn geleistet haben, ist eine Fehlbesetzung kein vernachlässigbarer Fehler mehr.
Wie sieht die Arbeit aus, wenn Codezeilen günstig sind? Vor drei Jahren bestand der Alltag eines erfahrenen Engineers darin, ein Ticket auszuwählen, den Code zu schreiben, einen Test zu schreiben, einen PR zu öffnen, und dann weiter zum nächsten Ticket, die meiste Zeit floss ins manuelle Schreiben von Code. Heute werden Tickets in einen Plan aufgeteilt, der Plan in Teilaufgaben, die jeweils klein genug sind, damit jeder PR in einer Sitzung lesbar bleibt, und diese Teilaufgaben werden parallel an Agenten übergeben. Die Zeit fließt in Entscheidungen darüber, was gebaut werden soll, in die Bereitstellung des richtigen Kontexts für den Agenten und in die Sicherstellung, dass das Ergebnis auslieferungsreif ist. Ein Agent baut, was man ihm gibt, eine Lücke im Input zeigt sich im Output innerhalb einer Stunde: Eine unklare Anforderung kommt als etwas zurück, das überzeugend, plausibel und auf einer Annahme aufgebaut ist; fehlender Kontext führt zu falschen Annahmen über das System; schwache Tests lassen generierten Code passieren, während sie das Verhalten, das sie nie abgedeckt haben, stillschweigend brechen.
Diese Neubewertung erklärt auch, warum der zweite Engineer aus der Vormittagsszene nicht die Antwort ist, und der Unterschied ist wichtig genug, um ihn klar zu benennen. Ein AI-native Engineer, wie wir den Begriff verwenden, ist ein Full-Stack-Entwickler mit soliden Grundlagen in Code-Qualität, Systemdesign und Sicherheit, der Coding-Agenten anleitet, wie sie Output erzeugen sollen, und diesen Output validiert, bevor er ausgeliefert wird. Die Grundlagen stehen in diesem Satz nicht zufällig an erster Stelle: Wer ohne den Agenten nicht über das System nachdenken kann, merkt auch nicht, wenn der Agent falsch liegt. Und wer den Code nicht richtig reviewen kann, wird durch den Agenten nicht zum Senior. Er wird nur schneller darin, Dinge zu produzieren, die er nicht versteht. Ein AI-native Engineer ist kein Prompter, jemand, der einen Agenten so bedient wie ein Suchfeld: ein Fenster, eine Anfrage nach der anderen, akzeptieren und weiter zum nächsten Prompt.
Das Unbequeme für Engineering-Leads ist, dass dieser Unterschied überall unsichtbar ist, wo Hiring normalerweise hinschaut. Er steht nicht im Lebenslauf, weil inzwischen jeder „AI“ im Lebenslauf stehen hat. Er zeigt sich nicht in der Take-home-Aufgabe, weil beide Abgaben vom Modell geschrieben wurden und auf dem Bildschirm identisch aussehen. Er zeigt sich nicht in einem Gespräch über Tooling, weil der Prompter dieselben Artikel gelesen hat wie Sie. Der Unterschied wird innerhalb weniger Minuten sichtbar, wenn man jemandem beim Arbeiten in einer echten Codebase zuschaut, und genau das lassen die meisten Interview-Prozesse nie zu.
Wir haben The Next 10X Engineer geschrieben, weil wir dieses Gespräch immer wieder geführt haben, einen CTO nach dem anderen. Das Paper beschreibt, was die Aufgabe heute ist, was AI-native bedeutet und was nicht, warum der alte Einstellungsprozess nicht mehr funktioniert, und die zwei Arbeitssitzungen, durch die wir ihn ersetzt haben: eine, die die Grundlagen ohne KI im Raum testet, und eine, die die Agent-Fähigkeiten mit aktivierten Tools testet, jeweils mit dem Bewertungsbogen, den wir dabei ausfüllen. Das ist der Prozess, den jeder Engineer, den wir vermitteln, durchläuft, konzipiert und bis heute durchgeführt von unserem CTO.
Die Frage, die einem Führungsverantwortlichen bleibt, ist eine einfache: Wenn der Multiplikator nun etwas ist, das Sie beobachten können, Ihr Prozess aber noch nie einen Kandidaten bei der Arbeit mit einem Agenten beobachtet hat, was misst Ihr Einstellungsverfahren dann eigentlich?
Laden Sie The Next 10X Engineer herunter, um die vollständige Begründung, beide Assessments und beide Scorecards zu erhalten.
