Hur jag går från idé till fungerande AI-produkt

De flesta AI-idéer börjar i fel ände. Man väljer en modell, bygger ett chattfält och försöker sedan hitta ett problem som passar. Jag har fått bättre resultat när jag gör tvärtom: börja med ett konkret jobb som redan görs, bryt ned jobbet i steg och bestäm först därefter vilka steg som faktiskt tjänar på en språkmodell. Det låter mindre spektakulärt än att "bygga en AI-agent". Det är också betydligt närmare hur jag numera bygger saker som faktiskt går att använda.

Problemet är nästan aldrig "vi behöver AI"

När jag började bygga egna AI-tjänster var det lätt att formulera idéer som funktioner: en CV-coach, en intervjusimulator, ett verktyg för medborgarskapsfrågor, en Humanizer, en investeringsanalys. Men en funktion är inte samma sak som ett jobb.

Ett bättre första steg är att skriva ned vad användaren försöker få klart. I CV-fallet är jobbet inte "chatta med AI". Det är att gå från ett befintligt CV och en jobbannons till ett bättre, sanningsenligt och mer relevant underlag utan att modellen hittar på erfarenheter. I mitt contentarbete är jobbet inte "skriv en artikel". Det är research, evidens, struktur, text, faktakontroll, redigering, SEO-kontroll och publiceringsbeslut. Den distinktionen styr arkitekturen.

Min första princip: workflow före modell

Jag börjar numera med ett flöde ungefär så här:

1. definiera input,
2. definiera önskat output,
3. lista vilka mellanbeslut som krävs,
4. markera vilka beslut som kan vara probabilistiska,
5. lägg deterministiska regler utanför modellen,
6. definiera vad som måste verifieras innan nästa steg får börja.

För contentmotorn jag byggt för BijoyIQ blev det till exempel inte en stor prompt som skulle "skriva en expertartikel". Flödet blev Researcher → Evidence Auditor → Content Architect → Writer → Fact Checker → Editor → SEO Reviewer → Internal-Link Reviewer → Publisher Gate. Det är mer omständligt. Det är poängen.

Varje steg har ett begränsat ansvar och ett kontrakt för vad det måste lämna vidare. Researchern får inte skriva artikeln. Writern får inte uppfinna källor. Editorn får inte ändra fakta för att få bättre flyt. Publisher Gate får inte kompensera för dålig evidens genom att skriva runt problemet.

Bygg den minsta vertikala skivan

Jag försöker inte längre bygga hela produkten först. Jag bygger en tunn vertikal kedja som kan genomföra ett enda verkligt fall från början till slut. För en AI-CV-produkt kan den första skivan vara:

• användaren laddar upp ett CV,
• systemet extraherar strukturerade fakta,
• användaren väljer en jobbannons,
• modellen föreslår förbättringar,
• varje förändring måste kunna härledas till CV:t eller annonsen,
• användaren godkänner innan den slutliga versionen skapas.

Om just den kedjan inte går att göra tillförlitlig hjälper det inte att lägga på voice, fler modeller eller snyggare UI.

Det här liknar också det synsätt som syns i mer formaliserad spec-driven utveckling: gör krav, scenarier och acceptanskriterier till varaktiga artefakter och låt implementationen härledas från dem, i stället för att låta koden bli den enda sanningen. AI ska inte äga regler som kod kan äga bättre. En av de mest användbara gränsdragningarna är enkel: om regeln kan uttryckas exakt bör den normalt inte lämnas åt modellen. Exempel:

LLM:n kan fortfarande göra bedömningar inne i de enskilda kontrollerna. Men själva state transitionen bör vara deterministisk.

Samma princip återkommer i andra produkter. En modell kan föreslå vilken CV-text som är starkast. Den ska inte få lägga till en arbetsgivare som inte finns i källdatan. En investeringsagent kan resonera om ett case. Den ska inte improvisera aktuella kurser eller rapporterade siffror.

Evals före skala

När en prototyp fungerar är frestelsen att börja bygga fler features. Jag försöker i stället samla de första verkliga felen. Vilka outputs var tekniskt korrekta men ändå dåliga? När missförstod modellen intentionen? När blev den för säker? Vilka edge cases återkom?

De exemplen blir ett litet golden dataset. OpenAI har beskrivit ett liknande arbetssätt för sin interna dataagent: återkommande analyser paketeras som workflows, medan evals används kontinuerligt för att upptäcka regressioner. Det är en bättre mental modell än att testa fem snygga demos och anta att systemet är klart. Min egen tumregel är att en AI-produkt inte är redo för mer autonomi förrän jag kan beskriva de viktigaste felmoderna med konkreta exempel.

