One reviewer, one axis

alex.leksat@gmail.com (Alex Tkachev) — Sun, 25 Oct 2026 00:00:00 GMT

When a coding agent says a task is done, it isn't done yet. Ask another agent to review the changes, and it finds a bunch of issues right away. After one or two such rounds, the code is worth my own review. Before that, there's no point in looking at it.

These reviews are part of doing the task: all of it happens before anyone else sees the work.

I tried several review skills, and each of them is good in its own way

thermo-nuclear-code-quality-review by Cursor: an extremely strict maintainability review.
code-review by Matt Pocock: two parallel agents: one checks the repo's coding standards, the other the spec.
My own blind-review: an agent gets only a path, figures out the purpose of the code by itself and looks for issues with no directions.

But they are universal, and my tasks aren't. What actually works for me boils down to three rules:

Each reviewer is a separate agent, given as little information as possible, so the main agent can't infect it with its own view of the task.
It gets a single axis, picked for the task.
It's read-only: it reports, and what to do with the report is up to the main agent and/or me.

Some axes I've used:

Regressions

I was moving a TypeScript project to strict mode: a refactoring under tighter typing. The reviewer prompt was roughly "Look at the current changes in this project and check them for regressions". No other hints.

The old bugs it ran into became TODOs, and a second reviewer checked them

Whatever axis I give a reviewer, it always notices bugs along the way. We fixed regressions right away, but the reviewer also found old bugs that were already in the project. We couldn't just ignore them, and fixing them in a refactoring task was not an option, so we left TODO comments describing them.

Those comments were a byproduct: the regression reviewer wasn't focused on these bugs and described them sloppily. So a second reviewer checked only the new TODO comments: how accurately each one describes its bug.

Repo style

On a patch for an open source project, matching its code style mattered a lot. Some repos have style guides, but practice beats any of them: the reviewer compares our changes with previous commits.

Simpler solutions, with and without context

After a session where the agent grilled me on the design and we made some decisions, I ran two agents in parallel on the same diff with one question: can the same thing be done simpler? One was told the decisions, the other wasn't. Both came back with something interesting.

The informed one judged the code within the design. Its findings were targeted: less code, fewer moving parts, a real bug.

The blind one judged the design itself. It kept proposing options we had already turned down, and the main agent filtered those out. But its ideas also changed the design: a couple of times they made me revise decisions from the grilling.

Reliability

A monitoring system, for example, must always work, under any conditions. A separate reviewer checks that the code never falls over with an uncaught error.

Not just how convenient it is to click around. When we add new error messages, a separate agent looks at nothing but them: how useful they are, and whether the user understands what to do next.

Plus the classics: security, maintainability, etc.

The main agent writes the reviewer prompts at my request, but I never leave the agents to their own devices. As soon as the reviewers start, I skim their prompts. If one is off, I cancel it and ask for a rewrite. Or I keep it as is and run another one next to it, written my way: one more axis. That's how the two simplicity reviewers, with and without context, came about.

I can also read the full reports

A reviewer hands its report to the main agent, and Claude Code doesn't show it to me as is, only the main agent's take on it. So I have a hook that saves every subagent's prompt and report to /tmp. I don't read them all the time, but now and then I look.

Who decides on a report changes from case to case. Sometimes the main agent summarizes the findings for me, and I decide. Sometimes, like in a big refactoring with frequent reruns, it decides by itself. The number of rounds differs too.

My practice comes down to this: every task needs its own workflow and its own set of focused reviewers. That's why universal review skills didn't work for me.

I'm still experimenting. Maybe I'll come up with a dozen more reviewers. Maybe the list never ends.

Recursion

This post went through the same process. I had doubts about the last lines, so a reviewer got a single question: does the ending work? It said yes, and showed what to tighten.

One reviewer, one axis 😁

Out of the team chat

alex.leksat@gmail.com (Alex Tkachev) — Sat, 24 Oct 2026 00:00:00 GMT

I found myself sharing tips and tricks with my colleagues. Now I'm sharing them with everyone.

It's about AI, of course: my main tool these days. Currently I'm on Claude Code, but the ideas are usually general and apply to any coding agent.

My first posts will be about my coding agent setup: user instructions, skills, hooks, config. I'll keep them short and to the point.

Mostly, though, this blog is practice for me: putting thoughts into words, and doing it every week. Finding a new topic each time will be the hardest part. A good challenge.

Wish me luck 🤞

Leksat

One reviewer, one axis

Out of the team chat