De oorspronkelijke bewering was eenvoudig: sommige engineers produceren ruwweg tien keer de output van een gemiddelde collega. Of die verhouding ooit meetbaar was of niet, AI-tooling heeft veranderd waaruit de vermenigvuldiger bestaat en wie hem kan bereiken.
Waar het idee vandaan komt
Het 10x-label bestond in de softwaremythologie al lang vóór large language models. Het beschreef engineers die diepe kennis, snelle besluitvorming en het vermogen om doodlopende wegen te vermijden combineerden. Het voordeel was persoonlijk en grotendeels cognitief. Een trage typist met het juiste mentale model kon nog altijd beter presteren dan een snelle typist met het verkeerde.
Het bewijs achter de oorspronkelijke verhouding was dun. Productiviteitsstudies uit de jaren zestig en tachtig toonden grote variatie tussen programmeurs, maar schattingen lopen sterk uiteen afhankelijk van hoe output werd gemeten en welke taak werd gebruikt. Het getal tien bleef hangen omdat het beeldend was, niet omdat het precies was.
Wat er is veranderd
AI-codeertools, agents en code-bewuste assistenten nemen nu een groot deel van het mechanische werk over: boilerplate, testopzet, documentatie, refactoring en zoeken door een codebase. Dit verkleint de kloof aan de onderkant. Een gemiddelde engineer met goede tooling werkt sneller dan een gemiddelde engineer zonder.
Het praktische gevolg is dat ruwe typsnelheid en patroonherkenning minder belangrijk zijn. Wat engineers nog steeds van elkaar onderscheidt is de kwaliteit van hun oordeel: weten welke output te vertrouwen, welke af te wijzen, en welk probleem in de eerste plaats verkeerd was gespecificeerd. Een AI-native engineer is niet simpelweg sneller bij bestaande taken; ze herstructureren welke taken überhaupt gedaan moeten worden.
Waar de vermenigvuldiger nu zit
Een aantal categorieën vaardigheden is waardevoller geworden, niet minder, naarmate tooling is verbeterd:
- Kwaliteit van specificaties. AI-modellen produceren code die evenredig is aan de helderheid van de input. Engineers die een vage vereiste kunnen omzetten in een precieze, testbare beschrijving, halen veel meer uit hun tools dan degenen die dat niet kunnen. Dit sluit direct aan op context engineering.
- Review onder druk. Gegenereerde code arriveert snel en leest vloeiend. De subtiele logicafout of de onjuiste aanname opsporen vereist dezelfde vaardigheid als altijd, maar dan sneller toegepast en vaker. Zie hoe je AI-gegenereerde code reviewt.
- Systeemdenken. Individuele functies genereren is eenvoudig. Bepalen hoe componenten bij elkaar passen, waar foutmodi zich bevinden en wat de architectuur over zes maanden kost om te wijzigen, blijft een menselijke taak.
- Weten wanneer je stopt. Te veel bouwen met AI-hulp is een nieuwe manier om fout te gaan. Tien abstracties genereren waar twee volstaan, levert technische schuld op en vermenigvuldigt niemands output.
De vermenigvuldiger is nu een vraag op teamniveau
Betere tooling heeft als gevolg dat uitzonderlijke impact moeilijker bij één persoon is aan te wijzen. Een engineer die de output van het hele team verhoogt, met betere prompts, effectieve review van gegenereerde code of door op te merken dat een model overtuigd het verkeerde antwoord gaf, levert meer waarde dan iemand die alleen sneller oplevert.
De oudere versie van 10x was individueel en grotendeels onzichtbaar. De huidige versie is terug te zien in de kwaliteit van pull requests, het aantal incidenten en hoe snel een team herstelt van een verkeerde afslag. Het is beter leesbaar, wat één reden is waarom er bewuster op geworven wordt.
Wat dit in de praktijk betekent
Als je aan het inhuren bent, is de vraag niet meer wie de meeste code kan produceren. Het gaat erom wie het beste oordeel heeft per eenheid output. Dat omvat weten wanneer een model het fout heeft, wanneer een spec onvolledig is, en wanneer de eenvoudige oplossing de juiste is. How to assess an engineer's AI ability beschrijft hoe die evaluatie eruitziet.
Waar we op testen
Het selectieproces van Miyagami is gebouwd om oordeelsvermogen te toetsen. Kandidaten doen twee sessies: een fundamentals-assessment zonder AI-tools en een AI-native assessment met AI-tools. De criteria die vandaag het best voorspellen of iemand echt impact heeft, zijn oordeelsvermogen per risico, dat geen van beide sessies overslaat, en ownership, dat alles omvat na de merge, of een mens of een agent de code schreef. Alle details over beide sessies en elk gescoord criterium staan bij hoe we selecteren.
Korte antwoorden
Is het 10x engineer-idee nog geloofwaardig?
Het productiviteitsverschil tussen engineers is reëel en gedocumenteerd, hoewel de verhouding van tien altijd een benadering was. AI-tooling heeft verschoven wat dat verschil veroorzaakt: oordeel en systeemdenken zijn nu belangrijker dan snelheid of patroonherkenning.
Kunnen AI-tools elke engineer een 10x engineer maken?
Tooling verhoogt de ondergrens voor iedereen, maar elimineert het verschil niet. Engineers met sterker oordeel halen meer uit dezelfde tools, vangen meer fouten in gegenereerde output en nemen betere architectuurbeslissingen. Het verschil blijft bestaan, alleen via andere vaardigheden.
Hoe herken je een 10x engineer in een sollicitatiegesprek?
Let op hoe ze omgaan met ambiguïteit, gegenereerde code reviewen en afwegingen uitleggen. Ruwe codeersnelheid is een zwak signaal. Gestructureerde taken rondom onvolledige specs en het reviewen van AI-output zijn betrouwbaarder. Zie how-to-assess-an-engineers-ai-ability voor een praktisch kader.
