AI skriver kode, men kan din infrastruktur følge med?

Vi er midt i en af de underligste inversioner i software-udviklingens historie. I årtier har målet været determinisme; at bygge systemer, der opfører sig ens hver gang. Nu lagrer vi probabilistiske AI-agenter oven på denne grund, og genererer kode i en alarmende skala og hastighed. Og ærligt talt? Det meste af vores infrastruktur var ikke bygget til dette.

Jeg har brugt år på at arbejde med DevOps-værktøj, co-forfatter forskning og hjælpe ingeniørhold med at nå deres højeste præstation. Det, jeg ser nu med AI-dreven udvikling, er mere end bare en evolution. Det afslører hver eneste revne i vores eksisterende arbejdsprocesser.

Problemet er allerede her

En 2025 GitClear-studie fandt, at næsten 7% af commits nu indeholder AI-genereret kode. Deres tidligere analyse af 153 millioner linjer ændret kode afslørede omkostningerne: “kode-churn” – kode, der blev omskrevet eller slettet inden for to uger – fordobledes i 2024 sammenlignet med pre-AI-baselines.

Sikkerhedsimplikationerne er lige så markante. Seneste analyse af 80 kuraterede kodningsopgaver på tværs af mere end 100 store sprogmodeller fandt, at AI-genereret kode introducerer sikkerheds-sårbarheder i 45% af tilfældene. Den reelle virkning? En ud af fem CISO’er rapporterer nu om større incidenter, der direkte er forårsaget af AI-genereret kode.

Hastighedsgevinsterne er reelle, men også stabilitetsomkostningerne.

Forstærkningseffekten

En ting, jeg har lært, er, at AI forstærker alt. Hvis du har gode praksisser, gør AI dem bedre og hurtigere. Hvis dine processer er rod, forstærker AI også rod, også. Dette spejler en mønster, der år efter år viser sig i DORA‘s årlige DevOps-rapporter: Færre variable fører til bedre resultater. Succesfulde hold standardiserer på færre operativsystemer, færre programmeringssprog, færre måder at gøre ting på. De reducerer kompleksitet bevidst.

AI-agenter følger samme mønster. Giv dem en konsistent miljø, hvor Python betyder samme version på hver udviklers maskine, hvor afhængigheder er låst og sporet, og de klarer sig godt. Tving dem til at navigere 17 forskellige konfigurationer, hver med subtile forskelle, og du brænder tokens på at figurere ud environmental quirks i stedet for at løse virkelige problemer.

Determinismeparadokset

Dette skaber en fascinerende spænding. I årtier har datalogi forfulgt determinisme som det ultimative mål. Nu kører vi probabilistiske workloads, AI-modeller, der bogstaveligt talt ikke kan garantere det samme output to gange, på toppen af systemer designet til forudsigelighed.

Mit svar? Hold så meget af stakken deterministisk som muligt. Hvis du kan opretholde 80% af din infrastruktur på et deterministisk niveau, har dine AI-agenter færre variable at håndtere. De bruger ikke kontekstvinduer på “Hvorfor fungerede denne afhængighed ikke?” eller “Lad mig prøve denne build-kommando igen.” De er fokuseret på det virkelige arbejde, du beder dem om at gøre.

Tænk på det: Når en agent prøver at kompilere noget og native bindings fejler, fordi ImageMagick ikke er installeret, er det en token-dyrt afveje. Hvis din miljø allerede inkluderer alt, der er nødvendigt (kompilatorer, biblioteker, den fulde afhængighedstræ ned til libc), fungerer agenten bare. Ingen fejlfinding, ingen prøvning, bare fremgang.

Specifikation og validering er nøgle

Hvad der bliver klart, er, at AI-dreven udvikling tvinger os til at tænke hårdere over to historisk under værdsatte færdigheder: specifikation og validering. Du skal formulere, hvad du faktisk bygger, og du skal have robuste måder at verificere, om du fik det.

