Jev: AI-modellen der træffer beslutninger

Jev kan ikke skrive en kundemail. Den kan ikke lave et tilbud eller forklare, hvorfor din strategi halter.

Den kan til gengæld læse kundemailen og besvare tre afgrænsede spørgsmål i samme API-kald: Hvilken afdeling skal have den? Hvor meget haster den? Beder kunden om pengene tilbage?

De tre svar er ikke et afsnit, du først skal fortolke. De er separate data, som et system kan bruge direkte: afdeling: teknisk, haster: 0,92 og refundering: 0,08.

Det er forskellen på Jev og de AI-værktøjer, de fleste kender. ChatGPT og Claude er bygget til at generere. Jev er bygget til at beslutte inden for en ramme, du har sat på forhånd.

Den officielle stavemåde er Jev, ikke JEV. TypeSafe AI lancerede modellen i september 2026 som den første i en ny kategori, de kalder System One models. Simon Willison foreslår det mere jordnære navn decision models. På dansk kalder jeg dem beslutningsmodeller.

Jev forklaret på ét minut

En almindelig LLM får en prompt og fortsætter teksten ét token ad gangen. Det er grunden til, at den kan skrive et svar, forklare en plan og producere kode. Det er også en langsom og relativt dyr måde at få svaret ja på.

Jev får i stedet to ting:

1. En tilstand. Den tekst og de data, der beskriver sagen lige nu. Det kan være en kundemail, en produktbeskrivelse, et dokument eller en tabel med synlige knapper i en browser.
2. Et sæt spørgsmål. Du definerer på forhånd, hvilke vurderinger systemet har brug for, og hvilke svar der er tilladt.

Jev svarer i et fast format og viser chancen for hvert valg. Din software bestemmer så, hvad der skal ske.

Tekst og data → afgrænsede spørgsmål → valg og sandsynligheder → kode eller menneske handler

Forestil dig en fælles supportindbakke. En besked lyder: “Stripe har fejlet i tre dage. Vi mister salg. Hjælp hurtigst muligt.”

I samme kald kan Jev vælge teknisk frem for salg og fakturering, score frustrationen og vurdere, om sagen haster. Et workflow kan lægge beskeden øverst i den tekniske kø. Hvis modellen er usikker, kan den sende sagen til en medarbejder uden at gætte.

Jev er derfor ikke et færdigt supportværktøj. Den er en komponent, som kan give almindelig software en form for sproglig dømmekraft.

Tre typer svar: Choice, Noul og Score

TypeSafe har gjort svarrummet bevidst lille. Jev kan levere tre typer vurderinger.

Choice vælger mellem kendte muligheder

Du giver modellen en liste og en forklaring til hver mulighed. Det kan være afdelinger, sagstyper, godkendelsesveje eller næste handling i et system.

Svaret viser både vinderen og chancen for hvert valg. Hvis teknisk får 85 procent og fakturering 15 procent, kan systemet se, hvor tæt valget var.

Noul svarer med sandsynligheden for ja

Navnet kommer fra Bernoulli-fordelingen, ifølge TypeSafes direktør. I praksis kan du læse en Noul som et tal mellem nej og ja.

Spørgsmålet kan være: “Beder kunden om en refundering?” Et svar på 0,95 betyder ikke, at sagen er fem procent refundering. Det er modellens sandsynlighed for, at udsagnet er sandt.

Score placerer sagen på en beskrevet skala

Her definerer du niveauerne. For frustration kan de være rolig, frustreret og meget vred. Jev returnerer en vægtet score, som også kan ligge mellem niveauerne.

En Score er ikke en lommeregner. Den beskriver en grad på en semantisk skala. Brug almindelig kode, hvis du skal lægge tal sammen eller regne en dato ud.

Confidence er ikke det samme som korrekthed

Choice og Score kommer med en confidence mellem 0 og 1. Tallet beskriver, hvor samlet eller spredt sandsynligheden er over de mulige svar.

