Vi befinner oss ved et vendepunkt i programvareutviklingen. Diskusjonen handler ofte om hvilken om AI skriver den beste koden (Claude vs. ChatGPT) eller hvor hvor AI skal bo (IDE eller CLI). Men det er ikke det rette spørsmålet.
Hvis vi omfavner AI som «Vibe Coders» – der vi angir hensikten og AI står for utførelsen – skaper vi en enorm strøm av ny programvare. En sverm av AI-agenter kan generere mer kode på ett minutt enn en seniorutvikler kan gjennomgå på en uke. Mennesket har blitt flaskehalsen.
Løsningen er ikke mer flere mennesker. Løsningen er en AI Design Authority.
Tradisjonelt er en «Design Authority» en gruppe arkitekter som møtes en gang i uken eller måneden for å godkjenne eller avvise et design. I en verden med high-velocity AI-utvikling er den modellen håpløst utdatert. Den er for treig og for reaktiv.
Hvis vi går over til «Disposable Code» – programvare som vi ikke refaktorerer i det uendelige, men kaster og genererer på nytt når kravene endrer seg – endrer rollen vår seg fundamentalt. Vi er ikke lenger murere som legger stein på stein. Vi er arkitektene til fabrikken som skriver ut veggene.
Men hvem sjekker om de veggene står rett?
En AI Design Authority er ikke en person, men en pipeline. En «Gauntlet» som hver linje generert kode må kjempe seg gjennom for å nå produksjonen. Denne prosessen erstatter ikke den menneskelige kodegjennomgangen med ingenting, men med noe bedre.
Den fungerer i tre lag:
1. Den utøvende makt (Genereringen)
Vi ber ikke én AI om en løsning, vi ber tre. Vi lar Gemini 3, GPT-5 og en open source-modell (som Llama) arbeide parallelt med det samme problemet. Dette forhindrer tunnelsyn og bryter «latheten» som LLM-er noen ganger sliter med. Denne tilnærmingen er også vitenskapelig undersøkt og viser at du kan forhindre AI-hallusinasjoner og bygge svært lange kjeder uten feil
2. Det harde filteret (Loven)
Her er det ingen diskusjon mulig. Koden må kompilere. Lintere skal ikke klage. Og avgjørende: de Black Box-tester må bestå. Vi tester ikke om funksjonen fungerer internt (det kan AI-en manipulere), vi tester om systemet på utsiden gjør det det skal. Feiler testen? Rett i søppelbøtta.
3. Det myke filteret (AI-juryen)
Dette er den virkelige innovasjonen. De gjenværende løsningene forelegges en spesialisert «Voting AI». Denne agenten skriver ikke kode, men leser kode. Den er opplært i våre arkitekturprinsipper, sikkerhetskrav (OWASP, ISO) og samsvarsregler (EU AI Act).
Den stemmer: «Løsning A er raskere, men Løsning B er sikrere og følger mikro tjenestearkitekturen vår bedre.»
Vinneren går til produksjon.
Denne modellen tvinger frem en maktfordeling som mangler i mange team.
project-description.md, rules.md, skills.md en principles.md), de strenge kravene. Arkitekten bestemmer hva vi bygger, hvem som bygger det, hvordan og hvorfor.Den frigjør oss fra syntaksfeilens tyrannisk grep og lar oss fokusere på det vi er gode på: Systemtenkning. Sannhetssøkende. Struktur og beslutningstaking.
Spørsmålet er ikke om AI kan skrive koden vår. Det kapittelet er allerede avsluttet. Kode blir i stor grad et forbruksvareprodukt.
Spørsmålet er: Tør du å gi slipp på kontrollen over koden for dermed å gjenvinne kontrollen over kvaliteten ?
gi meg besked