AI Design Authority

Vi er ved et vendepunkt i programvareutvikling. Diskusjonen handler ofte om hvilken AI som skriver den beste koden (Claude vs. ChatGPT) eller hvor hvor AI skal bo (IDE eller CLI). Men det er feil diskusjon.

Det virkelige problemet er ikke generasjon av kode. Det virkelige problemet er validering av det.

Når vi omfavner AI som «Vibe Coders» – der vi angir intensjonen og AI-en utfører – 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 Design Autoritet.

Fra håndverker til fabrikksjef

Tradisjonelt er "Design Authority" en liten gruppe arkitekter som møtes en gang i uken eller måneden for å godkjenne eller avvise et design. I en verden av høyhastighets AI-utvikling er den modellen håpløst utdatert. Den er for treg og for reaktiv.

Når 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 vår rolle fundamentalt. Vi er ikke lenger murere som legger stein for stein. Vi er arkitektene bak fabrikken som skriver ut veggene.

Men hvem kontrollerer om de veggene er rette?

«Utfordringen»: En automatisert ildprøve

En AI Design Authority er ikke en person, men en pipeline. En “Gauntlet” som hver regel av generert kode må kjempe seg gjennom for å nå produksjon. Denne prosessen erstatter ikke den menneskelige kodevurderingen med ingenting, men med noe bedre.

Det fungerer i tre lag:

1. Den utøvende makt (Generasjonen)
Vi ber ikke én AI om en løsning, vi ber om tre. Vi lar Gemini 3, GPT-5 og en åpen kildekode-modell (som Llama) jobbe parallelt med samme problem. Dette forhindrer tunnelsyn og bryter gjennom «latheten» som LLM-er noen ganger lider av. Denne tilnærmingen er også vitenskapelig undersøkt og viser at du kan forhindre AI-hallusinasjon og bygge svært lange kjeder uten feil

2. Det Harde Filteret (Loven)
Her er det ingen diskusjon mulig. Kode må kompilere. Linters skal ikke klage. Og avgjørende: den Svartboks-tester må bestå. Vi tester ikke om funksjonen virker internt (det kan manipulere AI-en), vi tester om systemet gjør det det skal utenfra. Feiler testen? Rett i søpla.

3. Det Myke Filteret (AI-juryen)
Dette er den virkelige innovasjonen. De gjenværende løsningene presenteres for en spesialisert “Voting AI”. Denne agenten skriver ingen kode, men leser kode. Han er trent på våre arkitekturprinsipper, sikkerhetskrav (OWASP, ISO) og samsvarsregler (EU AI Act).
Han sier: “Løsning A er raskere, men Løsning B er tryggere og følger mikrotjenestearkitekturen vår bedre.”

Vinneren går til produksjon.

Programvarens maktfordeling

Denne modellen tvinger frem et maktfordelingsprinsipp som mangler i mange team.

• Den lovgivende makt (Arkitekten): Arkitekten skriver «Grunnloven». Ledetekstene, arkitekturdokumentene (project-description.md, rules.md en principles.md), de strenge krav. Arkitekten bestemmer hva vi bygger og hvorfor.
• Den utøvende makt (Kodingsagentene): De utfører. Raskt, billig og under tilsyn av menneskelige utviklere.
• Den dømmende makt (Designmyndigheten): Et uavhengig AI-lag som sjekker mot loven.

Konklusjon: Arkitektens nye rolle

Det frigjør oss fra syntaksfeilenes tyranni og lar oss fokusere på det vi er gode på: Systemtenkning. Sannhetssøken. Struktur og beslutningstaking.

Spørsmålet er ikke om AI kan skrive koden vår. Det er allerede avgjort. Kode blir i stor grad forbruksvare.
Spørsmålet er: Tør du å overlate kontrollen over gjennomføring gi slipp, for dermed å få kontroll over kvalitet tilbake?