Vi står vid ett vägskäl i mjukvaruutveckling. Diskussionen handlar ofta om vilken AI som skriver den bästa koden (Claude vs. ChatGPT) eller var var AI ska bo (IDE eller CLI). Men det är inte den rätta frågeställningen.
Om vi omfamnar AI som “Vibe Coders” – där vi anger avsikten och AI utför den – skapar vi ett enormt flöde av ny mjukvara. En svärm av AI‑agenter kan på en minut generera mer kod än 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 Designauktoritet.
Traditionellt är “Design Authority” en grupp arkitekter som samlas en gång i veckan eller månaden för att godkänna eller avvisa en design. I en värld av snabb AI-utveckling är den modellen hopplöst föråldrad. Den är för långsam och för reaktiv.
Om vi övergår till “Disposable Code” – mjukvara som vi inte refaktoriserar i oändlighet, utan kastar bort och genererar på nytt när kraven förändras – förändras vår roll fundamentalt. Vi är inte längre murare som lägger sten för sten. Vi är fabriksarkitekterna som skriver ut väggarna.
Men vem kontrollerar om de där väggarna är raka?
En AI Design Authority är ingen person, utan en pipeline. En “Gauntlet” där varje rad genererad kod måste kämpa sig igenom för att nå produktion. Denna process ersätter inte den mänskliga kodgranskningen med ingenting, men med något bättre.
Det fungerar i tre lager:
1. Den verkställande makten (Genereringen)
Vi ber inte en enda 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 tunnelvision och bryter den “lättja” som LLM:ar ibland har. Denna metod är också vetenskapligt undersökt och visar att du 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. Koden måste kompilera. Linters får inte klaga. Och avgörande: Black Box-tester måste lyckas. Vi testar inte om funktionen fungerar internt (det kan manipulera AI:n), vi testar om systemet från utsidan gör vad det ska. Misslyckas testet? Direkt till papperskorgen.
3. Det mjuka filtret (AI‑juryn)
Detta är den verkliga innovationen. De återstående lösningarna läggs fram för en specialiserad “Voting AI”. Denna agent skriver ingen kod, men läser kod. Den är tränad på våra arkitekturprinciper, säkerhetskrav (OWASP, ISO) och efterlevnadsregler (EU AI Act).
Han 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.
Denna modell tvingar fram en maktdelning som saknas i många team.
project-description.md, rules.md, skills.md en principles.md), de hårda kraven. Arkitekten bestämmer vad vi bygger, vem som bygger, hur och varför.Den befriar oss från tyrannin av syntaxfel 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 avslutat. Kod blir till stor del en engångsprodukt.
Frågan är: Vågar du kontrollen över kod släppa, för att därmed återfå kontrollen över kvalitet att vinna tillbaka?
låt mig veta