# Tomas Andre - Technology Leader, AI Strategist & CAIO

> 30 years building systems that matter. From telecom to AI orchestration to Chief AI Officer - pragmatic technology leadership. Stockholm, Sweden.

Personal brand site of Tomas André, a Technology Leader & AI Strategist with 30 years of experience based in Stockholm, Sweden. Tomas runs three ventures: Mindtastic (AI training for senior developers and organizations), T1K (AI-first delivery framework), and Dolutions (data analytics). The site features insights on AI-assisted development, voice-to-text pipelines, and production-first thinking.

## Pages

- [Home](https://tomasandre.se/): Landing page with overview, stats, and featured insights
- [Insights](https://tomasandre.se/insights): All published articles and insights
- [About](https://tomasandre.se/about): About Tomas Andre - 30 years of technology leadership, from founding tech companies to pioneering AI-assisted development.
- [Expertise](https://tomasandre.se/expertise): Services and areas of expertise - AI training, technology strategy, and system delivery by Tomas Andre.
- [Contact](https://tomasandre.se/contact): Get in touch with Tomas Andre for AI training, technology strategy, or speaking engagements.
- [AI Training for Developers](https://tomasandre.se/ai-training): Hands-on AI-assisted development training for senior developers. Learn practical AI orchestration with your own code. 30 years experience.
- [Technology Strategy Consulting](https://tomasandre.se/strategy): Strategic AI consulting and technology leadership. From pilot to production - where 87% fail, we ship. 30 years experience.
- [Speaking & Advisory](https://tomasandre.se/speaking): Keynote speaking and board-level advisory on AI transformation. Anti-hype perspective grounded in 30 years of hands-on technology leadership.
- [Career & Background](https://tomasandre.se/career): 30 years of technology leadership. From founding Visionutveckling to pioneering AI-assisted development. The complete journey.
- [Philosophy & Approach](https://tomasandre.se/philosophy): Anti-hype philosophy for AI and technology. What AI can't do, personal accountability, and why results matter more than promises.
- [Chief AI Officer](https://tomasandre.se/caio): What the CAIO function actually means — and why it is decisive for organizations that want to genuinely own their AI transformation.

## Insights (Articles)

### [Planen innan ni lämnar rummet](https://tomasandre.se/insights/planen-innan-ni-lamnar-rummet)

After three years, strategy days and leadership meetings still don't use AI -- not because the tech is hard, but because you get stuck on the wrong question. On getting your own conversation in, keeping the human in the loop, and leaving the room with the action plan instead of a feeling.

# Planen innan ni lämnar rummet

Tekniken har funnits i över tre år. Alla har den i Teams. Och ändå: strategidagar, ledningsgruppsmöten, planeringsmöten. Ni sitter kvar efteråt och bygger planen för hand i PowerPoint, från minnet, precis som för fem år sedan.

Det gör mig upprörd, ärligt talat. Inte för att tekniken är svår. För att den enkla saken inte görs.

## Ni fastnar på fel fråga

Varje gång någon testar att spela in ett möte blir samtalet detsamma. Transkriptionen är inte helt korrekt. Det blev ett syftningsfel. Vilken modell är egentligen bäst. Efter tre år med det här vet jag att allt det är sekundärt.

Det viktiga är att få in er egen content. Samtalet, tillsammans med anteckningarna, med agendan, med planen ni redan skissat. Det är kontexten som gör allt. Prompten är den lilla delen. Och den mesta energin läggs på precis det som spelar minst roll.

## Den enkla saken

Kasta in samtalet, anteckningarna och agendan i samma fråga. Claude, ChatGPT, det spelar mindre roll -- men en betaltjänst. Gratisversionen ger er en avkortad summering. Och när ni arbetar med en strategi är avkortat detsamma som värdelöst. Ni behöver tillräckligt med data ut.

Sen sitter en människa i loopen. Det första svaret är inte sanningen. Ni itererar två, tre gånger. Ni fångar nyansen som föll bort, personen som inte fick rätt uppgift. Det är en process och ni styr den. Men resultatet ligger inte i närheten av en plan ni skrev själva i efterhand, ensamma, klockan sex på kvällen.

## Varför det inte får automatiseras

Här dyker alltid tanken upp. Och den kommer snabbt: kan vi inte automatisera det här? Bygga ett flöde som spelar in, transkriberar och lägger fram planen av sig själv?

Nej. Och det är värt att säga tydligt varför, för det är ingen teknisk invändning.

Det finns ingen intelligens i modellen som väger just er situation. Det är en prediktion av vad andra formulerat förut. Den vet inte vilken av era avdelningar som redan är överbelastad, att personen som fick huvudansvaret slutar om en månad, att förra årets plan föll på exakt den punkt ni är på väg att upprepa. Den kan inte veta det ni inte skrev in. Och den bryr sig inte om vad slutsatsen tillhör.

Därför är människan i loopen inte en kvalitetskontroll man lägger till på slutet. Den ÄR arbetet. Det är i iterationen -- när ni läser första utkastet och säger att nej, det där blev fel, det var inte så vi menade -- som planen faktiskt blir er. Automatiserar ni bort det steget har ni automatiserat bort värdet och behållit transkriptionen, som var den del som betydde minst.

En strategiplan ni lagt en heldag på är för viktig för att lämnas till ett tredjepartsflöde som ingen äger. Poängen är inte att spara bort mötet. Poängen är att flytta mötesdiskussionen till en handlingsplan. Och den förflyttningen är mänsklig.

Fråga den heller aldrig ja eller nej. Ett prediktionssystem ska strukturera ert arbete, inte fatta ert beslut.

## Gör det innan ni går hem

Det bästa läget är sista passet. Ni har haft er dag, ni har diskuterat, whiteboarden är full. Innan ni bryter: tryck på knappen, skicka in dagen, lägg upp resultatet på skärmen. Dela det. Reflektera tillsammans. Justera direkt medan alla är kvar och minns vad som sades.

Då går ingen därifrån med känslan av ett bra möte och inget mer. Alla går därifrån med dagens handlingsplan. I morgon börjar ni arbeta i stället för att sammanfatta.

Skillnaden mellan de två är ett knapptryck och en människa som orkar iterera. Att så få tar den skillnaden är det enda svåra i hela saken.

---

*Se även: [Ge mig insikter, inte beslutet](/insights/ge-mig-insikter-inte-beslutet) (serie 34) och [Det är I:et i AI som gör det](/insights/det-ar-i-et-i-ai-som-gor-det) (serie 39).*

### [Det är I:et i AI som gör det](https://tomasandre.se/insights/det-ar-i-et-i-ai-som-gor-det)

We call it intelligence, and the word makes us attribute understanding and consciousness the technology doesn't have. The superlatives do the rest. On why the language becomes part of the product -- and why that is a question of accountability.

# Det är I:et i AI som gör det

Det fanns en visa i barndomens tv, hos Magnus, Brasse och Eva, där hela poängen var att en enda bokstav bestämde hur vi uppfattade ett ord. Det är O:na i orden som gör det. Byt ut en bokstav och betydelsen skiftar under fötterna på dig.

Jag har tänkt att det är ungefär så med AI. Det är I:et som gör det.

Det är ordet intelligens som får oss att tillskriva dagens teknik egenskaper den inte har. När någon säger artificiell intelligens hör de flesta förståelse, resonemang, insikt, kanske avsikt, kanske något som liknar medvetande. Ordet drar med sig allt det där gratis, innan tekniken har visat en enda sak.

## Ett ord som lovar mer än det håller

Dagens generativa modeller är i grunden statistik. De predikterar nästa ord, nästa pixel, nästa steg utifrån enorma mängder träningsdata. Resultatet kan vara imponerande utan att systemet förstår någonting i den mening du och jag lägger i ordet förstå.

Det är inte en nedvärdering. Det är en beskrivning. En modell som gissar rätt ord tillräckligt ofta blir ett oerhört användbart verktyg. Men den vet inte vad den säger. Och framför allt inte vad du glömde fråga. Modellen löser det du ber om. Den har ingen uppfattning om det du inte tog med. Kalla den intelligent och du slutar tänka på just den gränsen.

## Superlativerna gör resten

Det är inte bara ett ord. Marknadsföringen lägger på resten.

Varje ny modell är revolutionerande, banbrytande, mänsklig, agentisk, resonerande, världsledande. Superlativerna flyttar blicken från vad tekniken faktiskt gör till vad vi hoppas att den ska vara. Efter tillräckligt många av dem bedömer man inte längre en produkt. Man förhåller sig till ett löfte.

Douglas Adams skrev om det innan tekniken fanns. I hans värld säljer Sirius Cybernetics Corporation sina robotar med Genuine People Personalities, äkta mänskliga personligheter. Berättelsen är så övertygande att den blir en del av produkten. Man köper inte längre en dörr, man köper en dörr som är genuint glad över att få öppna sig för dig. Språket är varan.

Vi är på väg åt samma håll. Orden formar förväntningarna innan tekniken har demonstrerat sina faktiska egenskaper. Sedan mäter vi tekniken mot förväntningarna i stället för tvärtom.

## Vi läser in det utifrån utfallet

Det blir tydligast i hur vi dömer. Bra svar, då är den intelligent. Dåligt svar, då är den dum.

I båda fallen gör vi samma sak. Vi behandlar en prediktionsmaskin som en tänkande aktör. Vi antropomorfiserar den. Uppåt när den imponerar, nedåt när den missar. Och vi lägger ett omdöme på maskinen som hör hemma hos oss. Den var varken klok eller dum. Den gissade. Vi tolkade gissningen som en karaktär.

## Byt ut ordet, så faller förväntningen

Gör tankeexperimentet. Anta att tekniken från början hade hetat något annat. Artificiell prediktion. Avancerad statistisk modell. Probabilistisk språkmotor.

Betydligt färre hade väntat sig förståelse eller medvetande. Ingen frågar om sin väderprognos är medveten, fast den gör i princip samma sak: bearbetar data och predikterar. Det var aldrig tekniken som bar de mänskliga förväntningarna. Det var ordet.

## Nyansen som inte får bli en ursäkt

Det finns ingen färdig definition av intelligens och det är därför debatten blir rörig. Definierar man det funktionellt, som förmågan att lösa problem och nå mål, kan man säga att dagens AI uppvisar vissa former av intelligens. Kräver man förståelse, medvetande, en subjektiv upplevelse, är den inte intelligent i mänsklig mening. Samma ord, olika saker. Och två kunniga personer kan gräla i en timme utan att inse att de aldrig pratade om samma sak.

Men den nyansen får inte bli en flykt. För hur du ska arbeta spelar det ingen roll vilken definition som vinner. Oavsett vilken du väljer landar du på samma plats: systemet producerar ett utfall och någon måste avgöra om utfallet håller. Den någon är du.

## Varför det här är en ansvarsfråga

Det är här jag inte stannar vid en språkobservation, för ordet gör något med hur vi tar ansvar.

Tror du att något är intelligent, litar du på det. Du lutar dig tillbaka. Du låter svaret passera för att det lät klokt. Vet du att det är inferens, prediktion, statistisk generalisering, då validerar du. Du läser varje rad, för du vet att ingen förstod den innan du gjorde det.

Ordet intelligens är alltså inte bara ett marknadsföringsproblem. Det är en inbjudan att lämna ifrån sig precis den del du inte kan delegera. Illusionen att maskinen förstår är exakt det som får en människa att sluta bära sitt eget omdöme. Och omdömet var hela jobbet.

Det är I:et i AI som gör det. Och kanske också superlativerna.

Fast egentligen är det tvärtom. I:et är det enda som inte gör något. Arbetet sköts av inferens, prediktion och statistisk generalisering. Intelligensen är bara ordet vi målar ovanpå. Det enda den uträttar är att få oss att sänka garden. Låt den inte få dig att se ett medvetande där det bara finns ett verktyg du fortfarande ansvarar för.

---

*Se även: [Samma ord, olika saker](/insights/samma-ord-olika-saker) (serie 30) och [Jag är smartare än AI:n](/insights/jag-ar-smartare-an-ai) (serie 1).*

### [Adoptionen var det riktiga projektet](https://tomasandre.se/insights/adoptionen-var-det-riktiga-projektet)

We built a carrier-grade calling system with a fraction of the team. The hard part was never getting AI to write code -- it was getting experienced people to change how they work. And that needs a mandate.

# Adoptionen var det riktiga projektet

Den här veckan lanserade Sonetel en ny mobilapp. Carrier-grade samtal över två plattformar -- den typ av system som en konservativ uppskattning säger tar fyra eller fem ingenjörer ett drygt år att bygga om. Vi gjorde det med en eller två personer som styrde AI. Den skillnaden är hela poängen. Men det är inte där lärdomen ligger.

Den enkla slutsatsen vore att det svåra var att få AI att skriva mjukvara. Det var det aldrig. AI skriver kod hela dagarna. Det svåra var något helt annat, och det hade ingenting med kod att göra.

## Det riktiga problemet

Det riktiga problemet var att få erfarna människor att ändra hur de arbetar -- ovanpå system och vanor byggda under många år. Att låta AI sköta utförandet, inte bara assistera, och samtidigt behålla omdömet.

Ett team som drivit en telefoniplattform i över tio år byter inte arbetssätt för att ett verktyg är smart. Mogna, beprövade system och de människor som kan dem utan och innan ändrar inte vanor på en demonstration. De har sett verktyg komma och gå. De vet vad som faktiskt går sönder klockan tre på natten, och de vet att den kunskapen inte sitter i en modell.

Det är inte ett tekniskt motstånd. Det är ett rimligt motstånd. Och det är det motståndet, inte koden, som avgör om en transformation blir verklig eller stannar vid en pilot som alla berömmer och ingen använder.

## Det sprids inte underifrån

Här är det de flesta underskattar. Adoption sprids inte nedifrån och upp.

Ett team byter arbetssätt av två skäl, och båda måste vara på plats samtidigt. Det första är att det är betrott uppifrån -- att de som bär risken har sagt att det här är vägen, inte ett sidoprojekt någon entusiast driver på egen hand. Det andra är att det synligt får deras eget omdöme att räcka längre. En veteran adopterar inte ett verktyg som hotar att ersätta honom. Han adopterar ett verktyg som tar hans hårt vunna instinkt -- hur det här systemet faktiskt fallerar -- och tillämpar den på varje samtal, så att kunskapen slutar vara inlåst i en enda persons huvud.

Saknas det första blir det andra aldrig prövat. Utan mandat kan AI-frågan alltid pareras: vi tar det sedan, vi tar det med någon annan, vi tar det när vi hinner. Och då händer ingenting.

## Mandatet var förutsättningen

Vårt hade ett. De som bär den yttersta risken för bolaget backade ett genuint nytt och oprövat arbetssätt innan det var uppenbart att det skulle löna sig -- vid den punkt där nej hade varit det säkra svaret. De bar risken så att resten av oss kunde göra jobbet.

Det är inte en fotnot i den här historien. Det är förutsättningen för allt annat i den. Utan det mandatet bygger ingen om ett carrier-grade system med en bråkdel av teamet, för ingen får ens börja på riktigt.

Det är precis det mönster jag skrivit om tidigare: transformation lyckas nästan uteslutande när den ägs av någon med reellt mandat i toppen. Skillnaden den här gången är att jag inte rapporterade om det utifrån. Jag satt i rummet och bar det.

## Vad det egentligen handlar om

AI ersatte inte ingenjörerna. Det kortade avståndet mellan en fråga och ett ärligt svar -- vad gör den här koden egentligen, var dog det här samtalet, är den här planen verklig. Det flyttade den svåra delen uppåt i stacken, från att skriva till att bedöma. Och bedömningen är fortfarande vår att bära.

AI utför. Människor avgör vad som är bra nog. Det lärde vi oss inte på en workshop. Vi lärde oss det genom att skeppa en riktig produkt, den svåra vägen, tillsammans.

Verktygen var den enkla delen. Adoptionen var den svåra -- och den var det riktiga projektet.

*Se även: [Ledaren som inte kan delegera](/insights/ledaren-som-inte-kan-delegera) (serie 21) och [Det var aldrig en teknikfråga](/insights/det-var-aldrig-en-teknikfraga) (serie 10).*

*Hela långversionen av den här historien finns på LinkedIn: [We shipped a year of work to the App Store this week](https://www.linkedin.com/pulse/we-shipped-year-work-app-store-week-here-how-ai-actually-tomas-andr%C3%A9-zwmme/).*

### [Ge mig insikter, inte beslutet](https://tomasandre.se/insights/ge-mig-insikter-inte-beslutet)

You don't buy governance by buying licenses. On why the gathering can be automated but the decision cannot -- and what a CAIO actually owns when AI costs run away.

# Ge mig insikter, inte beslutet

Jag pratar med en del organisationer om AI just nu, och det finns en panik som återkommer. Budgeten är spräckt, och ingen kan säga varför. Det fanns en satt siffra, den utgick från att kanske trettio procent skulle nyttja verktygen på allvar och resten inte alls, och så sprängdes den med råge.

Jag brukar fråga vad de tror att det beror på. Och då börjar det komma. De vet inte vem som nyttjar vad. De vet inte om det används i arbetet eller privat. Prismodellen hos leverantörerna rör på sig. Någon ville ha tjugodollarslicensen, någon annan tryckte på för tvåhundradollarsnivån, och ingen styr det, det bara sker. På ett bolag med tusentals anställda finns det inget rimligt sätt att attribuera kostnaden mot en satt budget.

Det som hände var att man köpte licenser och kallade det transformation. C-nivån sa att alla ska ha licenser, så driver vi AI-utvecklingen. Men du köper inte styrning genom att köpa licenser. Du kan inte styra det du inte ser.

## Vad jag faktiskt byggde

Så jag byggde mätningen själv. Jag klonar alla repon lokalt och tittar på det som faktiskt går att mäta. Commits per utvecklare den senaste månaden. Rader in och ut. Spend per person mot API:et. Det blir en översikt: vem har tryckt in trehundra rader, vem har tryckt in tiotusen, vem ligger på ett par hundra dollar i förbrukning den senaste veckan.

Den biten är deterministisk. Det är programmatiskt. Det finns inget omdöme i att samla in det, och därför automatiserar jag det utan att blinka.

## Var gränsen går

Men sen kommer frågan jag väntar på. Kan jag få den automatiserade rapporten? Den där modellen inte bara samlar in utan också drar slutsatsen och säger vad jag borde göra.

Då går jag nästan ut ur rummet.

Att samla in är en sak. Att besluta är en annan. Jag agerar inte på en slutsats jag inte kan validera, och modellen är inte tillräckligt bra för att jag ska vilja det. Ge mig insikterna. Lägg dem på bordet, deterministiskt insamlade. Sen tar jag beslutet.

För det är där omdömet sitter. Commits och rader är en grov signal, inget annat. En av de mest seniora jag har skriver få rader av hög komplexitet, sitter en dag och tänker och checkar in fyra rader som går rakt i produktion. Trehundra rader från någon annan kan betyda att de aldrig ens var inne och jobbade. Siffran pekar. Den beslutar inte.

## Det enda jag inte kan delegera

En språkmodell löser det du ber om. Den kan inte tala om för dig vad siffran betyder för just den här organisationen, den här personen, den här månaden. Den meningen är beslutet. Och beslutet är det jag ansvarar för.

Automatiserar du beslutet har du automatiserat bort just det du var satt att äga.

Rapporten är den enkla delen. Omdömet ovanpå den är jobbet. Det är därför det ligger hos en människa, och stannar där.

---

*Se även: [Jag är smartare än AI:n](/insights/jag-ar-smartare-an-ai) (serie 1) och [Kontrollpunkten är jobbet](/insights/kontrollpunkten-ar-jobbet).*

### [Vad hade hänt om vi spelat in det här?](https://tomasandre.se/insights/vad-hade-hant-om-vi-spelat-in)

I sat in a café and talked for fifteen minutes about a concrete problem and a solution. We both know the pipeline. And neither of us hit record. On the gap between knowing and doing.

# Vad hade hänt om vi spelat in det här?

Jag satt i ett kafé häromdagen och pratade med någon i en kvart. Ett konkret problem, en idé om hur det skulle lösas, ett par turer fram och tillbaka. Ett bra samtal. Vi kan båda pipelinen utan och innan -- spela in, transkribera, mata in i en modell, och du har en kravbild, de nästa frågorna att ställa, början på en affär.

Och ingen av oss tryckte på inspelning.

## Vad som faktiskt fanns på bordet

Det slog mig först efteråt. Hade vi spelat in de där femton minuterna vore arbetet redan halvgjort. Transkriptet mot kundens underlag hade gett själva use caset. Fem sokratiska följdfrågor hade legat och väntat på nästa steg. I stället är det borta, och jag sitter och rekonstruerar det ur minnet, som vanligt, sämre än om jag haft råmaterialet.

Det var inte ett tekniskt problem. Det var inte att vi inte visste hur. Det var att vi inte gjorde det.

## Gapet som inte är ett kunskapsgap

Det här är den obekväma delen av allt jag skriver om röst. Jag har skrivit i åratal att röst är det outnyttjade ingångslagret, att ett kvartssamtal bär mer än ett formulär, att det enda jobbet är att fånga och styra. Och så sitter jag själv i ett kafé och låter ett av de bättre samtalen den veckan rinna ut i sanden.

Gapet är inte förmåga. Vi kan det. Gapet är vanan. Att veta att röst är ingångslagret och att faktiskt trycka på knappen är två olika saker, och det är den andra som betalar.

## Det som varit redo länge

Tekniken har varit redo i åratal. Det var aldrig den som var hindret. Whisper dög för det här långt innan modellerna blev det de är nu.

Det enda som inte varit redo är vanan att trycka på inspelning innan samtalet börjar i stället för att inse värdet när det är slut. Och vanan är det enda som räknas.

---

*Se även: [Allt jag säger hamnar i text](/insights/allt-jag-sager-hamnar-i-text) (serie 2) och [Tre kanaler, ett ställe](/insights/tre-kanaler-ett-stalle).*

### [Bygget blev gratis. Flaskhalsen flyttade.](https://tomasandre.se/insights/bygget-blev-gratis-flaskhalsen-flyttade)

Everyone reacts to the speed now -- an app in a day. But building got cheap for everyone, so it stops being what decides. The hard part didn't disappear. It moved -- to people, and to productization.

# Bygget blev gratis. Flaskhalsen flyttade.

Det alla reagerar på just nu är hastigheten. Titta, en app på en dag. En prototyp på en eftermiddag. En idé som är i produktion innan veckan är slut. Och det är sant. Bygget blev gratis.

Men det är den minst intressanta delen, för det blev gratis för alla. När det inte kostar något att bygga slutar förmågan att bygga vara en vallgrav. Den är insatsen för att få vara med, inte det som avgör vem som vinner.

Så det svåra försvann inte. Det flyttade. Och det flyttade till två ställen.

## Det första: människor

Att få en organisation att faktiskt använda det här, att ändra hur den arbetar, går långsamt på ett sätt som tekniken inte gör. Tekniken är snabb. Människor är det inte. Ungefär hälften tar till sig det, ungefär hälften gör det inte, och skillnaden styrs av inställning, inte av verktyg.

Bygget tar en dag. Adoptionen tar arton månader. Och det är adoptionen som avgör om något av det blir värt något.

## Det andra: produktifiering

Avståndet mellan "det funkar i min Claude" och något som riktiga användare kan lita på är nästan hela ingenjörsarbetet. Och det är osynligt så länge du sitter inne i verktyget som gör hälften åt dig. Du känner dig färdig långt innan du är det.

Att bygga prototypen blev gratis. Att göra den till en produkt någon annan än du kan luta sig mot gjorde det inte.

## Det som inte blev gratis

Fällan är att låta sig imponeras av bygget. Bygget är insatsen nu. Vallgraven är det som inte blev gratis: omdömet, valideringen, att få människor att ändra sig, och det oglamorösa arbetet att få något att hålla för någon som inte är du.

När bygget är gratis är det inte bygget som avgör. Det är allt det andra.

---

*Se även: [Det funkar i din Claude](/insights/det-funkar-i-din-claude) (Leverans) och [Det imponerande och det fakturerbara](/insights/det-imponerande-och-det-fakturerbara).*

*Mindtastic om människodelen i praktiken -- [AI-transformationen flyttar människor](https://mindtastic.se/articles/ai-transformation-moves-people).*

### [Tangenttrycket är inte måttet](https://tomasandre.se/insights/tangenttrycket-ar-inte-mattet)

We ranked developers by how fast they produced. AI pours out the code now, so the keystroke is a measure that has lost its meaning -- and left the thinking exposed.

# Tangenttrycket är inte måttet

Det fanns ett halvt skämt om ett mått en gång. CPM. Tecken per minut. Hur fort du skrev. Ingen satte det på papper, men vi rankade ändå utvecklare lite efter throughput -- hur snabbt de producerade, hur mycket de fick ur sig.

Nu dånar AI ut koden. Och då blir det plötsligt synligt hur meningslöst det måttet alltid var. Det spelar ingen roll om du skriver trettio tecken i minuten eller hundratjugo. Modellen skriver det. Tangentbordet är inte längre flaskhalsen, och därmed inte heller måttet.

## Vad som återstår att mäta

Om inte produktionstakten, vad då?

Frågan. Riktningen. Den sokratiska knuffen som får modellen att gå åt rätt håll. Och framför allt: förmågan att titta på det som kom ut och veta om det är rätt. En senior som ställer den vassa frågan och validerar resultatet är i en helt annan klass än någon som bara matar verktyget och hoppas. Skrivandet var aldrig poängen. Nu är det bara uppenbart att det inte var det.

## Fällan vi inte släppt

Trots det mäter vi fortfarande halvt om halvt i volym. Rader. Commits. Jag har skrivit om hur lätt det är att luras av det, och jag kan ändå ertappa mig själv med att läsa en lista och tänka att den som tryckte in mest gjorde mest.

Men en av de mest seniora jag känner sitter en dag och tänker, checkar in fyra rader och går rakt i produktion. Throughput är ett fåfängemått. Det mäter rörelse, inte värde.

## Det proxyn dolde

Tangenttrycket var alltid en proxy för tänkande. Vi mätte fingrarna för att vi inte kunde mäta omdömet. AI tog bort fingrarnas betydelse och lämnade omdömet bart, utan något att gömma sig bakom.

Det är obekvämt för den som använde skrivandet som bevis på att man jobbade. Och det är goda nyheter för den som alltid hade omdömet men aldrig de snabbaste fingrarna.

---

*Se även: [Mitt jobb är frågorna](/insights/mitt-jobb-ar-fragorna) och [Ge mig insikter, inte beslutet](/insights/ge-mig-insikter-inte-beslutet) (serie 34).*

### [Det funkar i din Claude](https://tomasandre.se/insights/det-funkar-i-din-claude)

You build something genuinely good in your Claude and think you're almost done. But the client is doing more for you than you realise -- and the distance to a product is nearly all the work that's left.

# Det funkar i din Claude

Du bygger något riktigt bra inne i din Claude. Den läser dina filer, skriver utkastet till mejlet, öppnar det på skärmen, kommer ihåg din kontext, väljer rätt modell, anropar dina verktyg. Det känns som en produkt. Och du tänker det som alla tänker i det läget: det här skeppar jag bara, eller ger till en kollega, eller gör till en app.

Sedan försöker du, och upptäcker hur mycket klienten gjorde åt dig.

## Dopningen

Det går att vara väldigt produktiv inne i en desktop- eller kodklient utan att märka hur mycket den bär. Den hanterar kontexten åt dig. Den kopplar ihop dina verktyg via MCP. Den väljer modell. Den kan trigga saker på din dator -- öppna en mapp, lägga ett mejlutkast i din vanliga klient. Inne i den känner du dig som ett geni.

Det är dopningen. Och som med all dopning ser du den inte förrän den tas bort.

I det ögonblick du kliver utanför klienten -- en webbapp, ett API, något en icke-teknisk kollega ska kunna köra -- är allt det där borta. Och du får bygga det deterministiskt själv.

## Exemplet som avslöjar det

Ta mejlutkastet som dyker upp på skärmen. Det känns som kärnfunktionen i det du byggt. Men det fungerar bara för att desktop-klienten styr din dator och kan be operativsystemet öppna ett utkast. En webbapp kan inte trigga det. Funktionen som kändes som din var klientens.

Samma sak med skills, de återanvändbara instruktionerna som får hela din uppsättning att sjunga. Du kan inte bara exponera dem via ett API. De lever i leverantörens desktop och backend. Det finns server-side-varianter, men de är en bråkdel av det du gör lokalt.

Mönstret upprepar sig: det som fick din lösning att kännas färdig var i stor utsträckning saker klienten gav dig gratis, och som inte följer med ut.

## Avståndet du inte ser

Det som ser skeppbart ut i din egen Claude är en demo i en produkts kläder. Avståndet från "funkar för mig, här" till "funkar för vem som helst, där" är nästan hela ingenjörsarbetet -- och det är osynligt så länge du är dopad.

Det här är inget argument mot att bygga i Claude. Det är fortfarande den bästa platsen att tänka och prototypa på. Det är ett argument mot att förväxla prototypen med produkten, och mot att offerera en tidsplan som om det svåra är gjort när det svåra inte ens har börjat.

Klienten gör mer för dig än du tror. Att veta exakt vad den gör -- och vad du skulle behöva återskapa utan den -- är skillnaden mellan en demo som imponerar och en produkt som skeppar.

---

*Se även: [Det imponerande och det fakturerbara](/insights/det-imponerande-och-det-fakturerbara) (Leverans).*

*Mindtastic om skills över ytor och deras gränser -- [Skills as Governance](https://mindtastic.se/guides/skills-git-distribution).*

### [Teknikskulden du kan prata bort](https://tomasandre.se/insights/teknikskulden-du-kan-prata-bort)

The most valuable thing about an old system lives in the head of whoever has lived with it, not in the repo. On turning the voice pipeline backwards -- and talking away tech debt without rewriting a line.

# Teknikskulden du kan prata bort

En av utvecklarna jag pratade med nyligen hade suttit i samma kodbas i flera år. Den typen av system som ingen vågar röra. Det fungerar, det fakturerar, och dokumentationen är antingen inaktuell eller obefintlig. Alla på företaget behandlar det som en svart låda med en lapp på: rör inte.

Jag bad honom göra något som kändes fel för honom. Starta en inspelning och bara prata. Inte skriva. Inte dokumentera. Berätta för mig, högt, vad koden gör. Var den krånglar. Vad han alltid kollar innan han ändrar något. Vilket antagande som ligger begravt i en funktion som ingen längre minns varför den ser ut som den gör.

Det är ovant för en utvecklare att prata om sin kod. Vi är vana att skriva den, inte berätta om den. Men efter någon minut släppte det.

## Vad som faktiskt händer

Den inspelningen är inte en dikteringsövning. Den är råmaterial.

Du tar transkriptet och kör det mot kodbasen. Och då börjar det intressanta. AI:n hittar diffarna, skillnaderna mellan vad han sa att koden gör och vad den faktiskt gör. Den hittar dokumentationsluckorna, för nu finns det äntligen en beskrivning att jämföra koden mot. Den hittar antagandena han uttalade i förbifarten, de som aldrig stod någonstans men som hela systemet vilar på.

Du har inte skrivit om en rad. Du har inte byggt något nytt. Men du har precis flyttat en betydande del av teknikskulden från ingen-vet till någon-vet. Min erfarenhet är att man kan putta bort en femtedel bara genom att använda AI i de gamla processerna, inte bara i det nya bygget.

## Varför det fungerar

Kunskapen om ett gammalt system finns sällan i repot. Den finns i huvudet på den som levt med det. Felsökningarna klockan tre på natten, gångerna det small, de tysta reglerna om vad man inte gör. Inget av det är incheckat någonstans.

En språkmodell kan bara arbeta med det som ligger i kontextfönstret. Och det enda en legacy-kodbas saknar är just det utvecklaren bär omkring på. Rösten är det enda praktiska sättet att få ut det. Tio minuters tal rymmer mer av den verkliga modellen av systemet än vad någon orkar skriva ner på en vecka.

Och en sak till, som är hela poängen. Utvecklaren förblir den som äger vad som är sant. AI:n strukturerar det han sa och pekar på var det skaver mot koden. Men det är han som avgör vad som faktiskt stämmer. Det är inte en automatisering som ersätter hans omdöme. Det är en som förstärker det.

## Det är inte ett nytt verktyg

Det här är det tråkigaste use caset jag känner till. Ingen genererad video, ingen agent som gör tjugo saker samtidigt. En utvecklare som pratar om gammal kod. Det är brunt och oglamoröst, och det är förmodligen därför ingen pratar om det.

Det är inte heller nytt. Det gick att göra med transkribering för flera år sedan. Tekniken har aldrig varit hindret. Hindret har varit att någon ska komma på att vända röstpipelinen mot det gamla i stället för mot det nya.

## Positionen står öppen

Alla bygger framåt med AI. Greenfield, nya funktioner, snabba prototyper. Få vänder verktyget bakåt, mot de system som faktiskt bär verksamheten och som ingen vågar dokumentera.

Det är där den största skulden ligger. Och det är den som går att prata bort.

---

*Se även: [Allt jag säger hamnar i text](/insights/allt-jag-sager-hamnar-i-text) (serie 2) och [Kladdigt och krispigt](/insights/kladdigt-och-krispigt) (serie 14).*

*Mindtastic om greenfield kontra legacy i produktion -- [Production Reality Gap](https://mindtastic.se/articles/production-reality-gap-part1).*

### [Ersätter eller monterar](https://tomasandre.se/insights/ersatter-eller-monterar)

A voice in my feed said: don't automate the human things. He is right, but the line runs deeper. The question isn't human versus machine. It is whether the orchestration replaces something you already carry, or assembles something missing from the room.

# Ersätter eller monterar

En röst i mitt flöde häromdagen tog i ordentligt mot AI-experterna som vill automatisera det mänskliga. Svara på dina egna mejl. Höra av dig själv till någon du vill jobba med. Sitta med barnen vid läxorna. Poängen: automatiserar du det där har du inte effektiviserat något, du har raderat det enda som betydde något.

Hen har rätt. Men stannar ett steg för tidigt.

## Det är inte mänskligt mot maskinellt

Gränsen går inte mellan det mänskliga och det maskinella. Den går någon annanstans, och jag snubblade över den i ett samtal samma vecka.

Någon ville att alla skulle bygga team av agenter. En QA-agent, en frontend-agent, en panel av personas att testa idéer mot, till och med en liten styrelse av perspektiv att fatta beslut med. Smart, på pappret. AI kan hålla många perspektiv samtidigt.

Jag märkte mitt eget motstånd direkt.

## Varför jag inte bygger en AI-styrelse

För mina egna beslut vill jag inte ha den uppställningen. En simulerad kommitté ersätter just det jag bär med mig: ett omdöme byggt av konsekvenser, av att ha haft fel och fått betala för det. Jag ställer hellre en skarp fråga, får fem svar, och väger dem själv. Jag behöver inte att de fem rösterna låtsas vara en styrelse. Jag är styrelsen.

Och så fort en sådan uppställning får löpa själv glider den mot automation. En rapport jag inte bad om, ett beslut taget innan jag hann titta. Då har jag tappat det enda jag inte får tappa: greppet om vad som faktiskt bestäms.

## Sedan kommer vändningen

Här är det som gör frågan värd att ställa. Samma uppställning som är överflödig för mig är precis rätt för en organisation.

Helheten jag bär i ett huvud finns sällan i ett huvud därute. Den ligger utspridd. En person kan tekniken, en annan kunden, en tredje juridiken, en fjärde det som aldrig sägs på mötena. Och de pratar inte med varandra. Inte för att de inte vill, utan för att ingen struktur tvingar fram det.

Där ersätter orkestreringen inget omdöme. Den monterar ihop en vy som ingen enskild person i rummet håller. Den gör det utspridda samtidigt. Samma verktyg, motsatt värde, beroende på vem som håller i det.

## Den enda frågan som spelar roll

Frågan är alltså inte "ska du orkestrera agenter?" Den frågan leder ingenstans, för svaret är alltid "det beror på".

Frågan är: ersätter det något du redan bär, eller monterar det ihop något som saknas i rummet?

Ersätter det något som redan finns och redan fungerar, då är det ett löftesbrott. Precis det rösten i flödet syftade på. Monterar det ihop något som annars aldrig blir helt, då är det inte ett löftesbrott. Då är det det enda vettiga.

## Och därför är leverans något annat

Det är också därför AI i teknisk leverans inte är ett löftesbrott. Där ersätter den inte mitt ägarskap, den förstärker min kapacitet. Jag står fortfarande för varje rad. Det är metodik, inte en genväg förbi ansvaret.

Distinktionen är hela spelet. Inte mänskligt mot maskinellt, utan om verktyget ersätter något du redan bär eller monterar ihop något som saknas.

---

*Se även: [Jag är smartare än AI](/insights/jag-ar-smartare-an-ai) (serie 1) och [Automation före agenter](/insights/automation-fore-agenter) (serie 31)*

### [Automation före agenter](https://tomasandre.se/insights/automation-fore-agenter)

Most people don't trust a free-running AI agent -- they can't control what it does. The ones who win build it the other way around: stable, verifiable steps that an agent is allowed to start on command. Autonomy where it's safe, control where it counts.

# Automation före agenter

En klok formulering jag hörde nyligen, från någon som byggt mer av det här än de flesta: börja inte med agenten. Börja med automationen.

Jag har tänkt på den sedan dess, för den pekar på något jag sett gång på gång ute hos kunder utan att kunna sätta ord på det.

## Varför folk inte litar på agenter

De flesta människor litar inte på en fristående AI-agent. Inte för att de är bakåtsträvande. För att de inte kan kontrollera den.

De ser inte vad den gör steg för steg. De kan inte verifiera resultatet innan det är gjort. De vet inte om den hittade på halva vägen. Och de bär ändå ansvaret för vad som kommer ut. Det är inte teknikrädsla. Det är ett rimligt krav på kontroll från någon som ska stå för resultatet.

Ge en sådan person en agent som kör själv, och du har inte gett dem ett verktyg. Du har gett dem en risk de inte kan bedöma.

## Den omvända ordningen

Vänd på det. Bygg först det stabila steget -- en process som gör en väl avgränsad sak, samma sätt varje gång, och som går att verifiera. Hårdkodad om det behövs. Tråkig med flit. Den ska vara förutsägbar, inte smart.

Och låt sedan en agent få starta den. Inte improvisera fram den. Starta den.

Nu har du autonomin där den är ofarlig -- i valet av när och vad -- och kontrollen där den räknas -- i själva utförandet. Agenten fattar beslutet att köra. Maskinen gör jobbet, likadant varje gång.

Har du hundra sådana steg har du byggt något kraftfullt utan att någonsin be en människa att lita på något hen inte kan kontrollera.

## Det här är inte en kontrariansk åsikt

Det låter som en försiktig hållning i en bransch som hyllar autonomi. Det är det inte. Det är i linje med hur de mer eftertänksamma leverantörerna ritar gränsen: skilj på det förutbestämda flödet och den fria, självstyrande agenten. Använd det fria sparsamt, där det tål att gå fel.

Det provocerande är inte slutsatsen. Det provocerande är hur många som hoppar över den, bygger det imponerande autonoma först, och sedan undrar varför ingen i organisationen vågar använda det.

Kontroll är inte motsatsen till AI. Kontroll är vad som gör att någon vågar släppa in AI över huvud taget.

---

*Se även: [Det är inte farten som dödar](/insights/det-ar-inte-farten-som-dodar) (serie 26) och [Förtroendet kommer före tekniken](/insights/fortroendet-kommer-fore-tekniken) (serie 27)*

### [Samma ord, olika saker](https://tomasandre.se/insights/samma-ord-olika-saker)

Three people can deeply disagree about AI and all be right -- because they mean different things by the same words. Skill, agent, automation. Most of what sounds like a method dispute is really a dispute about words.

# Samma ord, olika saker

Jag satt i ett samtal där tre personer var oense om AI. Det tog en stund innan jag insåg att de inte var oense. De använde samma ord om olika saker och trodde att de bråkade om metod.

De bråkade om ord.

## Tre ord som inte betyder en sak

Säg "skill". För en person är det en mapp på hens dator som ett lokalt verktyg läser. För en annan är det något man laddar upp och anropar programmatiskt. För en tredje är det en självgenererad enhet i ett agentramverk som triggas av inkommande meddelanden.

Tre helt olika saker. Samma ord. Och de skiljer sig på precis det som spelar roll: var den bor, hur den startar, om den går att överlämna till någon annan.

Säg "agent". Nu är det värre. Det kan betyda en namngiven produkt. Det kan betyda ett arkitekturmönster -- en modell i en loop med verktyg och minne. Det kan betyda en grad av självständighet, allt från ett scriptat steg till något som agerar utan att bli tillsagt. Och det kan betyda en metafor, en "anställd på burk". Fyra register, ett ord, och de glider in i varandra mitt i en mening.

Säg "automation". För den som bygger pipelines är det en förstklassig kategori -- det stabila lagret. För den som tänker i processer är det inte ett begrepp alls, bara en process uppdelad i steg. Så "jag har noll automationer" kan betyda två rakt motsatta saker. Antingen "jag automatiserar ingenting" eller "jag tänker inte i den kategorin". Helt olika personer säger samma mening.

## Varför det inte är harmlöst

Det här är inte semantik för dess egen skull. När ett ord betyder flera saker drar man giltiga slutsatser om en betydelse och applicerar dem ogiltigt på en annan.

Ett exempel jag stötte på: "det går inte att produktifiera, det går ju bara att köra lokalt." Sant -- om man menar den ena sortens skill. Helt fel om man menar den andra, som har ett öppet gränssnitt för att triggas utifrån. Samma ord bar slutsatsen rakt över en gräns där den inte längre höll. Och då bygger man en affärsstrategi på en spärr som inte finns.

Ekvivokation, kallar logiker det. Det låter akademiskt. I praktiken ser det ut som två kunniga personer som pratar förbi varandra i en timme och går därifrån övertygade om att de är oense.

## Frågan som löser det

Innan du bestämmer om ni ska bygga agenter, eller om något går att sälja, eller om ett verktyg är en återvändsgränd -- ställ en fråga först.

Vilken sorts sak, i vilket sammanhang?

Den frågan är tråkig. Den stoppar tempot i ett rum som vill framåt. Men den är skillnaden mellan att lösa problemet och att laga fel sak med stor övertygelse.

Det mesta som låter som oenighet om vad man ska göra är oenighet om vad man pratar om.

---

*Se även: [Det imponerande och det fakturerbara är inte samma sak](/insights/det-imponerande-och-det-fakturerbara) (serie 28) och [Det var aldrig en teknikfråga](/insights/det-var-aldrig-en-teknikfraga)*

### [Det räcker inte att koda snabbare](https://tomasandre.se/insights/det-racker-inte-att-koda-snabbare)

Two shifts are happening simultaneously and both must be handled -- but one makes the other harder. And nobody talks about why.

# Det räcker inte att koda snabbare

Det sker två förflyttningar just nu. De händer parallellt. Och den ena gör den andra svårare.

## Görandet tar en ny form

AI tar i allt snabbare takt över exekveringen. Inte alltid, inte överallt, men trenden är tydlig. Kod som tidigare tog dagar skrivs på timmar. Arbetsflöden som krävde tre specialister kan driftsättas av en person med rätt metodikförståelse. Det är inte hype längre -- det är ett faktum som börjar synas i hur organisationer faktiskt bemannar och levererar.

Det förändrar vad som krävs. Rollen förflyttas från att producera varje detalj själv till att formulera problemet, styra riktningen och ta ansvar för resultatet. Flaskhalsen är inte längre exekveringen. Flaskhalsen är omdömet.

Men det skapar en dubbel kompetensförflyttning för den som tidigare bara har kodat.

## Den första förflyttningen: förstå affären

AI kan inte gissa varför ett system ska byggas. Den kan inte avgöra vilket problem som faktiskt är värt att lösa, vilken effekt som är meningsfull för kunden, eller om en elegant teknisk lösning adresserar rätt sak. Det kräver domänförståelse, konsekvenstänkande och erfarenhet av vad som faktiskt fungerar i en organisations vardag.

Den som har tillbringat åtta år med att koda lösningar som någon annan definierat saknar inte kompetens. Men den kompetensen är en annan -- och den förflyttningen tar tid.

## Den andra förflyttningen: använda AI för exekveringen

Parallellt med att förstå affären bättre behöver samma person lära sig att låta AI göra det man tidigare gjorde för hand. Det är inte en trivial förändring. Det är ett identitetsskifte. Hantverk som byggts upp under år omdefinieras. Det kräver ny metodik, nytt sätt att validera, nytt sätt att äga resultatet.

Dessa två förflyttningar händer alltså inte i sekvens. De händer på samma gång.

## Varför det är svårt på ett sätt ingen pratar om

Det finns en tredje faktor som gör det hela svårare och som sällan nämns: affärsmodellen.

För konsulter och frilansare som säljer sin tid är snabbhet aktivt kontraproduktivt. Fler fakturerbara timmar är mer intäkt. Den som är snabb med AI tjänar per definition mindre om ingenting annat förändras. Att omfamna AI utan att lösa affärsmodellen är inte rationellt -- det är ett ekonomiskt offer.

Det skapar en paradox. Timprismodellen belönar tre saker: att vara långsam, att exekvera snarare än att förstå, och att hålla sig i det man redan kan. Alla tre är exakt det som AI-eran kräver att man slutar med.

Att säga till en konsult att de "borde omfamna AI" utan att adressera den underliggande incitamentsstrukturen är inte rådgivning. Det är predikan.

## Vem springer faktiskt snabbast

Det som är intressant är vilka som rör sig snabbast just nu. Det är sällan kodaren som lärt sig förstå affären bättre.

Det är entreprenören som alltid har förstått affären, men fram till nyligen var beroende av andra för att genomföra. Personen som visste exakt vilket problem som behövde lösas, varför det var värdefullt och vad kunden egentligen betalade för -- men saknade teknisk exekveringsförmåga och var tvungen att förlita sig på mellanhänder.

Det beroendet är nu i stort sett borta.

Och det är en viktig signal. De som springer snabbast in i AI-eran är inte nödvändigtvis de som är bäst på teknik. Det är de som alltid hade svaret på "varför" -- och nu äntligen kan svara på "hur" utan att behöva fråga någon annan.

Det bekräftar i grunden vad AI faktiskt förstärker: domänkunskap. Inte teknisk fingerfärdighet.

## Vad som faktiskt krävs

Det räcker inte att bli snabbare. Det räcker inte att förstå affären. Och det räcker inte att sälja annorlunda.

Alla tre måste hända. Kompetensförflyttningen -- att förstå affären och använda AI för exekveringen -- är genuint svår och tar tid. Affärsmodellsförflyttningen -- att sluta sälja timmar och börja sälja levererat utfall och förståelse -- kräver att man omdefinierar vad man är och vad man erbjuder.

Det är ett identitetsskifte, inte ett verktygsbyte.

Den som klarar det har en position som inte konkurreras bort av nästa modellversion. Den som bara kodar snabbare har inte löst problemet. Den har bara förkortat den tid det tar.

---

*Se även: [Det imponerande och det fakturerbara är inte samma sak](/insights/det-imponerande-och-det-fakturerbara) (serie 28) och [Det är inte farten som dödar](/insights/det-ar-inte-farten-som-dodar) (serie 26)*

### [Det imponerande och det fakturerbara är inte samma sak](https://tomasandre.se/insights/det-imponerande-och-det-fakturerbara)

I've been asking people in the industry one concrete question -- have you shipped this to a paying customer? The answer is consistent and tells you something important about the gap between impressive and what actually reaches a paying client.

# Det imponerande och det fakturerbara är inte samma sak

Jag har ställt en fråga till folk i branschen. Inte abstrakt, konkret. Har du satt det här i produktion åt en kund?

Inte demonstrerat. Inte kört en workshop. Levererat, fakturerat, och ägt ansvaret för att det fungerar i en annan organisations vardag.

## OpenClaw

OpenClaw tar oproportionerligt stort utrymme i branschdiskussionen just nu. Podcasts, LinkedIn-flöden, konferensscener. Gateway-först-arkitektur, självorganiserande arbetsflöden, kurator som lär sig vad som används och vad som kan arkiveras. Det är genuint imponerande att se.

En av de mer tekniskt avancerade i fältet, aktiv inom AI-utbildning, byggare i månader, beskrev det som "självgörande på ett helt annat sätt."

Samma person, på frågan om det satts i produktion åt en betalande kund: "Det har jag inte gjort. Inte produktifierat den. Det har jag inte sett. Bara för egen värld."

## Vad det är

OpenClaw är ett personligt verktyg. Det är designat för sin ägare, inte för överlämning. Det som gör det kraftfullt är djupintegrationen med ägarens processer, kontext och arbetsflöden. Att flytta det till en kunds organisation är inte driftsättning. Det är en nybyggnation i en ny kontext med ny data.

Det kräver dessutom en teknisk mognad att driftsätta och underhålla som de flesta organisationer varken har eller ska behöva ha.

"Bara för egen värld" är inte ett misslyckande. Det är en precis beskrivning av vad verktyget är.

## Det enda affärsfallet

Det kommersiella sammanhanget kring den här kategorin av verktyg är i undantagsfall FOMO-konsulting. Workshops och samtal som säljer på att folk känner att de borde förstå, borde hänga med, borde vara med i rörelsen. Ingen i rummet säger att de inte förstår. Ingen frågar om det faktiskt kan levereras till en kund.

Det skapar ett verktyg som fyller mediekanaler i proportion till sin synlighet, inte till vad det faktiskt levererats för.

Det ärliga svaret är ovanligt. Det kostar att säga.

## Det som saknas

Vad köper kunden? Vem äger systemet när leveransen är klar? Vem ringer när något inte fungerar?

Ingen av de frågorna löses av nästa versionsuppdatering.

Om du inte kan svara på vem som äger systemet på måndag morgon har du inte byggt en produkt. Du har hållit en föreställning.

---

*Se även: [Förtroendet kommer före tekniken](/insights/fortroendet-kommer-fore-tekniken) (serie 27) och [De vill inte förstå -- de vill checka av](/insights/de-vill-inte-forsta-de-vill-checka-av) (serie 17)*

### [Förtroendet kommer före tekniken](https://tomasandre.se/insights/fortroendet-kommer-fore-tekniken)

The real threshold for AI adoption in established organisations is not the technology. It is that no one has had the honest conversation with the leader yet.

# Förtroendet kommer före tekniken

Det finns ett mönster som upprepas i i stort sett varje samtal jag haft med en erfaren ledare från ett etablerat bolag -- industri, försäkring, infrastruktur, det spelar ingen roll. De vet att AI förändrar saker. De har läst artiklarna. Någon i styrelsen har ställt frågan. Kanske har de till och med testat ChatGPT privat.

Men i ett formellt sammanhang -- med konsulter i rummet, med ett budgetbeslut på gång -- så beter de sig som om de förstår mer än de gör.

Det är inte oärlighet. Det är sunt självbevarelsedrift.

## Förtroendeproblemet

En 58-årig VD för ett medelstort industribolag ska inte behöva fråga en säljande konsult vad ett kontextfönster är. Det skapar en ojämlik dynamik som han vet att han förlorar på. Så han ställer inte frågan. Han nickar i stället, fattar ett beslut baserat på ofullständig information, och hoppas att det löser sig.

Det löser sig sällan.

Det vi kallar "motstånd mot AI-transformation" är ofta ingenting annat än det här: en ledare som inte har haft ett tryggt forum att vara ärlig i. Att säga: jag förstår inte tillräckligt för att fatta det här beslutet. Vad behöver jag faktiskt veta?

Det samtalet har aldrig hänt. Och det syns tydligt i resultaten.

## Vad som faktiskt blockerar

AI Sweden Leadership Report 2026 identifierar mandatfrågan som den kritiska skiljelinjen -- transformation lyckas när den ägs av en person i toppen med verkligt ägarskap. Jag delar den bilden helt. Men det leder till en uppföljningsfråga som rapporten inte svarar på:

Hur ska en person i toppen kunna ta verkligt ägarskap för något de inte förstår tillräckligt väl?

Svaret är att de inte kan. Inte förrän det finns ett tryggt forum för det ärliga samtalet.

Det är inte brist på vilja. Det är brist på en specifik sorts kontext: ett rum utan säljagenda, utan prestige på spel, där ledaren faktiskt kan sätta fingret på var de befinner sig -- och vart de behöver komma.

## Kartan som saknas

Det första jag gör i ett nytt ledarskapssamtal är att försöka förstå var personen faktiskt befinner sig på AI-skalan. Inte var de vill vara. Inte hur de presenterar sig. Var de är.

Det handlar om enkla, konkreta frågor. Har de personliga AI-inställningar? Har de laddat upp egna dokument och fått svar på dem? Har de sett skillnaden mellan ett generellt svar och ett svar som är förankrat i deras egna data? Vet de vad det kostar att köra det i produktion kontra i testmiljö?

Svaren på de frågorna är en karta. En ärlig karta. Och utan den kartan är alla rekommendationer om "AI-strategi" och "transformation" byggda på sand.

Konsultrapporter levererar ofta en karta -- men det är konsultens karta, inte ledarens. Det är kartan över vart de borde vilja gå, inte en ärlig inventering av var de faktiskt är.

## Det säkra rummet

Det som krävs är ett format där ledaren kan vara genuint nyfiken utan att det tolkas som inkompetens. Där de kan säga "jag förstår inte det här" och få ett rakt svar, inte en omedierad säljpitch.

Det formatet ser ut ungefär så här:

Ett första informellt möte -- inte ett möte med presentationer och förslag, utan ett samtal. Vad vet du om AI i dag? Vad har du testat? Vad är du orolig för? Vad skulle du egentligen behöva för att känna dig trygg med det här beslutet?

Utifrån de svaren kartlägger man var ledaren befinner sig. Inte för att döma, utan för att kunna visa rätt saker. En VD som aldrig laddat upp ett eget dokument och fått ett förankrat svar behöver se det -- live, med sin egen data -- innan något annat är meningsfullt.

Det är den upplevelsen som skapar förtroende. Inte en 60-sidig rapport.

## Initiativer som överlever

Organisationer som lyckas med AI-transformation har alltid en person i toppen som förstår tillräckligt väl för att ta verkligt ägarskap. Inte nödvändigtvis en tekniker -- men någon som kan skilja hajp från verklighet, som kan ifrågasätta leverantörernas påståenden, som kan styra utan att vara beroende av att någon annan tolkar verkligheten.

Den personen blir inte till genom att läsa en rapport. De blir till genom ett ärligt samtal -- oftast det första -- där de tillåts vara precis så okunniga de faktiskt är, och därifrån börjar bygga en verklig förståelse.

Förtroendet måste komma före tekniken. Det är inte en mjuk åsikt. Det är förutsättningen för att något annat ska hålla.

*Se även: [Det imponerande och det som når en kund är inte samma sak](/insights/det-imponerande-och-det-fakturerbara) (serie 28) -- samma tystnadsmekanik, men på praktikersidan: ingen i den tekniska kretsen säger att de inte har levererat. Och [Ledaren som inte kan delegera](/insights/ledaren-som-inte-kan-delegera) (serie 21) -- om varför mandatet måste komma uppifrån.*

### [Det är inte farten som dödar](https://tomasandre.se/insights/det-ar-inte-farten-som-dodar)

On why speed is not the problem with AI -- and why the crash reveals who actually owns what they built.

# Det är inte farten som dödar

Det finns ett gammalt humorprogram som simulerar Peter Solberg som intervjuas om rallykörning på dålig engelska. Han tillfrågas om han är rädd för farten. Han svarar: *"You know -- it's not the fart that kills you, it's the smell."*

På engelska låter det som någonting helt annat. Men på svenska hör man vad han faktiskt menar: det är inte farten som dödar. Det är smällen.

Och precis det stämmer om det som händer i AI-världen just nu.

## Farten är äkta

Det som händer är genuint imponerande. En projektledare kopplar Claude till ett projekthanteringsverktyg och bygger en dashboard som sammanställer kapacitet, velocity och budgetutfall automatiskt -- arbete som tidigare tog timmar varje vecka. En annan person bygger ett verktyg med namnkonfigurator, marknadsplats och betalningsflöde på en förmiddag. Saker skapas som inte funnits förut.

Det är inte hype. Det är verklig acceleration. Och det fungerar -- inte för att Claude är magisk, utan för att personen bakom vet exakt vad de vill uppnå. Det är den kunskapen som gör instruktionerna precisa. Det är inte verktyget som är anledningen. Det är personen.

## Vad stoppet avslöjar

Det är inte vibe-codingen som är problemet. Det är vad som händer när det slutar fungera.

En betalning fastnar. En konfiguration försvinner vid en uppdatering. En bugg dyker upp i en edge case ingen testade. Jira-kopplingen tappar data. Infrastrukturen som aldrig sattes upp ordentligt.

Vem tar tag i det? Vem letar buggen i kod som AI genererade men du inte fullt förstår? Vem konfigurerar upp miljön igen när den faller?

Det är inte ett hypotetiskt problem. Det är stoppet. Och i stoppet avslöjas vem som faktiskt äger systemet -- och vem som bara åkte med när allt gick rätt.

## The last mile går inte att fuska

Du kan bygga snabbt till sjuttio procent. Det är äkta. Imponerande. Värt att hylla.

Men the last mile -- produktionsmiljön, felhanteringen, skalningen, ansvaret när något inte stämmer -- den kräver att du förstår det du levererar. Inte för att du måste ha skrivit varje rad. Utan för att du måste kunna kliva in när det stannar. Hitta var. Förstå varför. Fatta ett beslut.

The last mile är inte ett tekniskt problem. Det är ett domänkunskapsproblem. Det är skillnaden mellan att ha kört en bil och att förstå vad som händer under motorhuven när den stannar.

## Vad det faktiskt innebär

Det här är inte ett argument mot att bygga. Det är ett argument för att veta vad du äger och vad du inte äger.

Bygg. Experimentera. Prototypa på en förmiddag. Det är rätt. Men sätt inte ett produktionssystem i drift om du inte kan svara på: vad händer om det går sönder? Vem fixar det? Har jag förstått varje del tillräckligt för att äga konsekvenserna?

Det är inte farten som dödar. Det är stoppet.

Och det är i stoppet du får svaret på om du faktiskt äger det du byggde.

*Se även: [Den som lyckas med AI är inte den du tror](/insights/den-som-lyckas-med-ai) (serie 18) och [Du kan inte validera det du inte förstår](/insights/du-kan-inte-validera-det-du-inte-forstar) (serie 6).*

### [Projektet var klart. Ingen annan förstod det.](https://tomasandre.se/insights/projektet-var-klart-ingen-annan-forstod-det)

On what happens when you build a project alone at high speed -- and then try to explain it to someone else. The code works. But the knowledge is stuck in you.

# Projektet var klart. Ingen annan förstod det.

Jag har byggt system i ett tempo som inte hade varit möjligt för tre år sedan. Ingen legacy att ta hänsyn till, ett rent sammanhang, full kontroll över varje beslut. AI som exekveringsmotor. Jag som den som visste vad som behövde byggas och varför.

Det är en kraftfull kombination. Det är också en fälla med en exakt tidsinställning.

Fällan utlöses inte när projektet är klart. Den utlöses när någon annan ska ta över det.

## Vad som faktiskt händer när du bygger ensam i högt tempo

Varje projekt bär på en mängd kunskap som aldrig skrivs ner. Inte för att du är slarvig -- utan för att du inte behöver skriva ner det. Du vet det. Du håller det i huvudet. Det är just det som gör dig snabb.

"Den här tabellstrukturen ser konstig ut men den beror på att rapporteringslogiken kräver det." Det behöver du inte anteckna. Du vet det.

"Det här undantaget fångas och dirigeras om för att uppströmstjänsten ibland returnerar null utan att det är ett fel." Du vet det. Det är uppenbart -- för dig.

"Det här fältet är nullable fast det inte borde vara, på grund av ett kantfall i onboardingflödet vi diskuterade med kunden i november." Det sitter i ditt korttidsminne. Det är inte skrivet någonstans.

Den här kunskapen är inte dokumentationsluckor. Den är hela systemets logik -- destillerad till implicit förståelse som lever i en enda persons huvud.

När tempot är högt och ansvaret är ditt ensamt, är det rationellt att hålla den kunskapen i dig. Det är faktiskt det som gör tempot möjligt. Kontextfönstret i ditt eget huvud är komplett. Du behöver inte förklara för dig själv.

## Överlämningen som avslöjar allt

Sedan kom ögonblicket. Någon annan skulle ta över -- eller åtminstone förstå tillräckligt för att kunna underhålla det jag hade byggt.

Jag satte mig ner för att förklara. Och märkte ganska snabbt att jag inte kunde förklara -- inte på ett sätt som gav den andra personen faktisk förståelse. Jag kunde peka. Jag kunde demonstrera. Men varje gång jag förklarade varför något var strukturerat som det var, behövde jag förklara tre saker till som förutsatte att man kände till bakgrunden till ytterligare tre saker.

Koden fungerade. Arkitekturen var faktiskt ganska ren. Men kunskapen som producerat den -- den fanns inte i koden. Den fanns i mig.

Systemet var klart. Men projektet var inte klart. Det skulle inte vara klart förrän det kunde överleva utan mig.

## Vad jag lärde mig om hastighet

Det är en missuppfattning att hastigheten i ett solo-AI-projekt beror på att du skippar steg. Det beror på att du skippar kommunikation. Du kommunicerar inte med ett team. Du kommunicerar inte med dokumentationssystemet. Du kommunicerar med AI:n och med dig själv, och den loopen är snabb.

Den snabbheten är verklig och värdefull. Men den har ett pris som inte syns förrän projektet behöver överleva dig.

Det finns en skillnad mellan ett projekt som är färdigt och ett projekt som är överlämningsbart. Jag hade byggt det första. Jag trodde jag hade byggt det andra.

## Vad som faktiskt hjälper

Det är inte mer dokumentation i efterhand. Det fungerar dåligt -- kontexten är kall och det är svårt att rekonstruera varför beslut fattades, inte bara vad de var.

Det som fungerar är externalisering i stunden. En mening i CHANGELOG för varje signifikant beslut -- inte vad som ändrades, utan varför. En kommentar i toppen av en modul som förklarar vilket problem den löser och varför den är strukturerad på det sättet. Ett deploy-skript som en annan person kan köra från grunden utan instruktioner från mig.

Och, om det är möjligt: en andra person som är med under bygget. Inte för att sakta ner -- utan för att den personen kan fråga "varför" i realtid, när svaret fortfarande är självklart för mig. Det är det billigaste och effektivaste sättet att externalisera kunskap.

Projektet är klart när det fungerar. Det är överlämningsbart när det fungerar utan att jag måste förklara det.

Det är inte samma sak.

*Se även: [En person, tusen leveranser](/insights/en-person-tusen-leveranser) (serie 7) och [Kontrollpunkten är jobbet](/insights/kontrollpunkten-ar-jobbet) (serie 11).*

*Mer om detta mönster från ett metodperspektiv: [The blank sheet ceiling](/articles/blank-sheet-ceiling-bsp-production-gap) på mindtastic.se*

### [Ansvar i tre nivåer](https://tomasandre.se/insights/ansvar-i-tre-nivaer)

How carefully do you need to review AI-generated code? The answer depends entirely on which of three levels you're working at -- and confusing them is the most common mistake in AI-assisted development.

# Ansvar i tre nivåer

Hur noga måste man egentligen granska AI-genererad kod?

Det är en fråga jag möter ofta. Och svaret jag brukar ge är nästan alltid: varje rad. Granska varje rad du committar. Förstå varför. Sätt ditt namn på det du äger.

Men det är inte hela svaret. Det är svaret för en specifik nivå -- och det finns tre.

## Simon Willisons ärliga erkännande

I maj 2026 publicerade Simon Willison -- en av de mest respekterade rösterna inom AI-assisterad utveckling, mannen som myntade distinktionen mellan vibe coding och agentic engineering -- ett nyhetsbrev med en obekväm insikt.

Han granskar inte längre varje rad. Inte ens för produktionskod. Han kallar det *normalization of deviance* och beskriver det som "quite upsetting". Sedan fortsätter han ändå.

Jag instämmer inte reflexmässigt i kritiken. Jag tror han har rätt -- på sin nivå.

Det är nivåerna som är poängen.

## Nivå 1 -- Solo (>10×)

Du bygger ett personligt verktyg. Ett experiment. Något för dig.

Om det går fel drabbar det dig. Du bär konsekvensen, du ser felet, du fixar det. Ansvaret är koncentrerat till en person och den personen är du.

På den nivån är rationell flexibilitet just det -- rationell. Arbetsloopen är bra praxis, inte ett moraliskt åtagande. Om du väljer att inte granska varje rad i ett personligt projekt är det ditt val och din risk. Vibe coding kan vara fullt rationellt på solo-nivå -- du känner konsekvenserna direkt.

Simon bygger personliga verktyg. iNaturalist-appar byggda på telefonen, Redis-lekplatser, presentationsverktyg. Det är solo-nivå. Hans glidning är rationell i den kontexten.

**Naturlig drift:** Mot vibe coding -- och det är okej.
**Minimikrav:** Inga formella policys krävs. Arbetsloopen är god praxis, inte ett åtagande.

## Nivå 2 -- Uppdrag (5--10×)

Nu är det inte längre din risk ensam.

Kundens system. Kundens data. Kundens verksamhet. Ditt namn på kontraktet -- och på koden.

Här slutar arbetsloopen vara ett val. Inte för att en process säger det, utan för att det är det enda sättet att faktiskt stå bakom det du levererar. Du kan inte säga "jag tyckte det såg rätt ut" när en bug kostar kunden pengar. Du måste kunna säga "jag förstod varje rad jag committade."

Det är ett professionellt åtagande. Och det är en tydlig gräns: på solo-nivå väljer du. På uppdrag väljer du bort ansvarstagandet.

**Naturlig drift:** Nivå 1-vanor smyger in -- "det ser rätt ut" ersätter faktisk granskning.
**Minimikrav:** Arbetsloopen är icke-förhandlingsbar. Varje commit kräver förståelse.

## Nivå 3 -- Bolagsleverans (2--5×)

Det här är den svåraste nivån -- inte för att kraven är högre, utan för att ansvaret lätt försvinner helt.

"Bolaget är ansvarigt" låter robust. Det är det inte. Det är en papperskonstruktion om ingen enskild person faktiskt äger varje rad som committas.

I ett team kan ansvar diffunderas till ingenting. Alla granskade koden innebär att ingen granskade koden. Ingen enskild person kände att de var den som ägde resultatet. Ingen visste exakt vart konsekvenserna hamnade om något gick fel.

Det enda som fungerar i praktiken är att en namngiven utvecklare committar, förstår och äger varje rad. Commiten är inte administrativt arbete. Det är det enda ansvarssteget som faktiskt existerar i ett team. Utan det är accountability ett ord utan innehåll.

Det är inte ett teknologiproblem. Det är ett metodproblem. Och det är precis vad som händer när ett bolag normaliserar solo-beteende i en bolagsleverans-kontext.

**Naturlig drift:** Ansvar diffunderar till ingen -- "alla granskade" ersätter ägarskap.
**Minimikrav:** Namngiven ägare per commit + teamöverenskommelse om AI-policys (inspelning, datahantering, kodincheckning, parallella trådar). Dessa beslut behöver fattas gemensamt -- de dyker annars upp som akuta frågor mitt i leveransen.

## Vad Simon Willison egentligen visar

Simon har rätt om sin egen situation. Hans reflektion är ärlig och välformulerad.

Problemet är att hans situation används som mall av organisationer som inte delar hans förutsättningar. En senior 25-årig solo-ingenjör som bygger personliga verktyg har en konsekvensstruktur som ser fundamentalt annorlunda ut än ett femtonpersonersteam som levererar ett affärskritiskt system till en kund.

Simon namnger risken själv -- *normalization of deviance*. Varje gång modellen producerar rätt kod utan nära granskning sänks tröskeln för nästa gång. Det är rationellt på nivå 1 där konsekvensen stannar hos dig. Det är farligt på nivå 3 där konsekvensen bärs av någon annan.

Mindtastics metodik är inte byggd för att ge Simon sämre verktyg. Den är byggd för att förhindra att nivå 1-beteende -- med sina rationella grunder -- slår igenom som norm i organisationer som opererar på nivå 3.

Det är tre olika svar på en fråga. Och den viktigaste kompetensen är att veta vilken nivå du är på.

*Se även: [Arbetsloopen -- sex steg som gör ansvar konkret](/insights/arbetsloopen-sex-steg) (serie 23) och [AI tvingar dig att tänka hårdare](/insights/ai-tvingar-dig-tanka-hardare) (serie 12).*

### [Arbetsloopen -- sex steg som gör ansvar konkret](https://tomasandre.se/insights/arbetsloopen-sex-steg)

Six steps that translate personal accountability from a conviction into a concrete work process. Context management, the inner loop, and why the commit is the final accountability checkpoint.

# Arbetsloopen -- sex steg som gör ansvar konkret

Personligt ansvar är en övertygelse. Arbetsloopen är hur den övertygelsen ser ut när den möter verklig kod.

Jag har kört den här processen i mer än ett år. Inte som ett experiment -- som min faktiska arbetsmetod, varje dag. Det som följer är inte teori. Det är vad som fungerar.

## Varför en loop behövs

LLM-assisterad utveckling har ett grundläggande problem: kontextfönstret är ändligt och fragmenterat.

Du läser projektet, pratar med modellen, skriver lite kod, pratar mer, byter fokus, byter tillbaka. Halvvägs in i implementationen vet modellen inte längre vad du beslutade i planeringsfasen. Planeringsbrus följer med in i implementationen och förstör den.

Loopen löser det. Varje fas börjar rent. Planeringen stannar i planen. Implementationen börjar med bara det som behövs för att bygga.

## De sex stegen

### Steg 1: Läs projektet

Ladda kontextfönstret med allt som är relevant -- kodbas, riktlinjer, git-historik, arkitekturbeslut. Fem minuter av kontextladdning sparar timmar av korrigering efteråt.

Det här steget är inte förberedelse. Det är arbete. Du läser för att förstå vad systemet faktiskt gör, inte vad du tror att det gör.

### Steg 2: Skriv en change request

Beskriv uppgiften i en fil på disk. Inte i chatten. Filen överlever nästa steg.

En CR ska svara på tre frågor: Vad ska göras? Vad är acceptanskriteriet? Vad är utanför scope?

Stor uppgift? Dela upp i faser. En fil per fas. Varje fas har eget scope och egna acceptanskriterier. Det tvingar fram precision -- du kan inte planera vagt när varje fas ska kunna stå ensam.

### Steg 3: Töm kontexten

Stäng konversationen. Börja om från noll.

Det här steget är det som de flesta hoppar över -- och det är det viktigaste. Planeringsdiskussionen innehåller osäkerheter, alternativ, bortkastade idéer. Den ska inte följa med in i implementationen. Bara CR:en ska med. Och relevant kod.

Rent kontextfönster = rent resultat.

### Steg 4: Bygg från planen

Följ CR:en. Inget annat.

Händer något oväntat? Stanna. Uppdatera CR:en först. Implementera sedan. Det kan verka omständigt. Det är det inte -- det är det som skiljer avsiktlig implementation från drift.

### Steg 5: Granska varje rad

Läs diffen. Bedöm din konfidenz:

- **Hög:** Jag förstår varje rad. Jag kan förklara varför. → Committa.
- **Medel:** Det ser rätt ut men jag är osäker på delar. → Granska mer. Fråga modellen. Fråga en kollega.
- **Låg:** Jag förstår inte varför det här fungerar. → STOPP. Förstå innan du går vidare.

Det här steget är arbetet. Inte ett hinder framför arbetet -- det ÄR arbetet. Det är här personligt ansvar tar form i handling. Varje rad du granskar är en rad du äger.

### Steg 6: Committa och dokumentera

Manuellt commit-meddelande. Uppdatera ändringslogg. Är det fler faser? Tillbaka till steg 3 med nästa fas.

Commiten är inte administrativt arbete. Det är det sista ansvarssteget -- du sätter ditt namn på det du har granskat och förstått.

## Den inre loopen

För stora uppgifter med flera faser upprepas steg 3 till 6 för varje fas. Varje fas får ett rent kontextfönster.

Det är det som kallas den inre loopen. Och det är det som gör att komplexa uppgifter förblir hanterbara -- inte för att de är enkla, utan för att du aldrig bär mer än en fas i taget.

## Vad loopen egentligen är

Loopen är inte en produktivitetsteknik. Det är en ansvarsstruktur.

Steg 2 tvingar dig att tänka klart innan du bygger. Steg 3 skyddar implementationen från planeringsbrus. Steg 5 gör att du inte kan commita det du inte förstår. Steg 6 sätter ditt namn på det du äger.

Varje steg är utformat för att göra det svårare att fly från konsekvenserna. Inte för att straffa -- utan för att det är så bra kod faktiskt skapas.

Personligt ansvar är en övertygelse. Det här är hur den ser ut när den fungerar.

*Se även: [Du kan inte validera det du inte förstår](/insights/du-kan-inte-validera-det-du-inte-forstar) (serie 17) och [AI tvingar dig att tänka hårdare](/insights/ai-tvingar-dig-tanka-hardare) (serie 12).*

### [Ledaren som inte kan delegera](https://tomasandre.se/insights/ledaren-som-inte-kan-delegera)

On why AI transformation cannot be delegated. And what it actually means to own it -- not as an advisor, but as the person responsible.

# Ledaren som inte kan delegera

AI Sweden Leadership Report 2026 intervjuade ledande företagschefer i Sverige om vad som faktiskt skiljer de organisationer som lyckas med AI-transformation från de som inte gör det. Mönstret som upprepades tydligast handlade inte om teknik, budget eller verktygsval.

Det handlade om ledarskap. Specifikt: vem som äger frågan.

Transformation lyckas nästan uteslutande när en person i toppen -- VD, styrelseordförande, ägare -- tar ett personligt och aktivt ansvar för att driva skiftet. Inte delegerar det till IT. Inte ger en arbetsgrupp i uppdrag att utreda. Utan faktiskt förstår, styr och tar ansvar.

Det är inte en teknisk fråga. Det är en ledarskapsförmåga -- och det är den förmågan som avgör.

## Vad delegering faktiskt skapar

Jag har sett mönstret många gånger. Ett bolag anlitar en konsult eller byrå för AI-transformation. Det levereras rapporter, rekommendationer, roadmaps. Presentationerna är välgjorda. Ledningsgruppen nickar.

Sedan händer ingenting. Eller allt händer -- men på fel ställe. En pilot startar i ett team som var entusiastiskt nog att ta kontakt med konsulten. Resten av organisationen vet knappt att det pågår.

Sex månader senare: projektet är "framgångsrikt" enligt konsultens mätning. Men utanför det rummet rör sig ingenting.

Det är inte konsultens fel. Det är strukturens fel. Konsulten äger inte beslutet. Konsulten äger inte kulturen. Konsulten äger inte vad som händer måndag morgon när piloten ska skalas upp och möter det dagliga motståndet.

## Rapporten bekräftar det

AI Sweden publicerade nyligen Leadership Report 2026 -- en av de mer genomarbetade analyserna av vad som faktiskt skiljer de organisationer som lyckas med AI-transformation från de som inte gör det.

Det tydligaste mönstret: transformation lyckas nästan uteslutande när den ägs av en person med reellt mandat i toppen. Inte en AI-ansvarig på mellanledningsnivå. Inte en extern rådgivare. Personen med ansvar för helheten.

> *"A very clear mandate from the highest leadership is required to break through old structures, and consensus was seldom reached at the initiation of the shift."*
> -- AI Sweden Leadership Report 2026

Det är exakt det jag sett. Och exakt därför jag inte längre konsultar den här typen av uppdrag. Det fungerar inte.

## Skillnaden i praktiken

Det handlar inte om titeln. Det handlar om vad som händer när det blir svårt.

Som konsult kan jag rekommendera att en ledare tar ett visst beslut. Som CAIO äger jag det beslutet. Jag sitter i ledningsgruppsmötet. Jag formulerar frågeställningarna. Jag driver uppföljningen.

Det innebär att jag kan möta motståndet direkt -- inte rapportera om det i en PowerPoint.

Det innebär att när ett team inte adopterar ett nytt arbetssätt, är det mitt problem att förstå varför och göra något åt det.

Det innebär att AI-agendan inte kan pareras med "vi tar det med konsulten." Konsulten sitter i rummet.

## Vad det faktiskt kräver

Rapporten beskriver det som att "actively understand, guide, and take responsibility." Tre verb som alla är aktiva. Inte "godkänna" eller "delegera" eller "följa upp på."

Det kräver att ledaren -- CAIO, VD, CDO, oavsett titel -- faktiskt förstår vad som händer. Inte på detaljnivå. Men tillräckligt för att ställa rätt frågor. Tillräckligt för att se när en teknisk lösning löser fel problem. Tillräckligt för att inte bli beroende av att någon annan tolkar verkligheten.

AI-förståelse i toppen är inte lyx. Det är en förutsättning för att mandat ska ha substans.

## Inte för alla

Det här är inte ett argument för att alla organisationer behöver en heltids-CAIO. Det är ett argument för att den person som driver AI-transformationen måste ha verkligt ägarskap -- oavsett om det är ett heltidsuppdrag, ett delat fokus, eller ett fraktionellt engagemang.

Det som inte fungerar är att ägarskapet saknas. Att AI-frågan hanteras som ett projekt vid sidan om, utan någon som kan bryta konsensus och driva igenom det som faktiskt behöver hända.

Rapporten är tydlig: de som väntar på att organisationen ska lösa det själv, väntar förgäves. Förändringen kräver en person som tar det personliga ansvaret.

Det är inte en ny insikt. Det är ett gammalt ledarskapsansvar -- applicerat på ett nytt område.

*Se även: [Personligt ansvar som grund](/insights/jag-ar-smartare-an-ai) (serie 1) och [Det var aldrig en teknikfråga](/insights/det-var-aldrig-en-teknikfraga) (serie 10). Mandatet i praktiken: [Adoptionen var det riktiga projektet](/insights/adoptionen-var-det-riktiga-projektet) (serie 41).*

*AI Sweden Leadership Report 2026: [ai.se/sv/ai-sweden-leadership-report-2026](https://www.ai.se/sv/ai-sweden-leadership-report-2026)*

### [Du investerar inte i AI -- du investerar i att nå dina mål](https://tomasandre.se/insights/du-investerar-inte-i-ai)

On why most organizations are asking the wrong question -- and what the organizations that actually succeed do differently. It's not about the technology. It's about what you're trying to achieve.

# Du investerar inte i AI -- du investerar i att nå dina mål

AI Sweden publicerade nyligen Leadership Report 2026 -- en genomlysning av vad som faktiskt skiljer organisationer som lyckas med AI-transformation från de som inte gör det. Rapporten bygger på djupintervjuer med ledande företagschefer i Sverige: VD:ar, CDO:s och styrelseledamöter från AstraZeneca, Södra, Saab, Norra Skog och fler.

En mening i rapporten sammanfattar den viktigaste skillnaden:

> *"Som ledare investerar du inte i AI -- du investerar i att nå dina mål. Vi fördubblade vår intäkt mellan 2020 och 2025 med AI som en nyckelaktivator."*
> -- Peder Blomgren, VP Head of Data Office R&D, AstraZeneca

Den meningen är enkel. Men den rymmer en hel strategisk omramning som de flesta organisationer missar helt.

## Fel fråga att börja med

Jag sitter i möten där frågan formuleras ungefär såhär: "Vilka AI-verktyg borde vi börja med?" Eller: "Hur mycket bör vi budgetera för AI?" Eller: "Hur håller vi oss relevanta när alla andra också investerar i AI?"

Alla dessa frågor börjar med tekniken. Och om du börjar med tekniken hamnar du i ett läge där varje beslut styrs av vad tekniken kan göra -- inte av vad du faktiskt försöker uppnå.

Resultatet är förutsägbart: isolerade pilotprojekt, produktivitetsverktyg som löser problem ingen kände sig pressad av, och en diffus känsla att "ni håller på med AI" utan att det påverkar något som faktiskt mäts.

## Effektivisering kontra expansion

AI Sweden-rapporten gör en distinktion som jag sett bekräftad om och om igen. De allra flesta organisationer börjar med automatisering -- göra det vi redan gör, men billigare. Spara timmar i backoffice. Minska handläggartid. Standardisera manuella steg.

Det är rationellt. Det är mätbart. Och det ger 10 procent av det möjliga värdet.

De organisationer som faktiskt förändrar sin konkurrensposition börjar istället med expansion. Inte "hur gör vi det vi gör billigare" -- utan "vad kan vi göra nu som vi inte kunde göra förut?"

Det kan vara nya intäktsströmmar. Produkter som inte var ekonomiskt genomförbara utan AI. Beslut som tidigare krävde veckor av analys och nu tar timmar. Kundupplevelser som var omöjliga att skala.

Rapporten: *"AI:s verkliga värde ligger inte i att göra samma saker billigare, utan i att göra helt nya saker."*

## Vad jag ser inifrån

Skillnaden är synlig i hur frågeställningarna formuleras.

Effektivisering-organisationen frågar: "Vilka processer kan vi automatisera?" och "Hur mäter vi sparade timmar?"

Expansion-organisationen frågar: "Vad begränsar oss idag som inte längre behöver begränsa oss?" och "Vad hade vi gjort om den begränsningen försvann?"

Den andra typen av fråga kräver att du förstår din verksamhet djupare -- inte AI djupare. Och den öppnar ett helt annat designutrymme.

## Hur det förändrar investeringslogiken

En konsekvens av det här är att traditionella ROI-kalkyler fungerar dåligt i det tidiga skedet av AI-transformation.

Effektiviseringslogiken är kalkylerbar: process X tar Y timmar, AI minskar det till Z timmar, differensen multiplicerat med timlön ger ett tal. Det ser ut som ett beslutsunderlag.

Expansionslogiken är en satsning: om det här fungerar kan vi nå marknader vi inte kommit åt, leverera erbjudanden vi inte kunnat prissätta, ta beslut med en hastighet vi inte haft. Hur kalkylerar du det?

Du gör det inte. Du bedömer sannolikheten, täcker risken med parallell leverans i kärnan, och fattar ett strategiskt beslut.

Rapporten igen: *"Den första fasen är nästan omöjlig att ta sig igenom för att du inte har ROI eller tydliga svar. Det kräver mod och ledarskap."*

Det är inte ett argument mot kalkyl. Det är ett argument mot att låta kalkylen ersätta omdömet i det skede av transformationen där omdöme faktiskt avgör.

## Vad frågan borde vara

Istället för "Vilka AI-verktyg borde vi använda?" -- vad vill du uppnå som du inte uppnår idag?

Svara på det tillräckligt konkret. Sedan kan man fråga om AI är rätt medel för att ta sig dit, och vilka delar av kedjan som behöver förändras för att det ska fungera i verkligheten.

Det är en annorlunda konversation. Svårare. Men den ger annorlunda beslut.

*Se även: [Hela kedjan](/insights/en-person-tusen-leveranser) (serie 7) och [Den som lyckas med AI är inte den du tror](/insights/den-som-lyckas-med-ai) (serie 18).*

*AI Sweden Leadership Report 2026: [ai.se/sv/ai-sweden-leadership-report-2026](https://www.ai.se/sv/ai-sweden-leadership-report-2026)*

### [Nittio procent av problemen är AI-genererade](https://tomasandre.se/insights/nittio-procent-av-problemen-ar-ai-genererade)

On what happens when a CTO reviews every commit for eight months and discovers that nearly all problematic code is AI-generated. Technical debt doesn't arise despite AI -- it arises because of AI.

# Nittio procent av problemen är AI-genererade

En CTO jag arbetar med har gjort något ovanligt. Under åtta månader har han granskat varje commit som passerar genom teamets CICD-pipeline. Varje pull request. Varje kodändring. Inte stickprov -- allt.

Hans slutsats: nittio procent av den problematiska koden är AI-genererad.

Inte nittio procent av all kod. Nittio procent av problemen.

## Det ingen vill höra

Det här är det som gör insikten obekväm: verktygen fungerar. De gör exakt vad de ska. De genererar kod snabbt, i stora volymer, med hög syntaktisk kvalitet. Koden kompilerar. Den passerar grundläggande tester. Den ser professionell ut.

Och den skapar teknisk skuld i en takt som ingen manuell utvecklare hade kunnat åstadkomma.

Det är inte ett argument mot AI. Det är ett argument för att sluta behandla AI-genererad kod som om den vore gratis.

## Multiplikatorn slår åt båda hållen

Jag har skrivit förut om att AI förstärker det du redan kan. Att en senior med rätt verktyg blir extraordinär. Det är sant. Men det jag inte betonade tillräckligt var den andra sidan.

En utvecklare som inte förstår uppgiften, som inte kan tolka krav, som inte ser arkitekturella konsekvenser -- den personen blev inte bättre av AI. Den personen blev farligare.

Tidigare producerade den utvecklaren medioker kod långsamt. Nu producerar samma person medioker kod i en takt som översvämmar systemet. Fler filer, fler moduler, fler beroenden -- allting genererat, ingenting granskat, allt teknisk skuld.

CTO:n uttryckte det så: "De som kan uttrycka sig tydligt och förstår uppgiften får bra resultat. De som inte kan det skapar större problem med AI än utan."

Det är det som saknas i branschens berättelse. AI gör inte alla bättre. AI gör alla snabbare. Och snabbare åt fel håll är värre än långsamt åt rätt håll.

## Teknisk skuld, 2026-versionen

Teknisk skuld är inget nytt. Varje utvecklingsteam lever med den. Men 2026-versionen ser annorlunda ut.

Traditionell teknisk skuld uppstår gradvis: genvägar under tidspress, halvfärdiga lösningar som blir permanenta, dokumentation som aldrig skrivs. Du ser den komma. Du kan hantera den.

AI-genererad teknisk skuld uppstår omedelbart och i volym. En junior utvecklare som ber en LLM generera en hel modul på en eftermiddag skapar mer teknisk skuld än samma utvecklare hade producerat på en månad manuellt. Koden ser ren ut. Den följer konventioner. Men antagandena är fel, edge cases saknas, och arkitekturen matchar inte resten av systemet.

Och det värsta: det syns inte vid en ytlig granskning. Koden ser professionell ut. Du måste förstå systemet för att se att den är fel. Och om du förstår systemet tillräckligt väl för att se det -- då hade du inte behövt AI för att skriva den.

## Riktlinjerna som ingen följde

CTO:n hade gjort sin del. Han hade skapat ett development skills-paket. Arkitekturstandarder. Definierade lager i applikationen. Use case-mallar med aktörer, flöden, affärsregler. Allt dokumenterat, allt distribuerat till teamet.

Nästan ingen följde dem.

Inte för att de var dåliga. Inte för att de var otydliga. Han vet inte varför -- för feedbacken uteblev. Ingen sa att det var svårt. Ingen sa att det inte fungerade. Ingen sa någonting alls.

Det är den tysta katastrofen. Du bygger strukturen. Du delar den. Du väntar på att den ska adopteras. Och du upptäcker först åtta månader senare, genom att granska varje rad kod, att den aldrig användes.

Utan feedback-loop finns det ingen adoption. Utan adoption finns det ingen struktur. Utan struktur finns det teknisk skuld.

## Vad siffrorna faktiskt säger

Nittio procent av problemen är AI-genererade. Det säger tre saker:

**Det säger att verktyget är neutralt.** AI genererar exakt det du ber om. Om du ber om rätt saker med rätt kontext och rätt förståelse får du extraordinära resultat. Om du inte gör det får du extraordinära problem.

**Det säger att granskning inte är valfritt.** CTO:n hittade problemen för att han läste varje rad. I ett team utan den granskningen hade samma kod passerat obemärkt. Kontrollpunkten är inte ett steg i processen -- den ÄR processen.

**Det säger att utbildning inte handlar om verktygen.** Ingen i teamet behövde lära sig mer om AI. De behövde lära sig mer om hur man uttrycker en uppgift, följer en arkitektur, och validerar ett resultat. Det är inte AI-utbildning -- det är professionell utveckling som råkar involvera AI.

## Året vi slutar låtsas

2024 var året alla började använda AI. 2025 var året alla pratade om produktivitetsvinster. 2026 borde vara året vi slutar låtsas att AI bara skapar värde.

Det skapar värde -- enormt värde -- i rätt händer. Men i fel händer skapar det teknisk skuld snabbare, elegantare, och svårare att upptäcka än något vi sett förut.

Nittio procent av problemen är AI-genererade. Det är inte en anklagelse mot verktygen. Det är en påminnelse om att verktygen bara är så bra som personen som använder dem.

Du äger fortfarande varje rad.

---

*Jag skrev i serie 6 att [du inte kan validera det du inte förstår](/insights/du-kan-inte-validera-det-du-inte-forstar). Det här är beviset: en CTO mätte det.*

*Se även: [Kontrollpunkten är jobbet](/insights/kontrollpunkten-ar-jobbet) (serie 11) och [AI tvingar dig att tänka hårdare](/insights/ai-tvingar-dig-tanka-hardare) (serie 12).*

*Mindtastic om varför domänkunskap multiplicerar AI-output -- [Domain knowledge multiplies AI output](https://mindtastic.se/articles/domain-knowledge-multiplies-ai-output).*

### [Varje möte för sig driver ingenting](https://tomasandre.se/insights/varje-mote-for-sig-driver-ingenting)

It is not Copilot versus protocol versus handwritten notes. It is all meetings together versus each meeting alone. Loose summaries drive no outcomes. The sum of them can.

# Varje möte för sig driver ingenting

Du har Copilot. Du har protokoll. Du kanske skriver egna anteckningar efteråt.

Bra. Inget av det driver ett outcome.

Inte för att formatet är fel. Copilot är inte problemet. Protokollet är inte problemet. Det handskrivna är inte problemet. De är alla lika bra -- och lika otillräckliga var för sig.

Problemet är att varje möte behandlas som komplett i sig självt. Dokumenterat. Arkiverat. Klart.

## Det är inte det ena eller det andra

Det finns en falsk dikotomi i hur vi pratar om mötesdokumentation. Copilot mot protokoll. AI-genererat mot mänskligt. Automatiserat mot genomtänkt.

Det spelar ingen roll. Det är fel fråga.

Rätt fråga är: hänger det ihop med allt annat, eller ligger det löst?

En sammanfattning som ligger löst driver ingenting. En sammanfattning som ingår i en ackumulerad struktur -- tillsammans med standupanteckningar, telefonsamtal, projektmöten, alla de andra tillfällena du träffat samma kontakt -- börjar peka mot något. Den bidrar till ett underlag som faktiskt kan användas för att driva mot ett outcome.

Det är inte det ena eller det andra. Det är båda, tillsammans, över tid.

## Vad som byggs när allt hänger ihop

En kontakt du arbetar med dyker upp i fler sammanhang än ett enda möte. Standups. Projektmöten med fyra andra. Telefon från bilen. Tre meningar i en Teams-kall som egentligen handlade om något annat.

Varje tillfälle ger ett fragment. Fragmenten ensamma räcker inte.

| Mötesformat | Vad det bidrar med |
|---|---|
| Standup (daglig, 10 min) | Prioriteringar, vad som faktiskt blockerar just nu |
| 1:1 (Teams eller fysiskt) | Djup, strategi, det som inte sägs inför gruppen |
| Projektmöte (3-8 pers) | Dynamik, vem som driver, vad som aldrig ifrågasätts |
| Telefonsamtal | Ofiltrerat. Ingen skärm, ingen presentation |
| Fysiskt möte | Energi, pauser, det informella efteråt |
| Workshop (10+ pers) | Vad de väljer att ta plats kring, vad de lämnar till andra |

Inget av dessa räcker ensamt. Tillsammans bildar innehållet i dem en struktur som AI faktiskt kan använda -- för att förbereda, för att identifiera mönster, för att svara på frågan om vad du egentligen försöker uppnå med den här kontakten.

Det är strukturen av allt, sammantaget, som driver mot ett outcome.

## Trösklarna finns

Strukturen är inte lika värdefull vid alla volymer. Det finns trösklar.

| Ackumulerade möten | Ungefärliga filer | Vad det faktiskt möjliggör |
|---|---|---|
| 1-2 | 1-4 | Ingenting. Du vet att kontakten finns. |
| 3-9 | 5-15 | Orientering. Du minns ungefär vad ni arbetar mot. |
| 10-20 | 16-35 | Riktning. Vad som återkommer, vad som hindrar, vart det pekar. |
| 20+ | 36+ | Underlag. AI kan förbereda, identifiera avvikelser, hjälpa dig driva mot outcome. |

Vid 20-pluströskeln händer något. Du behöver inte längre formulera en välskriven fråga. Du kan be AI:n löst: "Vad försöker vi egentligen uppnå här, och vad hindrar oss?" Strukturen bär svaret. Prompten behövs knappt.

## Mina egna siffror

Sedan 2022 samlar jag systematiskt -- sammanfattningar, röstnotat, transkript, förberedelser -- från alla format, om varje kontakt. Tillväxten ser ut så här:

| År | Filer tillagda | Kumulativt |
|---|---|---|
| 2022 | 14 | 14 |
| 2023 | 81 | 95 |
| 2024 | 229 | 324 |
| 2025 | 847 | 1 171 |
| 2026 (april) | 552 | 1 723 |

Under Q1 2025 hade jag nästan inga förberedelsefiler. Under Q1 2026 hade jag 39. Inte för att jag blivit bättre på förberedelse -- utan för att strukturen blivit tillräckligt rik för att förberedelse faktiskt ska leda till något.

Det ramverk jag använder för att fånga allt -- transkript, förberedelser, standups, dagliga dashboards, analytics -- är ett öppet ramverk, fritt att använda: [core-claude-skills](https://github.com/tandregbg/core-claude-skills). Inte ett färdigt system, utan ett utgångslager för den som vill bygga samma typ av struktur.

Jag är inte unik. Jag är strukturerad. Det är skillnaden.

## Inte ett nytt format, ett beslut

Lösningen är inte ett nytt verktyg. Inte bättre Copilot-inställningar eller strängare protokollkrav.

Det är ett beslut om hur du organiserar det du ändå producerar. Varje sammanfattning, protokoll och anteckning som rör samma kontakt hamnar på ett ställe. Inte sorterat per möte. Sorterat per kontakt, per vad du försöker åstadkomma.

Lösa sammanfattningar driver ingenting. Strukturen av alla möten tillsammans kan driva allt.

---

Hur många lösa sammanfattningar har du från dina viktigaste kontakter det senaste året?

Hur många av dem hänger ihop?

---

*Se även: [Din mötessammanfattning är värdelös](/insights/din-motessammanfattning-ar-vardelos) (serie 4) -- det isolerade dokumentets problem; [Tre kanaler, ett ställe](/insights/tre-kanaler-ett-stalle) (serie 5) -- infrastrukturen för att fånga allt i en pipeline; [Allt jag säger hamnar i text](/insights/allt-jag-sager-hamnar-i-text) (serie 2) -- mekanismen; [Kladdigt och krispigt](/insights/kladdigt-och-krispigt) (serie 14) -- hur ackumulerat material leder till precis förståelse.*

*Ramverket bakom siffrorna: [core-claude-skills](https://github.com/tandregbg/core-claude-skills) -- öppet ramverk, fritt att använda.*

### [Den som lyckas med AI är inte den du tror](https://tomasandre.se/insights/den-som-lyckas-med-ai)

On why the person who gets the most from AI isn't the most technical one -- but the one who understands the business outcome. Speed is proven. But speed without direction is just faster waste. The deciding factor is the one nobody talks about.

# Den som lyckas med AI är inte den du tror

Alla antar att den bästa programmeraren får bäst resultat av AI. Det har jag också trott. Men efter ett år av att se människor använda de här verktygen i produktion har jag sett motsatsen.

## Hastigheten är bevisad -- men snabbare på vad?

4-5 gånger snabbare kodning är bevisat. Kanske till och med 10 gånger. Det är inte kontroversiellt längre.

Men en programmerare med 10 gångers hastighet levererar fortfarande inom samma arbetstimmar, samma scope, samma förståelse. Kodningen blev snabbare. Utfallet förändrades inte. Hastighet utan riktning är snabbare slöseri.

## Tre saker som måste finnas

De som får extraordinära resultat har tre saker samtidigt:

**Teknisk förståelse** -- de behöver inte kunna koda, men de behöver förstå vad som händer.

**Historik** -- de känner domänen, systemen, kontexten. De har sett vad som fungerat och vad som gått sönder.

**Affärsutfallsförståelse** -- de bryr sig om resultatet. Inte om koden, inte om verktyget -- utan om vad som faktiskt händer för kunden, för verksamheten, för slutanvändaren.

Den tredje faktorn är multiplikatorn. Utan den producerar de andra två snabbare slöseri. Med den blir samma verktyg, samma LLM -- till något helt annat.

## Utvecklaren som förstår affären

Den bästa tillämparen av AI jag har sett är utvecklaren som har alla tre. Hen kodar, hen känner systemet -- och hen bryr sig om affärsutfallet. En driftperson som bygger ett diagnostikverktyg på tio minuter som ersätter en hel dags arbete. Inte för att verktyget var magiskt -- utan för att hen visste vilken fråga hen skulle ställa. Hen hade levt med problemet i åratal och brydde sig om utfallet.

Det är den ultimata kombinationen. Teknik, historik och affärsutfall i samma person.

Men det finns en dimension till -- en som jag inte hade med i den ursprungliga listan. Förmågan att se det som inte finns än. Inte bara förstå vad kunden behöver, utan föreställa sig en lösning som ingen har bett om. En process som inte existerar. En koppling som ingen ser. Det är den kreativa riktningen som skiljer den som levererar det som efterfrågades från den som förändrar vad som är möjligt. I ett team jag följer levererar en projektledare med verbal, improvisatorisk stil konsekvent bättre och snabbare än en metodisk, dokumentationsfokuserad kollega -- inte för att processen saknas, utan för att han ser målet, inte stegen.

Men de personerna är ovanliga. Och det leder till en viktigare fråga.

## Men de andra smarta människorna då?

Det finns personer i ledande befattning med marginell programmeringsbakgrund som får bättre resultat av AI på en eftermiddag än vad en utvecklare fick under en vecka. Inte för att hen kunde prompta bättre -- utan för att hen visste exakt vad hen ville uppnå.

Projektledare som förstår leveransen. Verksamhetsutvecklare som vet var friktionen sitter. Konsulter som har gjort tjugo migreringar och vet vilka frågor som alltid dyker upp. De har affärsutfallet. De har historiken. Den tekniska förståelsen behöver inte vara djup -- den behöver bara vara tillräcklig.

Och deras råmaterial är inte kod. Det är text. Transkriptioner. Samtal. Möten. Kunddialoger. Det är deras kod. När man börjar behandla den texten med samma systematik som utvecklare behandlar kod -- med kontextfönster, med domänkunskap, med struktur -- då händer något helt annat.

## Ingångspunkten är verbal

Jag har skrivit om det förut -- om [kladdigt och krispigt](/insights/kladdigt-och-krispigt), om hur röstinput bär mer information än något skrivet prompt. När du pratar fritt om ett problem du har levt med i tjugo år kommer associationerna, nyanserna -- allt det som gör att AI faktiskt har något att arbeta med. Det kladdiga inputet är inte slarv. Det är råmaterial som bara den med erfarenhet kan producera.

Verktygen finns redan. Teams spelar in möten. Telefonen spelar in samtal. Men de flesta organisationer har inspelning avstängt som standard -- inte av tekniska skäl, utan av vana. Kundservice spelar in varje samtal. Strategimötet som samlar organisationens dyraste timmar försvinner utan spår.

Och ja -- Teams egen mötessammanfattning finns. Men den är mellanmjölk. En generisk summering som inte förstår vad som var viktigt och vad som var ett sidospår. Utan att du själv lägger tid på att reflektera över vad som faktiskt hände -- vad du hörde, vad du tolkade, vad som avvek -- blir sammanfattningen en platt lista som ingen agerar på. Verktyget gör jobbet. Men bara om du gör ditt först.

## Den satsningen ingen har gjort

Det är naturligt att börja med utvecklingsavdelningen. Det är där verktygen landar först, där hastigheten är enklast att mäta. Men 12-18 månader in i hypen börjar ett annat mönster bli synligt.

Verksamhetens powerusers har Copilot, visst. De har Teams-sammanfattningar. Men det är inte det jag pratar om. Ingen har investerat i att visa dem vad som händer när deras tjugo års erfarenhet möter de här verktygen på riktigt -- inte som en generisk sammanfattning, utan som systematisk behandling av text med samma rigor som utvecklare behandlar kod. Utvecklarna fick investeringen. Verksamheten fick en Teams-licens och en förhoppning.

Men den dagen de börjar -- den dagen någon faktiskt sätter verktyget i händerna på personen som förstår affären, som har levt med kunderna, som vet var friktionen sitter -- då pratar vi inte om 4-5 gånger snabbare. Då pratar vi om världsklass. Tio gånger mer värde. Inte för att verktyget blev bättre, utan för att rätt person äntligen fick använda det.

Den som lyckas med AI är inte den du tror. Det är värt att fundera på.

---

*Jag skrev i serie 16 att [det börjar inte med prompten -- det börjar med dig](/insights/det-borjar-inte-med-prompten). Det här är uppföljningen: vilken "dig" är det?*

*Se även: [Du kan inte validera det du inte förstår](/insights/du-kan-inte-validera-det-du-inte-forstar) (serie 6) och [En person, tusen leveranser](/insights/en-person-tusen-leveranser) (serie 7).*

*Mindtastic om varför domänkunskap multiplicerar AI-output -- [Domain knowledge multiplies AI output](https://mindtastic.se/articles/domain-knowledge-multiplies-ai-output).*

### [De vill inte förstå -- de vill checka av](https://tomasandre.se/insights/de-vill-inte-forsta-de-vill-checka-av)

On why leadership teams don't want to understand AI -- they want to report that they've done something with AI. And why you can actually help with the latter, if you stop explaining the tool and start talking about their people.

# De vill inte förstå -- de vill checka av

Jag sitter i möten med ledningsgrupper. Inte som den som presenterar -- oftare som den som lyssnar från sidan medan någon annan försöker förklara vad vi gör och varför det spelar roll.

Och jag ser samma sak varje gång.

De nickar. De ställer en fråga eller två. De ser engagerade ut. Men när mötet är slut och de går tillbaka till sina kontor har de inte förstått mer än när de kom in.

De ville inte heller förstå. De ville kunna säga att de har gjort något med AI.

## Två drivkrafter som krockar

Det finns ett tryck uppifrån. Från styrelsen, från ägare, från branschpress, från LinkedIn-flödet som aldrig tystnar. Alla pratar om AI. Alla gör AI-satsningar. Om du inte gör det halkar du efter. Det är budskapet, och det fungerar.

Så ledningen behöver checka av rutan. Vi har gjort en AI-satsning. Vi har tagit in en expert. Vi har haft en workshop. Klart.

Men det finns en annan kraft som jobbar i exakt motsatt riktning: ingen vill avslöja att de inte förstår. Inte inför sina kollegor, inte inför styrelsen, inte inför konsulten som sitter mitt emot dem.

Jag har sett det. En chef som nickar igenom en hel presentation utan att ställa en enda följdfråga. Inte för att det var tydligt -- utan för att alternativet var att visa att det inte var det.

Resultatet: de köper det som känns tryggt och rapporterbart. Inte det som faktiskt förändrar något.

## Alla ord är fel

Och här är det som gör det hela nästan omöjligt att navigera.

Säg AI -- och de tänker ersättning. Robotar som tar jobb. Eller ännu värre: de tänker att de redan kan det, för de har ju Copilot.

Säg LLM -- och de har ingen aning om vad du menar. En förkortning till i raden av förkortningar som ingen frågar om.

Säg prompt -- och du signalerar en bransch av lycksökare som säljer kurser om hur du pratar med ChatGPT. Varje konsult som leder med ordet prompt borde ses som en varningsflagga, inte en referens.

Säg språkmodell -- för generiskt. Det låter som lingvistik, inte som verksamhetsutveckling.

Säg kontextfönster -- teknisk jargong som inte ens alla utvecklare förstår intuitivt.

Och här kommer det ironiska: orden som faktiskt beskriver det vi gör -- att ta befintlig erfarenhet och kompetens och förstärka den -- de finns inte i den här vokabulären. Hela språket kring det här ämnet är byggt av och för de som redan förstår. Resten sitter kvar vid bordet och nickar.

## Vad de egentligen behöver höra

Jag har testat. Jag har stått framför grupper och försökt förklara vad en språkmodell gör, hur kontextfönstret fungerar, varför det spelar roll vilken data du matar in. Det fungerar -- för dem som redan har en känsla för det.

För resten låter det som ytterligare en teknikpresentation de måste sitta igenom.

Det som faktiskt landar är något helt annat. Det är när du slutar prata om verktyget och börjar prata om deras folk.

Era medarbetare har tio, tjugo, trettio års erfarenhet. De vet hur era kunder tänker. De vet vilka problem som alltid dyker upp. De vet vad som fungerar och vad som inte gör det -- inte för att de har läst det, utan för att de har levt det.

Det vi pratar om är hur den erfarenheten gör mer. Snabbare. Skarpare. Med mindre friktion mellan det de vet och det som behöver produceras.

Ingen behöver lära sig ett nytt språk. Ingen behöver förstå hur en språkmodell fungerar under huven. De behöver se att det de redan kan har blivit mer värt -- inte mindre.

Det hotar ingen. Det avslöjar ingen. Och det ger ledningen exakt det de vill ha: en checkruta att rapportera uppåt, och en känsla av att deras organisation faktiskt har tagit ett steg framåt.

## Bort från ersättning, mot förstärkning

Det narrativ som har dominerat de senaste två åren handlar om ersättning. Vem som helst kan göra vad som helst. Vi behöver inte de här personerna längre. AI fixar det.

Det är inte bara fel. Det är aktivt skadligt.

Det skapar rädsla hos de som har erfarenheten. Det skapar falsk trygghet hos de som inte har den. Och det säljer en bild av verkligheten som inte stämmer -- att verktyget är det som avgör, inte personen.

Vridningen som behöver ske är enkel att formulera men svår att genomföra: det handlar inte om att köpa in ny kompetens. Det handlar om att frigöra den ni redan har.

En person med tjugo års erfarenhet av er bransch, era kunder, era processer -- den personen har alltid vetat vad som ska göras. Friktionen har varit att omsätta den kunskapen till dokument, till presentationer, till beslut, till handling. Det är den friktionen som har minskat radikalt.

Men bara för den som redan har kunskapen. Utan erfarenhet finns det ingenting att förstärka.

## Det som händer under ytan

Här är det märkliga. När man slutar förklara tekniken och börjar prata om människorna i rummet -- deras erfarenhet, deras kompetens, deras vardagsproblem -- då börjar de faktiskt förstå.

Inte för att någon förklarade hur en språkmodell fungerar. Utan för att de kände igen sig. De hörde sina egna utmaningar beskrivas. De såg sina egna medarbetare i exemplen. Och då öppnas en dörr som ingen teknisk presentation hade kunnat öppna.

Plötsligt frågar de: kan vi testa det här med vår kundtjänst? Kan Sara som har jobbat här i femton år använda det här på sina kundsamtal?

Det är rätt fråga. Och den kom inte för att de förstod verktyget. Den kom för att de förstod sina egna folk.

Förståelsen följer tillämpningen. Inte tvärtom.

## Lycksökarna och de som stannar

Det finns en hel industri av konsulter som säljer AI som magi. Tredagarskurser i prompt engineering. Presentationer fulla av buzzwords. Löften om att vem som helst kan göra vad som helst.

Det är de som har gjort det här samtalet så svårt. De har tagit varje ord -- AI, prompt, LLM -- och laddat det med förväntningar som inte stämmer. Och nu står vi här, de som faktiskt vet vad vi pratar om, och försöker kommunicera med ett språk som redan är förstört.

Lösningen är inte att hitta nya ord. Lösningen är att sluta prata om verktyget och börja prata om jobbet.

Era medarbetare vet redan vad som behöver göras. Det jag gör är att visa hur det kan göras snabbare -- med den erfarenhet som redan finns i huset.

Det behöver inget buzzword. Det behöver bara ett samtal om verkligheten.

---

*Se även: [Det börjar inte med prompten -- det börjar med dig](/insights/det-borjar-inte-med-prompten) (serie 16) och [Du kan inte validera det du inte förstår](/insights/du-kan-inte-validera-det-du-inte-forstar) (serie 6).*

### [Det börjar inte med prompten -- det börjar med dig](https://tomasandre.se/insights/det-borjar-inte-med-prompten)

On why the most important thing you can do with an LLM has nothing to do with how you write the prompt -- but whether you understood the task before you started typing.

# Det börjar inte med prompten -- det börjar med dig

Alla pratar om prompten. Hur du formulerar den. Vilken mall du använder. Vilka systemmeddelanden du skriver. Prompt engineering har blivit en hel disciplin -- som om hemligheten till bra resultat låg i hur du pratar med maskinen.

Det gör den inte.

Jag har sett team använda LLM-verktyg i åtta månader nu. Inte demos, inte workshops -- i produktion, varje dag, på riktiga kundprojekt. Och mönstret som träder fram har ingenting med prompten att göra.

## Det som faktiskt skiljer

Två utvecklare. Samma verktyg. Samma kodbas. Samma uppgift.

Den ena får ut en lösning som hänger ihop, som hanterar edge cases, som följer projektets arkitektur. Den andra får ut något som ser rätt ut men som faller samman vid första granskningen.

Skillnaden är inte prompten. Skillnaden är vad personen förstod innan prompten skrevs.

Den första utvecklaren förstod uppgiften. Inte bara vad som stod i kravet -- utan varför kunden behöver det, vad som kan gå fel, vilka beroenden som finns, vilken kontext som spelar roll. Den förståelsen formade allt som matades in i verktyget. Prompten var en konsekvens av förståelse, inte en ersättning för den.

Den andra utvecklaren läste kravet, kopierade det, och förväntade sig ett resultat. Prompten var perfekt formulerad. Förståelsen saknades.

## Varför LLM-perspektivet spelar roll

När du kallar det AI tänker du: verktyget borde förstå. Det borde resa frågor. Det borde kompensera för det jag missar.

När du kallar det vad det är -- en stor språkmodell, en LLM -- förstår du mekaniken. Modellen processar text. Den förutsäger nästa ord baserat på vad du gav den. Kvaliteten på det du stoppar in bestämmer kvaliteten på det som kommer ut.

Det är inte en metafor. Det är bokstavligen så det fungerar.

Kontextfönstret -- det utrymme där modellen arbetar -- är inte en teknisk detalj. Det är hela spelplanen. Och du bestämmer vad som finns där. Din förståelse av problemet. Din beskrivning av kundens behov. Dina följdfrågor. Din domänkunskap. Allt det är input -- och den inputen är du.

## Lyssnaren slår kodaren

Här är det som överraskade mig mest efter åtta månader.

Det är inte de bästa kodarna som får bäst resultat. Det är de som förstår uppgiften bäst. Och det är två helt olika saker.

En person i teamet är inte en utvecklare i traditionell mening. Men han förstår infrastruktur, han förstår vad kunden behöver, han kan ta en vag idé och göra den konkret. Med LLM-verktyg tar han sig an uppgifter han aldrig hade tackat ja till tidigare -- och levererar. Inte för att verktyget är magiskt, utan för att han vet vad som ska göras. Verktyget hjälper honom göra det.

En annan person med starkare teknisk bakgrund får sämre resultat. Inte för att verktyget sviker -- utan för att förståelsen av uppgiften är ytlig. Kravet läses, men det tolkas inte. Kontexten saknas. Och då spelar det ingen roll hur bra du promptar.

Det är rent soft skills. Att lyssna. Att fråga. Att bygga en bild av vad som faktiskt ska lösas innan du öppnar terminalen.

## Det är därför vi säger LLM

Vi slutade säga AI på Mindtastic. Inte för att vara pedantiska -- utan för att ordet formar beteendet.

Säger du AI förväntar du dig att verktyget tänker. Du lutar dig tillbaka. Du förväntar dig att det fyller i luckorna.

Säger du LLM förstår du att det är en språkmodell. Den processar det du ger den. Om du ger den en vag beskrivning får du ett vagt resultat. Om du ger den din djupa förståelse av problemet, dina specifika frågor, din domänkontext -- då får du något extraordinärt.

Kontextfönster och transkribering. Det är de två viktigaste orden. Inte för att de är komplicerade -- utan för att de beskriver exakt vad som händer. Du transkriberar din förståelse till text. Texten hamnar i kontextfönstret. Modellen arbetar med det.

Du är prompten.

## Vad detta betyder i praktiken

Jag såg det nyligen i ett samtal med en konsult. Hon ska migrera ett tjugotal bolag mellan två affärssystem. Hon är inte utvecklare. Hon har ingen teknisk bakgrund i traditionell mening.

Men hon kan migrering. Hon vet vilka frågor som måste ställas. Hon förstår processerna, riskerna, beroendena.

Så jag sa: spela in samtalet med kunden. Kasta in transkriberingen i en LLM. Ställ sokratiska frågor. Du kommer ha din migrationsplan -- utan att skriva ett enda dokument från scratch.

Hon förstod direkt. För hon förstod uppgiften. Verktyget var sekundärt.

Det är samma sak oavsett om du är utvecklare, konsult, projektledare eller verksamhetsutvecklare. Förstår du vad som ska lösas kan en LLM hjälpa dig leverera det på ett sätt som var omöjligt för två år sedan. Förstår du det inte hjälper ingen prompt i världen.

## Inte skit in, skit ut -- utan du in, du ut

Det finns ett gammalt uttryck: skit in, skit ut. Det stämmer. Men det är för passivt. Det låter som att problemet är lojt material.

Sanningen är mer specifik: det som kommer ut är en reflektion av dig. Din förståelse. Din nyfikenhet. Din förmåga att lyssna och ställa frågor innan du skriver.

Prompten är aldrig startpunkten. Förståelsen är det.

Det börjar inte med prompten. Det börjar med dig.

---

*Mindtastic om terminologin som formar arbetssättet -- [LLM, inte AI: varför det spelar roll](https://mindtastic.se/articles/llm-not-ai-terminology-matters).*

*Se även: [Du kan inte validera det du inte förstår](/insights/du-kan-inte-validera-det-du-inte-forstar) (serie 6) och [Mitt jobb är frågorna](/insights/mitt-jobb-ar-fragorna) (serie 13).*

### [Mustaschmilen -- från röst till produktion](https://tomasandre.se/insights/mustaschmilen-fran-rost-till-produktion)

Mustaschmilen reopened March 27 -- for the second year, on a platform that barely resembles the 2025 version. 70+ improvements. From hardcoded to fully configurable. This is what AI-first looks like over time.

# Mustaschmilen -- från röst till produktion

Den 27 mars 2026 öppnade anmälan till Mustaschmilen -- för andra gången.

Inte som en ny lansering. Som ett återöppnande av ett system som körde i produktion 2025, sedan förbättrades kontinuerligt under ett år, och nu är något fundamentalt annat än det var då.

## Hur det började

2025 byggde vi Tajmad -- anmälningsplattformen bakom Mustaschmilen -- utan en enda kravspecifikation. Ingen PowerPoint. Inget Jira-projekt. Det fanns ett samtal, en röstinspelning, en förståelse för vad evenemanget behövde. Och sedan ett system i produktion.

Det systemet fungerade. Det tog emot riktiga deltagare, hanterade riktiga betalningar, genererade riktiga kvitton. Men det var hårdkodat -- byggt för ett specifikt evenemang, med värden och logik inbakade direkt i koden. Tekniskt sett ett projekt, inte en plattform.

## 70+ förbättringar senare

Mellan den versionen och v1.15.12 som öppnade den 27 mars 2026 ligger över 70 förbättringar, fixes och tillägg. Inget ombyggnadsprojekt. Ingen re-spec. En obruten leveransrörelse där varje förändring hanterades med samma approach som originalet: identifiera vad som behövs, röstbeskrivning, AI-kodning, validering, produktion.

Det är det som syns i versionsnumret. Inte i en pressrelease.

Inget traditionellt mjukvaruprojekt levererar 70+ förbättringar på den tid och budget det här har tagit. Inte för att vi kodar snabbare -- utan för att varje förändring kostar en bråkdel av vad den kostar i en konventionell process. Det gör att förbättringar faktiskt genomförs istället för att hamna i en backlog som aldrig töms.

## Vad plattformen är idag

Det som öppnade den 27 mars är inte längre ett hårdkodat eventsystem. Det är en fullt adminkonfigurerbar plattform:

Arrangören sätter upp evenemang, distanser med individuella deltagartak och datumstyrda pristrappor direkt i adminportalen -- utan att röra kod. Anpassningsbara formulärfält kopplade till specifikt evenemang eller distans. Tilläggsförsäljning i köpflödet: t-shirts med storleksval och produktbilder, Mustaschvän-donation till Mustaschkampen. Kortbetalning via T1K Pay och Swedbank Pay med automatisk momshantering -- 6% på anmälningsavgift, 25% på tillägg, i enlighet med svensk skattelagstiftning. SHA256-verifierade kvitton. Dynamiska bekräftelsemail där varje deltagare får rätt innehåll baserat på exakt vad de köpte. Publik startlista. Realtidsdashboard med UTM-kampanjspårning och konverteringsgrad per källa.

En ny arrangör innebär ett nytt konto och en isolerad databas -- inte ett nytt projekt. Tajmad driver idag Mustaschmilen, Seskarö Trailrun och andra evenemang från en gemensam installation. Deltagarna ser aldrig Tajmad; de ser arrangörens varumärke.

## Från mars till november -- hela livscykeln

Det är lätt att tänka på ett anmälningssystem som "det man använder strax innan loppet". Mustaschmilen 2026 visar att det är fel.

Anmälan öppnade den 27 mars. Loppen går i november: Göteborg den 7:e på Åbytravet, Malmö den 14:e på Jägersro, Stockholm den 21:a på Solvalla. Det är sju månader av deltagardata, kommunikation och betalningsflöden som plattformen hanterar kontinuerligt -- inte bara på tävlingsdagen.

Distanserna är 5 km och 10 km. Barn springer ett eget 1 km-lopp. Den som inte kan delta fysiskt springer Mustaschmilen digitalt under hela november -- på valfri plats, i valfritt tempo, med GPS-spårning och personlig loppkod. Plattformen hanterar båda scenarierna i samma köpflöde och döljer automatiskt fält som inte är relevanta för det digitala formatet.

Det är den tidsdimensionen som gör systemet svårare att bygga än det ser ut. Datumstyrda pristrappor som slår om utan manuell hantering. Early bird som automatiskt övergår till ordinarie pris, ordinarie till sen anmälan. Deltagartak per distans som håller utan att behöva bevakas. Sju månaders kommunikation med deltagare vars köp ser olika ut. Allt autonomt, allt konfigurerbart, allt utan teknisk intervention.

## En person kör det

En operatör hanterar hela Mustaschmilen-operationen. Deltagarhantering, betalningsavstämning, CSV-export till startlista, omskickning av bekräftelsemail -- allt tillgängligt utan teknisk kompetens.

Det är inte ett resultat av att vi snålat. Det är ett resultat av att systemet är byggt så att en person med rätt verktyg har full kontroll. Det är vad AI-first leverans faktiskt innebär: inte snabbare kod, utan system som kräver färre människor att underhålla.

## Vad det betyder

Mustaschmilen 2026 är inte en lansering. Det är beviset på att modellen håller över tid.

Från hårdkodat event-projekt till konfigurerbar multi-tenant-plattform. Från version 1.0 till v1.15.12. Från ett evenemang till en plattform redo för vilken arrangör som helst. Allt utan att byta approach, utan att starta om, utan att skriva en kravspecifikation.

*Se även: [En person, tusen leveranser](/insights/en-person-tusen-leveranser) (serie 7) och [Från samtal till sajt](/insights/fran-samtal-till-sajt) (serie 9).*

*Hela case studien: [t1k.se/case-studies/tajmad](https://t1k.se/case-studies/tajmad)*

### [Kladdigt och krispigt](https://tomasandre.se/insights/kladdigt-och-krispigt)

Two words that name something that had no name. On how I calibrate my own input layer -- and why it determines what comes out.

# Kladdigt och krispigt

En kollega reformulerade det jag gör. Jag hade pratat om röst som råmaterial, om att allt jag säger hamnar i text, om hur information tätnar när den inte filtreras av ett formulär eller en brief. Han lyssnade en stund och sa: "Kladdigt och krispigt."

Jag stannade upp. För det var det. Fyra ord som ersatte ett stycke förklaringar.

Sen lade han till -- nästan i förbifarten -- att det egentligen var "knisprigt". Inte krispigt. Knisprigt. Ett ord han uppfunnit i stunden, en portmanteau som rymde båda lägen på en gång: det organiska och det precisa, sammansmälta till ett. Jag frågade vad han menade. Han sa att krispigt antyder renhet, klarhet, ett slutläge. Knisprigt är i rörelse. Det knäpper till. Det är det ögonblick när ostrukturerat material plötsligt har form -- inte för att strukturen påtvingades, utan för att den uppstod ur materialet.

Jag hade aldrig haft ett ord för det. Nu har jag tre.

## Vad det egentligen handlar om

Det intressanta är att distinktionen inte primärt handlar om vad som kommer ut ur AI. Den handlar om vad du stoppar in.

Det finns två lägen för röstinput, och de är inte utbytbara.

Kladdigt input är när du inte har ett strikt mål. Du beskriver fritt. Du associerar, avviker, återvänder, tappar tråden och hittar den igen. Du låter AI tolka -- semantisk tolkning, antaganden, inferens. Du säger "vi vill förstå var arbete fastnar i flödet" utan att definiera vad fastnar betyder eller vilket flöde du avser. Det är inte slöhet. Det är en medveten strategi. Kladdigt input är kraftfullt när du utforskar, när du beskriver ett problem du inte fullt förstår ännu, när det du vill ha är att AI ska spegla och strukturera det du redan vet men inte har formulerat.

Krispigt -- eller knisprigt -- input är något annat. Det är när du vet exakt vad du vill ha. "Lägg till ett fält för ärendetyp." "Ta bort det här avsnittet." "Flytta prioriteringen till kolumnen längst till vänster." Inga antaganden välkomnas. Inget tolkningsutrymme efterfrågas. Du är kirurgisk. Och AI förväntas vara det med.

Felet de flesta gör är att de blandar ihop lägena. De ger krispiga instruktioner när de egentligen utforskar -- och producerar output som är precis fel på ett träffsäkert sätt. Eller de ger kladdigt input när de behöver ett specifikt resultat -- och undrar varför AI "inte förstår vad de menar."

Knisprigt är Torbjörns ord för det ögonblick när du medvetet rör dig från det ena läget till det andra. Inte en slutprodukt. En övergång.

## Fem minuter innan, fem minuter efter

I praktiken ser det ut så här för mig.

Innan ett samtal spelar jag in en kort röstnotat. Vad vet jag? Vad vet jag inte? Vad är det viktigaste att ta reda på? Det är kladdigt input. Inget strikt mål. Jag tänker högt mot mikrofonen och låter AI sammanfatta och strukturera. Ibland hamnar jag i rätt frågeställning. Ibland avslöjar sammanfattningen att jag hade fel om vad mötet egentligen handlade om.

Efter samtalet spelar jag in ett nytt notat. Det är okularbesikning -- ett tekniskt uttryck jag lånat från byggbranschen, som betyder att verifiera med egna ögon snarare än att förlita sig på ritningar och protokoll. Jag lyssnar inte på inspelningen. Jag sitter inte med transkriptet. Jag berättar för mikrofonen vad som faktiskt hände, vad jag lade märke till, vad som avvek från det jag väntade mig.

Det är fortfarande kladdigt input. Men efterhandskladdigt. Det fångar saker som en transkription aldrig fångar -- tolkningen av pauser, den känsla av att samtalet vände vid ett visst ögonblick, den sak som sades med lite för mycket betoning.

Sen är det krispigt. Specifika uppföljningar. Specifika korrigeringar. Specifika changes. Inte ett dokument, utan en serie präcisa redigeringar av den bild som det kladdiga inputet etablerade.

Ingenting av det är automatiserat. Och det är poängen.

## Det som inte hade ett namn

Jag har skrivit om röst som råmaterial sedan 2023. Om hur ett 15-minuterssamtal bär mer information än ett formulär. Om hur kunden som aldrig skriver ett ord ändå hamnar i en sajt som låter som honom -- precis för att det kladdiga inputet fångade det som ett krav aldrig hade formulerat.

Men jag hade inte ett ord för kalibreringen. För det aktiva valet att vara i kladdigt läge när man utforskar och krispigt läge när man preciserar. Det var en praktik utan ett namn.

Knisprigt är närmast. Det rymmer övergången -- det organiska som knäpper till form utan att tappa sin ursprungliga röst.

AI översätter. Det är vad det gör. Det tar kladdigt input och skapar knisprigt output. Det tar krispigt input och applicerar det präcist. Men vem som bestämmer vilket läge man är i, och vem som bedömer om output faktiskt fångade rätt sak -- det är inte AI. Det är det enda jobbet som inte kan delegeras.

## Varför positionen fortfarande är öppen

Alla pratar om prompting. Om hur man skriver bättre instruktioner. Om agenter och orkestrering.

Ingen pratar om kalibrering av det egentliga ingångsläget -- om att träna sig att veta när man är i ett kladdigt moment och när man behöver knisprigt. Det är en mänsklig kompetens. Det kräver att du förstår vad du faktiskt försöker åstadkomma, inte bara vad du skriver i prompten.

Positionen "röst som primärt ingångslager för AI-arbete" har stått öppen i tre år. Det verkar fortfarande ingen ha tagit den.

Det är märkligare än det borde vara.

---

*Se även: [Allt jag säger hamnar i text](/insights/allt-jag-sager-hamnar-i-text) (serie 2) och [Från samtal till sajt](/insights/fran-samtal-till-sajt) (serie 9).*

*Mindtastic om de tre förhållningssätten i praktiken -- [vibe coding vs AI-orkestrering](https://mindtastic.se/articles/vibe-coding-vs-ai-orchestration).*

### [Mitt jobb är frågorna](https://tomasandre.se/insights/mitt-jobb-ar-fragorna)

On what happened when I stopped writing instructions to AI and started asking myself questions instead.

# Mitt jobb är frågorna

Jag ger inte AI instruktioner längre. Inte som första steg. Innan jag skriver ett enda ord i en prompt ställer jag frågor -- till mig själv. Vad behöver jag egentligen? Vad förstår jag inte? Vad kan gå fel?

Det är inte en teknik jag lärt mig. Det är något jag har gjort så länge att jag inte tänkte på det som en metod. Det var bara så jag jobbade. Sen visade det sig att det har ett namn.

## Det har tydligen ett namn

Någon beskrev det jag gör som sokratiska frågor. Att systematiskt ifrågasätta sina egna antaganden innan man agerar. Att använda frågor för att tvinga fram klarhet istället för att börja med svar.

Jag visste inte att det hette så. För mig var det aldrig filosofi -- det var överlevnad. Trettio år av att bygga system lär dig att det dyraste misstaget inte är att skriva fel kod. Det är att lösa fel problem. Och det enda sättet att veta om du löser rätt problem är att ifrågasätta det innan du börjar.

## Frågor först, alltid

Varje gång jag sätter mig med ett projekt börjar jag likadant. Inte med en prompt. Inte med en plan. Med frågor.

Vad är det faktiska problemet? Inte vad tror jag att problemet är -- vad är det verkligen? Vad antar jag som kanske inte stämmer? Var finns luckorna i min förståelse som jag fyller med vana istället för kunskap?

Det tar ibland fem minuter. Ibland en halvtimme. Ibland leder frågorna till att jag omdefinierar hela uppdraget. Ibland inser jag att jag redan vet lösningen och inte behöver AI:n alls.

Det är poängen. Frågorna är inte förberedelse inför det riktiga arbetet. Frågorna ÄR det riktiga arbetet.

## Instruktioner döljer vad du inte vet

En instruktion ser alltid komplett ut. "Bygg en landningssida med hero-sektion, tre fördelar och kontaktformulär." Det låter specifikt. Det låter genomtänkt.

Men fråga dig själv: Vem är den för? Vad ska besökaren göra efter att ha läst den? Vilken känsla ska den förmedla? Vad skiljer den från hundra andra landningssidor?

Plötsligt är instruktionen inte komplett alls. Den var en fasad av specificitet som dolde strategisk oklarhet. Och AI:n levererar exakt det du bad om -- en fasad.

Jag ser det hela tiden. Människor som skriver allt längre och mer detaljerade promptar. Mer kontext, fler instruktioner, tydligare format. Och resultatet blir marginellt bättre -- för problemet var aldrig instruktionen. Problemet var att de inte hade ifrågasatt sin egen förståelse av vad de ville ha.

## Inte en teknik -- ett förhållningssätt

Det handlar inte om att ställa rätt frågor i rätt ordning. Det finns inget ramverk. Inga fem steg. Det handlar om att vägra delegera det du inte har förstått.

Det är obekvämt. Ingen vill sitta med ett projekt och upptäcka att man inte kan formulera vad man egentligen behöver. Det är lättare att skriva en prompt och se vad som händer. Men "se vad som händer" är inte en strategi -- det är abdikation.

Jag har gjort det här i åratal utan att tänka på det. Det var inte en insikt eller en vändpunkt. Det var ett arbetssätt som långsamt kristalliserades ur erfarenhet av att ha gjort tillräckligt många misstag. Att veta att varje gång jag hoppar över frågorna betalar jag för det senare.

## Ansvar börjar med en fråga

I serie 12 skrev jag att AI tvingar dig att tänka hårdare. Det stämmer. Men det saknade en sak: hur.

Svaret visar sig vara frågor. Inte frågor till AI:n -- frågor till dig själv. Det är mekanismen. Det är så du faktiskt tänker hårdare istället för att bara veta att du borde.

Jag slutade ge instruktioner. Inte bokstavligt -- jag skriver fortfarande promptar varje dag. Men jag börjar aldrig med dem. Jag börjar med frågor. Det har jag alltid gjort. Nu vet jag att det har ett namn. Men namnet spelar ingen roll. Det som spelar roll är att du gör det.

*Se även: [Det börjar inte med prompten -- det börjar med dig](/insights/det-borjar-inte-med-prompten) (serie 16) och [AI tvingar dig att tänka hårdare](/insights/ai-tvingar-dig-tanka-hardare) (serie 12).*

*Mindtastic tränar precis det -- [den sokratiska metoden som AI-arbetsmetod](https://mindtastic.se/articles/socratic-questions-ai-development-method).*

### [AI tvingar dig att tänka hårdare](https://tomasandre.se/insights/ai-tvingar-dig-tanka-hardare)

On why AI doesn't reduce cognitive load but transforms it. And why that's the point.

# AI tvingar dig att tänka hårdare

En senior utvecklare hos en kund testade AI-assisterad utveckling i tre dagar.

Han nådde samma output som manuell kodning. Samma funktionalitet, samma kvalitet, ungefär samma tid. Han var inte snabbare. Han var inte långsammare.

Men han sa en sak som stannade kvar: "Jag var tvungen att tänka på ett helt annat sätt."

## Löftet som inte stämmer

Alla säljer AI som "tänk mindre, gör mer." Det är det universella löftet. Verktyget tar över de tunga kognitiva lyftena och du kan fokusera på det viktiga.

Det stämmer inte.

Det som händer i praktiken är att du slutar skriva och börjar definiera. Du slutar implementera och börjar validera. Du slutar bygga detaljer och börjar granska helheter.

Ingen av de sakerna är lättare. De är svårare. Men de är svårare på ett annat sätt -- och det skiftet är osynligt tills du faktiskt gör det.

## Från byggarmentalitet till granskarmentalitet

I traditionell utveckling tänker du: hur implementerar jag det här? Du bryter ner problemet, skriver lösningen, testar, itererar. Din hjärna jobbar som en byggare.

Med AI tänker du: är det här korrekt? Är det säkert? Är det rätt approach? Gör det vad jag bad om -- eller något subtilt annorlunda? Din hjärna jobbar som en granskare.

Granskarmentaliteten är kognitivt MER krävande. Att bygga är sekventiellt -- du tar ett steg i taget och varje steg har tydlig feedback. Att granska kräver att du håller hela systemet i huvudet samtidigt. Du måste förstå inte bara vad koden gör utan vad den BORDE göra, och sedan jämföra de två.

Det är därför den seniora utvecklaren hos kunden inte blev snabbare. Han bytte kognitivt arbete -- från att producera till att kvalitetssäkra. Och kvalitetssäkring kräver djupare förståelse än produktion.

## Det ingen berättar

Ingen som säljer AI-verktyg berättar att du behöver tänka hårdare. Det passar inte narrativet. Du ska tänka MINDRE. Du ska vara FRIARE. Du ska fokusera på det kreativa medan maskinen gör det tråkiga.

Men valideringen ÄR det kreativa. Och valideringen är inte tråkig -- den är krävande. Den kräver att du ifrågasätter varje förslag, förstår varje konsekvens, ser varje bieffekt.

Om du inte tänker hårdare validerar du inte. Om du inte validerar vibe-codar du. Och vibe-coding är inte en teknik -- det är abdikation av professionellt ansvar.

## Kvaliteten på tänkandet blir flaskhalsen

Här är insikten som förändrar allt: i en AI-assisterad arbetsprocess är det inte verktygen som avgör kvaliteten. Det är kvaliteten på ditt tänkande.

Två personer med samma AI-verktyg får radikalt olika resultat. Inte för att de promptar olika -- utan för att de tänker olika. Den som förstår domänen, som ser arkitekturella konsekvenser, som vet vad som kan gå fel i produktion -- den personen får användbar output. Den som inte har den kunskapen får output som ser bra ut men som inte håller.

Verktyget förstärker det du redan kan. Det kompenserar inte för det du inte kan. Och att kunna innebär inte att veta fakta -- det innebär att kunna tänka om fakta.

## Det kognitiva kravet ÄR ansvar

Det finns en direkt linje från denna insikt till personligt ansvar.

Om AI krävde mindre tänkande kunde man argumentera att vem som helst kan använda den. Att juniorer blir lika bra som seniorer. Att erfarenhet spelar mindre roll.

Men AI kräver MER tänkande -- bara av ett annat slag. Det innebär att erfarenhet blir mer värdefull, inte mindre. Det innebär att den som har byggt system i tjugo år har en fördel som inte kan hoppa över.

Det kognitiva kravet är inte en olycklig bieffekt av AI-assisterad utveckling. Det ÄR ansvar i handling. Att tänka hårdare ÄR att ta ansvar. Det är inte två separata saker -- det är samma sak sedd från olika vinklar.

## Vad det betyder i praktiken

Varje dag sitter jag med AI-genererad kod och ställer frågor. Inte till AI:n -- till mig själv. Förstår jag varför den valde den här lösningen? Ser jag vad som händer vid belastning? Vet jag vad som händer om en extern tjänst inte svarar?

Det är tänkande. Hårt tänkande. Det är inte det tänkande jag gjorde för fem år sedan -- då tänkte jag på implementation. Nu tänker jag på validering, konsekvenser, systemeffekter.

Jag tänker inte mindre. Jag tänker annorlunda. Och annorlunda, i det här fallet, betyder hårdare.

AI tvingar dig att tänka hårdare. Det är inte ett problem. Det är poängen.

*Se även: [Jag är smartare än AI](/insights/jag-ar-smartare-an-ai) (serie 1) och [Mitt jobb är frågorna](/insights/mitt-jobb-ar-fragorna) (serie 13).*

*Mindtastic om tekniken bakom det -- [den sokratiska metoden som AI-arbetsmetod](https://mindtastic.se/articles/socratic-questions-ai-development-method).*

### [Kontrollpunkten är jobbet](https://tomasandre.se/insights/kontrollpunkten-ar-jobbet)

On why I refuse auto-commits, auto-changelogs, and every form of unsupervised automation.

# Kontrollpunkten är jobbet

Jag vägrar auto-commits. Jag vägrar auto-changelogs. Jag vägrar att en agent pushar kod utan att jag läst varje rad.

Det låter ineffektivt. Det låter som att jag inte förstår vad verktygen kan. Det låter som friktion.

Det ÄR friktion. Och friktionen är medveten.

## "Human-in-the-loop" har blivit en checkbox

Branschen har ett uttryck: human-in-the-loop. Det låter bra i presentationer. Det låter ansvarsfullt. Det antyder att det finns en människa någonstans i processen som godkänner.

Men titta närmare. Titta på vad det faktiskt betyder i praktiken hos de som använder uttrycket.

Det betyder att en människa har möjligheten att reagera. Inte att hon gör det. Det betyder att det finns ett steg i flödet där en person KUNDE granska. Inte att granskningen händer. Det har blivit en organisatorisk checkbox -- "vi har human-in-the-loop" -- som skyddar mot ansvarsfrågor utan att faktiskt skydda mot fel.

Det jag gör är något annat. Det jag gör är att kontrollpunkten ÄR arbetet.

## Vad jag faktiskt gör vid varje commit

Varje dag läser jag varje diff. Rad för rad. Jag frågar mig: förstår jag den här förändringen? Behövs den? Är den korrekt? Gör den vad jag bad om -- eller gjorde AI:n något extra som jag inte efterfrågade?

Sedan uppdaterar jag changelog manuellt. Inte för att det tar lång tid. Utan för att ögonblicket där jag formulerar vad som ändrades tvingar mig att förstå vad som ändrades.

Automation tar bort steg. Medveten friktion gör att varje steg räknas.

> "Ordningen är oförhandlingsbar."

En auto-genererad changelog är en sammanfattning av något ingen har granskat. Den ser professionell ut. Den är meningslös. Changelog ska uppdateras medvetet, aldrig automatiseras. Ögonblicket du automatiserar dokumentationen av vad du gjort är ögonblicket du slutar förstå vad du gjort.

## Varför det ser ut som ineffektivitet

Jag förstår invändningen. Verktyg som auto-committar, auto-dokumenterar, auto-pushar sparar tid. Det är sant. Och om måttet är "antal commits per dag" eller "hastighet från idé till deploy" ser min process ut som en flaskhals.

Men det rätta måttet är inte hastighet per transaktion. Det rätta måttet är hastighet per KORREKT transaktion.

Hur många auto-commits behöver reverteras? Hur många auto-genererade changelogs säger ingenting om varför en förändring gjordes? Hur mycket tid går åt att felsöka saker som aldrig borde ha pushats?

Medveten friktion är långsammare per steg. Men varje steg håller. Och summan av steg som håller är snabbare än summan av steg som behöver göras om.

## Varje commit är ett löfte

Det som händer när jag trycker "commit" är inte en teknisk handling. Det är ett löfte. Jag säger: jag har läst det här. Jag förstår det här. Jag står bakom det här.

Ta bort det ögonblicket och du tar bort löftet.

Automation ersätter inte kontrollpunkten -- den eliminerar den. Och den kontrollpunkten är inte ett nödvändigt ont i processen. Den ÄR processen. Den är ögonblicket där professionellt ansvar manifesterar sig i handling.

Det handlar inte om att vara rädd för verktyg. Det handlar om att vägra ge bort det enda som gör att mitt namn på koden betyder något: att jag faktiskt beslutade att den skulle finnas där.

## Daglig praktik

Klockan 8 börjar dagen. AI genererar, föreslår, strukturerar. Jag granskar. Varje förändring, varje fil, varje rad. Sedan bestämmer jag vad som lever och vad som dör.

Det tar längre tid. Det kostar mer energi. Men varje rad som lever efter den processen är en rad jag kan svara för. Och att kunna svara för sitt arbete -- det är inte ineffektivitet.

Det är professionalism.

Kontrollpunkten är inte ett hinder på vägen till leverans. Kontrollpunkten är jobbet.

*Se även: [Jag är smartare än AI](/insights/jag-ar-smartare-an-ai) (serie 1) och [AI tvingar dig att tänka hårdare](/insights/ai-tvingar-dig-tanka-hardare) (serie 12).*

*Mindtastic om var den mänskliga gränsen faktiskt går -- [AI stannar vid PR:en](https://mindtastic.se/articles/ai-stops-at-the-pr).*

### [Det var aldrig en teknikfråga](https://tomasandre.se/insights/det-var-aldrig-en-teknikfraga)

About the time I dismissed a question as magic. And realized neither of us had the answer.

# Det var aldrig en teknikfråga

Jag sa "sluta prata magi."

Det var mitt svar till en affärspartner som frågade om AI kunde analysera en webbplats visuellt -- titta på designen, förstå varumärket, föreslå förändringar. Hon ville koppla ihop ett AI-verktyg med sajten och experimentera med det visuella uttrycket.

Jag förklarade att verktygen hon pratade om handlar om databasåtkomst, inte visuell analys. Att det hon beskrev var science fiction.

Jag hade fel. Inte helt -- men tillräckligt fel för att det spelar roll. Och det intressanta är inte att jag hade fel om tekniken. Det intressanta är vad mitt fel dolde.

## Vad jag fick fel

MCP -- Model Context Protocol -- som jag implementerat i projektet kan mer än databasåtkomst. Det är ett protokoll för hur AI-modeller ansluter till externa system. Databaser är en implementation. Men webbsidor kan skrapas, bilder analyseras, CSS läsas och modifieras. Inte genom magi -- genom att bygga rätt integration.

Min definition var för snäv. Jag hade implementerat MCP för ett specifikt syfte och generaliserade min implementation till hela teknologin. Det är som att säga att en hammare bara kan slå i spikar för att det är det enda jag använt den till.

Hennes instinkt var närmare verkligheten än min förklaring. Riktningen stämde. Och jag avfärdade det -- inte med nyfikenhet, inte med "låt mig kolla", utan med "sluta prata magi." Det var defensivt. Och det var fel.

## Men jag hade också rätt. Delvis.

Det hon ville göra -- experimentera med det visuella uttrycket -- kräver inte bara rätt verktyg. Det kräver att någon vet vad som är bra.

Tekniskt kan vi koppla AI till sajtens CSS, mata in skärmdumpar, låta modellen föreslå förändringar. Det fungerar.

Men frågan kvarstår: vem avgör om förändringen är bättre?

Hon är inte designer. Jag är inte designer. Vi har ingen i projektet med utbildning eller djup kunskap inom visuell design, varumärkesidentitet, eller användarupplevelse. Vi har åsikter. Vi har preferenser.

Det är inte samma sak som att veta.

Vi hade en diskussion om verktyg -- om vad tekniken kan och inte kan -- när den verkliga frågan var en helt annan.

## Gapet ingen ser

Jag har skrivit om det här förut. I "Du kan inte validera det du inte förstår" beskrev jag hur AI förstärker det du redan kan men inte ersätter det du saknar. Att verktyget är en katalysator som behöver bränsle.

Den artikeln hade ett outtalat antagande: att någon i rummet har expertisen. Att det finns en senior, en expert, en person som kan validera.

Vad händer när ingen i rummet kan det?

Det är vår situation. Hon vill förändra det visuella. Jag kan bygga verktygen. Men ingen av oss kan titta på resultatet och med säkerhet säga: det här är bättre. Det här kommunicerar rätt.

Vi kan tycka. Vi kan gissa. Men det är inte validering -- det är intuition utan grund. Och AI gör den intuitionen farligare, inte säkrare, för den producerar resultat som ser övertygande ut.

## Mönstret

Två personer som argumenterar om verktyg när det verkliga gapet är kompetens som ingen av dem har.

Det ser ut som en teknisk fråga: "Kan AI göra det här?" Svaret kan vara ja. Men den underliggande frågan -- "Har vi kunskapen att använda resultatet?" -- ställs aldrig. Den är osynlig för att ingen i rummet ser den.

Vi hade varsin blind fläck. Hennes var att verktygen löser problemet. Min var att problemet inte existerar. Hon överskattade verktygets förmåga att kompensera för saknad kunskap. Jag underskattade verktygets tekniska kapacitet. Tillsammans hade vi nästan hela bilden. Men istället för att lägga ihop den argumenterade vi om varsin halva.

De svåraste gapen att se är de där ingen i rummet har expertisen att ens identifiera gapet. "Du kan inte validera det du inte förstår" förutsatte att du vet att du inte förstår. Den riktigt farliga situationen är när du inte ens vet att det finns något att förstå.

AI löser inte osynliga gap -- den gör dem osynliga längre.

## Korrigeringen

Istället för "sluta prata magi" borde jag ha sagt: "Det du beskriver är möjligt. Men jag tror inte verktyget är problemet. Jag tror problemet är att ingen av oss vet vad vi siktar på."

Det hade öppnat en konversation om vad vi faktiskt behöver -- kanske en designer, kanske en strukturerad process för att utvärdera visuella val. Istället stängde jag samtalet med ett tekniskt svar som inte ens var korrekt.

Vi behöver prata om design. Inte om verktyg, inte om AI, inte om protokoll. Om vem som har kompetensen att avgöra hur sajten ska se ut och kännas. Och om svaret är "ingen av oss" -- vilket jag tror att det är -- så behöver vi hitta den kompetensen. Inte ersätta den med bättre teknik.

Verktyget var aldrig problemet. Kompetensen var det.

Och jag behövde ha fel för att se det.

*Se även: [Du kan inte validera det du inte förstår](/insights/du-kan-inte-validera-det-du-inte-forstar) (serie 6) och [De vill inte förstå -- de vill checka av](/insights/de-vill-inte-forsta-de-vill-checka-av) (serie 17).*

*Mindtastic om varför det kallas beteendeförändring, inte verktygsträning -- [varför vi inte kallar det AI-utbildning](https://mindtastic.se/articles/why-we-dont-call-it-ai-training).*

### [Från samtal till sajt](https://tomasandre.se/insights/fran-samtal-till-sajt)

How a 15-minute phone call became a complete website. And why no one asks how.

# Från samtal till sajt

<div style="margin: 2rem 0 2.5rem; border-radius: 8px; overflow: hidden; box-shadow: 0 8px 32px rgba(0,0,0,0.15); border: 1px solid rgba(255,255,255,0.08);">
<div style="background: #2a2a3a; padding: 8px 16px; display: flex; align-items: center; gap: 8px;">
<span style="width: 10px; height: 10px; border-radius: 50%; background: #ff5f57; display: inline-block;"></span>
<span style="width: 10px; height: 10px; border-radius: 50%; background: #febc2e; display: inline-block;"></span>
<span style="width: 10px; height: 10px; border-radius: 50%; background: #28c840; display: inline-block;"></span>
<span style="flex: 1; text-align: center; color: #888; font-size: 12px; font-family: monospace;">beyondbars.se</span>
</div>
<img src="/static/opt/images/beyondbars-screenshot-960.webp" alt="beyondbars.se -- Anders webbplats, byggd från ett 15-minuterssamtal" style="display: block; width: 100%;">
</div>

Jag ringde Anders. Vi pratade i femton minuter. Han berättade om sin cykelbusiness -- coaching, guidade turer, Billingen som hemmabas, trettio års erfarenhet på mountainbike. Jag spelade in samtalet.

Nästa dag hade han en färdig webbplats. Komplett med hans ord, hans bilder, hans färgpalett -- extraherad ur de nio foton han mejlade mig. Han hade inte skrivit en enda rad text. Inte ett enda formulär ifyllt. Inte en enda skriftlig beskrivning av vad han ville ha.

Sajten läser som om en copywriter skrev den. Men ingen copywriter var inblandad. Texten kommer från vad Anders sa i telefonen och i ett röstmeddelande han skickade efteråt. Hans egna ord, i hans egen röst, omvandlade till webbklar text.

## Paradoxen

Anders beskrev sig själv som "lyhörd och pedagogisk". Det är en formulering som aldrig hade kommit ur en skriftlig brief. I ett formulär hade han skrivit "erfaren MTB-coach" eller "professionell cykelcoach". Men när han pratar -- när han inte tänker på att det han säger ska bli text -- då säger han det som faktiskt stämmer.

Samma sak med "sprida glädjen och kärleken till fler". Det är inte marknadsföring. Det är vad en person säger när de förklarar varför de gör det de gör. Och det blev rubriken.

Det är paradoxen: kunden skrev ingenting, men sajten fångar hans röst perfekt. Bättre än om han hade skrivit det själv.

## Hur det fungerar

Pipelinen är inte komplicerad. Den är bara annorlunda.

Samtalet spelas in. Det transkriberas. AI strukturerar transkriptet till en brief -- affärsidentitet, tjänster, målgrupp, ton, vad som saknas. Bilderna analyseras -- AI plockar ut färger, kategoriserar (hero, porträtt, galleri), kontrollerar upplösning. Från briefen scaffoldas sajten. Från bilderna kommer färgpaletten. Ingen designer valde grönt och brunt -- det kom från skogsstigen i Anders foton.

Sen skickar Anders ett röstmeddelande med sin personliga berättelse. Det blir en ny sektion. Han smsar en korrigering. Den är live på minuter.

Totalt: tjugo minuters aktiv tid från klienten. Under en dag från första samtal till live sajt.

## Cafésamtalet

Jag sitter på café och förklarar det här för en vän. Han jobbar med telekom, inte webbutveckling. Ändå fattar han direkt. "Du menar att samtalet är kravspecen?" Ja. Exakt.

Han frågar hur det skiljer sig från Loveable eller Bolt -- verktygen som genererar gränssnitt från textbeskrivningar. Och det är en bra fråga, för svaret avslöjar hela poängen.

Loveable börjar med vad du skriver. Du måste formulera vad du vill ha. Det är UI först -- du beskriver hur det ska se ut, och sen fyller du på med data efteråt.

Det här börjar med data. Samtalet ger content. Bilderna ger design direction. Briefen ger struktur. Sajten är det visuella lagret ovanpå -- inte tvärtom.

Det är samma princip jag landat i gång på gång de senaste åren: allt börjar med data. Du drunknar i data, och sen strukturerar du. Aldrig tvärtom.

## Positionen ingen har tagit

Alla pratar om AI-kodning. Alla diskuterar agenter, orkestrering, kontextfönster. Men ingen pratar om röst som specifikationslager.

Det är märkligt. För de flesta professionella börjar inte sitt tänkande i text. De börjar med att prata. I möten, i samtal, över lunch. Det är där idéerna formuleras. Det är där kraven egentligen definieras -- i de tangenter och sidospår och halvfärdiga meningar som aldrig hade hamnat i en skriftlig spec.

En 15-minuterssamtal fångar saker som en formulärsvar aldrig gör. Tonfall som avslöjar prioriteringar. Domänreferenser som flödar naturligt men skulle rensas bort i ett dokument. Ärliga självbeskrivningar som ingen skriver i ett textfält.

Och ändå förväntar sig varje AI-verktyg att du börjar med att skriva.

## Samma princip, hela vägen

Det här är inte en ny idé. Det är samma princip jag har skrivit om sedan "Allt jag säger hamnar i text" -- att röst är tätare, att transkription förändrar vad som är möjligt, att tre kanaler kan landa på samma ställe.

Skillnaden är att det nu går hela vägen. Inte bara till en mötessammanfattning. Inte bara till en uppföljningslista. Hela vägen från samtal till live sajt.

Anders ringer mig. Han pratar. Han mejlar foton. Han skickar ett röstmeddelande med korrigeringar.

Han har en webbplats i produktion. Och han har inte skrivit ett ord.

Det borde inte vara anmärkningsvärt. Men det är det. Och det säger mer om var branschen står än vad någon AI-demo gör.

*Mindtastic om skillnaden i praktiken -- [vibe coding vs AI-orkestrering](https://mindtastic.se/articles/vibe-coding-vs-ai-orchestration).*

### [Text är data](https://tomasandre.se/insights/text-ar-data)

Why all professional work is fundamentally about text -- and why that changes everything.

# Text är data

Jag har skrivit sju artiklar. Om ansvar, om röst, om hur jag fångar allt som sägs, om varför generiska sammanfattningar är värdelösa, om infrastrukturen, om kunskap som förutsättning, om vad en person kan leverera. De flesta exemplen har handlat om programvaruutveckling -- kod, system, teknisk leverans.

Det har handlat om kod. Absolut.

Men det har också handlat om exakt samma sak som allting annat jag gör.

## Kod är konversation

När jag pratar med en utvecklare om en kodförändring fångas det samtalet. Kundens formuleringar, de tekniska avvägningarna, det som sades mellan raderna om vad som faktiskt är prioriterat. Transkriptet blir underlag. Koden skrivs. Koden är text.

När jag sitter i ett projektmöte och vi diskuterar tidplan, leverans, förväntningar -- det är exakt samma process. Samtalet fångas. Transkriptet bearbetas. Besluten dokumenteras. Dokumentationen är text.

När jag har ett säljsamtal och kunden beskriver sitt problem -- samma process. Den verbala konversationen fångas. Transkriptet bevarar den. Sammanfattningen blir underlag för offerten. Offerten är text.

När avtalet ska skrivas baseras det på vad som faktiskt diskuterades. Avtalet är text.

När jag pratar med en medarbetare om hur det går, vad som fungerar, vad som inte fungerar -- samma process. Med sekretess kring innehållet, men med exakt samma hantering. Anteckningarna är text.

Kod. Projektdokumentation. Offerter. Avtal. Sammanfattningar. Mötesanteckningar. Det är allt text. Och text är data.

## Data kan processas

Det är insikten som binder ihop allt jag skrivit om. Inte att AI är ett bra verktyg -- det vet alla vid det här laget. Utan att allt professionellt arbete i grunden handlar om text som kan behandlas som data.

Samtalet är text efter transkription. Koden är text. Specifikationen är text. Avtalet är text. Beslutet dokumenteras som text. Uppföljningen är text.

Och all den texten -- oavsett om den började som ett kundsamtal, en kodgranskning, ett säljmöte eller ett medarbetarsamtal -- kan processas med AI. Sammanfattas. Struktureras. Jämföras med tidigare data. Användas som kontext för nästa steg.

Processen jag beskrivit i den här serien ser likadan ut oavsett vad texten handlar om. Fånga samtalet. Bearbeta transkriptet. Granska resultatet. Ta ansvar för vad som kommer ut. Bygg vidare på vad som faktiskt sades.

Det spelar ingen roll om det är en kodförändring eller ett säljsamtal. Det spelar ingen roll om det är en projektuppföljning eller ett medarbetarsamtal. Kedjan är densamma. Ansvaret är detsamma. Processen är densamma.

## Varför det ser ut som separata världar

Folk behandlar kodarbete, projekthantering, försäljning och medarbetarsamtal som fundamentalt olika aktiviteter. Olika verktyg, olika processer, olika människor.

Men från perspektivet "text är data" är det en och samma sak. Det som skiljer dem åt är innehållet och sekretessnivån -- inte processen.

En person som förstår det -- som behandlar allt professionellt arbete som text som kan fångas, bearbetas och användas som data -- den personen jobbar inte i separata världar. Den personen jobbar i ett system.

Och det systemet skalar på exakt det sätt jag beskrivit: en person, med rätt kunskap, rätt kedja, och fullt ansvar i varje steg.

Kod var inte bara exemplet. Kod är en av många former av text. Och text är data.

*Se även: [Allt jag säger hamnar i text](/insights/allt-jag-sager-hamnar-i-text) (serie 2) och [Kladdigt och krispigt](/insights/kladdigt-och-krispigt) (serie 14).*

### [En person, tusen leveranser](https://tomasandre.se/insights/en-person-tusen-leveranser)

How knowledge, chain, and accountability let one person deliver what used to require a team.

# En person, tusen leveranser

Jag levererar ensam det som förut krävde team.

Det är inte skryt. Det är en beskrivning av vad som faktiskt händer när du kombinerar djup erfarenhet, AI som verktyg, och ett system som fångar och bearbetar allt du säger och gör. Skalan förändras. Inte marginellt -- fundamentalt.

Och det är det som gör folk obekväma. Inte att AI finns. Utan vad det innebär för hur arbete organiseras.

## Vad som faktiskt förändrats

Förut var det en begränsning i hur mycket en person kunde leverera. Du hade din tid, din kapacitet, dina händer. Om du ville leverera mer behövde du fler personer. Teamet var lösningen på skalproblemet.

AI har inte tagit bort behovet av kunskap. Det har tagit bort flaskhalsen mellan kunskap och leverans.

Jag kan idag ta ett kundsamtal, fånga hela konversationen, bearbeta den till strukturerad kontext, använda den som grund för kod, text, analys, och leverera resultatet -- i en takt och med en precision som hade krävt tre till fem personer för tio år sedan. Inte för att AI gör jobbet åt mig. Utan för att AI tar bort friktionen mellan det jag redan vet och det som behöver produceras.

Det som förut tog tid var inte tänkandet. Det var översättningen -- från tanke till specifikation, från specifikation till implementation, från implementation till leverans. Varje steg hade friktion. Varje överlämning tappade information. AI komprimerar den kedjan. En person med rätt grund och rätt system gör hela resan själv.

## Förutsättningarna

Det funkar inte utan grund. Det har jag skrivit om -- du kan inte validera det du inte förstår, och AI förstärker bara det du redan har. Det är inte en generell utsaga om att vem som helst ensam kan göra vad som helst.

Det funkar för den som har:

Kunskapen. År av att bygga system, leverera till kunder, leva med konsekvenserna av att ha haft fel. Det är grunden som AI förstärker. Utan den finns det ingenting att skala.

Kedjan. Röst till text, text till struktur, struktur till handling. Förberedelse innan mötet, transkript efter, projektspårning, daglig överblick. Inte ett enda verktyg -- utan en kedja där varje steg bygger på det förra. Det är infrastrukturen som gör att information inte försvinner.

Ansvaret. Varje rad output passerar genom mig innan den lämnar systemet. Det är inte förhandlingsbart, och det är det som gör att skalan inte kompromissar kvaliteten. Mer volym utan kontroll är inte leverans -- det är produktion av problem.

De tre sakerna tillsammans -- kunskap, kedja, ansvar -- är det som gör att en person levererar i en skala som förut var omöjlig.

## Vad det innebär för alla andra

Det här är den obekväma delen.

Om en person med rätt grund kan leverera det som förut krävde ett team, vad händer med teamet? Vad händer med organisationer som är byggda runt antagandet att skalning kräver fler människor? Vad händer med affärsmodeller som säljer tid istället för resultat?

De fungerar inte längre. Inte för att folk blir överflödiga -- utan för att logiken förändras. Värdet sitter inte i antalet personer som jobbar. Det sitter i kunskapen och systemet som en person har. En person som levererar rätt sak snabbare och med högre kvalitet än ett team som koordinerar, överlämnar, och tappar information i varje steg.

Det är inte en teoretisk insikt. Det är min vardag.

Och den som fortfarande säljer timmar istället för resultat, som fortfarande organiserar arbete i team för att det alltid har gjorts så, som fortfarande tror att skalning betyder rekrytering -- de sitter på en affärsmodell som AI håller på att göra irrelevant.

## Inte ensam. En.

Det finns en viktig skillnad. Jag säger inte att jag jobbar ensam. Jag har samarbetspartners. Jag har kunder jag jobbar nära. Jag har relationer som bär mina projekt.

Det jag säger är att leveranskapaciteten -- vad en person faktiskt kan producera och ansvara för -- har förändrats i grunden. En person med rätt kunskap, rätt kedja och fullt ansvar levererar i en skala som förut var förbehållen team.

"En person kan leverera värde till tusen." Det är inte en slogan. Det är vad som händer när du tar AI på allvar, tar din kunskap på allvar, och tar ansvar för varje steg i kedjan.

De som har grunden blir farligt effektiva. De som inte har den köper verktyg och undrar varför ingenting händer.

Skillnaden har aldrig varit större.

*Se även: [Den som lyckas med AI är inte den du tror](/insights/den-som-lyckas-med-ai) (serie 18) och [Jag är smartare än AI](/insights/jag-ar-smartare-an-ai) (serie 1).*

*Mindtastic om vad som faktiskt krävs för att leverera på det sättet -- [bortom prototyperna, produktion först](https://mindtastic.se/articles/beyond-prototypes-production-first-ai-development).*

### [Du kan inte validera det du inte förstår](https://tomasandre.se/insights/du-kan-inte-validera-det-du-inte-forstar)

Why AI amplifies what you already know but doesn't replace what you lack -- and why the hype is dangerous.

# Du kan inte validera det du inte förstår

Det finns en hype just nu som säger att AI demokratiserar allt. Att vem som helst kan göra vad som helst. Att verktyget jämnar ut spelplanen.

Det stämmer inte. Och det är farligt att tro att det gör det.

AI är det bästa verktyget jag någonsin haft tillgång till. Det förändrar vad en enskild person kan leverera. Det accelererar, det strukturerar, det genererar i en takt som var omöjlig för fem år sedan. Allt det är sant.

Men det gör dig inte till något du inte är.

## Katalysatorn behöver bränsle

En katalysator snabbar upp en reaktion. Den skapar den inte. Om det inte finns något att reagera med händer ingenting -- oavsett hur effektiv katalysatorn är.

AI fungerar exakt så. Det tar det du redan kan och förstärker det. Har du lång erfarenhet av att bygga system -- AI gör dig sjukt produktiv. Du vet vad som är rätt svar. Du vet vad som ser bra ut men är fel. Du kan granska, ifrågasätta, och styra. AI ger dig hastighet och volym. Din erfarenhet ger dig riktning och kvalitet.

Men har du ingen grund att stå på finns det ingenting att förstärka. Katalysatorn snurrar i tomgång. Du får output -- massor av output -- men du har inget sätt att veta om det är bra eller dåligt. Och det är värre än att inte ha något alls, för du tror att du har något.

## Hypen som skadar

"Alla kan koda nu." "Alla kan skriva affärsplaner." "Alla kan göra marknadsanalyser." Det är vad hypen säger. Och det låter fantastiskt -- ända tills det hamnar i produktion.

Jag ser det i workshops. Jag ser det i kundprojekt. Människor som ber AI producera något inom ett område de inte behärskar, får tillbaka ett resultat som ser professionellt ut, och accepterar det. Inte för att de är lata -- utan för att de inte har referensramen att se vad som är fel.

En person utan säkerhetskunskap som ber AI skriva autentiseringskod får kod som ser bra ut. Den kompilerar. Den verkar fungera. Men den har hål som en erfaren utvecklare ser på trettio sekunder. Personen utan kunskapen ser ingenting -- för de vet inte vad de letar efter.

En person utan affärserfarenhet som ber AI producera en marknadsanalys får ett dokument med rätt rubriker och övertygande formuleringar. Men antagandena kan vara felaktiga, siffrorna osannolika, och slutsatserna baserade på mönster från träningsdata som inte speglar den specifika marknadens verklighet. Personen utan erfarenheten vet inte var dokumentet sviker.

Valideringen kräver kunskap. Och den kunskapen kan inte AI ge dig.

## Det du har ett humm om

Det finns ett mellanläge som är mer intressant. Det handlar inte bara om det du redan är expert på och det du inte kan alls. Det handlar om det du har ett humm om.

De saker du har en känsla för. De områden du har tillräckligt med erfarenhet för att veta att något inte stämmer, även om du inte kan peka på exakt vad. De frågor du vet att du borde ställa, även om du inte vet alla svaren.

Det är där AI blir riktigt kraftfullt. Inte som ersättning för expertis -- utan som förstärkare av den grundkunskap du faktiskt har. Du vet tillräckligt för att styra. Du vet tillräckligt för att ifrågasätta. Och med AI kan du gå från "jag har ett humm om det här" till genuint djup förståelse -- för verktyget hjälper dig utforska, testa, och strukturera det du redan hade en intuition om.

Det kräver fortfarande att du har den intuitionen. AI skapar den inte åt dig.

## Varför detta är obekvämt

Den här insikten är obekväm för att den går emot berättelsen att AI gör alla lika. Den gör inte det. Den gör de som redan har kunskap och erfarenhet mer effektiva. Den vidgar gapet -- den jämnar inte ut det.

Det är inte ett argument mot AI. Det är ett argument för att vara ärlig om vad verktyget faktiskt gör. Det förstärker dig. Det är fantastiskt om du har något att förstärka. Det är meningslöst -- eller farligt -- om du inte har det.

Och det är ett argument för att investera i kunskap, inte bara i verktyg. I erfarenhet, inte bara i licenser. I att bygga den grund som AI sedan kan förstärka, istället för att hoppas att verktyget kompenserar för grunden som saknas.

## Verkligheten

AI gör dig inte till något du inte är. Det gör dig mer av det du redan är.

Har du decenniers erfarenhet av att bygga system -- AI gör dig till den mest produktiva versionen av den erfarenheten. Har du djup kunskap inom ett område -- AI hjälper dig leverera den kunskapen snabbare, bredare, med högre precision.

Har du ingen grund -- har du fortfarande ingen grund. Men med snyggare output.

Du äger varje rad output. Och du kan inte äga det du inte förstår.

*Mindtastic tränar kombinationen -- [domänkunskap multiplicerar AI-output](https://mindtastic.se/articles/domain-knowledge-multiplies-ai-output).*

### [Tre kanaler, ett ställe](https://tomasandre.se/insights/tre-kanaler-ett-stalle)

The practical infrastructure for capturing everything said -- online meetings, physical meetings, and phone calls in one pipeline.

# Tre kanaler, ett ställe

Jag har skrivit om att allt jag säger hamnar i text. Jag har skrivit om varför din mötessammanfattning är värdelös. Men jag har inte skrivit om den praktiska frågan som avgör om det faktiskt fungerar: hur fångar du allt?

Svaret är inte ett verktyg. Det är tre kanaler som alla landar på samma ställe.

## Onlinemöten

De flesta möten idag sker i Teams, Zoom, Meet. I Teams finns transkription inbyggt -- du kan kopiera texten direkt efter mötet. Det funkar. Det är lite manuellt arbete, lite copy-paste, men det är fullt körbart.

För den som vill ha det mer strömlinjeformat finns Fireflies. Det kopplar in sig i mötena, spelar in, transkriberar. Och det viktiga: det har ett API. Jag hämtar alla mina Fireflies-transkript centralt var femtonde minut. Automatiskt. Inget manuellt steg. Mötet slutar, och inom en kvart ligger transkriptet redo att bearbetas.

Det är inte magi. Det är en integration och ett schemalagt anrop. Men det eliminerar friktionen som gör att folk slutar fånga sina möten efter första veckan.

## Fysiska möten

Inte alla samtal sker framför en skärm. Kundmöten, workshops, luncher där det viktiga sägs mellan huvudrätterna -- det behöver fångas också.

Jag använder record-me på min iPhone eller iPad. Varje fysiskt möte spelas in. Ljudfilen skickas sedan vidare genom samma pipeline som mina Fireflies-möten. Samma ställe, samma bearbetning, samma kedja efteråt. Det spelar ingen roll om mötet hände i Teams eller i ett konferensrum -- transkriptet hamnar på samma plats.

I nyare versioner av iOS finns Apple Intelligence, som ger dig möjlighet att kopiera text direkt från inspelningen. Det förenklar ytterligare. Men principen är densamma: fysiska samtal får inte behandlas annorlunda än digitala. Om du bara fångar onlinemöten tappar du hälften av det som faktiskt sägs.

## Telefonsamtal

Den tredje kanalen som de flesta missar helt. Inkommande och utgående samtal -- de som ofta innehåller de snabbaste besluten, den mest ofiltrerade informationen, de saker folk säger i telefonen som de aldrig hade skrivit i ett mejl.

Jag använder Sonetel som telefonitjänst. De har en funktion för samtalsinspelning, och ett API för att hämta ljudfilerna. Samma princip som Fireflies -- automatisk hämtning, centralt lagrad, redo för transkription.

Det är den kanal folk oftast glömmer. Och det är den kanal där den mest värdefulla informationen ofta finns, just för att telefonsamtal är spontana, oförberedda, ärliga.

## Konvergenspunkten

Tre kanaler. Ett ställe.

Onlinemöten via Fireflies. Fysiska möten via record-me. Telefonsamtal via Sonetel. Alla landar i samma pipeline. Alla blir transkript. Alla blir sökbar, strukturerbar text.

Det är inte tre separata system. Det är tre ingångar till samma system. Och det är poängen -- det spelar ingen roll var samtalet sker. Det fångas. Det bearbetas. Det försvinner inte.

Sedan tar kedjan vid. Förberedelse inför nästa möte baserat på vad som sades i det förra. Sammanfattning, beslut, uppföljning. Projektspårning om det behövs. Daglig överblick. Allt det som jag beskrivit i de andra artiklarna -- men det börjar här. Med att ljudet faktiskt fångas, oavsett kanal.

## Det enda som krävs

Infrastrukturen är inte komplicerad. Det är inte dyrt. Fireflies har rimliga planer. Sonetel likaså. record-me är ett verktyg jag byggt själv, men det finns alternativ.

Det som krävs är beslutet att faktiskt göra det. Att bestämma sig för att inget samtal är för oviktigt för att fångas. Att sluta behandla fysiska möten och telefonsamtal som undantag från systemet.

De flesta som säger att de jobbar med AI-stödda arbetsflöden fångar sina Teams-möten och inget mer. Det är en tredjedel av bilden. Resten försvinner.

Ingenting behöver försvinna. Infrastrukturen finns. Kanalerna finns. Det enda som saknas är vanan.

*Se även: [Allt jag säger hamnar i text](/insights/allt-jag-sager-hamnar-i-text) (serie 2) och [Text är data](/insights/text-ar-data) (serie 8).*

*Mindtastic om hur man bygger den vanan systematiskt -- [hur röst blir strukturerad mötesdokumentation](https://mindtastic.se/articles/voice-to-structured-meeting-documentation).*

### [Din mötessammanfattning är värdelös](https://tomasandre.se/insights/din-motessammanfattning-ar-vardelos)

Why generic AI summaries make the documentation problem worse, and what you should do instead.

# Din mötessammanfattning är värdelös

Du hade ett möte igår. Teams Copilot genererade en sammanfattning. Du skummade igenom den, kanske vidarebefordrade den, och tänkte att mötet var dokumenterat.

Det är det inte.

Det du har är en generisk lista med agendapunkter, namn på folk som pratade, och ett par åtgärdsförslag som låter rimliga men som missar allt som faktiskt avgjorde vad som hände i det rummet.

Och du är inte ensam. Det här är standard nu. Folk accepterar den automatiska sammanfattningen och tror att de har fångat mötet. De har inte fångat någonting.

## Vad sammanfattningen faktiskt säger

Den säger att ni diskuterade punkt tre på agendan. Den säger att Maria nämnde budgeten. Den säger att nästa steg är att "följa upp med kunden."

Det låter korrekt. Det är korrekt -- på ytan. Men ytan var inte där det viktiga hände.

Det som faktiskt avgjorde mötets utfall satt i det som röst bär och text inte fångar -- tonen i Marias röst när hon sa "budgeten funkar nog", omformuleringen som avslöjade det verkliga problemet, pausen innan det avgörande svaret. Det var informationen som förändrade förutsättningarna.

Ingenting av det finns i din sammanfattning. AI:n var med på mötet. Den förstod ingenting.

## Varför generiska sammanfattningar är farliga

Det hade varit bättre om sammanfattningen inte fanns alls. Då hade du åtminstone vetat att mötet inte var dokumenterat. Då hade du kanske skrivit egna anteckningar, eller ringt en kollega och sagt "vad var det egentligen som hände på det mötet?"

Men nu har du ett dokument. Det ser professionellt ut. Det har rubriker och tidsstämplar och åtgärdspunkter. Det ger dig känslan av att informationen är bevarad. Och den känslan är falsk.

Du fattar beslut baserade på en sammanfattning som fångade strukturen men missade substansen. Du följer upp åtgärdspunkter som låter rätt men som missar vad kunden faktiskt menade. Du förbereder dig inför nästa möte med en version av verkligheten som är tekniskt korrekt och praktiskt oanvändbar.

Det generiska sammanfattandet har inte löst dokumentationsproblemet. Det har gömt det. Folk tror att deras möten är fångade, och slutar anstränga sig för att faktiskt förstå vad som sades.

## Vad jag gör istället

Jag fångar hela samtalet. Inte sammanfattningen -- samtalet. Allt som sades, i den ordning det sades, med de pauser och avvikelser och halvfärdiga meningar som faktiskt ingick.

Sedan bearbetar jag transkriptet -- med AI, ja, men inte med en generisk sammanfattningsfunktion som behandlar alla möten likadant. Jag styr vad som extraheras. Jag granskar vad som kommer ut. Jag vet vad som var viktigt i just det samtalet, för jag var där och jag hörde tonerna som text inte fångar.

AI bearbetar. Jag beslutar vad som är korrekt. Det är inte samma sak som att låta Copilot skriva en sammanfattning och acceptera den.

Och sedan bygger kedjan vidare. Förberedelsen inför nästa möte drar från det faktiska transkriptet -- inte från en generisk sammanfattning. Projektspårningen uppdateras med det som verkligen bestämdes -- inte med vad AI:n gissade var åtgärdspunkter. Den dagliga överblicken baseras på vad som faktiskt hände -- inte på en förenklad version av det.

Skillnaden är inte verktyg. Skillnaden är att jag behandlar den verbala konversationen som den rikaste informationskällan jag har. Inte som något som Teams-sammanfattningen kan hantera åt mig.

## Den verbala konversationen är underutnyttjad

Det här handlar inte om att Teams Copilot är dåligt. Det gör vad det är designat för -- producera en snabb generisk överblick.

Problemet är att folk stannar där. De tar den generiska överblicken och behandlar den som dokumentation. De investerar i bättre promptmallar, längre kontextfönster, dyrare AI-modeller -- och ignorerar att den rikaste informationskällan de redan har försvinner varje dag för att ingen fångar den på riktigt.

Den verbala konversationen bär det som ingen skriftlig kommunikation bär. Det spontana, det ofiltrerade, det som folk säger utan att ha planerat att säga det. Det är där de verkliga prioriteringarna avslöjas. Det är där relationsinformationen sitter -- den kontext runt kontexten som avgör om en leverans landar rätt.

Och det behandlas som om Copilot kan sammanfatta det i fem punkter.

Det kan den inte. Sluta låtsas att den kan.

*Se även: [Allt jag säger hamnar i text](/insights/allt-jag-sager-hamnar-i-text) (serie 2) och [Kladdigt och krispigt](/insights/kladdigt-och-krispigt) (serie 14).*

*Genomlysning-formatet på mindtastic.se bygger på exakt detta -- [strategimötet som inte lämnar något spår](https://mindtastic.se/articles/strategy-meeting-leaves-no-trace).*

### [Jag sa det för ett år sedan](https://tomasandre.se/insights/jag-sa-det-for-ett-ar-sedan)

On being too early, context window limitations, and what happens when the market finally catches up.

# Jag sa det för ett år sedan

Nu skriver alla om kontextfönster. Jag är glad. Och lite frustrerad.

Inte för att jag vill ha cred. Det är inte det. Det är mer det där specifika obehaget av att ha sagt något länge, sett att folk inte riktigt lyssnade, och sedan se exakt samma sak börja dyka upp överallt -- formulerat av andra, i andra kanaler, till ett publik som nu är redo att ta emot det.

Det är inte illviljan. Det är att man undrar vad man hade kunnat göra annorlunda. Vad fan är det man missade?

## Vad jag faktiskt sa

Jag körde workshops i slutet av 2024 och under 2025 där kontextfönster var ett av de ämnen deltagarna hade mest fundamentala missuppfattningar om. Organisationer tog beslut baserade på input-siffror. "100 000 tokens -- det måste räcka för hela kodbasen." Det räcker inte. Det handlar inte om kapacitet, det handlar om vad som faktiskt händer med informationen.

Tre konkreta saker jag sa, som nu börjar dyka upp i andras texter:

Att input-kapacitet och faktisk förståelsekapacitet är olika saker. Du kan stoppa in en miljon tokens, men det du faktiskt får användbar respons på är en bråkdel av det. Modellen degraderar -- inte dramatiskt, inte från noll till hundra, men konsekvent. Det som sades i mitten av ett långt sammanhang är statistiskt sett det som modellen hanterar sämst.

Att output-kapaciteten är den verkliga begränsningen ingen pratar om. Alla marknadsför input. Ingen marknadsför output. ChatGPT stoppar runt 4 000 tokens. Claude når 8--10 000 på en bra dag. Du kan fylla systemet med hur mycket du vill -- du kommer fortfarande att få tillbaka fem sidor oavsett hur mycket du stoppade in.

Att kostnadsskillnaden mellan att testa och att faktiskt använda är en storleksordning ingen förutsett. Gratisnivån är designad för att skapa beroende, inte för att utvärdera. Professionell användning kostar det professionell användning kostar. Det är inte ett problem med AI -- det är ett problem med att folk testar i ett läge och beslutar i ett annat.

Det är dessa tre saker. Konkreta. Verifierbara. Saker jag sa i workshops till grupper av senior developers och tekniska ledare under 2024 och 2025.

## Varför ingen lyssnade

Det är lätt att vara bitter om det. Det är mer ärligt att säga att jag förmodligen hade fel om timing.

Marknaden var inte redo. Det är inte publiken man bör klandra när man är för tidigt ute. Smärtan var inte tillräckligt synlig. Kontextfönstret som problem uppstår inte förrän du faktiskt kört mot det i produktionsmiljöer, förklarat för en kund varför AI:n "glömde" instruktionerna från tre sidor sedan, sett kostnadsshocker när man gick från testmiljö till API. De erfarenheterna kräver tid. Marknaden hade inte hunnit skaffa dem.

Det är inte trevlig insikt. Men det är den korrekta.

Att vara tidig innebär att du talar till folk som ännu inte har det problem du löser. Du har svaret, men de har inte frågan ännu. Och det spelar ingen roll hur rätt du har -- timing är inte en akademisk fråga. Det är vad avgör om något faktiskt kommuniceras.

Frustrationen är riktig, och den är berättigad. Men den är inte effektiv att hålla i.

## Vad det betyder nu

Att de nu skriver om det är inte ett hot. Det är ett tecken.

Marknaden rör sig. Det problem jag hade svar på för tolv månader sedan är nu tillräckligt synligt för att mainstream tech-media ska skriva om det. Det är validering -- inte av mig, utan av att det faktiskt var ett verkligt problem och inte ett konstgjort ett.

Och det ger en position att ta nu, snarare än att vänta ytterligare ett år.

Erfarenheten av att ha sett det komma, av att ha kört mot det i produktion, av att ha förklarat det till hundratals senior developers och sett vilka missuppfattningar som faktiskt fastnar och vilka som glider av -- den erfarenheten är inte replikerbar av någon som börjar skriva om det nu. Det är inte arrogans. Det är vad tolv månader av praktisk tillämpning ger.

Positionen är att säga: jag var här ett år innan det blev allmänt. Och det finns ett skäl till det.

## Det jag säger nu som folk inte är redo för

Kontextfönster är historia. Eller snarare -- det är en lösad fråga nu när tillräckligt många börjar förstå begränsningarna. Det som kommer härnäst är det som inte har skrivits om ännu.

Röst som primärt ingångslager. Inte som feature, inte som convenience -- utan som det fundamentala sättet att fylla AI-system med information som faktiskt speglar verkligheten. Det ämnet är öppet på exakt samma sätt som kontextfönster var öppet för tolv månader sedan.

Och AI-orkestrering som yrkeskompetens. Inte som en fördel tidiga adopters har, utan som den grundläggande skillnaden mellan de som levererar och de som experimenterar. Det konversationen håller på att röra sig mot -- men inte är riktigt där ännu.

Om ett år kommer folk att skriva om det. Jag skriver om det nu.

Det är allt man kan göra när man är tidig: fortsätta säga det, med mer precision och mer bevis varje gång, tills marknaden hinner ikapp.

Och sedan inte vara bitter om att det tog ett år.

*Se även: [Du kan inte validera det du inte förstår](/insights/du-kan-inte-validera-det-du-inte-forstar) (serie 6) och [AI tvingar dig att tänka hårdare](/insights/ai-tvingar-dig-tanka-hardare) (serie 12).*

*Mindtastic om gapet mellan vad som demonstreras och vad som faktiskt levereras -- [produktionsverkligheten del 1](https://mindtastic.se/articles/production-reality-gap-part1).*

### [Allt jag säger hamnar i text](https://tomasandre.se/insights/allt-jag-sager-hamnar-i-text)

On voice as raw material, why transcription changes everything, and the position no one has claimed.

# Allt jag säger hamnar i text

Allt jag säger hamnar i text.

Det påståendet har fått folk att titta konstigt på mig. Några nickar. Ingen har frågat vad jag faktiskt menar med det. Och det är exakt problemet.

Jag pratar om en daglig praktik som förändrat hur jag tänker på information -- vad det är, var det uppstår, och vad som egentligen försvinner när vi inte fångar det. Det är inte en feature. Det är inte ett verktyg. Det är ett sätt att se på röst som råmaterial.

Ingen äger den positionen. Och det är konstigt, för det har gått tre år sedan det tekniskt sett blev möjligt.

## Bakgrunden jag bär med mig

2011 visste jag att det borde gå att göra. Jag såg hur mycket information som försvann varje dag -- i möten, i samtal, i de saker folk faktiskt sa i kontrast till vad som hamnade i protokollet efteråt. Problemet var att tekniken inte höll. Taligenkänning var för ostabil, för kontextokänslig, för opraktisk i verkliga arbetsflöden.

Frustrationen byggdes upp under ett decennium. "Varför kan inte tekniken hänga med visionen?"

2022 kom OpenAI Whisper. Och plötsligt gick det att göra det jag alltid vetat borde gå att göra: göra röst till text, text till sökbar data, data till faktisk kontext för beslut. Det var inte revolution. Det var en lösning på ett problem jag burit sedan 2011.

## Hur det faktiskt ser ut

Varje möte spelas in. Varje kundsamtal, varje intern genomgång, varje röstnotat jag pratar in i telefonen -- allt hamnar i text. Det är inte ett komplicerat system. Det är en vana, plus rätt verktyg. Och volymen av transkriberat material jag har att jobba med skiljer sig fundamentalt från vad de flesta jobbar med.

Det finns en viktig skillnad som de flesta inte tänker på: det minne vi skapar direkt är inte samma sak som det minne vi skapar i efterhand. Anteckningar skrivna efter ett möte är inte dokumentation av mötet. De är dokumentation av vad vi väljer att minnas. Vad vi lade märke till. Vad som kändes viktigt nog att skriva ner.

Rösttranskription fångar det faktiska utbytet. Det som faktiskt sades, i den ordning det sades, med de pauser och avvikelser och halvfärdiga meningar som faktiskt ingick i konversationen. Det är ett helt annat råmaterial.

Sedan är det jag som bestämmer vad som händer med det. Vad som sammanfattas. Vad som skickas vidare. Vad som används som kontext nästa gång en liknande fråga dyker upp. Det är inte automatik -- det är ett system. Och skillnaden är att jag jobbar med vad som faktiskt sades, inte med min rekonstruktion av det.

## Varför röst är tätare

Text du skriver är alltid en filtrerad version av vad du tänkte. Du väljer vad som är värt att formulera. I den processen försvinner saker -- det som lät konstigt, det som sades med lite för mycket eftertryck, den biinformationen som egentligen berättar mer om situationen än den information du menar dokumentera.

Röst är tätare. En person som säger "det här behöver vara snabbt" med betoning på snabbt kommunicerar något helt annat än samma ord i ett mejl. En kund som svarar på en fråga med en paus innan svaret -- det är information. En kollega som förklarar ett problem och viker av halvvägs igenom för att ge ett exempel från förra året -- det är information. Ingenting av det hamnar i traditionella mötesanteckningar.

När den informationstätheten blir text som är sökbar, strukturerbar och användbar som AI-kontext förändras spelet. Inte för att AI förstår alla nyanser, utan för att du kan ställa precisa frågor mot ett material som faktiskt speglar vad som hände -- inte mot din minnesbild av det.

## Det ingen har skrivit om

AI-diskussionen just nu handlar om kontextfönster, om prompting, om agenter och orkestrering. Alla pratar om vad som händer med information när den väl är inne i systemet. Ingen pratar seriöst om hur du fyller systemet med rätt information från början.

Röst är ingångslaget som de flesta ignorerar.

Folk samlar skärmdumpar, klistrar in text, skriver ihop beskrivningar av vad de vill ha. Det är filtrering, inte råmaterial. Och det som försvinner i filtreringen är ofta det som avgör om resultatet blir bra eller mediokert.

Det har gått tre år sedan Whisper gjorde det möjligt. Position "röst som primärt ingångslager för AI-arbete" är fortfarande öppen. Ingen har tagit den. Ingen skriver om det från ett personligt praktikperspektiv -- från hur det faktiskt ser ut att köra det varje dag, i verkliga samtal, med verkliga kunder.

Det är märkligt. För det är inte komplicerat. Det är bara en vana de flesta inte har.

## Börja fånga det du redan säger

Du pratar redan. Samtal, möten, tankar du formulerar högt. Den informationen försvinner nu. Den spelas inte in, transkriberas inte, hamnar inte som data.

Det är inte ett tekniskt problem. Verktyg finns. De är billiga. Det är ett vanemässigt problem -- att faktiskt börja behandla röst som råmaterial istället för som ett temporärt informationsformat du inte kan använda till något.

Du säger redan saker som är värda att fånga. Frågan är om du gör det.

Det enda du förlorar när du inte fångar det är allt du redan säger.

*Mindtastic tränar detta steg för steg -- [hur röst blir strukturerad mötesdokumentation](https://mindtastic.se/articles/voice-to-structured-meeting-documentation).*

### [Jag är smartare än AI](https://tomasandre.se/insights/jag-ar-smartare-an-ai)

On accountability, judgment, and why the consequences of being wrong make you smarter than any AI.

# Jag är smartare än AI

Jag är smartare än AI.

Det påståendet har fått folk att skratta. Det har fått folk att nicka. Det har fått folk att vilja diskutera i en timme. Och ingen av dem förstår riktigt vad jag menar.

## Det låter arrogant. Det är det inte.

Ändå vägrar jag automation. Ingen agent jobbar fritt med min kommunikation eller min kod. Jag tar varje beslut manuellt.

Och ändå -- AI är med i allt jag levererar. Kod, text, struktur, analys.

Folk ser detta och tänker att det är inkonsekvent. "Du litar ju på tekniken -- varför litar du inte på den hela vägen?"

Det är precis rätt fråga. Och svaret har ingenting med tekniken att göra.

Det handlar om vad mitt namn betyder.

Jag har jobbat och byggt system i trettio år. Levererat med mitt namn på produkten. Under den tiden har jag lärt mig en sak med absolut klarhet: det spelar ingen roll vem som hjälpte dig bygga det. Om det går sönder är det ditt fel. Om det skadar någon är det ditt fel.

## Så här jobbar jag faktiskt

Klockan 8:00 är dagen igång. Alla möten, alla samtal -- allt som sägs hamnar i text. Det är råmaterial. Sedan är det jag som bestämmer vad som händer med det.

Varje kodmodul diskuteras med Claude. Varje textstruktur testas. Sedan läser jag varje rad som kommer tillbaka. Jag ifrågasätter. Jag ändrar. Och till slut trycker jag på enter.

AI föreslår. Jag bestämmer. Jag pushar.

Ordningen är oförhandlingsbar. AI:n genererar volym och variation. Jag väljer vad som faktiskt levereras. Det beslutet tar jag. Alltid. Utan undantag.

## Varför inte agenter?

Varje gång jag funderat på det stannar jag vid samma fråga: när agenten gör fel -- vem är ansvarig?

Agenter gör fel. Alla system gör fel. Det intressanta är inte om det händer -- det intressanta är vad som händer efteråt. Vem förklarar felet? Vem bär konsekvensen?

Om jag kör en agent som skickar fel kommunikation till en kund kan jag inte peka på verktyget. Mitt namn stod på det. Det är min kod, min deployment, mitt ansvar.

> "Jag tror inte på automation. Jag är fullständigt ansvarig för min kommunikation och kod vilket gör att jag måste ha koll."

Det handlar inte om vilken typ av beslut det är. Det handlar om att det är mitt namn. Inte ett bolags. Inte ett systems. Mitt. Och den dagen en agent levererar något fel med mitt namn på, är det inte agenten som svarar.

Ambiguöst ansvar är oacceptabelt. Det är inte en åsikt. Det är hur jag väljer att leva.

## Vad "smartare" faktiskt betyder

Inte att jag beräknar snabbare. Inte att jag har mer kunskap. På de mätpunkterna förlorar jag kapitalt.

Det jag menar är att jag bär något som ingen AI-modell bär: konsekvensen av att ha fel.

Konsekvens skapar omdöme som inte kan simuleras. När jag fattar ett beslut som visar sig vara fel påverkar det mina relationer, min ekonomi, mitt rykte. Det smärtar. Och den smärtan är information som formar nästa beslut. Det är inte romantik -- det är kalibrering genom verkligheten.

AI:n har ingen hud i spelet. Den lär sig från mönster i träningsdata, inte från att ha levt med konsekvenserna av att ha levererat fel till en kund som litar på dig.

Dessutom bär jag relationskunskap som ingen modell kan hålla. Jag vet vad som nämndes på ett möte för sex månader sedan och som aldrig dokumenterades. Jag förstår kontexten runt kontexten -- det outtalade som avgör om en leverans landar rätt.

Människor löser problem MED AI, inte tvärtom.

## Verktyg, inte magi

Att ha kontroll kostar tid. Jag ska inte låtsas annat. Med agenter hade jag levererat snabbare i vissa avseenden. Det är sant.

Men det jag inte kan kontrollera kan jag inte svara för. Och att svara för mitt arbete är inte ett krav som ställs på mig utifrån. Det är ett krav jag ställer på mig själv.

AI är det bästa verktyget jag haft tillgång till i trettio år. Det förändrar vad en person kan leverera. Den produktivitetsskillnaden är verklig.

Men det är fortfarande ett verktyg.

Du äger varje rad kod, varje mening, varje beslut. AI är bara verktyget. Det är du som är hantverkaren.

Jag är smartare än AI -- inte för att jag beräknar bättre, utan för att jag är den som bär konsekvensen av att ha haft fel.

Det är tillräckligt.

*Se även: [Kontrollpunkten är jobbet](/insights/kontrollpunkten-ar-jobbet) (serie 11) och [AI tvingar dig att tänka hårdare](/insights/ai-tvingar-dig-tanka-hardare) (serie 12).*

*Mindtastic tränar det personliga ansvaret -- [varför validering är det centrala](https://mindtastic.se/articles/ai-validation-imperative-developer-accountability).*