AI förändrar systemutvecklingen, det är tydligt. Men hur ser förändringen ut, i vilken takt sker den och vad vet vi egentligen om effekterna? Vi har en välfärd att bemanna, ett digitalt arv att förnya och klimat-, säkerhets- och beredskapskriser att hantera samtidigt, och då kan föråldrade beslutsunderlag bli dyra, beslutsunderlag som kan få oss att avfärda möjligheter som AI nu ger oss, investera utifrån antaganden som inte längre håller eller lova besparingar som aldrig uppstår. Ett beslut kan vara väl underbyggt på papperet och ändå bygga på en verklighet som inte längre finns, och vi behöver därför förstå både vad som förändras och hur, och hur långt våra underlag räcker.

Kan AI ersätta utvecklare? Visst ser man frågan dyka upp lite då och då, ofta tillsammans med mycket bestämda svar. Någon hänvisar till en studie som visar att utvecklare blir långsammare samtidigt som någon annan visar en applikation som byggts på några minuter och drar slutsatsen att utvecklarna snart är helt överflödiga. Båda dessa missar det som är mest intressant för oss som arbetar med offentlig digitalisering, att fråga sig hur AI förändrar vilka uppgifter vi kan genomföra, hur vi organiserar utvecklingen och vilka kompetenser vi behöver, hur snabbt verktygens möjligheter omsätts i fungerande tjänster, och vilka underlag som ger oss skäl att ändra våra beslut?

Det handlar som så ofta om både kunskap och styrning. Ett missvisande påstående i ett samtal går att rätta till, men samma påstående i en budget, en upphandling eller ett beslut om kompetensförsörjning kan påverka verksamheten i flera år. Därför behöver vi fråga vad som faktiskt observerats, med vilket verktyg och i vilken miljö, innan vi bedömer vad resultatet betyder för oss i dag.

Detta, och en massa annat, resonerar jag om i detta kanske lite spretiga (det finns så mycket spännande att fundera på i detta ämne) inlägg.

En bra studie behöver också en datumstämpel

Att det är viktigt att basera sina beslut på aktuell och ändamålsenlig information kan beskrivas genom ett antal exempel. Det första exemplet är METR:s uppmärksammade studie från juli 2025 där sexton erfarna utvecklare arbetade med 246 uppgifter i stora öppen källkod-projekt som de redan var väl bekanta med. När de fick använda AI tog uppgifterna i genomsnitt 19 procent längre tid, samtidigt som utvecklarna upplevde att de hade blivit snabbare. Datainsamlingen skedde februari - juni 2025, främst med Cursor och Claude 3.5/3.7 Sonnet (Becker et al., 2025). Det är ett viktigt resultat då det bland annat visar varför vår känsla av produktivitet behöver prövas mot vad som faktiskt händer. Det säger däremot inte att AI gör alla utvecklare långsammare, och forskarna var själva tydliga med begränsningen.

I februari 2026 redovisade METR en uppföljning. Forskarna bedömde nu att AI sannolikt gav större tidsvinster än tidigare, men resultaten var osäkra. Båda gruppernas konfidensintervall omfattade möjligheten att någon tidsvinst inte fanns, och dessutom ville allt fler utvecklare undvika uppgifter där AI förbjöds, vilket gjorde urvalet skevt, något som tvingade METR att ändra sin studiedesign (Becker et al., 2026). Och nu i oktober är resultatet från den studien ändå obsolet givet hur snabbt utvecklingen går.

Den första studien blev inte fel då den beskriver vad som hände under de förutsättningar som undersöktes. Uppföljningen ger dock skäl att ompröva hur väl resultatet beskriver senare användning, men visar inte säkert hur stor förändringen är. Tillsammans illustrerar studierna varför vi behöver skilja mellan ett dokumenterat resultat, en möjlig förändring och en säker slutsats om dagens situation.