Hvis én mulighed står klart, er confidence høj. Hvis tre muligheder ligger tæt, er den lav. Noul har ikke et særskilt confidence-tal, fordi selve svaret allerede er en sandsynlighed mellem nej og ja.

Confidence er nyttig, fordi du kan bygge tvivl ind i systemet:

• Høj sikkerhed: udfør en lille og reversibel handling automatisk
• Mellem sikkerhed: foreslå et valg, men bed en medarbejder bekræfte
• Lav sikkerhed: stop og send sagen til manuel behandling

En confidence på 0,95 er stadig ikke et bevis. Kalibrering virker på grupper af mange svar. Den lover ikke, at et bestemt svar er korrekt.

I Ray Amjads videodemo svinger den samme vurdering af en falsk faktura med to til tre point mellem kørsler. Da han tilføjer klare tegn på svindel til kriterierne, stiger svaret fra cirka 85 til 94 procent. Formulering og gentagelser betyder stadig noget.

Et typed svar forhindrer et ugyldigt format. Det forhindrer ikke et gyldigt, men forkert svar. Confidence er et signal til routing, ikke en garanti.

Jev er ikke en ny ChatGPT

Jev og en LLM kan læse den samme kundemail. De er bygget til forskellige job.

Det ene erstatter ikke det andet. En stærk løsning kan bruge begge.

En LLM kan læse en rodet mail og skrive et svar. Jev kan kontrollere, om svaret adresserer kundens problem, om tonen bryder en regel, og om sagen bør sendes til et menneske. Almindelig kode kan slå kunden op, tjekke beløbsgrænser og sende beskeden.

Det giver tre lag:

1. Kode håndterer fakta, regler, beregninger og handlinger
2. Jev håndterer smalle vurderinger af sprog og betydning
3. En LLM håndterer generering og sværere ræsonnering

Den opdeling betyder mere end modelnavnet. Du bruger ikke en dyr, generativ model til at afgøre alt. Og du beder ikke en sort boks om at udføre noget, almindelig kode kan afgøre præcist.

Hjælp og automatisering er to forskellige job

I et foredrag optaget før lanceringen skelner TypeSafe-stifter Diogo Almeida mellem hjælp og automatisering. ChatGPT og Claude hjælper et menneske, som læser svaret og ejer valget. Et system i baggrunden skal kunne bruge svaret direkte uden en person ved siden af.

Almeida kobler forskellen til måden, modellerne lærer på. Med RLHF bliver svar belønnet, når mennesker foretrækker dem. TypeSafes tese er, at et rart og sikkert svar ikke altid er et korrekt valg i software.

I dag kalder TypeSafe sin retning RLCD: reinforcement learning for calibrated decisions. Målet er ikke god tekst, men valg og sandsynligheder, som software kan sætte grænser omkring. Derfor er formen på API’et en del af produktet. Den handler ikke kun om fart.

Foredraget nævner ikke Jev ved navn og viser hverken træningsmetode, kalibreringskurver eller en produkttest. Det forklarer tesen bag produktet. Det beviser ikke, at Jev er korrekt kalibreret på din opgave. Det skal måles på dine data, dit sprog og prisen på de forskellige fejl.

Jev og en LLM kan arbejde i to tempi

Ray Amjad beskriver i videoen Jev som System 1 og en model som Claude eller Codex som System 2. Jev tager de mange små valg. Den større model lægger planen, ser på de svære sager og hjælper med at rette kriterier og grænser.

Et system til fakturaer kan for eksempel lade Jev se efter kendte tegn på svindel. Klare sager går videre. Tvivl går til et menneske eller en større model, som kan samle flere spor og skrive en forklaring.

Når fagfolk retter et forkert valg, kan en kodeagent foreslå nye kriterier eller eksempler. Det kræver ikke ny træning af Jev. Amjads korte version er: “Rules learn. No retraining.”

Jeg ville dog ikke lade en agent ændre regler i drift på egen hånd. Hver ændring kan flytte både fejl og confidence. Kør den først mod dit faste testsæt, se forskellen og få en person til at godkende den.

Jev er heller ikke klassisk machine learning

