Utvecklarens jobb var aldrig att skriva kod

Fråga en erfaren utvecklare vad hen faktiskt gör om dagarna, och svaret är sällan "skriver kod". Det är att förstå ett verksamhetsproblem, väga alternativ mot varandra, hitta felet som ingen annan hittar, och avgöra vad som är tillräckligt bra för produktion. Koden har alltid varit medlet, inte målet.

Det är därför vi på XLENT ser agentisk kodning som något större än ett nytt verktyg. När AI-agenter tar över allt mer av själva implementationen som kodgenerering, felsökning, iteration, så blir det tydligt vad utvecklarrollen egentligen består av. Och det är inte syntax. 

Vad agentisk kodning är, och vad det inte är 

Begreppen blandas ofta ihop, så låt oss vara tydliga. Vibe-kodning har kommit att beteckna ett arbetssätt där man accepterar AI-genererad kod utan att egentligen granska den. Det passar utmärkt för en prototyp en fredagseftermiddag, oacceptabelt för system som hanterar patientdata eller elnät. 

Agentisk kodning är något annat: AI-agenter som utför verkligt ingenjörsarbete, läser kodbasen, skriver kod, kör tester, rättar sina egna fel över flera steg MEN, inom ramar som människor sätter. Utvecklaren formulerar mål och acceptanskriterier, agenten arbetar, och resultatet passerar samma kodgranskning, testautomation och CI-pipeline som all annan kod. 

Skillnaden mot traditionell utveckling är inte lägre kvalitetskrav. Det är var människans tid läggs. 

En historisk parallell är när kompilatorn tog över översättningen till maskinspråk. När programmeringsspråk som C och Java ersatte assembler protesterade många utvecklare som byggt sin yrkesstolthet på att optimera maskinkod för hand. Men utvecklingen gjorde det möjligt att bygga mer, snabbare och med högre kvalitet och utvecklarens roll blev ännu viktigare. Nu står vi inför samma typ av skifte: från att beskriva hur något ska byggas till att beskriva vad som ska byggas.

Vad vi har lärt oss av att göra det på riktigt 

Som partner till Anthropic har vi inte bara läst om det här, vi har gjort det till en del av hur vi arbetar. Vi kör interna bootcamps där konsulter bygger verkliga lösningar med Claude Code, vi har certifierat medarbetare via Anthropicsutbildningsprogram, och vi har till och med arrangerat en intern kodningstävling där team fick lösa skarpa uppgifter med AI-agenter under tidspress. 

Tre mönster återkommer: 

• Specifikationen är den nya källkoden. Det som skiljer bra resultat från dåliga är inte "prompt-skicklighet" utan förmågan att specificera: tydliga acceptanskriterier, dokumenterade kodkonventioner, tester som definierar korrekt beteende. För att få resultat som håller, behöver vi ge agenten samma kontext som vi skulle ge en ny kollega. Exempelvis arkitekturbeslut, domänregler och vad som inte får ändras. 

• Granskningsförmåga blir kärnkompetens. När kod produceras tio gånger snabbare flyttas flaskhalsen till att bedöma den. Erfarna utvecklare blir mer värdefulla, inte mindre. Men värdet sitter i omdömet: att se det subtila felet, ifrågasätta den onödiga abstraktionen, veta när "fungerar" inte betyder "klart". Juniora utvecklare behöver medvetet träna just detta, eftersom de inte längre bygger intuitionen genom att skriva varje rad själva. 

• Rollgränserna mjuknar. Produktägare och domänexperter kan gå från idé till fungerande prototyp utan att vänta på utvecklingskapacitet. Det ersätter inte utvecklaren, tvärtom, det flyttar utvecklarens insats till där den gör störst skillnad: arkitektur, säkerhet, och att avgöra om prototypen är redo att bli en färdig produkt. 

Säkerhet och data: frågan ingen kommer undan 

För många organisationer är den avgörande frågan inte om AI-agenter kan skriva bra kod, det är vart data tar vägen. Kan man ge Anthropic eller OpenAI tillgång till miljöer där kunddata finns? Svaret kräver samma analys som vilken molntjänst som helst: vilken data exponeras, vilka avtalsvillkor gäller kring träning och lagring, och vad säger GDPR, kundavtal och i vissa fall säkerhetsskyddslagstiftning? 

