De Nieuwe 10x Engineer Schrijft Geen 10x Zoveel Code. Ze Bouwen Het Systeem Dat Het Schrijft.

De 10x engineer is al decennialang een mythe in Silicon Valley. De eenzame genie, met koptelefoon op, produceert elegantie code op supermenselijke snelheid. We hebben gedebatteerd over het bestaan ervan, gediscussieerd over hoe ze te werven en stilletjes gewalgd van iedereen die beweert er een te zijn.

Maar iets interessants gebeurde op weg naar de AI-georiënteerde toekomst: de 10x engineer werd echt. Ze zien er alleen niet uit zoals we ons hadden voorgesteld.

OpenAI deelde onlangs hoe een team van drie personen Codex gebruikte om 1.500 pull requests en ongeveer een miljoen regels code te verzenden, zonder één regel handmatig te schrijven. Drie engineers, en geen enkele handgeschreven code. Een productieproduct dat door honderden interne gebruikers wordt gebruikt.

Dat is niet 10x; het is dichter bij 100x. En de vaardigheid die het mogelijk maakte, was niet het sneller typen of meer algoritmen kennen. Het was het bouwen van het systeem dat AI-agents productief maakt: de workflows, de beveiligingsmechanismen, de verificatielussen, de interfaces waarop agents aansluiten en mensen via beoordelen.

Ik geloof dat dit de opkomst is van een nieuwe sleutelfunctie in engineeringsorganisaties. Ik zou het AI-Orkestratie-Engineering noemen.

Drie Disciplines Lopen Een Standup Binnen

Als je naar wat een AI-Orkestratie-Engineer eigenlijk doet, kijkt, herken je drie vertrouwde disciplines die in één zijn samengevoegd.

Het meest voor de hand liggende ingrediënt is DevOps. DevOps centraliseerde de implementatiepijplijn. Één team configureerde de CI/CD-workflows die elke engineer gebruikte bij het verzenden van code. AI-Orkestratie-Engineering doet hetzelfde, maar voor agent-workflows. Het definieert hoe taken aan agents worden toegewezen, hoe uitvoer wordt geverifieerd, hoe retries en fallbacks werken. Het is de gedeelde infrastructuur waarop agents draaien.

Daarnaast is er architectuur, die meer overlapt met DevOps dan je zou verwachten. Architecten beslissen welke interfaces zijn vergrendeld, welke patronen worden afgedwongen, welke grenzen niet kunnen worden overschreden. In een agent-georiënteerde wereld is dit nog belangrijker. Agents hebben schone, goed gedocumenteerde codebases met duidelijke contracten nodig. De AI-Orkestratie-Engineer definieert die beperkingen, niet alleen voor menselijke leesbaarheid, maar voor agent-comprehensie. Een rommelige repository is niet alleen technische schuld meer. Het is een productiviteitsplafond voor elke agent die het aanraakt.

Het minst begrepen onderdeel is de AI-specifieke laag. Prompt-engineering, contextbeheer, modelselectie, agentconfiguratie. Vandaag de dag doen de meeste engineers dit op een verspreide, taak-voor-taak-manier. Elke persoon ontdekt zijn eigen aanwijzingsstijl, zijn eigen agentopstelling, zijn eigen workarounds. De AI-Orkestratie-Engineer centraliseert dit. Ze bouwen de gedeelde playbooks, de herbruikbare configuraties, de organisatorische kennis over wat werkt en wat niet werkt over modellen en use cases.

Afzonderlijk bestaan deze drie functies in de meeste engineeringsorganisaties van vandaag. Het argument is dat het combineren ervan in één centrale rol iets kwalitatief anders creëert.

De Showrunner-Metafoor

Een filmregisseur bedient de camera niet, speelt niet in de scènes en monteert de beelden niet. Maar elke frame weerspiegelt hun beslissingen.

Ze kiezen de compositie van de shot, het tempo, de toon. Ze beslissen wanneer ze dichtbij moeten komen en wanneer ze ver weg moeten gaan. Ze zetten de omgeving op (verlichting, setontwerp, blocking) zodat elke persoon op de set zijn beste werk kan doen binnen een coherent visioen. De crew is individueel getalenteerd, maar zonder die coördinatie, krijg je een rommeltje dat nooit wordt verzonden.

AI-Orkestratie-Engineering werkt op dezelfde manier. De agents zijn capabel. De modellen zijn krachtig. Maar zonder iemand die het systeem ontwerpt dat hen coördineert, de beperkingen definieert, de feedbacklussen bouwt, de workflows structureert, krijg je wat we allemaal hebben meegemaakt: inconsistentie uitvoer, verspilde compute, agents die tegenstrijdige doelen nastreven en engineers die meer tijd besteden aan het oplossen van AI-gegenereerde code dan ze zouden hebben besteed aan het schrijven van de code zelf.

De regisseur maakt een film die groter is dan de som van zijn onderdelen. De AI-Orkestratie-Engineer doet hetzelfde voor agent-vloten.

Waarom De Meeste Organisaties Onderinvesteren

Dit is wat ik zie in de industrie: bedrijven investeren zwaar in AI-hulpmiddelen en niet genoeg in de systemen eromheen.

Engineers krijgen toegang tot Copilot, Claude, Codex. Ze experimenteren individueel. Sommigen worden power users. De meesten bereiken een plateau op het niveau van “fancy autocomplete”. De 20% productiviteitswinst die studies blijven melden? Dat is het symptoom van tool-niveau-adoptie zonder systeemniveau-denken.

