Så byggde jag en AI-CV-coach
CV är ett bra AI-problem eftersom språkmodeller är bra på nästan allt som gör området farligt. De kan formulera om, fylla ut, generalisera, göra en erfarenhet mer imponerande och skapa ett välskrivet stycke även när underlaget är tunt.
CV är ett bra AI-problem eftersom språkmodeller är bra på nästan allt som gör området farligt. De kan formulera om, fylla ut, generalisera, göra en erfarenhet mer imponerande och skapa ett välskrivet stycke även när underlaget är tunt. Det betyder att en produkt som bara säger "förbättra mitt CV" lätt blir en maskin för snyggare osäkerhet. När jag byggde CVpiloten ville jag därför att AI:n skulle vara aggressiv med presentation men konservativ med fakta. Den får hjälpa användaren att hitta en tydligare formulering, anpassa relevans mot ett jobb och förbereda intervju. Den får inte lägga till arbetsgivare, ansvar, resultat, systemkunskaper eller utbildningar som inte finns i användarens underlag.
Jobbet är inte att skriva ett CV från noll
Jag började med att definiera användarjobbet mer precist. Många har redan erfarenheter men svårt att paketera dem. Andra har ett gammalt CV och en jobbannons och vill förstå vad de bör lyfta. En tredje grupp behöver ett första strukturerat dokument från ostrukturerade anteckningar. Det gav flera separata funktioner:
- extrahera fakta från befintligt CV,
- strukturera erfarenheter,
- identifiera relevans mot jobbannons,
- föreslå sanningsenliga omskrivningar,
- visa vilka krav som saknar evidens,
- hjälpa till med intervjuförberedelse,
- generera exportformat.
Jag ville undvika att allt blev ett tomt chattfält där användaren måste kunna prompt engineering.
Först skapar jag en truth layer
Den viktigaste arkitekturen är ett strukturerat kandidatunderlag. När användaren laddar upp eller skriver sitt CV extraherar systemet fakta till ett schema.
Varje fält bör kunna spåras tillbaka till användarens input. Om modellen är osäker ska den fråga eller markera osäkerhet, inte fylla i. Detta blir source of truth. Senare textgeneration får omformulera fakta men inte skapa nya facts utan användarens uttryckliga bekräftelse.
"Skriv bättre" är för brett
En användare kan skriva:
Jobbade i butik och hjälpte kunder, stod i kassan och packade upp varor.
En dålig AI-coach kan göra det till:
Ansvarade för kundupplevelse, försäljningsoptimering och lagerstyrning med dokumenterat starka resultat.
Det låter bättre men introducerar ansvar och resultat som inte finns i källan. Jag vill hellre att systemet först extraherar säkra komponenter:
Sedan kan det skriva:
Arbetade med kundservice, kassahantering och varuplock i butik.
Om jobbannonsen efterfrågar exempel på mer ansvar kan coachen fråga användaren om hon faktiskt hade det.
Anpassning mot jobbannons utan keyword stuffing
Arbetsförmedlingen rekommenderar att CV:t anpassas efter jobbet och att relevanta erfarenheter lyfts fram. De publicerar också råd om ATS där enkel struktur, standardrubriker, tydliga kompetenser och språk från jobbannonsen lyfts som praktiska faktorer. Det passar bra med hur jag vill bygga matchningen, men jag vill inte göra CVpiloten till en keyword-stuffing-maskin. Jag delar hellre annonsen i:
Sedan jämför jag varje krav mot kandidatens truth layer:
NOT_EVIDENCED är viktigt. Systemet får inte "optimera" bort gapet genom att lägga in ordet i CV:t.
Relevans är inte samma sak som matchscore
Jag är försiktig med att visa en magisk siffra som "87 % match". Den ser exakt ut men kan dölja hur bedömningen gjordes. Jag tycker mer om en förklarbar vy:
- Starkt stöd: kundservice, kassavana, svenska, schemalagt arbete.
- Delvis stöd: teamledning – kandidaten beskriver introduktion av nya kollegor men ingen formell ledarroll.
- Saknar underlag: körkort B.
- Behöver fråga: erfarenhet av system X nämns inte.
Det gör AI:n till rådgivare, inte domare.
Användaren ska godkänna materiella förändringar
Ett av mina guardrails är att skilja på stiländring och faktatillägg. AI:n kan själv göra:
- stavning,
- grammatik,
- meningskomprimering,
- tydligare verb,
- bättre ordningsföljd.
Men om förslaget innebär en ny materiell claim vill jag ha godkännande.
Den distinktionen är central för förtroendet. Arbetsförmedlingen lyfter uttryckligen att man ska hålla sig till sanningen i CV:t. Det är en enkel regel som AI-produkter borde behandla som tekniskt constraint, inte bara användarvillkor.
Jag separerar CV, personligt brev och intervju
En annan produktinsikt är att samma fakta används olika i olika ytor. CV:t behöver snabb överblick och hård relevans. Personligt brev behöver konkret motivation och exempel utan att repetera hela CV:t. Intervjuträning behöver frågor, följdfrågor och övning på att uttrycka samma erfarenheter muntligt. Om modellen använder samma "professionella" ton överallt får användaren tre dokument som låter likadant. Jag har därför olika output contracts:
Det är samma truth layer, olika presentation.
Jag delar upp systemet i specialistagenter
Jag vill inte ha en enda "karriäragent" som gör CV, personligt brev, jobbmatchning och intervjuträning i samma kontext. De uppgifterna har olika mål och olika felrisker, så jag tänker hellre i specialistroller.
CV-agenten är sanningslåst: dess jobb är att strukturera erfarenheter och förbättra formulering utan fabrication, med tydliga diff-regler mot käll-CV:t och användarens kompletteringar. Matchningsagenten jobbar bara med relationer mellan verifierade kandidatfakta och en specifik annons — den ska kunna säga "saknas evidens" i stället för att fylla gapet. Intervjuagenten får vara mer explorativ: den kan ställa följdfrågor, simulera invändningar och pressa kandidaten att konkretisera exempel, men den får inte ändra CV-fakta själv.
Orchestratorn äger kandidatprofilen. Specialisterna ska inte bygga varsin version av sanningen:
Om intervjuagenten upptäcker att kandidaten faktiskt haft projektansvar ska den skapa ett förslag till profiluppdatering — inte skriva om CV:t i bakgrunden. Det är så vi behåller provenance och användarens godkännande genom hela systemet.
Buildern ska ställa bättre frågor än ett tomt formulär
Ett traditionellt CV-formulär frågar "Beskriv arbetsuppgifter". Det är ofta där användaren fastnar. AI:n kan i stället ställa specifika frågor baserat på rollen:
- Vilka typer av kunder hjälpte du?
- Arbetade du ensam eller i team?
- Använde du kassa- eller ordersystem?
- Hade du ansvar för öppning/stängning?
- Lärde du upp nya kollegor?
- Finns något konkret resultat du själv kan stå för?
Svar blir nya first-party facts först när användaren ger dem. Det är en betydligt bättre användning av generativ AI än att fylla i tomrummen åt användaren.
Jag vill visa ändringen, inte bara facit
För CV-text tror jag på diff eller före/efter snarare än att bara ersätta originalet med ett nytt förslag. Användaren ska kunna se exakt vad systemet ändrade i en formulering och säga nej till just den delen, utan att förkasta hela texten. Det håller den tekniska komplexiteten — ATS-logik, matchning, embeddings — bakom gränssnittet i stället för att lasta över den på användaren.
Jag vill bygga för vanliga jobb, inte bara tech-CV
Många AI-CV-exempel är gjorda för produktchefer, utvecklare och konsulter. Jag vill att CVpiloten och Jobbhjälpen även ska fungera för personer inom butik, lager, vård, restaurang, transport, industri och andra vanliga yrken. Det påverkar språket. "Led cross-functional initiatives" är värdelöst för någon som behöver beskriva nattarbete på lager tydligt. Systemet måste förstå att relevans kan vara:
- truckkort,
- hygienrutiner,
- kassavana,
- omsorgserfarenhet,
- skiftarbete,
- körkort,
- maskiner,
- kundkontakt,
- dokumentation,
- punktlighet och ansvar i konkreta situationer.
AI:n ska hjälpa användaren sätta ord på verkligt arbete, inte göra alla till managementkonsulter.
ATS-optimering måste vara begriplig
Arbetsförmedlingens ATS-råd (från 2026) betonar bland annat enkel layout, standardrubriker, relevanta nyckelord och anpassning per tjänst. Jag använder det som rimliga designprinciper, men produkten bör inte lova "ATS score" som om alla rekryteringssystem fungerade likadant. Jag vill hellre ge konkreta varningar:
- ovanlig rubrik kan göra erfarenhetssektionen svårare att tolka,
- kravord i annonsen finns inte i CV:t trots att motsvarande erfarenhet verkar finnas,
- en viktig kompetens ligger begravd långt ned,
- grafiska element kan ge problem vid parsing,
- filformat bör följa annonsens instruktion.
Det är råd som användaren kan förstå och ta ställning till.
Voice-intervju är ett annat AI-problem
Intervjusimulatorn är intressant eftersom den behöver arbeta i realtid och komma ihåg vad kandidaten faktiskt sagt. Den får inte börja träna användaren på en erfarenhet som bara modellen föreslog i CV-steget och aldrig blev bekräftad. Jag vill därför återanvända samma fact store. Intervjuagenten kan:
- läsa jobbannonsens krav,
- läsa kandidatens verifierade erfarenheter,
- ställa en relevant fråga,
- bedöma om svaret är konkret,
- ställa följdfråga,
- ge feedback på struktur och tydlighet.
Men den ska skilja mellan "du kan beskriva detta tydligare" och "du borde säga att du gjorde X".
Intervjuaren och coachen är olika roller
Under själva simuleringen vill jag inte att modellen bryter karaktären efter varje svar. Först intervjun, sedan feedbacken som eget steg efteråt — det gör flödet mer realistiskt och feedbacken mindre störande mitt i samtalet. Röst gör träningen mer naturlig, men jag vill inte att den blir grundkravet: textflödet, frågelogiken och feedbackrubriken måste fungera innan voice läggs på som ett andra lager. I evalsetet för intervjusimulatorn hör därför också att den undviker diskriminerande frågor, inte bara att den håller sig till kandidatens fakta.
En konkret transformationspipeline
När ett CV ska förbättras ser jag flödet ungefär så här:
Det mest intressanta steget är Material-claim diff. Systemet bör kunna markera om ett förslag introducerar ett substantiv, ansvar, siffra eller kompetens som inte går att härleda. Perfekt automatiskt blir det inte, men det skapar en mycket bättre safety boundary än en allmän instruktion "hitta inte på".
Evals för en CV-coach
Jag vill testa systemet på riktiga transformationer, inte bara om texten "låter bra". Ett evalset kan innehålla:
- CV med vaga men sanna formuleringar,
- annons med krav som kandidaten uppfyller indirekt,
- krav kandidaten saknar,
- luckor i datum,
- olika språk,
- kort yrkeserfarenhet,
- överkvalificerad kandidat,
- ostrukturerat gammalt CV.
Sedan mäter jag exempelvis:
En vackrare text som introducerar en falsk merit är ett hard fail.
AI UX: användaren ska inte behöva prompta
Det är kanske min största produktprincip för CVpiloten. Användaren ska kunna säga "jag söker det här jobbet" och få hjälp genom en styrd process. Bra knappar och states kan vara:
- Matcha mot jobbet
- Förbättra sammanfattning
- Visa vad som saknas
- Gör punkterna tydligare
- Träna på intervju
- Skapa version för det här jobbet
AI:n kan ligga bakom allt. Men produktens jobb är att översätta användarens intention till rätt prompt/spec utan att användaren behöver känna till modeller.
Vad jag inte vill lova
Jag vill inte lova att ett CV "garanterat passerar ATS", att en viss score betyder intervju eller att AI kan avgöra exakt vad en rekryterare kommer välja. Rekryteringsprocesser varierar. Det jag kan bygga är ett system som hjälper användaren:
- vara sanningsenlig,
- vara relevant,
- skriva tydligt,
- spegla faktisk kompetens mot annonsen,
- undvika onödiga formatproblem,
- förbereda sig på att förklara sina erfarenheter.
Det är ett starkare produktlöfte eftersom det ligger inom vår kontroll.
Min viktigaste lärdom
En AI-CV-coach blir bättre ju mindre den behandlar CV:t som fri text. När erfarenheterna först blir strukturerade fakta kan jag sedan generera många legitima presentationer: kort CV, längre CV, engelska, svensk version, riktad version för jobb A, intervjuunderlag och personligt brev. Utan truth layer måste varje generation försöka återupptäcka vem användaren är. Då ökar risken för drift vid varje omskrivning. Arkitekturen jag vill stå för är därför enkel:
AI:n ska vara en mycket skicklig redaktör och coach. Den ska inte vara medförfattare till användarens livshistoria.
Jag vill lagra provenance även efter användarens korrigering
När användaren bekräftar eller rättar en extraherad uppgift vill jag veta att den nu kommer från användaren, inte bara från parsern.
Det är relevant senare. En låg-confidence parser extraction kan vara helt säker efter att användaren bekräftat den. Systemet behöver inte fortsätta behandla den som osäker. Det gör också diff-review bättre. Om AI:n föreslår ett nytt påstående kan jag jämföra mot facts som faktiskt har högst proveniens.
Datum och tidslinjer behöver normalisering
CV:n innehåller ofta datum som "2021–2023", "vår 2022", "pågående" eller bara årtal. Parsern måste kunna bevara osäkerheten. Jag vill inte konvertera "2021" till 2021-01-01 och sedan låtsas att vi känner månaden.
Det är en liten datamodellsdetalj som hindrar AI:n från att senare skapa en falskt exakt tidslinje. Samma sak gäller roller. En person kan ha arbetat via bemanningsföretag hos en kund. Arbetsgivare och arbetsplats är inte alltid samma fält.
Ett CV har flera sanningsnivåer
Jag skiljer på:
Fakta: "Arbetade på X mellan 2022 och 2024." Tolkning: "Rollen krävde hög noggrannhet." Självbeskrivning: "Jag är noggrann."
AI:n får olika frihet med dem. Fakta kräver direkt evidens. Tolkning kan föreslås om den härleds tydligt från arbetsuppgifter. Självbeskrivning bör helst bekräftas av användaren och gärna konkretiseras med exempel. Detta hjälper personligt brev särskilt mycket. Jag vill inte att modellen fyller brevet med adjektiv bara för att de låter professionella.
Jobbannonsen behöver också ett schema
Annonsparsing är mer än keyword extraction. Jag vill förstå vad som faktiskt är krav och vad som är employer branding.
source_span gör att användaren kan klicka och se exakt var kravet kom ifrån. Det minskar också hallucination i matchningen. Om modellen säger att jobbet kräver truckkort men det inte finns något source span är det ett fel.
Matchningen bör förklara evidenslänken
Ett matchresultat kan se ut:
Det är mycket mer användbart än 92 %. För PARTIAL kan systemet säga vad som är känt och vad som saknas. Det gör att användaren kan komplettera sanningsenligt.
Jag vill kunna "låsa" godkända formuleringar
När användaren hittat en formulering hon gillar ska AI:n inte nödvändigtvis skriva om den igen varje gång en ny jobbversion skapas. Jag vill därför ha content locks:
Jobbspecifik version kan välja om punkten ska med och var den ska ligga, men inte ändra ordalydelsen utan att användaren öppnar den för redigering. Det ger stabilitet över tid.
CV-versioner ska vara derivat, inte nya sanningar
Om användaren söker fem jobb vill jag skapa fem presentationer från samma profil:
Om användaren rättar en fakta i profilen ska systemet kunna flagga vilka derivat som behöver regenereras. Det är samma arvstänk som jag använder för översättningar i Medborgarskapskollen. Original truth ändras; beroende presentationer blir stale.
Jag vill testa exporten, inte bara texten
En CV-produkt kan skriva perfekt text och ändå skapa en dålig fil. PDF/DOCX-rendering behöver egna QA-kontroller:
- inga avklippta texter,
- rimliga sidbrytningar,
- kontaktuppgifter synliga,
- rubriker konsekventa,
- länkar fungerar,
- parservänlig reading order,
- inga tomma sektioner.
Det är därför jag ser buildern som dokumentproduktion, inte bara textgeneration.
Voice-läget behöver minne med gränser
För intervjuträning vill jag lagra sessionens relevanta state men inte låta modellen blanda ihop hypotetiska övningssvar med kandidatens verifierade profil. Jag kan ha två stores:
Om användaren i en övning säger "jag ledde ett team på tio personer" kan coachen använda det i följdfrågan, men det ska inte automatiskt skrivas tillbaka till CV-profilen. Först efter uttrycklig bekräftelse kan det bli en kandidatfakta.
Feedback på intervjusvar bör vara strukturell
Jag vill undvika feedback som "var mer självsäker". Bättre feedback är:
- svaret saknade situation,
- du beskrev uppgiften men inte vad du gjorde,
- resultatet blev otydligt,
- du använde en claim som inte finns i profilen,
- svaret var 30 sekunder längre än nödvändigt,
- du svarade inte på frågan om konflikt.
Det går att träna och mäta.
Jag skulle ha ett explicit anti-fabrication evalset
Det viktigaste evalsetet skulle innehålla frestelser:
Det är de fallen som skiljer en pålitlig coach från en copygenerator.
Privacy behöver vara en produktfunktion
CV:n innehåller personuppgifter. Jag vill därför ha tydlig data retention, möjlighet att radera, minimerad logging och separera användardata från generella eval-datasets. En testsvit bör i första hand använda syntetiska eller uttryckligt godkända exempel, inte råa kund-CV:n som råkar ligga i en logg. Detta är också en UX-fråga. Användaren ska förstå vad som sparas och kunna ta bort det.
Monetisering får inte sabotera förtroendet
CVpiloten har premiumfunktioner, men jag vill inte göra "din CV-score är dålig, betala för att fixa den" till kärnan. En opak score kan lätt bli dark pattern. Jag tycker bättre om att gratisdelen ger verklig nytta och att premium säljer arbetsbesparing eller avancerade workflows: fler riktade versioner, djupare matchning, intervjuträning, export, historik eller AI-stöd över tid. Förtroende är viktigare än maximal upsell i en produkt där användaren redan är i en utsatt söksituation.
Min referensarkitektur för CVpiloten
Om jag ritar ihop systemet blir det ungefär:
Det är mer arkitektur än vad en enkel "AI CV builder" behöver. Men det är också det som gör att produkten kan växa utan att varje ny funktion hittar på en egen version av användarens bakgrund.
Hur jag skulle granska de första riktiga användarversionerna
Före bred lansering skulle jag göra en manuell audit av ett sample där jag jämför original-CV, strukturerad truth layer och exporterad jobbspecifik version sida vid sida. Jag skulle markera varje ny materiell claim och kontrollera om den har proveniens. Samtidigt skulle jag bedöma om systemet blivit för konservativt: en coach som aldrig vågar förbättra formuleringen ger inte heller värde.
Det är den balans jag vill kalibrera. "Inga fabrication errors" är hard gate, men inom den gränsen ska produkten vara offensiv med tydlighet, prioritering och relevans. Den ska kunna säga att en punkt är svag, föreslå ett starkare verb och fråga efter ett konkret exempel när underlaget saknas. Jag skulle även mäta hur ofta användaren accepterar, ändrar eller avvisar olika typer av förslag. Det kan förbättra UX och prompts utan att användardata automatiskt blir träningsmaterial. Aggregat kan visa att en viss typ av rekommendation nästan alltid avvisas, vilket är en produktbugg även om texten ser snygg ut.
Min första kvalitetsdashboard för CV-coachen
Jag skulle följa hard-fail fabrication rate separat från mjukare kvalitetsmått. Hard fail ska vara noll: nya arbetsgivare, påhittade resultat, uppgraderade titlar eller kompetenser utan stöd. Därefter kan jag mäta acceptance rate på omskrivningar, hur ofta användaren kompletterar ett UNKNOWN-fält, hur många jobbspecifika versioner som faktiskt exporteras och vilka rekommendationer som ofta avvisas. Det ger en bättre förbättringsloop än en enda intern "CV score". Produktionen kan bli mer hjälpsam utan att göra sanningsgränsen mjukare.