Det första vi gör med ett nytt uppdrag är att fråga vad som ska ha hänt när det är klart. Inte uttryckt som en modell eller en plattform, utan rent praktiskt: vad ska vara annorlunda en vanlig tisdag tre månader senare, när vi inte längre är inblandade. Om det enda svaret är att bolaget vill ha en bättre känsla för var AI passar, så är vi fel leverantör för just det. Det låter snålt. Men det sparar båda parter ett kvartal och en faktura som ingen blir glad av i efterhand.
Vi har landat i tre saker. Vi bygger system som ska gå i drift och stå kvar där. Vi lär team att underhålla det de fått, så att det inte ruttnar när vi går. Och så vägleder vi när ett beslut ska tas och ingen i rummet riktigt vet vad alternativen kostar över tid. Det är hela listan. Allt annat har vi gallrat bort, och den gallringen har tagit oss längre tid än jag vill erkänna.
Bygga betyder att något hamnar i drift
När vi säger bygga menar vi kod som körs på en server någon betalar för, inte en prototyp som imponerar i ett möte. Det är skillnaden mellan något som funkar när du visar det och något som funkar klockan 02:14 en söndag när ingen tittar. Det senare är svårare, och det är där det mesta av arbetet faktiskt ligger. Ett typiskt bygge hos oss är ett flöde i n8n som plockar upp inkommande mejl, ett FastAPI-lager som gör den tyngre logiken, och en Postgres-databas där vi lägger pgvector ovanpå för att kunna söka i bolagets egna dokument. Inget av det är spännande att se på. Det är poängen.
Det jag är trött på är demos som aldrig var tänkta att överleva kontakt med riktig data. Du har sett dem. En chatt som svarar perfekt på tre förberedda frågor och faller ihop på den fjärde, för att någon hårdkodat halva svaret. Vi bygger inte sådant, och jag vägrar leverera något jag själv inte skulle våga sätta i produktion. När vi sätter en RAG-lösning så bestämmer vi tidigt vilken embeddingmodell vi kör, oftast BAAI/bge-m3 om det ska vara flerspråkigt, och vi mäter faktiskt hur ofta den hämtar rätt stycke innan vi släpper den vidare. Mätningen är tråkig. Den är också det enda som skiljer ett system som håller från ett som ser hyfsat ut första veckan.
Drift hör ihop med bygget. Vi tar inte ett uppdrag, levererar en zip-fil och försvinner. Om vi byggt något som anropar Anthropic Claude eller OpenAI gpt-5.4 så lägger vi LiteLLM emellan från start, så att bolaget kan byta modell utan att skriva om sin kod den dagen priset eller kvaliteten ändras. Det kostar lite extra nu och sparar mycket senare. Sådana val gör vi hela tiden, och de syns sällan i en demo.
Lära är inte en PowerPoint
Den vanligaste sortens AI-utbildning jag stött på är en halvdag där någon visar ChatGPT på storbild och alla nickar. Folk går därifrån peppade och kan ingenting nytt på måndag. Vi gör inte den varianten. När vi håller workshop sitter vi i bolagets egen kod och deras egna data, och vi bygger något litet som faktiskt funkar innan dagen är slut. Det kan vara att få Cursor att förstå deras kodbas, eller att sätta upp Ollama lokalt och köra Qwen2.5 på en laptop så att teamet ser med egna ögon att en modell inte behöver bo i molnet för att vara användbar.
Internutbildning hos oss handlar mer om vad man inte ska göra än om nya trick. Var gränsen går för vad en språkmodell kan lova. När en hallucination är ett irritationsmoment och när den är ett juridiskt problem som ingen vill äga. Hur man skriver en prompt som inte går sönder så fort indata ser lite annorlunda ut. Det är mindre glamoröst än folk hoppas, och mer användbart än de räknat med.
Code review är den delen jag personligen tycker mest om, även om den säljer sämst. Ett team har byggt något med AI, det funkar, och de vill veta om det håller. Vi går igenom det rad för rad och pekar på var det kommer att spricka. Ofta är det inte modellvalet som är problemet, utan att någon glömt vad som händer när tjänsten i andra änden är nere i fyra sekunder. Det är sådant man bara ser om man byggt och brustit ett antal gånger själv. Min teori är att den erfarenheten är värd mer än all teori vi kan rabbla, och därför försöker vi lämna den kvar hos teamet i stället för att behålla den.
Vägleda är där pengar sparas i tysthet
Den tredje saken ser minst ut som ett leverabelt och betyder ibland mest. Ett bolag står inför ett vägval och alla i rummet har en åsikt men ingen har räknat. Ska vi köra molnmodell eller lokalt. Vilken leverantör binder vi oss till. Vad händer med våra data. Här går vi in och gör grovjobbet med siffrorna i stället för känslorna. Ibland blir svaret att Anthropic Claude i molnet är helt rätt, för att volymen är låg och kraven på sekretess hanterbara. Ibland blir svaret att en Llama 3.1 70B på egen hårdvara betalar sig på åtta månader och att den dataskyddsdiskussionen då blir betydligt kortare.
Leverantörsval gör vi med en kallare blick än de flesta. En modellleverantör är inte en partner du gifter dig med, det är en kran du vill kunna stänga. Därför ritar vi arkitekturen så att bytet är möjligt, med ett abstraktionslager som LiteLLM eller en orkestrering i LangGraph som inte vet eller bryr sig om vilken modell som svarar i andra änden. Jag fattar fortfarande inte varför så många bygger sig fast i en enda leverantörs SDK när alternativet kostar någon timme extra i början. Det är som att mura igen ytterdörren för att man råkar gilla utsikten just nu.
Exit-klausuler är den del av vägledningen som folk glömmer tills det är för sent. Vad äger ni egentligen om sex månader. Var ligger era inbäddningar, era promptmallar, era loggar. Kan ni ta med er allt och köra någon annanstans, eller sitter halva er logik i ett gränssnitt ni inte kommer åt. Vi tittar igenom avtalen och pekar på var bolaget riskerar att bli inlåst utan att märka det. Det här är en av få saker där jag tycker att vi tjänar in vårt arvode redan på första mötet, för en dålig inlåsning är dyr på ett sätt som inte syns förrän man vill därifrån.
Det vi säger nej till
Vi bygger inte fler dashboards. Det är inte en stilfråga, det är en observation. Det vi ofta ser i fältet är att en dashboard blir platsen där en idé går för att dö lugnt, en skärm med snygga grafer som ingen öppnar efter andra veckan. Om svaret på ett problem är ytterligare en vy att titta på, då har vi oftast missat själva problemet. Vi tar hellre bort en dashboard och låter systemet agera direkt, så att människan får ett färdigt förslag i stället för en graf hon ska tolka.
Vi gör inte heller AI-strategi på papper. Du vet sorten. Ett fyrtiosidigt dokument med en mognadstrappa och en roadmap i tre faser, som ser fint ut i en styrelsepresentation och inte producerar en enda rad kod. Jag har läst för många sådana. De är inte värdelösa i teorin, men i praktiken blir de en hyllvärmare som ger bolaget en känsla av framsteg utan att något rör sig. Om vi ska prata strategi gör vi det medan vi bygger den första riktiga saken, för då tvingas strategin möta verkligheten direkt.
Och vi tar inte uppdrag som inte producerar något konkret. Om jag inte kan beskriva vad som finns i drift eller i någons huvud när vi är klara, då tackar vi nej. Det har hänt att vi sagt nej till uppdrag som hade gett bra betalt, helt enkelt för att kunden ville ha vår närvaro snarare än en leverans. Det är en lyx att kunna säga nej, det vet jag. Men varje gång vi gjort det har det varit rätt, och de gånger vi tummade på det i början ångrade vi det.
Hur vi avgör om vi är rätt
Det finns några frågor vi ställer oss innan vi tackar ja, och de handlar mindre om tekniken än om bolaget på andra sidan bordet.
- Finns det en person som äger problemet och som kommer att leva med lösningen efteråt, eller skickas vi in av någon som själv ska gå vidare nästa kvartal.
- Får vi prata med dem som faktiskt gör jobbet, inte bara med dem som beställer det.
- Går det att mäta om det vi bygger gjorde någon skillnad, eller är allt en fråga om magkänsla i efterhand.
Om de tre sakerna stämmer brukar resten lösa sig, även när tekniken är knepig. Om de inte stämmer hjälper ingen modell i världen, och då är det ärligare att säga det tidigt. Vi är ganska bra på att känna igen ett uppdrag som kommer att gå snett, för vi har varit med om några. Det är inte stolthet, det är ärr.
Det jag landar i, efter att ha skalat bort allt vi inte gör, är att arbetet blivit roligare och tydligare på samma gång. Vi vet vad vi är till för. Bolagen som hör av sig vet vad de får. Och de gånger vi inte passar säger vi det rakt ut, vilket sparar alla tid. Bygga, lära, vägleda. Det är så vi jobbar nu. Hör av dig om du sitter med något av det.