Här behöver de flesta en kombination av olika AI-modeller. Att använda AI för kodassistans i en kodbas utan känslig information är en sak. Att låta en AI analysera produktionsloggar med personuppgifter eller affärskritisk data är en helt annan. Där kan lokala modeller, som körs på den egna infrastrukturen vara rätt val, även om de inte är lika kraftfulla som de senaste AI-modellerna. Ibland är en enklare modell som aldrig lämnar den egna miljön ett bättre alternativ än en mer avancerad modell som inte får användas.

Nyckeln är att låta rätt modell göra rätt jobb: känslig data hanteras lokalt, medan mindre känsliga uppgifter kan skickas till externa AI-tjänster. Det handlar inte om att välja bort AI utan om att bygga en genomtänkt arkitektur med tydliga regler för hur data får användas. 

Det här är en arkitekturfråga, och den ska lösas med samma metodik som all annan arkitektur: klassificera data, kartlägga flöden och dokumentera besluten. 

Tokenomics: att lära sig hushålla med intelligens 

En mindre uppmärksammad kompetens håller på att växa fram: att veta vilken modell en uppgift kräver. De stora leverantörerna erbjuder modeller i olika viktklasser. Hos Anthropic exempelvis Sonnet för det breda vardagsarbetet och Opus eller Fable för de verkligt komplexa uppgifterna. Prisskillnaden är betydande, och kapacitetsskillnaden är stor men inte alltid relevant. 

Erfarna team lär sig delegera som en bra chef: rutinuppgifter till den snabba och billiga modellen, arkitekturbeslut och svår felsökning till den tunga. Men det finns ingen tabell för detta, det handlar om övning. Vad fungerar och vad fungerar inte för just era uppgifter och er kodbas lär man sig bara genom att testa, mäta och justera. 

Gör man det fel bränner man tokens i onödan, och det märks allt tydligare i takt med att fler leverantörer och verktyg går över till att ta betalt för faktisk förbrukning än fasta licenser. Kostnadsmedvetenhet blir en del av ingenjörskapet, ungefär som molnkostnader blev det för tio år sedan. Team som tidigt bygger vanan att logga förbrukning, jämföra modeller på verkliga uppgifter och sätta riktlinjer får både bättre ekonomi och bättre resultat. 

Disciplinen avgör 

AI-genererad kod blir inte bättre än processen runt den. De organisationer som lyckas använder AI för att öka tempot, men behåller eller ökar kravet på kvalitet. Automatiserade tester, kodgranskning och tydliga arbetssätt är fortfarande avgörande. AI är en väldigt snabb kollega, men den fattar inte besluten. 

Det sägs ofta att AI saknar förståelse för verksamheten och affärsmålen. Det stämmer bara om den inte får den informationen. Med rätt kontext, som dokumentation, exempel och tydliga ramar kan AI ge betydligt bättre resultat. Sedan är det fortfarande utvecklarens ansvar att bedöma, förbättra och fatta rätt beslut. 

Från utvecklare till problemlösare 

Skiftet vi ser handlar i grunden om hur våra roller förändras. Utvecklare växer in i en roll där arkitektur, problemlösning och affärsförståelse blir allt viktigare. QA-specialister kan automatisera mer av sitt arbete, och produktägare får större möjligheter att påverka den tekniska utvecklingen. Ingen av rollerna försvinner, men alla förändras. Det som blir viktigast är fortfarande omdöme, helhetssyn och förmågan att förstå vilket problem som faktiskt ska lösas. 

Vårt råd till dig som leder utveckling är att inte börja med verktyget, utan med arbetssättet. Välj ett avgränsat, verkligt problem. Sätt tydliga ramar för vad AI får göra, hur resultaten ska granskas och vilka tester som ska genomföras. Låt teamet experimentera inom de ramarna och utvärdera resultatet på samma sätt som för allt annat utvecklingsarbete. 

Kod har aldrig varit poängen. Nu blir det uppenbart. 

XLENT är partner till Anthropic och hjälper företag att införa AI-lösningar baserade på Claude, från strategi och utbildning till implementation. Nyfiken? Hör av dig.