Tre verb. En metod.

Vi har tre ord på en whiteboard. Bygg, mät, automatisera. Det är hela metoden. När folk frågar hur vi arbetar på Kapaciti väntar de sig en process-pyramid eller en SCRUM-variant med ceremonier och sprintar och retros. Vi har inte det. Vi har tre verb, i en specifik ordning, och en envis åsikt om varför just den ordningen är rätt.

Det här är en post om varför vi börjar med Bygg, varför mätning kommer före automation, och varför nästan allt jag har lärt mig de senaste åren går emot hur de flesta konsulter just nu jobbar med AI.

Bygg först, planera mindre

Den första instinkten när någon kommer till oss med ett problem är att börja prata om det. Workshops, kravspec, intressentintervjuer, framtidsanalys. Klassiskt. Vi gör inte så. Eller, vi gör det lite, men korthugget och bara om det krävs för att förstå vad vi ska bygga den första prototypen av.

Anledningen är enkel. När du planerar i ett rum med människor som aldrig har sett tekniken funka, planerar du på fantasi. Du gissar vad Claude klarar, du gissar hur RAG beter sig på just det här bolagets dokumentförråd, du gissar hur lång tid en agent tar på sig att svara när Postgres ligger i Stockholm och modellen i Frankfurt. Allt det är gissningar tills någon har byggt något och tittat på det.

Min teori är att de flesta misslyckade AI-projekt dör i specfas. Inte för att speccen är dålig, utan för att den är skriven utan att någon har provat. När prototypen sedan möter verkligheten är gapet mellan vad bolaget trodde de skulle få och vad som faktiskt går att bygga så stort att hela projektet förlorar moralen redan innan det har börjat på riktigt.

Så vi vänder på det. Innan vi pratar pris, innan vi pratar arkitektur, bygger vi en hyfsat ful prototyp på två till fem dagar. Oftast i n8n eller en liten FastAPI-tjänst med en LiteLLM-router framför Claude och en lokal Llama 3.1 70B via Ollama som backup. Datat är fejk eller ett litet utdrag. Den kör inte i produktion. Men den finns. Den går att klicka på. Den ger ett svar.

Sedan tittar vi på den tillsammans. Och då händer något som jag fortfarande tycker är en av få magiska saker i det här jobbet. Bolaget som beställde börjar plötsligt ha åsikter. De säger "den ska kunna göra X också" och "den får aldrig svara så där" och "varför läser den inte fakturarader". Nu har vi en konversation som är värd något, för den är grundad i något konkret istället för i fantasi.

Mät innan du automatiserar

Här gör de flesta fel, och jag skriver det utan att vara nedlåtande, för jag har gjort det själv många gånger. Du har en prototyp. Den ser hyfsad ut. Demon imponerar. Beställaren säger "kör, sätt det i produktion, automatisera". Och om du gör som de säger har du precis byggt en maskin som upprepar fel snabbare än vad någon hinner upptäcka.

Mät är det tråkigaste verbet av de tre. Det är därför det hoppas över. Men det är också det som bestämmer om hela bygget håller eller inte.

När vi pratar mätning menar vi inte vaga KPI-presentationer. Vi menar konkret. Hur ofta hallucinerar modellen när den svarar på kundsupportfrågor med RAG mot er dokumentation. Hur många minuter sparar mottagaren faktiskt på att klassificera inkommande mail. Vad är felmarginalen när systemet läser av belopp från PDF-fakturor jämfört med en människa som gör samma sak. Hur ofta returnerar embedding-sökningen via pgvector irrelevanta träffar för en specifik typ av fråga.

Det här går inte att gissa. Det går inte heller att lita på modellanbudens egna benchmarks, för de är gjorda på engelska och på fall som inte liknar svenska SME-företags vardag. Du måste sätta dig med riktig data, riktig användning, och faktiskt räkna.

Det jag är trött på är konsulter som säljer in en automation och sedan inte mäter om den fungerar. Det blir en svart låda som rullar och vars värde aldrig prövas igen. När bolaget ett halvår senare frågar "har det här tjänat in sig" har ingen ett svar.

I praktiken brukar vår mätfas se ut så här. Vi kör prototypen parallellt med det manuella arbetet i två till fyra veckor. Vi loggar varje svar, varje beslut, varje fel. Vi tittar på loggarna i hand. Inte i en dashboard. I hand. Det går inte att förstå hur en RAG-pipeline beter sig genom att titta på medelvärden. Du måste läsa de faktiska svaren och bedöma dem ett efter ett, åtminstone i början.

Sedan justerar vi. Modellval, prompt, chunkning, embedding-modell. Vi byter kanske från OpenAIs embeddings till BAAI/bge-m3 lokalt. Vi sänker temperaturen. Vi lägger till en re-ranker. Vi mäter igen. Den här loopen är inte rolig att presentera på styrelsemöten, men det är där värdet faktiskt skapas.

