Marc-André MoreauNote: dette lange indlæg blev oprindeligt skrevet til essayudfordringen hos The Pragmatic Engineer om, hvordan softwareudvikling ændrer sig.
Oktober 2025. Claude Sonnet 4.5 er lige udkommet, og alle hos Devolutions er i gang med AI-uddannelse fra Mindstone. Budskabet fra CEO’en er klart: vi tager alle de nødvendige skridt for at gøre virksomheden AI-native. Medarbejdere får tilbudt en frivillig fratrædelsespakke, hvis de ikke vil være en del af det nye „Devolutions 2.0“. Medarbejdere, der bliver, skal forpligte sig og satse fuldt ud på AI sammen med resten af os. Her er historien om det gennemgribende skift hos Devolutions, og om hvordan en stor migrering, der oprindeligt var anslået til tre år, blev gennemført på bare ét.
Devolutions er en selvfinansieret canadisk softwarevirksomhed med hovedkontor i Lavaltrie, Quebec, og over 250 medarbejdere over hele verden. Navnet „Devolutions“ står for „Development Evolutions“, fra dengang stifteren, David Hervieux, tog opgaver med softwareudvikling, længe før den kommercielle succes, vores flagskibsprodukt, Remote Desktop Manager (RDM), har i dag. RDM er et program til forbindelsesstyring: det starter forbindelser med indsættelse af legitimationsoplysninger for protokoller som RDP, SSH, VNC, ARD, PowerShell osv. Hvis noget tager imod legitimationsoplysninger og opretter forbindelse, understøtter RDM det sandsynligvis allerede.
Mit team er lidt særligt: det omfatter udviklerne fra filialkontoret i Ottawa, men også udviklere i USA, Tyskland og Japan. Internt kalder vi det arkitekturteamet, fordi vi er ansvarlige for at bygge mange genbrugelige komponenter, som andre teams bruger. Strukturen er meget løs, men alle er meget selvstændige, motiverede og ansvarlige. De fleste teams hos Devolutions arbejder på kontoret, ikke på afstand, i hovedkontoret i Lavaltrie.
Selv er jeg CTO hos Devolutions. I et tidligere liv grundlagde jeg projektet FreeRDP. Jeg er Microsoft MVP i kategorierne Windows og PowerShell. Min primære ekspertise ligger i Windows-protokoller, især RDP og godkendelse. Jeg har en evne til reverse engineering og til at grave mig ned i systemernes indre. Jeg kan lide at eksperimentere med teknologi for at finde måder, vi kan samle brikkerne i puslespillet på og bygge de produkter, vi ønsker.
Windows-skrivebordsprogrammer bliver ofte ladt i stikken i AI-verdenen: de mest populære værktøjer udkom først uden understøttelse af Windows, og da understøttelsen endelig kom, var den kun delvis. Skrivebordsprogrammer er, til forskel fra webprogrammer, markant dårligere stillet, fordi de er meget sværere at validere automatisk med AI. På trods af de udfordringer lykkedes det os at porte Remote Desktop Manager, et massivt .NET-virksomhedsprogram med tusindvis af UI-dialogbokse, til Avalonia, et UI-framework på tværs af platforme, på mindre end et år. Endnu mere overraskende nåede Windows-migreringen 100 % først, foran andre platforme med mindre teknisk gæld.
Tre år komprimeret til ét
Det store Avalonia-migreringsprojekt
Vi prioriterer skrivebordet, og vi er fast besluttet på at lave fremragende skrivebordsprogrammer. Derfor sponsorerer vi Avalonia med 3 millioner USD over 3 år. Grunden er enkel: vi vil ikke ofre oplevelsen i skrivebordsprogrammet ved at bruge et webprogram i trenchcoat, som Electron, men vi skal stadig lette udviklingsbyrden ved at migrere til et UI-framework på tværs af platforme i .NET. Vi har gennem årene samlet meget ældre kode og mange avancerede funktioner, så vi har ikke råd til at skrive det hele om til et nyt UI-framework mellem to hovedversioner. Før AI anslog vi indsatsen til mindst 3 år. Avalonia gav os muligheden for en delvis migrering, så vi kunne blande native UI-elementer med Avalonia.
Det er den mest ambitiøse migrering, der nogensinde er forsøgt hos Devolutions: over 1.500 WinForms-UI-elementer, der rækker mere end et årti tilbage, bare for RDM Windows. Andre platforme har langt færre native UI-elementer. I oktober 2025 undersøgte jeg, hvordan vi kunne bruge AI til at fremskynde det, for på det tidspunkt var migreringen stadig mest manuel. Det første, jeg gjorde, var at lave et script, der gennemgik kildefiler i vores monorepo og registrerede antallet af platformspecifikke UI-elementer, der skulle migreres, fra det allerførste commit, hvor Avalonia blev introduceret. Det tal blev vores udgangspunkt, og hver platform skulle bringe det ned på nul ved at fjerne elementerne, efterhånden som de blev erstattet af Avalonia.
Det samlede antal for alle platforme tilsammen var over 5.800 UI-elementer, der skulle portes, og på det tidspunkt var fremdriften knap nok nogle få procent for hver platform.
Fasen med AI-slop-kanonen
Tidlige forsøg på at fremskynde Avalonia-migreringen førte til en masse AI-slop, og det meste af det var jeg personligt ansvarlig for. Frustrationen var heldigvis kun midlertidig, og når jeg ser tilbage, var det et nødvendigt skridt for at lære. Den egentlige værdi af fasen med AI-slop-kanonen var at vække de udviklere, der vidste, hvad de gjorde, så de begyndte at tilføje og forbedre instruktionerne til AI, for at den lavede færre fejl.
Udfordringerne var disse:
- Jeg lavede ikke meget UI selv, så jeg vidste ikke, hvad jeg gjorde
- AI-modeller fra for et år siden lavede mange fejl
- AI havde ikke de rigtige værktøjer til at se før og efter
RDM understøtter mange forbindelsesposter, især VPN’er, som brugere kan bruge som afhængighed for en anden forbindelsespost. De kan for eksempel have en RDP-forbindelse, der automatisk starter en WireGuard-VPN, hvis den er nødvendig for at oprette forbindelse til den tilknyttede RDP-server. Jeg besluttede at prøve at porte VPN-forbindelsesposten først, i håb om at udtrække nok instruktioner til, at AI blev god til at porte alle de andre VPN-poster. Det krævede et par forsøg, og jeg måtte bede kolleger hjælpe mig med at rette ting på en eksperimentel branch, hvorefter jeg opdaterede instruktionerne ved at pege LLM’en på commits, så den kunne lære af dem. Efter et par iterationer som disse var instruktionerne gode nok til, at jeg automatisk kunne porte et par andre typer VPN-poster, men de krævede stadig mange rettelser.
Processen blev halvmanuel: jeg startede en session, hvor jeg bad agenten analysere og opremse de næste enkleste typer VPN-poster, jeg kunne porte. Jeg tog en batch på 10 ad gangen, startede derefter RDM manuelt for at tage skærmbilleder før og efter og satte dem ind i AI-agenten igen. Skærmbillederne alene hjalp meget med at få det visuelle rigtigt, men mange problemer dukkede først op, når man klikkede og prøvede ting af. Mange elementer krævede, at bestemt VPN-software var installeret og kunne bruges, så det var ikke let at teste alt. Jeg migrerede omkring hundrede forbindelsesposter på den måde. Efter min bedste viden fungerede de, men mange små problemer smuttede igennem, og andre måtte bruge tid på at rette dem.
Der tog jeg en pause, for mit mål var at sætte AI-migreringsprocessen i gang: én enkelt Markdown-fil på 5.000 linjer med instruktioner fra WinForms til Avalonia, slebet gennem de tidlige forsøg, blev nu brugt med succes af nogle få udviklere. Migreringen gik ikke med halsbrækkende fart, men den gik stadig hurtigere end før. Inderst inde vidste jeg, at vi kun var måneder fra, at den rette person satte farten op, når vedkommende fuldt ud havde forstået, hvordan processen optimeres effektivt, så det meste af tiden bruges på gennemgang og hurtige rettelser, mens langt det meste af udførelsen klares af AI. Forestil Dem en person, der tester i stil med kvalitetssikring (QA) og gennemgår hundredvis af UI-dialogbokse for at validere dem, og som også har selvtillid til at rette koden i stedet for blot at åbne en sag. Heldigvis skete det til sidst!
Accelerationen af Avalonia-migreringen
I begyndelsen af april 2026 nåede RDM Windows 25 % af Avalonia-migreringen. I slutningen af samme måned blev milepælen på 50 % nået.
Der blev gjort betydelige fremskridt hen over sommeren, indtil vi nåede milepælen på 100 % i RDM Windows i begyndelsen af september:
Det er et markant brud med tempoet fra migreringens første dage. Hvad ændrede sig?
- Der blev tilføjet mange delte, genbrugelige Avalonia-komponenter for at gøre migreringen lettere
- Folk, der vidste, hvad de gjorde, tog sig tid til at forbedre AI-instruktionerne
- En håndfuld personer gennemgik hundredvis af UI-komponenter ad gangen
De oprindelige AI-migreringer, der indførte slop, hjalp også med at afdække en liste over problemer, der krævede rent, grundlæggende arbejde. Der fandtes for eksempel endnu ingen filvælgerkomponent på tværs af platforme, så vi lavede en ordentlig komponent, og AI-instruktionerne blev opdateret til at bruge den. Ellers pakkede AI ofte platformspecifikke filvælgere ind bag betinget kompilering og gentog det flere gange uden genbrug. Vi måtte i starten bruge tid på at bygge de nødvendige byggesten med højere kompleksitet, før vi prøvede at sætte farten op.
Arbejdet blev derefter taget op af andre, som gik i gang med at høste gevinsterne ved at migrere de nyligt frigjorte komponenter med lavere kompleksitet og validere dem i store batches. Det er vigtigt: selv om De i teorien har hundrede UI-komponenter, der kan migreres, er arbejdet først gjort, når de oprindelige kildefiler er fjernet. Ellers kan De aldrig være sikker på Deres reelle fremdrift.
Hvis De ser nøje på de andre platforme, lægger De måske mærke til en enorm stigning i procent mellem milepælene på 50 % og 100 % for RDM Windows, specifikt for RDM Linux, som gik fra 12,7 % til 94,3 %. Mange af de komponenter, der blev migreret fra WinForms i RDM Windows, kunne nu genbruges, som de var, i RDM Linux. Det alene var ikke tilstrækkeligt, for ellers havde vi set RDM Linux nå 50 % (eller mere) tidligere. Skiftet skete, da udviklerne af RDM Linux begyndte aggressivt at høste gevinsterne ved at erstatte hundredvis af de oprindelige Linux-komponenter med de nye Avalonia-komponenter og validere dem i store batches.
Hvordan softwareudvikling ændrede sig
At lave ændringer, De ikke er tryg ved
Med mine tidlige forsøg på at migrere WinForms til Avalonia med AI forstod jeg ikke reelt, hvad jeg gjorde. Jeg er ikke UI-udvikler, har aldrig været det og bliver det sandsynligvis aldrig (uden AI). Det kan virke kontraintuitivt, men der er stor værdi i at lave ændringer, De ikke er tryg ved. I Avalonia-migreringen var hensigten at finpudse AI-instruktioner nok til at automatisere det meste af slidarbejdet og overlade manuel gennemgang og rettelser efter migreringen til udvikleren.
I 2025 købte Devolutions PowerShell Universal, og skaberen af produktet, Adam Driscoll, kom med på mit team. Kort efter ansatte vi endnu en udvikler til at arbejde på produktet, så det oprindelige team på én person reelt blev fordoblet. PowerShell Universal (PSU) er et ASP.NET-program skrevet i C#, der sætter en IT-administrator i stand til at gøre scripts til fuldt funktionelle webprogrammer for slutbrugere. Det kan også afvikle scripts på en fjernmaskine ved hjælp af en agent.
Devolutions havde allerede en agent med mere avancerede funktioner, herunder fjernafvikling, så det varede ikke længe, før vi planlagde at erstatte den oprindelige PSU-agent, skrevet i C#, med den eksisterende Devolutions Agent, skrevet i Rust. Udfordringen var, at PSU-udviklerne ikke kunne Rust, og at udviklerne af Devolutions Agent ikke kendte PSU. I teorien var det en enkel integration. I praksis så jeg ingen reel fremdrift, kun mockups og demoer, ikke pull requests, der bragte os tættere på noget, vi kunne levere.
Jeg bad C#-udviklerne om at gøre noget, de ikke var trygge ved: bare vibe-code det, De har brug for, i Rust-koden, så godt De kan, med viden om, hvordan De vil have det gjort, så det kan bruges i PowerShell Universal. Intentionen betyder noget: vi vidste, at ændringerne ville svare til det, de ønskede, selv om vi sandsynligvis ville ændre formen gennem flere justeringer. Udgangspunktet var et funktionelt build af Devolutions Agent, som vi vidste med sikkerhed svarede til det, der var ønsket til PowerShell Universal. Ikke en mockup og ikke en designspecifikation!
Jeg hjalp med at gennemgå måden, det blev gjort på, og der var meget frem og tilbage mellem C#- og Rust-udviklerne, indtil vi fastlagde formen for, hvordan Devolutions Agent skulle oprette forbindelse til PowerShell Universal og konfigureres som vært for fjernafvikling af PowerShell-scripts. Det er et af de øjeblikke, jeg er mest stolt af: at accelerere udviklingen ved at lade udviklere ændre kode, de ikke forstod, fordi de forstod intentionen bedre end dem, der skulle gennemgå den senere.
Hvorfor virker det? Fordi udviklere, som i mange integrationer, ofte kun kender deres egen del godt, men ikke har dyb viden om det, de integrerer med. Den tilgang gør det lettere for begge sider at iterere på den rigtige kode, indtil der er enighed. Det er ligegyldigt, hvor god Deres mockup er. Den rigtige kode er altid bedre.
At lukke den agentiske feedback-loop
AI ændrer meget, men nogle grundregler består. AI er kun så god som de værktøjer, den kan arbejde med. Hvis Deres AI ikke har øjne, ser den ikke ødelagte visuelle layouts. Den gætter kun på, at den gjorde det rigtige. Hvis Deres AI ikke kan bruge en debugger, instrumenterer den koden med logning for at finde ud af, hvilke kodestier der bliver kørt. I mange tilfælde er den manglende effektivitet ikke vigtig, så længe den til sidst finder ud af det selv, eller et menneske er med i loopet for at validere.
Hvis De skal huske én lære fra i år, er det, at De bør investere i at lukke den agentiske feedback-loop for AI, så De høster de største gevinster. Feedback-loopet var ikke helt lukket i Avalonia-migreringen af RDM, men det blev opvejet af, at udviklerne validerede og itererede hurtigt på ændringerne.
Tidligere i år købte vi open source-projektet UniGetUI. UniGetUI er en brugergrænseflade oven på flere pakkehåndteringsværktøjer som WinGet, Chocolatey, PowerShell, npm, pip og så videre. Projektet var oprindeligt kun til Windows, skrevet i C# med WinUI. Det er nu fuldt ud på tværs af platforme med Avalonia, og De kan bruge det med Homebrew på macOS eller med distributionsspecifikke pakkehåndteringsværktøjer på Linux. Migreringen krævede flere forsøg, før den første succes, og blev gjort helt anderledes end den for RDM.
Jeg forhandlede selv aftalen om at købe UniGetUI på plads. Den overdrog vedligeholdelse og ejerskab af projektet til Devolutions, uden at den oprindelige forfatter var involveret. Jeg stod for alt det indledende arbejde i overgangen, indtil vi satte en fuldtidsudvikler på projektet. Jeg gjorde to forsøg på at migrere UniGetUI automatisk til Avalonia, og begge mislykkedes, fordi LLM’erne ikke kunne regne ud, hvordan Avalonia-API’erne skulle kaldes korrekt, og fordi jeg ikke havde det rigtige værktøj til at lukke feedback-loopet med AI-agenten ved at give den øjne på resultatet.
Til det tredje forsøg konfigurerede jeg Avalonia Build MCP, som lod LLM’en hente API-dokumentationen effektivt, og jeg instrumenterede programmet, så det kunne bruges med Avalonia DevTools MCP. Nu havde jeg korrekt brug af Avalonia-API’erne, men endnu vigtigere kunne LLM’en nu starte Avalonia-programmet, interagere med det og inspicere det visuelle resultat på en måde, der tæt ligner Playwright MCP-serveren til webprogrammer. Jeg lod den køre i over 24 timer for sig selv og bad i praksis bare GitHub Copilot om at blive ved. Til sidst havde jeg en første funktionel og brugbar version af UniGetUI i Avalonia, der lignede den oprindelige i WinUI tæt nok.
Det var det, jeg overlod til den nye udvikler, vi havde sat til at arbejde fuldtid med UniGetUI. Med et par uger mere med justeringer og rettelser fra en person, der kunne arbejde med Avalonia bedre end jeg, nåede vi endelig noget, der var anstændigt. Fordi brugere er særligt følsomme over for et skift af UI-framework, gik der omkring to måneder, før vi kunne slette den oprindelige WinUI-version og holde os udelukkende til den nye Avalonia-frontend.
At nedbringe teknisk gæld
Devolutions Server er et ASP.NET-program, der bruger SQL Server uden en ORM. Sådan har det været fra starten, og fordi der er meget ældre kode, kan vi ikke bare „lige“ tilføje understøttelse af en anden database som PostgreSQL. For at gøre det værre er den ene person i virksomheden, der kender denne vanskelige del af programmet, på vej på pension. Han er vores tidligere CTO. Da Fable 5 blev udgivet den 9. juni, så jeg det perfekte tidspunkt til at prøve PostgreSQL-migreringen, for snart ville den svært tilgængelige viden om den tekniske gæld ikke længere være der.
Jeg lavede omhyggeligt en plan i GitHub Copilot med Fable 5 og startede derefter agenten. Det lykkedes mig at få den op på et minimalt funktionelt niveau inden for de første 24 timer. Derefter lavede jeg en udtømmende gap-analyse for at finde huller, der skulle lukkes, genererede en ny plan med mere testdækning og mere end-to-end-test. Jeg fik GitHub Copilot til at bruge sit browser-canvas til at indlæse webprogrammet, logge på med en testbruger, klikke rundt og validere, at det virkelig virkede. Jeg lod det endda køre tests, hvor det skulle vente på, at planlagte opgaver kørte. Om aftenen den 12. juni, da et amerikansk direktiv om eksportkontrol tvang Anthropic til at trække Fable 5 tilbage for alle, kun tre dage efter udgivelsen, havde jeg gennemført størstedelen af arbejdet.
Selv om jeg ikke havde en dyb forståelse af databaser og den del af programmet, havde jeg på det tidspunkt finpudset min evne til at lave store og komplekse migreringer med AI. Jeg brugte detaljeret og udtømmende gap-analyse til at finde ud af, hvad der skulle gøres, hvad der skulle rettes, og hvad der ikke opførte sig som originalen. Jeg genererede planer for at tilføje enhedstest og også integrationstest og kombinerede det med end-to-end-test, hvor AI-agenten interagerede med programmet. Det, jeg lavede, var nyttigt, og det var i et vist omfang påvist, at det virkede, men det var endnu ikke gennemgået i dybden.
Og her bliver det interessant: jeg har aldrig haft det sjovere med vores tidligere CTO end i det seneste år. Han var meget imponeret over fremdriften og gik i gang med at rette det, han kunne finde, med Claude Code. Jeg overlod min branch til ham, da jeg havde bragt den så langt, jeg kunne, og han tog den derfra med et perspektiv, jeg ikke havde. Det tog nogle uger reelt at finde alle de subtile problemer, der var tilbage, men vi var et rigtig godt team og fik det gjort.
Min anbefaling, når teknisk gæld skal nedbringes i højrisikoområder af koden, er ikke at spare på tokens. Brug de største modeller, og start mange fokuserede gennemgange for at afdække de forskellige slags problemer, De er bange for kan opstå. Det er meget let at få ting til at virke, men det kræver meget mere tid og mange flere kræfter at få dem rigtige.
Hvordan kodegennemgange har ændret sig
Gennemgår mennesker hver eneste linje kode? Nej, for det skalerer ikke. Ingen kan gennemgå en konstant strøm af massive pull requests og samtidig være fokuseret nok til at fange alle problemer. Den gode nyhed er, at en AI-agent aldrig bliver træt af at fange problemer. Kodegennemgange hos Devolutions handlede ofte om at forklare ændringerne for en kollega, som så stillede spørgsmål tilbage. Med AI kan De lave en første lokal gennemgang af Deres ændringer og derefter lade en anden AI-agent lave en anden gennemgang, når De åbner pull requesten.
Her er en sjov historie om kodegennemgang med GitHub Copilot: vi havde engang en person, der „brokkede sig“ over, at den blev ved med at finde problemer i vedkommendes pull requests, og fordi det var reelle problemer, kunne vedkommende ikke argumentere imod dem. Hvis alle de problemer findes i koden, hvorfor kan den så ikke rapportere 50 af dem på én gang i stedet for 10 ad gangen? Den egentlige irritation var at skulle køre i loop, indtil AI-kodegennemgangen holdt op med at finde reelle problemer, der skulle rettes.
For ændringer med en potentielt stor skadesradius har vi normalt en person, der ser nøjere på ændringerne. I stedet for at gå linje for linje i GitHubs webgrænseflade fandt vi det meget mere effektivt blot at tjekke branchen ud lokalt og stille AI de spørgsmål, De normalt ville have stillet forfatteren af pull requesten. De kan tømme alle Deres bekymringer ud og vente på, at AI validerer, om ændringerne matcher Deres forventninger. Det er også lettere at bede AI forklare, hvordan ændringerne blev lavet, hvilke dele af programmet de påvirker, og hvordan. Derefter kan De bare bede AI indsende fundene som inline-kommentarer på pull requesten.
For at undgå at „stemple“ pull requests igennem har vi i øjeblikket et pilotprojekt, hvor AI automatisk godkender pull requests, hvis ændringerne matcher bestemte kriterier. Der er ingen grund til at vente på, at et menneske trykker på en knap, hvis skadesradiusen ikke er kritisk.
At skalere AI på tværs af Devolutions
Eksplosionen af AI-værktøjer
I januar 2026 havde vi et internt team af AI-ambassadører, hvis rolle var at fremme brugen af AI ved at dele deres egne erfaringer med kollegerne. AI-instruktioner blev vedligeholdt af nogle få udviklere i monorepoet. Budskabet til alle var, at de skulle opdatere AI-instruktionerne, så AI blev bedre til at forstå koden, i stedet for at modstå AI og brokke sig over, at den lavede for mange fejl. Internt brugte de fleste udviklere Claude Code, og mindre grupper brugte GitHub Copilot, Cursor eller Codex. Vi havde to AI-udvalg: en styregruppe med den øverste ledelse, som drøftede AI-initiativer på højere niveau eller grundlæggende AI-projekter, og et udvalg for AI-kompetencecenteret med AI-ambassadørerne, mere praktisk og operationelt.
Fristelsen er der til at prøve at standardisere, hvilke AI-værktøjer vi tilbyder, men vi står imod. Udviklere har deres egne præferencer, og vi vil ikke tvinge dem til at bruge et værktøj, de ikke kan lide. Jeg har personligt aldrig brudt mig om Claude Code og gik fuldt ind på GitHub Copilot. Jeg kan ikke argumentere imod en, der føler sig produktiv i et værktøj, jeg ikke selv ville bruge, selv om jeg ikke kan forklare det rationelt. Min teori er, at produktivitetsgevinsten ved AI-værktøjer er så stor, at sammenligningen sker med værktøjer fra før AI, ikke mellem AI-værktøjer. I det øjeblik nogen har succes med ét AI-værktøj, der passer til vedkommendes mentale model og arbejdsflow, vil vedkommende holde fast i det. Jeg brugte VS Code meget før AI, så jeg gik naturligt med GitHub Copilot først. Mange udviklere foretrækker at bruge Claude Code i en terminal ved siden af deres primære IDE (Visual Studio eller JetBrains) og ser VS Code som endnu en IDE ved siden af den, de allerede har.
Vi oplevede den første AI-„nedetid“, da vi ramte en månedlig grænse på 5.000 USD, hvilket krævede, at vi opgraderede vores konto hos Anthropic for at kunne fortsætte. Vi havde nogle dage, hvor nogle brugere af Claude Code midlertidigt skiftede til GitHub Copilot, mens problemet med grænsen på vores konto blev løst. Tallene så store ud dengang for hele virksomheden. Nu er de bare det, en enkelt superbruger nemt kan bruge. GitHub Copilot bruger stadig premium request-modellen, som gjorde den utroligt billig, hvis De vidste, hvordan den skulle bruges effektivt. Cursor er dyrere, men vi begyndte at tilbyde den til vores webudviklere og til marketingafdelingen på grund af de avancerede indbyggede agentiske browserfunktioner.
En bivirkning af eksplosionen af nye AI-værktøjer er, at vores proces for leverandørstyring hurtigt blev en flaskehals. Med et nyt AI-værktøj, der ser interessant ud, næsten hver dag, og et klart budskab fra CEO’en om, at vi satser fuldt ud på AI, voksede antallet af anmodninger om at få godkendt nye produkter fra forskellige leverandører ud over det, vores juridiske afdeling og sikkerhedsafdeling kunne nå inden for rimelig tid. Selv om det lykkedes at komme igennem hele processen og få værktøjet godkendt, hvad så med nye funktioner, der sandsynligvis også bør godkendes igen, som funktioner til cloud-sandboxing? Hvad med nye AI-modeller, der udkommer, men leveres af en ny inference-udbyder, som ikke blev brugt, da den oprindelige godkendelse blev lavet? Vi har strømlinet processen, men det er stadig et problem i dag.
De store krige om AI-markdown
Kan De huske, da agent skills og AGENTS.md endnu ikke fandtes, og hvert værktøj brugte en forskellig konvention for Markdown-filer? Jeg kalder det gerne „de store krige om AI-markdown“: forskellige filnavne, stier, formater og så videre. Medmindre De standardiserede på ét enkelt AI-værktøj, ramte De uundgåeligt inkompatibiliteterne. GitHub Copilot brugte .github/copilot-instructions.md, Claude Code brugte CLAUDE.md med mulig indlejring. Genbrugelige „slash-kommandoer“ og stispecifikke instruktioner. Alle kunne kun læses af deres egne værktøjer, indtil Claude skills blev til agent skills, som de fleste værktøjer tog til sig og læste fra de samme stier. Alle undtagen Claude. AGENTS.md blev den nye norm, som Claude igen ikke læste, og som krævede CLAUDE.md i stedet.
Vi skrev oprindeligt scripts til at synkronisere og tilpasse agent skills og Markdown-filer, så de var kompatible i vores monorepo, med et CI-job, der kørte det, hver gang en af filerne blev ændret, men det gjorde det svært at iterere på at opdatere instruktioner lokalt. Vi skiftede til sidst til git-symlinks, som er et virkeligt besvær på Windows, fordi symlinks kræver særlig konfiguration for at blive aktiveret ordentligt. Vi begyndte at flytte instruktioner ud af de primære AGENTS.md/CLAUDE.md og ind i mindre Markdown-filer, med genbrugelige arbejdsflows trukket ud i deres egne agent skills. Kan De huske den massive Markdown-fil på 5.000 linjer til Avalonia-migreringer? Den blev delt op i mange mindre agent skills, og platformspecifikke konventioner blev trukket ud i deres egne Markdown-filer.
Nye skills bliver ved med at blive føjet til Devolutions’ primære monorepo: mere end 25 alene er til specifikke opgaver relateret til Avalonia. Der blev tilføjet agent skills til at redigere oversættelsesfiler. Den oprindelige version af de skills fik naivt LLM’en til at læse meget store .resx-filer, bare for at ændre en linje. Senere blev de skrevet om og optimeret til at bruge et hjælpescript, så prisen for en redigering faldt fra 1 USD til nogle få cent, fordi LLM’en ikke behøvede at læse hele filen, kun den linje, den ville redigere.
Hackathonet om agent skills til AI
Størstedelen af agent skills blev dog stadig skrevet af en håndfuld personer i virksomheden, et tilbagevendende emne i vores AI-udvalg. Løsningen blev at arrangere et virksomhedsdækkende hackathon om „AI agent skills“ for udviklere i marts. Vi havde holdt mange hackathons før, men interessen var dalet de seneste år, og færre deltog. Det var tid til noget nyt, med et andet format, der kunne bryde den „hackathon-træthed“, der havde indfundet sig.
Jeg tog mig tid til at sætte et dedikeret repository til agent skills i gang, som udviklerne blot kunne klone og åbne i det værktøj, de selv valgte, med en README.md og nogle eksisterende agent skills til at komme i gang. Jeg lavede en god AGENTS.md med autoritative referencer til brug ved skrivning af agent skills og med instruktioner om at bruge PowerShell-scripts på tværs af platforme sammen med SKILL.md til hjælpescripts. IT havde udrullet PowerShell 7 på forhånd på alle maskiner, så brugere af macOS, Linux og Windows kunne bruge de agent skills uden videre.
I ugerne før hackathonet kom vi med flere meldinger for at opmuntre deltagerne til at tænke over, hvad de gerne ville lave, og skrive deres navn og projektidé i forvejen i et Slack-canvas, som alle kunne se. Vi skød selve dagen i gang med et kort konferenceopkald, hvor jeg præsenterede det git-repository, der skulle bruges, viste nogle eksempler på agent skills, hvordan man kom i gang, og hvor de mere detaljerede instruktioner fandtes. Målet var enkelt: klon dette repository, skriv en agent skill til hvad som helst, De vil, og indsend en pull request, når De er færdig. De skal ikke bekymre Dem om at lave den bedste agent skill eller den mest komplekse. De skal fokusere på at gøre mindst én færdig. Ved hackathonets afslutning skulle alle føle sig trygge ved at skrive deres egne agent skills. Ikke flere undskyldninger. Agent skills, der skulle ligge i et bestemt projekt for at virke, kunne udvikles i et andet repository, så længe der blev lagt en kopi i det dedikerede hackathon-repository, så pull requesten kunne indsendes.
Tilgangen med ét enkelt git-repository til hackathonet hjalp virkelig med at få det til at føles, som om alle arbejdede på det samme i fællesskab, i stedet for at hver sad i sit eget projekt. Der var meget aktivitet i hackathonets Slack-kanal, hvor deltagerne delte links til deres egne pull requests eller stillede spørgsmål. Det var langt det mest vellykkede hackathon, vi har haft i årevis, og da det var slut, havde vi fået 60 agent skills ind.
At udbrede AI ud over udviklerne
Succesen med „udvikler“-hackathonet var så stor, at den førte til et „no-code“-hackathon i maj. Vi tilpassede formatet lidt, især værktøjet, som blev skiftet til ChatGPT eller Claude, og vi tog imod custom GPT’er og andre typer brugerdefinerede instruktioner til AI-agenter, der virker bedst i chatbots. Mødelokaler var reserveret dagen igennem, og arrangørerne stillede sig til rådighed for at hjælpe. Mange ikke-udviklere satte virkelig pris på, at en ekspert tog sig tid til at hjælpe dem med at opnå ting, de ikke engang vidste, de kunne.
Vi må ikke glemme, at selv i en softwarevirksomhed hviler en stor del af forretningen på ikke-udviklere, og de skal også være med i AI-omstillingen. Som udviklere er kløften mellem AI-værktøj til udviklere og til ikke-udviklere mere tydelig for os, end den er for ikke-udviklere, når de ser på vores værktøjer. Med prompten som den nye brugergrænseflade: kan vi sætte udviklerværktøj op, så vores produktmarketingteam kan bruge det? Svaret er, viser det sig, ja!
Til kontekst: mange interne anmodninger til vores produktmarketingteam handler om at opdatere eller ændre webstedet, og ændringerne bliver lavet af webmarketingteamet. Vi havde allerede taget Cursor i brug hos webudviklerne på grund af den indbyggede browser, der føles som Chromes „Inspect element“, men uendeligt meget stærkere. Jeg satte et nyt git-repository i gang, magen til det fra hackathonet, og skrev et sæt agent skills, der gjorde det let at hente og spejle et hvilket som helst websted, så Cursor kunne redigere statiske websteder og lave mockups. Ikke mere Figma med en masse frem og tilbage: De kunne bare redigere det rigtige websted ved at prompte, og jeg tilføjede endda en agent skill, der eksporterede det lokalt ændrede statiske websted til én enkelt .htm-fil.
Det gav meget hurtigere iterationer med en kopi af det rigtige websted, De kunne interagere med. Det føles helt anderledes end skærmbilleder, eller endda interaktive mockups, der simulerer webstedet, men ikke reelt bygger på det. Det reducerede antallet af overdragelser og langstrakte processer for at ændre webstedet markant. Bedst af alt kunne udvikleren nu føre det eksporterede, ændrede statiske websted ind i Cursor og få ændringerne lavet ordentligt i den kildekode, webstedet bygges fra.
I dag er det team et af vores mest avancerede, når det gælder indførelse af AI, og det kan udløse redigeringer af webstedet ved at tagge Cursor-botten i en Slack-samtale. Webstedet bliver ændret, bygget og midlertidigt udrullet med et link, De bare kan åbne for at se, om ændringerne er gode. Hvis de godkendes, bliver de flettet og udrullet automatisk. Det ville selvfølgelig være meget sværere for skrivebords- og mobilprogrammer som Remote Desktop Manager, men hvis det, De udvikler, bruger en webstak, har De den fordel, at loopet er meget lettere at lukke i sandkassemiljøer i cloud.
Den nye økonomi i at bygge software
Ansættelse uden at øge antallet af medarbejdere
Vi havde ingen masseafskedigelser på grund af AI hos Devolutions. I stedet tilbød vi frivillige fratrædelsespakker. I efteråret 2025 var det kun nogle få medarbejdere, der valgte at tage imod. Vi ville ikke have, at medarbejdere skulle føle sig fanget i et „Devolutions 2.0“, der måske ikke længere passede til dem. I 2026 tilbød vi generøse pakker til førtidspension, og de fleste berettigede medarbejdere tog imod. Selv om året ikke er slut endnu, er vi på vej til et balanceret antal fratrædelser og nyansættelser, så det samlede antal medarbejdere forbliver det samme. Vi er ikke holdt op med at ansætte, men vi er holdt op med at genbesætte. AI har været en vigtig faktor i at omfordele arbejdsstyrken: hver nyansættelse understøtter det nye Devolutions, og hver fratrædelse fjerner os yderligere fra det gamle Devolutions.
Nye AI-projekter i massevis
Alene i 2026 har jeg skabt et stort antal nye, større projekter fra bunden, alle med GitHub Copilot-appen. Min bærbare computer er nu vågen hele tiden og kører agenter det meste af tiden. Når jeg kommer hjem, sætter jeg den til strøm og starter mine sessioner igen. Før jeg sover, sørger jeg for, at mine sessioner ikke står stille, og sender dem af sted på job natten over. Når jeg vågner om morgenen, sætter jeg dem ofte bare i gang igen, og når jeg tager af sted mod kontoret, har de allerede rykket sig. Jeg er sikker på, at andre CTO’er oplever det samme: tid er en valuta, når AI-agenter kører længe. Al den tid, hvor De ikke sidder foran computeren, kan pludselig blive produktiv.
Jeg er stadig ikke helt sikker på, hvor sundt det er på lang sigt, men det er den nye virkelighed, jeg prøver at vænne mig til. Jeg har altid haft langt flere ambitiøse idéer, end jeg har haft tid og ressourcer til at føre ud i livet, så det er meget spændende og udmattende på én gang. Tidligere var jeg begrænset af, at jeg ikke kunne tage kritiske ressourcer fra for at bygge et sideprojekt på et indskud. Nu handler det om, hvor meget tid jeg kan bruge på at forberede en plan og starte en agent. Læg dertil et ubegrænset tokenbudget, og jeg har bygget mere software de seneste måneder end i hele mit liv.
Her er en kort liste over eksperimenter, der virkede godt nok til, at jeg ryddede op i dem, så de kunne udgives ordentligt, og de bruges alle i produktion, enten som værktøjer eller som komponenter i et af vores produkter:
- Pinget: C#- og Rust-porte af winget-cli (C++), gjort på tværs af platforme. Tilgængelig som en NuGet-pakke til brug i UniGetUI.
- psign: kodesigneringsværktøj på tværs af platforme skrevet i Rust, der understøtter alle Authenticode-filformater, med understøttelse af Azure Key Vault og Azure Artifact Signing.
- windbg-tool: kommandolinjeværktøj i Rust, der bruger WinDBG-motoren, designet specifikt til at lade AI-agenter inspicere procesdumps, som jeg har brugt til at undersøge BSOD’er på min bærbare computer.
Alle disse massive projekter blev færdige på nogle uger, til en brøkdel af det, det ville have kostet tidligere. Historisk kunne jeg kun vælge nogle få af de idéer og planlægge arbejdet over flere måneder eller år, så andre kunne udføre det. Jeg tror, det er derfor, mange ledere på C-niveau nyder AI så meget: hvis De er vant til at finde ud af, hvad De vil have andre til at bygge, på en meget specifik måde, der passer til Deres krav, føles det meget naturligt at tale med en AI-agent.
Jeg brænder nu mindst 15.000 USD af om måneden i GitHub Copilot. Det kan virke af meget, men det er stadig ingenting i forhold til at uddelegere den slags arbejde til et team af fuldtidsudviklere. Det er ikke kun billigere. De kan som regel også vurdere gennemførligheden inden for de første 24 timer og afbryde eksperimenter, der er dømt til at mislykkes, tidligt. Tidligere var ressourcerne bundet meget længere, før man ramte en uforudset stopklods.
At bygge software til AI, ikke kun med AI
AI kan skrive en masse kode hurtigt, men den bør først regnes for god, når det er bekræftet, at den kører korrekt mindst én gang. Tests er den enkleste måde at afvikle kode på for at sikre, at den matcher den forventede adfærd, men ikke alt er let at teste. Mange dele af et program kan være svære at automatisere eller kræve et bestemt kørende miljø. Den gode nyhed er, at AI nu kan hjælpe Dem med at opnå et højt niveau af testbarhed meget lettere end før.
Ud over tests bør De investere i at bygge værktøjer, der er designet specifikt til en AI-agent. Tilbage i mine FreeRDP-dage kan jeg stadig huske de lange timer, jeg brugte på at lave en ændring, bygge, køre en kommando for at oprette forbindelse til en Windows-VM, klikke og skrive noget for at udløse en bestemt RDP-funktion, jeg arbejdede på, og se, om den virkede. Og så forfra, i det uendelige.
Spol frem til i dag med IronRDP, den åndelige efterfølger til FreeRDP, skrevet i Rust i stedet for C. Det er en indsats over flere år, som jeg begyndte hos Devolutions længe før AI, og jeg vidste udmærket, hvor gigantisk den var. Projektet er meget aktivt, med mange interne og eksterne bidragydere. Ud fra det, AI kunne, satte jeg mig for at bygge en agentisk RDP-klient med ét mål: at min AI-agent skulle gøre den kedelige, gentagelige del, jeg plejede at gøre manuelt.
Strategien er enkel: ironrdp-agent starter en daemon-proces til fjernskrivebordsforbindelsen, som kan styres med gentagne IPC-kald fra kommandolinjen. AI-agenten kan derefter tage skærmbilleder, interagere med skrivebordet ved at klikke og skrive, bruge udklipsholderen, køre scripts, kopiere filer og så videre. Det betyder, at jeg kan lade min AI-agent bruge timer på slidarbejdet med at teste funktioner udtømmende, funktioner der før krævede et menneske, alt imens jeg sover.
Hvem vil ikke gerne vågne op til en lang liste over „manuelle“ testtilfælde, der om morgenen er bekræftet til at virke? Sådan tilføjede jeg omdirigering af filsystemet for Windows i IronRDP. Den kopierede komplekse strukturer af filer og mapper og tjekkede filhash før og efter. Den kopierede endda en ISO-fil på 8 GB for at bekræfte, at den kunne overføre filer på over 4 GB uden at ødelægge dem.
Den nye økonomiske virkelighed med AI betyder, at der er et meget højt afkast ved at bygge værktøjer, der er beregnet specifikt til AI-agenter. Ikke nok med det. Det er også billigere end før at udvikle de værktøjer, så De ikke behøver at vælge og vrage. Med traditionel udvikling oversteg prisen for at bygge komplekse udviklingsværktøjer ofte produktivitetsgevinsterne.
Det, der kommer nu
At lukke feedback-loopet for Windows-skrivebordsprogrammer
Avalonia-migreringen af RDM Windows udnyttede ikke et fuldt feedback-loop med AI-agenten, men det blev opvejet af udviklere, der itererede hurtigt i valideringsfasen. Avalonia-migreringen af UniGetUI blev for det meste lavet med et lukket feedback-loop med AI-agenten over 24 timer, efterfulgt af et par ugers rettelser fra en udvikler. Den del, jeg ikke har fortalt Dem, er, at den eneste effektive måde at lukke feedback-loopet på et Windows-skrivebordsprogram lige nu er at lade AI-agenten tage kontrollen over computeren.
Hvis De installerer winapp CLI og de tilhørende agent skills til UI-automatisering i GitHub Copilot-appen, kan De lade AI-agenten starte Deres program og interagere med det på samme måde, som den ville med et webprogram, der kører i Playwright. Det eneste problem er, at Windows kun understøtter, at ét program har inputfokus ad gangen, så De kan reelt ikke lave andet, mens AI-agenten styrer computeren. Derfor lod jeg ofte langvarige opgaver med UI-validering køre natten over, når jeg ikke sad foran computeren.
Udfordringen det næste år bliver at lukke feedback-loopet for Windows-skrivebordsprogrammer, så AI-agenter kan starte og teste brugergrænseflader uden at afbryde noget. Et fuldt fjernskrivebordsmiljø kunne virke, men det kræver en masse ekstra værktøj til fjernudrulning og fjernafvikling. Windows Sandbox er stadig RDP under motorhjelmen, men det er desværre begrænset til én forbindelse ad gangen, så samtidige sessioner er ikke mulige.
Med min status som Microsoft MVP kan jeg give Microsoft direkte feedback, og jeg håber at finde en løsning på problemet, muligvis ved at bidrage med en del af den tekniske løsning gennem IronRDP. Det bliver et fokusområde det næste år, fordi det ville frigøre produktivitetsgevinster med AI-agenter for os.
Mine forudsigelser for det næste år
Det seneste år har der været så meget, at det føltes som et årti. Så meget, der for nylig føltes naivt ambitiøst, er de seneste måneder blevet ret let at opnå. Jeg tror ikke, vi er tæt på, at AI når et plateau. Den accelererer bare videre i en svimlende fart. Jeg følte for nylig en dyb uro, da jeg på nogle timer blev færdig med noget, jeg havde fået et estimat på 4 måneders arbejde for, med traditionelle udviklingsmetoder.
Agentiske arbejdsflows uden et menneske i loopet bliver mere almindelige. Langt flere arbejdsflows bliver udløst automatisk frem for manuelt og udfører flere handlinger uden et menneske i loopet. For eksempel ved automatisk at opdatere dokumentation, så den matcher kildekoden til et produkt. Ved automatisk at finde sikkerhedsproblemer og åbne en pull request med et foreløbigt fix. Mennesker bliver ofte i loopet et sted, men færre steder.
AI-forbruget bliver en permanent og betydelig del af en virksomheds budget. For nogle måneder siden var vi på vej mod 1 million USD om året ud fra de månedlige omkostninger, men det er siden vokset til 2 millioner USD om året. Vi har stadig ingen planer om at skære i AI-forbruget. De skal huske, at det er en virksomhed med 250 medarbejdere, så det er omkring 8.000 USD pr. medarbejder. Jeg forventer, at tallet kun bliver ved med at vokse, også når vi beslutter os for at prøve at optimere omkostningerne.
Det, der forblev det samme
I en verden, der ændrer sig så hurtigt, hvilke sandheder består så?
Det betyder stadig noget at finde og konfigurere de rigtige værktøjer til opgaven. Vil De reverse engineere software skrevet i C/C++? Tag Dem tid til at installere Ghidra eller IDA Pro, og konfigurér en MCP-server, så den viser funktionerne for Deres AI-agent. Ellers kører De i praksis en hurtig bil med punkterede dæk. Den kommer ingen vegne, og De spilder en masse tokens på forsøget.
Dyb viden om softwarearkitektur er stadig relevant. De må ikke forveksle det at have nået et mål med at have gjort det på den rigtige måde. AI er fremragende til at gøre det, De beder om, men hvis De kun har en overfladisk forståelse, overlader De mange vigtige beslutninger til det rene held. Dyb forståelse er det, der hjælper Dem med at styre AI i den rigtige retning, så den ikke tager genveje, der kan stride mod Deres tilsigtede krav.
At bygge huset, før fundamentet er støbt, er stadig en dårlig idé. En god del af arbejdet med Avalonia-migreringen gik med at bygge ordentlige komponenter, der kunne genbruges flere steder. Hvis vi havde presset de migreringer igennem, der afhang af dem, ville AI-agenten have skabt en masse meget ens boilerplate-kode og hjælpefunktioner. At støbe et ordentligt fundament under et hus, der allerede står, kan lade sig gøre, men det koster mange tokens og meget tid.
Læringer
Jeg har lært meget det seneste år, men hvis jeg skulle koge det ned til en kort liste, er den her:
- Udførelsen er komprimeret: der er mere værdi i at vide, hvad der skal gøres, end i selv at gøre det
- De bør aktivt nedbringe teknisk gæld for at genvinde en smidighed, der tidligere er gået tabt
- Invester i at bygge værktøjer, der lader AI-agenter lukke feedback-loopet
- Kodegennemgange findes stadig, men udføres nu med AI på flere niveauer
- At lave ændringer i kode, De ikke forstår, kan accelerere udviklingen
Jeg håber, at min erfaring som CTO hos Devolutions i det seneste år med AI har været relevant for Deres virkelighed i praksis, og at De har lært noget af den. Jeg glæder mig til næste år på denne uendelige rutsjebanetur!