{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"ai/ai-code-review","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/ai/ai-code-review/","da":"https://cmaintz.github.io/tech-atlas/da/terms/ai/ai-code-review/"},"term":{"en":"AI code review","da":"AI-kodegennemgang"},"aka":{"en":["AI-assisted code review"],"da":["AI-assisteret kodegennemgang"]},"domain":["ai"],"cluster":"ai-coding","layer":"application","status":"emerging","summary":{"en":"Using a large language model to read proposed code changes and leave comments on bugs, risks and style before a person approves them.","da":"At lade en stor sprogmodel læse foreslåede kodeændringer og kommentere fejl, risici og stil, før et menneske godkender dem."},"body":{"formal":{"en":"The use of a large language model, triggered when a change is proposed in version control, to read the changed lines with their surrounding code and post comments that point out likely bugs, security weaknesses and unclear parts, as an addition to review by people.","da":"Brugen af en stor sprogmodel, der sættes i gang, når en ændring foreslås i versionsstyring, til at læse de ændrede linjer og koden omkring dem og skrive kommentarer om sandsynlige fejl, sikkerhedssvagheder og uklare steder, som en tilføjelse til menneskers gennemgang."},"plain":{"en":"Like a proof-reader who checks every letter before it is posted - quick to spot slips, sometimes fussy about nothing, and never the one who signs it.","da":"Som en korrekturlæser, der tjekker hvert brev, før det sendes - hurtig til at fange smuttere, af og til pernitten over ingenting og aldrig den, der skriver under."},"inPractice":{"en":"At a software house building a school portal, a developer opens a change request; within a minute an AI reviewer notes that a new search field goes straight into a database query, and the senior developer confirms it and sends the change back.","da":"Hos et softwarehus, der bygger en skoleportal, åbner en udvikler en ændringsanmodning; inden for et minut påpeger en AI-gennemgang, at et nyt søgefelt sendes direkte ind i en databaseforespørgsel, og seniorudvikleren bekræfter det og sender ændringen tilbage."},"whyItMatters":{"en":"It catches easy mistakes early and gives every change a first reading, but it misses some real problems and flags harmless ones, so it supports human review rather than replacing it.","da":"Den fanger lette fejl tidligt og giver hver ændring en første læsning, men den overser nogle reelle problemer og markerer harmløse, så den støtter menneskers gennemgang frem for at erstatte den."}},"deepDive":{"en":"A typical AI reviewer is triggered by a pull-request webhook or a CI job. It assembles context from the diff hunks, the surrounding code of each changed function, related files found through a repository index or embeddings, the pull-request description and linked issue, and any repository instruction files; it then asks a model for findings and maps each one to a file and line range posted through the code host's review API. More elaborate tools run as agents that can open further files, run the test suite or invoke static analysers before commenting. Some teams also use the same machinery for summarising the change for human reviewers, which is often more reliably useful than the findings themselves.\n\nThe engineering problem is precision. A reviewer that posts ten speculative comments per pull request trains developers to ignore it, so products filter by confidence and severity, deduplicate, restrict comments to changed lines, and let teams suppress categories. LLM reviewers are comparatively good at local defects visible in the diff: missing null or bounds checks, off-by-one errors, unescaped input reaching a query or shell, swallowed exceptions, and mismatches between code and its docstring or tests. They are weak where the relevant fact is outside the context: business rules, cross-service invariants, authorisation that depends on configuration elsewhere, concurrency, and whether the change is the right design at all. Output is non-deterministic, so the same diff can yield different findings on a rerun.\n\nAI review complements rather than replaces static application security testing. SAST tools apply deterministic, CWE-mapped rules with reproducible results and SARIF output suitable for audit trails; an LLM reviewer finds some issues rules cannot express but cannot demonstrate coverage. A known weakness is correlated blind spots: when the same model family that generated the code also reviews it, both may share the same misconception.\n\nTwo governance points matter. First, the pipeline itself is an attack surface: on public repositories the pull-request text and code are attacker-controlled and can carry prompt injection aimed at suppressing findings or, if the job has secrets or a write-scoped token, exfiltrating them, so the reviewer should run with read-only permissions and without secrets on fork contributions. Second, accountability stays human. NIST SP 800-218 (SSDF) practice PW.7 calls for reviewing and/or analysing human-readable code to identify vulnerabilities; an AI reviewer can be one documented input to that practice, but branch protection should still require an approving human review, and bot comments should never count as approval.","da":"En typisk AI-reviewer udløses af en webhook for en pull request eller et CI-job. Den samler kontekst fra diffens hunks, den omgivende kode for hver ændret funktion, relaterede filer fundet via et repository-indeks eller embeddings, beskrivelsen af pull requesten og den tilknyttede issue samt eventuelle instruktionsfiler i repositoryet; derefter beder den en model om fund og knytter hvert fund til en fil og et linjeinterval, der postes via kodehostens review-API. Mere avancerede værktøjer kører som agenter, der kan åbne flere filer, køre testsuiten eller kalde statiske analyseværktøjer, før de kommenterer. Nogle teams bruger også samme maskineri til at opsummere ændringen for de menneskelige reviewere, hvilket ofte er mere pålideligt nyttigt end selve fundene.\n\nDet tekniske problem er præcision. En reviewer, der poster ti spekulative kommentarer pr. pull request, lærer udviklerne at ignorere den, så produkterne filtrerer efter sikkerhed og alvor, fjerner dubletter, begrænser kommentarer til ændrede linjer og lader teams slå kategorier fra. LLM-reviewere er forholdsvis gode til lokale fejl, der kan ses i diffen: manglende tjek for null eller grænser, off-by-one-fejl, uescapet input, der når en forespørgsel eller en shell, undertrykte undtagelser og uoverensstemmelser mellem koden og dens docstring eller tests. De er svage, hvor den relevante viden ligger uden for konteksten: forretningsregler, invarianter på tværs af tjenester, autorisation, der afhænger af konfiguration andre steder, samtidighed, og om ændringen overhovedet er det rigtige design. Outputtet er ikke-deterministisk, så samme diff kan give forskellige fund ved en ny kørsel.\n\nAI-kodegennemgang supplerer statisk sikkerhedstest (SAST) frem for at erstatte den. SAST-værktøjer anvender deterministiske regler knyttet til CWE med reproducerbare resultater og SARIF-output, der egner sig til revisionsspor; en LLM-reviewer finder nogle problemer, som regler ikke kan udtrykke, men kan ikke dokumentere dækning. En kendt svaghed er korrelerede blinde vinkler: Når samme modelfamilie, som skrev koden, også gennemgår den, kan begge dele have samme misforståelse.\n\nTo styringspunkter er vigtige. For det første er selve pipelinen en angrebsflade: På offentlige repositories er teksten og koden i en pull request styret af angriberen og kan bære prompt injection, der sigter mod at undertrykke fund eller, hvis jobbet har hemmeligheder eller et token med skriveadgang, at lække dem, så revieweren bør køre med læseadgang alene og uden hemmeligheder på bidrag fra forks. For det andet forbliver ansvaret menneskeligt. NIST SP 800-218 (SSDF), praksis PW.7, kræver gennemgang og/eller analyse af menneskelæsbar kode for at finde sårbarheder; en AI-reviewer kan være ét dokumenteret input til den praksis, men branch protection bør stadig kræve en godkendende menneskelig gennemgang, og kommentarer fra bots må aldrig tælle som godkendelse."},"edges":[{"type":"requires","to":"ai/large-language-model","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/vulnerability","why":{"en":"It can spot common security slips, such as unchecked input, before they are merged - though it misses others and must not be the only check.","da":"Den kan fange almindelige sikkerhedsfejl, som ukontrolleret input, før de flettes ind - men den overser andre og må ikke være det eneste tjek."},"confidence":"medium","strength":"normal"},{"type":"causes","to":"security/false-positive","why":{"en":"It often flags code that is actually fine, and too many such comments teach people to ignore it.","da":"Den markerer ofte kode, der faktisk er i orden, og for mange af den slags kommentarer lærer folk at ignorere den."},"confidence":"medium","strength":"minor"},{"type":"used-with","to":"platform/ci-cd","why":{"en":"It runs as one more automatic step when a change is proposed, next to the build and tests.","da":"Den kører som endnu et automatisk trin, når en ændring foreslås, ved siden af bygning og tests."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"platform/version-control","why":{"en":"It reads the proposed change and posts its comments where the team already discusses changes before merging.","da":"Den læser den foreslåede ændring og skriver sine kommentarer, hvor teamet i forvejen drøfter ændringer før sammenfletning."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"ai/human-in-the-loop","why":{"en":"A person still decides whether each comment matters and whether the change is approved.","da":"Et menneske afgør stadig, om hver kommentar er vigtig, og om ændringen godkendes."},"confidence":"high","strength":"normal"},{"type":"used-with","to":"ai/ai-coding-assistant","confidence":"high","strength":"normal"}],"depth":3,"sources":[{"title":"OWASP Top 10 for Large Language Model Applications 2025","tier":"reference","publisher":"OWASP"},{"title":"NIST SP 800-218 - Secure Software Development Framework (SSDF) Version 1.1","tier":"standard","publisher":"NIST"}],"draft":true}