Un ingeniero de Google se registró en Surmado Code Review la semana pasada. El producto corre sobre Scout, nuestro AI research analyst. Escribió un archivo STANDARDS.md para su proyecto, abrió su primer pull request y le pasó Scout.
Scout marcó una falla arquitectónica crítica que habría tumbado producción.
No hizo merge. Nos escribió un correo describiendo su flujo de trabajo:
“Tomo el feedback de Surmado y lo copio en Gemini. Gemini se autoflagela y luego me da un nuevo prompt para usar con Gemini Code Assist en mi IDE. Code Assist hace los cambios. Actualizo la rama y Surmado vuelve a revisar la nueva versión automáticamente. Y solo cuando agoto el ciclo, recién ahí etiqueto a mis colaboradores para que revisen.”
Léelo de nuevo. Hay un ciclo ahí que vale la pena nombrar.
El ciclo
- Gemini Code Assist escribe el código en su IDE.
- Surmado lo revisa contra su
STANDARDS.md. - Pega la revisión de Surmado en el chat de Gemini.
- Gemini lee el veredicto de Surmado y se reescribe el prompt a sí mismo.
- Code Assist regenera el código con el nuevo prompt.
- Sube la nueva rama. Surmado vuelve a revisar automáticamente.
- Cuando agota el ciclo, etiqueta a sus colaboradores humanos.
El último paso es el que más nos quedó dando vueltas. El ciclo no reemplaza la revisión humana. Hace que la revisión humana entre en juego solo cuando realmente hace falta. Para cuando una persona mira el PR, lo obvio ya está arreglado. Las fallas de arquitectura, las violaciones de estándares, las cosas que un lector cuidadoso atraparía un martes cansado por la tarde. Ya no están. Al revisor humano le quedan las partes que sí necesitan a un humano: tradeoffs de diseño, intención, criterio.
Esa es la versión de la IA en el flujo de desarrollo que de verdad funciona. No es “la IA reemplaza a los humanos”. La IA se ocupa de la parte que converge. Los humanos se ocupan de la parte que decide.
Lo que dijo Gemini
El ingeniero pegó la revisión de Surmado en Gemini dos veces durante la sesión. Las dos veces, Gemini estuvo de acuerdo con Surmado al instante.
La primera respuesta:
“Surmado acaba de atrapar una falla arquitectónica crítica que habría tumbado tu sitio en producción, y la marcó citando directamente el archivo
STANDARDS.mdque escribimos hace 20 minutos. Definitivamente no deberías hacer merge de este PR todavía. Esto es exactamente lo que pasó y por qué Surmado tiene toda la razón.”
La segunda:
“Surmado encontró un hueco en nuestra ejecución y, sinceramente, la pifié con el prompt que te di para Code Assist.”
Esa segunda cita es la que más nos quedó dando vueltas. Gemini no le echó la culpa al modelo. Gemini le echó la culpa al prompt. Las instrucciones que Gemini le dio a Code Assist no incluían las convenciones del equipo, porque Gemini no sabía cuáles eran las convenciones del equipo.
Surmado sí sabía, porque el ingeniero las había escrito veinte minutos antes. STANDARDS.md es el puente entre lo que el equipo valora y lo que el modelo puede ejecutar.
Por qué este es el producto
La mayoría de las herramientas de revisión de código con IA chequean buenas prácticas genéricas. Indenta tu código. No hagas shadowing de variables. Evita números mágicos.
Eso es lo mínimo. Cualquier linter lo hace. La razón por la que los equipos siguen haciendo merge de código malo es que los bugs que duelen en producción no son genéricos. Son específicos a cómo construye el equipo. Son las cosas que están en tu wiki, tus documentos de diseño, las convenciones que viven en la cabeza de tres ingenieros senior.
STANDARDS.md es donde pones eso. Scout lo lee. Cada PR se revisa contra ese archivo. Cada nueva ejecución lee el nuevo diff y la revisión anterior, así Scout puede ver si los problemas previos quedaron resueltos.
El ciclo del ingeniero funciona porque cada pieza hace lo que sabe hacer. Gemini escribe código. Surmado lo chequea contra las reglas del equipo. Gemini se autocorrige cuando recibe feedback externo. Los humanos revisan lo que queda. La integridad viene del ciclo, no de un solo modelo.
Cómo se siente en la práctica
Así describió sus intentos previos con proyectos web:
“Me emocionaba con las filas de código que se generaban y después esperaba, lleno de expectativa, a que mi creación cobrara vida. Solo para decepcionarme mucho cuando inevitablemente se rompía.”
Cualquiera que haya intentado vibe-codear un proyecto real conoce ese arco. La emoción. La expectativa. El choque.
Después esto:
“Esta noche no. Hice merge de PRs que lograron exactamente lo que me había propuesto.”
Esa es la diferencia. No es “la IA escribió código”. Ni “la IA revisó código”. Un ciclo que converge a software que funciona, con un checkpoint humano al final cuando hace falta.
El encuadre que nos gusta
La mayoría de las herramientas de IA se posicionan contra los humanos. “Más rápido que un revisor humano.” “Atrapa cosas que los humanos pasan por alto.”
Surmado se posiciona entre IAs. No más rápido que Gemini. No más inteligente que Claude. El modelo que escribió el código no sabe lo que el equipo valora. El modelo que lo revisó sí, porque alguien lo escribió.
Así se ve un producto de orquestación. El LLM no es el producto. La forma en que el LLM se conecta con las reglas reales de tu equipo es el producto.
El ingeniero lo resumió en su último mensaje: “Muy impresionado. Y está perfectamente integrado en el flujo.”
Eso es lo que estamos construyendo.
Dos clics. Y ya funciona. $15 al mes por 100 PRs. Nunca miramos tu código. Los frontier labs que usamos tampoco.