Four Eyes, Two Agents

Every developer is familiar with the review process: Before code goes live, at least one other developer takes another look at it. In my work, this process has taken on a new dimension in recent months. Now, each of my colleagues—including me—works on code changes with an AI agent. Nevertheless, the code still needs to be reviewed. I always review manually, but now I also have my own agents look over what my colleague has built. So two pairs of eyes have become four—two human and one artificial.

And the same thing happens every time: edge cases pop up that no one had thought of before—neither my colleague nor his agent.

What does one do better than the other?

Of course, you have to ask yourself this question at the outset. After all, it’s the same tool, the same model. Why does one person notice something that the other overlooks, even though the latter was involved in the design from the very beginning?

But if you think about it more carefully, it becomes clear that the answer is actually quite simple. Neither of them can do anything better or differently than the other. They’re in two completely different roles: that of the author and that of the reviewer.

The author and the reviewer see things differently

Anyone who builds a feature has a goal in mind. Their solution should work and be functionally sound. In doing so, we don’t just tell the developer that it has to work in the end; we also provide functional and technical guidance, tell them what to look out for, and work with them to develop a concept that will then guide the development process. And yet, just like us, they remain completely focused on the intent behind the task. That’s a good thing, but it means they become blind to the gap between what was intended and what actually ends up in the code. It’s a bit like proofreading your own text and still missing a typo because you know what’s supposed to be there.

My agent does know the context, the related ticket, and what the goal was. But he didn’t build it himself, and so he isn’t attached to any particular solution. He reads the code as it actually stands, not as it was intended. On top of that, I’m asking him a different question. My colleague’s agent was supposed to build something. Mine is supposed to find something. That’s a completely different task, and a different task leads to a different perspective.

The question comes from a person

But the most important part is something else: The edge cases don’t come from the agent at all. They come from you.

The agent doesn’t seek out these cases on its own. From my work on the project, I know where things can get tricky; I often have a sense of where extra caution is needed, and I direct the agent exactly there. My colleague’s agent didn’t come up with the idea because my colleague didn’t think to ask. Not because his tool is inferior, but because at that moment he lacked the context from which to even pose that question.

That’s exactly the point. The agent amplifies the question you ask it. It doesn’t replace it. It’s incredibly good at following a lead, but someone has to tell it which lead to follow. And that intuition about where it’s worth looking comes from experience, from knowledge of the domain, and sometimes simply from a gut feeling at the right moment.

Where the Work Lies Today

For us, this means, in practical terms, that our work has shifted. In the past, most of our time was spent actually writing the code. Today, AI writes most of it, and often everything works without any intervention. That’s exactly what makes it dangerous. The real work now lies elsewhere—namely, in that second, independent review to verify that it’s actually correct. That’s why we never have the same agent write and review the code; instead, we always have a second person go over it with their own agent.

This doesn’t mean the dual-review principle has become obsolete—quite the opposite. It’s simply gained new participants: two agents that build and search, and two people who know where to send their agents. Sometimes, a fresh and unbiased perspective on complicated tasks is exactly what’s needed.