Fällan med platåer

Jag skrev nyligen om AI-trötthet, och hävdade att det som ingenjörer upplever inte är en kronisk sjukdom, utan snarare träningsvärk. Man måste bara pusha igenom det, anpassa sig och komma ut starkare.

Det där är allt gott och väl, men det finns mer att berätta om den historien, och det blir alltmer uppenbart. Den verkliga risken som ingenjörsteam står inför just nu är inte utbrändhet. Det är platåer.

Den nya splittringen

Near nog varje senioringenjör använder AI nu. Copilot, Claude, Cursor, Codex, du namnger det. Den delen är avgjord. Om du leder en ingenjörsorganisation, ser du förmodligen en bred antagande och känner dig bra till mods.

Du borde inte göra det.

Antagningsnumret är meningslöst. Vad som betyder något är den splittring som sker under ytan. Ditt team delar sig tyst i två grupper. Det finns ingenjörer som fick en produktivitetsboost och bosatte sig, och ingenjörer som fortsätter att pusha varje vecka. Nya arbetsflöden, nya agentkonfigurationer, nya sätt att bryta ner problem för AI att hantera.

Båda grupperna syns i dina instrumentpaneler som “AI-användare”. Men den ena är på ett progressivt träningsprogram. Den andra stannade vid den första vikten som kändes bekväm.

För sex månader sedan var gapet mellan dessa två grupper knappt synligt. Nu är det uppenbart för alla som uppmärksammar det. Om ytterligare sex månader kommer det att vara strukturellt.

Vad en platå egentligen ser ut som

Ingenjören som platåer är inte fel i den klassiska bemärkelsen. De är kompetenta. De levererar. De använder sin agent för enkla jobb och städar upp efter den. De fick kanske en 20-30% produktivitetsökning och tyckte att det var tillräckligt.

Problemet är att ingenjören bredvid dem inte stannade där. Den ingenjören kör nu multi-agentarbetsflöden, förbättrar verifieringsloopar, bryter ner hela funktioner i AI-exekverbara bitar, granskar på arkitektonisk nivå istället för rad för rad, och levererar med 2-3 gånger sin tidigare takt. Inte för att de är mer begåvade. För att de fortsatte att träna medan alla andra tog en vila som blev en kvartalsvila.

Detta handlar inte om AI-entusiasm eller att vara en tidig antagare. Den tidiga antagningsfasen är över. Detta handlar om kontinuerlig anpassning versus enstaka justering. Och den ackumulerade skillnaden mellan dessa två tillvägagångssätt blir allt svårare att ignorera.

Den konkurrensrelaterade pressen är verklig och accelererar

Om dina team hade lyxen att anpassa sig på sin egen tid, skulle platåproblemet vara ett prestationshanteringproblem. Irriterande, men hanterbart.

Men om du tittar på den bredare situationen i mjukvaruindustrin, är chansen stor att du inte har den lyxen.

Mjukvaruindustrin, i stort sett, skapades för att hjälpa människor med digitalt arbete: hjälpa supportagenter se inkommande ärenden, spåra svar till kunder, hantera arbetsflöden. Nu förskjuter AI-agenter hela arbetsflödet och stör därmed de underliggande SaaS-plattformarna. Utöver det börjar kunderna att ställa en fråga: “Behöver vi fortfarande köpa det här, eller kan vi bygga det själva nu?” AI har börjat minska barriären mellan “köp” och “bygg” för en växande uppsättning användningsfall. Den klibbighet som tidigare skyddade din intäkt försvagas varje kvartal.

Dina platåerade ingenjörer arbetar i en takt som är kalibrerad för en konkurrensmiljö som inte längre existerar.

Citaten som omformade allt för mig

Jag har hört det mer än en gång nu, från produktchefer som rullade upp ärmarna och kodade funktioner, från ingenjörsledare som omformade misslyckade arkitekturer, i olika företag, i olika sammanhang:

“Det var lättare för mig att iterera på det här med mina agenter, än med den ingenjören.”

Första gången jag hörde det, trodde jag att det var överdrift. Tredje gången, insåg jag att det var en ledande indikator.

Så som jag ser det, finns det ingenjörer som kommer att blomstra i den här nya världen och vara “multiplikatorer” av AI-förmågor. För att göra det, måste de vara starka inom två områden, båda som kan utvecklas med tillräcklig inre motivation och intellektuell nyfikenhet:

• De opererar “på samma våg” som deras intressenter (PM, eng chefer, etc). De förstår vad som är bra, så du behöver inte förklara saker för dem. För om de producerar samma antal missförstånd som din kodagent, kommer agenten alltid att vinna den striden. Den är tillgänglig direkt, 24/7, och tröttlös.
• De förbättrar kontinuerligt sina AI-konfigurationer, så att när du ger dem något, vet du att det kommer att göras inte bara bra (se ovan), utan också tillräckligt snabbt för att hålla jämna steg med den nya marknadstakten.

Varför det här är ett ledarskapsproblem, inte ett individuellt

Det är frestande att ramla in det här som ett individuellt ansvar för ingenjörerna. “Håll jämna steg eller bli lämnad efter.” Men om du leder en ingenjörsorganisation, låter den ramen dig slippa undan.

Dina platåerade ingenjörer platåerade inte i ett vakuum. De platåerade för att ingenting i deras miljö pressade dem förbi den initiala justeringen. De nådde en rimlig produktivitetsökning, ingen utmanade dem att gå längre, och tröghet gjorde resten.

Ingenjörerna som fortsatte att pusha? De flesta av dem är självmotiverade. De skulle ha fortsatt oavsett. Men du kan inte bemanna en ingenjörsorganisation helt med självmotiverade pionjärer. Frågan för ledare är: hur flyttar du mitten?

Detta är ett förändringshanteringsproblem, och ett av mina favoritramverk för det kommer från Heath-brödernas bok Switch. Den korta versionen: du måste ge människor en tydlig riktning, göra dem känna varför det betyder något, och forma om miljön så att det nya beteendet är den lättaste vägen. Tillämpat på ingenjörsteam ser det ut så här:

Hitta dina ljusa fläckar och gör dem synliga. Identifiera ingenjörerna som har pushat längst i sina AI-arbetsflöden och låt dem demonstrera för teamet regelbundet. Inte träningspass. Live-genomgångar av riktigt arbete. När mitten av ditt team ser skillnaden mellan deras arbetsflöde och den bästa anpassarens arbetsflöde, skapas en produktiv obehag som ingen order kan matcha.

• Förminska förändringen. “Anta AI” är för abstrakt för att agera på. Den här sprinten, nagla e2e-agenter, nästa sprint rulla ut det över hela organisationen, och så vidare. Specifika hanterbara steg slår ambitiösa transformationsprogram varje gång, och små vinster betyder något.
• Forma om standarderna. Kodifiera verifieringsprocessen i AI-färdigheter, och se till att de distribueras över hela ditt team och över alla deras agenter. Definiera dina arbetsflöden och använd verktygen som stöder det. Gör det nya sättet att arbeta den lättaste vägen, så att människor dras mot det istället för att behöva kämpa sig dit.

Fönstret stängs

Här är den del som gör det här brådskande snarare än bara viktigt.

Just nu är anpassningsgapet en prestationsskillnad. Dina platåerade ingenjörer är långsammare än dina anpassade, men de är fortfarande produktiva. De bidrar fortfarande. Du kan bära dem.

Det fönstret stängs. När AI-förmågor accelererar och konkurrensrelaterad press ackumuleras, ökar den minsta livskraftiga takten för ingenjörsarbete. Den “tillräckligt bra” ingenjören idag är inte garanterad att vara tillräckligt bra nästa kvartal. Inte för att de blev sämre, utan för att golvet flyttades upp.

Organisationerna som lyckas flytta hela sina team upp för anpassningskurvan, inte bara de tidiga antagarna, kommer att ha en ackumulerad strukturell fördel. De som inte gör det kommer att hitta sig själva bemannade för en tävlingspace som inte längre existerar.

Varje ingenjörsledare jag pratar med förstår det här intellektuellt. Mycket få har ändrat hur de kör sina team i respons.

Det finns inget bekvämt tempo

I AI-trötthetsartikeln hävdade jag att värk är beviset på att träning fungerar. Det är fortfarande sant. Men den efterföljande sanningen är svårare: vikten fortsätter att öka.

I en vanlig gym, kan du välja en bekväm vikt och behålla den för alltid. Ingen lägger till vikter på din stång utan att fråga. I den nuvarande mjukvarulandskapet, flyttar varje ny modellrelease, varje ny agentförmåga, varje nytt arbetsflöde som någon figurerar ut och delar, stången. Stå stilla och vikten kommer så småningom att fälla dig.

Det finns inget bekvämt utrymme i mjukvaruindustrin just nu. Inte för enskilda ingenjörer, inte för teamen de arbetar med, inte för företagen som byggs av dessa team. Den enda säkra positionen är kontinuerlig rörelse. Och den enda fråga som betyder något för ingenjörsledare är om hela ditt team rör sig, eller bara de som skulle ha rört sig ändå.