{"slug": "your-team-is-getting-faster-at-code-review-your-seniors-are-drowning", "title": "Your Team Is Getting Faster at Code Review. Your Seniors are Drowning.", "summary": "A senior engineer reports that while their team has become faster at code review since adopting coding agents, the quality of merged code has declined, with more infrastructure and functional issues slipping through. The engineer attributes this to agent-generated code appearing plausible on the surface, leading reviewers to ease off, and cites a study finding agent-authored pull requests have 1.87 times the semantic redundancy and receive more positive reactions than human-authored ones. The engineer, who is also the team's manager and architect, says they are 'drowning' under the review load and that the traditional review model has stopped working.", "body_md": "Every so often I go read code that's shipped in our platform. Not to review it (that ship has already sailed)...just to see where the system is drifting.\n\nLately I've been finding a lot of issues. Not nitpicks or code style issues. I mean infrastructure and functional problems that are hurting how our application performs and how far it can scale.\n\nAfter sitting and thinking on this (and doing some reading), I don't think my team got sloppy. If anything, they got better at code review...\n\nWhen coding agents landed in our workflow, the volume shot up almost immediately. Every engineer on my team works with one or more agents throughout the day now, and the majority of the code going into our platform is generated that way.\n\nLike many teams, the first thing to break in our process was the throughput. Everyone still had their own work to get done, and on top of that they suddenly had a lot more pull requests to get through. Things slowed down noticeably. A lot of people have been writing about this, and yeah, we lived it too.\n\nThen we adjusted. My team moves through code review faster today than it did before any of this started.\n\nSo the queue problem got better. But the code coming out the other end has real problems in it.\n\nI want to be careful about where the blame goes here, because I don't think it belongs to the people doing the reviewing.\n\nThere's a paper from MSR '26 (Huang, Jaisri, Shimizu, Chen, Nakashima and Rodríguez-Pérez, \"More Code, Less Reuse\") that looked at 3,858 Python pull requests and compared agent authored ones against human authored ones. The agent pull requests carried roughly 1.87 times the semantic redundancy...code duplicating logic that already existed in the repo.\n\nFine, that one I could have guessed...but the second finding surprised me.\n\nReviewers responded to the agent pull requests more warmly than to the human ones. More neutral and positive reactions on the agent PRs. More disgust, anger, fear and surprise on the ones a person wrote. The authors' read is that agent output is generated on probability, so it looks plausible on the surface, and reviewers ease off accordingly.\n\nPut that next to what happened on my team and it sheds some interesting light on the situation. We got faster at review because we're reviewing code that's really good at looking fine. That's different than getting better at review...but from the inside the two feel the same.\n\nMost of what I've seen getting written about has landed on devs getting overwhelmed and burning out. And I definitely see the same patterns emerging. The load is heavy and people are tired.\n\nBut burnout is not the number that shows up in a business review...\n\nSenior engineers are spending enormous chunks of their time either reviewing everything that moves, or fixing what slipped through because a change needed senior eyes and didn't get them. That's time they aren't spending on architecture, or on the sophisticated, complicated, genuinely value driving work that mostly only they can do. Your most expensive people are buried in review queues and bug tickets.\n\nI'll use myself, since I'm the example I can speak to honestly. I'm the most senior person on my team. I'm also the manager, the architect of the system, and lately an IC working through a steady stream of issues that reached production. I need to spend more time on reviews...but there's no more time to spend.\n\nIn all honesty, I'm drowning. And unless I find a way to identify more clearly and accurately where my attention is actually needed, I don't think this gets better on its own.\n\nSomewhere in here, the review model we inherited quietly stopped working.\n\nThat model treats pull requests as roughly interchangeable. They land in one queue, they all get looked at, they all get an approval from somebody. It held up fine for a long time because a human being had to sit down and write every line first. Writing was an unofficial throttle. It isn't anymore.\n\nSo the same amount of attention now gets spread across several times the volume, and it thins out everywhere at once. The safe changes get a careful read. The dangerous ones get that same read. And I find out which was which weeks later, when I'm scrolling through merged code and I see glaring issues staring back at me.\n\nThe failure is in the model itself. It assumed every change deserves about the same scrutiny, and it's still running in a world where the volume tripled and the risk never spread itself evenly across it.\n\nThis is the problem I'm building Merge Lantern for, so consider me a little biased. It leaves the reviewing up to you. There dozens of AI review tool out there today with claims to help you with the review process. That's not what Merge Lantern does. Instead, it ranks your open pull requests by how much risk they're carrying, so the senior attention you actually have lands on the changes that need it.\n\nWhat I'm sure of is the shape of the problem. Attention is the scarce resource now. Spreading it evenly across everything was always a little wasteful, and it worked anyway when volume was low. Obviously it doesn't work now.\n\nSo here's the question I'm wrestling with this week...\n\nHow do you decide which pull requests get the careful read? Is it a written rule, is it a gut call, or is it whoever has time that afternoon? And if you've found a way to make that decision deliberately, I would love to hear how.\n\n*Huang, Haoming, et al. “More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-Generated Pull Requests.” arXiv:2601.21276, arXiv, 29 Jan. 2026. _arXiv.org*, [https://doi.org/10.48550/arXiv.2601.21276._](https://doi.org/10.48550/arXiv.2601.21276._)\n\nI'm building Merge Lantern, risk intelligence for small engineering teams. It flags which open pull requests most need senior eyes before they merge, in one short daily digest. It's early, and the first 5 design partners get their first 3 months free. If your team feels this problem, join the waitlist at [mergelantern.com](https://mergelantern.com/?utm_source=devto&utm_medium=footer&utm_campaign=your-team-is-getting-faster-at-code-review-your-seniors-are-drowning-4de7).", "url": "https://wpnews.pro/news/your-team-is-getting-faster-at-code-review-your-seniors-are-drowning", "canonical_source": "https://dev.to/pixel-wraith/your-team-is-getting-faster-at-code-review-your-seniors-are-drowning-1j75", "published_at": "2026-08-10 15:28:46+00:00", "updated_at": "2026-08-10 15:49:39.801853+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-agents", "ai-products"], "entities": ["Huang", "Jaisri", "Shimizu", "Chen", "Nakashima", "Rodríguez-Pérez"], "alternates": {"html": "https://wpnews.pro/news/your-team-is-getting-faster-at-code-review-your-seniors-are-drowning", "markdown": "https://wpnews.pro/news/your-team-is-getting-faster-at-code-review-your-seniors-are-drowning.md", "text": "https://wpnews.pro/news/your-team-is-getting-faster-at-code-review-your-seniors-are-drowning.txt", "jsonld": "https://wpnews.pro/news/your-team-is-getting-faster-at-code-review-your-seniors-are-drowning.jsonld"}}