Agentic AI er flyttet ind i engineering. Kode bliver skrevet hurtigere, og der bliver leveret mere. VentureBeat beskriver et skifte i selve kernen af udvikling, hvor agenter løfter eksekvering og øger den samlede kodeproduktion markant. Det genkender vi. I Snilld ser vi teams, der før brugte en uge på et featureflag, nu få tre varianter klar på en eftermiddag. Men produkterne bliver ikke nødvendigvis bedre i samme tempo — og det er pointen.
Hastighed ser godt ud i et sprint-review, men virkeligheden rammer i driften. VentureBeat formulerer det klart: at skrive kode var sjældent den rigtige flaskehals. Det svære er at definere krav rigtigt, integrere i rodede systemlandskaber og holde software kørende under uforudsigelige forhold. Når agenter producerer mere kode, vokser alle de andre problemer. Det skifte ser vi i flere danske organisationer, også i sektorer med tung regulering som finans og velfærdsteknologi.
Writing code var ikke begrænsningen
“Writing code was never the rate limiter.” Sætningen fra VentureBeat lød provokerende, men den holder, når man ser på praksis. Krav glider, API’er ændrer kontrakter, og afhængigheder knækker i fredagsdeploy. Agenten kan bygge, men den forhandler ikke tværgående arkitektur eller løser en konflikt mellem produkt og sikkerhed. I et forløb stod vi med to næsten identiske features, fordi kravene havde været mundtlige og skiftet tre gange. Koden var udmærket. Problemet var, at ingen havde afstemt beslutningen undervejs.
Selv når dygtige udviklere bruger agentværktøj, falder gevinsten, hvis konteksten ikke hænger sammen. Agenter komprimerer eksekveringstid, men ikke tvetydighed, ansvar eller driftskompleksitet. Det er VentureBeats konklusion, og den matcher vores erfaring. En kunde fik en feature ud på tre dage i stedet for tre uger — hvorefter to uger gik med at lukke edge cases, der aldrig stod i kravene.
Fra mere kode til mere værdi
Mere kode er ikke lig med bedre produkter. I AI-euforien bliver det let glemt. Hvis I ikke måler effekten på brugeradfærd, fejl efter deploy og reel forretningsværdi, står I bare med et større repo. Flyt fokus fra “lines of code” og “antal PRs” til mål som adoption, retention i relevante kohorter, change failure rate og escaped defects. VentureBeat advarer netop mod at bruge klassiske udviklingsmål som produktivitetsmål — det råd er værd at følge.
Vi har set, at produktchefer presses til at åbne sluserne: flere features, højere tempo. I én case så vi 3x flere pull requests, mens lead time for review fordobledes, og bug-tætheden i produktion steg ca. 15 procent de første to måneder. Det lugter ikke af værdi. Først da teamet indførte hårde feedback-loops — korte hypoteser, A\/B på små udsnit og en bevidst pause mellem agenter og release — vendte tallene.
Nye flaskehalse i review og kontekst
Når agenten skriver meget kode, lander bunken hos mennesket. Human review bliver den nye flaskehals. VentureBeat peger på, at ingeniører mister dyb kontekst, som normalt opbygges ved selv at skrive koden. Vi ser det samme: review tager længere tid, fordi man skal udlede rationale fra diff’en i stedet for fra sin egen tankeproces. Det øger risikoen for fejl, der glider igennem, fordi en isoleret ændring ser fin ud, men kolliderer med antagelser et andet sted.
Et simpelt greb hjælper: kræv rationale-logs fra agenten sammen med PR’en — hvorfor, hvilke antagelser, hvilke alternativer blev fravalgt. Det komprimerer manglende kontekst for revieweren. Mål også selve reviewet: gennemsnitstid per PR, antal kommentarer til agent- vs. menneskeændringer og andelen af PRs, der kræver rollback. Uden målinger flyder det.
Governance, sikkerhed og pengepungen
Agentkonfigurationer er reelt ny infrastruktur. VentureBeat anbefaler at versionere, reviewe og teste både prompts og “skills” før udrulning. Behandl agent-opsæt som kode med semver, changelogs og staging-miljøer. Vi har set et grimt eksempel, hvor manglende prompt-versionering betød, at to teams i samme koncern byggede det samme API i hver sin variant. Dobbeltarbejde og dobbelt vedligehold — et rent governance-svigt.
Sikkerhedsmæssigt bør agenter ikke arve fulde rettigheder fra deres operatør. Least-privilege er ikke til diskussion: adskil læse- og skriveadgang, og læg menneskelige gates foran destruktive handlinger. VentureBeat er tydelig her, og vi er enige. Oveni kommer økonomistyring: kvoter, rate limits, tagging per bruger og team, budgetalarmer. Der er historier om løbske agent-loops, inklusiv en ubekræftet fortælling om en regning på en halv milliard dollars i én måned. VentureBeat henviser til Axios — tag tallet som anekdote, indtil der foreligger åben dokumentation.
Vibe coding og AI-first udvikling
“Vibe coding” lyder smart, men idéen er reel: udvikleren beskriver ønsket adfærd i naturligt sprog, og en agent bygger. MarktechPost gennemgår værktøjer fra fuldstack agentplatforme til AI-native editors, hvor mennesket arbejder tæt på koden. Det sænker prisen fra idé til prototype og skubber flere iterationer igennem, hurtigere. Ikke magi — en anden arbejdsrytme.
Vi testede det i en Snilld-workshop. Prototypen kom på 40 minutter, men integrationskontrakten mod et eksisterende auth-system manglede, så vi måtte bygge den ordentligt bagefter. Tradeoff’et er klart: jo længere væk fra koden du arbejder, desto mere brug for stærke kontrakter, test og observability. MarktechPost peger netop på forskellen mellem værktøjer, der kører end-to-end, og dem, der holder mennesket tættere på editoren. Valget er strategisk, ikke smagssag.
Nye roller, budgetter og organiseringen
Når agentiske værktøjer flytter ind, ændrer rollerne sig. New York Times beskriver, hvordan Box skabte nye jobtyper som AI-arkitekter og AI solutions managers — og endda forventer at være flere ansatte, ikke færre. Det matcher det, vi ser: virksomheder hyrer folk, der kan designe agentiske flows, etablere governance og koble AI til eksisterende data- og driftssystemer. Ikke alle skærer ned; nogle flytter omkostningerne og bygger nye kompetencer.
Budgetterne følger med. Der opstår en tradeoff mellem at betale for frontier-modeller og at investere i bedre test, logging og dataforvaltning. VentureBeat argumenterer for at betale for kvalitet, fordi dårligere output skaber mere omarbejde. Vi tilføjer: uden klare målinger på driftsstabilitet og produktværdi bliver “dyr model” let en bekvem forklaring på et svagt design. Køb kvalitet — men mål effekten benhårdt.
Drift, observability og incident management
Driftsteams får nye opgaver. Når agenter kan trigge pipelines, skal procedurerne justeres. Ingen fri adgang til produktion. Kør alt gennem staging, og læg menneskelige approval-gates på ændringer, der sletter, migrerer eller rører kritiske ressourcer. Det er klassisk DevOps — nu for ikke-menneskelige aktører, som kan eksekvere parallelt og på skæve tidspunkter.
Observability får en anden vægt. Unit-tests fanger ikke runtime-adfærd, der afhænger af eksterne systemer, skiftende datakvalitet eller en agent, der vælger en “kreativ” vej. Mål fejlrate efter deploy, rollback-frekvens, MTTR og — ja — agent-generated-lines-per-release holdt op mod bug-density. Man kan smile ad målet, men det hjælper med at kalibrere tempo mod kvalitet. Log også agent-metadata: prompt-version, aktiverede værktøjer, model. Uden det kan I ikke genskabe et forløb, når noget går skævt kl. 02.14.
Tre konkrete tiltag I kan starte i morgen
For det første: en governance-checkliste. Versionér alle prompts og skills med semver og changelogs, kræv peer review, kør i staging og rul gradvist ud. Least-privilege for agenter, adskilte læse\/skrive-rettigheder og månedlige cost-reviews med tag-baserede kvoter per team. Kedeligt — men redder jer, når presset stiger.
For det andet: et review-workflow med mål. Hver PR fra agenter skal have rationale-log, inkl. antagelser og tests. Mål tid per review, ændringer per PR og procent, der kræver rollback. Indfør kontekstbevarende artefakter: annoterede PRs, prompt-historik, runbooks og et fælles sprog for “hvorfor”, ikke kun “hvad”. Det lyder basalt, men vi har set det halvere review-tiden på tre uger i et dansk team.
Fra målsætning til virkelighedstest
For det tredje: flyt produktmålinger frem i køen. Sæt hypoteser, kør A\/B i små bidder, og bind features til KPI’er som aktivering, tid til første værdi og churn i udsatte segmenter. Det er dyrere at rulle tilbage på fornemmelser end at teste på rigtige brugere i små doser. VentureBeat anbefaler at måle det, der faktisk betyder noget — det budskab kan ikke blive klarere.
En praktisk detalje, der ofte overses: isolér agentiske eksperimenter i feature-flags med klare udløb. Ellers ender I med permanent beta-adfærd i produktion, der er tung at rydde op i. Vi kørte for nylig en oprydning, hvor fem “midlertidige” agent-forsøg forstyrrede målinger. Ikke ond vilje — bare manglende housekeeping.
Hvad agentic AI ikke løser
Agentic AI fjerner ikke tvetydige krav. Den løser heller ikke ansvar, når to systemer peger fingre ad hinanden. Og når antallet af agenter og kald skalerer, følger skjulte omkostninger: mere observability, flere sikkerhedskontroller, flere regressionstests. VentureBeat er tydelig: agenter komprimerer eksekveringstid, ikke kompleksitet. Det mærkes først rigtigt, når pageren bipper, og loggen er 300 MB tungere end i går.
Der er også huller i dokumentationen. Vi mangler uafhængige metrikker for, hvordan agentisk kode påvirker bug-density eller MTTR på tværs af brede stikprøver. MarktechPosts gennemgang af vibe coding-værktøjer er nyttig, men longitudinelle cases på store legacy-kodebaser er få. Her vil mere neutral forskning hjælpe — især i regulerede miljøer.
Sådan gør vi det i Snilld
Vi anbefaler et kort, skarpt forløb, der binder teknik og produkt sammen: en workshop med produkt, drift og sikkerhed ved samme bord; et governance-roadmap med klare roller og rettigheder; og en lille prototype-integration i jeres rigtige miljø med observability tændt fra dag ét. Vi har gjort det i både finans og velfærdsteknologi. Læringen går igen: det går stærkt — indtil det rammer integrationerne. Byg kontrakterne først.
Vi siger også nej, når det lugter af “bare skru op for agenten”. Nogle problemer kræver domæneforståelse, ikke mere kode. Én kunde ville automatisere en kompleks aftalelogik; reglerne var uklare. Agenten gjorde det hurtigere uklart. Mennesker måtte rydde op. Den slags små, konkrete observationer er der, arbejdet sker i virkeligheden.
Modargumenter og risici
Skeptikere kalder dette overstyring og mener, at pointen med AI var færre mennesker. New York Times’ Box-historie viser, at nogle organisationer hyrer flere. Andre skærer ned. Sandheden ligger midt imellem. Vi ser både omkostningsreduktion og omkostningsforskydning. Data peger i begge retninger, afhængigt af modenhed og disciplin. Og gentagelsen om de store regningstal: Uber skulle ifølge VentureBeat have indført loft på AI-forbrug efter et overforbrug tidligt på året, men detaljerne er ikke offentligt revideret. Brug det som pejlemærker, ikke regnskab.
Et andet modargument handler om innovationstempo: “Hvis vi lægger gates ind, dræber vi farten.” Det har vi ikke set. Når gates er datadrevne og automatiserede, sænker de ikke tempoet mærkbart, men mindsker variansen i kvalitet. Det overraskede os, hvor hurtigt teams vænnede sig til rationale-logs og versionsstyrede prompts. Efter to uger føltes det som en lettelse, ikke en byrde.
Tjekliste til i morgen
Sæt kvoter og rate limits pr. team, slå budgetalarmer til, og tag et 30-minutters cost-review hver uge i en måned. Versionér alle prompts og skills med semver og changelogs, og kræv staging-run før produktion. Gør rationale-logs til obligatorisk bilag på PRs fra agenter, og mål reviewtid samt rollback-frekvens. Til sidst: vælg tre produkt-KPI’er, og bind jeres næste to releases til dem via A\/B-test i små, kontrollerede rollout-rings.
Det er små skridt. Men hastigheden har I allerede fået. Nu skal skinnerne lægges, så toget bliver på sporet.
