AI bygger hurtigere end nogensinde – men kan det også vedligeholde?
Den dag AI byggede en compiler fra bunden
For nylig så jeg en demonstration, der ville have lydt som ren science fiction for bare tre år siden. Et AI-system havde genereret en fungerende compiler, der kunne målrette flere processorarkitekturer. Ikke et legetøj. Ikke en prototype. En ægte, driftsklar compiler der bestod 99% af branchestandard-testsuitene.
Sådan. Så langt er vi altså.
Udviklingen inden for AI-kodegenerering har været vanvittig. Vi gik fra at forudsige det næste ord i en sætning til hele funktioner, komplette filer, og nu — i stigende grad — hele projekter. Med denne eksplosion i capabilities er der opstået en fascinerende bivirkning: fænomenet "vibe forks."
En vibe fork er i bund og grund det, der sker, når nogen bruger vibe coding til at skabe en clean-room implementation af eksisterende software. De kopierer ikke kode. De genskaber funktionalitet fra scratch, fremkaldt af stadig mere kapable AI-systemer. Kildekoden er ikke længere den barriere, den engang var — den var det egentlig aldrig. Viden om hvordan ting virker, er blevet optaget i træningsdata og indkodet i modelvægte.
Carlini Compiler-eksperimentet
Måske det mest slående eksempel kommer fra nyere AI-forskning. Seksten AI-agenter blev sluppet løs på en fælles kodebase for at bygge en C-compiler fra bunden. Efter næsten 2.000 sessioner og $20.000 i API-omkostninger producerede de en 100.000-linjes compiler, der kunne bygge Linux 6.9 på x86, ARM og RISC-V-arkitekturer. Den kompilerer endda DOOM.
Lad det lige synke ind.
Hundrede tusinde linjer produktionskvalitets-compilerkode. Tre forskellige processorarkitekturer. En kerne der faktisk booter. Dette er ikke et weekendhack-projekt — dette er software, der tog forskere år at bygge, reproduceret af autonome agenter over hvad der svarer til et par ugers compute-tid.
Den umiddelbare reaktion er enten eufori eller eksistentiel angst, afhængigt af hvor man sidder. Men jeg tror, virkeligheden er mere nuanceret — og ærligt talt, mere interessant.
Hvorfor jeg ikke mister søvn over vibe forks
Her kommer min kontroversielle holdning: vibe forks er imponerende, men de er ikke den eksistentielle trussel mod software-forvaltere, de umiddelbart kan se ud til at være.
Overvej økonomien i overflod. Når hvem som helst kan prompt'e en C-compiler til at eksistere, ophører artefaktet med at være knapt. Hvad der bliver knapt er dømmekraft — specifikt dømmekraft om hvilken af de mange genererede alternativer der er korrekt, vedligeholdt, sikker, og værd at stole på i produktionssystemer.
Dette mønster har udspillet sig før. Kig på app stores. Kloningsomkostningen der er praktisk talt nul. Barrieren for at komme på markedet er lav. Resultatet? Hundrede habit trackers, tusinde lommelygte-apps, et ocean af næsten identiske produktivitetsværktøjer. Klonerne eksisterer. De ender bare sjældent med at komme hele vejen.
Det der adskiller vinderne fra bunken er ikke features. Det er kuratering, discovery, tillid og omdømme. Den redaktionelle fremhævelse, brugeranmeldelserne, stjernevurderingerne, den brand recognition der tog år at opbygge. Du kan replicere feature-listen fra den ene dag til den anden. Du kan ikke replicere tilliden.
Indesidderens skjulte fordel
Her kommer noget kontraintuitivt: den samme egenskab der gør vibe forking mulig, hjælper faktisk indesiddere mere end den hjælper nykommere.
Bredt udbredt software har været i træningsdata utallige gange. Den er blevet ramt af corner cases og edge conditions, som udviklere brugte år på at opdage og rette. Modellen er god til at vedligeholde denne software præcis fordi verden allerede har gjort det hårde arbejde med at finde, hvad der er i stykker.
En helt ny vibe fork har ingen af denne historik. Den fungerer måske smukt for happy path. Men det mystiske crash der kun sker, når man processerer en fil med Unicode-tegn midt på en tirsdag eftermiddag i november? Det tog nogen tre måneder at spore. Det står ikke i din prompt. Det er institutional knowledge indlejret i den originale kodebase.
Modellerne er genuint bedre til at vedligeholde det, verden allerede har lært at vedligeholde. Det er ikke fair, men det er sandt.
Det menneskelige element der ikke skalerer
Og så er der support. Her halter vibe forks virkelig, og jeg tror det er den mest undervurderede barriere i hele ligningen.
Agentic AI kan absolut håndtere greenfield-projekter. Bygge noget nyt fra scratch? Modellerne er bemærkelsesværdigt kapable. Men rigtig software er ikke greenfield. Rigtig software er brownfield. Den har akkumulerede afhængigheder, legacy-integrationer, weird configurations, og den akkumulerede Technical debt fra år med "det ordner vi senere."
Hvert modent projekt bærer essential complexity — den iboende vanskelighed i det problem, det løser. Men det bærer også accidental complexity, den type der sniger sig ind over tid gennem skiftende krav, personaleudskiftning, og de tusind små beslutninger der virkede fornuftige dengang.
At reducere den accidental complexity? Det er en dybt menneskelig opgave. Det kræver forståelse af kontekst, der måske aldrig er blevet skrevet ned. Det kræver samtaler med brugere om hvad de faktisk har brug for. Det kræver skøn over afvejninger, der kun giver mening givet organisatorisk historie.
AI-agenter kan hjælpe med alt dette. Men de kan ikke gøre det alene, og de kan bestemt ikke gøre det for en fresh fork der ikke har de relationer eller den kontekst.
Den reelle mulighed
Her er hvad jeg tror der egentlig sker med vibe forks: de eliminerer ikke værdien af god software. De demokratiserer evnen til at bygge ny software.
De mennesker der var blokeret fra at skabe, fordi de ikke kunne C eller ikke havde års erfaring med compilerkonstruktion? De er nu ublokerede. De startups der ikke havde råd til at bygge infrastruktur fra bunden? De kan prototypere og validere idéer hurtigere end nogensinde før.
Hvad vibe forks ikke let kan replicere, er den akkumulerede tillid, community og institutional knowledge der gør software værdifuld over tid. Det bygges stadig på den gamle måde: gennem år af at shippe, lytte, fixe og iterere.
Så ja, barrieren for at genskabe software er faldet dramatisk. Men barrieren for at skabe software der betyder noget — den type folk stoler på med deres forretninger og deres levebrød — kræver stadig det menneskelige element. Det vil den altid.
Spørgsmålet er ikke, om AI kan bygge dine drømme. Det kan. Spørgsmålet er, om du kan bygge noget værd at vedligeholde.