Mer kod. Inte nödvändigtvis mer värde

AI gör utvecklare snabbare. Det gör inte automatiskt organisationen snabbare. För det krävs att vi också utvecklar hur vi fattar beslut, delar kunskap och beskriver det vi vill bygga. Det senaste året har jag suttit i många samtal om AI i mjukvaruutveckling. Nästan alla börjar på samma ställe.
Vilken modell ska vi använda? Vilka licenser behöver vi? Claude Code, Copilot eller Cursor? Hur hanterar vi säkerheten? Det är rimliga frågor. Men jag tror att vi behöver lägga minst lika mycket tid på vad som händer med vårt sätt att arbeta. Tänk på versionshantering, CI/CD, DevOps och agilt arbete. Verktygen var viktiga, men värdet växte fram när vi också förändrade hur vi samarbetar, tar ansvar och levererar. AI kräver en liknande förflyttning.

Flaskhalsen flyttar

Anta att en utvecklare kan producera fem gånger mer kod. Levererar organisationen då fem gånger snabbare?
Nej. Flaskhalsen flyttar till allt som omger koden. Vad ska vi bygga, och i vilken ordning? Hur hänger lösningen ihop med resten av systemet? Vem fattar besluten? Hur hinner vi samordna, granska, testa och släppa det som byggs?

När kod blir billig blir samordning dyr

Det känner jag igen från många team. Den begränsande faktorn har sällan varit att skriva koden. Den har varit att komma fram till vad koden ska göra och hur vi vet att den fungerar.

Tio versioner av samma system

Samtidigt växer AI-användningen ofta fram som en samling individuella arbetssätt. Varje utvecklare har sina egna promptar, instruktionsfiler och sätt att beskriva produkten. Lokalt fungerar det bra. Men över tid får organisationen flera konkurrerande beskrivningar av samma system. Samma begrepp betyder olika saker. Ett arkitekturbeslut finns dokumenterat på ett ställe men saknas på ett annat. AI-assistenterna arbetar utifrån olika förutsättningar. Resultatet blir mer kod, fler motsägelser och mer arbete med att få delarna att hänga ihop.

Därför behöver målet vara större än att alla utvecklare använder AI. Målet är att utveckla mjukvara tillsammans med AI, som team och organisation – och att det syns i kvalitet, ledtider och värde för kunden.
AI-modeller och verktyg kommer att bytas ut. Vår förståelse av verksamheten, användarnas behov och systemens uppbyggnad behöver leva vidare. Det är den strategiska tillgången: ett gemensamt verksamhetsspråk, tydliga produktbeskrivningar, arkitekturdokumentation, API-kontrakt och dokumenterade beslut.

”Standardisera kontexten, inte verktygen” Team kan behöva olika verktyg, men de behöver en gemensam grund. Då blir vi också mindre beroende av en enskild leverantör.

Det kräver mer än att samla dokument på ett ställe. Någon behöver ta ansvar för att kunskapen är aktuell. När en lösning förändras följer beskrivningen med. När ett beslut fattas går skälen att förstå i efterhand.
Inaktuell dokumentation har alltid skapat problem. När den blir underlag för genererad kod omsätts missförstånden i implementation – snabbt.

Specifikationen blir viktigare

När AI tar fram en större del av implementationen behöver vi lägga mer omsorg på att beskriva avsikten: vilket problem vi löser, vilka begränsningar som gäller och vad som räknas som ett fungerande resultat. Det är kärnan i specifikationsdriven utveckling. Vi har länge kunnat lämna luckor i beskrivningarna, eftersom utvecklaren fyllt i dem med erfarenhet, produktförståelse och samtal med kollegor. AI fyller också i luckorna. Resultatet kan se rimligt ut och ändå bygga på fel antaganden. En bra specifikation gör antagandena synliga. Den beskriver förväntat beteende och hur det ska verifieras. Den behöver inte vara färdigtänkt från start, men den behöver hållas levande när teamet lär sig mer.

Vad det betyder för roller och ledarskap

Tyngdpunkten i utvecklarrollen flyttar. Mer av arbetet handlar om att förstå problemet, utforma lösningen, uttrycka avsikten och granska det som byggs. Teknisk skicklighet behövs fortfarande – för att bedöma arkitektur, hitta fel och förstå konsekvenser. För många erfarna utvecklare är det välbekant. De har länge bidragit med just den förmågan, även när uppmärksamheten legat på kodandet. Förändringen berör också ledarskapet. När mer kan produceras snabbare blir tydliga prioriteringar, fungerande beslutsvägar och gemensamt lärande viktigare. Det ansvaret finns oavsett om organisationen har traditionella chefer eller självorganiserande team. Vi behöver se var arbetet fastnar och ge människor mandat att lösa det. Vi behöver gemensamma sätt att kvalitetssäkra det AI producerar. Och vi behöver följa upp om det vi bygger faktiskt gör nytta.

Ett sätt att börja

Välj en avgränsad funktion i nästa sprint. Skriv tillsammans ned behovet, begränsningarna och hur ni avgör om lösningen fungerar. Låt AI arbeta utifrån det underlaget och granska sedan både resultatet och processen. Var behövde någon förklara sådant som saknades? Vilka antaganden blev fel? Vilka beslut dröjde? Där finns era förbättringsmöjligheter. Jag har inte hela svaret på hur ett högpresterande team arbetar med AI. Men jag tror att mycket börjar i förmågan att skapa gemensam förståelse.

Om era utvecklare blev dubbelt så snabba i morgon – var skulle kön bildas först?