Jeg har lagt mærke til noget interessant: Personer med produktledelses- eller produktteknisk baggrund er ofte mere succesfulde med AI-agenter lige nu. De er allerede trænet til at tænke i termer af krav, succeskriterier og kompromiser. De er komfortable med at spørge “Hvorfor gjorde du det valg?” og justere baseret på begrundelsen.

Validering, at vide, om tingene er korrekte, har altid været software-udviklingens sværeste problem. QA er blevet kriminelt under værdsat i årtier, og det er det mest udfordrende: At bestemme, om softwaren løser den virkelige brugerbehov. AI løser ikke dette. Hvis noget, gør det det mere kritisk, fordi du nu validerer probabilistiske output mod deterministiske krav.

Tillid, men verificér (og kontroller)

Der er en holdning, jeg er begyndt at omfavne: Vi burde antage, at kode genereret af AI er fjendtlig, indtil det er bevist anderledes. Ikke fordi AI er ondsindet, men fordi vi simpelthen ikke ved. Vi kan ikke gennemgå hver eneste linje, når agenter genererer tusinder af linjer om dagen.

Dette betyder, at vi skal flytte kontrolpunkter. Hvis vi ikke kan låse alt ved udviklingstid, har vi brug for stærkere kontroller ved køretid. Operatører, SRE’er, platformhold, hvem som helst, der er ansvarlig for produktion, har brug for bedre indsigt i, hvad der kører, fuld afhængighedssporing og klar proveniens for hver artifact.

Dette er, hvor reprodusibilitet bliver essentiel. Når du kan matematisk bevise, at artifactet, du testede lokalt, er identisk med det, der kører i produktion – samme input, samme output, samme afhængighedslukning – kan du begynde at træffe intelligente beslutninger. Måske behøver du ikke at genkøre enhedstests i CI, hvis du allerede har kørt dem lokalt, og intet er ændret. Måske kan du kortlægge testdækning til kodeændringer og springe irrelevante test-suiter over.

Hvad kommer næste

Vi er ved et vendepunkt. Hold, der allerede havde gode praksisser, ser massive produktivitetsgevinster med AI. Hold, der kæmpede, kæmper nu hurtigere.

Infrastrukturen, der driver AI-dreven udvikling, skal bygges til reprodusibilitet fra bunden. Ikke boltet på efterfølgende med scanning-værktøj og revisioner, men bagt ind i, hvordan udviklere arbejder fra dag én. Når din udviklingsmiljø er identisk på Mac og Linux, når hver eneste afhængighed er sporet og låst, når du har fuld proveniens for hver artifact, bliver AI-agenter kraftmultiplikatorer i stedet for kaosgenererende.

Her er mit største råd til hold, der prøver at lykkes i AI-alderen:

• Standardiser brutalt. Færre variable korrelerer med højere præstation. Lås din tech-stack, gennemfør konsistente miljøer på tværs af alle platforme, og eliminér konfigurationsdrift, før AI forstærker det. Hvis Python-versionssammenfald forårsager problemer nu, vil de forårsage 10 gange flere problemer, når AI genererer kode i stor skala.

• Byg validering ind i din arbejdsproces, ikke ved slutningen. Med AI, der genererer kode hurtigere, end mennesker kan gennemgå det, kan du ikke kun stole på manuel kodegennemgang alene. Implementer automatiseret test, der validerer, ikke kun at koden kører, men også at den løser det virkelige krav. Gør din CI/CD-pipeline til din sikkerhedsnet, med stærke porte ved køretid for produktionssendings.

• Investér i reprodusibilitet som infrastruktur. Behandl miljøkonsistens som en førsteklasses infrastruktur-bekymring. Når du kan matematisk bevise, at din lokale miljø, CI-miljø og produktionmiljø er identiske, eliminerer du en hel klasse af “fungerer på min maskine”-problemer. Denne deterministiske grundlag er, hvad der tillader dig at lagre probabilistiske AI-workloads oven på.

Spørgsmålet er ikke, om AI vil skrive det meste af vores kode. Det gør det allerede for mange hold. Spørgsmålet er, om vores infrastruktur kan følge med.