We hebben onze vetteringsstandaard gepubliceerd. Beide assessments, beide scorecards, wat goed eruitziet, wat slecht eruitziet: alles, openbaar. Voordat je het leest, is dit het denken achter de zes criteria die we scoren als de kandidaat een agent open heeft, en waarom de sessie is opgebouwd zoals hij is.
Het AI-native assessment is de tweede van twee werksessies in een echte codebase. Tegen de tijd dat een kandidaat eraan toekomt, heeft hij of zij een fundamentalsessie doorstaan in een codebase die hij of zij nooit eerder had gezien, met echte tickets en zonder AI-tools, want als je niet over een systeem kunt redeneren zonder de agent, kun je niet zien wanneer de agent het fout heeft. Dan begint de tweede sessie: een nieuwe set tickets en de AI-codeertools die ze normaal gesproken zouden gebruiken. Een agent die het grootste deel van de productie verzorgt, en wij die kijken wat de mens er daadwerkelijk aan bijdraagt.
Het eerste criterium is verificatie van AI-output. Goed ziet eruit als het opvangen van gehallucineerde API's, subtiel foute logica of beveiligingslekken in gegenereerde code voordat die live gaat. Slecht ziet eruit als vertrouwen omdat het compileert. De fout heeft een textuur die je binnen minuten leert herkennen: de kandidaat houdt op engineer te zijn en wordt een doorgeefluik tussen het model en de codebase. Elke wijziging geaccepteerd, elke prompt beantwoord met "ga door", tickets gesloten zonder er ook maar één te controleren. Het is precies hoe de dertien jaar ervaren developer uit de inleiding van het paper onderuitging, en het is onzichtbaar voor elk proces dat alleen kijkt naar wat hij heeft opgeleverd, want wat hij opleverde compileerde.
Het tweede is tool-orkestratie, en daar zit de multiplier. Goed ziet eruit als weten wanneer je werk aan de agent overdraagt, de scaffolding, de boilerplate, de tests, en wanneer je de nieuwe logica en de lastige randgevallen zelf schrijft, en vervolgens die twee parallel laat lopen in worktrees zodat agents niet conflicteren. Slecht ziet eruit als één venster voor alles, of het spiegelbeeld daarvan: dingen met de hand schrijven die een agent beter doet, uit trots. Vrijwel geen enkel sollicitatieproces test dit, wat opmerkelijk is gezien het het verschil is tussen een engineer en de meerdere malen snellere versie van diezelfde engineer.
De overige vier completeren het beeld. Spec-gedreven ontwikkeling: een vaag ticket opsplitsen in stukken die klein genoeg zijn voor de tool om goed uit te voeren, in plaats van de hele onduidelijke vraag in één keer erin te gooien. Prompt- en context-engineering: de taak zo inrichten dat de tool in één of twee passes bruikbare output levert, in plaats van dezelfde vage vraag in een loop opnieuw te prompten. AI-versneld debuggen: de agent gebruiken voor root-cause analysis, log-triage en stack traces, zonder de stap over te slaan van het zelf reproduceren en begrijpen van de fout. En context-switch hygiene: weten wat elke agent doet, terugkomen bij de juiste, en niet laten dat notificaties het schakelen bepalen. Dat laatste wordt in beide sessies gescoord, omdat het over de engineer gaat en niet over de tools, en het is het punt dat bepaalt of orkestratie een multiplier is of gewoon meerdere foute dingen tegelijk.
In het paper staat dat de scorecard niet het hele plaatje is. Drie dingen wegen even zwaar en passen niet op een kaart, dus zoeken we ze in beide assessments. Oordeel naar risico: een tekstwijziging, een kleine refactor en een betalingsmigratie verdienen niet dezelfde review. Met agents telt dat zwaarder, want de tool levert alle drie even snel en even stellig op. Ownership: wat je merget, ben je zelf verantwoordelijk voor. „De agent deed het” is geen verklaring die wij in een assessment accepteren, en jouw team accepteert hem ook niet in een incident review. Tot slot de multiplier: de beste engineers ronden het ticket af en laten de repo ook beter ingericht achter voor de volgende agent. Denk aan een herbruikbaar commando, een scherper contextbestand of een test die de hele klasse van bugs afvangt en niet alleen dit ene geval.
Waarom publiceren we alles, inclusief de scoring? Daar zijn drie redenen voor. Ten eerste heeft de sector een referentiepunt nodig. “We screenen op AI-vaardigheden” is al even nietszeggend geworden als “senior” op een cv, en een gepubliceerde standaard is lastiger na te doen dan een claim. Ten tweede verdienen kandidaten te weten waar ze aan beginnen. De engineers die wij zoeken, lezen de standaard en denken: “eindelijk test iemand het echte werk”. Ten derde kunnen we het betalen. Het voordeel zit niet in de scorecards. Het zit in de mensen die de sessies leiden: zij bouwen elke dag productiesoftware met deze tools, en alleen zo weet je hoe een fout antwoord eruitziet. Een detacheringsbureau kan onze rubric morgen kopiëren en kan er nog steeds geen score mee geven.
Er is ook een reden voor kopers om dit te lezen, en we bedoelen het als uitnodiging, niet als steek. Als je iemand betaalt voor engineers, toets dan hun selectiemethode aan een gepubliceerde standaard, de onze of een betere. Vraag wat er getest wordt, hoe het gescoord wordt en waarop mensen afvallen. De bureaus die dit serieus aanpakken, geven je een gedetailleerd antwoord en vinden de vraag waarschijnlijk prima. De rest stuurt je een slide over hun talentenpool.
Het whitepaper loopt door beide sessies heen met de scorecards die we er tijdens invullen. Als je één hoofdstuk leest, lees dan dat over de AI-native assessment. Daar schuilt de volgende slechte hire.
Lees de standaard op hoe we screenen. Download The Next 10X Engineer.
