Slår AI vores udviklingscyklusser i stykker?

En af de ting, jeg tænker meget over for tiden, er, om AI stille og roligt er ved at bryde nogle af de antagelser, moderne softwareudvikling har været bygget op omkring i årtier.

Ikke fordi Scrum, Agile eller iterativ udvikling var forkert. Men fordi mange af de idéer blev skabt i en verden med fundamentalt andre forudsætninger.

I årevis har en af kerneidéerne i softwareudvikling været betydningen af korte feedback-loops: To-ugers sprints, hurtige iterationer, kontinuerlig læring og tæt samarbejde med forretningen. Logikken var sund: Hvis vi arbejder for længe uden feedback, øger vi risikoen for at bygge det forkerte.

Men hvad sker der, når den mængde arbejde, der kan produceres inden for de samme feedback-loops, pludselig ændrer sig markant?
Jeg ser allerede udviklere, der bruger værktøjer som Claude Code og AI-agenter, blive to til tre gange mere produktive i visse sammenhænge. Arbejde, der før tog uger, kan pludselig laves på dage.

Og det rejser et interessant spørgsmål: Hvis et to-ugers sprint nu indeholder, hvad der før svarede til fire, otte eller endda flere ugers output, arbejder vi så stadig med korte feedback-loops? Eller har vi ubevidst genskabt langcyklus-udvikling, bare gemt inde i den samme kalenderstruktur?

Jeg tror, det her kun er begyndelsen. Lige nu føles AI ofte som de tidlige dage med computere. I starten erstattede computere primært manuel bogføring og skrivemaskiner. Eksisterende processer forblev stort set intakte. Tingene blev bare hurtigere og mere effektive.

Men det virkelig transformerende skift kom senere, med computere koblet sammen via netværk, internettet, cloud computing og SaaS-platforme. Alt sammen muliggjorde helt nye operating models. Min vurdering er, at AI vil følge en lignende bane.

I dag skriver mange udviklere stadig kode direkte, bare hurtigere og med mere assistance, svarende til introduktionen af elektronisk bogføring og tekstbehandling. Men agentisk udvikling er allerede på vej, og værktøjer som Claude Code giver os et glimt af noget langt større, selvom jeg ikke tror, det er blevet mainstream endnu.

Jeg tror, udviklere i stigende grad vil orkestrere agenter i stedet for selv at skrive det meste af koden. Hvis du allerede ved, hvordan koden skal skrives, er der et voksende argument for, at du måske ikke længere behøver at skrive hver linje manuelt. Du kan i stedet guide agenter, der genererer kode i din foretrukne stil, arkitektur og kvalitetsstandard.

På det tidspunkt begynder rollen at skifte. Udvikleren bliver mindre en ren producent og mere en orkestrator, reviewer, arkitekt og beslutningstager.

Og hvis produktiviteten ikke stiger med 2x eller 3x, men 10x eller 20x over tid, så bliver implikationerne meget større end blot individuelle produktivitetsgevinster. For på et tidspunkt holder softwareudvikling måske op med at være flaskehalsen.

Alt omkring den bliver flaskehalsen i stedet: Pull request-reviews, governance-processer, manuel test, godkendelser, møder, deployment pipelines, beslutningsstrukturer, organisatorisk koordinering osv.

Mange organisationer er i dag optimeret til en verden, hvor det er dyrt og relativt langsomt at skrive software. Hvad sker der, når softwaregenerering bliver næsten øjeblikkelig, men organisatoriske beslutninger stadig bevæger sig med menneskelig hastighed? Hele systemet begynder at se anderledes ud.

Og det rejser endnu et interessant spørgsmål: Hvad sker der med Scrum og faste sprintcyklusser i en verden, hvor produktionshastigheden accelererer dramatisk?

For at være fair ved jeg godt, at mange organisationer allerede er bevæget sig mod kortere cyklusser, continuous delivery-modeller, Kanban-inspirerede flow-systemer og mere fleksible måder at arbejde på. Nogle har allerede forladt klassisk Scrum helt.

Men jeg tror, implikationerne her går meget dybere end, om et team kører to-ugers sprints eller ej. For det handler ikke kun om softwareudviklingsteams. Det her ændrer potentielt hastigheden på hele systemet omkring produktudvikling: Kundefeedback, marketing, eksperimenter, product discovery, deployment, drift, governance og beslutningstagning.

Alle processer, der er forbundet med at bygge, lancere og videreudvikle softwareprodukter. Og hvis softwareskabelse accelererer dramatisk, så kommer alle omkringliggende organisatoriske systemer pludselig under pres for også at udvikle sig.

Det er en del af grunden til, at jeg i stigende grad tror, fremtiden vil bevæge sig endnu længere mod kontinuerlig deployment, flow-baserede systemer, Kanban-inspireret tænkning og højautomatiserede operationelle modeller. Ikke fordi Scrum var forkert, men fordi antagelserne under Scrum er ved at ændre sig.

Hvis én eller to personer med AI-agenter pludselig kan opnå det, der før krævede store teams, så begynder selve team-dynamikken at ændre sig. I stedet for blot at videreudvikle eksisterende måder at arbejde på, bliver vi måske nødt til at opfinde helt nye.

• Hvordan ser ledelse ud i den verden?
• Hvordan ser koordinering ud?
• Hvad sker der med roller?
• Hvad sker der med organisationsdesign?

Og for at tage et klassisk Scrum-eksempel: Hvad sker der med retrospektiver?

Vil AI-agenter til sidst analysere leverancemønstre, incidents, samarbejdsflaskehalse, deployment-fejl og kundefeedback kontinuerligt i realtid? Vil forbedringsloops selv blive automatiserede? Vil retrospektiver udvikle sig fra planlagte møder til always-on læringssystemer?

Og hvis teams i stigende grad bliver mennesker, der orkestrerer samlinger af agenter, er der så overhovedet brug for klassiske Scrum Master-kapabiliteter på samme måde, som vi kender dem i dag? Eller bliver selve orkestreringen til noget fundamentalt andet?

Jeg ved det ikke. Men jeg er i stigende grad overbevist om, at vi ser ind i noget meget større end produktivitetsgevinster. Vi ser ind i et skift i, hvordan arbejde designes, koordineres, ledes og forbedres.

Og jeg glæder mig oprigtigt til at være en del af den fremtid og være med til at forme, hvordan software, teams og organisationer kommer til at fungere i det kommende årti.

Hvad tænker du?