Der neue 10x-Engineer schreibt nicht 10x so viel Code. Er baut das System, das es schreibt.

Der 10x-Engineer ist ein Silicon-Valley-Mythos, der seit Jahrzehnten besteht. Der einsame Genie, mit Kopfhörern, produziert eleganten Code mit übermenschlicher Geschwindigkeit. Wir haben debattiert, ob sie existieren, argumentiert, wie man sie einstellt, und stillschweigend jeden beneidet, der behauptet, einer zu sein.

Aber etwas Interessantes passierte auf dem Weg in die AI-erste Zukunft: Der 10x-Engineer wurde real. Er sieht nur nicht so aus, wie wir uns ihn vorgestellt haben.

OpenAI teilte kürzlich mit, wie ein dreiköpfiges Team mit Codex 1.500 Pull-Requests und etwa eine Million Codezeilen ausgeliefert hat, ohne eine einzige Zeile manuell zu schreiben. Drei Ingenieure und null handgeschriebener Code. Ein Produktionsprodukt, das von hunderten internen Benutzern verwendet wird.

Das ist nicht 10x; es ist eher 100x. Und die Fähigkeit, die es ermöglichte, war nicht, schneller zu tippen oder mehr Algorithmen zu kennen. Es war das Aufbauen des Systems, das die Produktivität von AI-Agenten ermöglicht: die Workflows, die Sicherheitsmechanismen, die Verifizierungsschleifen, die Schnittstellen, die Agenten nutzen und Menschen überprüfen.

Ich glaube, dass dies die Entstehung einer neuen Schlüsselfunktion in Ingenieurorganisationen ist. Ich würde es AI-Orchestrierungsingenieurwesen nennen.

Drei Disziplinen gehen in einen Standup

Wenn man sich ansieht, was ein AI-Orchestrierungsingenieur eigentlich tut, erkennt man drei vertraute Disziplinen, die zu einer verschmolzen sind.

Das offensichtlichste Element ist DevOps. DevOps hat die Bereitstellungspipeline zentralisiert. Ein Team konfigurierte die CI/CD-Workflows, die jeder Ingenieur bei der Auslieferung von Code nutzte. AI-Orchestrierungsingenieurwesen tut das gleiche, aber für Agent-Workflows. Es definiert, wie Aufgaben Agenten zugewiesen werden, wie Ausgaben validiert werden, wie Wiederholungen und Fallbacks funktionieren. Es ist die gemeinsame Infrastruktur, auf der Agenten laufen.

Dann gibt es die Architektur, die sich mit DevOps mehr überschneidet, als man erwarten würde. Architekten entscheiden, welche Schnittstellen gesperrt sind, welche Muster durchgesetzt werden, welche Grenzen nicht überschritten werden können. In einer agentenbasierten Welt ist dies noch wichtiger. Agenten benötigen saubere, gut dokumentierte Codebasen mit klaren Verträgen. Der AI-Orchestrierungsingenieur definiert diese Einschränkungen, nicht nur für die Lesbarkeit durch Menschen, sondern auch für die Verständlichkeit durch Agenten. Eine chaotische Repo ist nicht nur technische Schulden, sondern auch eine Produktivitätsdecke für jeden Agenten, der sie berührt.

Das am wenigsten verstandene Stück ist die AI-spezifische Schicht. Prompt-Engineering, Kontextverwaltung, Modellauswahl, Agentenkonfiguration. Heute tun die meisten Ingenieure dies in einer zerstreuten, Aufgabe-für-Aufgabe-Weise. Jeder Mensch findet seinen eigenen Prompt-Stil, seine eigene Agenten-Einrichtung, seine eigenen Workarounds. Der AI-Orchestrierungsingenieur zentralisiert dies. Er baut die gemeinsamen Spielbücher, die wiederverwendbaren Konfigurationen, das organisatorische Wissen darüber, was funktioniert und was nicht, über Modelle und Anwendungsfälle hinweg.

Getrennt existieren diese drei Funktionen in den meisten Ingenieurorganisationen heute. Das Argument ist, dass die Kombination von ihnen in einer einzigen, zentralen Rolle etwas qualitativ anderes schafft.

