{"slug": "pair-programming-earned-a-lighter-code-review-ai-hasn-t", "title": "Pair Programming Earned a Lighter Code Review. AI Hasn't.", "summary": "A developer argues that AI-assisted coding should not automatically receive lighter code reviews, unlike traditional pair programming which has earned such trust through research. The post cites studies showing pair programming's benefits and warns that AI-generated code introduces security issues and functional bugs, while evaluation costs remain high.", "body_md": "Is writing code with an agent the same thing as pair programming?\n\nThat question has been going around lately, and there's a practical consequence sitting inside it that I don't see many people chasing down.\n\nOn a lot of teams, code that a pair of devs wrote gets a lighter code review.\n\nI personally have never seen that written down anywhere. It's not in a policy doc and nobody voted on it. But everywhere I have worked, when a PR came from two people who built and tested it together, the review was lighter. Reviewers trusted the code more. Fewer issues got found in review. Fewer bugs slipped through afterward. So the lighter review kept looking like the right call, and it stuck.\n\nThat's a risk decision, even though it never feels like one. Somebody looked at a category of change and decided it needed less scrutiny than everything else.\n\nAnd here is the part worth sitting with. Pairing earned that discount.\n\nResearchers have studied pair programming for a long time, and the results are less magical than the marketing but pretty consistent.\n\nCockburn and Williams (2000) found pairing costs roughly 15% more development time and buys back roughly 15% fewer defects. They also measured statistically significant gains in design quality, technical skill, team communication, and resilience when someone leaves, since knowledge stops living in one person's head.\n\nThe 2009 meta-analysis from Hannay, Dybå, Arisholm and Sjøberg is more nuanced. A small positive effect on quality. A medium positive effect on duration, so pairs finish faster on the clock. A medium negative effect on effort, because they burn more total person-hours. Complexity moves the needle too: pairs are faster when the work is simple, and produce higher quality when the work is hard.\n\nA couple caveats here, since I'm using this research to defend a practice. Neither study measured code review specifically. They measured defects and duration, and \"so review gets shorter\" is my personal inference from fewer defects showing up at the door. The authors of the meta-analysis also flag signs of publication bias in the pair programming literature, which is worth knowing before anyone treats these numbers as completely settled.\n\nEven with these caveats, there's a track record here. The lighter review is resting on something real.\n\nThe other thing about that discount is that it was never a one size fits all deal.\n\nTwo juniors pairing usually produce better code than either of them would have alone. Genuinely better. But still not as good as what comes out when a senior is in the pair. I've watched that difference play out enough times to treat it as a hard rule rather than a hunch.\n\nSo the shortcut was never \"pairing gets a lighter review.\" It was closer to \"this pair, working on this, has earned a lighter review.\" Everybody doing the reviewing knew that, even if nobody ever said it.\n\nWhich raises the question that made me want to write all of this stuff down...if a developer plus an agent counts as a pair, which pair is it?\n\nI want to be careful here, because there's a lot to consider and the tooling is moving fast. But from what I've seen up to this point, AI generated code on its own comes with a lot of problems in it. Security issues. Functional bugs. And a slower one that worries me more than the rest...people losing their understanding of their own systems, which makes those systems harder to fix the longer it goes on.\n\nNone of that earns a lighter review.\n\nThe cost moved the other direction at the same time, too. We've all read and seen how producing code got cheap. Evaluating it didn't. Nothing about an agent made reading code faster, made holding a system in your head easier, or made it quicker to spot a wrong assumption (no matter how confident the agent sounds).\n\nSo put those together. A lot of developers are working with agents right now. If that counts as pairing, it gets the lighter review. So we read less of the code, right when a lot more of it is showing up. And it's the kind that's hardest to spot problems in just by reading it.\n\nThat cost doesn't stay with the team that filed it that way. It lands on users, on clients, and on the business, usually much later.\n\nThat's the part I'm mulling over today.\n\nNo one on the engineering team is going to stand up and propose reviewing AI written code less carefully (at least I hope not). That's not how it happens. It happens when a category you already had quietly absorbs a new kind of work, and the rule attached to that category comes along for the ride. Dev + agent starts getting called pairing, pairing already had a discount, and the discount transfers without anyone explicitly deciding anything.\n\nMost teams inherited their review shortcuts, and I'd be surprised if anyone wrote down what earned them. So when something new shows up asking to be filed under an existing category, there's nothing to check it against.\n\nSo here is what I would actually ask you to do, and then a real question.\n\nGo find your team's review shortcuts. The paired code one. The \"it's only a config change\" one. The \"this person's PRs are always clean\" one. They exist, they're mostly unwritten, and you probably inherited at least one of them from a team you're no longer on.\n\nThen ask what earned each one, and whether that thing is still true for the code you're merging today.\n\nWhat did you find when you went looking? I am very curious whether other teams have caught this happening, or whether it's already too far along to see clearly. If you would rather talk it through than leave a comment, my inbox is open.", "url": "https://wpnews.pro/news/pair-programming-earned-a-lighter-code-review-ai-hasn-t", "canonical_source": "https://dev.to/pixel-wraith/pair-programming-earned-a-lighter-code-review-ai-hasnt-2e4f", "published_at": "2026-08-03 20:09:43+00:00", "updated_at": "2026-08-03 20:43:29.216194+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-safety"], "entities": ["Cockburn", "Williams", "Hannay", "Dybå", "Arisholm", "Sjøberg"], "alternates": {"html": "https://wpnews.pro/news/pair-programming-earned-a-lighter-code-review-ai-hasn-t", "markdown": "https://wpnews.pro/news/pair-programming-earned-a-lighter-code-review-ai-hasn-t.md", "text": "https://wpnews.pro/news/pair-programming-earned-a-lighter-code-review-ai-hasn-t.txt", "jsonld": "https://wpnews.pro/news/pair-programming-earned-a-lighter-code-review-ai-hasn-t.jsonld"}}