En klassisk model kræver ofte et datasæt med kendte svar. Du træner den til én bestemt opgave. Så tester og driver du den som sin egen del af systemet.

Jev kommer som en generel model bag et API. Du beskriver kategorier og kriterier i forespørgslen. Det gør det hurtigt at prøve en ny beslutning uden først at træne en model fra bunden.

Det betyder ikke, at du slipper for data. Du behøver stadig historiske sager med et facit, hvis du vil vide, om den virker godt nok hos dig. Data flytter fra træning til evaluering.

Jev kan også skabe signaler til en klassisk model. Den kan måle købslyst, hast og interesse for et produkt i salgsnoter. En model for salg kan koble de signaler med ordrer og sæson.

Hvad kan en virksomhed bruge Jev til?

Start ikke med spørgsmålet: “Hvor kan vi bruge Jev?” Start med: “Hvor bruger vi tid på den samme vurdering igen og igen?”

Det er opgaver, hvor en medarbejder læser tekst og vælger, scorer, sorterer eller kontrollerer. Her er seks mønstre, der går igen på tværs af brancher.

1. Kundeservice: fordel og prioritér sager

En indbakke kan få 500 beskeder om ugen. Medarbejdere læser hver besked for at finde produkt, problem, alvor og ansvarlig afdeling.

Jev kan stille alle de spørgsmål parallelt. Systemet kan automatisk fordele klare sager. Tvivl, vrede kunder og sager med økonomisk risiko kan gå til en erfaren medarbejder.

Jev bør ikke skrive hele svaret alene. Den kan være det hurtige lag, der sørger for, at den rigtige proces starter.

2. Salg: sortér leads efter konkret fit

Et CRM indeholder hjemmesidetekst, noter og mails. Meget af det er ustruktureret. En sælger kan godt vurdere, om en virksomhed passer til en bestemt målgruppe, men vurderingen tager tid og varierer fra person til person.

Jev kan give hver sag flere signaler: branchefit, modenhed, problem og købslyst. Din kode kan vægte dem efter jeres egen salgsmodel.

Det er mere brugbart end ét uklart spørgsmål som “Er dette et godt lead?” Et samlet tal skjuler, hvorfor virksomheden ligger højt eller lavt.

3. E-handel: ryd op i produktdata

Varetekster fra leverandører bruger skiftende navne og mangler ofte felter. Jev kan vælge type og kendte træk. Den kan også mærke tekst, som ser ud til at bryde en regel.

Kode bør stadig kontrollere SKU, pris, lager og mål. Jev tager den sproglige del. Et menneske ser de usikre produkter, før de bliver publiceret.

4. Dokumenter: kontrollér krav og kilder

TypeSafe viser et tjek af kilder. Først ser en enkel søgning, om citatet er med. Så spørger systemet Jev: Støtter teksten det, modsiger den det, eller handler den om noget andet?

Det mønster kan bruges i rapporter, tilbud, kvalitetsdokumenter og compliance. Faste krav tjekkes med kode. Semantiske krav vurderes af modellen. Usikre fund går til en fagperson.

Det er ikke juridisk godkendelse på autopilot. Det er en billig måde at flytte menneskets tid fra alle sider til de sider, der kræver dømmekraft.

5. AI-sikkerhed: kontrollér andre modellers arbejde

En generativ model kan skrive et svar, vælge et værktøj eller foreslå en handling. Jev kan være et ekstra tjek. Den kan se efter prompt injection, følsomme data, svage kilder og værktøjskald, der ikke passer til brugerens ønske.

Det er her de lave omkostninger kan få stor betydning. Hvis hvert dyrt AI-kald kan kontrolleres med flere små vurderinger, bliver et feedback-loop økonomisk muligt.

Et screenshot delt af sikkerhedsudvikleren Greg Pstrucha viser 99,3 procent nøjagtighed, 0,259 sekunders svartid og 0,026 dollar pr. 1.000 vurderinger i én intern pipeline. Det er et resultat fra én aktør uden offentlig metode eller datasæt. Brug det som et spor, ikke som dokumentation for din egen løsning.

