El problema
Somos un equipo pequeño. Cinco personas construyendo una plataforma de IA. En cualquier momento tenemos 14 repositorios activos. Eso significa muchos PRs y no suficientes humanos para revisarlos bien.
Las revisiones estaban tardando demasiado. Se pasaban por alto cosas importantes. Estábamos entregando código más rápido de lo que podíamos verificar.
Así que construimos nuestro propio bot de revisión de código. Empezó como un proyecto paralelo para resolver un problema interno. Ahora es un producto. Surmado Code Review. $15 al mes por 100 PRs.
Así lo construimos. Qué partes fueron vibe-coded, cuáles no, y el framework que recomendamos para prototipar cualquier pipeline de IA.
Fase 1: Inicio con vibe coding
La primera versión era un agente de resumen. Nada más. Abrías un PR y obtenías un resumen en lenguaje natural de los cambios. Lo hicimos completamente con vibe coding. Rápido, improvisado, con Claude haciendo el trabajo pesado.
Después empezamos a preguntarnos: ¿también puede detectar bugs?
Ahí se puso interesante.
Fase 2: El paso forward-backward
Esta es la parte que creemos que de verdad vale la pena compartir. Es un framework que puedes usar para cualquier pipeline de IA, no solo revisión de código.
Tomamos un concepto del entrenamiento en ML: el forward-backward pass. Pero en lugar de entrenar los pesos de un modelo, tratamos todo el pipeline como si fuera un LLM.
Así funciona.
Forward pass. Defines un conjunto de inputs controlados. En nuestro caso, PRs con bugs que plantamos deliberadamente. Los ejecutas en el pipeline y registras qué detecta y qué se le escapa.
Backward pass. Analizas lo que se escapó. Ajustas prompts, estructura, lógica de revisión. Luego ejecutas de nuevo. ¿Esta vez detectó el bug? ¿Aumentaron los falsos positivos?
Repites. Cada ciclo es rápido y barato. No estás reentrenando un modelo. Estás iterando sobre código, prompts y arquitectura con señal inmediata de si funcionó.
La idea clave: conviertes a Claude Code en un usuario sintético. Le das un input esperado y un output esperado. Dejas que genere casos de prueba adicionales y evalúe los resultados contra tu pipeline. Eso es tu test harness.
Los test harnesses son fáciles de hacer con vibe coding. Si tienes un API activo, puedes montar uno en una tarde. Algo desplegado, en contenedor o corriendo localmente basta. Defines los tipos de bugs que quieres que tu pipeline detecte, generas casos, los ejecutas e iteras.
Eso fue nuestro v1 y v2. Teníamos 10 teorías distintas sobre cómo estructurar la lógica de revisión. En vez de debatirlas, pasábamos las 10 por el harness y dejábamos que los resultados decidieran.
Fase 3: Donde el vibe coding toca techo
Después de toda esa experimentación, encontramos el verdadero desbloqueo: el grounding en estándares.
El agente de revisión mejoró drásticamente cuando tenía un documento de estándares bien escrito contra el cual referenciar. Las convenciones reales de codificación del equipo y sus decisiones arquitectónicas.
Si haces vibe coding, probablemente ya tienes un CLAUDE.md o .cursorrules. Eso es un contrato de escritura. Le dice al agente qué producir. Pero la mayoría de los equipos no tiene un contrato de revisión. No hay un archivo equivalente que le diga a nadie, humano o máquina, qué es aceptable para hacer merge. Esa asimetría es de donde viene el drift.
Escribimos un STANDARDS.md por repo. Una vez que ese archivo existió, el agente de revisión tenía algo concreto contra lo cual chequear. No mejores prácticas genéricas. Nuestras opiniones concretas sobre cómo construimos.
Pero hay algo importante. El documento de estándares en sí no podía ser vibe-coded. Cómo estaba formateado, cómo se integraba al pipeline, el lenguaje y la estructura. Todo eso requirió criterio humano. Lo escribimos, lo revisamos, probamos cómo lo interpretaba el agente, y lo volvimos a revisar. Ese loop lo manejó un humano.
La productización fue totalmente a mano. Cada parte.
Autenticación y pagos. Conectados de forma deliberada. Nos importa proteger el dinero del cliente.
Estados de fallo y reembolsos. Diseñados a mano. Cuando algo sale mal, necesitamos saber exactamente qué pasa y por qué.
Privacidad. Innegociable. El código del cliente pasa por nuestro pipeline. Eso exige arquitectura deliberada, no código generado.
Integración con Scout. Scout es nuestro analista de investigación con IA. El cableado entre Surmado Code Review y Scout fue cuidadoso, probado e intencional.
También invertimos tiempo en el peso de los modelos dentro del pipeline. Ser deliberados sobre qué modelo maneja qué, balanceando costo y calidad. Esa clase de decisiones no se presta al vibe coding. Requiere entender tus márgenes, las expectativas de tus clientes y los modos de fallo de cada nivel de modelo.
Nada de eso lo delegamos en la máquina.
Fase 4: Revisión humana y pulido
Después del prototipo con vibe coding y del loop de testing agentic que nos dejó con una base sólida, el resto fue mucho trabajo humano de revisión. Leer outputs. Compararlos con lo que realmente marcaría un ingeniero senior. Ajustar el documento de estándares. Matar falsos positivos.
Lo dogfooded en los 14 repos internos. Para cuando lanzamos la v7, había pasado por miles de PRs reales sobre código que nos importaba.
El resultado: 3× mejora en tiempo hasta merge en esos repos. Los PRs dejaron de quedarse esperando. Los ingenieros senior dejaron de cazar las mismas cinco cosas en cada revisión. Los juniors dejaron de adivinar convenciones. Los PRs generados por agentes dejaron de derivar hacia formas que nadie del equipo habría escrito.
Mi equipo de desarrollo me obligó a lanzarlo. Estaban cansados de decirle a amigos fundadores que no, que no podían tenerlo, que era interno. Así que lo convertimos en producto.
El framework (tómalo)
Si estás construyendo cualquier pipeline de IA, de revisión de código o de lo que sea, este es el patrón.
1. Prototipa con vibe coding. Haz que el flujo básico funcione. No pienses demasiado la arquitectura. Deja que la IA arme el andamiaje.
2. Construye un test harness agentic. Define tus inputs y outputs esperados. Deja que Claude Code actúe como un usuario sintético. Este es el paso forward-backward. Es rápido de armar si tienes un API al que llamar, y te permite probar 10 ideas en el tiempo que te tomaría evaluar una manualmente.
3. Deja que los datos elijan a los ganadores. No debatas qué enfoque es mejor. Pásalos todos por el harness. La señal es inmediata.
4. Encuentra el mecanismo de grounding. Para nosotros fue un documento de estándares. Para ti podría ser una guía de estilo, una rúbrica, un conjunto de reglas o un dataset de referencia. La cosa que hace tu pipeline consistente y con opinión. Ese es tu verdadero diferenciador, y casi seguro requiere trabajo humano.
5. Construye a mano lo que protege al cliente. Auth, pagos, privacidad, estados de fallo. Esto no es territorio de vibe coding. Esto es lo que gana confianza. Hazlo de forma deliberada.
La conclusión honesta
El vibe coding es un framework fenomenal de prototipado y experimentación. El loop de testing agentic, el patrón forward-backward, nos permitió movernos más rápido en desarrollo temprano de lo que nunca habríamos podido. Pasamos de “¿y si construimos un bot de revisión de código?” a un prototipo funcionando que atrapaba bugs reales en cuestión de días.
Pero las cosas que hacen que un producto sea confiable requirieron humanos tomando decisiones deliberadas con contexto completo. El grounding en estándares. La selección de modelos. Los flujos de pago. La arquitectura de privacidad.
Prototipa y experimenta con vibe coding. Construye a mano lo que protege al cliente. Esa es la línea. Creemos que es la correcta.
Pruébalo en tus repos
Surmado Code Review. $15/mes por 100 PRs. Construido por un equipo de cinco personas. Dogfooded en 14 repos.
Ver cómo funciona Surmado Code Review o empezar una revisión en tu próximo PR.
Lecturas relacionadas: