Another radical change in time and energy use during development is that, besides planning, I spend much more time doing code review, both automated and manual.

Having good code review infrastructure is extremely necessary when working with code agents, because no matter how good the context you provide, how explicit your project rules are, models are probabilistic, and often they don't do what you ask, and sometimes they straight up break everything.

By doing Code Review you can ensure that at least a subset of possible model deviations are avoided, and that you can validate that the preconditions you set for your project are being met.

Automated Code Review

As soon as Claude Code finishes implementing something, unless it's a very simple script or something one-shot, I run a swarm of code review agents.

The flow is:

1. Using the /code-review command, multiple specialized agents generate review documents (markdowns in the project root, all starting with CODE_REVIEW_*.md and in .gitignore). Each one reviews different things: performance, security, style, architecture, etc.
2. An orchestrator summarizes all comments into CODE_REVIEW.md.
3. Here I usually review at minimum the summary to see what kind of errors came up.
4. If there are many errors or I have doubts, with /validate-code-review, I run a set of agents that corroborate whether the comments are valid (sometimes review agents have false positives).
5. This generates a final review document containing the valid errors and comments.

I review that document again, and reference it in Claude Code with @CODE_REVIEW.md, along with instructions about what to fix and what not to. Sometimes I just delete the things I don't want to change and simply reference the document.

You can see examples of the code review agents in the Claude Code plugin I use for my games.

Manual Code Review

Manual review is done on a "final" PR in GitHub, after the automated review has done its job.

I use GitHub's review tools to create comments and change suggestions in the code. When I finish, the comments stay in the PR and I tell Claude Code to review the code review comments.

With the gh command it gets all the info and can start fixing whatever I asked for in the GitHub interface.

Pre-commit Hooks

Before creating the PR, when committing, I run all the scripts that will run in CI: build, tests, lint, etc. This allows Claude to fix them automatically before pushing the code and keeps each commit 'cleaner'.

An important note: at the time of writing this, Claude Code is very lazy and when things get complicated it wants to use --no-verify to push without validation. I try to prevent it but sometimes it slips through.

The good thing is that CI catches that. When it happens, I tell it to review the CI errors.

The main reason for doing this is that we use fewer GitHub Actions minutes and on top of that iteration is faster. Pre-commit hooks run locally and are instant. CI remains as a backup in case something slips through, if I run out of GitHub Actions minutes, or if it's down or something.

What's Next

MCP (Model Context Protocol) servers and CLIs (Command Line Interfaces) allow Claude Code to connect with databases, APIs, external services, and tools that don't come built-in.

In the next post I'll cover how I use MCPs and CLIs to extend Claude Code's capabilities and connect it with the tools I use daily.