6. Browseragenter: vælg næste handling

Projektet Jev Ultrafast viser en browseragent, der får en forenklet liste over sidens synlige elementer. Jev vælger handling og mål. En lille LLM skriver kun tekst, når handlingen kræver det.

I den viste Google Flights-demo finder agenten en flysøgning på 7,073 sekunder. Den bruger 17 kald til Jev. Hvert kald tager typisk 178 millisekunder, og svaret blev tjekket bagefter.

Jev gjorde det ikke alene. En lille generativ model skrev “Zurich” og “London”, når agenten skulle udfylde felterne. Den anslåede modelpris var omkring 0,0039 dollar. Det tal dækker Jev og de to tekstkald, men ikke browserens drift.

Uret starter, efter agenten har set siden første gang. Start af browseren, det første sideskift og sluttesten ligger uden for de syv sekunder. Testen dækker tre forsøg med én opgave i én browser. Den viser ikke, hvor godt agenter virker på tværs af sider og opgaver.

Community-projekterne viser en form, ikke et facit

De første dage efter lanceringen kom der kodekontrol, en trading-bot, browsersystemer og små spil. De viser, at et beslutnings-API kan sættes ind mange steder. De viser ikke, at løsningerne er sikre nok til produktion.

Jev Review viser opbygningen. Først finder det tegn på risiko. Så vælger det et stykke kode, sætter navn på fejlen, måler hvor slem den er og vælger et relevant review.

Projektets egen README kalder det et eksperiment. Det har endnu ikke statiske analysatorer, compiler-fejl eller dokumenterede nøjagtighedsmål. Fund er prompts til review, ikke bevis på fejl.

Det er en nyttig regel for alle Jev-demoer: Se på systemets form. Vent med at stole på resultatet, til det er målt mod et kendt facit.

De andre delte eksempler passer til samme mønster:

• Test af nye releases. Rafal Wilinski viser mange browseragenter, der prøver at bryde en ny version på samme tid. De arbejder på en enkel HTML-model af siden. Opslaget viser fart og skala, men ikke antal fund, falske alarmer eller dækningsgrad.
• Regler for kode og tekst. Victor Mota og Mark Jaquith viser en slags kvalitativ linter. Den kan vurdere, om en kommentar passer til koden, om en log kan røbe data, og om en fejltekst hjælper brugeren. En vist score på 99 ud af 100 er modellens dom over én kommentar, ikke 99 procent målt nøjagtighed.
• Mange kommentarer på én gang. Ray Amjad viser 150 kodekommentarer vurderet på 9,3 sekunder for cirka én cent. Han viser ikke, om de udvalgte kommentarer faktisk var de forkerte. Tallet siger noget om fart og pris, ikke om kvalitet.
• En trading-bot. Jarrod Watts lader Jev vælge køb eller salg og sender valget til et marked. Det viser, at et svar kan blive til en handling på få millisekunder. Det siger intet om afkast eller risiko. En dårlig plan kan også tabe penge hurtigere.

Jev kan også ligge i den brugerflade, vi allerede kender

Ben’s Bites har samlet flere små Jev-forsøg. Her står modellen ikke som et eget AI-værktøj. Den ligger bag en funktion, som brugeren allerede kender:

• En browserudvidelse finder sponsorafsnit i YouTube-undertekster eller lyd og kan springe dem over.
• Et chatfilter forsøger at fjerne negative kommentarer med det samme.
• Gmail-søgning finder mails efter hensigten bag en søgning. En to-do-liste kan filtreres på samme måde.
• Andre demoer bruger Jev til en mere semantisk version af copy-paste, drag-and-drop og Cmd+F.
• En macOS-demo kobler talekommandoer til valg af handlinger på computeren.

Fælles for dem er et afgrænset valg bag en kendt knap eller handling. Brugeren skal ikke lære at skrive prompts. Jev bliver en lille del af produktet.

