Vi har publicerat vår granskningsstandard. Båda bedömningarna, båda bedömningskorten, vad bra ser ut, vad dåligt ser ut: allt, öppet. Innan du läser det är det här tankarna bakom de sex kriterier vi bedömer när kandidaten har en agent öppen, och varför sessionen är uppbyggd som den är.
AI-native-bedömningen är den andra av två arbetssessioner i en riktig kodbas. När en kandidat når den har de klarat en grundlagssession i en kodbas de aldrig sett, med riktiga ärenden och inga AI-verktyg, eftersom om du inte kan resonera om ett system utan agenten kan du inte avgöra när agenten har fel. Sedan börjar den andra sessionen: en ny uppsättning ärenden och vilka AI-kodningsverktyg de normalt skulle använda. En agent som sköter merparten av produktionen, och vi ser på vad människan faktiskt bidrar med.
Det första kriteriet är verifiering av AI-output. Bra ser ut som att fånga hallucinerade API:er, subtilt felaktig logik eller säkerhetsluckor i genererad kod innan den levereras. Dåligt ser ut som att lita på den för att den kompilerar. Misslyckandet har en karaktär man lär sig känna igen inom minuter: kandidaten slutar vara en utvecklare och blir ett relä mellan modellen och kodbasen. Varje ändring accepterad, varje prompt besvarad med "kör", ärenden stängda utan att kontrollera något av dem. Det är precis hur den trettonåriga utvecklaren i vitbokens inledning föll samman, och det är osynligt för varje process som bara tittar på vad han levererade, eftersom det han levererade kompilerade.
Det andra är verktygsorkestration, och det är där multiplikatorn finns. Bra ser ut som att veta när man ska överlämna arbete till agenten, ställningen, boilerplate-koden, testerna, och när man ska handkoda den nya logiken och de krångliga kantfallen, och sedan köra de två parallellt i worktrees så att agenter inte kolliderar. Dåligt ser ut som ett fönster som används till allt, eller dess spegelvänd, att av stolthet handkoda saker som en agent gör bättre. Nästan ingen intervjuprocess någonstans testar det här, vilket är anmärkningsvärt med tanke på att det är skillnaden mellan en utvecklare och den flera gånger snabbare versionen av samma utvecklare.
De återstående fyra kompletterar bilden. Spec-driven development: att bryta ner ett vagt ärende i delar som är tillräckligt små för att verktyget ska kunna utföra väl, i stället för att kasta hela den tvetydiga frågan mot det på en gång. Prompt- och kontextteknik: att ställa in uppgiften så att verktyget producerar användbar output i ett eller två pass, i stället för att omprompta samma vaga begäran i en loop. AI-accelererad felsökning: att använda agenten för rotorsaksanalys, loggtriage och stack traces, utan att hoppa över steget att reproducera och förstå felet själv. Och kontextbytes-hygien: att veta vad varje agent gör, komma tillbaka till rätt en, och inte låta notifieringar styra bytena. Den sista bedöms i båda sessionerna, eftersom det handlar om utvecklaren snarare än verktygen, och det är den som avgör om orkestrering är en multiplikator eller bara flera fel saker som händer samtidigt.
Rapporten säger det rakt ut: scorecard visar inte hela bilden. Tre saker väger lika tungt och får inte plats på ett kort, så vi letar efter dem i båda bedömningarna. Omdöme utifrån risk: en textändring, en enkel refaktorering och en betalningsmigrering ska inte få samma granskning. Med agenter spelar det större roll, eftersom verktyget levererar alla tre lika snabbt och med samma säkerhet. Ägarskap: mergar du koden äger du den, och “agenten gjorde det” är ingen förklaring vi godtar i en bedömning, och inte heller något ditt team godtar i en incidentgenomgång. Hävstång: de bästa utvecklarna blir klara med ärendet och lämnar dessutom repot bättre förberett för nästa agent, med ett återanvändbart kommando, en tydligare kontextfil eller ett test som fångar hela buggklassen i stället för enstaka fall.
Varför publicera allt, poängsättningen inräknad? Det finns tre skäl. För det första behöver branschen en referenspunkt. "Vi granskar AI-kunskaper" har redan hamnat där "senior" på ett CV hamnade, och en publicerad standard är svårare att imitera än ett påstående. För det andra har kandidater rätt att veta vad de går in i. De utvecklare vi vill ha är de som läser standarden och tänker "äntligen testar någon det faktiska jobbet". För det tredje har vi råd. Scorecarden är inte vårt försprång. Det ligger hos dem som leder sessionerna: de bygger produktionsmjukvara med de här verktygen varje dag, och det är enda sättet att veta hur ett fel svar ser ut. Ett bemanningsföretag kan kopiera vår bedömningsmall imorgon och ändå inte kunna poängsätta efter den.
Det finns också ett värde för dig som köpare av dessa tjänster, och vi menar det som en inbjudan snarare än en känga. Om du betalar någon för utvecklare, håll deras urvalsprocess mot en publicerad standard, vår eller en bättre. Fråga vad som testas, hur det bedöms och vad som gör att kandidater inte godkänns. De företag som gör detta ordentligt svarar i detalj och tycker förmodligen att frågan är välkommen. Övriga skickar dig ett bildspel om sin talangpool.
Vitboken går igenom båda sessionerna med de bedömningskort vi fyller i under dem. Om du läser ett kapitel, läs det om AI-native-bedömningen. Det är där nästa felrekrytering gömmer sig.
Läs standarden på hur vi granskar. Ladda ned The Next 10X Engineer.