Die Showrunner-Metapher

Ein Filmregisseur bedient nicht die Kamera, spielt nicht in den Szenen und schneidet nicht den Film. Aber jeder Frame spiegelt seine Entscheidungen wider.

Er wählt die Kameraeinstellung, das Tempo, den Ton. Er entscheidet, wann man hereinzoomt und wann man zurückzoomt. Er richtet die Umgebung ein (Licht, Set-Design, Blocking), damit jeder Mensch im Team innerhalb einer kohärenten Vision sein Bestes tun kann. Das Team ist individuell talentiert, aber ohne diese Koordination erhält man ein Chaos, das nie ausgeliefert wird.

AI-Orchestrierungsingenieurwesen funktioniert genauso. Die Agenten sind fähig. Die Modelle sind leistungsfähig. Aber ohne jemanden, der das System entwirft, das sie koordiniert, die Einschränkungen definiert, die Rückkopplungsschleifen aufbaut, die Workflows strukturiert, erhält man das, was wir alle erlebt haben: inkonsistente Ausgaben, verschwendete Rechenleistung, Agenten, die im Widerspruch zueinander arbeiten, und Ingenieure, die mehr Zeit damit verbringen, von AI generierten Code zu reparieren, als sie selbst geschrieben hätten.

Der Regisseur macht einen Film, der größer ist als die Summe seiner Teile. Der AI-Orchestrierungsingenieur tut das gleiche für Agenten-Flotten.

Warum die meisten Organisationen unterinvestieren

Hier ist, was ich über die Branche sehe: Unternehmen investieren stark in AI-Tools und nicht genug in die Systeme um sie herum.

Ingenieure erhalten Zugang zu Copilot, Claude, Codex. Sie experimentieren individuell. Einige werden zu Power-Usern. Die meisten bleiben auf dem Level von “fancy Autocomplete” stecken. Die 20% Produktivitätssteigerungen, die Studien immer wieder melden? Das ist das Symptom der Tool-Ebene-Adoption ohne System-Ebene-Denken.

Die Organisationen, die durchbrechen, diejenigen, die 2x oder mehr Durchsatz melden, haben etwas gemeinsam. Sie haben die Orchestrierung zentralisiert. Jemand (oder ein Team) besitzt die Agent-Workflows, die Repository-Vorbereitung, die Verifizierungsinfrastruktur, den gemeinsamen Kontext, den jeder Agent zugreifen kann.

Wie die Rolle tatsächlich aussieht

Der Tag eines AI-Orchestrierungsingenieurs könnte Folgendes umfassen:

• Entwurf von Agent-Workflows: Definieren, wie eine Feature-Anfrage zu einer Spezifikation wird, zu einem Plan wird, zu parallelen Agentenaufgaben wird, zu überprüftem und zusammengeführtem Code wird.
• Aufbau von Verifizierungsinfrastruktur: Automatisierte Tests, Linting-Regeln, Sicherheits-Scans und Bewertungsrahmen, die Agenten bestehen müssen, bevor ihre Arbeit zusammengeführt wird.
• Wartung der Repository-Gesundheit für Agenten-Verbrauch: Dokumentation, klare Schnittstellen, Abhängigkeitsverwaltung und Codebase-Vereinfachung, alles optimiert für Agenten-Verständnis, nicht nur für menschliche Lesbarkeit.
• Zentralisierung von Prompt- und Kontext-Strategien: Gemeinsame System-Prompts, Abruf-Pipelines, Modell-Routing-Entscheidungen und Konfigurationsvorlagen, die das gesamte Team nutzt.
• Überwachung und Verbesserung der Agentenleistung: Verfolgung von Erfolgsraten, Fehlermodi, Kosten pro Aufgabe und Zeit-bis-zur-Zusammenführung über die Agenten-Flotte hinweg, dann Anpassen des Systems basierend auf Daten.

Diese Person sitzt an der Schnittstelle von Plattform-Engineering, Software-Architektur und AI-Expertise. Sie schreibt keine Features. Sie baut das System, das die Feature-Lieferung schnell, zuverlässig und skalierbar macht.

