Detta är inte en artikel vars poäng är "AI gjorde minsann fel en gång så bäst att fortsätta som innan, det här är ändå mest hajp". Inte heller är poängen att alla borde rita om sin organisation imorgon för nu är allting helt annorlunda. Tekniken vi har tillgång till idag kommer inte försvinna och väldigt sannolikt kommer den bara att förbättras. Men i vilken takt det kommer ske och vilka effekter det kommer få går bara att spekulera i. När det nu är så mycket som händer är det lätt att få alldeles för bråttom att ändra allt utan att tänka efter lite först. Känna stress för att alla andra verkar redan kommit igång så då vill man börja springa innan man går.

Jag tror att många underskattar vad som faktiskt händer när utvecklare börjar använda AI för att skriva kod.

Det finns en föreställning om att AI gör att man inte längre behöver utvecklare eller att ett utvecklingsteam helt plötsligt kan producera tio gånger så mycket. I en hel del moment kan AI göra människor mycket snabbare för det går att generera kod, tester, dokumentation, API-klienter och tekniska förslag i en hastighet som hade varit svår att föreställa sig för bara några månader sedan.

Men det betyder inte automatiskt att värdet ökar i samma takt. Idén att man inte längre behöver människor bygger på ett missförstånd om att det var skrivandet som var den svåra delen.

Det var det sällan. Det svåra har alltid varit att förstå vad som faktiskt ska byggas och varför det ska byggas. Vilket problem det löser och vilka begränsningar som finns. Och inte helt sällan, att förstå när ingenting alls borde byggas.

AI förstärker den kompetens du redan har

AI-kod är inte magisk. Den är ett resultat av instruktioner, exempel, antaganden och uppföljande frågor och de sakerna kommer från människor.

Om du är duktig på att förstå affärsproblemet kommer det att märkas i hur du använder AI. Du kommer att ge bättre kontext, ställa bättre följdfrågor, be om rätt avvägningar och granska svaret på ett mer relevant sätt. Om du har arkitekturellt tänkande kommer du att se när AI föreslår något som fungerar i ett isolerat exempel men som inte passar in i helheten. Om du är bra på att se risker kommer du att reagera när AI missar behörigheter, felhantering, prestanda, etc.

Men motsatsen gäller också.

Om du tenderar att överkomplicera lösningar kommer AI ofta att hjälpa dig att överkomplicera dem snabbare. Om du är otydlig med vad problemet faktiskt är kommer AI att fylla i luckorna själv och ibland kommer det att bli bra och ibland blir det mindre bra. De skarpare modellerna genererar sällan buggar, men i de fall som luckorna fylls med antaganden som inte stämmer med det du vill så är dessa ofta gömda i till synes elegant kod.

AI tar inte bort dina mönster utan skalar upp dem. Och det blir ett växande problem eftersom AI kommer att utgå från din befintliga kodbas och se den som något värt att bygga vidare på. Den befintliga kodbasen utgör grundriktningen, och din prompt snävar in den riktningen. Du får alltså ett fantastiskt verktyg till att springa otroligt snabbt i helt fel riktning om det vill sig illa.

Samma sak gäller team. AI förstärker inte bara individers förmåga, utan också teamets sätt att arbeta. Starka team med tydlig riktning och bra kommunikation kan få enorm hävstång av AI. Svaga team kommer däremot att skala upp sina problem.

Ju större ett team är, desto viktigare blir kommunikationen. Om AI plötsligt gör att teamet kan skapa betydligt mer kod och fler förändringar men kommunikationen ligger kvar på samma nivå uppstår ett glapp. Det glappet blir snabbt farligt när fler saker byggs, men färre saker förankras. Fler beslut tas, men färre delas.

Det är lätt att tänka att detta mest blir en teknisk påverkan men det är hela organisationen som påverkas. Organisationen är van vid att det tar en viss tid från ax till limpa och att den tiden gör att man hinner fånga upp problem och iterera innan något är klart och släpps. Med den hastighet man nu kan hålla sätts en helt annan press på att göra rätt direkt. Beslut måste vara genomtänkta från början och när man nu har möjlighet att göra ännu fler saker samtidigt behöver man tänka ytterligare ett steg för att förutse hur dessa saker samverkar.

Kompetens är inte en rak skala

Vi pratar ofta om kompetens som om det vore en enda skala från junior till senior, från dålig till bra. Men i verkligheten är kompetens mycket mer flerdimensionell. En utvecklare kan vara väldigt snabb men svag på affärsförståelse. En annan kan vara tekniskt skicklig men göra lösningar som är lite mer komplicerade än vad som egentligen behövs. En tredje kan vara bra på att skriva kod som är lätt att läsa och förstå men ha svårt att se helheten.

När AI kommer in i bilden försvinner inte de här skillnaderna utan blir snarare starkare. För AI producerar inte bara kod, den producerar kod i den riktning du styr den. Och riktningen avgörs av ditt omdöme.

“Kan man inte bara be AI vara neutral?”

Jo, det kan man. Man kan be AI skriva en neutral lösning, följa best practices, hålla det enkelt och undvika onödig komplexitet. Det är ofta en bra start.