Human-in-the-loop ska sitta där felet kostar. "Människa i loopen" betyder inte att en person ska klicka godkänn på allt. Då har man ofta bara byggt en långsammare process.

Jag lägger mänsklig kontroll där något är svårt att reversera, svårt att verifiera automatiskt eller dyrt om det blir fel. OpenAI beskriver samma grundprincip för agentiska system: hög-risk actions och upprepade misslyckanden bör kunna eskaleras till en människa. För mig innebär det till exempel:

• CV: användaren godkänner materiella förändringar.
• Content: Publisher Gate stoppar artiklar med saknad evidens.
• Finansiell analys: systemet får säga "kan inte bedöma".
• Automation: verktygsbehörigheter begränsas till exakt det arbetssteget kräver.

Det är också bättre UX än att låtsas att modellen är säkrare än den är.

Vad jag har slutat göra. Jag försöker undvika fyra saker som såg attraktiva ut i början: 1. Chatbot som standardgränssnitt. Om användaren kan klicka "Matcha mitt CV mot jobbet" är det ofta bättre än att tvinga fram en prompt. 2. En agent som gör allt. När research, beslut, text och QA sker i samma kontext blir det svårt att se var ett fel uppstod. 3. Dyraste modellen överallt. Olika steg har olika kvalitetskrav. Routing är ofta bättre än en universell modell. 4. "Vi fixar kvaliteten senare." Om systemet saknar source-of-truth, evals och stoppregler från början blir det dyrt att lägga till dem när flödet redan automatiserats.

Rollback och idempotens är en produktfråga, inte en backend-detalj

Prototypen bevisar bara den lyckliga vägen: att ett enda exempel kan gå från input till output. Det verkliga arbetet börjar när jag frågar vad som händer vid dålig input, timeout, felaktig tool response, dubbelkörning eller saknad evidens. Om en operation körs två gånger eller måste backas behöver det finnas en plan för det innan agenten får agera i riktiga system — det är inte en backenddetalj, det är produktbeteende. Det verkliga jobbet efter prototypen är att göra fel begripliga, reversibla och testbara. Först därefter ökar jag autonomin.

Min nuvarande byggordning

När jag går från idé till produkt ser ordningen numera ungefär ut så här:

Det är nästan motsatsen till "vibe build tills det ser färdigt ut".

AI gör det möjligt att bygga mycket snabbare. Det gör också att man mycket snabbare kan bygga fel system. Min viktigaste lärdom är därför inte hur man promptar modellen bättre. Det är att flytta så mycket som möjligt av produktens kvalitet från en enskild prompt till arkitektur, evidens, states, testfall och tydliga gränser för vad modellen får bestämma.

Ett exempel på hur jag bryter ned en AI-idé

Säg att idén är: "AI ska hjälpa en jobbsökare att få ett bättre CV." Om jag stannar där är nästan allt odefinierat. Vad betyder bättre? Ska AI skriva om, prioritera, matcha, formatera eller hitta luckor? Får den lägga till sådant som låter rimligt? Ska resultatet vara ett dokument, en poäng eller en chatt? Jag försöker i stället göra problemet explicit.

Input:

• befintligt CV,
• jobbannons,
• eventuella användarsvar,
• vald målroll.

Source of truth: CV:t och det användaren uttryckligen bekräftar. Jobbannonsen får påverka relevans och prioritering, men får inte användas som källa till kandidatens erfarenheter.

Modellens tillåtna uppgifter:

• identifiera relevanta erfarenheter,
• föreslå tydligare formuleringar,
• komprimera eller strukturera,
• markera vilka delar som bör utvecklas,
• ställa frågor när fakta saknas.

Modellens förbjudna uppgifter:

• lägga till arbetsgivare,
• lägga till utbildning,
• lägga till certifieringar,
• tillskriva användaren ansvar eller resultat som inte finns i source of truth.

Acceptanskriterier:

• varje materiellt påstående i slut-CV:t kan härledas till källdata,
• inga obligatoriska CV-sektioner försvinner utan explicit beslut,
• relevanta delar från annonsen påverkar prioritering men inte fakta,
• användaren kan se och godkänna materiella förändringar.

Det är först här modellfrågan blir intressant. En stor modell kan vara bättre på omformulering. En mindre modell kan räcka för klassificering. Kod kan sköta diff, strukturkontroll och export. En embedding-modell kan användas för retrieval. När workflowen är tydlig blir "vilken AI ska jag använda?" flera mindre frågor i stället för en stor.

En annan princip: separera generering från beslut. Språkmodeller är bra på att skapa kandidater. Jag försöker vara mer försiktig med att låta dem fatta det slutliga beslutet när beslutet går att validera med regler eller data.

