Jag har även fångat upp diskussioner med ingenjörer och ledare i branschen. Nyfikenheten är stor, men ännu är early days och det finns ingen given formel eller mall för hur vi introducerar AI teknologi i våra organisationer.
I dessa artiklar kommer jag avsiktligen avstå från att använda AI, idag översvämmas internet över av lättviktigt genererat innehåll och jag vill helst inte bidra till den typen av utveckling.
Första delen av mina artiklar handlar om att gå från assistenter till agenter. När det gäller språkmodeller i allmänhet och deras kodgenererande kapacitet i synnerhet, har det funnits en ganska polariserad debatt om hur användbart deras output egentligen är.
Ena sidan diskuterar om 10x utvecklingshastighet, medan andra menar att den genererade koden är så pass bristfällig att det tar mer tid att granska och fixa än att skriva kod själv från början. Min bild är att modellernas kapacitet har blivit märkbart bättre de senaste halvåret, men framförallt har kunskapen om hur man använder dessa modeller på bästa sätt har tagit stora steg framåt. Nu flyttas debatternas fokus mer mot risker och begränsningar i fragila agentiska arbetsflöden. Att kodgenerering med hjälp av AI är ett seriöst redskap för mjukvaruutveckling känns inte längre kontroversiellt.
Hur använder mjukvaruutvecklare AI rent praktiskt?
Det mest basala sättet som också blivit introduktionen för många är att använda chatbotarnas webinterface, beskriva vilken hjälp man önskar med i vanlig text och sedan kopiera eller ladda ner den genererade koden till sitt projekt. Det fungerar oftast bra för en första version, men för vidareutveckling, testning och felsökning blir snabbt omständligt.
Nästa steg är att integrera en AI-assistent i sin kodeditor (IDE= integrated development environment). Pionjären inom detta var Cursor, men snabbt släpptes det flera AI-assistenter som plug-ins för alla utvecklingsplattformar. Vi som arbetar som mjukvarutvecklare kan se vår kod på samma sätt som förut men har nu tillgång till en kodgenererande AI som snabbt kan skriva skelettkod, göra autocomplete på hela funktioner, skriva unittester, föreslå kodändringar, felsöka buggar och mer. AI:s roll är dock fortfarande mer av en assistent som hjälper oss att bli effektivare och vi har fortfarande full kontroll på koden.
I början av 2025 anserade företaget Anthropic verktyget Claude Code. Skillnaden mot de tidigare beskrivna arbetssätten är att Claude Code installeras lokalt på utvecklarens dator och accessas via en kommandoprompt, även kallad terminal eller CLI (Command Line Interface). AI:n är inte beroende av en IDE utan lever som en egen process i systemet. Utrustad med olika verktyg för att söka, organisera och skriva filer på disk blir AI:n härmed en agent i ordets rätta bemärkelse. Claude Code ges tillgång till de filer (typiskt kod och relaterade filer från ett kodrepository), analyserar koden och blir sedan tillgänglig för att göra tillägg eller förändringar enbart baserat på vad vi skriver i klartext i terminalen ungefär som en chatbot.
Det kan vara intressant att veta att kodgenerering baserat på instruktioner på detta sätt ibland kallas “vibecoding”. Flera företag, bland annat svenska Lovable, har byggt plattformarslösningar som göra det enkelt utan programmeringskunskap bygga egen mjukvara. Detta kan vara ett snabbt sätt att bygga prototyper och enklare webbaserade produkter. Skillnaden mellan den typen av verktyg och kodningsagenter som Claude Code, Gemini CLI och Codex CLI är att de senare integreras direkt i ett företags befintliga utvecklingssystem.
Med andra ord kan man nu använda dessa agenter för att interagera direkt med företagets utvecklingsplattform genom att generera och köra automatiserade tester, dokumentation, bygga binärer, bygga databaser, driftsätta och via nya kommunikationsprotokoll som MCP koppla upp mot externa tjänster och datakällor.
Viktigt att komma ihåg är att den underliggande tekniken fortfarande är språkmodeller, så förmågan att definiera verktyg och agenter på ett optimalt sätt (med naturligt språk) blir väldigt centralt. Vi har inte längre att göra med väldefinierade strikta protokoll där kontraktsbrott omedelbart stoppar exekveringen. Det blir också svårare, men lika viktigt, att förstå hur man ska mäta kvalitet när man arbetar med gråskalor istället för binära resultat.
Nya mönster som har börjat tas i bruk är att definiera upp specialiserade subagenter som körs parallellt och i sin tur orkestreras av en övergripande agent. Dessa “agent team” kör i hög grad autonomt och utvecklarens roll har förflyttats från kodning till att fatta övergripande beslut, underhålla AI-plattformen, monitorera dess exekvering samt säkerställa att resultaten valideras. Att arbeta på det här sättet är fortfarande nytt och förenat med en hel del risker. De som tagit detta längst är vanligen små tech-orienterade produktteam med höga tekniska ambitioner och stor riskaptit.
Oavsett hur långt man är villig att gå finns det en faktor som är kritisk om man ska kunna använda den här typen av teknik och kunna lita på att den gör mer nytta än skada.
Kontext: Det vill säga agentens förmåga att förstå sammanhanget i vilken koden genereras.
Vilket innebär agentens förmåga att förstå sammanhanget i vilken koden genereras, utan förmågan kommer AI att gissa sannolika mönster och ge en hög andel övertygande men troligen felaktiga svar, så kallade “hallucinationer”. Om en ny produkt byggs scratch är detta ett mindre problem även om nogrannheten bör vara hög och se till att agenten dokumenterar alla beslut och ändringar under utvecklingens gång. Finns det däremot en en stor mängd mer eller mindre dokumenterad legacy-kod behöver man vara extra varsam.
Hur ska vi då gå tillväga?
Mitt förslag är lägga en hel del tid på att skapa kompletta systemdokumentation med hjälp av AI detta är inte bara nödvändigt som kontext för agenten utan också värdefullt för medarbetare som inte är bekanta med systemet. Med hjälp av kunskap hos seniora medarbetare, befintlig dokumentation, kod, och databasscheman kan en agent instrueras att dokumentera enskilda subsystem i form av text, arkitekturdiagram och flödesscheman. Den genererade dokumentationen granskas och godkänns av de personer som har bäst kunskap om systemet. Sedan bins detta ihop genom subsystem via deras interaktionspunkter tills det uppnått en top-down vy för hela systemet. När agenten skall utföra en ny uppgift kan den då gå från toppen och orientera sig ner till den delen av systemet som skall ändras utan att dra iväg på några stickspår. Den kommer också få en helt annan potential som planeringspartner inför större systemändringar.
I nästa del kommer jag att höja blicken och ta en titt på hur dessa typer av kodningsagenter kan används för stöpa om och effektivisera hela produktutvecklingsflödet, och hur det i sin tur påverkar processer och roller.
Tack för att du läste!
Mats Litzell