Men då får man också en ganska neutral lösning, vilket inte behöver vara något dåligt. Många system skulle må bra av mer neutral och lite mindre kreativ kod. Och i flera fall räcker en neutral lösning mer än väl för det man behöver. Men om målet är att skapa något riktigt bra räcker det sällan med “meh”.

Bra tekniska lösningar uppstår inte bara genom att undvika fel. De uppstår genom avvägningar och genom att förutspå framtida krav.

• Vad ska vara flexibelt och vad ska vara hårdkodat?

• Vad ska byggas nu och vad kan vänta?

• Vilket system ska äga vilken data?

• Var ska komplexiteten ligga, och vad är onödig komplexitet och vad är den komplexitet som är hjärtat i systemet?

• Vilka framtida behov är rimliga att ta höjd för, och vad är bara fantasier?

Det är inte frågor AI kan lösa i ett vakuum. Inte minst för att detta är frågor som kräver mänsklig kreativitet att lösa. Den LLM-arkitektur vi har med AI idag blickar bakåt på så sätt att den samlat in hela världens kunskap och destillerat ner den till dig. Men vissa av problemen du står inför är helt nya, eller åtminstone så är kompositionen av problemen nya. Vilket kräver kreativt tänkande som är svårt att enbart använda AI till.

Mer kod är inte samma sak som mer värde

Om alla i ett team börjar använda AI och blir tre gånger snabbare på att producera kod så låter det först som en fantastisk nyhet.

Men frågan är, tre gånger mer av vad? Tre gånger mer genomtänkta lösningar? Tre gånger mer kundvärde? Tre gånger bättre arkitektur?

Eller bara tre gånger mer kod?

För kod är inte gratis bara för att den är snabb att skriva. Kod ska läsas, testas, felsökas, vidareutvecklas, dokumenteras och ibland avvecklas. Den ska passa in i helheten. Och inte minst så kommer den utgöra kontexten för nästa AI-agent som ska bygga ovanpå den. Bra kod föder bra kod, dålig kod föder dålig kod.

Det är här sprängradien kommer in. Alla utvecklare har en sprängradie och alla team har en sprängradie. Alla organisationer har en sprängradie. Varje gång nånting nytt tas fram, så blir det en sprängradie bara av att saker förändras.

Vissa skapar små problem som är lätta att rätta till. Andra skapar stora problem som påverkar flera system, flera team och flera år framåt.

AI minskar inte automatiskt den sprängradien. Den kan lika gärna göra den större eftersom sprängradien är proportionerlig med hur mycket som produceras.

Värdet flyttar uppåt

Värdet flyttas från att skriva varje rad kod själv till att formulera rätt problem. Hammock Driven Development blir viktigare än nånsin.

Det betyder också att specifikationer blir viktigare. Jag vet, det låter tråkigt. En specifikation i en AI-driven utvecklingsprocess behöver inte betyda hundrasidiga dokument som ingen mer än AI läser. Det kan betyda att man använder AI för att tänka bättre innan man börjar kodar eller till andra uppgifter för den delen. Be AI hitta fel i din specifikation, eller låt AI intervjua dig för att hjälpa dig ta fram den.

Alla gånger jag använt AI på olika sätt så har slutsatsen alltid blivit att ju mer konkret mitt problem och min formulering är, desto vassare är AI på att lösa det. AI är betydligt bättre på att rätta buggar eller hitta var det finns inkonsekvens i en specifikation än vad den är på att lösa "bygg ett bra e-handelssystem åt mig".

Frågan är inte hur mycket kod vi kan producera

AI håller redan på att förändra hur utveckling går till. Den kommer göra många saker snabbare och den kommer göra det möjligt för fler att bygga mer. Vilket i sig är fantastiskt. Flera av mina kollegor som aldrig skrivit en rad kod tidigare har kunnat bidra med saker på dagar eller timmar som tidigare tagit en utvecklare dagar eller veckor, så det är inga tvivel om att världen ser annorlunda ut idag än vad den gjorde för bara någon månad sedan.

Men om vi bara mäter AI i hur mycket mer kod vi kan producera riskerar vi att missa poängen.

Den viktiga frågan är inte: Hur mycket snabbare kan vi skriva kod?

Se det som att AI är ett sätt att trimma din bil från att kunna köra i 100 km/h till att kunna köra i 10 000 km/h. Vill du verkligen sätta dig i den bilen utan att ha kollat så att det inte finns ett stort berg i den riktning du tänkt köra?

För dig som köper in system eller tjänster går vi nu in i lite av en vilda västern-period där du kommer få erbjudande om att köpa in system och tjänster från helt nya aktörer som använder AI för att lösa dina problem. Det kommer vara lockande att kapa kostnader på detta sätt, och utmaningen för dig blir att veta vem som erbjuder en bil i ljusets hastighet på väg mot avgrunden, och vem som kan förstå vad det är du behöver och sen exekvera på det.

Den viktiga frågan blir: Hur mycket bättre kan vi tänka innan vi skriver eller beställer kod?

AI gör inte automatiskt ditt team klokare. Den gör teamets omdöme mer skalbart. Och det är både möjligheten och risken.

AI ökar inte bara produktiviteten, den ökar också sprängradien.