De Plateau-Val

Ik schreef onlangs over AI-moeheid, waarin ik betoogde dat wat ingenieurs meemaken niet een chronische aandoening is, maar trainingspijn. Doorbreek het, pas aan, kom sterker uit.

Dat is allemaal goed en klopt, maar er is meer aan dat verhaal, en het wordt snel duidelijker. Het echte risico waar engineeringteams nu mee te maken krijgen, is niet uitputting. Het is plateauën.

De Nieuwe Scheiding

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

Je zou je niet goed moeten voelen.

Het adoptiecijfer is betekenisloos. Wat ertoe doet, is de scheiding die eronder plaatsvindt. Je team deelt zich stilzwijgend op 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.

Wat Plateau Echt Lijkt

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 productiviteitsverbetering 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 functies in AI-uitvoerbare stukken, beoordeelt op architectuurniveau in plaats van regel voor regel, en levert met een snelheid van 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 tijd 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 bij ondersteuningsagenten die inkomende gevallen zien, het bijhouden van antwoorden aan klanten, het beheren van workflows. Nu verplaatsen AI-agenten de hele workflow en daarmee de onderliggende SaaS-platforms. Bovendien begint AI de drempel tussen “kopen” en “zelf bouwen” voor een groeiend aantal use-cases te verkleinen. De kleefkracht die eerder je omzet beschermden, verzwakt elke kwartaal.

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

De Quote Die Alles Voor Mij Opnieuw Formuleerde

Ik heb het meer dan eens gehoord, van productmanagers die hun mouwen oprolden en vibe-coded functies, van engineeringleiders die falende architectuur ontwierpen, bij verschillende bedrijven, in verschillende contexten:

“Het was gemakkelijker voor me om dit te itereren met mijn agenten 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, dus je hoeft dingen niet te overexpliceren. Omdat als zij evenveel misverstanden produceren als je coderingsagent, de agent die strijd altijd zal winnen. Het is direct beschikbaar, 24/7, en niet moe.
• Zij verbeteren constant hun AI-instellingen, dus als je iets aan hen geeft, weet je 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 Probleem

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

Je ingenieurs die op een plateau zitten, zijn niet in een vacuüm op een plateau beland. Zij zijn op een plateau beland omdat niets in hun omgeving hen verder duwde dan de initiële aanpassing. Zij haalden een redelijk ogende productiviteitsverbetering, niemand daagde hen uit om verder te gaan, en de inertie deed de rest.

De ingenieurs die bleven pushen? De meesten van hen zijn zelfgemotiveerd. Zij zouden toch pushen. Maar je kunt een engineeringorganisatie niet volledig bemannen met zelfgemotiveerde pioniers. De vraag voor leiders is: hoe verplaats je de middengroep?

Dit is een veranderingsbeheersingsprobleem, en een van mijn favoriete kaders voor dit is 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 zo vormgeven dat het nieuwe gedrag de weg van de minste weerstand is. Toegepast op engineeringteams ziet dit eruit als:

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. Geen trainingsessies. Live walkthroughs van echt werk. Wanneer de middengroep van je team het verschil ziet tussen hun workflow en die van de topadapter, creëert dit productieve ongemak dat geen enkel mandaat kan evenaren.

• Verklein de verandering. “AI adopteren” is te abstract om op te acteren. Deze sprint, nagel de e2e agentic testing, volgende sprint rol het uit over de hele organisatie, enz. Specifieke beheersbare stappen verslaan ambitieuze transformatieprogramma’s elke keer, en kleine overwinningen tellen.
• Vorm de standaardwaarden om. Codificeer het verificatieproces in AI-vaardigheden en zorg ervoor dat deze worden uitgerold over je team en over al hun agenten. Definieer je workflows en gebruik de tooling die dit ondersteunt. Maak de nieuwe manier van werken de weg van de minste weerstand, zodat mensen ernaartoe zweven in plaats van er moeite voor te moeten doen.

Het Venster Sluit

Dit is het deel dat dit 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 dragen.

Dat venster sluit. Naarmate AI-mogelijkheden versnellen en concurrentiedruk zich opstapelt, stijgt het minimum viable tempo van engineeringwerk. De “goede genoeg” ingenieur van vandaag is niet gegarandeerd goed genoeg voor volgend kwartaal. Niet omdat hij slechter wordt, maar omdat de vloer omhoogging.

De organisaties die erin slagen om hun hele teams omhoog te krijgen op de aanpassingscurve, niet alleen de vroege adopters, zullen een structurele voorsprong hebben. Degenen die dat niet doen, zullen ontdekken dat ze zijn bemand voor een concurrentietempo dat niet meer bestaat.

Elke engineeringleider die ik spreek, begrijpt dit intellectueel. Zeer weinigen hebben hun teams aangepast in reactie hierop. De kloof tussen begrip en actie is op zichzelf een soort plateau.

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 moeilijker: het gewicht blijft toenemen.

In een normale sportschool kun je een comfortabel gewicht kiezen en dat voor altijd vasthouden. Niemand voegt platen toe aan je stang zonder het te vragen. In het huidige softwarelandschap verplaatst elke nieuwe modelrelease, elke nieuwe agentmogelijkheid, elke nieuwe workflow die iemand uitvindt en deelt, de stang. Blijf stilstaan en het gewicht pind je uiteindelijk.

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 engineeringleiders is of je hele team in beweging is, of alleen degenen die dat toch zouden doen.