The post (its title translates roughly as “AI’s implementation quality was mediocre and I had to point things out every time, so I made it raise the quality automatically before I check”) describes a personal workflow for Claude Code. The author reports that although Claude Code could implement changes in one go, the resulting code often fell short of the author’s own standards, even when the design had been worked out beforehand in plan mode, so every change ended up needing the author’s own comments.

The author’s first attempt — having a subagent or Codex CLI review the code and fix everything before checking it — ran into a different problem: AI review findings include off-target and excessive ones, and having all of them addressed sometimes left the code messier. The fix the author adopted, credited to an article by another developer, kawarimidoll, was to have the AI judge whether each finding is appropriate before acting on it. The result is a /self-review slash command that chains a parallel review with a critical evaluation step, which the author reports running after almost every implementation, before reading the code.

Key Points

  • /self-review launches three reviewer agents in parallel: a general reviewer covering quality, security and performance; a codex-reviewer that uses Codex CLI’s codex review command, valued by the author for giving the perspective of a model other than Claude; and a simplify-reviewer focused on readability, consistency and maintainability, aimed at the over-abstraction and unnecessary complexity the author associates with AI-generated code.
  • The general reviewer is based on the reviewer agent in kawarimidoll’s article, and the simplify-reviewer on Anthropic’s official code-simplifier agent.
  • Overlapping findings between the three reviewers are not treated as a problem: when several reviewers flag the same place, the author reads that as a sign the finding has higher priority.
  • After all reviews finish, a /fix-review-comments skill evaluates each finding critically — asking whether it really needs fixing — fixes only the ones it judges valid, and gives a reason for each one it declines. This step is the one the author identifies as the key to the setup, and it too is modelled on a command from kawarimidoll’s configuration.
  • In the example session shown, the three reviewers raised ten findings in total, of which six were addressed and four declined; the addressed ones appear as five items because one covers a point two reviewers shared. Each declined finding carries a reason such as “intentionally designed that way in the requirements” or “already covered by the existing text”. The author says this project-aware selection is what makes it possible to leave the fixes to run automatically.
  • The claimed outcome is that the quality of the code is raised to some extent before the author reads it; this rests on the author’s own experience, and the post reports no measurement.

Context

The post is a single developer’s firsthand account of a personal configuration, published in a public repository of configuration files. It sits alongside other writing on AI reviewing AI-generated code before a human does (see also Critical Dialogue Review). The distinguishing idea here — critically triaging review findings before fixing them rather than applying all of them — is described on Review Finding Triage.