Vill jag att språkmodellen ska vara lösningen, att den ska bygga lösningen, eller behöver jag en kombination? Ju mer tid jag tillbringar med språkmodeller, desto mer inser jag att svaret på den frågan hjälper mig framåt.
För några år sedan köpte jag en reMarkable 2, ett digitalt anteckningsblock med den i särklass bästa skriva på papper-känsla jag hittat i en elektronisk pryl. Men den är också en fantastisk läsplatta. Jag har alltid föredragit att läsa med en penna i handen framför att läsa på en skärm. Den norska plattan erbjuder det bästa av två världar.
Med ett undantag.
Det är fruktansvärt yxigt att flytta de markeringar jag gör på läsplattan in i mitt arkiv med anteckningar. Texterna går att exportera till datorn som pdfer, men där har jag behövt öppna dem en och en och kopiera in alla markeringar för hand till arkivet.
När språkmodellerna började tolka bilder trodde jag att problemet var löst. Men hur många olika kombinationer av prompter och modeller jag än testade så fick jag det inte att fungera.
Jag började med enkla instruktioner: “Läs igenom den här pdf:en och hämta ut alla gulmarkerade meningar.” Ibland fick jag ut en eller ett par av den passager jag hade markerat, ofta missades mycket, inte sällan kom sånt som inte var markerat med. Prompterna blev längre och mer komplexa, men utan någon egentlig skillnad i resultat.
Så jag gav upp och fortsatte exportera, öppna och kopiera manuellt.
När jag började experimentera med Claude Code kring årsskiftet bestämde jag mig för att testa ett nytt angreppssätt. Istället för att be Claude lösa uppgiften direkt i chatten bad jag om ett program som gjorde jobbet. Steg för steg växte en lösning fram. Först i form av ett Python-skript som kördes från kommandoraden. Och som steg två ett “riktigt” program för MacOS, med ett användarvänligt gränssnitt, diverse olika inställningar och annat som gör det än mer funktionellt.
Den avgörande skillnaden: Istället för att låta Claude lösa själva arbetsuppgiften direkt blev språkmodellens roll att bygga lösningen som gör jobbet. Och programkoden som blev resultatet är i sig själv helt fri från artificiell intelligens.
I beskrivningar av språkmodeller – och inte minst i jämförelser med hur traditionell programkod fungerar – används ibland begreppen deterministisk och probabilistisk.
Traditionell programkod är deterministisk, med tydliga regler som ger samma resultat varje gång programmet körs. Ett klick på “Print” skickar en text till skrivaren. Ett klick på kamera-appens avtryckare tar ett nytt foto. 1+1 blir alltid 2.
Språkmodellerna är däremot probabilistiska, system som bygger på sannolikheter. Givet en viss prompt svarar språkmodellen med ett statistiskt rimligt svar, men det går i förväg inte att säga vad det kommer att bli.
Och det är här skillnaden mellan mina två försök att plocka ut markeringar ur pdf:erna ligger. Uppgiften är deterministisk och gick därför att lösa på ett mer robust sätt genom programkod som identifierar gulmarkerade partier matematiskt (letar efter pixlar som är gula), mäter var på sidan de finns och sen hämtar ut den underliggande texten. När jag vill få den uppgiften utförd finns inga statistiska överväganden att göra. Det finns ett rätt sätt att göra det på, och det går att åstadkomma i programkod. Det var därför det probabilistiska försöket – chatten som ibland missade markeringar, ibland hittade på – inte kunde lösa en uppgift som kräver exakthet.
Däremot har inte jag det programmeringskunnandet som behövs för att skriva den koden. Det kan Claude Code hjälpa mig med, när vi tillsammans kan iterera oss fram: AI-agenten gör ett försök att lösa delproblemen på vägen, jag testar och ger feedback.
“Vad är det egentligen för typ av uppgift jag behöver hjälp med?” har blivit en fråga jag stannar vid, åtminstone en kort stund, innan jag börjar bygga nya lösningar. Vissa uppgifter har ett rätt svar. Då vill jag ha kod, inte en kvalificerad gissning.
Men som helhetslösning behöver det inte vara antingen eller. Inte sällan kommer automationer som byggs med hjälp av språkmodeller att innehålla båda ingredienserna.
Mycket av min användning sker fortfarande i chattformat, så klart. En del i Python-script. Men en hel del av det jag bygger i no-code-verktyget n8n är kombinationer.
Ett exempel: Varje fredagsmorgon får jag ett mail från en av mina n8n-agenter som innehåller sammanfattningar av de texter jag sparat till min läslista under veckan men ännu inte hunnit läsa.
Error loading image: Claude hjälper både till med att skapa n8n-flödet och utföra steg i det.
För att åstadkomma det flödet i n8n har Claude Code hjälpt mig att bland annat skriva en hel del javascript till några av delstegen, bland annat för att hämta de texter som fortfarande är olästa i läskön. Det här är steg som är deterministiska, de ska alltid utföras på samma sätt och alltid ge ett förväntat resultat. Att låta en språkmodell avgöra vilka texter som fortfarande är flaggade som olästa är kanske en uppgift som är tillräckligt enkel för att det oftast ska bli rätt. Men jag vill att det alltid ska bli rätt, och för det är traditionell programkod bättre.
Men i själva flödet används Claude också, där de probabilistiska dragen hos en språkmodell är nödvändiga: För att sammanfatta de olästa texterna.
Vi har alltså tre sätt att använda språkmodellerna. Som någon att diskutera med, någon som kan skriva kod, eller en kombination mellan de två. Givet att de flesta av oss först mötte språkmodellerna i chattform och hur kraftfulla språkmodellerna har blivit är det naturligt att första instinkten är att hoppa in i en ny konversation och förvänta sig en lösning på ett problem eller behov där.
Men det är dags att ifrågasätta den intuitionen.
Ska språkmodellen vara lösningen?
Ska språkmodellen skapa lösningen?
Om uppgiften har ett objektivt rätt svar, då är det troligen ett verktyg du behöver. Om uppgiften är en tolkning, sammanfattning, bedömning eller någon form av kreativ output är ett resultat direkt från chatten sannolikt lösningen.
Och om jag får gissa: Ofta är det en kombination du behöver!