De er stadig demoer. Nyhedsbrevet viser ingen målinger af nøjagtighed, falske alarmer eller stabilitet. Eksemplerne udvider listen over mulige anvendelser. De dokumenterer ikke, at løsningerne er klar til drift.

En mulig anti-case: automatisk compaction

En anden demo bruger Jev til straks at forkorte en kodeagents kontekst. Det kan se oplagt ud: færre tokens burde give en lavere pris. Ben’s Bites peger på, at regnestykket kan gå den anden vej.

En agent kan ofte genbruge uændret kontekst via prompt caching. Hvis konteksten hele tiden erstattes af et nyt resumé, kan den fordel forsvinde. Du sparer tokens ét sted, men betaler for Jev, ny kontekst og mere teknik et andet sted.

Det er ikke et bevis for, at compaction altid er en dårlig idé. Det er en regel for evalueringen: Mål den samlede pris og kvalitet i hele forløbet. Mål ikke kun det enkelte Jev-kald.

Er Jev virkelig 40 til 200 gange hurtigere?

Diogo Almeida skrev først, at Jev var 20 til 200 gange hurtigere og 40 til 400 gange billigere. TypeSafes lange tekst er mere snæver. Den siger 70 til 500 millisekunders svartid og 40 til 200 gange højere fart på opgaver, der passer til System One.

Hjemmesidens tal på 193,6 gange højere fart og 444,6 gange lavere pris kommer fra fire interne evalueringer. TypeSafe skriver selv, at de nok ligger i den høje ende af de gevinster, andre vil se. De tal kommer fra leverandøren. De er ikke et løfte om din opgave.

Den konkrete pris er lettere at forholde sig til. Den 27. september 2026 kostede Jev 1.13 0,042 dollar pr. million input-tokens. Output-tokens var gratis. Modellen havde en kontekst på 64.000 tokens pr. forespørgsel og tog kun tekst, JSON og lister med tekst.

Et regneeksempel: 1.000 sager på hver 2.000 input-tokens bruger to millioner tokens. Ved listeprisen er modelregningen 0,084 dollar. Integration, lagring, overvågning og menneskeligt review koster stadig noget.

Hastigheden kommer ikke kun fra en mindre regning. Flere uafhængige spørgsmål om den samme sag behandles parallelt. Ti spørgsmål behøver derfor ikke ti ture over netværket.

En teknisk forklaring, som har bredt sig efter lanceringen, peger på genbrug af den fælles input-del. Systemet kan forberede teksten én gang, køre flere spørgsmål parallelt og kun se på sandsynligheden for de tilladte svar. Det er en troværdig måde at bygge en model som Jev på. TypeSafe har ikke bekræftet, at deres motor virker præcis sådan.

Et helt flow bliver heller ikke 200 gange hurtigere. Databaser, en browser, en tekstmodel og andre systemer tager stadig tid. I flydemoen tog hvert Jev-kald få millisekunder. Hele opgaven tog syv sekunder.

En mere nøgtern måling findes i TypeSafes cookbook om parallelle spørgsmål. Her blev en GDPR-tekst på 53.777 tegn vurderet med 13 spørgsmål. Ét samlet kald kostede i gennemsnit 0,000497 dollar og tog 0,27 sekunder. 13 sekventielle kald kostede 0,00609 dollar og tog 2,71 sekunder. Sammenligningen viser værdien af at genbruge samme input, men samtidige enkeltkald ville gøre forskellen i tid mindre.

Hvad ved vi om kvaliteten?

TypeSafe har valgt ikke at dele tal fra offentlige test. De beder i stedet kunder måle på deres egen opgave. Det giver mening. Det betyder også, at der ved start er få beviser fra andre end dem selv.

En beslutningsmodel kan se stærk ud på én opgave og fejle på en anden. Kategorier, sprog, mængden af støj og formuleringen af kriterier ændrer resultatet.

Dansk er et konkret spørgsmål. TypeSafe skriver, at engelsk er det primære træningssprog og det sprog, hvor Jev er mest præcis. Andre sprog virker, men skal testes særskilt. En dansk virksomhed bør derfor ikke overføre et engelsk resultat direkte.

