Plateaufellen

Jeg skrev nylig om AI-utmattelse, og argumenterte for at det ingenjørene opplever ikke er en kronisk tilstand, men treningssmerter. Kom deg gjennom det, tilpass deg, og bli sterkere.

Det er alles godt og greit, men det er mer til historien, og det blir raskt mer åpenbart. Den virkelige risikoen som møter ingeniørteamene nå, er ikke utbrenthet. Det er platåering.

Den nye splitten

Nesten hver eneste senioringeniør bruker nå AI. Copilot, Claude, Cursor, Codex, du navngir det. Den delen er avgjort. Hvis du leder en ingeniørorganisasjon, ser du sannsynligvis bredt adopsjonsnummer og føler deg godt til mote.

Du burde ikke.

Adopsjonsnummeret er meningsløst. Det som betyr noe, er splitten som skjer under det. Ditt team deler seg stille inn i to grupper. Det er ingeniører som fikk en produktivitetsøkning og slo seg til ro, og ingeniører som fortsatt presser hver eneste uke. Nye arbeidsflyter, nye agentkonfigurasjoner, nye måter å dekomponere problemer for AI å håndtere.

Begge grupper vises i dine dashboards som “AI-adopterere”. Men den ene er på et progressivt treningprogram. Den andre stoppet ved den første vekten som føltes komfortabelt.

For seks måneder siden, var gapet mellom disse to gruppene knapt synlig. Nå er det åpenbart for alle som betaler attention. Om ytterligere seks måneder, vil det være strukturelt.

Hva platå egentlig ser ut som

Ingeniøren som har platåert, gjør ingenting galt i den tradisjonelle forstand. De er kompetente. De leverer. De bruker sin agent for enkle jobber og rydder opp etter den. De fikk kanskje en 20-30% produktivitetsøkning og kalte det ferdig.

Problemet er at ingeniøren ved siden av dem, stoppet ikke der. Den ingeniøren kjører nå multi-agent-arbeidsflyter, forbedrer verifiseringssykler, dekomponerer hele funksjoner i AI-utførbare biter, gjennomgår på arkitektonisk nivå i stedet for linje-for-linje, og leverer med 2-3 ganger sin tidligere fart. Ikke fordi de er mer talentfulle. Fordi de fortsatte å trene mens alle andre tok en hvile dag som ble til en hvile kvartal.

Dette handler ikke om AI-entusiasme eller å være en tidlig adopter. Tidlig adopsjonsfase er over. Dette handler om kontinuerlig tilpasning versus enkelt tilpasning. Og den komponenterende forskjellen mellom disse to tilnærmingene blir umulig å ignorere.

Konkurransetrykket er reelt og akselererende

Hvis ditt team hadde luksusen av å tilpasse seg på deres egen tidsplan, ville platåproblemet være et ytelsesledelsesproblem. Irriterende, men håndterbart.

Men hvis du ser på den bredere situasjonen i programvareindustrien, er sjansen stor at du ikke har den luksusen.

Programvareindustrien, for det meste, ble skapt for å hjelpe mennesker med digitalt arbeid: hjelpe supportagenter se innkommende saker, spore svar til kunder, håndtere arbeidsflyter. Nå er AI-agenter i ferd med å erstatte hele arbeidsflyten, og med det, forstyrre de underliggende SaaS-plattformene. I tillegg, med AI som blir mer kapabel dag for dag, begynner dine kunder å stille spørsmålet: “Trenger vi fortsatt å kjøpe dette, eller kan vi bygge det selv nå?” AI har startet å krympe barrieren mellom “kjøp” og “bygge” for en utvidende sett av brukstilfeller. Den limningen som tidligere beskyttet din inntekt, svekkes hver kvartal.
Dine platåerte ingeniører opererer med en fart som er kalibrert for en konkurransemiljø som ikke lenger eksisterer.

Citaten som omdefinerte alt for meg

Jeg har hørt det mer enn en gang nå, fra produktledere som rullet opp ermene og kode-features, fra ingeniørledere som redesignet feilende arkitekturer, i forskjellige selskaper, i forskjellige sammenhenger:

“Det var enklere for meg å iterere på dette med mine agenter, enn med den ingeniøren.”

Første gangen jeg hørte det, trodde jeg det var hyperbol. Tredje gangen, realiserte jeg at det var en ledende indikator.

Slik jeg ser det, er det ingeniører som vil trives i denne nye verden og være “multiplikatorer” av AI-egenskaper. For å gjøre det, må de være sterke i to områder, begge som kan selvutvikles med nok intrinsisk motivasjon og intellektuell nysgjerrighet:

