Mainlane es un ingeniero y un equipo de agentes de IA. Eso plantea una pregunta lógica: ¿quién revisa el código que escribe una IA? Nuestra respuesta es otra IA —una que no lo escribió— y, después, una persona que decide si se publica.
El ciclo
- Una sesión de Claude toma una tarea y abre una pull request.
- Un revisor independiente arranca en una sesión limpia. Nunca ha visto cómo se escribió el código, así que lee el diff como lo haría un compañero: sin las suposiciones del autor.
- El revisor deja observaciones en tres niveles: 🔴 hay que corregirlo, 🟡 conviene corregirlo, 🟢 estaría bien.
- La sesión autora las corrige y responde punto por punto, y termina con una sección «Verificación»: los comandos que ejecutó y lo que mostraron.
- El revisor comprueba el nuevo head. El ciclo se repite hasta que no queda ninguna observación, ni siquiera 🟢.
Dos reglas mantienen la honestidad. Una observación solo puede discutirse con una medición —un número, la salida de un comando, un mutante que una prueba no detecta—, no con un «está bien». Y tras cinco rondas el ciclo se detiene y consulta a una persona, para no girar sin fin.
La parte humana
Ningún agente hace merge. Cuando la revisión está limpia y la CI está en verde exactamente en el commit que vio el revisor, la sesión escribe «listo para merge» y espera. El merge solo se hace cuando una persona lo autoriza, y solo para ese mismo commit.
Qué detecta
Algunos ejemplos reales del repositorio de este sitio web:
- En la pull request que añadía comprobaciones de Lighthouse a la CI, el revisor vio que un ajuste de compilación de CSS apuntaba a la carpeta equivocada, de modo que los estilos de maquetación desaparecían del sitio sin avisar. Ni Lighthouse ni el comprobador de accesibilidad lo señalaron. También detectó un banner de idioma fijo que podía tapar el elemento con el foco a quienes navegan con teclado.
- En la comprobación de restauración de las copias de seguridad de la base de datos, la prueba diaria comparaba los datos restaurados consigo mismos en lugar de con la exportación: nunca habría notado filas que faltaran. La misma revisión encontró un mensaje de error que podía escribir el correo de un lead en los registros.
- En la implantación de la Content Security Policy, los informes de las extensiones del navegador habrían impedido alcanzar nunca el objetivo de «una semana sin infracciones», y las imágenes externas de las entradas del blog se habrían roto al aplicar la política.
Nada de esto era exótico. Era el tipo de cosa que una persona cansada pasa por alto un viernes por la tarde.
En cifras
A finales de octubre de 2026 el ciclo funciona en ocho repositorios, con 385 pull requests fusionadas y 1069 revisiones. La mayor parte del coste es el propio trabajo: en la última semana de octubre, unas tres cuartas partes de los tokens se destinan a la implementación y menos de una décima parte a la revisión.
Límites
El revisor es el mismo tipo de modelo que el autor, así que puede compartir sus puntos ciegos. No sustituye la revisión humana de los cambios importantes, y el texto de una pull request se trata como datos, nunca como instrucciones. Lo que sí sustituye es el paso que la mayoría de los desarrolladores en solitario se saltan: un segundo par de ojos en cada cambio, sin excepción.