De organisaties die doorbreken, diegenen die 2x of meer doorvoer melden, hebben iets gemeen. Ze hebben de orkestratie centraal gesteld. Iemand (of een team) is eigenaar van de agent-workflows, de repository-voorbereiding, de verificatie-infrastructuur, de gedeelde context die elke agent kan benaderen.

Hoe De Rol Er Daadwerkelijk Uitziet

De dagelijkse routine van een AI-Orkestratie-Engineer kan onder andere het volgende omvatten:

• Het ontwerpen van agent-workflows: definiëren hoe een functieaanvraag een specificatie wordt, wordt een plan, wordt parallelle agenttaken, wordt beoordeelde en samengevoegde code.
• Het bouwen van verificatie-infrastructuur: geautomatiseerde tests, linting-regels, beveiligingsscans en evaluatiekaders die agents moeten doorstaan voordat hun werk wordt samengevoegd.
• Het onderhouden van repository-gezondheid voor agent-consumptie: documentatie, duidelijke interfaces, afhankelijkheidsbeheer en codebase-vereenvoudiging, allemaal geoptimaliseerd voor agent-comprehensie, niet alleen menselijke leesbaarheid.
• Het centraliseren van prompt- en contextstrategieën: gedeelde systeemprompts, ophaalpijpen, modelrouteringsbeslissingen en configuratiesjablonen die het hele team gebruikt.
• Het monitoren en verbeteren van agentprestaties: het bijhouden van succespercentages, foutmodi, kosten per taak en tijd-tot-samenvoegen over de agent-vloot, en vervolgens het systeem afstemmen op basis van gegevens.

Deze persoon zit op het snijvlak van platform-engineering, software-architectuur en AI-expertise. Ze schrijven geen functies. Ze bouwen het systeem dat functielevering snel, betrouwbaar en schaalbaar maakt.

Het Historische Patroon

In de vroege dagen van cloud computing was implementatie de zijmissie van elke engineer. Elk team had zijn eigen scripts, zijn eigen serverconfiguraties, zijn eigen manier van code in productie krijgen. DevOps kwam op om deze werkzaamheden te centraliseren, en Platform Engineering evolueerde om het te bouwen in gedeelde, self-service-infrastructuur.

AI volgt dezelfde boog. Op dit moment is agent-gebruik de zijmissie van elke engineer. Elke persoon heeft zijn eigen aanwijzingsstijl, zijn eigen hulpmiddelenvoorkeuren, zijn eigen mentale model voor wanneer AI helpt en wanneer het niet helpt. De organisaties die dit centraliseren, die het behandelen als infrastructuur in plaats van individueel experiment, zullen vooruitkomen op dezelfde manier als organisaties met volwassen DevOps-praktijken diegenen zonder inhalen.

Het verschil is snelheid. De DevOps-overgang duurde een decennium. Deze kan kwartalen duren. hoewel ik toegeef dat deze voorspelling ervan uitgaat dat organisaties het patroon sneller herkennen dan ze gewoonlijk doen.

De Weg Vooruit

Als je een engineeringsleider bent, dit is wat ik zou voorstellen, hoewel je resultaten kunnen variëren afhankelijk van hoe ver je team al is.

1. Identificeer wie deze werkzaamheden al informeel uitvoert. Elke organisatie heeft iemand die de agent-workflows heeft uitgefigured, die andere engineers om advies vragen over prompting of tool-opstelling. Die persoon is je proto-AI-Orkestratie-Engineer.
2. Maak het expliciet. Geef de functie een naam, een mandaat en middelen. Laat het niet blijven als een zijproject dat is gekoppeld aan iemands “echte” baan.
3. Begin met repository-klaarheid. Voordat je investeert in geavanceerde agent-workflows, zorg ervoor dat je codebase iets is dat agents daadwerkelijk kunnen navigeren. Schone interfaces, goede documentatie, uitgebreide tests, vereenvoudigde architectuur.
4. Centraliseer wat werkt. Wanneer iemand een aanwijzingsstrategie of workflowpatroon ontdekt die de agent-uitvoer aanzienlijk verbetert, vang het op. Maak het de standaard voor het hele team, niet tribale kennis die is opgesloten in iemands hoofd.
5. Meet op systeemniveau. Houd niet alleen individueel hulpmiddelgebruik bij. Houd bij hoeveel taken agents eind-tot-eind voltooien, wat de beoordelings- en herschrijfpercentages zijn, waar de knelpunten liggen.

De Nieuwe 10x

De mythe van de 10x engineer was altijd over individuele heldendaden. Één persoon, die iedereen overtreft door pure talent en cafeïne.

De realiteit van de 10x engineer in de AI-tijdperk is over systeemdenken. De persoon die elke andere engineer (en elke agent) productiever maakt door de juiste infrastructuur, de juiste workflows, de juiste beperkingen te bouwen.

Ze schrijven geen 10x zoveel code. Ze bouwen het systeem dat het schrijft.

Ik ben er niet zeker van dat deze rol precies zal kristalliseren zoals ik het hier heb beschreven. Maar ik ben redelijk zeker dat de organisaties die de orkestratielaag (wat ze het ook gaan noemen) uitfigureren, degene zullen zijn die daadwerkelijk de productiviteitswinsten realiseren waar iedereen anders alleen maar over praat.