Een AI-native engineeringteam leiden: wat het werk werd toen output niet meer schaars was (2026)

Diagram met kapotte engineeringmetrics naast drie dingen die leiders moeten beschermen: begrip, oordeel en autonomie

Het meeste dat over AI en engineeringteams wordt geschreven, gaat over personeel: wie je aanneemt, wie je ontslaat. Er wordt veel minder geschreven over het deel dat de week van een founder echt opslokt: het leiden van de mensen die er nog zijn. Dat werk veranderde stiller en ingrijpender dan de rekensom van het aannemen, en de verandering heeft één onderliggende oorzaak. In de hele geschiedenis van software was output de schaarse grondstof. Leiden ging grotendeels over er meer van krijgen: blokkades wegnemen, prioriteren, focus beschermen, aannemen. Output is niet meer schaars.

Wat nu schaars is, zijn begrip, oordeel en de bereidheid van goede engineers om dit werk te blijven doen. Die drie zijn wat een AI-native engineeringleider echt managet, en geen ervan staat op de dashboards die de meeste teams nog gebruiken. Dit is wat er kapotgaat, wat de teams die het goed doen hebben ontdekt, en waar founders het ongemerkt mis hebben.

Je metrics werden ruis

Begin bij de meetinstrumenten, want leiden op basis van kapotte cijfers is erger dan leiden zonder cijfers. Als agents het grootste deel van de gecommitte code genereren, meten regels code, snelheid van pull requests en doorlooptijd niet meer wat je denkt dat ze meten. Ze meten dan hoeveel je tooling genereerde, en dat is een budgetbeslissing, geen prestatiesignaal. Elk team kan ze vanmiddag verdubbelen.

De metrics die overleefden, zijn de metrics die de doorstroom door de beperking volgen in plaats van het volume dat erin gaat. De diepte van de reviewwachtrij en de frequentie van contextwisselingen zijn de nuttige voorlopende indicatoren: ze voorspellen bottlenecks voordat de opleveringscijfers ze laten zien, omdat ze het deel van de pijplijn meten dat niet sneller werd. Daarnaast zijn de praktijken die het overnemen waard zijn beslissnelheid, naleving van beleid en cohortanalyse om het manipuleren van metrics op te sporen, want een scorekaart die volume beloont in een tijd van gratis volume wordt binnen één sprint bespeeld, meestal zonder dat iemand dat bedoelt.

Eén eerlijke kanttekening: de gemeten productiviteitswinst door AI verschilt enorm tussen teams, en het verschil volgt hoeveel een team investeerde in evaluatie, governance en het loodgieterswerk van integratie, niet welk model het koos. De grens van wat modellen kunnen, is zelden de bottleneck. Alles tussen een frontiermodel en een meetbaar resultaat wel.

Begripsschuld is de verplichting die niemand boekt

Het nuttigste begrip dat ik dit jaar benoemd zag, is begripsschuld: engineers die snel opleveren zonder de systemen waarin ze opleveren twee of drie lagen diep te begrijpen, en die geleidelijk het diagnostische en redenerende vermogen verliezen dat hen waardevol maakte. Het is de zus van technische schuld en een stuk moeilijker te zien, omdat de code er goed uitziet. Het tekort komt pas boven tijdens een incident, als niemand in het gesprek kan beredeneren waarom het systeem zich gedraagt zoals het doet.

De diagnose is verfrissend low-tech: wekelijkse demo's. Geen statusupdates — demo's, waarin een engineer doorloopt wat hij of zij heeft gebouwd en vragen over het waarom beantwoordt. Of een team zijn eigen werk kan uitleggen, is een veel beter signaal dan of het er meer van produceert, en in tegenstelling tot elke dashboardmetric kan een agent het niet bespelen. Het leidende principe, van de teams die dit bewust doen: besteed het sleurwerk uit, niet het denken.

De kwaliteitsvraag, beantwoord

Dit is geen betoog dat code die met AI is geschreven slechter is. Shopify meldt terugdraaipercentages voor met AI geschreven code die ongeveer gelijk zijn aan hun basislijn van vóór AI — gelijke kwaliteit is haalbaar. Het risico is niet dat de code slecht is. Het is dat mensen hem niet meer begrijpen, en dat kost je dit kwartaal niets en alles tijdens je eerste serieuze storing.