I en prisanalys kan modellen exempelvis hjälpa till att formulera hypoteser om varför en förändring skett. Men den faktiska beräkningen av bokningsvärde, volymförändring eller elasticitet ska komma från data och kod. I en SEO-pipeline kan modellen föreslå canonical clusters, men live SERP och Search Console avgör vad som faktiskt händer. I en contentpipeline kan modellen föreslå ett claim, men source ledger avgör om det får stå som fakta. Det här ger en arkitektur jag använder ofta:

Poängen är inte att minska AI-användningen. Poängen är att använda modellen där dess styrkor faktiskt är värdefulla.

Hur jag väljer mellan en enkel prompt, en Skill och en agent

Jag har också slutat anta att alla AI-funktioner behöver en agent.

Enkel prompt. Bra när uppgiften är liten, engångsbetonad och outputen går att inspektera direkt. Exempel: sammanfatta ett stycke, föreslå fem rubriker eller omformulera ett mejl.

Skill eller återanvändbar instruktion. Bra när samma metod ska användas om och om igen. Humanizer-projektet är ett tydligt exempel. Där vill jag inte varje gång återförklara researchprinciper, anti-patterns och evals. De ska ligga i ett återanvändbart metodlager.

Agent. Bra när uppgiften kräver verktyg, flera steg, eget arbetsminne eller handoffs. Researcher i contentfabriken är en agent därför att den behöver söka, bedöma källor och lämna ett strukturerat evidenspaket till nästa steg.

Multi-agent. Bra först när separationen skapar verkligt värde. Jag använder det när olika steg behöver olika permissions, kontext eller kvalitetsperspektiv. Om nio agenter bara turas om att skriva samma text har man byggt latency, inte arkitektur.

Designa failure states innan happy path är klar

En annan förändring i mitt arbetssätt är att jag försöker namnge failure states tidigt. För en AI-produkt kan det vara:

• NO_SOURCE
• LOW_CONFIDENCE
• CONFLICT
• PERMISSION_DENIED
• TOOL_FAILURE
• RETRY_LIMIT
• NEEDS_HUMAN
• BLOCKED

Det gör två saker. För det första tvingas jag definiera vad produkten ska göra när AI:n inte lyckas. För det andra blir UX:en bättre, eftersom användaren kan få ett konkret nästa steg i stället för ett generiskt felmeddelande.

Om en contentartikel saknar evidens är lösningen inte "försök generera igen". Lösningen kan vara "två materiella claims saknar primärkälla; research krävs". Om ett CV-underlag är för tunt är lösningen inte att modellen ska bli mer kreativ. Den ska ställa en fråga.

Verktygsaccess är en produktfråga

När AI får använda tools förändras riskprofilen radikalt. En modell som bara skriver text kan hallucinera. En modell som kan skicka, radera, köpa, committa eller publicera kan omsätta hallucinationen i handling. Därför försöker jag skriva tool permissions som en del av produktkraven:

Det är mycket enklare att resonera om än "agenten får använda alla verktyg men ska vara försiktig".

Var jag sätter observability: en produkt är inte produktionsmässig för att den fungerar när jag tittar på den. Jag vill kunna förstå vad som hände efteråt. För varje viktig run vill jag kunna återfinna:

• input,
• vald modell/version,
• instruktion/version,
• retrieved context,
• tool calls,
• output,
• valideringsresultat,
• state transitions,
• kostnad/latens där det är relevant,
• human override.

Det behöver inte vara ett avancerat tracing-system från dag ett. En strukturerad logg är bättre än ingenting. Men utan detta blir det svårt att svara på om en förbättring verkligen förbättrade systemet eller bara gjorde en demo snyggare.

Min definition av "fungerande" har blivit hårdare

Förr kunde jag kalla något fungerande när happy path gav rätt output tre gånger i rad. Nu vill jag åtminstone se:

• ett verkligt användarfall från början till slut,
• definierade failure states,
• testfall för de viktigaste felen,
• tydlig source of truth,
• permissions som matchar uppgiften,
• mätbar kvalitet,
• en väg för mänsklig eskalering,
• en plan för vad som händer när modellen eller leverantören ändras.

Det är fortfarande inte "enterprise complete". Men det är en mycket bättre gräns mellan prototyp och produkt.

Checklistan jag använder innan jag bygger mer: innan jag lägger på nästa feature försöker jag kunna svara ja på följande:

1. Kan jag beskriva användarens jobb i en mening utan ordet AI?
2. Vet jag vilken data som är source of truth?
3. Vet jag vilka steg som måste vara deterministiska?
4. Kan systemet uttrycka att underlaget inte räcker?
5. Har jag verkliga exempel på failure modes?
6. Finns minst ett evalset som kan fånga regression?
7. Har agenten minsta nödvändiga tool access?
8. Loggas viktiga beslut och tool calls?
9. Vet användaren vad som händer när systemet stoppar?
10. Skapar nästa feature verkligt användarvärde eller bara mer AI-yta?

