{"id":88,"date":"2026-08-03T08:00:29","date_gmt":"2026-08-03T08:00:29","guid":{"rendered":"https:\/\/www.dobryakov.net\/blog\/88\/"},"modified":"2026-08-03T08:00:29","modified_gmt":"2026-08-03T08:00:29","slug":"code-review-theater","status":"publish","type":"post","link":"https:\/\/www.dobryakov.net\/blog\/88\/","title":{"rendered":"The Employment Theater of AI Code Review"},"content":{"rendered":"

3 AM. A senior developer stares at the monitor, eyes red. On screen: a massive diff. The AI generated five hundred lines of code in three seconds. Now our hero is spending half an hour reading every single line \u2014 checking brackets, variable names, indentation. In their head: "This is real engineering work."<\/p>\n

From the outside \u2014 surrealist tragicomedy: the AI spent a moment, the human spent thirty minutes reading the output. Meanwhile, this same developer refused to spend five minutes before<\/em> running the model to write clear acceptance criteria, boundary conditions, and an automated test that would verify the code in milliseconds.<\/p>\n

The pattern is everywhere.<\/p>\n

<\/p>\n

The paradox<\/h2>\n

Smart, experienced engineers choose slow, ineffective micromanagement of machine output over effective goal-setting. Organizations deploy AI tools expecting a 10x productivity gain. What they get is a developer who became a human linter for the neural network.<\/p>\n

The gap is real. One case: a founder with deep domain expertise in warehouse logistics rewrote a 10-year codebase alone. Six months later \u2014 zero system outages, 10\u201315 deploys per day during business hours, a two-week team sprint closing in 10\u201330 minutes.<\/p>\n

The key: they knew exactly how to specify tasks. Deep domain knowledge meant requirements could be written precisely enough that the agent delivered the right result on the first pass.<\/p>\n

Did they then read the generated code line by line? No. They built criteria and verification systems.<\/p>\n

The developer who sets tasks precisely is a different role entirely from the developer who reviews agent output.<\/p>\n

Root cause one: employment theater<\/h2>\n

For decades, professional value in engineering was measured by physical actions \u2014 keystrokes, file scanning in the IDE, catching typos, strict PR reviews.<\/p>\n

When an engineer furrows their brow and stares at code, they send a signal to the room and \u2014 more importantly \u2014 to themselves: "I'm doing hard intellectual work. I'm producing. I'm valuable."<\/p>\n

Criteria look like nothing. You can spend half an hour staring out the window, thinking through non-functional requirements, failure scenarios, data validation rules. From the outside \u2014 and in the developer's own internal monologue \u2014 this looks like doing nothing. The guilt creeps in: why am I being paid if I haven't opened the editor?<\/em><\/p>\n

Reading code becomes a safe harbor. A perfect simulation of busy-ness that protects against the fear of being caught "not working." This is employment theater \u2014 visible activity replacing invisible but real work.<\/p>\n

Root cause two: identity crisis<\/h2>\n

There's a deeper layer.<\/p>\n

Engineering culture spent years building a cult of the craftsman. Developers grew accustomed to seeing themselves as the only real creators \u2014 while the people who write specs, gather requirements, and formalize acceptance criteria (the PMs, the analysts) were second-tier support staff. The jokes about "useless managers who just move Jira cards" were standard locker-room material.<\/p>\n

Then the AI era arrived. Someone told the developer: "Look \u2014 writing basic code is now a machine function. Your new role is to decompose problems precisely, define interaction contracts, write success criteria, and validate results."<\/p>\n

At that moment, something short-circuits.<\/p>\n

Accepting this role means acknowledging that you now need to do exactly the work you've been dismissing your entire career. The engineering ego resists: "I'm a creator. I write code. I'm not writing specs for a machine \u2014 I'll just read through what it generated, line by line."<\/p>\n

This is identity defense, not a rational choice.<\/p>\n

The trap<\/h2>\n

Reviewing AI-generated code by eye is an illusion of control \u2014 and not just slow.<\/p>\n

The human brain reliably misses subtle architectural bugs and memory leaks in beautifully formatted AI output. What sets in is a trust hallucination: it looks clean, it must work<\/em>. AI-generated code often reads better than human-written code \u2014 consistent formatting, conventional naming, no personal quirks in structure. The brain reads "clean" as "correct." That's the mechanism of the trap.<\/p>\n

The result: the developer ends up in the worst of all worlds.<\/p>\n