{"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-pair-programming","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/ai/ai-pair-programming/","da":"https://cmaintz.github.io/tech-atlas/da/terms/ai/ai-pair-programming/"},"term":{"en":"AI pair programming","da":"AI-parprogrammering"},"aka":{"en":["pair programming with AI"],"da":["parprogrammering med AI"]},"domain":["ai"],"cluster":"ai-coding","layer":"application","status":"current","era":2021,"summary":{"en":"Writing code together with an AI tool in a running back-and-forth, where the human stays in charge and checks every change.","da":"At skrive kode sammen med et AI-værktøj i en løbende dialog, hvor mennesket bestemmer og tjekker hver ændring."},"body":{"formal":{"en":"A way of working, named after the practice of two programmers sharing one screen, in which a developer and an AI coding assistant take turns proposing, questioning and refining code, with the developer reading and approving each change before it is kept.","da":"En arbejdsform, opkaldt efter praksissen med to programmører ved én skærm, hvor en udvikler og en AI-kodeassistent skiftes til at foreslå, udfordre og forbedre kode, og udvikleren læser og godkender hver ændring, før den beholdes."},"plain":{"en":"Like driving with a quick-thinking friend reading the map - they suggest turns and spot signs, but your hands stay on the wheel and you decide where to go.","da":"Som at køre bil med en kvik ven, der læser kortet - vennen foreslår sving og ser skilte, men dine hænder bliver på rattet, og du bestemmer, hvor turen går hen."},"inPractice":{"en":"A developer at an accounting firm, chasing a rounding error in invoice totals, asks the assistant for two possible fixes, picks one, then has it explain a line she does not trust before keeping the change.","da":"En udvikler i et revisionsfirma, der leder efter en fejl i, hvordan fakturabeløb rundes af, beder assistenten om to mulige løsninger, vælger den ene og får den så til at forklare en linje, hun ikke stoler på, før hun beholder ændringen."},"whyItMatters":{"en":"Keeping a person reading along is what separates helpful speed from blind trust - the human catches the confident mistakes before they reach real users.","da":"At et menneske læser med, er det, der skiller nyttig fart fra blind tillid - mennesket fanger de selvsikre fejl, før de når rigtige brugere."}},"deepDive":{"en":"Pair programming was formalised in Extreme Programming by Kent Beck in the late 1990s: two developers at one workstation, a driver who types and a navigator who reviews each line, thinks ahead and catches mistakes, swapping roles frequently. GitHub marketed Copilot from its 2021 launch as \"your AI pair programmer\", and tools such as Aider describe themselves the same way. The metaphor is imperfect in an instructive way: in AI pairing the model usually drives, producing code faster than a person types, and the human becomes the permanent navigator, whose job is exactly the review discipline that is easiest to let slip.\n\nEffective practice keeps changes small and reversible. The developer states intent and constraints, asks for one focused change, reads the diff, runs tests, and commits before the next step, so each increment can be rolled back; Aider, for example, commits every AI edit to git automatically for this reason. Useful moves include asking for two alternative approaches before choosing, asking the model to explain a line or predict how code behaves on an edge case, having it write failing tests first and then the implementation, and challenging its assumptions rather than accepting the first answer. The model has no persistent memory of team conventions unless they are supplied through instruction files or the prompt.\n\nThe productivity evidence is mixed and context-dependent. In a controlled experiment by Peng et al. (2023), developers with Copilot completed a greenfield task, implementing an HTTP server in JavaScript, 55.8% faster than a control group. METR's randomised trial published in July 2025 found the opposite for experts on familiar ground: 16 experienced open-source maintainers working on 246 real issues in their own large repositories took 19% longer when AI tools were allowed, while believing afterwards that AI had made them about 20% faster. The gap between perceived and measured speed is itself a reason to measure rather than assume.\n\nThe security evidence points the same way. Perry et al. (ACM CCS 2023) found that participants with an AI assistant wrote less secure code on several tasks and were more likely to believe their code was secure, a textbook case of automation bias. Human pairing also delivers knowledge sharing, collective code ownership and mentoring, which AI pairing does not replace and may erode if juniors accept code they could not have written. The line from vibe coding is whether the human reads and understands every change; the line from a coding agent is whether the human is present at every step.","da":"Parprogrammering blev formaliseret i Extreme Programming af Kent Beck i slutningen af 1990'erne: to udviklere ved én arbejdsstation, en driver, der skriver, og en navigatør, der gennemgår hver linje, tænker fremad og fanger fejl, og de bytter roller ofte. GitHub markedsførte Copilot fra lanceringen i 2021 som \"your AI pair programmer\", og værktøjer som Aider beskriver sig selv på samme måde. Metaforen halter på en lærerig måde: Ved AI-parprogrammering er det som regel modellen, der kører, og den producerer kode hurtigere, end et menneske skriver, mens mennesket bliver den permanente navigatør, hvis opgave netop er den disciplin med gennemgang, der er lettest at slække på.\n\nGod praksis holder ændringerne små og reversible. Udvikleren angiver hensigt og begrænsninger, beder om én fokuseret ændring, læser diffen, kører testene og committer før næste trin, så hvert skridt kan rulles tilbage; Aider committer fx automatisk hver AI-ændring til git af netop den grund. Nyttige greb er at bede om to alternative løsninger, før man vælger, at bede modellen forklare en linje eller forudsige, hvordan koden opfører sig i et grænsetilfælde, at lade den skrive fejlende tests først og derefter implementeringen og at udfordre dens antagelser i stedet for at tage det første svar. Modellen har ingen varig hukommelse om teamets konventioner, medmindre de gives via instruktionsfiler eller prompten.\n\nEvidensen for produktivitet er blandet og afhænger af konteksten. I et kontrolleret eksperiment af Peng et al. (2023) løste udviklere med Copilot en opgave fra bunden, at implementere en HTTP-server i JavaScript, 55,8 % hurtigere end en kontrolgruppe. METR's randomiserede forsøg, offentliggjort i juli 2025, fandt det modsatte for eksperter på kendt grund: 16 erfarne open source-maintainere, der arbejdede på 246 reelle issues i deres egne store repositories, brugte 19 % længere tid, når AI-værktøjer var tilladt, men mente bagefter, at AI havde gjort dem ca. 20 % hurtigere. Kløften mellem oplevet og målt hastighed er i sig selv en grund til at måle frem for at antage.\n\nSikkerhedsevidensen peger samme vej. Perry et al. (ACM CCS 2023) fandt, at deltagere med en AI-assistent skrev mindre sikker kode i flere opgaver og oftere troede, at deres kode var sikker, et skoleeksempel på automatiseringsbias. Parprogrammering mellem mennesker giver desuden videndeling, fælles ejerskab af koden og mentorskab, som AI-parprogrammering ikke erstatter og kan udhule, hvis juniorudviklere accepterer kode, de ikke selv kunne have skrevet. Grænsen til vibe coding går ved, om mennesket læser og forstår hver ændring; grænsen til en kodeagent går ved, om mennesket er til stede ved hvert trin."},"edges":[{"type":"requires","to":"ai/ai-coding-assistant","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"ai/vibe-coding","why":{"en":"Both hand the typing to AI, but in pair programming the developer reads and understands every change, while vibe coding skips that reading on purpose.","da":"Begge overlader skrivningen til AI, men ved parprogrammering læser og forstår udvikleren hver ændring, mens vibe coding bevidst springer den læsning over."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"ai/human-in-the-loop","why":{"en":"The developer approving each change is a human-in-the-loop check applied to everyday programming.","da":"At udvikleren godkender hver ændring, er menneske i løkken anvendt på daglig programmering."},"confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/version-control","confidence":"high","strength":"normal"}],"depth":4,"sources":[{"title":"Chen et al. (2021), Evaluating Large Language Models Trained on Code","tier":"reference"},{"title":"Perry et al. (2023), Do Users Write More Insecure Code with AI Assistants? (ACM CCS)","tier":"reference"},{"title":"METR (2025), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity","url":"https://arxiv.org/abs/2507.09089","tier":"reference","publisher":"METR"},{"title":"Peng et al. (2023), The Impact of AI on Developer Productivity: Evidence from GitHub Copilot","url":"https://arxiv.org/abs/2302.06590","tier":"reference","publisher":"arXiv"}],"draft":true}