Jag har på senare tid insett att när jag läser påståenden om AI så måste jag försöka ta reda på när data samlades in, vilka modeller och arbetssätt som användes och när resultatet publicerades för att försöka verifiera aktualitet och trovärdighet, och med tanke på verktygens utvecklingstakt kommer det ändå ofta att handla om en historisk återblick.

Förändringstakten beror på vad vi följer

En modell kan bli bättre på en viss koduppgift utan att ett team omedelbart ändrar sitt arbetssätt eller att kommunen får kortare ledtider. Verktygens förmåga, människors lärande och organisationens möjlighet att använda resultaten behöver följas var för sig, och en förbättring i ett led innebär inte automatiskt samma förbättring i nästa (som vanligt hänger allt ihop). För att bedöma förändringstakten behöver vi jämförelser över tid med tydliga utgångspunkter. Vi måste fråga oss om samma typ av uppgift blivit lättare, eller om vi gör andra uppgifter, och om utfallet beror på en ny modell, mer erfarna användare eller förändrade arbetsflöden. De studier som tas upp här ger delar av bilden, men underlag från olika miljöer och med olika mått ger ingen säker kurva för förändringstakten.

Föråldrade underlag kan ge långvariga felbeslut

Det är här risken med föråldrade beslutsunderlag blir konkret. Tänk en kommun som avstår från att pröva AI-stödd utveckling därför att ett äldre försök gav dåliga resultat. När verktygen sedan har förbättrats finns risken att kommunen fortsätter lägga resurser på manuellt arbete utan att ens undersöka alternativen. Kostnaden kan visa sig som kvarstående köer, förbättringar som aldrig genomförs och kompetens som inte utvecklas, och det är en faktisk konsekvens av beslutet att vänta med AI-införandet även om själva väntan sällan får en egen rad i kalkylen.

Eller tänk en upphandling som utgår från en äldre föreställning om vad kommunen måste köpa och vad den kan utveckla själv. Om egenutveckling och samskapande inte kontinuerligt prövas kan kommunen binda sig till fleråriga avtal som begränsar framtida val, baserat på en kalkyl som var rimlig när den gjordes men som nu leder till ett dyrt beslut när kostnaderna och möjligheterna har förändrats. Att hålla fast vid beslutet kan dessutom förstärka det leverantörsberoende vi så desperat försöker minska.

Exemplen är tänkta beslutssituationer, inte uppmätta effekter i en viss kommun. De visar varför informationens aktualitet behöver bedömas utifrån beslutets konsekvenser, och ju längre ett beslut binder oss och ju svårare det är att ändra, desto viktigare blir det att kontrollera om dess centrala antaganden fortfarande håller. Det räcker alltså inte att en källa är vetenskaplig eller kommer från en trovärdig aktör. Det ger skäl att ta resultatet på allvar, men garanterar alls inte att det går att överföra till dagens situation. Vi måste skilja mellan att ett resultat var giltigt i den studerade miljön vid en specifik tidpunkt och hur användbart det är i ett beslutsunderlag här och nu.

Särskilt problematiskt blir det när uttalanden vandrar vidare. En slutsats från ett tidigare försök hamnar i en presentation, blir ett argument i ett strategidokument och återkommer sedan som en etablerad sanning, med datum, modellversion och begränsningar försvunna på vägen. Till slut ser slutsatsen mer säker ut, samtidigt som kopplingen till den situation som faktiskt undersöktes blivit svagare. Här ser jag en koppling till socio-teknisk skuld där en föråldrad föreställning ofta lever vidare genom våra avtal, rutiner och investeringsbeslut. Då räcker det inte att tekniken förbättras, utan organisationen behöver också ompröva de beslut som togs utifrån den gamla bilden, annars kan ett inaktuellt antagande fortsätta begränsa oss långt efter att det tekniska hindret undanröjts.

Mer kod är ett otillräckligt mått på framsteg

Frågan om hur AI förändrar systemutvecklingen kräver också att vi skiljer mellan olika effekter. Att en modell klarar ett kod-test, att en utvecklare blir snabbare och att en organisation skapar mer nytta är tre olika saker.

