De Plateau-Val

Ik schreef onlangs over AI-moeheid, waarin ik betoogde dat wat ingenieurs meemaken geen chronische aandoening is, maar trainingspijn. Doorbijten, aanpassen, sterker worden.

Dat is allemaal goed en wel, maar er is meer aan die verhaal, en het wordt snel duidelijker. Het echte risico dat ingenieursteams nu tegenkomen, is niet uitputting. Het is het plateau bereiken.

De Nieuwe Scheiding

Bijna elke senior ingenieur gebruikt nu AI. Copilot, Claude, Cursor, Codex, noem maar op. Dat deel is afgerond. Als je een ingenieursorganisatie leidt, zie je waarschijnlijk brede adoptiecijfers en voel je je goed bij het idee.

Je zou je niet goed moeten voelen.

Het adoptiecijfer is nietszeggend. Wat ertoe doet, is de scheiding die eronder plaatsvindt. Je team splitst zich stilzwijgend in twee groepen. Er zijn de ingenieurs die een productiviteitsboost kregen en zich vestigden, en ingenieurs die elke week blijven pushen. Nieuwe workflows, nieuwe agentconfiguraties, nieuwe manieren om problemen te decomponeren voor AI om ze aan te pakken.

Beide groepen verschijnen in je dashboards als “AI-gebruikers.” Maar de ene zit op een progressief trainingsprogramma. De andere stopte bij het eerste gewicht dat comfortabel aanvoelde.

Zes maanden geleden was de kloof tussen deze twee groepen nauwelijks zichtbaar. Nu is het duidelijk voor iedereen die oplet. Over nog eens zes maanden zal het structureel zijn.

Hoe Het Plateau Echt Uitziet

De ingenieur die op een plateau zit, doet niets verkeerd in de traditionele zin. Hij is competent. Hij levert. Hij gebruikt zijn agent voor eenvoudige taken en ruimt op na hem. Hij kreeg misschien een productiviteitslift van 20-30% en noemde het goed genoeg.

Het probleem is dat de ingenieur naast hem niet stopte daar. Die ingenieur draait nu multi-agent workflows, verbetert verificatielussen, decomponeert hele functionaliteiten in AI-uitvoerbare stukken, beoordeelt op architecturaal niveau in plaats van regel voor regel, en levert met 2-3 keer zijn vorige tempo. Niet omdat hij getalenteerder is. Omdat hij bleef trainen terwijl iedereen anders een rustdag nam die uitliep op een rustkwartaal.

Dit gaat niet over AI-enthusiasme of vroeg adopteren. De vroege adoptiefase is voorbij. Dit gaat over continue aanpassing versus eenmalige aanpassing. En het verschil tussen die twee benaderingen wordt onmogelijk te negeren.

De Concurrentiedruk Is Echt En Versnelt

Als je teams de luxe hadden om op hun eigen tempo aan te passen, zou het plateau-probleem een prestatiebeheersingskwestie zijn. Iritant, maar beheersbaar.

Maar als je naar de bredere situatie in de software-industrie kijkt, is de kans groot dat je die luxe niet hebt.

De software-industrie is grotendeels gecreëerd om mensen te helpen met digitaal werk: helpen ondersteunende agenten om inkomende gevallen te zien, antwoorden van klanten te volgen, workflows te beheren. Nu verplaatsen AI-agents de hele workflow en daarmee de onderliggende SaaS-platforms. Bovendien vragen je klanten, nu AI capabeler wordt, een vraag: “Hebben we dit nog nodig, of kunnen we het zelf bouwen?” AI heeft de barrière tussen “kopen” en “bouwen” voor een groeiend aantal use-cases verkleind. De kleefkracht die eerder je inkomsten beschermden, verzwakt elke kwartaal.

Je ingenieurs die op een plateau zitten, werken op een tempo dat is gekalibreerd voor een concurrentieomgeving die niet meer bestaat.

Het Citaten Dat Alles Voor Mij Opnieuw Gaf

Ik heb het meer dan eens gehoord, van productmanagers die hun mouwen oprolden en vibe codeerden, van ingenieursleiders die falende architectuur herontwierpen, bij verschillende bedrijven, in verschillende contexten:

“Het was gemakkelijker voor me om hieraan te werken met mijn agents, dan met die ingenieur.”

De eerste keer dat ik het hoorde, dacht ik dat het hyperbool was. De derde keer, realiseerde ik me dat het een leidende indicator was.

Zoals ik het zie, zijn er ingenieurs die zullen floreren in deze nieuwe wereld en “vermenigvuldigers” van AI-mogelijkheden zullen zijn. Om dat te doen, moeten ze sterk zijn in twee gebieden, die beide zelfontwikkeld kunnen worden met voldoende intrinsieke motivatie en intellectuele nieuwsgierigheid:

• Zij opereren “op dezelfde golflengte” als hun stakeholders (PM’s, eng-managers, etc.). Zij begrijpen wat goed is, zodat je het niet hoeft uit te leggen. Omdat als zij evenveel misverstanden produceren als je codeeragent, de agent die strijd altijd zal winnen. Het is onmiddellijk beschikbaar, 24/7, en niet moe.
• Zij verbeteren constant hun AI-instellingen, zodat wanneer je iets aan hen geeft, je weet dat het niet alleen goed gedaan wordt (zie het bovenstaande punt), maar ook snel genoeg om bij te blijven met het nieuwe markttempo.

Waarom Dit Een Leiderschapsprobleem Is, Niet Een Individueel

Het is verleidelijk om dit te framen als de verantwoordelijkheid van een individuele ingenieur. “Blijf bij of word ingehaald.” Maar als je een ingenieursorganisatie leidt, laat die framing je van de haak.

Je ingenieurs die op een plateau zitten, zijn niet op een plateau geraakt in een vacuüm. Zij zijn op een plateau geraakt omdat niets in hun omgeving hen verder duwde dan de eerste aanpassing. Zij bereikten een redelijk uitziende productiviteitslift, niemand daagde hen uit om verder te gaan, en inertie deed de rest.

De ingenieurs die bleven pushen? De meesten van hen zijn zelfgemotiveerd. Zij zouden toch blijven pushen. Maar je kunt een ingenieursorganisatie niet alleen bemannen met zelfgemotiveerde pioniers. De vraag voor leiders is: hoe verplaats je het midden?

Dit is een veranderingsbeheersingsprobleem, en een van mijn favoriete kaders hiervoor komt uit het boek Switch van de Heath-broers. De korte versie: je moet mensen een duidelijke richting geven, hen laten voelen waarom het ertoe doet, en de omgeving herschappen zodat het nieuwe gedrag de weg van de minste weerstand is. Toegepast op ingenieursteams, ziet dat er zo uit:

Vind je heldere plekken en maak ze zichtbaar. Identificeer de ingenieurs die het verst zijn gegaan in hun AI-workflows en laat hen demo’s geven aan het team. Niet trainingsessies. Live walkthroughs van echt werk. Wanneer het midden van je team het verschil ziet tussen hun workflow en die van de top-adapter, creëert het productieve ongemak dat geen enkel mandaat kan evenaren.

• Verklein de verandering. “AI adopteren” is te abstract om op te handelen. Deze sprint, nagel de e2e-agents testen, volgende sprint rol het uit over de hele organisatie, enz. Specifieke, beheersbare stappen verslaan ambitieuze transformatieprogramma’s elke keer, en kleine overwinningen tellen.
• Herschap de standaardwaarden. Codificeer het verificatieproces in AI-vaardigheden en zorg ervoor dat die worden uitgerold over je team en over al hun agents. Definieer je workflows en gebruik de tooling die dat ondersteunt. Maak de nieuwe manier van werken de weg van de minste weerstand, zodat mensen ernaartoe neigen in plaats van ernaar te moeten vechten.

Het Venster Sluit

Dit is het deel dat het dringend maakt in plaats van alleen maar belangrijk.

Op dit moment is de aanpassingskloof een prestatieverschil. Je ingenieurs die op een plateau zitten, zijn langzamer dan je aangepaste ingenieurs, maar ze zijn nog steeds productief. Ze dragen nog steeds bij. Je kunt ze nog steeds dragen.

Dat venster sluit. Naarmate AI-mogelijkheden versnellen en concurrentiedruk samenkomen, stijgt het minimum viable tempo van ingenieurswerk. De “goede genoeg” ingenieur van vandaag is niet gegarandeerd goed genoeg voor het volgende kwartaal. Niet omdat hij slechter wordt, maar omdat de vloer omhoog is gegaan.

De organisaties die erin slagen om hun hele teams omhoog te krijgen op de aanpassingscurve, niet alleen de vroege adopters, zullen een samengaand structureel voordeel hebben. Degene die dat niet doen, zullen merken dat ze zijn bemand voor een concurrentietempo dat niet meer bestaat.

Elke ingenieursleider die ik spreek, begrijpt dit intellectueel. Weinigen hebben hun manier van leidinggeven veranderd als reactie. De kloof tussen begrip en actie is een soort plateau op zich.

Er Is Geen Comfortabel Tempo

In het AI-moeheidstuk betoogde ik dat pijn het bewijs is dat training werkt. Dat is nog steeds waar. Maar de follow-up waarheid is harder: het gewicht blijft omhoog gaan.

In een normale sportschool kun je een comfortabel gewicht kiezen en dat altijd vasthouden. Niemand voegt gewichten toe aan je stang zonder het te vragen. In het huidige software-landschap verplaatst elke nieuwe modelrelease, elke nieuwe agentmogelijkheid, elke nieuwe workflow die iemand uitvindt en deelt, de stang. Blijf staan en het gewicht zal je uiteindelijk pinnen.

Er is geen comfortabele ruimte in de software-industrie op dit moment. Niet voor individuele ingenieurs, niet voor de teams waar ze voor werken, niet voor de bedrijven die die teams bouwen. De enige veilige positie is continue beweging. En de enige vraag die ertoe doet voor ingenieursleiders is of je hele team in beweging is, of alleen degene die sowieso al in beweging waren.