AI Design Authority

Vi befinner oss ved et vendepunkt innen programvareutvikling. Diskusjonen handler ofte om hvilken AI skriver den beste koden (Claude vs. ChatGPT) eller hvor hvor AI bør 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 gå gjennom 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 høyhastighets AI-utvikling 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 – 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).
Han stemmer: «Løsning A er raskere, men Løsning B er tryggere 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-agentene): De utfører arbeidet. Raskt, billig og under tilsyn av menneskelige utviklere.
• Den dømmende makt (Design Authority): Et uavhengig AI-lag som kontrollerer at loven følges.

Konklusjon: Arkitektens nye rolle

Det frigjør oss fra tyranniet av syntaksfeil 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