Ergens in het afgelopen jaar begon bijna elk gesprek dat we met engineering managers voeren met dezelfde vraag: lopen we achter? Draaien anderen al parallelle agents? Heeft iemand de take-home echt laten vallen, of posten ze daar alleen over? Het eerlijke antwoord was tot nu toe dat iedereen gokt, inclusief de mensen die er het meest zelfverzekerd over posten.
De Engineering Leader Benchmark is deze week open gegaan.
Het werkt eenvoudig. Je beantwoordt twintig vragen over hoe je team met AI werkt, hoe je werft, hoe je controleert en hoe je de teamgrootte bepaalt. Het gaat erom dat je je antwoorden naast die van andere engineering leaders legt die de vragenlijst invulden. De score zelf is minder belangrijk. Je ziet of iets waarvan je dacht dat iedereen er moeite mee heeft, alleen bij jou speelt, en waar andere teams verder zijn. We publiceren de resultaten geaggregeerd en geanonimiseerd. Iedereen die meedoet krijgt het rapport en ziet waar hij of zij binnen de benchmark staat ten opzichte van andere deelnemers.
De vier onderdelen zijn niet willekeurig. Het zijn de vier plekken waar we in twee jaar bouwen met deze tools en het beoordelen van de engineers die ze gebruiken hebben gezien dat de manier van werken het verst achterloopt op de tooling.
Hoe jouw team met AI werkt is het productiviteitsonderdeel. Het whitepaper achter deze benchmark begint met drie engineers op dezelfde backlog: een die geen AI gebruikt, een die prompt in één venster, en een die heen en weer gaat tussen vier git worktrees met een agent in elk. Tegen de lunch heeft de derde gedaan wat de eerste donderdag afkrijgt. De vragen hier stellen vast op welke van die drie jouw team daadwerkelijk lijkt, in tegenstelling tot welke het zichzelf vindt.
Hoe je inhuurt is het filteronderdeel. Elke take-home die ergens wordt ingeleverd is nu modelgegenereerd, dus het eindproduct zegt niets over de persoon, en patroonherinnertests meten precies het werk dat agents hebben overgenomen. De vragen hier gaan na of jouw proces ooit een kandidaat ziet werken, met en zonder de tools, of dat het nog steeds alleen de uitkomst beoordeelt.
Hoe je verifieert is het vertrouwensonderdeel. Wanneer het meeste opgeleverde code gegenereerd is, is de echte bijdrage van de engineer validatie: het opsporen van de gehallucineerde API, de subtiel foute logica, het beveiligingslek, vóórdat het wordt uitgerold in plaats van erna. Teams weten zelden hoeveel van wat ze mergen daadwerkelijk is gelezen. De vragen hier maken dat meetbaar, en dit is het onderdeel waar we de meest ongemakkelijke antwoorden verwachten.
Hoe je inschaalt is het planningsonderdeel. In onze projecten draait een project dat in 2024 tien engineers nodig had nu op vier. Of jouw eigen verhouding is veranderd, en of jouw headcount-plan voor 2027 dat weerspiegelt, zegt meer over jouw operationeel model dan welk tooling-onderzoek dan ook.
Twintig vragen, vier onderdelen, een paar eerlijke minuten. Wat je terugkrijgt is het enige wat niemand in deze markt heeft gehad: jouw positie ten opzichte van peers die dezelfde vragen beantwoorden over dezelfde verschuiving, in plaats van weer een mening over wat teams 'zouden moeten' doen.
Het eerste rapport wordt nu samengesteld op basis van vroege reacties, en bijdragers lezen het als eersten. Als je een engineeringteam runt en je de plannen voor 2027 dit kwartaal afrondt, is dit de goedkoopste reality check die er is.
Meld je aan voor het benchmarkrapport. De volledige onderbouwing van de vragen, inclusief beide assessments die we bij engineers afnemen, staat in The Next 10X Engineer.
