Den nye skilleveggen

Jeg skrev nylig om AI-utmattelse, og argumenterte for at det ingenjører opplever ikke er en kronisk tilstand, men snarere treningsverk. Gjennomfør det, tilpass deg, og bli sterkere.

Dette er alt godt og greit, men det er mer å si om denne historien, og det blir raskt mer og mer åpenbart. Den virkelige risikoen for ingeniørteamene nå er ikke utmattelse. Det er å havne på en platå.

Den nye skilleveggen

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

Du bør ikke gjøre det.

Utbredelsesnummeret er meningsløst. Det som betyr noe, er skilleveggen som skjer under overflaten. Ditt team deler seg stille og rolig 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. Nytt arbeidsflyt, nye agentkonfigurasjoner, nye måter å dekomponere problemer for AI å håndtere.

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

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 en platå egentlig ser ut som

Ingeniøren som har havnet på en platå, gjør ingenting galt i klassisk 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 ikke stoppet der. Den ingeniøren kjører nå multi-agent-arbeidsflyt, forbedrer verifiseringsløkker, dekomponerer hele funksjoner i AI-utførbare deler, gjennomgår på arkitektonisk nivå i stedet for linje for linje, og leverer med 2-3 ganger sin tidligere hastighet. Ikke fordi de er mer talentfulle. Fordi de fortsatt trener mens alle andre tar en hvile dag som utviklet seg til en kvartals hvile.

Dette handler ikke om AI-entusiasme eller å være en tidlig tilpasser. Tidlig tilpasningsfasen er over. Dette handler om kontinuerlig tilpasning versus enkelttilpasning. Og forskjellen mellom disse to tilnærmingene blir umulig å ignorere.

Konkurransetrykket er reelt og akselererende

Hvis dine team hadde luksusen av å tilpasse seg på egen tid, 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 ble i stor grad skapt for å hjelpe mennesker med digitalt arbeid: å hjelpe supportagenter se innkommende saker, spore svar til kunder, håndtere arbeidsflyt. Nå er AI-agenter i ferd med å erstatte hele arbeidsflyten og med det undergrave de underliggende SaaS-plattformene. I tillegg, med AI som blir mer kapabel dag for dag, begynner dine kunder å stille spørsmål: “Trenger vi fortsatt å kjøpe dette, eller kan vi bygge det selv nå?” AI har startet å redusere barrieren mellom “kjøp” og “bygg” for en økende mengde brukstilfeller. Den fasthet som tidligere beskyttet din inntekt, svekkes hver kvartal.

Dine ingeniører som har havnet på en platå, opererer med en hastighet som er justert for en konkurranse som ikke lenger eksisterer.

Citaten som endret 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 overdrivelse. Tredje gangen, innsett jeg at det var en ledende indikator.

Jeg ser det slik: Det er ingeniører som vil trives i denne nye verden og være “multiplikatorer” av AI-kapasiteter. For å gjøre det, må de være sterke i to områder, begge kan utvikles selv 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 er bra, så du ikke trenger å 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 utmattingsfri.
• De forbedrer kontinuerlig sine AI-oppsett, så når du gir noe til dem, vet du at det vil bli gjort ikke bare bra (se punkt ovenfor), men også raskt nok til å holde tritt med den nye markedstempoet.

Hvorfor dette er et ledelsesproblem, ikke et individuelt problem

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

Dine ingeniører som har havnet på en platå, havnet ikke på en platå i en vakuum. De havnet på en platå fordi ingenting i deres omgivelse presset dem forbi den innledende tilpasningen. De traff en rimelig seende produktivitetsøkning, ingen utfordret dem til å gå videre, og trøkket gjorde resten.

Ingeniørene som fortsatt presser? De fleste av dem er selv-motiverte. De ville presset uansett. Men du kan ikke bemanne en ingeniørorganisasjon helt med selv-motiverte frontier-seekere. 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. Kort versjon: du må gi folk en klar retning, gjøre dem føle hvorfor det betyr noe, og omforme omgivelsen så det nye oppførslet er den letteste veien. Applisert på ingeniørteam, ser det slik ut:

Finn dine lyse punkter og gjør dem synlige. Identifiser ingeniørene som har presset lengst i sine AI-arbeidsflyt og la dem demonstrere for teamet regelmessig. Ikke treningsøkter. Live-gjennomgang av virkelig arbeid. Når midten av ditt team ser forskjellen mellom deres arbeidsflyt og topp-tilpasnings-arbeidsflyten, skaper det en produktiv ubehag som ingen påbud kan matche.

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

Vinduet lukker

Her er delen som gjør dette急t rather enn bare viktig.

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

Det vinduet lukker. Mens AI-kapasiteter akselererer og konkurransetrykket forsterkes, stiger den minste mulige hastigheten 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 seg opp.

Organisasjonene som klarer å flytte hele sine team opp tilpasningskurven, ikke bare de tidlige tilpasserne, vil ha en sammensatt strukturell fordel. De som ikke gjør det, vil finne seg selv bemannet for en konkurransehastighet som ikke lenger eksisterer.

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

Det finnes ingen komfortabel hastighet

I AI-utmattelsesartikkelen, argumenterte jeg for at sårhet er bevis på at trening fungerer. Det er fortsatt sant. Men følgende sannhet er hardest: vekten øker kontinuerlig.

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

Det finnes 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 det 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.