AI-designauktoritet

AI Design Authority

Vi befinner oss vid en vändpunkt inom mjukvaruutveckling. Diskussionen handlar ofta om vilken AI skriver den bästa koden (Claude vs. ChatGPT) eller var var AI ska bo (IDE eller CLI). Men det är inte rätt frågeställning.

Om vi omfamnar AI som "Vibe Coders" – där vi anger intentionen och AI:n sköter utförandet – skapar vi en enorm ström av ny mjukvara. En svärm av AI-agenter kan på en minut generera mer kod än vad en senior utvecklare kan granska på en vecka. Människan har blivit flaskhalsen.

Lösningen är inte mer människor. Lösningen är en AI-designansvarig.

Från hantverkare till fabrikschef

Traditionellt är en "Design Authority" en grupp arkitekter som träffas en gång i veckan eller månaden för att godkänna eller förkasta en design. I en värld av AI-utveckling i hög hastighet är den modellen hopplöst föråldrad. Den är för långsam och för reaktiv.

Om vi går över till "Disposable Code" – mjukvara som vi inte refaktorerar i oändlighet, utan kastar bort och genererar på nytt när kraven ändras – då förändras vår roll fundamentalt. Vi är inte längre murare som lägger sten för sten. Vi är arkitekterna bakom fabriken som skriver ut väggarna.

Men vem kontrollerar att väggarna står rakt?

"Gauntlet": Ett automatiserat elddop

En AI Design Authority är inte en person, utan en pipeline. En "Gauntlet" som varje rad genererad kod måste kämpa sig igenom för att nå produktion. Denna process ersätter inte mänsklig kodgranskning med ingenting, utan med något bättre.

Det fungerar i tre lager:

1. Den verkställande makten (Genereringen)
Vi ber inte en AI om en lösning, vi ber tre. Vi låter Gemini 3, GPT-5 och en öppen källkodsmodell (som Llama) arbeta parallellt med samma problem. Detta förhindrar tunnelseende och bryter den "lättja" som LLM:er ibland lider av. Detta tillvägagångssätt är också vetenskapligt undersökt och visar att man kan förhindra AI-hallucinationer och bygga mycket långa kedjor utan fel

2. Det hårda filtret (Lagen)
Här är ingen diskussion möjlig. Kod måste kompilera. Linters får inte klaga. Och avgörande: de Black Box-tester måste godkännas. Vi testar inte om funktionen fungerar internt (det kan AI:n manipulera), vi testar om systemet gör vad det ska göra från utsidan. Misslyckas testet? Direkt i papperskorgen.

3. Det mjuka filtret (AI-juryn)
Detta är den verkliga innovationen. De återstående lösningarna presenteras för en specialiserad "Voting AI". Denna agent skriver ingen kod, utan läser kod. Den är tränad på våra arkitekturprinciper, säkerhetskrav (OWASP, ISO) och efterlevnadsregler (EU AI Act).
Den röstar: ”Lösning A är snabbare, men Lösning B är säkrare och följer vår mikrotjänstarkitektur bättre.”

Vinnaren går till produktion.

Maktfördelningsprincipen för mjukvara

Denna modell framtvingar en maktdelning som saknas i många team.

  • Den lagstiftande makten (Arkitekten): Arkitekten skriver "konstitutionen". Promptarna, arkitekturdokumenten (project-description.md, rules.md, skills.md en principles.md), de hårda kraven. Arkitekten bestämmer vad vad vi bygger, vem som bygger det, hur och varför.
  • Den verkställande makten (Kodningsagenter): De utför arbetet. Snabbt, billigt och under överinseende av mänskliga utvecklare.
  • Den dömande makten (Design Authority): Ett oberoende AI-lager som kontrollerar efterlevnad av reglerna.

Slutsats: Arkitektens nya roll

Den befriar oss från syntaxfelens tyranni och låter oss fokusera på det vi är bra på: Systemtänkande. Sanningssökande. Struktur och beslutsfattande.

Frågan är inte om AI kan skriva vår kod. Det ämnet är redan utagerat. Kod blir i hög grad en förbrukningsvara.
Frågan är: Vågar du släppa kontrollen över koden för att därmed återta kontrollen över kvaliteten ?

låt mig veta

Gerard

Gerard är aktiv som AI‑konsult och manager. Med mycket erfarenhet från stora organisationer kan han särskilt snabbt lösa ett problem och arbeta mot en lösning. Kombinerat med en ekonomisk bakgrund säkerställer han affärsmässiga och ansvarsfulla val.