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 den AI:n bör bo (IDE eller CLI). Men det är inte rätt frågeställning.
Om vi omfamnar AI som "Vibe Coders" – där vi anger avsikten och AI:n utför jobbet – skapar vi en enorm ström av ny mjukvara. En svärm av AI-agenter kan på en minut generera mer kod än en senior utvecklare hinner granska på en vecka. Människan har blivit flaskhalsen.
Lösningen är inte mer människor. Lösningen är en AI Design Authority.
Traditionellt sett är en "Design Authority" en grupp arkitekter som träffas en gång i veckan eller månaden för att godkänna eller underkänna en design. I en värld av AI-utveckling med 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 slänger och genererar på nytt när kraven förändras – förändras vår roll i grunden. Vi är inte längre murare som lägger sten för sten. Vi är arkitekterna till fabriken som skriver ut väggarna.
Men vem kontrollerar att de där väggarna är raka?
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 den mänskliga kodgranskningen med ingenting, utan 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 tunnelblick och bryter den "lathet" som LLM:er ibland drabbas 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 finns det inget utrymme för diskussion. Koden måste kompilera. Linters får inte klaga. Och avgörande är att Black Box-tester måste klara sig. Vi testar inte om funktionen fungerar internt (det kan AI:n manipulera), vi testar om systemet på utsidan gör det det ska göra. Misslyckas testet? Direkt i 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, utan läser kod. Den är tränad på våra arkitekturprinciper, säkerhetskrav (OWASP, ISO) och regelverk (EU AI Act).
Den resonerar: "Lösning A är snabbare, men Lösning B är säkrare och följer vår mikrotjänstarkitektur bättre."
Vinnaren går vidare till produktion.
Denna modell tvingar fram en maktfördelning som saknas i många team.
project-description.md, rules.md, skills.md en principles.md), de stenhårda kraven. Arkitekten bestämmer vad vi bygger, vem som bygger det, hur och varför.Den befriar oss från syntaxfelens tyranni och låter oss fokusera på det vi är bra på: Systemtänkande. Sökande efter sanning. Struktur och beslutsfattande.
Frågan är inte om AI kan skriva vår kod. Det kapitlet är redan avslutat. Kod håller till stor del på att bli en slit-och-släng-produkt.
Frågan är: Vågar du släppa kontrollen över koden för att därmed återvinna kontrollen över kvaliteten ?
låt mig veta