En agent kan lösa en avgränsad programmeringsuppgift utan att kunna ta ansvar för en kommunal tjänst genom hela dess livscykel som också omfattar verksamhetsregler, integrationer, tillgänglighet, säkerhet, drift och förändringar över tid. Ett högt testresultat säger något om förmågan under testets förutsättningar, men det säger inget om hur mycket en kommun kan spara totalt sett.

Ett exempel på hur besvärligt det kan vara att mäta effektivitet i AI-användning är ett brittiskt försök med AI-baserade kodassistenter som kördes mellan november 2024 och februari 2025, och där utvecklingsteam i statsförvaltningen fick möjlighet att använda GitHub Copilot och Gemini Code Assist i sitt arbete. Totalt gjordes 2 500 licenser tillgängliga, vilket dock inte betyder att 2 500 utvecklare deltog i utvärderingen – den huvudsakliga enkätanalysen byggde på 424 svar från användare i 31 departement och myndigheter (Government Digital Service, 2025). De svarande uppskattade att verktygen sparade dem i genomsnitt 56 minuter per arbetsdag. Det var alltså deras egen bedömning, inte en uppmätt skillnad mellan jämförbara grupper med och utan AI, och rapporten varnar både för att samma tidsvinst kan ha räknats i flera arbetsmoment och för att optimism kan ha lett till överskattning. Rapporten redovisade också automatiskt insamlad användningsstatistik, så kallad telemetri. För GitHub Copilot accepterades i genomsnitt 15,8 % av de föreslagna kodraderna. Det måttet beskriver vilka förslag användarna tog in i sin kod, men det visar varken hur stor del av hela systemet som AI skrev eller om den accepterade koden höll tillräcklig kvalitet. För mig är det därför två olika frågor som siffrorna belyser, dels hur mycket hjälp utvecklarna upplevde att de fick, dels hur ofta de tog emot verktygets kodförslag. En tänkbar förklaring är att en utvecklare kan få hjälp att förstå ett fel eller hitta en lösning och sedan skriva koden själv, och ett sådant stöd behöver inte synas som accepterade kodrader. Samtidigt bekräftar en accepterad kod-rad ingen tidsbesparing då förslaget kan behöva granskas och ändras, så den ena siffran kan därför inte användas som kontroll av den andra.

Även GovTech i Singapore har undersökt kodassistenter i offentlig systemutveckling. I ett försök med GitHub Copilot från oktober 2023 till januari 2024 deltog 70 utvecklare, och 40 personer svarade på enkäten. De svarande rapporterade bland annat minskad tid för kodning, men samtidigt rapporterade mer än hälften ingen förbättring av effektiviteten i överlämningar mellan personer eller team. Också här byggde bedömningen av tidsvinster på enkäter snarare än en randomiserad jämförelse (Ng et al., 2024).

Jag läser dessa försök som stöd för att undersöka möjligheterna närmare, samtidigt som de visar varför vi behöver flera mått. Försöken beskriver dessutom de verktyg och arbetssätt som användes då vilket ger erfarenheter att bygga vidare på, men de ger överhuvudtaget ingen prognos alls för vad dagens verktyg skulle ge i en svensk kommun.

För mig blir slutsatsen att vi behöver följa våra utvecklingsinitiativ hela vägen från verksamhetens behov till en tjänst som fungerar i vardagen. Om kodningen går snabbare men väntan på kravförtydliganden, integrationer eller godkännanden är oförändrad kan verksamheten ändå få vänta lika länge som tidigare. Därför vill jag veta hur lång tid det tar från idé till användbar tjänst, hur mycket granskning och omarbetning av AI-genererad kod som krävs och om lösningen går att förvalta och skala med rimliga resurser. Först när vi också följer kvaliteten i tjänsten och vad den betyder för invånaren kan vi bedöma om AI-stödet har gett den förbättring vi ville åstadkomma.