• De opererer “på samme bølge” som deres interessenter (PM-er, ingeniørledere osv). De forstår hva som ser bra ut, så du ikke må overforklare ting for dem. Fordi hvis de produserer like mange misforståelser som din kodeagent, vil agenten alltid vinne den kampen. Den er tilgjengelig øyeblikkelig, 24/7, og utmattelig.
• De forbedrer kontinuerlig sine AI-oppsett, så når du overleverer noe til dem, vet du at det kommer til å bli gjort ikke bare bra (se punkt ovenfor), men også raskt nok til å holde tritt med den nye markedstempo.

Hvorfor dette er et ledelsesproblem, ikke et individuelt

Det er fristende å ramme dette som et individuelt ingeniørens ansvar. “Hold følge eller bli latt tilbake.” Men hvis du leder en ingeniørorganisasjon, lar den rammen deg slippe unna.

Dine platåerte ingeniører platåerte ikke i en vakuum. De platåerte fordi ingenting i deres miljø presset dem forbi den initielle tilpasningen. De traff en rimelig serlig produktivitetsøkning, ingen utfordret dem til å gå videre, og inerti gjorde resten.

Ingeniørerne som fortsatte å presse? De fleste av dem er selv-motiverte. De ville ha presset uansett. Men du kan ikke bemanne en ingeniørorganisasjon helt med selv-motiverte frontier-sekere. Spørsmålet for ledere er: hvordan flytter du midten?

Dette er et endringsledelsesproblem, og ett av mine favoritt-rammeverk for det kommer fra Heath-brødrenes bok Switch. Den korte versjonen: du må gi folk en klar retning, gjøre dem føle hvorfor det betyr noe, og omforme miljøet så det nye atferden er den letteste vei. Applisert til ingeniørteam, ser det ut som:

Finne dine lyse punkter og gjøre dem synlige. Identifiser ingeniørerne som har presset lengst i sine AI-arbeidsflyter og la dem demo til teamet regelmessig. Ikke treningsøkter. Live-gjennomgang av virkelig arbeid. Når midten av ditt team ser forskjellen mellom deres arbeidsflyt og topp-adapterens arbeidsflyt, skaper det en produktiv ubehag som ingen mandat kan matche.

• Krympe endringen. “Adopter AI” er for abstrakt til å handle på. Denne sprinten, nagle e2e agentic testing, neste sprint rulle det ut over hele organisasjonen, og så videre. Spesifikke, håndterbare steg slår ambisiøse transformasjonsprogrammer hver gang, og små seirer betyr noe.
• Omforme standardene. Kodifiser verifiseringsprosessen i AI-ferdigheter, og sikre at de er deployert over hele ditt team og over alle deres agenter. Definer dine arbeidsflyter og bruk verktøy som støtter det. Gjør den nye måten å arbeide på den letteste vei, så folk drifter mot den i stedet for å måtte slåss for å komme dit.

Vinduet lukker

Her er delen som gjør dette urgent i stedet for bare viktig.

Nå, er tilpasningsgapet en ytelsesforskjell. Dine platåerte ingeniører er langsommere enn dine tilpassede, men de er fortsatt produktive. De bidrar fortsatt. Du kan bære dem.

Vinduet lukker. Mens AI-egenskaper akselererer og konkurranse-trykket forsterkes, stiger minimumsviable fart for ingeniørarbeid. “God nok”-ingeniøren i dag, er ikke garantert å være god nok neste kvartal. Ikke fordi de ble dårligere, men fordi gulvet flyttet opp.

Organisasjonene som klarer å flytte hele sine team opp tilpasningskurven, ikke bare tidlige adopterer, vil ha en komponenterende strukturell fordel. De som ikke gjør det, vil finne seg selv bemannet for en konkurranse-fart som ikke lenger eksisterer.

Hvert eneste ingeniørleder jeg snakker med, forstår dette intellektuelt. Veldig få har endret hvordan de kjører sine team i respons.

Det er ingen komfortabel fart

I AI-utmattelse-artikkelen, argumenterte jeg for at smerter er bevis på at trening fungerer. Det er fortsatt sant. Men følgende sannhet er hardere: vekten fortsetter å øke.

I en normal treningssal, kan du velge en komfortabel vekt og holde den for alltid. Ingen legger på plater på din stang uten å spørre. I den nåværende programvarelandskapet, hver ny modellutgivelse, hver ny agent-egenskap, hver ny arbeidsflyt som noen kommer på og deler, flytter stangen. Stå stille og vekten vil til slutt felle deg.

Det er ingen komfortabel plass i programvareindustrien nå. Ikke for enkelte ingeniører, ikke for teamene de jobber på, ikke for selskapene teamene bygger. Den eneste trygge posisjonen er kontinuerlig bevegelse. Og den eneste spørsmålet som betyr noe for ingeniørledere, er om hele ditt team beveger seg, eller bare de som ville ha beveget seg uansett.