AI blir snabbt en del av den dagliga mjukvaruutvecklingen. Det gick snabbt från att endast ställa enstaka kodfrågor till ChatGPT till att nu kunna köra flera autonoma agenter parallellt. Utvecklare kan idag lämna över mer av det dagliga arbetet än någonsin tidigare.
Men bara för att vi kan lämna över mer, betyder det att vi borde göra det?
Under en Learning Lunch på Softhouse delade webbutvecklaren och systemarkitekten Jonathan med sig av hur hans eget sätt att arbeta med AI har utvecklats, vad han lärt sig av att släppa lös agenter i en riktig kodbas och varför snabbare utveckling också ställer nya krav på arkitektur, testning och kanske framför allt på utvecklaren själv.
Kort sagt: Bara för att AI-agenter nu skriver merparten av koden betyder det inte att vi ska kasta gamla kunskaper och lärdomar överbord.
Börja med gränser, inte prompts
Det ska vara lätt att göra rätt.
Det är sant för både personer och agenter. Att göra det rätta ska alltid vara det enkla valet. Men hur säkerställer vi att nya förändringar inte bryter gamla implementationer, och hur gör vi det möjligt att inga missförstånd uppstår mellan våra olika tjänster? Enkelt svar: genom att använda metoder som funnits sen länge, automatiserade tester, tjänstekontrakt för alla API-rutter och strikt kodgranskning.
Jonathans erfarenheter kommer bland annat från ett KPI-dashboardprojekt som utvecklades för en kund med begränsad budget. Systemet hanterar avdelningshierarkier, behörigheter, gemensamma mätvärden och logik för uppföljning. AI-assisterad utveckling gjorde det möjligt att arbeta snabbt, men hastigheten fungerade bara när den omgivande arkitekturen gav AI tydliga gränser. Projektet bygger därför på strikt TypeScript, Prisma-scheman, Fastify och Zod-validering på API-rutterna. Principen är ganska enkel: ju tydligare systemet definierar hur giltig data och korrekt beteende ser ut, desto mindre utrymme får AI att göra felaktiga antaganden.
Men det här är egentligen inget nytt. Tydliga gränser, väldefinierade kontrakt och genomtänkt arkitektur var goda principer långt innan AI började skriva kod. AI förändrar hur vi arbetar, men det betyder inte att vi ska kasta bort det vi redan lärt oss om bra mjukvaruutveckling. Snarare tvärtom. När mer kod kan produceras snabbare blir de etablerade principerna ännu viktigare.
Men det finns en annan regel som Jonathan tycker är minst lika viktig: utvecklaren måste fortfarande förstå systemet.
Om du inte kan förklara arkitekturen och logiken på en whiteboard förstår du förmodligen inte tillräckligt mycket av det AI har byggt för att kunna förvalta det säkert över tid.
Från TDD till Test-Enforced Development
Testning har en central roll i Jonathans arbetssätt, men inte nödvändigtvis i traditionell Test-Driven Development (TDD)-bemärkelse. Han beskriver sitt arbetssätt som Test-Enforced Development (TED).
När en bugg dyker upp är den första uppgiften inte att be AI fixa den. I stället handlar det om att skapa ett integrationstest som återskapar problemet och misslyckas. Först därefter får agenten uppgiften att få testet att gå igenom. Det förändrar testets roll något. Testet blir både ett bevis på att buggen faktiskt existerar och en gräns för vad agenten får förändra.
Jonathan har också gått ifrån att lägga stor vikt vid den traditionella testpyramiden. I stället föredrar han det han kallar en Integration Diamond, där integrationstester och tyngre service-tester tar större plan än vanliga unit-tester. Att testa helheten har nu ännu större värde än tidigare.
För AI-assisterad utveckling ger det något väldigt värdefullt: en snabb feedbackloop som kontrollerar om agentens förändringar faktiskt fungerar genom hela systemet och inte bara isolerat. Att skapa ett system som är lätt att testa och verifiera. Samma färdighet som alltid, skapa en systemarkitektur som möjliggör testbarhet.
Uppför AI-stegen
Jonathan beskriver sin egen resa med AI-utveckling som en slags stege. På den första nivån ser utvecklingsarbetet ut ungefär som det alltid har gjort: skriva kod manuellt, söka på webben, läsa dokumentation och hitta svar på Stack Overflow. Sedan kommer chattbotarna. ChatGPT och Claude ligger vid sidan av utvecklingsmiljön och blir ett bollplank för att diskutera problem, generera idéer eller granska kod. Nästa steg är att flytta in AI i själva utvecklingsmiljön. Integrerade IDE-agenter kan läsa projektet, ändra filer och följa projektspecifika instruktioner.
Därifrån börjar det gå fort.
Flera agenter kan arbeta samtidigt i separata arbetsytor, var och en med olika uppgifter. I teorin innebär det att betydligt mer arbete kan utföras parallellt. I praktiken dyker en annan flaskhals upp:
utvecklaren.
Varje resultat behöver fortfarande förstås, granskas och verifieras. Att köra fyra agenter samtidigt gör dig inte nödvändigtvis fyra gånger så produktiv om du hela tiden måste växla kontext mellan fyra olika arbetsflöden. Jonathan beskriver den här nivån som kraftfull men också mentalt utmattande.
Och högst upp på stegen finns agent-svärmar, där agenter koordinerar uppgifter och delegerar arbete vidare till andra agenter med allt mindre mänsklig inblandning. Då uppstår en helt annan fråga: vad händer när utvecklaren inte längre är meningsfullt involverad i processen?
Ibland gör agenten exakt det du ber om
En av Jonathans erfarenheter illustrerar ganska väl varför tydliga skyddsräcken behövs. Under en refaktorering fick en agent instruktionen att få en testsvit med misslyckade tester att gå igenom. Så det gjorde den.
Genom att radera testerna som misslyckades.
Tekniskt sett var testsviten nu grön. Applikationen var förstås fortfarande inte fixad. Händelsen ledde till en explicit projektregel: agenter får inte ändra eller radera befintliga tester utan mänskligt godkännande. Fler regler följde.
Agenterna instruerades att använda standardiserade verktyg för datumhantering, som date-fns, i stället för att skapa egen logik för datumjämförelser. På så sätt minskade risken för subtila fel kopplade till datum och tidszoner. De förhindrades också från att hårdkoda CSS-värden och behövde i stället använda applikationens befintliga design tokens och teman.
Reglerna kan verka små var för sig, men tillsammans pekar de på något större.
Att arbeta effektivt med kodagenter handlar om att skriva tydliga och bra prompts, men även om styrning: att definiera vad agenten får göra, vilka konventioner den måste följa och var mänskligt godkännande krävs. Att få agenten att göra det du faktiskt tänker. Agenten är expert på att få saker att fungera, men har ibland svårt att se helheten. Den har laserfokus på att lösa just exakt uppgiften och har inget framtidstänk på hur vi skulle kunna jobba vidare med detta. Som utvecklare är du i slutändan ansvarig för det du producerar. Se därför till att agenten skapar kod som du själv förstår.
Risken med små fel i stor skala
Kod behöver inte vara dramatiskt fel för att bli ett problem.
En liten andel tveksamma arkitekturbeslut, onödiga abstraktioner eller subtila buggar kan verka hanterbara var för sig. Men om de fortsätter att samlas på hög genom hundratals eller tusentals förändringar blir effekten större över tid.
Resultatet kan bli en kodbas som fortfarande fungerar, men som gradvis blir svårare att förstå, förvalta och förändra. Det är därför kodgranskning och förståelse fortsätter att vara avgörande, även när själva koden produceras snabbare. AI kan accelerera implementationen, men tar inte bort behovet av ingenjörsmässigt omdöme. Prova att jobba utan agenter i din egen kodbas under en förmiddag. Då märker du ganska snabbt om arkitekturen och abstraktionsnivån fortfarande håller.
Och vad händer med utvecklaren?
Det finns också en mindre teknisk sida av allt det här. AI gör det väldigt enkelt att lämna över just det ögonblick där du tidigare hade stannat upp, tänkt igenom problemet och arbetat dig fram till en lösning. Den bekvämligheten har ett pris.
Ju oftare vi lämnar över den processen till AI, desto lättare blir det att vända sig till modellen innan vi själva hunnit tänka igenom problemet. Med tiden väcker det en relevant fråga om vad det gör med vår förmåga att resonera, felsöka och bygga en djup teknisk förståelse. Jonathan ser motsägelsen i sitt eget arbete.
Han använder AI varje dag. Det hjälper honom att utveckla snabbare, översätta presentationer, förstå legacy-system och lösa problem som tidigare hade tagit betydligt längre tid. Samtidigt ligger en del av glädjen i mjukvaruutveckling just i att lösa de där problemen själv. Och kanske är det en av de mer intressanta frågorna i agenternas era.
Utmaningen kanske inte bara handlar om att ta reda på hur mycket arbete vi kan lämna över till AI, utan om att bestämma vilka delar av arbetet vi fortfarande vill, och behöver, äga själva.