AI förändrar också vilka uppgifter vi väljer

I mitt tidigare inlägg AI gör mig inte bara snabbare – den får mig att göra saker jag annars aldrig hade gjort beskrev jag hur AI gör det möjligt att ta itu med sådant som annars aldrig prioriteras. En automatiskt genererad API-katalog som blir byggd är svår att värdera enbart i sparade timmar om alternativet var att den inte skulle byggas alls. Här finns en intressant komplettering från METR. I en analys från maj 2026 skiljer forskarna mellan tidsvinster på gamla uppgifter, tidsvinster på den nya uppsättning uppgifter vi väljer med AI och förändringen i det samlade värdet av arbetet. När verktygen förändras väljer vi också andra uppgifter, och då kan olika produktivitetsmått ge olika bilder utan att något av dem behöver vara fel (Cunningham & Whitfill, 2026).

Detta är särskilt relevant i en kommun där det finns många processer med små ärendevolymer, då var och en kan ha varit för liten för att motivera ett utvecklingsprojekt, samtidigt som de tillsammans innebär mycket manuellt arbete och onödig väntan. Om kostnaden för att undersöka och bygga en lösning sjunker kan fler sådana behov bli möjliga att möta och nyttan uppstår då genom att ambitionsnivån höjs. Den möjligheten försvinner ur kalkylen om vi enbart mäter hur snabbt samma utvecklare skriver samma kod som tidigare.

Utvecklarrollen förändras och lärandet behöver skyddas

AI kan redan ta över betydande delar av kod-produktionen i vissa arbetsflöden. Därifrån är dock steget långt till slutsatsen att utvecklarrollen är ersatt. Någon måste fortfarande förstå problemet, bedöma lösningen och kunna ingripa när den inte fungerar, och förändringen behöver därför följas i de faktiska arbetsuppgifterna och kompetensbehoven snarare än beskrivas som ett troligt datum när ett yrke försvinner.

Arbetsmarknaden ger ändå skäl till oro. Stanfordforskarna Brynjolfsson, Chandar och Chen redovisar ett växande sysselsättningsgap för amerikanska 22–25-åringar i AI-exponerade yrken. Gapet är 19 procent relativt utvecklingen för mindre exponerade jämnåriga och uppstår främst genom minskad rekrytering. Forskarna betonar att detta är beskrivande indikatorer, inte säkra kausala uppskattningar av AI:s effekt, och det är heller inget direkt mått på svenska utvecklarjobb (Brynjolfsson et al., 2026).

Men frågan är relevant även i Sverige – hur skapar vi nästa generations erfarna utvecklare om vi minskar möjligheten att komma in i yrket? En experimentell studie från Anthropic, publicerad i januari 2026, ger ytterligare ett perspektiv. I den studien fick 52 utvecklare, huvudsakligen juniorer, lära sig ett nytt Python-bibliotek, hälften med AI-stöd och hälften utan. Gruppen med AI-stöd fick i genomsnitt 50 % rätt på det efterföljande kunskapstestet, jämfört med 67 % i gruppen utan AI. Studien mätte förståelse direkt efter uppgiften och kan därför inte avgöra långsiktig kompetensutveckling, men ändå (Shen & Tamkin, 2026).

Det talar för att vi behöver utforma lärandet med avsikt. Låt juniorer använda AI, men ge dem handledning och tid att förklara vad koden gör, varför lösningen valts och hur den kan fallera (även seniorer behöver tid till det för att garantera lösningars kvalitet och behålla/utveckla sin kompetens). Att snabbt få något att fungera och att förstå det tillräckligt för att förvalta det är helt enkelt olika prestationer.

Vi kan bygga ny skuld mycket snabbare

