AI design authority

AI Design Authority

Vi står ved et vendepunkt i programvareutvikling. hvilke Om AI skriver den beste koden (Claude vs. ChatGPT) eller hvor om AI må bo (IDE eller CLI). Men det er ikke riktig problemstilling.

Problemet er ikke generering av kode. Det er validering derav.

Hvis vi omfavner AI som «Vibe Coders» – der vi angir intensjonen og AI 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-designmyndighet.

Fra håndverker til fabrikksdirektør

Tradisjonelt er «Design Authority» en liten gruppe arkitekter som møtes ukentlig eller månedlig 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 vi ikke refakterer i det uendelige, men kaster og genererer på nytt når kravene endrer seg – endres vår rolle fundamentalt. Vi er ikke lenger murere som legger stein for stein. Vi er arkitektene for fabrikken som printer veggene.

Men hvem kontrollerer at disse veggene står rette?

The "Gauntlet": En automatisert ildprøve

En AI Design Authority er ikke en person, men en pipeline. En «Gauntlet» som hver linje generert kode må kjempe seg gjennom for å nå produksjon. Denne prosessen erstatter ikke menneskelig code review 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 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 den «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)
Dette er ikke til diskusjon. Koden må kompilere. Linters må ikke klage. Og avgjørende: Black box-tester må bestå. Vi tester ikke om funksjonen fungerer internt (det kan manipulere AI), vi tester om systemet gjør det det skal utvendig. 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 compliance-regler (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 maktfordeling (trias politica)

Denne modellen håndhever en maktfordeling som mangler i mange team.

  • Den lovgivende makt (Arkitekten): Arkitekten skriver "grunnloven". Promptene, arkitektur-dokumentene (project-description.md, rules.md, skills.md en principles.md), de harde kravene. Arkitekten bestemmer hva hva vi bygger, hvem som bygger det, hvordan og hvorfor.
  • Den utøvende makt (Kodingagentene): De utfører. Raskt, billig og under tilsyn av menneskelige utviklere.
  • Den dømmende makt (Designmyndigheten): Et uavhengig AI-lag som kontrollerer etter loven.

Konklusjon: Arkitektens nye rolle

Den befrier oss fra tyranniet til syntaksfeil og lar oss fokusere på det vi er gode på: systemtenkning. Sannhetsfunn. Struktur og beslutningstaking.

Spørsmålet er ikke om AI kan skrive vår kode. Det temaet er allerede avsluttet. Kode vil i stor grad bli et engangsprodukt.
Spørsmålet er: Tør du å gi fra deg kontrollen over kode gi slipp på, for dermed å gjenvinne kontroll over kvalitet å vinne tilbake?

gi meg beskjed

Gerard

Gerard er aktiv som AI-konsulent og leder. Med mye erfaring fra store organisasjoner kan han svært raskt avdekke et problem og arbeide mot en løsning. Kombinert med en økonomisk bakgrunn sørger han for kommersielt forsvarlige valg.