{"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://atlas.maintz.dev/)"},"id":"ai/ai-code-review","url":{"en":"https://atlas.maintz.dev/en/terms/ai/ai-code-review/","da":"https://atlas.maintz.dev/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."},"howTo":{"steps":{"en":["Decide what the AI reviewer is for, such as a first pass for bugs and security slips or a summary for the human reviewer, and write that down in the team's review policy.","Run it from the pull request pipeline with a read-only token, and without secrets or write access on pull requests from forks, since the code and description it reads may carry prompt injection.","Keep branch protection requiring at least one approving review from a person (and from code owners where you use them), and do not let a bot's comments or approval count towards the required approvals.","Give the tool repository instructions on your conventions and known risk areas, and limit comments to changed lines and to findings above a confidence and severity threshold.","Keep your static analysis (SAST) and tests as required checks next to the AI reviewer, since the model cannot prove coverage and may share blind spots with the model that wrote the code.","Have the author or reviewer resolve every AI comment as fixed or dismissed, so the pull request history shows what was checked, as input to the code review practice in the NIST SSDF (PW.7).","Every quarter, sample dismissed and accepted comments to measure how many were real problems, and switch off categories that mostly produce noise."],"da":["Beslut, hvad AI-gennemgangen skal bruges til, fx en første gennemlæsning for fejl og sikkerhedssmuttere eller et resumé til den menneskelige reviewer, og skriv det ind i teamets politik for kodegennemgang.","Kør den fra pull request-pipelinen med et token, der kun har læseadgang, og uden hemmeligheder eller skriveadgang på pull requests fra forks, da koden og beskrivelsen, den læser, kan indeholde prompt injection.","Behold branch protection, der kræver mindst én godkendende gennemgang fra et menneske (og fra code owners, hvor I bruger dem), og lad aldrig en bots kommentarer eller godkendelse tælle med i de krævede godkendelser.","Giv værktøjet instruktioner i repositoryet om jeres konventioner og kendte risikoområder, og begræns kommentarerne til ændrede linjer og til fund over en tærskel for sikkerhed og alvor.","Behold statisk analyse (SAST) og tests som krævede tjek ved siden af AI-gennemgangen, fordi modellen ikke kan dokumentere dækning og kan have samme blinde vinkler som den model, der skrev koden.","Lad forfatteren eller revieweren lukke hver AI-kommentar som rettet eller afvist, så pull requestens historik viser, hvad der er tjekket, som input til praksissen for kodegennemgang i NIST SSDF (PW.7).","Tag hvert kvartal en stikprøve af afviste og accepterede kommentarer for at måle, hvor mange der var reelle problemer, og slå kategorier fra, der mest giver støj."]},"pitfalls":{"en":["Letting the AI review replace the human reviewer, so business rules, authorisation elsewhere and design choices are never checked by anyone.","Running the reviewer on public pull requests with secrets or a write token, so a malicious pull request can use prompt injection to steal them.","Leaving every comment category switched on, so developers drown in speculative remarks and learn to ignore the real findings."],"da":["At lade AI-gennemgangen erstatte den menneskelige reviewer, så forretningsregler, autorisation andre steder og designvalg aldrig bliver tjekket af nogen.","At køre gennemgangen på offentlige pull requests med hemmeligheder eller et token med skriveadgang, så en ondsindet pull request kan stjæle dem via prompt injection.","At have alle kommentarkategorier slået til, så udviklerne drukner i spekulative bemærkninger og lærer at overse de reelle fund."]},"guides":[{"title":"NIST SP 800-218 - Secure Software Development Framework (SSDF) Version 1.1","url":"https://csrc.nist.gov/pubs/sp/800/218/final","publisher":"NIST","tier":"standard"},{"title":"Secure Coding with AI Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"},{"title":"About GitHub Copilot code review","url":"https://docs.github.com/en/copilot/concepts/agents/code-review","publisher":"GitHub","tier":"official-doc"},{"title":"About protected branches","url":"https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches","publisher":"GitHub","tier":"official-doc"}]},"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}