The Review Paradox

On the review paradox

Every Thursday our company holds an AI meetup, and at a recent one, one of our AI engineers shared a passage he'd read in a blog post by Tom Wojcik:

"Developers who fully delegated to AI finished tasks fastest but scored worst on evaluations. The novices who benefit most from AI productivity are exactly the ones who need debugging skills to supervise it, and AI erodes those skills first." Tom Wojcik, tomwojcik.com

He called this the "review paradox." The more AI writes, the less qualified you become to review it. And the two can't be separated. You don't develop an eye for good work by reading about good work. You develop it by doing the work clumsily yourself, getting torn apart by people more senior than you, and building a feel for it through years of real practice.

This topic has been hotly debated in developer communities lately. But I want to talk about everyone else: office workers and people in non-engineering roles.

Here's how I see it. Once AI starts doing most of the actual execution, what's left for us is reviewing, managing, planning, and strategy. That sounds great. But think about how we learned those things in the first place. We learned them by doing the grunt work ourselves. We learned by getting chewed out by our bosses at previous jobs. We learned by making mistakes and being corrected. The judgment to review a piece of work comes from having done that work hundreds of times yourself.

Now take that away. AI does the execution, and I only review the output. But I don't have the muscle to judge what good output looks like. And the scariest part is that you never notice you're getting duller.

There's an interesting trend here. In developer communities, people have actually started working on this problem. The core principle is: don't review the code, review the spec and the architecture.

Here's what that means. Before any code gets written, you write a proper spec. You define the problem clearly, understand the tradeoffs, translate business language into product requirements, and translate product requirements into technical architecture. A person reads and reviews the spec, the architecture, and the verification plan, so they genuinely understand what's being built and why. Then AI writes the code and checks whether the code follows the spec. Checking for compliance is something AI is good at. Judging whether the spec itself is right is a job for a person.

Some teams are making this mandatory. They actually enforce it. Honestly, if you don't enforce it, nobody does it. Everyone just vibes along with AI and ships whatever comes out.

You could fairly ask why anyone should bother. If AI does the work and the code runs fine, what does a person need to understand?

If you don't understand it, you get a little duller every day without realizing it. But if you step in properly at the level of spec and architecture, the situation actually gets better, because you end up spending your time on the parts that matter most instead of on mechanical execution.

There's a line that sums this up perfectly:

"Software engineering was never just about typing code. It's defining the problem well, understanding the problem, translating the language from business to product to code, clarifying ambiguity, making tradeoffs, understanding what breaks when you change something."

You can swap "software engineering" for any kind of knowledge work and it still holds.

One more thing I discovered recently. Claude has a setting called "Learning." Instead of handing you the answer right away, it actually teaches you through back-and-forth questions. A few months ago I would have looked at that and thought, "Don't ask me, just do it." Now it makes complete sense to me. If the point is to keep building judgment and understanding, simply swallowing answers is the worst possible approach.

That's actually close to why I've always written on Brunch (a Korean blogging platform). It was less about sharing with others and more about understanding things deeply myself. To write about something, you have to understand it fairly well. I've always felt there's a lot I don't know and an enormous amount I still need to learn, so writing about situations and topics that inspired me has been my own way of learning. In the AI era, AI can churn out blog posts. I think that's probably why I still write these by hand (with Claude's help, of course). Nobody asked me to. It's just my way of building my own review muscle.

So I want to put a question to you. In AI-driven work today, which approach is right?

A. People should review the quality of code and documents themselves.

B. AI checks whether the work complies with the spec and architecture, and people review the spec and architecture.

C. AI only writes code and documents, and is never used for verification.

D. Skip things like specs. Shipping fast is what matters.

And going forward, how can we build our ability to learn in the AI era? Especially as the old setup, where a senior colleague or coworker sat next to you, tore your work apart, and coached you, slowly disappears?

Originally published in Korean on Brunch, March 20, 2026.