Ok, det her bliver et af mine mere nørdede artikler, men man udvikler sig vel med opgaven.
Jeg har de seneste måneder bygget en lille app til Rørvig Sejlklub. En vagtplan og frivillig-koordinering til klubbens sommer-sejlerskole, brugt af omkring 150 frivillige hen over sæsonen. Jeg har bygget den selv. Eller rettere: jeg har bygget den med Lovable, et af de nye AI-udviklingsværktøjer, som vi for nylig er blevet partnere med hos Consid.
Det er en lille app i den store sammenhæng. Men det jeg har lært undervejs, peger på et større spørgsmål som flere og flere virksomheder kommer til at stå i: Når AI kan skrive koden, hvem vurderer så, om den er god?
Vibe coding har et hul i midten
Det er blevet billigt at få AI til at skrive kode. Det er ikke længere noget der kræver ti års erfaring fra et udviklingsteam. En person med en god idé og et kreditkort kan på en weekend bygge noget der virker. Det er en reel demokratisering, og den vil ændre meget.
Men der er et hul i den fortælling. Det er nemt at få AI til at skrive kode der ser rigtig ud. Det er sværere at få AI til at skrive kode der også er rigtig. Forskellen mærker man ikke på dag ét. Man mærker den den dag noget går galt i produktion, og brugerne bliver påvirket.
Det fag der løser den slags hedder arkitektur, og det handler om at forudse. At se hvor systemet knækker når noget uventet sker, hvor sikkerheden er svag, hvor en god beslutning i dag bliver en dyr beslutning om to år. AI kan overtage håndværket. Men ikke overblikket.
To agenter, to perspektiver
Det var præcis det problem jeg sad med. Jeg kunne bygge appen med Lovable, men jeg kunne ikke selv vurdere om de arkitekturvalg den foreslog, var fornuftige på den lange bane. Selvom vi har dygtige arkitekter i huset, gav det ikke mening at trække en af dem ind på et gratis fritidsprojekt.
Det jeg endte med at gøre, var at sætte to AI-agenter op til at vurdere arkitekturen i appen sammen.
Den ene kørte i selve byggemiljøet og kendte koden i detaljer. Den havde adgang til at se hvad der faktisk var implementeret, hvilke valg der lå bag, og hvilke afhængigheder der var i spil.
Den anden kørte uden adgang til koden, men med en struktureret ramme for arkitekturvurdering. Den fulgte playbooks fra et værktøj kaldet EA Workbench, som min kollega Anders Bendtsen står bag. Dens job var at læse arkitektur-beskrivelsen og pege på det der så skævt ud.
Min rolle var at sidde i midten og afgøre hvad der overlevede deres uenigheder.
Hvor de gav forskellige svar
Lad mig give to konkrete eksempler.
Den eksterne agent foreslog at en bestemt funktion i appen blev ændret, fordi den ifølge agenten ville skjule en konkurrence for brugerne hvis der opstod en teknisk fejl. Det lød rimeligt. Men da den interne agent læste koden, viste det sig at funktionen var designet til at gøre det stik modsatte. Hvis der opstod fejl, blev konkurrencen vist, ikke skjult. Det var et bevidst valg, dokumenteret i koden. Den eksterne agent havde simpelthen læst koden forkert og bygget en hel anbefaling oven på en fejlantagelse. Efter at have set kodeuddraget trak den anbefalingen tilbage.
I et andet tilfælde foreslog den eksterne agent en større omkalfatring af datamodellen. Teknisk set en bedre løsning. Men appen var i drift med 150 brugere, og sæsonen var i fuld gang. Den interne agent pegede på at en fejl midt i sæsonen ville påvirke brugerne direkte. Den eksterne agent gav sig, da den så tidsplanen, og foreslog i stedet en faseopdelt løsning hvor det kritiske blev rettet nu, og det strukturelle udskudt til efter sæson.
Begge eksempler peger på det samme. AI-agenter har høj selvtillid og lav fornemmelse for kontekst. Den ene tog fejl af koden. Den anden tog fejl af risikoen. En af dem alene ville have leveret en plan der så fornuftig ud, men som ville have skabt problemer i drift.
Hvorfor det virkede
Det er fristende at konkludere at to AI-agenter er bedre end én. Det er ikke konklusionen.
Det virkede fordi tre ting var på plads. Den ene agent havde adgang til virkeligheden. Den anden agent fulgte en struktureret metode. Og der sad et menneske i midten med vetoret. Det sidste lag bliver i AI-debatten ofte kaldt human in the loop, og det er nemt at sige. Det er sværere at gøre rigtigt. Det kræver at mennesket faktisk har autoritet og kompetence til at sige nej, ikke bare en knap der hedder "godkend". Tag ét af de tre lag væk, og det falder fra hinanden. To AI-agenter uden ramme er bare to selvsikre stemmer der modsiger hinanden. En struktureret metode uden kodeadgang er en velformuleret anbefaling baseret på antagelser. Og uden mennesket i midten er der ingen til at afgøre hvilke uenigheder der betyder noget, og hvilke der er støj.
Det er stilladset omkring AI'en der gør forskellen, ikke modellen.
Det er stilladset omkring AI'en der gør forskellen, ikke modellen.
Hvad det betyder for andre
Mange virksomheder eksperimenterer lige nu med AI-udviklingsværktøjer. Det er en god udvikling. Men der ligger en antagelse under begejstringen, som jeg synes fortjener mere opmærksomhed. Antagelsen er at hvis man kan bygge med AI, så kan man også vurdere det AI bygger.
Det kan man ikke nødvendigvis. At producere kode med AI er ikke det samme som at vurdere om koden er god. Det er to forskellige discipliner. At AI har gjort den ene billig, betyder ikke at den anden er fulgt med.
Løsningen er ikke at lade være, men at bygge stilladset bevidst. For et lille projekt som Rørvig Sejlklub kan det være to AI-agenter med klare roller og et menneske i midten. For en større organisation handler det om at koble AI-udviklingsværktøjer sammen med den arkitekturpraksis man allerede har. Det er præcis det Anders har bygget EA Workbench til.
Det afgørende ved AI lige nu er, hvad organisationerne gør med den — ikke hvad modellerne kan.