Det här knyter direkt an till min forskning om socio-teknisk skuld. Ett systems förändringsbarhet beror på mer än kodens kvalitet, den beror också på kompetens, ansvar, arbetssätt och relationer till andra aktörer. Thoughtworks beskriver i sin Technology Radar från april 2026 begreppet kognitiv kodbasskuld (codebase cognitive debt), vilket är det växande avståndet mellan ett systems implementation och teamets gemensamma förståelse av hur och varför det fungerar. Det är en erfarenhetsbaserad expertbedömning, men den sätter ändå ord på en risk som är lätt att känna igen (Thoughtworks, 2026). Forskaren Margaret-Anne Storey utvecklar resonemanget ytterligare i ett förslag till en modell med tre samverkande skulder; teknisk skuld i koden, kognitiv skuld i människors gemensamma förståelse och intentionsskuld i den dokumenterade kunskapen. Den sista handlar om förlorade eller aldrig nedskrivna skäl, mål och begränsningar bakom systemets utformning. Nämnas ska att texten är ett konceptuellt papper, inte ett belägg för hur vanligt problemet är (Storey, 2026).

För en kommun kan detta vara mycket konkret. En AI-agent kan föreslå en ny regel i en tjänst, en regel som verkar fungera och godkänns. Ett år senare vet ingen om den uttrycker ett lagkrav, en lokal rutin eller ett missförstånd. Koden finns kvar, men organisationen har tappat förmågan att bedöma den.

I Principer för hantering av det digitala arvet beskrev jag medborgarcentrering, överförbarhet och styrning som vägledning för att hantera arvet. AI ökar behovet av dessa principer eftersom om vi kan producera lösningar snabbare måste vi också kunna förklara deras syfte, granska dem och förändra dem över tid.

När verksamheten kan bygga behöver kommunen hålla ihop helheten

Med AI kan fler medarbetare omsätta en idé i en fungerande prototyp. Jag ser en stor möjlighet i att verksamhetskunskapen kommer närmare själva utvecklingen, vilket är jättebra då den som möter problemet också kan visa hur en möjlig lösning skulle kunna fungera. Detta var en viktig poäng i Från projekt till fokuserade sprintar, när återkopplingen blir billigare kan vi bygga och lära medan verksamheten fortfarande är med i arbetet, och vi kan upptäcka missförstånd innan de hunnit bli dyra beslut.

Men kommunen behöver kunna skilja en prototyp från en tjänst som andra ska förlita sig på. En sådan tjänst behöver en ägare, tydliga regler för dataåtkomst och en plan för drift och underhåll, annars riskerar varje förvaltning att skapa sin egen lösning och sitt eget informationslager. Här blir resonemanget i API- och MCP-strategier för offentlig sektor centralt, att gemensamma gränssnitt och informationsmodeller ger förutsättningar för återanvändning. Behörigheter till exempel behöver vara tekniskt verkställda, de kan inte vila på en instruktion till en modell om att vara försiktig.

Utvecklingsorganisationens uppgift blir därför bredare då den behöver hjälpa verksamheten att bygga, utveckla gemensamma komponenter och upprätthålla kvaliteten i det som ska användas. Att reducera den till en granskningsfunktion skulle också vara att kasta bort dess förmåga att lösa problem tillsammans med verksamheten.

Egenutveckling och samskapande blir viktigare alternativ

Om AI sänker kostnaden för att utveckla och förvalta en viss lösning förändras också förutsättningarna för om man ska köpa eller bygga själv. En lösning som tidigare krävde en stor investering kan numer med fördel utvecklas själv eller tillsammans med andra kommuner i många fall. Jag säger inte att en egenbyggd lösning alltid kommer bli billigare eftersom vi behöver räkna på kostnaden för hela livscykeln, inklusive säkerhetsarbete, förvaltning och kompetens, men egenutvecklade lösningar i öppen källkod ger bättre förutsättningar för granskning och gemensam utveckling, ett viktigt inspel då vi behöver värdera rådigheten i varje val av lösning, om vi kan ändra verksamhetsregler, få ut information och byta leverantör eller AI-modell som vi vill.