Den rigtige evaluering er ikke “føles svarene gode?” Brug et datasæt med kendte udfald. Mål mindst:

• Hvor ofte rammer modellen rigtigt for hver kategori?
• Hvilke fejl er falske positiver og falske negativer?
• Fanger confidence de svære sager?
• Hvad koster en fejl i kroner, tid eller kundetillid?
• Hvor stor en andel kan køre automatisk ved en sikker grænse?
• Ændrer resultatet sig, når modellen får en ny version?

Den sidste er praktisk. Aliaset jev-latest flytter, når TypeSafe udgiver en ny stabil model. En produktionstjeneste bør logge den præcise version og låse den, hvis grænserne er testet mod den.

Hvad Jev ikke kan

TypeSafe har offentliggjort en side med kendte svagheder i Jev 1.13. Den er mere nyttig end en glat produktside, fordi den gør arbejdsdelingen klar.

Den skriver ikke

Jev kan ikke formulere en mail, en rapport eller en forklaring. Hvis du tvinger den til at vælge ét tegn ad gangen, får du en langsom og dårlig tekstgenerator.

Brug en LLM, når outputtet skal være ny tekst. Brug Jev, når svaret kan afgrænses på forhånd.

Den ser kun tekst

Jev 1.13 tager tekst, JSON og lister med tekst. Den ser ikke billeder, lyd eller video.

Browserdemoen sender derfor et enkelt HTML-træ med synlige felter og knapper. Jev ser ikke selve skærmbilledet. Det gør agenten hurtig, men den kan overse farver, grafik, canvas og andre rent visuelle tegn.

Hvis din sag starter som en faktura eller et foto, skal OCR eller en anden model først gøre indholdet til tekst. Den del kan også lave fejl og skal med i din test.

Den er ikke en lommeregner

Jev tæller ikke pålideligt. Den bør heller ikke sammenligne datoer, beregne intervaller eller udlede et præcist tal fra en Score.

Udtræk eventuelt måned og dag som valg. Lad derefter kode samle og sammenligne datoen.

Den kan læse spørgsmålet for bogstaveligt

Jev læser det, du skrev. Den gætter ikke på, hvad du mente. Negationer, skjulte krav og flere valg i ét spørgsmål øger risikoen for fejl.

Hvis du efter et forkert svar siger “det jeg mente var…”, har du fundet den tekst, der mangler i kriterierne.

For meget kontekst gør den dårligere

Jev kan tage meget tekst ind, men mere er ikke altid bedre. TypeSafe skriver selv, at støj kan få modellen på afveje og give flere fejl.

Hent og filtrér først. Send kun de felter, der er nødvendige for den konkrete vurdering.

Tekst kan forsøge at styre modellen

Jev ser ikke selv input som farligt. En varetekst eller mail kan rumme en besked, der prøver at styre svaret.

Det kaldes prompt injection. Test hjælper. Men klare krav fjerner ikke hele risikoen.

Den forklarer ikke sit svar

Du får et valg og et tal. Du får ikke et citat, en årsag eller en ræsonnering, der viser, hvorfor modellen valgte sådan.

Det gør Jev svær at bruge i beslutninger, hvor et menneske har krav på en forklaring. Det gør også fejl sværere at undersøge.

Simon Willison viser problemet med en lille test. Han bad Jev vurdere, om byer omkring San Francisco var “gode”. Cupertino endte øverst, og East Palo Alto nederst. Uden en forklaring er det svært at se, hvilke skjulte mønstre der styrede resultatet.

Bias bliver gemt i et tal

Et struktureret svar kan se mere objektivt ud end et tekstsvar. Det er det ikke nødvendigvis.

Hvis Jev scorer en jobansøger til 0,63, kan tallet skjule skævhed i modellen, kriterierne eller de data, du sender ind. Fraværet af en forklaring gør ikke problemet mindre.

Jeg ville ikke lade Jev dømme alene om job, kredit, forsikring, sundhed eller andre valg med stor effekt for et menneske. Her bør Jev højst være ét tegn blandt flere. Et menneske skal eje valget.