Das historische Muster

In den frühen Tagen der Cloud-Computing war die Bereitstellung jedes Ingenieurs Nebenaufgabe. Jedes Team hatte seine eigenen Skripte, seine eigenen Server-Konfigurationen, seine eigene Art, Code in die Produktion zu bringen. DevOps entstand, um diese Arbeit zu zentralisieren, und Plattform-Engineering entwickelte sich, um es in gemeinsame, selbstbedienungsfähige Infrastruktur zu bauen.

AI folgt dem gleichen Bogen. Derzeit ist die Agenten-Nutzung jedes Ingenieurs Nebenaufgabe. Jeder Mensch hat seinen eigenen Prompt-Stil, seine eigene Tool-Präferenz, seine eigene mentale Modellierung davon, wann AI hilft und wann nicht. Die Organisationen, die dies zentralisieren, die es als Infrastruktur und nicht als individuelles Experimentieren behandeln, werden genauso vorankommen, wie Organisationen mit ausgereiften DevOps-Praktiken es gegenüber denen ohne getan haben.

Der Unterschied liegt in der Geschwindigkeit. Der DevOps-Übergang dauerte ein Jahrzehnt. Der eine könnte in Quartalen liegen. Ich gebe jedoch zu, dass diese Vorhersage davon ausgeht, dass Organisationen das Muster schneller erkennen, als sie es normalerweise tun.

Der Weg nach vorne

Wenn Sie ein Ingenieur-Führer sind, hier ist, was ich vorschlagen würde, obwohl Ihre Meilen variieren können, je nachdem, wie weit Ihr Team bereits ist.

1. Identifizieren Sie, wer diese Arbeit bereits informell leistet. Jedes Unternehmen hat jemanden, der die Agent-Workflows herausgefunden hat, den andere Ingenieure für Rat suchten, wenn es um Prompting oder Tool-Einrichtung ging. Diese Person ist Ihr Proto-AI-Orchestrierungsingenieur.
2. Machen Sie es explizit. Geben Sie der Funktion einen Namen, ein Mandat und Ressourcen. Lassen Sie es nicht als Nebenprojekt an jemandes “echtem” Job hängen.
3. Beginnen Sie mit der Repository-Bereitschaft. Bevor Sie in komplexe Agent-Workflows investieren, stellen Sie sicher, dass Ihre Codebase etwas ist, das Agenten tatsächlich navigieren können. Saubere Schnittstellen, gute Dokumentation, umfassende Tests, vereinfachte Architektur.
4. Zentralisieren Sie, was funktioniert. Wenn jemand eine Prompt-Strategie oder Workflow-Struktur entdeckt, die die Agenten-Ausgabe dramatisch verbessert, erfassen Sie sie. Machen Sie es zum Standard für das gesamte Team, nicht zu Stammeswissen, das in einem Menschenkopf gesperrt ist.
5. Messen Sie auf System-Ebene. Verfolgen Sie nicht nur die individuelle Tool-Nutzung. Verfolgen Sie, wie viele Aufgaben Agenten von Ende zu Ende erledigen, wie die Überprüfungs- und Nachbearbeitungs-Raten aussehen, wo die Engpässe sind.

Der neue 10x

Der Mythos des 10x-Engineers war immer über individuelle Heldentaten. Eine Person, die durch reine Begabung und Koffein jeden übertrifft.

Die Realität des 10x-Engineers in der AI-Ära ist über System-Denken. Die Person, die jeden anderen Ingenieur (und jeden Agenten) produktiver macht, indem sie die richtige Infrastruktur, die richtigen Workflows, die richtigen Einschränkungen aufbaut.

Er schreibt nicht 10x so viel Code. Er baut das System, das es schreibt.

Ich bin nicht sicher, ob diese Rolle genau so kristallisiert, wie ich sie hier beschrieben habe. Aber ich bin ziemlich sicher, dass die Organisationen, die die Orchestrierungsschicht (wie auch immer sie sie nennen) herausfinden, diejenigen sein werden, die tatsächlich die Produktivitätssteigerungen realisieren, über die jeder andere nur spricht.