Mistral Vibe for Code topper en ny sammenligning af coding‑agenter med 22 ud af 25 point. Claude Code ligger en hårsbredde efter med 21, mens OpenAI Codex får 14 og Cursor 6. Testen samler alt i én virkelig udviklingsopgave fra scaffold over tests til en færdig pull request – og er dateret 14. juli 2026. Vurderingen er en kapabilitets‑sammenligning på tværs af dokumenterede features, benchmarks og vendor‑specs – ikke ét kørt run på én maskine (kilde 2407).
For teams der skal vælge værktøj nu, er det faktisk godt nyt. Tallene siger mindre om rå hastighed og mere om, hvor langt hver agent er på integration, testloop og sporbarhed. Altså det, der afgør om noget kan rulles ind i daglig drift uden at brænde weekenden af.
Hvordan testen var skruet sammen
Opgaven er jordnær: i en eksisterende Python/FastAPI‑service skal der tilføjes et /subscriptions‑endpoint, med rigtigt filarbejde, Pydantic‑modeller, en service‑layer, tests der kører, fejl der rettes, og en PR der åbner pænt med beskrivelse. Den klassiske tretrinsraket. Scaffold, test, ship. Scoringen er fordelt på fem dimensioner á 1–5 point: feature‑scaffolding, testgenerering og run‑loop, PR‑ og async‑workflow, surface coverage samt cost/openness/control. Max 25 point. Hver delscore har en kort begrundelse i kilden (kilde 2407).
Der er også klare forbehold: benchmark‑tal kommer fra forskellige suiter som SWE‑bench Verified, SWE‑Bench Pro og Terminal‑Bench, der ikke kan læses som én skala; vendor‑påstande er markeret som netop påstande; og produkterne ændrer defaults og priser løbende. Resultaterne er et øjebliksbillede pr. 14/7‑2026 (kilde 2407).
Hvad afspejler scorerne i praksis
På feature‑scaffolding bliver forskellen tydelig: Mistral og Claude ligger højt, fordi de kan læse hele projektets kontekst og orkestrere ændringer på tværs af filer uden at miste tråden. Codex kan noget af det, men mister overblikket ved større ændringer. Cursor falder igennem – især omkring multi‑fil‑forståelse i et styret flow (kilde 2407).
Test‑ og valideringsloopet er næste knast. Claude får topkarakter her ifølge tabellen, mens Mistral også scorer stærkt. Pointen er, at testskrivning og iterativ fejlretning skal passe ind i eksisterende mønstre og køre løbende. Cursor og Codex kræver mere manuel hånd på rattet og ekstra gating for at undgå regressions, hvilket spiser tid i CI.
PR, async og alt det kedelige vigtige
PR‑ og async‑workflow handler om at komme sikkert fra lokal idé til færdig PR med synlighed på ændringer og værktøjskald. Her stikker Mistral af med en moden opsætning med remote agenter, parallelle sandboxes og vedholdende sessioner, mens Claude er tæt på. Codex og Cursor kan åbne PRs, ja, men uden samme dybde i session‑håndtering og observabilitet ifølge kildens scoring (kilde 2407).
Surface coverage lyder som marketing, men er i praksis “hvor mange interfaces og filtyper holder agenten styr på uden hjemmelavet lim”. Bred dækning betyder færre huller i kæden. Mistral får et rent femtal her, blandt andet fordi CLI, web, IDE‑plugins og baggrundsagenter hænger sammen.
Styring, priser og kontrol
Den sidste dimension samler penge, åbenhed og kontrol. Mistral scorer højt med åben CLI og fleksible driftsmodeller. Men et vigtigt forbehold: omkostningseffektivitet er Mistrals egen påstand, markeret som vendor‑claim i kilden – ikke uafhængigt verificeret (kilde 2407). Codex og Cursor får lavere score, især på kontrol og enterprise‑styring. Ikke fordi de ikke virker, men fordi de i denne sammenligning ikke matcher samme grad af selv‑hosting, sporbarhed og politikker ud af boksen.
Summen bliver derfor en rangorden, der giver mening i en operations‑linse: Mistral 22, Claude 21, Codex 14, Cursor 6. Tallene siger ikke, at Cursor ikke kan hjælpe i IDE’et. De siger, at når hele kæden skal samles fra prompt til PR med audit og testloop, så mangler der brikker (kilde 2407).
Dybdegående om Mistral Vibe for Code
Mistral Vibe for Code beskrives som Mistrals samlede agent til arbejde og kode – tidligere Le Chat – hvor kodningsfladen kører via en open‑source CLI på GitHub under Apache 2.0. Arkitekturen er lagdelt med Devstral til agentlogik, Codestral til hurtige completion‑opgaver og en embed‑model til semantisk søgning. Remote agenter kører på Mistral Medium 3.5 ifølge artiklens gennemgang. Devstral 2 er en 123B model med 256K kontekstvindue, og Mistral positionerer resultater på SWE‑bench Verified som state‑of‑the‑art for åbne modeller. Praktiske detaljer: projektbevidst scanning af filtræ og Git‑status, og hooks til at køre egne shell‑kommandoer før og efter hvert agent‑trin (kilde 2407).
Det praktiske udbytte er færre “nå, det glemte den også lige” i multi‑fil‑ændringer. Hooks fungerer som minipolitikker: afvis uvedkommende ændringer, kør formatering, check licensheaders, blokér kodegen i bestemte mapper. Det gør en 22/25 plausibel i en driftssammenhæng. Usikkerheden? Pris og cost‑efficiency mangler uafhængige målinger, og selv med åben CLI er der forskel på at have komponenter i open source og at køre managed remote‑agenter med nødvendig adgangsstyring og audit. Kilden markerer cost‑påstanden som vendor‑oplyst, hvilket bør trigge lokal validering (kilde 2407).
Claude Code tæt efter
Claude Codes 21/25 kommer af stærke testloops og solid surface. På dansk: god til at skrive tests, køre dem, lytte til fejl og prøve igen – uden at miste stilen i kodebasen. Kildens vurdering peger dog på, at integration og kontrol ikke helt matcher Mistrals kombination af åbenhed, driftstyper og observabilitet. Tradeoff’et er høj daglig produktivitet mod mere arbejde med enterprise‑policies og livscyklusstyring før fuld udrulning (kilde 2407).
Konsekvensen for et team er konkret: Claude er stærk til hurtig feature‑eksekvering og testdrevet udvikling, men planlæg sporbarhed, modelstyring og tydelige gates i CI fra start, så ændringer ikke glider udenom.
Codex og Cursor i det hårde lys
Hvorfor de lavere scorer? Ifølge tabellen snubler Codex og Cursor især, når orkestrering på tværs af filer og processer skal holdes stramt, og når PR‑flowet kræver persistent kontekst og dyb observabilitet. De kan åbne PRs og generere kode, men den samlede kæde får for meget friktion. I praksis betyder det manuel opsamling: ekstra testgates, streng menneskelig review og flere re‑runs for at lukke regressions (kilde 2407).
Det gør dem ikke ubrugelige; de kan være glimrende til lokal produktivitet og spikes. Men hvis målet er “fra prompt til PR med audit‑logs”, peger scoringen på et større integrationsarbejde – eller et andet værktøj til den del.
Operationsimplikationer uden pynt
Før noget rulles bredt ud, skal AI‑forslag ind som første‑klasses borgere i CI/CD. Ellers mister man styring over, hvad der faktisk deployes. AWS’ QA‑blog siger det samme: organiser tests i regression‑suiter, kør dem som batch, og lad resultater gate deployments automatisk. Referenceopsætningen QA Studio viser desuden, hvordan man paralleliserer tests og trækker agentisk QA ind i pipelines via CLI (kilde 2409). Det gælder uanset agentvalg.
Adgangskontrol og audit‑logning er næste skridt. Hvem må hvad, hvorfra, og hvordan revideres det. Derudover modelstyring: hvilke versioner kører hvor, med hvilke temperaturer, tokens, værktøjs‑hooks. Det er tungt – men alternativet er uforudsigelig opførsel og svær fejlfinding midt i en release.
Forslag til Po
C der faktisk måler noget
En kort, målelig PoC trumfer to måneders whiteboard. Mål fx gennemløbstid fra opgave til PR, ændring i test‑coverage, gennemsnitlig PR‑review‑tid, fejlrater efter merge og de rene omkostninger pr. lukket PR. Tag mindst to repræsentative features og kør dem gennem samme pipeline med agent on/off. Sammenlign på tal, ikke fornemmelser. Tilgangen er også i tråd med Snillds manual, som anbefaler målbare PoCs og eksplicitte driftstemaer som CI/CD‑integration, adgangskontrol og datastyring – markeret her som Snillds position, ikke en ekstern måling (kilde 2408).
Tekniske opgaver til PoC’en kan prioriteres skarpt: definér prompts og systeminstruktioner, etabler agent‑hooks i repoet, sæt sikkerhedsgates i pipeline, og indsamling af metrikker som artefakter. Uden telemetri flyver man i blinde. Med den i hånden kan man derimod tage et køligt valg, også hvis favoritværktøjet viser sig at være nummer to.
Hvad betyder overblikket for platformvalg
Scoringsprofilen fortæller mest om, hvor meget infrastrukturlim der stadig skal bygges. En høj score i testloop betyder færre manuelle runder i QA – ikke nul. En femmer i surface coverage betyder mindre særintegration i IDE og CLI, men tjek stadig jeres niche‑sprog og artefakter. Og cost/openness/control kræver eget regneark, især når leverandøren selv har leveret tallet. Kilden markerer netop Mistrals cost‑efficiency som vendor‑claim, så her er lokal måling obligatorisk (kilde 2407).
For DevOps‑hold er budskabet prosaisk: fold agentens handlinger ind i eksisterende gates, ikke omvendt. For sikkerhed og compliance er spørgsmålet, hvor meget kode og data der forlader miljøet. En åben CLI kan hjælpe med inspektion, men managed remote‑agenter kræver klare politikker for adgang og logging. AWS’ reference på regression‑suiter og pipeline‑integration er et godt startpunkt, også hvis man ikke er på AWS (kilde 2409).
Ubetrådt terræn og huller i kortet
Der er åbne spørgsmål, som artiklen selv lægger op til. Hvordan er “surface coverage” præcist kvantificeret på tværs af filtyper og værktøjer? Hvilke testcases ligger bag hver delscore? Hvordan udløses hooks og remote‑agenter i praksis med auth, permissions og audit? Kilden beskriver funktionerne, men fuld driftsdokumentation skal hentes hos leverandørerne, før man kan designe politikkerne ordentligt (kilde 2407).
Der mangler desuden uafhængige målinger af cost‑efficiency og runtime‑latens i et standardmiljø. Artiklen er en kapabilitetsvurdering pr. 14/7‑2026, ikke et runtime‑bench i samme cluster for alle kandidater. Og ja, der er få offentlige referencecases i produktion, som viser effekt på throughput og fejlrate. Det bør være et krav i næste evalueringsrunde.
Den korte konklusion for travle teams
Mistral Vibe for Code vinder den samlede kapabilitetsvurdering med 22/25, tæt fulgt af Claude Code på 21. Codex og Cursor taber terræn i den komplette kæde fra scaffold til PR, især på orkestrering, observabilitet og kontrol. Det betyder ikke, at værktøjerne er værdiløse; det betyder, at de kræver mere omkringliggende infrastruktur for at levere stabilt i drift. Det praktiske takeaway er enkelt: start småt, mål alt, integrér i jeres CI/CD, og hold en klar revisionssti. Snillds manual anbefaler netop en instrumenteret PoC med fokus på driftstemaer som CI/CD‑integration, adgangsstyring og datagovernance; det er en position, ikke en ekstern måling (kilde 2408).
Og så den rå note: forskellen viser sig først, når man sidder med det i hænderne. Ikke på et slide. Ikke i en tabel. I pull requesten, der enten går igennem jeres gates – eller bliver stoppet af dem.
