AI skriver kode, men kan din infrastruktur holde tritt?

Vi lever gjennom en av de merkelige inversjonene i softwareingeniørhistorien. I årevis har målet vært determinisme; å bygge systemer som oppfører seg likt hver gang. Nå legger vi på probabilistiske AI-agenter på toppen av denne grunnlaget, og genererer kode i en alarmende skala og hastighet. Og ærlig talt? Det meste av vår infrastruktur var ikke bygget for dette.

Jeg har brukt årevis på å arbeide med DevOps-verktøy, samforfattet forskning og hjulpet utviklingsteams å nå deres høyeste ytelse. Det jeg ser nå med AI-drevet utvikling er mer enn bare en evolusjon. Det avdekker hver eneste sprekk i våre eksisterende arbeidsflyter.

Problemet er allerede her

En 2025 GitClear-studie fant ut at nesten 7% av commitene nå inneholder AI-generert kode. Deres tidligere analyse av 153 millioner linjer med endret kode avdekket kostnaden: “kodeomløp” – kode som ble omskrevet eller slettet innen to uker – doblet i 2024 sammenlignet med pre-AI-baselinjer.

Sikkerhetsimplikasjonene er likevel også svært alvorlige. Ny analyse av 80 kurerte kodingsoppgaver over mer enn 100 store språkmodeller fant ut at AI-generert kode introduserer sikkerhetsvulnerabiliteter i 45% av tilfellene. Den virkelige virkningen? En av fem CISOer rapporterer nå om store hendelser direkte forårsaket av AI-generert kode.

Hastighetsgevinster er virkelige, men også stabilitetskostnadene.

Forsterknings-effekten

En ting jeg har lært er at AI forsterker alt. Hvis du har gode praksiser, gjør AI dem bedre og raskere. Hvis dine prosesser er uordentlige, forsterker AI også uordenen. Dette speiler en mønster som dukker opp år etter år i DORA‘s årlige DevOps-rapporter: færre variabler fører til bedre resultater. Suksessfulle team standardiserer på færre operativsystemer, færre programmeringsspråk, færre måter å gjøre ting på. De reduserer kompleksitet med vilje.

AI-agenter følger samme mønster. Gi dem en konsistent miljø der Python betyr samme versjon på hver utviklers maskin, der avhengigheter er låst og sporet, og de lykkes. Tving dem til å navigere 17 forskjellige konfigurasjoner, hver med subtile forskjeller, og du brenner tokens på å finne miljølige feil i stedet for å løse faktiske problemer.

Determinismeparadokset

Dette skaper en fascinerende spenning. I årevis har datavitenskapen forfulgt determinisme som det ultimate målet. Nå kjører vi probabilistiske arbeidsbyrder, AI-modeller som faktisk ikke kan garantere samme utgang hver gang, på toppen av systemer designet for forutsigbarhet.

Mitt svar? Hold så mye av staken deterministisk som mulig. Hvis du kan opprettholde 80% av infrastrukturen på et deterministisk nivå, har dine AI-agenter færre variabler å håndtere. De bruker ikke kontekstvinduer på “Hvorfor installerte ikke denne avhengigheten?” eller “La meg prøve denne byggekommandoen igjen.” De fokuserer på det faktiske arbeidet du ber dem om å gjøre.

Tenk på det: når en agent prøver å kompilere noe og native bindinger feiler fordi ImageMagick ikke er installert, er det en token-ekspensiv omvei. Hvis miljøet allerede inkluderer alt som trengs (kompilatorer, biblioteker, hele avhengighetstreet ned til libc), fungerer agenten bare. Ingen feilsøking, ingen prøving og feil, bare fremgang.

Spesifikasjon og validering er nøkkel

Hva som blir tydelig er at AI-drevet utvikling tvinger oss til å tenke harder om to historisk undervurderte ferdigheter: spesifikasjon og validering. Du må formulere hva du faktisk bygger, og du må ha robuste måter å verifisere at du fikk det.

