AI Design Authority
Vi står ved et vendepunkt innen programvareutvikling. Diskusjonen handler ofte om hvilken hvorvidt AI skriver den beste koden (Claude vs. ChatGPT) eller hvor hvor den AI-en skal bo (IDE eller CLI). Men det er ikke den riktige problemstillingen.
Hvis vi omfavner AI som «Vibe Coders» – der vi angir intensjonen og AI-en 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 mennesker. Løsningen er en AI-designautoritet.
Fra håndverker til fabrikkdirektør
Tradisjonelt er en «Design Authority» en gruppe arkitekter som møtes en gang i uken eller måneden for å godkjenne eller forkaste et design. I en verden med AI-utvikling med høy hastighet er den modellen håpløst utdatert. Den er for treg 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 endres – da endres rollen vår fundamentalt. Vi er ikke lenger murere som legger stein for stein. Vi er arkitektene bak fabrikken som printer veggene.
Men hvem kontrollerer at veggene står rett?
«Gauntlet»: En automatisert ildprøve
En AI Design Authority er ikke en person, men en rørledning. En «Gauntlet» som hver linje med generert kode må kjempe seg gjennom for å nå produksjon. Denne prosessen erstatter ikke menneskelig kodegjennomgang 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 åpen kildekode-modell (som Llama) jobbe parallelt med det samme problemet. Dette forhindrer tunnelsyn og bryter «latskapen» som LLM-er noen ganger lider av. 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 ingen diskusjon mulig. Kode må kompilere. Linters må ikke klage. Og avgjørende: de Black Box-tester må bestås. 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øpla.
3. Det myke filteret (AI-juryen)
Dette er den virkelige innovasjonen. De gjenværende løsningene legges frem for en spesialisert «Voting AI». Denne agenten skriver ikke kode, men leser kode. Den er trent på 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 vår mikrotjenestearkitektur bedre.”
Vinneren går til produksjon.
Programvarens maktfordelingsprinsipp
Denne modellen tvinger frem en maktdeling som mangler i mange team.
- Den lovgivende makt (Arkitekten): Arkitekten skriver «grunnloven». Promptene, arkitekturdokumentene (
project-description.md, rules.md, skills.md en principles.md), de ufravikelige kravene. Arkitekten bestemmer hva hva vi bygger, hvem som bygger det, hvordan og hvorfor. - Den utøvende makt (Koding-agenter): De utfører arbeidet. Raskt, rimelig og under tilsyn av menneskelige utviklere.
- Dømmende makt (Designmyndigheten): Et uavhengig AI-lag som kontrollerer at loven følges.
Konklusjon: Arkitektens nye rolle
Den frigjør oss fra syntaksfeilenes tyranni og lar oss fokusere på det vi er gode til: Systemtenkning. Sannhetssøking. Struktur og beslutningstaking.
Spørsmålet er ikke om AI kan skrive koden vår. Det emnet 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 igjen?
gi meg beskjed