Standaardiseer infrastructuur, geen tools

De meest gemaakte leiderschapsfout op dit moment is een tool verplichten. Een founder leest dat een bepaalde assistent voorloopt, verklaart dat het team die gaat gebruiken en behandelt adoptie als een compliancemetric. Dat is de verkeerde laag om te standaardiseren, en het kost je goodwill zonder blijvend voordeel — de ranglijst is al veranderd voordat de uitrol klaar is.

De aanpak van Shopify is het betere patroon: in plaats van één assistent te verplichten, bouwden ze een interne LLM-proxy — een centrale gateway die verzoeken van Claude Code, Copilot, Cursor of wat dan ook via één platform routeert. Dat geeft de leiding wat ze echt nodig heeft: kostenbeheersing, gebruiksanalyse per team en project, en de mogelijkheid om van model te wisselen zonder iemands workflow aan te raken. Engineers houden hun tools. Het bedrijf houdt zijn optionaliteit. De redenering is ontwapenend eerlijk: niemand weet nog welk bedrijf, welke workflow of welk model gaat winnen.

Dit is te veralgemeniseren. Standaardiseer wat duur is om te veranderen en onzichtbaar voor de individuele engineer — de gateway, de evaluatie-harness, de reviewvereisten, het deploymentpad. Laat wat goedkoop is om te veranderen en heel persoonlijk — editor, assistent, promptstijl — met rust.

Twee releaselagen, zodat snelheid niet meer vecht met kwaliteit

Als output zich vermenigvuldigt, wordt het releaseproces de plek waar leiderschap echt plaatsvindt, en een enkele poort naar productie verandert in een wachtrij met een manager vooraan die haastige beslissingen neemt. Het antwoord van Ramp is een systeem met twee lagen: teams deployen naar early access wanneer ze klaar zijn en bereiken zo ongeveer 10% van de klanten, en voor algemene beschikbaarheid is bewijs nodig volgens een vaste checklist — onderbouwing van de feature, demovideo, KPI-overzicht, klantfeedback, analyse van de gebruikersreis, gereedheid van het team, uitrolstrategie — waarbij de leiding reviews binnen 48 uur afhandelt.

Het inzicht eronder is het verinnerlijken waard: snelheid en kwaliteit zijn geen afweging meer zodra je twee releaselagen hebt. Engineers kunnen continu opleveren, en dat maakt het werk prettig. Het bedrijf krijgt een echte lat voordat iets iedereen bereikt. En cruciaal: de leider is niet langer de bottleneck bij elke afzonderlijke beslissing, omdat de checklist vastlegt wat "klaar" betekent in plaats van dat in het hoofd van één persoon te laten.

De sentimentkloof die founders verkeerd lezen

Dit is het deel dat te weinig gewicht krijgt, en het is een leiderschapsprobleem, geen technisch probleem. Ongeveer 84% van de developers gebruikt AI-tools of is dat van plan — maar het sentiment is gedaald, en ongeveer 46% zegt te wantrouwen wat die tools opleveren. De grootste frustratie is niet dat AI nutteloos is; het is de specifieke ellende van "bijna goed" output en het sleurwerk van code debuggen die niemand heeft geschreven.

Adoptie is geen instemming. Als je hoog toolgebruik leest als bewijs dat je team blij is met de overgang, lees je een getal dat dat niet zegt. En op de fora waar engineers vrijer praten, zijn de klachten consistent en concreet: opgelegde productiviteitsverhogingen, opgelegde metrics, druk om de hele dag door machines gegenereerde code te reviewen, en een gevoeld verlies van hun eigen vakontwikkeling. Sommigen zeggen ronduit dat ze liever minder verdienen dan vijftig uur per week agents te orkestreren in plaats van het vak te beoefenen waarvoor ze tekenden.

Zet dat af tegen wat de tevredenheid van developers echt drijft, en dat is volgens enquêtes steeds weer autonomie en vertrouwen, nog vóór beloning. Merk dan op dat het standaardspeelboek — verplicht de tool, meet de adoptie, verhoog het outputdoel — juist autonomie en vertrouwen aantast. Zo eindigt een leider met een team dat veel AI gebruikt, zijn cijfers haalt en stilletjes gaat solliciteren.

