Veertig jaar lang was de 10X engineer een stelling, geen observatie. Studies vonden tienvoudige verschillen tussen programmeurs op dezelfde taak, mensen twistten decennialang over de methodologie, en de uitdrukking werd vooral een manier om te zeggen: 'neem mensen aan zoals ik'. Iedereen debatteerde of zo iemand bestond, maar iedereen was het eens over wat je moest meten: output.
Zet vandaag drie engineers op dezelfde backlog en kijk ze een ochtend lang. De eerste gebruikt helemaal geen AI. Goede engineer, leest alles, codeert alles zelf. De tweede heeft een agent open in één venster: prompt, wachten, lezen, opnieuw prompten. De derde heeft vier git worktrees open met een agent in elk: één voor een feature, één voor een bug, één die een pull request reviewt, één die end-to-end tests schrijft, en beweegt er tussendoor om te controleren wat elke agent heeft geproduceerd. Tegen de lunch heeft de derde gedaan wat de eerste donderdag afkrijgt.
De volgende 10X engineer is de derde. Wat die doet: een vaag ticket oppakken, omzetten in een geshipte wijziging waar hij of zij voor in kan staan, en agents gebruiken om het deel dat vroeger typen was te comprimeren. Twee sets vaardigheden maken dat mogelijk: de fundamenten die er altijd al waren, en agent-vaardigheden die drie jaar geleden nog niet bestonden.
Het voor de hand liggende moet ook gezegd worden, en het whitepaper waarop dit artikel is gebaseerd zegt het zonder omhaal: AI heeft sommige engineers slechter gemaakt. De tweede engineer in die ochtendscène produceert meer dan twee jaar geleden en begrijpt er soms minder van.
De cijfers hierachter komen uit onze eigen oplevering. Op Miyagami-builds wordt 80 tot 90 procent van de productiecode nu door een model geschreven, en een project dat in 2024 tien engineers nodig had, draait vandaag op vier. We zijn daar niet via een pilot beland; het is waar twee jaar klantwerk naartoe is geconvergeerd, en het is waarom de juiste engineers inhuren nu meer uitmaakt dan ooit. Als vier mensen dragen wat tien droegen, is één verkeerde hire geen afrondingsfout meer.
Hoe ziet het werk eruit als regels code goedkoop zijn? Drie jaar geleden bestond de dag van een senior engineer uit: ticket pakken, code schrijven, test schrijven, een PR openen, volgend ticket, en het grootste deel van de uren ging op aan code met de hand schrijven. Nu worden tickets opgesplitst in een plan, het plan in stukken die klein genoeg zijn zodat elke PR in één zit te lezen is, en die stukken gaan parallel naar agents. De uren gaan naar beslissen wat te bouwen, de agent de juiste context meegeven, en controleren of het resultaat veilig is om te shippen. Een agent bouwt wat je hem geeft, dus een gat in de input verschijnt binnen het uur in de output: een onduidelijke requirement komt terug als iets zelfverzekerd, aannemelijk en gebaseerd op een gok; ontbrekende context komt terug als verkeerde aannames over je systeem; slappe tests laten gegenereerde code slagen terwijl het gedrag dat ze nooit afdekten stilletjes stuk gaat.
Die herkadering verklaart waarom ook de tweede engineer uit de ochtendscène het antwoord niet is, en het onderscheid is belangrijk genoeg om scherp te stellen. Een AI-native engineer, zoals wij de term gebruiken, is een full-stack developer met solide fundamenten in codekwaliteit, systeemontwerp en security, die coding agents aanstuurt in hoe ze output produceren en die output valideert voordat die geshipt wordt. De fundamenten staan eerst in die zin om een reden: als je niet over het systeem kunt redeneren zonder de agent, kun je niet zien wanneer de agent het fout heeft. En als je de code niet goed kunt reviewen, maakt de agent je geen senior. Hij maakt je sneller in het produceren van dingen die je niet begrijpt. Een AI-native engineer is geen prompter, iemand die een agent gebruikt zoals je een zoekvak zou gebruiken: één venster, één verzoek tegelijk, accepteren en door naar de volgende prompt.
Het lastige voor engineering-leads is dat dit verschil onzichtbaar is op de plekken waar hiring normaal gesproken kijkt. Het staat niet op het cv, want iedereen heeft 'AI' op het cv staan. Het zit niet in de take-home opdracht, want beide inzendingen zijn door een model geschreven en zien er op het scherm identiek uit. Het blijkt niet uit een gesprek over tooling, want de prompter heeft dezelfde posts gelezen als jij. Het verschil is zichtbaar binnen minuten van iemand zien werken in een echte codebase, en dat is precies het ene ding dat de meeste sollicitatieprocedures nooit doen.
We hebben The Next 10X Engineer geschreven omdat we dit gesprek steeds één CTO tegelijk voerden. Het paper loopt door wat het werk nu is, wat AI-native betekent en wat niet, waarom het oude hiring-proces is opgehouden te werken, en de twee werksessies waardoor we het hebben vervangen: één die de fundamenten test zonder AI in de ruimte, één die de agent-vaardigheden test met de tools aan, elk met de scorecard die we er tijdens invullen. Het is de procedure die elke engineer die wij plaatsen doorloopt, ontworpen en nog steeds uitgevoerd door onze CTO.
De vraag die het voor een lead achterlaat is een eenvoudige: als de multiplier nu iets is dat je kunt observeren, en je procedure heeft nog nooit een kandidaat zien werken met een agent, wat meet je hiring dan eigenlijk?
Download The Next 10X Engineer voor de volledige onderbouwing, beide assessments en beide scorecards.