Det er også her EU AI Act og GDPR kan blive relevante. En lav API-pris ændrer ikke dit ansvar for data, forklarlighed og menneskelig kontrol.

Data forlader dit system

Jev kører som et API hos TypeSafe. Når du sender en mail eller et dokument, behandler en ekstern leverandør indholdet.

TypeSafe skriver, at data fra kunder ikke bruges til træning. De har også en aftale for data. Nul lagring er ifølge deres docs kun en mulighed på enterprise-planer.

Det er ikke det samme som, at alle data bør sendes. Kortlæg persondata og fortrolige oplysninger. Fjern det, modellen ikke behøver. Afklar opbevaring, underdatabehandlere og overførselsgrundlag, før du lægger kunde- eller medarbejderdata i et nyt API.

Kan du bruge Jev uden at være udvikler?

Ja til at undersøge det. Nej til de fleste rigtige arbejdsgange.

TypeSafe har et Playground, hvor du kan indsætte en tekst og definere spørgsmål uden at bygge en app. Det er nok til at lære formen og teste 20 eksempler.

En driftssikker løsning kræver mere. Nogen skal hente data, kalde API’et, omsætte svaret til en handling, logge version og resultat, håndtere fejl og sende tvivl til et menneske. Det er almindeligt integrationsarbejde.

Du behøver ikke kunne kode for at eje problemet. Den svære del ligger hos den, der kender jobbet:

• Hvilke valg findes der i virkeligheden?
• Hvor går grænsen mellem to kategorier?
• Hvilke fejl kan accepteres?
• Hvornår skal et menneske tage over?
• Hvad er et korrekt resultat på historiske sager?

En udvikler kan bygge broen. Den, der kender jobbet, sætter rammerne.

Sådan finder du en egnet første opgave

En god første Jev-opgave har fire tegn:

1. En person læser allerede tekst for at lave den samme vurdering mange gange
2. Svarmulighederne kan skrives ned på forhånd
3. Der findes gamle sager, som kan bruges som facit
4. En fejl kan opdages eller rulles tilbage, før den gør stor skade

“Hvilken af vores fire køer skal mailen i?” passer godt.

“Skal vi opsige denne medarbejder?” passer ikke.

Hold også øje med volumen. Hvis en medarbejder træffer vurderingen fem gange om måneden, sparer en integration sjældent nok. Hvis den sker 5.000 gange, kan hastighed, pris og ensartethed ændre økonomien.

En pilot på to uger

Start med 100 til 500 historiske sager. Skjul facit for modellen. Definér spørgsmål og kriterier ud fra jeres virkelige proces, ikke ud fra en demo.

Kør derefter Jev i skyggetilstand på nye sager i to uger. Den må gerne svare, men den må ikke udføre handlingen. Sammenlign med medarbejdernes faktiske valg.

Del resultaterne op. Et gennemsnit på 95 procent kan skjule, at modellen rammer 99 procent på simple sager og kun 60 procent på den kategori, der koster penge.

Når du sætter confidence-grænser, så start forsigtigt. Automatisér kun den sikre, reversible del. Den rigtige succesmåling er ikke, hvor mange sager modellen rører. Det er, hvor mange sager den kan fjerne fra køen uden at øge fejl og risiko.

Gem hver tvivl og hver uenighed mellem Jev og medarbejderen. De sager bliver næste runde af din test. Det er det feedback-loop, som gør både kriterier og grænser bedre over tid.

Læs også min guide til AI-implementering i små virksomheder. Processen er den samme: vælg ét problem, test på rigtige opgaver og mål resultatet, før du udvider.

Den tekniske form

Du kan forstå API’et ud fra én forespørgsel. Her er TypeSafes supporteksempel i en forkortet form:

{
  "state": "Stripe har fejlet i tre dage. Vi mister salg. Hjælp hurtigst muligt.",
  "model": "jev-1.13.0",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Hvilket team skal håndtere sagen?",
      "criteria": {
        "billing": "Betaling, abonnement eller refundering",
        "technical": "Fejl, nedbrud eller integrationer",
        "sales": "Priser, opgradering eller nye konti"
      }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "Beskeden udtrykker hast eller tidspres"
    }
  }
}

Svaret bruger de samme navne. Choice viser valget, alle chancer og confidence. Noul viser chancen for ja.

Modellen bør ikke eje hele flowet. Kode vælger data, kalder modellen, sætter grænser og handler. Jev leverer kun sit syn på sproget.

TypeSafe har SDK’er til Python og JavaScript. Deres agent-skill på GitHub hjælper kodeagenter med at forme spørgsmålene. Det kan spare tid i start. Det erstatter ikke din test.

Spørg parallelt, når svarene er uafhængige

Hvis fem spørgsmål bruger den samme sag, så send dem i samme kald. Jev evaluerer dem parallelt og isoleret. Det sparer netværksture og lader systemet genbruge inputtet.

Hvis spørgsmål nummer to kræver svaret fra nummer ét, skal du bruge et nyt kald. Alternativt kan du spørge til flere mulige grene på forhånd og kun bruge svaret fra den gren, koden vælger.

Hold politik og model adskilt

Jev kan sige, at en mail sandsynligvis er kritisk. Din kode skal beslutte, hvad kritisk betyder i praksis.

Det gør grænser, logning og ændringer synlige. Du kan hæve kravet fra 0,80 til 0,92 uden at ændre spørgsmålet. Du kan også kræve to uafhængige signaler, før systemet blokerer noget.

Test hele systemet, ikke kun svaret

En fejl kan ligge flere steder. Måske mangler der data. Måske er spørgsmålet uklart, grænsen forkert eller koden fuld af fejl.

Log derfor inputversion, spørgsmålsversion, modelversion, rå sandsynligheder, valgt handling og det senere facit. Ellers kan du ikke se, om løsningen bliver bedre eller bare anderledes.

Min vurdering af Jev lige nu

Jev ændrer ikke, hvad AI kan forstå. Den ændrer formen på det svar, software får tilbage.

Det lyder som en lille forskel. I et system, der skal køre tusindvis af gange uden en person ved siden af, er formen afgørende. Et afsnit skal læses og fortolkes. Et valg med sandsynligheder kan testes, sættes bag en grænse og sendes videre til kode.

Der er samtidig mindre at gemme sig bag. Jev kan ikke skrive en overbevisende forklaring efter en dårlig beslutning. Du står tilbage med tallet og din evaluering. Det kræver mere disciplin, ikke mindre.

Jeg ville ikke begynde med at erstatte en hel proces. Jeg ville vælge ét gentaget, sprogligt valg med lav risiko. Lade Jev køre ved siden af mennesker. Måle fejlene på dansk. Og først derefter beslutte, om en del af køen kan køre automatisk.

Hvis resultaterne holder, er den lave pris og korte svartid ikke bare en billigere måde at gøre det samme på. De gør det muligt at lægge flere små kontroller ind i en arbejdsgang, end en almindelig LLM økonomisk kan bære.

Det er her, Jev kan få en rolle. Ikke som endnu en chatbot, men som et hurtigt lag mellem data, kode og de folk, der ejer valget.

Kilder og videre læsning

• TypeSafe AI: Introducing System One Models & Jev
• TypeSafe-dokumentation: Introduktion til Jev
• TypeSafe-dokumentation: Modeller, pris og grænser
• TypeSafe-dokumentation: Kendte svagheder i Jev 1.13
• TypeSafe cookbooks og eksempler
• Simon Willison: Jev introduces a new shape of LLM
• Browser Use: Jev Ultrafast
• Dev Agrawal: Jev Review
• TypeSafe AI’s officielle agent-skill
• Ray Amjad: Jev + Claude Code = The Cheapest Agentic Coding Loop Yet
• Diogo Almeida: What’s next after RLHF?
• Ben’s Bites: What can you build with Jev?
• YouTube Sponsor Detection med Jev