Geef het voorbeeld, verplicht het niet

Het meest effectieve adoptieverhaal dat ik tegenkwam, bevat helemaal geen verplichting. Shopify-VP Farhan Thawar stimuleerde adoptie door zijn eigen gebruik te laten zien en het te brengen als hefboom in plaats van als genialiteit: "Ik zei niet: kijk eens hoeveel werk ik heb gedaan en hoe slim ik ben. Ik zei: 'Kijk eens hoe lui ik ben.'" Die framing verspreidde zich tot buiten engineering, omdat ze mensen toestemming gaf in plaats van een verplichting.

Ze lost ook een statusprobleem op dat leiders vaak missen. Als AI-gebruik verplicht is en wordt gemeten, wordt het gebruiken ervan een bekentenis dat je hulp nodig had. Als een senior leider het openlijk gebruikt om saai werk te vermijden, wordt het wat het zou moeten zijn: een tool die goede engineers gebruiken omdat ze betere dingen te doen hebben. Die twee framings leveren met identieke tooling heel verschillende culturen op.

Leid voor je fase, niet voor het essay dat je las

Een nuttige correctie op dit alles: het juiste technische leiderschap verandert met de teamgrootte. Van seed tot ongeveer tien engineers wil je bouwers die zelf de handen uit de mouwen steken en op snelheid optimaliseren, geen architecten die plannen voor een schaal die je niet hebt. Tussen tien en twintig ligt het echte kantelpunt, waar onomkeerbare architectuurbeslissingen — datastores, DevOps-model, testinfrastructuur — uitharden tot culturele fundamenten die heel moeilijk terug te draaien zijn. Tussen twintig en vijftig wordt de leiderschapsvraag diagnostisch: zijn je problemen mensenproblemen of architectuurproblemen, en past je structuur bij het antwoord?

De meeste founders die dit lezen, zitten in de eerste categorie, en het eerlijke advies is dat je het meeste van het bovenstaande apparaat nog niet nodig hebt. Je hebt wekelijkse demo's nodig, een gateway in plaats van een verplichte tool, en de discipline om je eigen systeem te blijven begrijpen.

Wat je deze maand verandert

Haal volumemetrics uit je reviews. Als regels code, gemergede PR's of storypoints op een dashboard van de leiding staan, haal ze weg. Vervang ze door de diepte van de reviewwachtrij en de tijd tot de eerste review.
Begin met wekelijkse demo's, met vragen. Vijftien minuten: iemand laat zien wat er is gebouwd en beantwoordt "waarom"-vragen. Dit is je enige echte instrument voor begripsschuld.
Zet een gateway voor de modellen, geen verplichting voor de engineers. Centraliseer routering, kosten en analyse; laat mensen hun eigen assistent kiezen.
Splits je releases in twee lagen. Continu opleveren aan een kleine groep, een bewijschecklist voor alle anderen. Schrijf de checklist op, zodat "klaar" niet meer alleen in je hoofd bestaat.
Vraag naar vertrouwen, niet naar gebruik. In je volgende één-op-ééngesprekken: hoeveel van wat de tools je geven vertrouw je echt, en waar kost "bijna goed" je de meeste tijd? De antwoorden zijn je echte roadmap.
Verschuif budget van tools naar mensen. Organisaties besteden ongeveer 93% van hun AI-budget aan technologie en 7% aan training, proces en verandermanagement. Als jouw verdeling daarop lijkt, is herverdelen de goedkoopste verbetering die er is.
Gebruik het zelf, zichtbaar, voor de saaie delen. Toestemming verspreidt zich sneller dan beleid.

Dat laatste budgetcijfer vat het hele argument samen in één verhouding. Teams besteden bijna alles aan capaciteit en bijna niets aan de mensen die het moeten opnemen, en vragen zich dan af waarom de adoptie ongelijk is en het sentiment daalt. De beperking was nooit het model.

De leiders die goed uit dit tijdperk komen, zijn niet degenen die het snelst adopteerden. Het zijn degenen wier engineers het systeem nog begrijpen, nog hun oordeel gebruiken over wat er gebouwd moet worden, en er over twee jaar nog willen zijn. Output was nooit het moeilijke deel van het werk. Het leek alleen zo.