# It May Take Longer to Review a PR Than It Takes to Write It > Source: > Published: 2026-07-17 14:06:11+00:00 # It May Take Longer to Review a PR Than It Takes to Write It **Olena Babenko**, Staff Software engineer at Aiven, cut straight to the uncomfortable truth in a recent interview I had with her in London. The oversight model collapses the moment the person approving the output can **no longer reliably tell whether it’s good**, bad, or just convincingly wrong. She pointed to a growing mismatch between how fast code is being generated and how slowly it is actually being checked. ## AI is speeding up code creation, but review can’t keep up Olena says she keeps running into the same cycle, that looks like this “**a steady stream of announcements about how the newest model will change software engineering**, followed almost weekly by another company unveiling its most powerful release yet”. Then someone actually turns the model on and gives it a simple task, and it hallucinates, a lot. She sees this happen often enough that the pattern itself has become the story. The industry isn’t there yet, she says, at least not in the systems she works with. The real problem, in her view, shows up one step later in the pipeline: engineers are spending less time writing code and more time reviewing it, and the incentive structures around that shift have not caught up. Therefore, I asked her what that imbalance looks like: We have an ability to generate code very, very fast, thousands of lines of code, and without thinking how people perceive that code, how readable it is, how good it is, how simple it is to understand, but code reviewing, scaling, and automation is not on that same level yet. As a result, you can create a PR, and a person who actually reviews it took **much more time to review it than you spent writing it**. This means that the problem, at least according to Olena, is structural, not just technical: The current system and a lot of managerial tools are made on KPIs, they are made on individual contributions of code writing, so if you look at the GitHub contributions or Jira tickets, they are praising writing code, finishing tasks, creating PRs, while the people who do the PR reviews, their jobs are not valued that much. Add unusually verbose AI-generated code into that mix, and reviewing takes even longer than the writing did. ## The review burden has always been there, but it’s getting worse Olena is careful to point out this isn’t new. She says that a reviewer burden existed even before all this and **AI is just amplifying this problem**. She describes a colleague’s experience at a previous company: engineers spending two weeks on an issue, then dropping a thousand-line PR on a reviewer who was, realistically, expected to just hit merge, not actually engage with the work. The fix, in her view, is not more automation but **earlier communication, smaller PRs, and separating refactoring from actual logic changes**, paired with management that treats reviewing as real work worth rewarding: This is a question of management. ## AI can make tests look good without actually making the code reliable Olena also pointed to one of the first things AI tends to break in a codebase: **unit tests**. Writing them is boring, so people delegate it a lot, but AI can already game the system, making tests pass without making the code reliable. By her account, models will patch internal implementations or hardcode expected outputs rather than genuinely verify behavior, leaving teams with high coverage numbers that protect against nothing – though the damage doesn’t show up right away. They are not falling apart in one day. This is a process that’s eroding your system with a small step day by day until you realize that your new system is really unreliable, really something you’re not supposed to do in production. By the time anyone notices, **the damage started much earlier**. ## ‘We are delegating too much thinking to AI’ Olena’s biggest long-term concern is **skill erosion**: We’re delegating too much thinking to AI. But AI doesn’t become an expert just because we use it: it has no memory, it can’t really learn, and it can’t build experience. Humans can do that, at least for now. The problem is that we’re not really learning from the experience either, so our skills and critical thinking keep getting weaker. That undercuts the standard reassurance that a human stays in the loop. “You might end up in a situation where you have a human in the loop, but those people do not have correct skills anymore”, Olena said. A safety net only works if the person holding it still knows how to catch something.