Om flera svar är nej försöker jag fixa systemet innan jag bygger mer.

Vad jag skulle bygga om jag började om från noll: om jag började ett nytt AI-SaaS i morgon skulle jag göra de första veckorna ganska tråkiga med flit. Jag skulle välja ett enda jobb, samla 20–50 verkliga exempel och bygga ett litet evalset innan jag la tid på en bred produktupplevelse. Sedan skulle jag göra en manuell version av workflowen där varje modellsteg går att inspektera. Först när jag ser vilka moment som faktiskt tar tid eller skapar fel skulle jag automatisera dem.

Det betyder också att jag skulle skjuta upp "agentifiering". En agent är värdefull när den behöver välja verktyg eller navigera en uppgift som inte kan uttryckas som ett fast flöde. Om processen i praktiken alltid är steg A → B → C är ett vanligt workflow ofta billigare, enklare att testa och lättare att felsöka.

Jag skulle även designa en leverantörsgräns tidigt. Prompts, schemas, evals och business rules ska helst inte vara så hårt kopplade till en enda modell att ett modellbyte blir en omskrivning av hela produkten. Det behöver inte betyda en avancerad abstraktionslayer. Det kan räcka att modellval och modellparametrar ligger i konfiguration medan produktlogiken ligger någon annanstans.

Fem frågor jag använder för att avgöra om AI ens behövs

Kan regeln beskrivas exakt? Då bör kod sannolikt äga den. Behöver uppgiften förstå ostrukturerat språk eller göra en mjuk bedömning? Då är LLM mer relevant. Kan felet upptäckas innan det når användaren eller ett externt system? Om nej behöver jag hårdare kontroll eller mindre autonomi. Finns tillräcklig source of truth? Om modellen måste gissa kärnfakta är problemet ofta data, inte prompting. Blir användaren snabbare eller bättre, eller har jag bara gjort gränssnittet mer imponerande? Om värdet inte går att beskriva utan att nämna AI är idén ofta omogen.

Vad jag menar med AI-native produktutveckling: för mig betyder det inte att allt styrs av en agent. Det betyder snarare att produkten är designad för att utnyttja probabilistiska komponenter medvetet.

Det innebär att systemet har plats för osäkerhet, kan be om mer information, kan producera flera kandidater, kan evalueras på verkliga exempel och kan förbättras genom att failure cases matas tillbaka till instruktioner, data och tests. Samtidigt hålls hårda regler, auth, betalningar, behörigheter och kritiska beräkningar i deterministiska lager.

Den kombinationen är mycket mer intressant än en ren chatbot. När AI är som bäst märker användaren ofta inte ens var modellen börjar och slutar. De märker bara att ett jobb som tidigare krävde fem manuella steg nu blir ett kontrollerat flöde med bättre stöd.

Det snabbaste jag kan bygga är inte alltid det snabbaste sättet att komma till en fungerande produkt. AI har sänkt kostnaden för implementation så mycket att krav, evidens, evals och produktgränser blivit en större del av jobbet.

Jag börjar därför inte längre med "vilken modell?". Jag börjar med "vilket jobb?", "vilken source of truth?", "hur ser fel ut?" och "vad måste vara sant för att vi ska våga gå vidare?". När de frågorna är besvarade blir modellvalet ofta den enklaste delen.

En sista kontroll: kan produkten bli bättre av sina egna fel? Det är min kanske viktigaste produktionsfråga. Om användaren korrigerar modellen, en reviewer blockerar ett claim eller ett workflow faller på samma edge case tre gånger bör den informationen kunna bli ett nytt eval, en tydligare business rule eller en förbättrad instruktion. Annars samlar systemet erfarenhet utan att lära sig organisatoriskt.

Jag vill därför ha en enkel feedbackloop: incident → klassificerad felmod → regressionstest → ändring → re-run av evalset. Det är först då AI-produkten blir ett system som går att förbättra kontrollerat i stället för en prompt som råkar fungera just nu.

Källor och vidare läsning

• OpenAI: A practical guide to building AI agents
• OpenAI: Inside our in-house data agent
• GitHub Spec Kit: Spec-Driven Development

Relaterade artiklar

• Så använder jag Claude Code för att skriva SQL mot riktiga produktionsdata
• Varför jag börjar med workflow innan jag väljer modell
• Så väljer jag var AI faktiskt skapar värde
• Så designar jag AI-produkter för användare som inte bryr sig om AI
• Varför read-only är mitt defaultläge för nya AI-agenter
• Hur AI har förändrat min build-vs-buy-kalkyl