Jeg har lagt merke til noe interessant: personer med produktledelse eller produktutviklingsbakgrunn er ofte mer suksessfulle med AI-agenter nå. De er allerede trent til å tenke i termer av krav, suksesskriterier og kompromisser. De er komfortable med å spørre “Hvorfor valgte du det?” og justere basert på grunnene.

Validering, å vite om tingene faktisk er korrekte, har alltid vært softwareingeniørernes hardeste problem. QA har vært kriminelt undervurdert i årevis, og det er det mest utfordrende delen: å bestemme om softwaren løser den faktiske brukerbehovet. AI løser ikke dette. Hvis noe, gjør det det enda viktigere, fordi du nå validerer probabilistiske utgangsdata mot deterministiske krav.

Tillit, men verifiser (og kontroll)

Det er en holdning jeg begynner å omfavne: vi bør anta at kode generert av AI er fiendtlig til den er bevist motsatt. Ikke fordi AI er ondsinnet, men fordi vi enkelt ikke vet. Vi kan ikke gjennomgå hver eneste linje når agenter genererer tusenvis av linjer per dag.

Dette betyr å flytte kontrollpunktene. Hvis vi ikke kan kontrollere alt på utviklingstid, trenger vi sterkere kontroller på kjøretid. Operatører, SREer, plattformteam, hvem som helst som er ansvarlig for produksjon, trenger bedre oversikt over hva som kjører, fullstendig avhengighetssporings og tydelig proveniens for hver artifact.

Dette er der hvor reproduserbarhet blir essensiell. Når du kan matematisk bevise at artifacten du testet lokalt er identisk med hva som kjører i produksjon – samme inn-data, samme ut-data, samme avhengighetslukning – kan du begynne å ta intelligente beslutninger. Kanskje du ikke trenger å kjøre enhetstester i CI hvis du allerede har kjørt dem lokalt og ingenting har endret seg. Kanskje du kan kartlegge testdekning til kodeendringer og hoppe over irrelevante test-suiter.

Hva kommer neste

Vi er på et vendepunkt. Team som allerede hadde gode praksiser ser massive produktivitetsgevinster med AI. Team som hadde problemer, har nå problemer raskere.

Infrastrukturen som driver AI-drevet utvikling må bygges for reproduserbarhet fra bunnen av. Ikke boltet på etterpå med skanningsverktøy og auditor, men innbygget i hvordan utviklere arbeider fra dag én. Når utviklingsmiljøet ditt er identisk på Mac og Linux, når hver avhengighet er sporet og låst, når du har fullstendig proveniens for hver artifact, blir AI-agenter kraftmultiplikatorer i stedet for kaosgeneratore.

Her er mitt største råd for team som prøver å lykkes i AI-alderen:

• Standardiser brutalt. Færre variabler korrelerer med høyere ytelse. Lås ned teknologistaken, tving konsistente miljøer på tvers av alle plattformer, og eliminér konfigurasjonsdrift før AI forsterker det. Hvis Python-versjonsuoverensstemmelser forårsaker problemer nå, vil de forårsake 10 ganger flere problemer når AI genererer kode i stor skala.

• Bygg validering inn i arbeidsflyten, ikke bare på slutten. Med AI som genererer kode raskere enn mennesker kan gjennomgå den, kan du ikke bare stole på manuell kodegjennomgang alene. Implementer automatisk testing som validerer ikke bare at koden kjører, men at den løser det faktiske kravet. Gjør CI/CD-pipeline ditt trygghetsnett, med sterke porter på kjøretid for produksjonsutleveringer.

• Investér i reproduserbarhet som infrastruktur. Behandle miljøkonsistens som en førsteklasses infrastruktur-bekymring. Når du kan matematisk bevise at lokal-miljøet, CI-miljøet og produksjonsmiljøet er identiske, eliminerer du en hel klasse av “fungerer på min maskin”-problemer. Dette deterministiske grunnlaget er hva som tillater deg å trygt legge på probabilistiske AI-arbeidsbyrder på toppen.

Spørsmålet er ikke om AI vil skrive mesteparten av koden vår. Det gjør det allerede for mange team. Spørsmålet er om vår infrastruktur kan holde tritt.