Whitepaper · 14 sidor · av Bo Wesdorp
Hur AI förändrade systemutvecklingen
Sedan 2022 har utvecklingsteam tagit i bruk AI-verktyg i sex vågor, från autokomplettering i editorn till agenter som arbetar på egen hand. Den här sidan följer resan: vilka verktyg som kom när, hur vart och ett förändrade det dagliga arbetet och vad de team som fick ut mest av dem gjorde annorlunda.
Jag har byggt om hur våra utvecklare arbetar fyra gånger sedan 2022. Varje gång kom något som tog bort en begränsning, och inom några månader var det tydligt att arbetet inte hade försvunnit. Det hade flyttat.
De flesta team jag pratar med köpte verktygen i den ordningen och ändrade inget annat. De har Copilot-licenser från 2023 och budget för agenter från i år, och de kör dem mot en granskningsprocess, en definition av klart och en bemanningsplan som alla härstammar från tiden då det var dyrt att skriva kod.
I våra egna projekt kommer nu 80 till 90 procent av produktionskoden från en modell. Det gjorde oss inte snabbare i sig. Det som tog oss från tio utvecklare till fyra var att bygga om allt runt omkring.
Fyra år med AI-verktyg i utveckling
De flesta team köpte verktygen i den här ordningen och ändrade inget annat runt omkring. Välj en våg för att se vad teamen tog i bruk, hur arbetet förändrades och vad som blev kvar till nästa våg. Stacken byggs på allt eftersom.
2022 till 2023 · Våg 1
Kodkomplettering
- Vad teamen började använda
- Team köpte licenser till GitHub Copilot. Kodkompletteringen låg i editorn och krävde ingen ändring i arbetssättet, och därför spreds den så snabbt.
- Så förändrades arbetet
- Utvecklare slutade skriva standardkod för hand och började acceptera förslag med Tab.
- Kvar till nästa våg
- Att avgöra vad som ska skrivas
2023 till 2024 · Våg 2
Chatt
- Vad teamen började använda
- Utvecklare hade ChatGPT eller Claude öppet bredvid editorn och klistrade in kod fram och tillbaka. GitHub Copilot Chat flyttade in chatten i IDE:n, och Cursor avslutade den eran genom att låta modellen läsa hela repot.
- Så förändrades arbetet
- Arbetet började med att beskriva problemet i ord i stället för att skriva koden.
- Kvar till nästa våg
- Att få modellen att förstå ditt system
2024 till 2025 · Våg 3
Kontext
- Vad teamen började använda
- Model Context Protocol kom i slutet av 2024. Teamen lade till filerna CLAUDE.md, AGENTS.md och .cursorrules i sina repon, och Aider, Cline och Windsurf förde in agentbaserad redigering i editorn.
- Så förändrades arbetet
- Utvecklare började skriva för modellen: kontextfiler i repot och direkta kopplingar till ärenden, scheman och felloggar.
- Kvar till nästa våg
- Att avgöra vad modellen får göra
Tidigt 2026 · Våg 4
Harness
- Vad teamen började använda
- Claude Code med hooks, skills och subagents, OpenAI Codex och LangChain Deep Agents gjorde modellen till en agent. Langfuse och Braintrust visade vad agenten faktiskt gjorde.
- Så förändrades arbetet
- Agenten körde testerna, läste felet, rättade det och öppnade pull requesten. Utvecklarna konfigurerade vad den fick komma åt.
- Kvar till nästa våg
- Att prompta vid varje varv, och omdömet i uppsättningen
Mitten av 2026 · Våg 5
Loop
- Vad teamen började använda
- Claude Code lanserade /loop i mars 2026, Codex lade till goals, och GitHub Copilot coding agent och OpenClaw tog över arbete från tickets. Befintlig CI blev utlösaren och oftast också verifieraren.
- Så förändrades arbetet
- Agenter körs enligt schema eller vid en händelse utan att någon godkänner varje varv. Utvecklarna utformar kontrollen som säger åt dem att stanna.
- Kvar till nästa våg
- Att verifiera det som kommer tillbaka
Nu · Våg 6
Verifiering
- Vad teamen började använda
- Teamen lägger till AI-granskning (CodeRabbit, Greptile, Qodo, Graphite), skanning av vad agenten har kommit åt (Semgrep, Snyk, Socket) och verktyg som visar granskningskön (Faros, LinearB). De team som rör sig snabbast ändrar också arbetsordningen.
- Så förändrades arbetet
- Specen och acceptanstesterna skrivs innan agenten startar. Då kontrolleras de flesta ändringar automatiskt, och människor läser bara de riskfyllda.
- Kvar till nästa våg
- Att skriva specen och testerna en gång, innan agenten körs
2022 till 2023 · Komplettering
Våg 1 av 6Kodkomplettering tog bort skrivarbetet
Vad teamen började använda
Team köpte licenser till GitHub Copilot. Kodkompletteringen låg i editorn och krävde ingen ändring i arbetssättet, och därför spreds den så snabbt.
Så förändrades arbetet
Utvecklare slutade skriva standardkod för hand och började acceptera förslag med Tab.
GitHub Copilot lade en modell i editorn och avslutade raden du skrev. Den tog bort boilerplate från jobbet, och ingen saknar det arbetet.
Den gjorde också fel angreppssätt precis lika snabbt att skriva som rätt. Begränsningen flyttade från hur snabbt man kunde skriva till om man visste vad man skulle skriva.
Var fokus ligger
Att känna till rätt angreppssätt innan förslaget dyker upp. Ett snabbt fel svar är fortfarande ett fel svar.
- Löst
- Boilerplate och nästa kodrad
- Kvar till nästa våg
- Att avgöra vad som ska skrivas
Verktygen i den här vågen
Testar vi för det här?
DelvisVi testar det som komplettering inte kan göra åt dig
Ingen poängsätts på skrivhastighet eller på hur väl man använder autocomplete. Bedömningen av grunderna körs med alla AI-verktyg avstängda. En utvecklare som inte kan resonera om ett system utan förslag kan inte heller avgöra när ett förslag är fel.
2023 till 2024 · Chat
Våg 2 av 6Chat gjorde en beskrivning till ett kodblock
Vad teamen började använda
Utvecklare hade ChatGPT eller Claude öppet bredvid editorn och klistrade in kod fram och tillbaka. GitHub Copilot Chat flyttade in chatten i IDE:n, och Cursor avslutade den eran genom att låta modellen läsa hela repot.
Så förändrades arbetet
Arbetet började med att beskriva problemet i ord i stället för att skriva koden.
ChatGPT och Claude gjorde en problembeskrivning till ett kodblock. För en utvecklare på mellannivå var det det största enskilda hoppet på hela tidslinjen.
Ingen av dem kunde se ditt system. Ett år av prompt engineering följde, en verklig färdighet som användes på fel lager. Chat lärde också de utvecklare som läste förklaringen och gjorde dem som inte läste den snabbare.
Var fokus ligger
Att läsa förklaringen och inte bara koden, och att märka när svaret är skrivet för ett system som inte är ditt.
- Löst
- Att göra en beskriven problemställning till fungerande kod
- Kvar till nästa våg
- Att få modellen att förstå ditt system
Verktygen i den här vågen
Testar vi för det här?
JaVi testar om de kan förklara en ändring som de inte skrivit själva
I AI-native-bedömningen kör utvecklaren sina egna verktyg, och vi frågar varför agenten valde sitt tillvägagångssätt. ”Agenten gjorde det” godtar vi inte som förklaring, och en utvecklare som skickar om samma vaga uppmaning i stället för att rätta indata får låga poäng.
2024 till 2025 · Kontext
Våg 3 av 6Kontext gjorde det du matar modellen med till produkten
Vad teamen började använda
Model Context Protocol kom i slutet av 2024. Teamen lade till filerna CLAUDE.md, AGENTS.md och .cursorrules i sina repon, och Aider, Cline och Windsurf förde in agentbaserad redigering i editorn.
Så förändrades arbetet
Utvecklare började skriva för modellen: kontextfiler i repot och direkta kopplingar till ärenden, scheman och felloggar.
Här slutade branschen se modellen som produkten och började se det man matar den med som produkten. Det är också det lager som de flesta team fortfarande befinner sig i, oavsett vad de tror om sig själva.
Det som ingen varnar för är förfall. Filen som stämde i mars beskriver ett system som slutade finnas i september, och en inaktuell kontextfil är värre än ingen alls: den gör agenten säker men fel, på ett sätt som klarar granskningen. Vi räknar uppdateringen som en del av definitionen av klart.
CLAUDE.md, AGENTS.md och .cursorrules innehåller det som en ny utvecklare behöver veta, nedskrivet där verktyget läser det vid varje körning.
Publicerad av Anthropic i slutet av 2024. Det är en standard för att ge en modell tillgång till sådant som inte är filer: ärendehanteringen, schemat och felloggen.
Var fokus ligger
Att hålla kontextfiler aktuella. En inaktuell CLAUDE.md ger säkert men felaktigt arbete som ändå klarar granskningen.
- Löst
- Modellen kan läsa ditt repository, dina ärenden och ditt schema
- Kvar till nästa våg
- Att avgöra vad modellen får göra
Verktygen i den här vågen
Testar vi för det här?
JaVi bedömer den kontext de sätter upp och det de lämnar efter sig
Prompt- och kontextengineering är ett av de sex AI-native-kriterierna: ger uppsättningen användbart resultat på en eller två omgångar? Vi tittar också på om utvecklaren lämnar något som gör nästa ärende enklare, till exempel en tajtare CLAUDE.md eller ett återanvändbart kommando.
Tidigt 2026 · Harness
Våg 4 av 6Harnessen: en agent är en modell plus allt runt omkring
Vad teamen började använda
Claude Code med hooks, skills och subagents, OpenAI Codex och LangChain Deep Agents gjorde modellen till en agent. Langfuse och Braintrust visade vad agenten faktiskt gjorde.
Så förändrades arbetet
Agenten körde testerna, läste felet, rättade det och öppnade pull requesten. Utvecklarna konfigurerade vad den fick komma åt.
Begreppen kom i februari 2026. Mitchell Hashimoto använde uttrycket harness engineering, och inom några veckor var det en disciplin byggd på en enda mening: en agent är en modell plus en harness.
Modellen är den del du inte styr över och kan byta ut. Harnessen är allt annat: loopen som kör den, verktygen den kan anropa, hur kontexten komprimeras när en uppgift drar ut på tiden, sandlådan den körs i, behörighetsgränserna, hooks som körs före och efter en åtgärd, subagenterna den kan starta och observerbarheten som i efterhand visar vad den gjorde. Det förklarade varför två företag med samma modell och samma licens får helt olika resultat.
Säkerhet fick en ny form här. En harness är ett system med inloggningsuppgifter och verktygsåtkomst, där en modell avgör vad som anropas. Det du granskar är därför inte längre bara koden. Det är också vad agenten fick nå.
Var fokus ligger
Besluten i uppsättningen. Vilka verktyg agenten kan anropa, var sandlådans gräns går och vad en hook blockerar gäller nu allt som teamet levererar.
- Löst
- En agent som kan slutföra något: köra testerna, läsa felet, åtgärda det och öppna pull requesten
- Kvar till nästa våg
- Att prompta vid varje varv, och omdömet i uppsättningen
Verktygen i den här vågen
Testar vi för det här?
DelvisVi testar orkestrering, inte en komplett harness-uppbyggnad
Verktygsorkestrering poängsätts i AI-native-bedömningen: vad utvecklaren lämnar till agenten, vad utvecklaren behåller själv och om arbete körs parallellt i separata worktrees. Att utforma ett teams sandlåda, behörigheter och hooks ryms inte på sextio minuter. För plattformsroller lägger därför DevOps-bedömningen till en genererad pipelineändring med en behörighet som är bredare än den ser ut.
Mitten av 2026 · Loop
Våg 5 av 6Loopen kör agenter utan att någon godkänner varje steg
Vad teamen började använda
Claude Code lanserade /loop i mars 2026, Codex lade till goals, och GitHub Copilot coding agent och OpenClaw tog över arbete från tickets. Befintlig CI blev utlösaren och oftast också verifieraren.
Så förändrades arbetet
Agenter körs enligt schema eller vid en händelse utan att någon godkänner varje varv. Utvecklarna utformar kontrollen som säger åt dem att stanna.
Vi hade agenter som kunde slutföra riktiga uppgifter, och seniora utvecklare som satt och godkände varje steg. En harness utrustar en körning. En loop sätter ihop många körningar, startade enligt schema eller av en händelse och begränsade av något som en maskin kan kontrollera.
Claude Code lanserade /loop i mars 2026 och Codex lade till goals i april. Din befintliga CI är oftast både trigger och verifierare.
Var fokus ligger
Verifieraren och stoppvillkoret. Båda utformas innan loopen körs.
- Löst
- En senior utvecklare som skriver ”ja, fortsätt” i fyra fönster
- Kvar till nästa våg
- Att verifiera det som kommer tillbaka
En loop som fungerar
- Verifieraren utformas före loopen
- Stoppvillkoret är något en maskin kan kontrollera
- Den körs först på en smal, vältestad yta
- Någon läser morgonens resultat
En loop som bränner pengar
- Agenten skrev själv de tester den bedöms mot
- Stoppvillkoret är ”tills det ser klart ut”
- Den riktades mot hela kodbasen första dagen
- Ingen kan säga vad den ändrade i natt
Verktygen i den här vågen
Testar vi för det här?
NejVi testar inte loopar, vi testar det de bygger på
En loop som körs utan tillsyn kräver timmar, en riktig CI och en kodbas som utvecklaren känner till. En bedömning på 60 minuter kan därför inte visa det. Det vi kan se är grunden som en loop behöver: om utvecklaren delar upp ett vagt ärende i bitar som en maskin kan kontrollera, och om utvecklaren verifierar resultatet i stället för att lita på det för att det kompilerar.
Nu · Verifiering
Våg 6 av 6Verifiering är flaskhalsen, och spec- och testdriven utveckling löser den
Vad teamen började använda
Teamen lägger till AI-granskning (CodeRabbit, Greptile, Qodo, Graphite), skanning av vad agenten har kommit åt (Semgrep, Snyk, Socket) och verktyg som visar granskningskön (Faros, LinearB). De team som rör sig snabbast ändrar också arbetsordningen.
Så förändrades arbetet
Specen och acceptanstesterna skrivs innan agenten startar. Då kontrolleras de flesta ändringar automatiskt, och människor läser bara de riskfyllda.
Fem flaskhalsar löstes med nästa release. Den här gör det inte. Ett working paper från Harvard visade att företag som införde kodagenter skrev cirka 30 procent mer kod, blev inte klara med mer arbete och fick vänta 49 procent längre på att koden gick igenom granskning. AI-verktyg för granskning stängde inte glappet.
När varje ändring väntar på att en senior ska läsa den blir dina seniora utvecklare kön. Spec- och testdriven utveckling tar bort dem ur kön. Specen och acceptanstesterna skrivs innan agenten genererar något, så varje körning kontrolleras automatiskt mot något som agenten inte styr över. Människor läser bara det som testerna inte kan bedöma.
Var fokus ligger
Skriv specen och acceptanstesterna först. Då står testerna för det mesta av verifieringen och dina seniora utvecklare läser bara det som testerna inte kan bedöma.
- Löst
- Spec- och testdriven utveckling: kontrollerna finns före koden
- Kvar till nästa våg
- Att skriva specen och testerna en gång, innan agenten körs
Granskning är din flaskhals
- Fler pull requests mergas helt utan granskning
- Agentskrivna pull requests väntar mycket längre innan någon tar tag i dem
- Dina seniora utvecklare är kön, och nya regler gör den längre
- Agenter överger sina egna pull requests när återkopplingen inte är en misslyckad kontroll
Du har kommit förbi det här
- Specen och testerna finns innan koden genereras
- Verifieraren är oberoende av det som skrev ändringen
- Granskningens djup styrs av vad en ändring kan förstöra
- Kön är tom i slutet av veckan
Verktygen i den här vågen
Granskning
Hur långt agenten kom
Se kön
Testar vi för det här?
JaVerifiering väger tyngst i våra bedömningar
Verifiering av AI-output är det kriterium vi väger tyngst för AI-native utvecklare: att fånga påhittade API:er, subtilt felaktig logik och säkerhetsluckor innan de går i produktion. Spec-driven utveckling poängsätts i samma session. Vi tittar på om utvecklaren skriver ner vad ändringen ska göra och hur den ska kontrolleras innan agenten startar. Vi bedömer också om utvecklaren anpassar granskningen efter risk. QA-utvecklare får verifiera en funktion de inte har designat, med genererade tester som alla går igenom men täcker fel sak.
Sex arbetssätt hos teamen som har kommit längst
Bocka i det som ditt team redan gör. Vid fyra eller fler har teamet tagit till sig arbetssättet och inte bara verktygen.
Bocka i det som ditt team redan gör.
Engineering Leader Benchmark Q4 2026
Se vilket lager ditt team befinner sig på
Benchmarken frågar hur ditt team arbetar med agenter, hur ni verifierar och hur ni planerar. Du ser ditt resultat på åtta minuter, jämfört med team i din storlek när tillräckligt många har svarat.
Frågor om vitboken
Vår andra whitepaper beskriver de två bedömningar som varje utvecklare går igenom.
Nästa generations 10X-utvecklareVad är den största flaskhalsen i AI-assisterad systemutveckling?
Verifiering. Kodagenter har ökat mängden kod, men granskningstiden har ökat lika mycket. Ett working paper från Harvard som omfattar 718 företag visade 30 procent mer kod, ingen märkbar ökning av färdigt arbete och 49 procent längre tid från pull request till merge.
I vilken ordning har utvecklingsteam börjat använda AI-verktyg?
I sex vågor: kodkomplettering som GitHub Copilot (2022 till 2023), chatt som ChatGPT och Claude (2023 till 2024), kontext genom Model Context Protocol och filer som CLAUDE.md och AGENTS.md (2024 till 2025), agent-harnesses som Claude Code och OpenAI Codex (tidigt 2026), loopar som kör agenter utan godkännande vid varje steg (mitten av 2026) och nu granskning, skanning samt spec- och testdriven utveckling för att verifiera det agenterna producerar.
Vilka AI-verktyg bör ett utvecklingsteam börja med?
Verktygen spelar mindre roll än i vilken ordning arbetet runt dem införs. De flesta team har redan komplettering och chatt. Nästa steg som lönar sig är kontext: en underhållen CLAUDE.md eller AGENTS.md och kopplingar till ärenden och scheman. Agenter och loopar lönar sig först när teamet skriver spec och tester innan agenten startar.
Vad är harness engineering?
Harness engineering är att utforma allt runt modellen: loopen som kör den, verktygen den kan anropa, komprimering av kontext, sandlådan, behörigheter, hooks, subagenter och observerbarhet. Mitchell Hashimoto gav begreppet dess namn i februari 2026 och sammanfattade det som agent = model + harness.
Vad är skillnaden mellan context engineering och harness engineering?
Context engineering avgör vad modellen ser, genom filer som CLAUDE.md och AGENTS.md och protokoll som MCP. Harness engineering omfattar hela körmiljön runt modellen, inklusive vad den får göra och hur dess arbete kontrolleras.
Testar Miyagami utvecklare på de här färdigheterna?
På de flesta av dem. Verifiering, context engineering, orkestrering av verktyg och förmågan att förklara genererad kod poängsätts i vår AI-native-bedömning, och fundamentals-bedömningen genomförs med AI-verktygen avstängda. Vi testar inte loopar som körs utan tillsyn, eftersom en session på sextio minuter inte kan visa dem på ett tillförlitligt sätt.
Få en shortlist inom tre dagar
Du skickar roller och stack i ett kort formulär eller under ett samtal på trettio minuter. Inom tre arbetsdagar får du namngivna senior utvecklare att granska, alla med båda scorecards, och du kan hyra in inom fem.
ISO 27001Certifierad