När jag började använda Claude Code mer seriöst märkte jag snabbt att en bra AI räcker långt. Den kan läsa kod, föreslå lösningar, skriva tester och hålla ganska mycket context i samma process. Men i vissa lägen vill jag inte ha en generalist. Jag vill ha någon som bara tänker på security. Eller någon som läser koden som en senior reviewer. Eller varför inte två modeller som får argumentera mot varandra innan jag tar beslut om sätt att lösa utmaningen?
Det var där Claude Norns började.
Norns är ett litet plugin med tillhörande orchestrator-upplägg för Claude Code som låter mig kalla in 26 olika expertpersonas vid behov. Det är fortfarande Claude Code som är arenan som används, men bakom kommandona finns specialiserade roller och flera AI-verktyg som kan användas tillsammans.
Codex kan utföra en code review. Gemini kan användas för snabb research till låg tokenkostnad. Claude kan vara senior architect med överblick över allt som händer.
Poängen är inte att ersätta mitt omdöme, utan att göra det enklare att få in rätt sorts motstånd i rätt ögonblick.
Från en bred agent till rätt perspektiv
Det enklaste sättet att använda Claude Norns är /quick.
Jag kan då skriva något i stil med:
/quick review src/api/auth.tseller:
/quick security the login formoch låta systemet själv styra frågan till rätt persona. Det finns till exempel roller för code review, security, performance, debugging, architecture, frontend, backend, database, Drupal, Liquid, TypeScript, Python och en hel del annat.
Det låter kanske som ännu en lista med agents, men för mig är det viktiga inte antalet. Det viktiga är: kommer de till användning och hur enkelt är det att kalla på dem? Om jag behöver skriva en lång prompt för att få en bra security review varje gång, kommer jag tyvärr inte använda den varje gång. Om det räcker med ett kort kommando, blir det en naturlig del av min arbetsprocess.
Det är samma skäl som jag byggde Norns Companion för tmux-sessioner. När något kräver för mycket context switching händer det mer sällan än det borde göra. Norns Companion håller koll på var mina agenter befinner sig under tiden jag arbetar. Claude Norns handlar mer om vilken sorts agent jag vill kalla in vid vilket tillfälle.
När jag vill att modeller ska säga emot varandra
Den del jag tycker är mest intressant att skruva på är inte single-persona-kommandona, utan de workflows som finns i /debate och /security-audit.
Med /debate kan två modeller föreslå varsin lösning, kritisera varandra och sedan sammanfatta en gemensam rekommendation.
Det är användbart när jag står inför ett val som inte har ett självklart lösningsförslag:
/debate REST vs GraphQL for this customer APIeller:
/debate should this feature live in the CMS or in the app layer?Jag vill inte att modellerna bara ska bekräfta första bästa idé. Jag vill att de ska hitta vad jag missar och på så sätt även driva min utveckling framåt. En debatt mellan två modeller är inte magi, men den gör det svårare för ett dåligt antagande att ta plats bara för att det lät rimligt i första svaret man får tillbaka.
Detta passar särskilt bra för beslut när det kommer till arkitektur av lösningar. Inte för att AI ska fatta beslutet åt mig, utan för att jag får se argumenten utvecklas från flera håll innan jag själv landar i något hållbart.
Security audit som röd och blå sida
/security-audit är byggt på samma idé, men mer uppstyrt.
Först finns det en blå sida som försöker tänka fram en säker lösning.
Sedan finns det en röd sida som försöker hitta brister i blå sidas lösning.
Efter det kommer rekommendation och validering.
Det här är en typ av workflow där en vanlig prompt lätt kan bli för snäll. Om jag ber en agent "kolla om auth-flödet är säkert" får jag ibland ett förväntat rimligt svar, men det kan fortfarande låta som en checklista. När jag explicit delar upp arbetet i försvar, attack och fix upplever jag resultatet oftare som mer stabilt. Var finns attackytan? Vilket antagande bygger lösningen på? Vad händer om användaren manipulerar inputen? Vilka steg går faktiskt att testa?
Det betyder inte att jag ersätter riktig mänsklig granskning. Men för vardaglig utveckling är det ett bra extra lager att ha nära till hands. Särskilt i projekt där jag annars hade nöjt mig med att själv tänka "det där ser nog okej ut".
Det som försvann: Double Diamond
En tidigare version av Claude Norns byggde mer på Double Diamond: först utforska, sedan avgränsa, sedan utveckla, sedan leverera. På papperet var det snyggt. I praktiken blev det alldeles för många steg för den sorts arbete jag gör till vardags.
Jag behöver inte alltid ett helt designflöde. Ibland behöver jag bara en bra reviewer. Ibland behöver jag en security-reviewer. Ibland behöver jag två modeller som får bråka om en lösning en stund.
Så jag slimmade ner verktyget. Gamla phase-kommandon och en hel del död kod försvann, och lösningen blev mindre. Det är en rätt viktig lärdom för mig i skapande av agentverktyg överlag: fler steg gör inte automatiskt systemet smartare. Ett workflow måste vara lätt nog att jag faktiskt använder det när jag är mitt i arbetet. Annars kan jag likaväl slänga det.
Varför inte bara använda prompts?
Det går såklart att göra mycket av detta med vanliga prompts. Jag kan be Claude agera security-reviewer. Jag kan be Codex reviewa en diff. Jag kan öppna Gemini separat och be om research.
Men då behöver jag hålla ihop upplägget själv varje gång. Vilken modell passar? Vilken persona ska användas? Hur ska filreferenser skickas med? Ska det vara read-only? Hur ska resultatet jämföras?
Med Claude Norns försöker jag paketera de stegen så att de blir en del av arbetsflödet istället för en ny liten planeringsuppgift som bryter mitt workflow. Det är inte en ersättning för att tänka, det är ett sätt att göra det lättare att tänka och se fler perspektiv.
Vad jag vill testa mer
Nästa steg är att samla bättre exempel från daglig användning av verktyget.
Jag vill ha screenshots som visar skillnaden mellan en vanlig prompt och en mer riktad persona.
Jag vill också testa /debate på några arkitekturval där jag redan har en magkänsla, för att se om modellerna hittar något jag själv förbiser.
Jag har valt att inte lyfta estimate-skillen som huvudexempel här. Den är viktig för mig, men den är också väldigt specifik för mitt sätt att jobba med offerter och uppgraderingar. Claude Norns blir lättare att förstå genom bredare exempel: review, security, debugging och architecture.
Det finns också en praktisk fråga kring publicering. Verktyget finns lokalt hos mig och i GitHub-repot, men innan jag pekar folk dit vill jag säkerställa att installation, provider-detektering och dokumentation känns rimligt stabila. En artikel om verktyget blir snabbt en sorts löfte. Jag vill att det löftet ska vara lagom.
Experter, inte autopilot
Det jag gillar mest med Claude Norns är att det inte försöker ta över hela arbetsflödet. Det är inte byggt för att jag ska trycka på en knapp och bränna tokens till max. Det är byggt för de där små besluten under dagen där ett extra perspektiv kan göra stor skillnad för mig.
En security-auditor som bara tänker på attackytor. En reviewer som bara letar regressioner. En performance-persona som inte bryr sig om att lösningen är elegant om den blir långsam. En debatt där två modeller tvingas formulera varför deras egen lösning är bättre.
Det är så jag vill använda AI i utveckling just nu. Inte som en ersättare för ansvar, utan som ett sätt att få fler skarpa vinklar på samma problem.
Och när det fungerar känns det mindre som att jag har startat upp en större autopilot. Det känns mer som att jag har experter nära till hands, experter som stöttar mig i mitt arbete.