Automatisera är sista steget, inte första

När vi når automatiseringssteget har vi alltså redan ett system som fungerar och som vi vet fungerar, för vi har siffror på det. Då, och först då, blir automation rätt fråga.

Automatisering betyder att någonting kör utan människa i loopen. Det är ett stort steg. Det betyder att felen som finns kvar nu kommer ske utan tillsyn. Om mätfasen visade att systemet missar tre procent av fakturorna och du automatiserar utan kontrollsteg, så missar systemet nu tre procent av fakturorna utan att någon ser det. Den siffran måste vara acceptabel innan ni går från manuell tillsyn till automation, inte efter.

Här brukar LangGraph eller egna små orkestreringsskript komma in. Vi bygger inte alltid orkestrering. Ärligt talat är n8n med några få noder ofta tillräckligt för en stor del av fallen. När det inte räcker går vi vidare. Men vi börjar aldrig med en agent-arkitektur som första lösning, för agentkedjor är roliga att rita på whiteboard och svåra att felsöka när de gör fel beslut i steg fyra av sju.

Jag fattar fortfarande inte varför så många byggen idag startar med agent-arkitektur. En enkel pipeline med tydliga steg och ett LLM-anrop per steg är nästan alltid lättare att mäta, billigare att köra, och enklare att laga. Agenter är rätt verktyg när uppgiften är öppen och när stegen inte går att förutse i förväg. För majoriteten av vad svenska SME-bolag faktiskt vill automatisera är det inte fallet.

Vad vi sa nej till denna vecka

En del av att ha en metod är att veta vad som inte passar in i den. Vi har sagt nej till tre saker den senaste veckan, och det säger något om hur vi tänker.

Det första var en förfrågan om att bygga "en AI-assistent för hela bolaget" med integration mot allt från Slack till deras ERP. Stort projekt på pappret, hyfsad budget. Vi sa nej eftersom det inte fanns något specifikt problem som assistenten skulle lösa. Det var en idé om att alla skulle få en AI-assistent, inte ett behov. När vi frågade vad assistenten skulle göra första veckan i drift fick vi inget svar. Då finns inget att bygga, inget att mäta, och därför inget att automatisera.

Det andra var en chatbot på en hemsida för ett bolag som redan hade en chatbot som fungerade okej. De ville byta för att den nya skulle vara "smartare". Vi sa nej eftersom de inte hade mätt vad den nuvarande gjorde rätt eller fel. Att byta system utan att veta vad systemet du har faktiskt presterar är att kasta pengar på ett problem du inte har definierat.

Det tredje var ett RAG-projekt mot en dokumentsamling som var totalt okurerad. Tusentals filer, ingen versionshantering, motstridiga dokument från olika år, ingen tydlig sanning om vad som var aktuellt. Vi sa att det första steget inte var att bygga en RAG-pipeline. Det var att rensa data. Vi kan göra det också, men det är inte AI, det är källkritik och informationsstruktur. Vi var tydliga med att utan den fasen skulle systemet hallucinera självsäkert ur ett kaos. De ville ändå köra. Vi tackade nej.

Det här är inte för att vi har råd att tacka nej. Det är för att vi inte har råd att göra projekt som är dömda att misslyckas. Skillnaden är värd att tänka på.

Fokus är en strategi, inte en känsla

Det här är kanske den minst tekniska delen av posten, men det är den jag funderar mest på. Fokus blir ofta beskrivet som en personlig egenskap eller en känsla. Du har fokus eller så har du det inte. Min övertygelse är att det är fel. Fokus är ett strategiskt val som upprepas många gånger om dagen.

När vi säger nej till ett projekt är det fokus. När vi säger till ett bolag att de inte är redo för automation ännu är det fokus. När vi väljer att inte bygga en agent-arkitektur fast vi tekniskt skulle kunna är det fokus. När vi sätter en två veckor lång mätfas innan vi går vidare till produktion är det fokus.

Bygg, mät, automatisera är inte bara en arbetsordning. Det är en filtreringsmekanism. Om en fråga inte passar in i ordningen, oftast för att någon vill hoppa över Mät, så vet vi att vi ska sakta ner och inte påskynda. Om någon vill ha en plan istället för en byggd prototyp vet vi att vi ska bygga ändå. Om någon vill automatisera utan mätning vet vi att svaret är att mäta först.

Det fina med tre verb är att de är kortare än vad ett misstag är. Du hinner tänka igenom dem innan du gör fel sak. Det är hela poängen.

På Kapaciti gör vi mycket av det här. Hör av dig om du sitter med något som passar.