Qodo (tidligere CodiumAI) har på under to år bevæget sig fra et lille test-genererings-plugin til en fuld platform for AI-kodegennemgang, der i marts 2026 hentede 70 millioner dollar i en Series B-runde og nu tæller Walmart, Nvidia, Red Hat, Box, Intuit, Ford Motors og Monday.com blandt sine kunder, ifølge selskabets egen pressemeddelelse. I februar 2026 skiftede produktet fra én samlet AI-gennemgang til en arkitektur med flere specialiserede agenter, der arbejder parallelt på hver sin del af en pull request. Denne guide viser dig, hvordan du kommer fra nul til en fungerende Qodo-opsætning, der automatisk gennemgår dine pull requests på GitHub, GitLab, Bitbucket eller Azure DevOps.
Vi bygger et komplet eksempelprojekt undervejs: et lille Node.js-API, som vi lader Qodo gennemgå, forbedre og teste automatisk. Du får den nøjagtige konfigurationsfil, kommandoerne der trigger en gennemgang, og en liste over de fejl, danske og nordiske udviklerteams oftest støder på, når de sætter værktøjet op for første gang.
Hvad er Qodo, og hvorfor er det relevant lige nu
Qodo er en AI-drevet platform til kodekvalitet og kodegennemgang, bygget til at sidde mellem “AI’en skrev koden” og “koden er klar til produktion”, som selskabet selv formulerer det. Produktet startede som CodiumAI og skiftede navn til Qodo den 30. september 2024, samtidig med en Series A-runde på 40 millioner dollar. Siden har platformen udviklet sig fra et enkelt test-genereringsværktøj til fire klart adskilte produkter: Qodo Gen til IDE og terminal, Qodo Merge (det åbne kildekode-projekt kendt som PR-Agent) til automatisk pull request-gennemgang, en agent-værktøjskasse kaldet Agentic Toolbox til CLI-baseret arbejde, og Qodo Cover til automatisk testgenerering.
Det, der gør Qodo interessant for danske og nordiske udviklingsteams netop nu, er tidspunktet. I februar 2026 lancerede selskabet det, de kalder Qodo 2.0: en arkitektur, hvor gennemgangen af en pull request ikke længere er ét AI-kald, men fire parallelle specialist-agenter, der hver dækker fejlfinding, kodekvalitet, sikkerhed og testdækning. Ifølge en sammenligning på dev.to af otte AI-værktøjer til kodegennemgang opnåede Qodo 2.0 den højeste samlede F1-score i testen på 60,1 procent, med en recall på 56,7 procent. Det er ikke perfekt, men det er et konkret, målt resultat frem for et marketingudsagn.
Samtidig er finansieringen et signal om, at platformen ikke forsvinder foreløbig. Serie B-runden på 70 millioner dollar i marts 2026 bragte den samlede kapital op på 120 millioner dollar, og virksomheden retter nu skarpt ind mod det, de kalder “software slop”, altså den stigende mængde kode genereret af AI-agenter som Claude Code og OpenAI’s værktøjer, der aldrig bliver ordentligt gennemgået af mennesker. For teams, der allerede bruger GitHub Copilot, Cursor eller Claude Code til at skrive kode, giver det mening at sætte et selvstændigt gennemgangslag op, som ikke er styret af samme model eller samme firma.
Forudsætninger: dette skal du bruge, før du starter
Før du går i gang, skal følgende være på plads. Listen er bevidst konkret, så du ikke opdager manglende adgang midt i opsætningen.
- Et GitHub-, GitLab-, Bitbucket- eller Azure DevOps-repository, hvor du har administratorrettigheder (nødvendigt for at installere en Git-app)
- Node.js version 20 eller nyere installeret lokalt, hvis du vil følge eksempelprojektet
- Git version 2.40 eller nyere
- En arbejds-e-mail til oprettelse af Qodo-konto (privat Gmail-adresse fungerer også til test)
- Adgang til at oprette eller redigere filer i roden af standard-branchen i dit repository
- Mindst én åben eller kommende pull request, du kan teste konfigurationen på
- Cirka 30-40 minutter uden afbrydelser til selve opsætningen
Du behøver ikke en betalt plan for at komme i gang. Qodo tilbyder en 14-dages gratis prøveperiode uden krav om betalingskort, med ubegrænsede gennemgange og ubegrænsede credits i prøveperioden, ifølge selskabets prisside. Det er rigeligt til at gennemføre denne guide og teste værktøjet på et par rigtige pull requests, før du beslutter dig for en betalt plan.
Trin 1: Opret en Qodo-konto
Gå til Qodos hjemmeside og vælg “Start Trial” frem for “Book a Demo”, medmindre du repræsenterer en virksomhed med mere end 30 udviklere, hvor Enterprise-sporet giver mere mening (mere om det i prisafsnittet nedenfor). Opret kontoen med din arbejds-e-mail. Der kræves ikke betalingskort for at starte prøveperioden.
Efter oprettelsen lander du i Qodo-portalen, hvorfra al efterfølgende konfiguration foregår. Portalen er det centrale sted til at forbinde Git-udbydere, se gennemgangshistorik og justere regler, så det er værd at bruge et par minutter på at klikke rundt, før du går videre.
Trin 2: Forbind Qodo til dit Git-repository
Qodo understøtter fire Git-udbydere: GitHub, GitLab, Bitbucket og Azure DevOps, hvilket dækker stort set alle opsætninger man støder på i danske virksomheder, fra startups på GitHub til større organisationer på selvhostet Azure DevOps. Fremgangsmåden varierer let afhængigt af udbyder, men mønsteret er det samme.
GitHub
Inde i Qodo-portalen vælger du “Install Qodo on GitHub”. Du bliver sendt til GitHubs egen installationsside for Qodo-appen, hvor du vælger, om appen skal have adgang til alle dine repositories eller kun udvalgte. For de fleste teams anbefales det at starte med et enkelt, ikke-kritisk repository, indtil I har testet konfigurationen. Godkend adgangen, og du bliver sendt tilbage til Qodo-portalen, hvor repositoriet nu står som forbundet.
GitLab, Bitbucket og Azure DevOps
For GitLab og Bitbucket foregår forbindelsen på lignende vis via en app eller adgangstoken, som Qodo-portalen guider dig igennem trin for trin. Azure DevOps kræver typisk, at du opretter et personligt adgangstoken (Personal Access Token) med rettigheder til kodelæsning og kommentering på pull requests, som du derefter indsætter i Qodo-portalen. Uanset udbyder er slutresultatet det samme: Qodo får adgang til at læse diffs og skrive kommentarer på dine pull requests.
Trin 3: Installer Qodo Gen i din editor
Mens Qodo Merge (gennemgangsdelen) fungerer uden nogen editor-installation, giver Qodo Gen dig AI-assistance direkte i IDE’en, i CLI’en og i Git-workflowet, som selskabet selv beskriver det. Søg efter “Qodo Gen” i din editors udvidelsesmarked (VS Code Marketplace eller JetBrains Plugin-marketplace) og installer udvidelsen. Efter installation logger du ind med samme konto, du oprettede i trin 1.
Hvis du allerede bruger GitHub Copilot, Cursor eller Claude Code til at skrive kode, kan Qodo Gen sagtens køre side om side med disse værktøjer. Formålet er forskelligt: de andre værktøjer hjælper dig med at skrive kode, mens Qodo primært fokuserer på at gennemgå og forbedre kode, der allerede er skrevet, uanset om den kom fra et menneske eller en AI-agent. Hvis du vil sammenligne redigerings-oplevelsen med andre AI-editorer, kan du se vores opsætningsguide til Cursor AI eller guiden til Claude Code.
Trin 4: Byg eksempelprojektet, du skal teste med
For at gøre resten af guiden konkret bygger vi et lille Node.js-API, som vi bevidst udstyrer med et par typiske fejl, Qodo skal fange. Opret en ny mappe og initialiser projektet:
mkdir qodo-demo-api && cd qodo-demo-api
npm init -y
npm install expressOpret filen server.js med følgende indhold. Bemærk, at koden med vilje indeholder en usikker praksis (brugerinput indsat direkte i et databasekald), som vi senere skal se, om Qodo fanger:
const express = require('express');
const app = express();
app.use(express.json());
const users = [{ id: 1, name: 'Anna', email: '[email protected]' }];
app.get('/users/:id', (req, res) => {
const query = "SELECT * FROM users WHERE id = " + req.params.id;
const user = users.find(u => u.id == req.params.id);
if (!user) return res.status(404).send('Not found');
res.json(user);
});
app.listen(3000, () => console.log('API kører på port 3000'));Initialiser Git, commit koden, og push til det repository, du forbandt til Qodo i trin 2:
git init
git add .
git commit -m "Initial API med bevidst usikker query"
git branch -M main
git remote add origin https://github.com/dit-brugernavn/qodo-demo-api.git
git push -u origin mainTrin 5: Opret konfigurationsfilen .pr_agent.toml
Qodo Merge (det bagvedliggende PR-Agent-projekt) styres enten via Qodo-portalens grafiske grænseflade eller via en konfigurationsfil ved navn .pr_agent.toml, placeret i roden af standard-branchen. Vi bruger filen her, fordi den er versioneret sammen med koden og nemmere at dele på tværs af et team. Opret filen i roden af dit repository:
[github_app]
pr_commands = [
"/agentic_describe",
"/agentic_review"
]
[pr_reviewer]
require_security_review = true
require_tests_review = true
num_code_suggestions = 4
[pr_code_suggestions]
commitable_code_suggestions = trueSektionen [github_app] styrer, hvilke kommandoer der automatisk køres, hver gang en ny pull request åbnes. Hvis dit repository ligger på GitLab, Bitbucket Cloud eller Bitbucket Server, erstatter du sektionsnavnet med henholdsvis [gitlab], [bitbucket_app] eller [bitbucket_server]. Kommandoerne /agentic_describe og /agentic_review hører til Qodo 2.0-arkitekturen og erstatter de ældre separate kommandoer /review, /describe, /improve og /compliance, som stadig virker, men som Qodo dokumenterer som værende på vej ud.
Commit og push filen:
git add .pr_agent.toml
git commit -m "Tilføj Qodo-konfiguration"
git pushVær opmærksom på, at ændringer i .pr_agent.toml først træder i kraft, når filen er merget til standard-branchen. Det er en af de hyppigste kilder til forvirring hos nye brugere: man tilføjer konfigurationen i en feature-branch og undrer sig over, at den ikke bliver brugt på selv samme pull request.
Trin 6: Opret en pull request og udløs den første gennemgang
Lav en ny branch, indfør en ændring, og åbn en pull request:
git checkout -b fix/bruger-endpoint
# ret i server.js, commit ændringen
git push -u origin fix/bruger-endpointÅbn pull requesten på GitHub (eller din valgte udbyder). Hvis pr_commands er sat korrekt i .pr_agent.toml, begynder Qodo automatisk at analysere diffen inden for typisk et minuts tid, og der dukker en kommentar op med en strukturet gennemgang: en kort beskrivelse af ændringen, en risikovurdering og konkrete forslag til forbedringer, opdelt efter de fire specialist-agenter (fejl, kodekvalitet, sikkerhed, testdækning).
I vores eksempel med den usikre SQL-lignende streng-konkatenering bør sikkerhedsagenten flage linjen, hvor req.params.id indsættes direkte i en query-streng, og foreslå parametriserede forespørgsler i stedet. Det er præcis den type fejl, som er nem at overse i en manuel gennemgang, men som et automatiseret, specialiseret lag er godt til at fange konsekvent.
Trin 7: Brug kommandoer manuelt i PR-kommentarer
Ud over automatisk gennemgang kan du til enhver tid skrive kommandoer direkte som en kommentar på pull requesten for at trigge specifikke handlinger. De vigtigste kommandoer er:
| Kommando | Funktion | Bemærkning |
|---|---|---|
/agentic_review | Kører den fulde multi-agent-gennemgang (Qodo 2.0) | Anbefalet fremfor /review |
/agentic_describe | Genererer eller opdaterer PR-beskrivelsen automatisk | Erstatter /describe |
/review | Ældre, enkelt-model gennemgang | Fungerer stadig, men udfases gradvist |
/improve | Foreslår konkrete kodeforbedringer som commitbare forslag | Hedder /improve_code på Bitbucket |
/describe | Genererer PR-titel og -beskrivelse | Ældre kommando |
Skriv for eksempel /agentic_review som en almindelig kommentar på pull requesten, og Qodo starter en ny gennemgang inden for kort tid, uafhængigt af om der er sket nye commits siden sidst.
Trin 8: Konfigurer via portalen som alternativ til TOML-filen
Hvis dit team ikke ønsker at vedligeholde en konfigurationsfil i hvert repository, tilbyder Qodo-portalen en grafisk konfigurationsside, hvor de samme indstillinger (antal kodeforslag, krav om sikkerhedsgennemgang, krav om testgennemgang) kan sættes centralt for alle forbundne repositories. Det er særligt relevant for større organisationer, der vil håndhæve ensartede regler på tværs af mange teams, uden at hvert team selv skal huske at tilføje en fil.
Fordelen ved portalen er central styring. Fordelen ved TOML-filen er, at ændringer er versionerede og synlige i Git-historikken, så andre udviklere kan se, hvornår og hvorfor gennemgangsreglerne blev ændret. De fleste teams starter med portalen for hurtigt at komme i gang og skifter til TOML-filen, når konfigurationen stabiliserer sig.
Trin 9: Sæt Qodo Cover op til automatisk testgenerering
Qodo Cover er platformens funktion til automatisk at generere unit-tests for kode, der mangler testdækning. I vores eksempelprojekt har vi ingen tests overhovedet, hvilket er et oplagt sted at starte. Installer et testframework:
npm install --save-dev jest supertestTilføj derefter et testscript i package.json:
"scripts": {
"test": "jest"
}Når pr_reviewer.require_tests_review er sat til true i konfigurationen (som vi gjorde i trin 5), vil Qodos gennemgang aktivt pege på filer, der mangler testdækning, og i mange tilfælde foreslå konkrete test-cases direkte i PR-kommentaren. Du kan derefter acceptere forslagene som commitbare ændringer, hvorefter de lægges direkte ind i din branch.
Trin 10: Sæt Agentic Toolbox op til CLI-baseret arbejde
Qodos “Agentic Toolbox” er den del af platformen, der er bygget specifikt til at fungere sammen med kodende AI-agenter som Claude Code, OpenAI Codex eller andre CLI-baserede assistenter. Tanken er, at når en AI-agent selv skriver og committer kode, skal der findes et uafhængigt kvalitetslag, der kan køres direkte i terminalen eller som en del af et CI/CD-flow, uden at skulle vente på en pull request.
Log ind på Qodo-portalen og find sektionen for Agentic Toolbox under dokumentationen “Understanding the Agentic Toolbox”. Herfra kan du generere et API-nøgle-token, som knyttes til dit CLI-værktøj eller din CI/CD-pipeline, så gennemgangen kan trigges automatisk, hver gang en agent afslutter en opgave, i stedet for kun ved en færdig pull request. Det er særligt nyttigt, hvis I allerede har sat en MCP-server op til flere AI-assistenter, da Agentic Toolbox kan indgå som endnu et værktøj i den samme kæde.
Trin 11: Juster reglerne, så gennemgangen passer til jeres kodebase
En generisk gennemgang, der er ens for alle repositories, bliver hurtigt til støj. Qodo lader dig oprette specifikke regler, kaldet et “Rules system”, som gør det muligt at fortælle platformen, hvad der er vigtigt i netop jeres kodebase, for eksempel at alle nye endpoints skal have rate-limiting, eller at ingen ny kode må logge personoplysninger i klartekst. Det gøres enten i portalen under Code Governance, eller ved at udvide .pr_agent.toml med brugerdefinerede prompts under [pr_reviewer]-sektionen.
For teams, der arbejder med flere repositories, der deler samme mønstre og standarder, findes desuden en funktion til gennemgang på tværs af repositories (cross-repo code review) i de betalte planer, som gør det muligt at anvende de samme regler konsekvent på tværs af hele organisationens kodebase, i stedet for at genopfinde konfigurationen for hvert enkelt repository.
Trin 12: Overvåg og finjuster med dashboard og analyse
Qodo-portalen indeholder et dashboard, der viser antal gennemførte gennemgange, hvor mange forslag der er blevet accepteret, og hvor meget af det credit-baserede forbrug I har brugt i indeværende periode. Brug de første par ugers data til at se, om num_code_suggestions (antallet af forslag pr. gennemgang) er sat for højt eller for lavt. Et for højt tal skaber støj og “forslags-træthed” hos udviklerne, mens et for lavt tal betyder, at reelle problemer aldrig bliver fanget.
Basér justeringen på faktiske tal fra jeres eget dashboard i stedet for en generel tommelfingerregel, da støjniveauet varierer meget afhængigt af, hvor stor og hvor gammel kodebasen er.
Priser: fra gratis prøveperiode til Enterprise
Qodos prismodel er bygget op omkring tre niveauer og et credit-system, hvor $0,012 pr. credit deles på tværs af hele teamet, ifølge selskabets prisside. Her er de tre niveauer, som de så ud i september 2026:
| Plan | Pris | Målgruppe | Inkluderet |
|---|---|---|---|
| Free Trial | Gratis i 14 dage, intet betalingskort | Enkeltpersoner, der vil teste værktøjet | Ubegrænsede gennemgange og credits i prøveperioden |
| Pro Team | Fra $30, credit-baseret ($0,012/credit) | Teams op til 30 brugere | Agentisk PR-gennemgang, regelsystem, Git- og IDE-integrationer, dashboard, ingen årsbinding |
| Enterprise | Individuel pris, kræver demo | Organisationer med 30+ brugere | SSO/SAML, audit logs, BYOK (egne LLM-nøgler), single-tenant eller on-prem, dedikeret support |
Pro Team-planen fungerer efter et pakke-system, hvor cirka 2.500 credits svarer til omkring 18 gennemgange om måneden, 5.000 credits til omkring 36 gennemgange, og 20.000 credits til omkring 144 gennemgange, afhængigt af hvor store og komplekse jeres pull requests er. Der er ingen fast grænse for, hvor meget I kan bruge, men et månedligt “overage cap” kan sættes af kontoadministratoren for at undgå uventede regninger, hvis forbruget stiger brat.
Sammenlignet med at abonnere på flere separate AI-kodeassistenter, som vi har dækket i vores guider til GitHub Copilot og JetBrains AI Assistant, positionerer Qodo sig som et supplerende lag oven på den kode, der allerede er skrevet, snarere end en erstatning for disse værktøjer.
5 almindelige faldgruber, når du sætter Qodo op
- Konfigurationsfilen ligger i den forkerte branch. Hvis
.pr_agent.tomlkun findes i en feature-branch, bliver den ignoreret. Filen skal ligge i roden af standard-branchen for at træde i kraft. - Forkert sektionsnavn til Git-udbyderen. Bruger I GitLab, men har kun en
[github_app]-sektion i filen, bliver kommandoerne aldrig udløst. Tjek at sektionsnavnet matcher jeres faktiske udbyder. - Blanding af gamle og nye kommandoer. Nogle teams beholder
/reviewog/improvei derespr_commands, samtidig med at de forventer den nye agentiske adfærd. Skift helt til/agentic_reviewog/agentic_describe, hvis I vil have Qodo 2.0’s fulde multi-agent-analyse. - For bredt scope ved første installation. At give Qodo-appen adgang til samtlige repositories fra dag ét gør det svært at vurdere, om konfigurationen virker som forventet. Start med ét repository, og udvid derefter gradvist.
- Ingen opfølgning på credit-forbrug. Uden et sat “overage cap” kan et team med mange og store pull requests hurtigt bruge flere credits end forventet i en travl måned. Sæt et loft, og hold øje med dashboardet i de første uger.
Forventet output: sådan ser en typisk gennemgang ud
Når /agentic_review er kørt på en pull request, poster Qodo typisk en struktureret kommentar, der er delt op i sektioner. Et forenklet eksempel, baseret på vores demo-API fra trin 4-6, kunne se sådan ud:
Qodo Agentic Review
Sikkerhed (1 fund):
- server.js:8 — Brugerinput (req.params.id) indsættes direkte i en
SQL-lignende streng. Anbefaling: brug parametriserede forespørgsler
eller en ORM til at undgå injektion.
Kodekvalitet (1 fund):
- server.js:9 — To forskellige metoder bruges til at slå brugeren op
(variablen "query" bruges aldrig). Fjern død kode eller brug den
konsekvent.
Testdækning (1 fund):
- Ingen tests fundet for GET /users/:id. Foreslået test-case vedlagt
som commitbart forslag.
Beskrivelse (auto-genereret):
"Retter fejlhåndtering i bruger-endpointet og forbereder for
fremtidig databaseintegration."Bemærk, at hvert fund er knyttet til en specifik linje og en konkret handling, ikke en generel bemærkning om “god kodepraksis”. Det er netop denne konkrethed, der ifølge Qodos egne benchmarktal er årsagen til den højere F1-score sammenlignet med enkelt-model-tilgange.
Fejlfinding: 8 problemer og løsninger
- Qodo reagerer slet ikke på en ny pull request. Tjek først, om
.pr_agent.tomler merget til standard-branchen, og om Git-appen faktisk har adgang til det pågældende repository i Qodo-portalen. - Kommandoen
/reviewvirker, men/agentic_reviewgør ikke. Bekræft at jeres konto kører Qodo 2.x og ikke en ældre V1-installation. Portalen har en separat guide til at migrere fra Qodo V1. - Kommentaren nævner kun beskrivelse, ingen gennemgang. Sandsynligvis mangler
/agentic_reviewipr_commands-listen, mens/agentic_describeer til stede. Tilføj begge, hvis I vil have begge dele automatisk. - Bitbucket-kommandoen
/improvegør ingenting. På Bitbucket hedder kommandoen/improve_codei stedet for/improve, fordi navnet er reserveret af platformen selv. - For mange irrelevante forslag. Sænk
num_code_suggestionsi[pr_reviewer]-sektionen, og overvej at tilføje projektspecifikke regler under Code Governance, så gennemgangen fokuserer på det, der faktisk betyder noget for jeres kodebase. - Azure DevOps-forbindelsen fejler med “unauthorized”. Det personlige adgangstoken mangler ofte rettigheden til at skrive kommentarer på pull requests, ikke kun læse kode. Generér et nyt token med begge rettigheder markeret.
- Credit-forbruget stiger hurtigere end forventet. Store, monolitiske pull requests koster flere credits end mange små. Opfordr teamet til mindre, hyppigere pull requests, hvilket i øvrigt også er god praksis uafhængigt af Qodo.
- Portal-konfiguration og TOML-fil modsiger hinanden. Hvis begge er sat op samtidig, kan det være uklart, hvilken der vinder. Vælg én kilde til sandhed, enten portalen eller filen, og undgå at vedligeholde begge for samme repository.
Avancerede tips til erfarne teams
Når den grundlæggende opsætning kører stabilt, er der flere måder at skrue op for værdien af platformen. For det første kan I bruge “blast radius”-vurderingen, som Qodo tilbyder til at estimere, hvor stor en del af kodebasen en given ændring reelt påvirker, hvilket er nyttigt til at prioritere, hvilke pull requests der kræver ekstra menneskelig opmærksomhed ud over AI-gennemgangen.
For det andet bør organisationer med flere teams overveje BYOK (bring your own key) på Enterprise-planen, så gennemgangerne kører på jeres egne LLM-nøgler i stedet for Qodos delte infrastruktur. Det giver bedre kontrol over dataflow og kan være et krav, hvis jeres compliance-afdeling stiller krav om, at kode aldrig forlader en bestemt juridisk jurisdiktion, hvilket er særligt relevant for finans- og sundhedssektoren i Norden under NIS2 og lignende regulering.
For det tredje: kombinér Qodos Rules-system med jeres eksisterende linting og statisk analyse i stedet for at erstatte det. Qodo er stærkest til kontekstafhængige vurderinger, som en traditionel linter ikke kan lave, mens en linter stadig er hurtigere og billigere til at fange rene formateringsfejl. De to lag udfylder hinanden i stedet for at konkurrere.
Endelig, hvis jeres team allerede bruger flere AI-værktøjer i produktionsflowet, kan det være værd at kigge på, hvordan Qodo Merge sammenlignes med indbyggede AI-gennemgangsfunktioner i platforme som GitLab Duo, især hvis I allerede har oplevet sikkerhedsproblemer med indbyggede AI-funktioner i jeres CI/CD-kæde.
Sådan sammenligner Qodo sig med andre kodegennemgangsværktøjer
Der findes flere andre værktøjer, der løser lignende problemer, men med forskellig vægtning. Sourcegraph Cody fokuserer mere på kodesøgning og forståelse af store kodebaser end på automatiseret pull request-gennemgang. GitHub Copilot har i 2026 fået sin egen funktion til at godkende og kommentere pull requests, men den er tættere bundet til GitHub-økosystemet, mens Qodo bevidst er bygget udbyder-uafhængigt fra starten.
| Værktøj | Primært fokus | Git-udbydere | Åben kildekode-komponent |
|---|---|---|---|
| Qodo Merge | Automatiseret PR-gennemgang, multi-agent | GitHub, GitLab, Bitbucket, Azure DevOps | Ja (PR-Agent) |
| GitHub Copilot | Kodegenerering + PR-godkendelse | Primært GitHub | Nej |
| Sourcegraph Cody | Kodesøgning i store kodebaser | GitHub, GitLab, Bitbucket | Delvist |
| GitLab Duo | Indbygget AI i GitLab-platformen | Kun GitLab | Nej |
Vælger man Qodo, er en af de klareste fordele netop platform-uafhængigheden: samme konfiguration og samme regelsæt kan genbruges på tværs af GitHub, GitLab, Bitbucket og Azure DevOps, hvilket er en fordel for organisationer, der (som mange offentlige og halvoffentlige danske institutioner) sidder med en blanding af Git-udbydere på tværs af forskellige afdelinger.
Det åbne kildekode-spor er også værd at nævne særskilt. PR-Agent, som ligger til grund for Qodo Merge, findes stadig som et selvstændigt open source-projekt under organisationen qodo-ai på GitHub. Det betyder, at teams med stærke krav om selvhostning eller begrænset budget kan køre en tidligere, ikke-agentisk version af gennemgangsværktøjet helt gratis og selv styre infrastrukturen, mod til gengæld at gå glip af Qodo 2.0’s multi-agent-arkitektur, portal, dashboard og Enterprise-funktioner som SSO og BYOK. For et lille team eller et sideprojekt kan det være det rigtige valg, mens organisationer, der har brug for central styring på tværs af mange repositories, hurtigt vil finde den hostede løsning mere tidsbesparende.
Sådan migrerer du fra Qodo V1, hvis I allerede er kunder
Har jeres team brugt Qodo Merge eller PR-Agent, før februar 2026-arkitekturen kom, ligger I sandsynligvis stadig på det, dokumentationen kalder Qodo V1. Det er ikke automatisk et problem: de gamle kommandoer /review, /describe og /improve virker fortsat, og gennemgangen stopper ikke med at fungere fra den ene dag til den anden. Men I går glip af den forbedrede træfsikkerhed, som multi-agent-arkitekturen giver, og på sigt bliver V1 udfaset til fordel for V2.
Migreringen foregår i tre trin. Først opdaterer I .pr_agent.toml, så pr_commands-listen erstatter de gamle kommandoer med /agentic_review og /agentic_describe, som beskrevet i trin 5 ovenfor. Dernæst tjekker I, om jeres eventuelle brugerdefinerede prompts under [pr_reviewer] og [pr_code_suggestions] stadig er kompatible, da nogle ældre nøgler er blevet omdøbt i forbindelse med overgangen til den agentiske arkitektur. Til sidst kører I en testgennemgang på en ubetydelig pull request for at bekræfte, at de nye kommandoer trigges korrekt, før I ruller ændringen ud på jeres vigtigste repositories.
Et praktisk råd fra migreringen: lad de gamle og nye kommandoer køre parallelt i en overgangsperiode på et testrepository, så I kan sammenligne output fra /review og /agentic_review side om side, før I fjerner de gamle kommandoer helt fra produktions-repositories. Det giver jer et konkret grundlag for at vurdere, om den nye arkitektur reelt finder flere eller mere relevante problemer i netop jeres kodebase, i stedet for blot at stole på de generelle benchmarktal.
On-premises og data-residency for danske og nordiske organisationer
For organisationer i den offentlige sektor eller i regulerede brancher som finans og sundhed er spørgsmålet om, hvor koden fysisk behandles, ofte lige så vigtigt som selve funktionaliteten. Qodo tilbyder to relevante modeller for dette: en single-tenant SaaS-installation, hvor jeres data holdes adskilt fra andre kunders infrastruktur, og en fuld on-premises-installation, hvor platformen kører inden for jeres eget netværk.
Begge modeller kræver Enterprise-planen og en dialog med Qodos salgsteam, da opsætningen involverer netværkskonfiguration, der varierer fra organisation til organisation. Kombineret med BYOK-funktionen (bring your own key) betyder det, at hverken selve koden eller de LLM-kald, der analyserer den, nødvendigvis behøver forlade jeres egen infrastruktur eller jeres valgte cloud-region. Det er særligt relevant i lyset af NIS2-direktivet, som fra 2026 stiller skærpede krav til leverandørstyring og dokumentation af, hvor kritiske systemers data behandles, for de cirka 6.000 danske virksomheder, der er omfattet af reglerne.
Hvis jeres organisation endnu ikke har taget stilling til, om en cloud-baseret eller selvhostet model er det rigtige valg, er en praktisk tilgang at starte på Pro Team-planen med standard SaaS-driften, indsamle erfaring med, hvilke repositories og teams der har mest gavn af værktøjet, og først derefter forhandle en Enterprise-aftale med de specifikke data-residency-krav, som jeres compliance-afdeling stiller.
Komplet eksempelprojekt: fra kode til godkendt gennemgang
Her er den samlede, rettede version af demo-API’et efter at have fulgt Qodos forslag fra trin 6, så du kan se, hvordan koden ser ud, når sikkerhedsfundet er rettet:
const express = require('express');
const app = express();
app.use(express.json());
const users = [{ id: 1, name: 'Anna', email: '[email protected]' }];
app.get('/users/:id', (req, res) => {
const id = Number(req.params.id);
if (Number.isNaN(id)) return res.status(400).send('Ugyldigt ID');
const user = users.find(u => u.id === id);
if (!user) return res.status(404).send('Not found');
res.json(user);
});
module.exports = app;
if (require.main === module) {
app.listen(3000, () => console.log('API kører på port 3000'));
}Og den tilhørende test, som enten Qodo Cover foreslår, eller som du selv skriver ud fra Qodos anbefaling om manglende testdækning:
const request = require('supertest');
const app = require('./server');
describe('GET /users/:id', () => {
it('returnerer bruger ved gyldigt ID', async () => {
const res = await request(app).get('/users/1');
expect(res.statusCode).toBe(200);
expect(res.body.name).toBe('Anna');
});
it('returnerer 404 ved ukendt ID', async () => {
const res = await request(app).get('/users/999');
expect(res.statusCode).toBe(404);
});
it('returnerer 400 ved ugyldigt ID', async () => {
const res = await request(app).get('/users/abc');
expect(res.statusCode).toBe(400);
});
});Kør testene lokalt for at bekræfte, at alt virker, før du pusher den endelige version:
npm testPush ændringerne, og lad Qodo køre en ny /agentic_review på den opdaterede pull request. Denne gang bør sikkerhedsfundet være væk, og testdæknings-sektionen bør vise, at der nu findes tests for endpointet.
Sikkerhedsovervejelser, før I giver Qodo adgang til kodebasen
At give et tredjepartsværktøj læseadgang til hele kodebasen og skriveadgang til pull request-kommentarer er ikke en beslutning, der bør tages alene af den udvikler, der sætter integrationen op. Som minimum bør jeres sikkerhedsansvarlige eller IT-sikkerhedsfunktion involveres, inden Qodo-appen godkendes på et repository med produktionskode eller adgang til hemmeligheder i CI/CD-variabler.
Konkret bør I tjekke tre ting. For det første, hvilken adgang appen faktisk beder om ved installation, både på GitHub, GitLab, Bitbucket og Azure DevOps, adgangen bør være begrænset til de repositories, I aktivt vil have gennemgået, ikke organisationens fulde portefølje. For det andet, om jeres eksisterende hemmeligheder (API-nøgler, adgangskoder, certifikater) allerede er fjernet fra kodebasen og flyttet til en secrets manager, da en AI-gennemgangsplatform i praksis får læseadgang til alt, hvad der ligger i diffen, inklusive eventuelle hardkodede værdier. For det tredje, om jeres dataklassificering tillader, at kildekode sendes til en ekstern leverandørs infrastruktur, medmindre I har valgt BYOK eller on-premises-modellen beskrevet ovenfor.
Det er værd at bemærke, at denne type overvejelse ikke er unik for Qodo. Enhver AI-drevet udviklingsplatform, uanset om det er en kodeassistent, en gennemgangsplatform eller en test-generator, rejser de samme spørgsmål om dataflow og adgangsstyring. Den praktiske forskel ligger i, hvor gennemsigtig leverandøren er omkring, hvilke data der forlader jeres infrastruktur, og hvilke kontrolmuligheder (som BYOK og on-prem) der findes for organisationer med skærpede krav.
Ordliste: centrale begreber i Qodo
| Begreb | Betydning |
|---|---|
| Qodo Gen | IDE-, CLI- og Git-integreret AI-assistance under selve kodningen |
| Qodo Merge / PR-Agent | Automatiseret gennemgang af pull requests, delvist open source |
| Qodo Cover | Automatisk generering af unit-tests for kode uden testdækning |
| Agentic Toolbox | CLI-baseret kvalitetslag til brug sammen med kodende AI-agenter |
| .pr_agent.toml | Konfigurationsfil, der styrer gennemgangens adfærd pr. repository |
| Blast radius | Vurdering af, hvor stor en del af kodebasen en ændring reelt påvirker |
| BYOK | Bring Your Own Key — brug af egne LLM-nøgler i stedet for Qodos delte infrastruktur |
Ofte stillede spørgsmål
Er Qodo gratis at bruge?
Der findes en 14-dages gratis prøveperiode uden krav om betalingskort med ubegrænsede gennemgange i perioden. Herefter kræver fortsat brug enten Pro Team-planen eller en Enterprise-aftale.
Kan Qodo bruges sammen med GitHub Copilot eller Cursor?
Ja. Qodo Gen konkurrerer ikke direkte med disse værktøjer, da fokus er på gennemgang og kvalitetssikring af kode, uanset om koden blev skrevet af et menneske eller en anden AI-assistent.
Hvilke Git-udbydere understøtter Qodo?
GitHub, GitLab, Bitbucket (Cloud og Server) og Azure DevOps understøttes alle direkte via dedikerede installationsflows i Qodo-portalen.
Hvad er forskellen på /review og /agentic_review?/review er den ældre, enkelt-model-baserede gennemgang, mens /agentic_review hører til Qodo 2.0-arkitekturen med fire parallelle specialist-agenter for fejl, kodekvalitet, sikkerhed og testdækning.
Kræver opsætningen adgang til hele kodebasen med det samme?
Nej. Du kan starte med at give Qodo-appen adgang til et enkelt repository og udvide adgangen gradvist, efterhånden som I bliver komfortable med konfigurationen.
Er data fra vores kode sikre hos Qodo?
Enterprise-planen tilbyder BYOK, single-tenant SaaS eller on-prem-installation for organisationer med strenge krav til datahåndtering. Pro Team-planen inkluderer streng data-retention som standard.
Kan jeg bruge Qodo på selvhostede GitLab- eller Bitbucket-installationer?
Bitbucket Server (selvhostet) understøttes via en separat konfigurationssektion, [bitbucket_server], adskilt fra den skybaserede [bitbucket_app]-sektion. On-premises-dokumentationen dækker de nødvendige netværks- og adgangskrav.
Hvad koster det, hvis vi vokser ud af Pro Team-planen?
Pro Team er designet til op til 30 brugere. Derover er man henvist til en Enterprise-aftale med individuel prisfastsættelse, som kræver en dialog med Qodos salgsteam via en demo.
Skal vi vælge de nye agentiske kommandoer, eller er de gamle kommandoer fint nok til et lille team?
Hvis I lige er startet og kun har et enkelt repository, gør det ikke den store forskel i praksis, om I bruger /review eller /agentic_review, da begge stadig virker. Men da Qodo selv dokumenterer, at de ældre kommandoer gradvist udfases til fordel for den agentiske arkitektur, er det mest fremtidssikret at starte med /agentic_review og /agentic_describe fra dag ét, så I undgår en migrering senere, når de gamle kommandoer på et tidspunkt stopper med at blive vedligeholdt.