AI kan alltså hjälpa oss att minska beroendet till hindrande system, men samma teknik kan skapa nya beroenden till en utvecklingsplattform eller en enskild modell att ta hänsyn till. Min slutsats är att modelloberoende, tillgång till källkod och kontrollerad dataåtkomst behöver ingå i arkitekturen från början. Vilken modell som fungerar bäst måste prövas på de faktiska uppgifterna den ska lösa, och en generell multiplikator för hur mycket sämre ett halvår äldre verktyg skulle vara hjälper oss knappast att fatta det beslutet.

Sverige behöver följa genomförandet närmare

Sveriges AI-strategi från februari 2026 uttrycker ambitionen att landet ska vara bland världens tio främsta AI-nationer och bäst på att använda AI för att förbättra offentlig förvaltnings kostnadseffektivitet, kvalitet och service. Strategin framhåller också behovet av data och kompetens (Regeringskansliet, 2026). Det är en riktning att arbeta med, men en rankningsplacering ger begränsad vägledning till den kommun som försöker förbättra en konkret tjänst och vi behöver veta vilka arbetssätt som fungerar och under vilka förutsättningar.

SCB redovisar att 35 procent av företagen i Sverige med minst tio anställda använde AI under 2025. Den siffran mäter företagens användning av olika AI-tekniker, men den beskriver varken kommunernas användning eller hur mycket AI-stöd svenska offentliga utvecklingsteam har (SCB, 2025). Jag skulle gärna se en återkommande, jämförbar uppföljning av offentlig systemutveckling, se vilka verktyg som används, på vilka uppgifter de används, samt hur ledtider, kvalitet och förmågan att underhålla lösningar förändras. Det går att börja gemensamt i kommunsektorn och dela både resultat och mätmetoder. Vi behöver samtidigt undvika att jämföra andelen kommuner med ett AI-initiativ med andelen företag som uppger AI-användning och sedan behandla skillnaden som ett exakt mått på eftersläpning då olika definitioner och urval ger olika svar.

Kriserna gör det viktigare att lära och agera

Den kommunala verkligheten väntar inte på att AI-debatten ska landa. SKR:s arbete med välfärdens kompetensförsörjning betonar redan behovet av att bättre ta till vara medarbetarnas kunskap och kapacitet (SKR, 2026). Därtill kommer behoven av beredskap, klimatanpassning och förnyelse av den digitala infrastrukturen. AI löser inte dessa utmaningar på egen hand, men kriserna gör kostnaden för felbeslut större och om vi avfärdar möjliga förbättringar med hänvisning till föråldrade erfarenheter kan vi binda knappa resurser i arbete som hade gått att förenkla. Samtidigt, om vi i stället skalar upp utifrån gamla eller missvisande framgångsexempel kan vi skapa nya kvalitets- och säkerhetsproblem, så vi behöver bedöma både risken med att införa en lösning och kostnaden för att låta bli att undersöka den.

DORA:s rapport från 2025 beskriver AI som en förstärkare av organisationens befintliga styrkor och svagheter, och det är en användbar organisatorisk hypotes att pröva även i våra kommuner (DORA, 2025). Gemensamma arbetssätt och tydligt ansvar kan hjälpa oss att omsätta tekniken i nytta, men otydlig styrning kan samtidigt ge oss fler lösningar som ingen riktigt äger vilket blir problematiskt på lång sikt.

Det senare vore särskilt olyckligt när målet, som jag beskrivit i Proaktiv och prediktiv ärendehantering – ett återbesök, är att ge invånaren sammanhängande hjälp. Tjugo snabbare byggda tjänster med tjugo separata informationsflöden gör inte automatiskt mötet med kommunen mer sammanhållet.

