I fyrtio år var 10X-utvecklaren ett argument, inte en observation. Studier fann tiofaldiga skillnader mellan programmerare på samma uppgift, folk ifrågasatte metodologin i decennier, och uttrycket blev mest ett sätt att säga "anställ folk som mig". Alla argumenterade om huruvida personen existerade, men alla var överens om vad man skulle mäta: output.
Sätt tre utvecklare på samma backlog i dag och följ dem en förmiddag. Den förste använder inte AI alls. Duktig utvecklare, läser allt, kodar allt. Den andre har en agent öppen i ett fönster: prompt, vänta, läs, prömpta igen. Den tredje har fyra git worktrees öppna med en agent i varje, en jobbar på en funktion, en på en bugg, en granskar en pull request, en skriver end-to-end-tester, och rör sig mellan dem och kontrollerar vad varje agent producerat. Vid lunch har den tredje gjort det som den förste avslutar på torsdag.
Nästa 10X-utvecklare är den tredje. Vad de gör är att ta en vag ticket, omvandla den till en levererad förändring de kan stå för, och använda agenter för att komprimera det som förut var maskinskrivning. Två uppsättningar färdigheter gör det möjligt: de grundläggande som alltid funnits, och agentfärdigheter som inte existerade för tre år sedan.
Det uppenbara behöver också sägas, och vitboken som den här artikeln bygger på säger det rakt ut: AI har gjort vissa utvecklare sämre. Den andre utvecklaren i förmiddagsscenen producerar mer än de gjorde för två år sedan och förstår ibland mindre av det.
Siffrorna bakom allt detta kommer från vår egen leverans. I Miyagamis projekt skrivs nu 80 till 90 procent av produktionskoden av en modell, och ett projekt som behövde tio utvecklare 2024 drivs av fyra utvecklare i dag. Vi kom inte dit via ett pilotprojekt, det är vad två års kundarbete konvergerat mot, och det är därför att hyra in rätt utvecklare nu spelar större roll än någonsin. När fyra personer bär vad tio bar, slutar en felrekrytering att vara ett avrundningsfel.
Hur ser arbetet ut när kodrader är billiga? För tre år sedan var en senior utvecklares dag att välja en ticket, skriva koden, skriva ett test, öppna en PR, nästa ticket, och merparten av timmarna gick åt till att skriva kod för hand. Nu delas tickets upp i en plan, planen i delar som är tillräckligt små för att varje PR ska kunna läsas vid ett tillfälle, och dessa delar skickas till agenter parallellt. Timmarna går åt till att bestämma vad som ska byggas, ge agenten rätt kontext och säkerställa att resultatet är säkert att leverera. En agent bygger vad du ger den, så en brist i indata visar sig i utdata inom en timme: ett otydligt krav kommer tillbaka som något selvsäkert, trovärdigt och byggt på en gissning; saknad kontext kommer tillbaka som felaktiga antaganden om ditt system; svaga tester låter genererad kod passera och bryter tyst den beteende de aldrig täckte.
Den omformuleringen förklarar varför den andre utvecklaren i förmiddagsscenen inte heller är svaret, och distinktionen är viktig nog att precisera. En AI-native utvecklare, som vi använder termen, är en fullstack-utvecklare med solida grundkunskaper inom kodkvalitet, systemdesign och säkerhet, som instruerar kodagenter om hur de ska producera output och validerar den outputen innan den levereras. Grundkunskaperna kommer först i den meningen av en anledning: om du inte kan resonera om systemet utan agenten kan du inte se när agenten har fel. Och om du inte kan granska koden ordentligt gör agenten dig inte senior. Det gör dig snabbare på att producera saker du inte förstår. En AI-native utvecklare är inte en promptare, någon som använder en agent som du skulle använda en sökruta, ett fönster, en förfrågan i taget, acceptera och gå vidare till nästa prompt.
Det besvärliga för tekniska ledare är att den här skillnaden är osynlig överallt där rekrytering normalt tittar. Den syns inte i CV:t, för alla har "AI" i CV:t nu. Den syns inte i hemuppgiften, för båda inlämningarna var modellskrivna och ser identiska ut på skärmen. Den syns inte i ett samtal om verktyg, för promptaren har läst samma inlägg som du. Skillnaden syns inom några minuter av att se någon arbeta i en riktig kodbas, och det är precis det som de flesta intervjuprocesser aldrig gör.
Vi skrev The Next 10X Engineer för att vi fortsatte ha det här samtalet en CTO i taget. Dokumentet går igenom vad arbetet är nu, vad AI-native betyder och vad det inte betyder, varför den gamla rekryteringsprocessen slutade fungera, och de två arbetssessionerna vi ersatte den med: en som testar grundkunskaperna utan AI i rummet, en som testar agentfärdigheterna med verktygen påslagna, vardera med det bedömningskort vi fyller i under den. Det är processen varje utvecklare vi placerar genomgår, utformad och fortfarande ledd av vår CTO.
Frågan det lämnar för en ledare är enkel: om multiplikatorn nu är något du kan observera, och din process aldrig en enda gång har sett en kandidat arbeta med en agent, vad mäter din rekrytering egentligen?
Ladda ned The Next 10X Engineer för det fullständiga resonemanget, båda bedömningar och båda scorecards.
