Otro cambio radical en el uso de tiempo y energía durante el desarrollo es que, además del planning, paso mucho más tiempo haciendo code review, tanto automatizado como manual.

Tener buena infraestructura de code review es extremadamente necesario cuando uno trabaja con agentes de código, porque por más que uno de el mejor contexto del mundo, tenga las reglas del proyecto híper explícitas y todo, los modelos son probabilísticos, y muchas veces no hacen lo que uno les pide, y a veces directamente rompen todo.

Haciendo Code Review uno puede asegurarse de que al menos se evite un subconjunto de las posibles desviaciones que puede tener un modelo, y que podamos validar que se cumplen las precondiciones que pusimos en nuestro proyecto.

Code Review Automatizado

Apenas Claude Code termina de implementar algo, a menos que sea un script muy simple o algo oneshot, corro un swarm de agentes de code review.

El flujo es así:

1. Usando el comand /code-review, múltiples agentes especializados generan documentos de review (markdowns en el root del proyecto, todos empiezan con CODE_REVIEW_*.md y están en .gitignore). Cada uno revisa cosas distintas: performance, seguridad, estilo, arquitectura, etc.
2. Un orquestrador resume todos los comentarios en CODE_REVIEW.md.
3. Acá suelo revisar como mínimo el resumen para ver qué tipo de errores surgieron.
4. Si hay muchos errores o tengo mis dudas, con /validate-code-review, corro un set de agentes que corroboran que los comentarios son válidos (a veces los agentes de review tienen falsos positivos).
5. Esto genera un documento final de review que contiene los errores y comentarios válidos.

Ese documento lo reviso nuevamente, y lo referencio en Claude Code con @CODE_REVIEW.md, junto con instrucciones sobre qué arreglar y qué no. A veces directamente borro las cosas que no quiero cambiar y simplemente referencio el documento.

Podés ver ejemplos de los agentes de code review en el plugin de Claude Code que uso para mis juegos.

Code Review Manual

El review manual es sobre un PR "final" en GitHub, ya después de que el automatizado hizo lo suyo.

Uso las herramientas de review de GitHub para crear comentarios y sugerencias de cambios en el código. Cuando termino, los comentarios quedan en el PR y le digo a Claude Code que revise los comentarios del code review.

Con el comando gh obtiene toda la info y puede empezar a arreglar lo que sea que le haya pedido en la interfaz de GitHub.

Pre-commit Hooks

Antes de crear el PR, cuando se hace commit, corro todos los scripts que se van a correr en CI: build, tests, lint, etc. Esto permite que Claude los arregle automáticamente antes de subir el código y que cada commit esté más 'limpio'.

Una nota importante: al momento de escribir esto, Claude Code es muy vago y cuando se le complica quiere usar --no-verify para subir sin validar. Yo intento que no lo haga pero a veces se me escapa.

Lo bueno es que CI detecta eso. Cuando pasa, le digo que revise los errores en CI.

La razón principal para hacer esto es que así usamos menos minutos de GitHub Actions y encima la iteración es más rápida. Los pre-commit hooks corren localmente y son instantáneos. CI queda como respaldo por si algo se escapa, si me quedo sin minutos de GitHub Actions o si está caído o algo.

Lo que viene

Los servidores MCP (Model Context Protocol) y CLI (Command Line Interfaces) permiten que Claude Code se conecte con bases de datos, APIs, servicios externos y herramientas que no vienen incluidas de fábrica.

En el próximo post voy a contar cómo uso MCPs y CLIs para extender las capacidades de Claude Code y conectarlo con las herramientas que uso día a día.