För att vi verkligen ska börja lära oss hur AI påverkar utvecklingen skulle jag vilja börja med ett begränsat, verkligt behov och ett team där verksamhet och utveckling arbetar tillsammans. Det gör vi i och för sig redan i en del initiativ, men jag skulle lägga till att det ska dokumenteras vilka verktyg som används, mäta tiden från idé till användbar tjänst, följ kvaliteten även efter införandet, ge teamet utrymme att förstå lösningen, och sedan göra likadant igen i nästa initiativ när verktygen eller förutsättningarna ändras. Resultat och kod ska såklart delas för återanvändning med andra kommuner. I beslutsunderlaget att starta detta skulle jag också skriva ut vilka antaganden som beslutet vilar på, när de senast prövades och vem som ansvarar för att följa upp dem. Ett tidigare negativt försök behöver en tidpunkt för omprövning, och ett positivt försök behöver följas när modellen, användningen eller kraven ändras. Inför ett beslut som binder kommunen under flera år bör de avgörande antagandena kontrolleras på nytt.

För mig är frågan därför hur AI förändrar systemutvecklingen, i vilken takt och på vilka grunder vi bedömer förändringen. Svaret behöver rymma både nya möjligheter och det vi ännu inte vet. Vi behöver kunna visa vad ett beslut bygger på, hur relevant underlaget är och om dess viktigaste antaganden fortfarande håller, annars kan gammal information göra vår digitalisering både dyrare och långsammare, just när samhället behöver att vi använder våra resurser bättre.

Källor och vidare läsning

Källorna nedan kontrollerades den 1 oktober 2026.

  • Becker, J., Rush, N., Barnes, B. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, 10 juli. Randomiserad studie med data från februari–juni 2025. Läs studien och metodbeskrivningen.
  • Becker, J. et al. (2026). We are Changing our Developer Productivity Experiment Design. METR, 24 februari. Uppföljning som startade i augusti 2025; betydande urvalsproblem och osäkra effektstorlekar. Läs uppföljningen.
  • Government Digital Service (2025). AI coding assistant trial: UK public sector findings report. Publicerad 12 september; försöket genomfördes november 2024–februari 2025. Enkäter, telemetri och kvalitativa uppgifter, inte ett randomiserat effektmått. Läs rapporten.
  • Ng, K. K. B., Fauzi, L., Leow, L. & Ng, J. (2024). Harnessing the Potential of Gen-AI Coding Assistants in Public Sector Software Development. GovTech Singapore. Tillgänglig på arXiv från 25 september 2024. Läs forskningsrapporten.
  • Cunningham, T. & Whitfill, P. (2026). Task Substitution and Uplift. METR, 8 maj. Analytiskt resonemang om hur ändrade uppgiftsval påverkar produktivitetsmått. Läs analysen.
  • Brynjolfsson, E., Chandar, B. & Chen, R. (2025, reviderad 2026). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence. Stanford Digital Economy Lab. Version 12 augusti 2026 med amerikanska lönedata till juni 2026; beskrivande arbetsmarknadsanalys. Läs rapporten.
  • Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. Experimentell preprint med 52 deltagare. Anthropics presentation publicerades 29 januari; studien mäter omedelbar förståelse, inte långsiktigt lärande. Läs forskarnas presentation.
  • Thoughtworks (2026). Codebase cognitive debt. Technology Radar, 15 april. Erfarenhetsbaserad expertbedömning. Läs beskrivningen.
  • Storey, M.-A. (2026). From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI. Konceptuell preprint, arXiv:2603.22106; första version 23 mars, version 4 den 6 april. Läs artikeln.
  • Regeringskansliet (2026). Sveriges AI-strategi, 20 februari, samt regeringens sammanfattning. Läs strategin och handlingsplanen.
  • SCB (2025). Artificiell intelligens i Sverige 2025. Statistik om AI-användning i företag med minst tio anställda under 2025. Läs statistiknyheten.
  • SKR (2026). Action plan för välfärdens kompetensförsörjning. Sidan innehåller material för satsningen 2026. Läs om arbetet.
  • DORA (2025). State of AI-assisted Software Development. Forsknings- och branschrapport från DORA, som drivs av Google Cloud. Läs rapportens presentation och hämta rapporten.
← Tillbaka till bloggen