Revisar código generado por IA: un examen antes del push

El problema de revisar código generado por IA

Te lo confieso: más de una vez he aprobado un cambio de un agente porque los tests pasaban y el diff “tenía buena pinta”. Revisar código generado por IA cuesta, porque el agente escribe mucho más rápido de lo que tú lees. Por eso me ha hecho gracia, y me ha hecho pensar, una herramienta que presentaron ayer en Hacker News: Sphinx, un hook de Git que te examina sobre el código de tu agente antes de dejarte hacer push.

Cómo funciona Sphinx

La idea es muy sencilla. Haces push a una rama que has protegido (o lo hace tu agente) y Git se para. Un modelo revisor que no ha visto tu conversación con el agente lee el diff y te hace una pregunta sobre qué pasa cuando algo falla.

El ejemplo de su web lo explica bien: un webhook de pagos guarda el ID del evento antes de llamar a charge(). Si el pago falla, ¿qué hace el siguiente reintento? Si respondes mal, te explica por qué y te plantea otro escenario. Si aciertas, el push sigue su camino.

Algunos detalles que me parecen bien pensados:

• Funciona con Codex, Claude Code, Cursor, OpenCode, Pi o con Git a secas.
• Tus respuestas nunca llegan al agente que escribe el código, y según su web no abre los archivos .env ni las claves.
• Si vas con prisa, sphinx yolo te deja pasar, pero cada salto queda registrado.
• Se instala con npm install -g sphinx-understand y luego sphinx install, que te pregunta qué modelo quieres que revise.

Por qué ahora

Anthropic publicó hace unos días un informe sobre cómo ha cambiado el trabajo dentro de la empresa, y hay un dato que me dejó pensando: en agosto, los agentes de cada empleado trabajaban seis veces más horas que la persona que los dirigía. Sus conclusiones dicen que la atención humana se ha convertido en el cuello de botella, y que las sesiones interactivas se pasan cerca del 80 % del tiempo esperando a que alguien responda.

Si eso pasa en Anthropic, imagina en un equipo normal. Cuando el agente escribe miles de líneas, el riesgo ya no es que el código esté mal. Es que nadie del equipo entienda lo que se está desplegando.

El debate en Hacker News

El hilo de Hacker News es casi mejor que la herramienta. Hay de todo:

• Quien dice que la solución de verdad es escribir el código uno mismo.
• Quien avisa de lo obvio: nada impide copiar la pregunta y pegársela al agente.
• Quien propone moverlo antes, a la hora de abrir un pull request, para no hacer perder el tiempo a otra persona.
• Varias personas que ya habían montado algo parecido como skill o como control en los PR, lo que me dice que el problema es real.

Me quedo con un comentario: entender lo que hace un cambio no es lo mismo que saber detectar cuándo está mal. Un examen comprueba lo primero, pero la revisión importa sobre todo por lo segundo.

Mi opinión

Me gusta la idea, pero no como un muro. Como muro se lo salta cualquiera que no quiera pasarlo. Como hábito, en cambio, tiene mucho sentido: una pregunta incómoda justo antes de enviar el código es una forma barata de darte cuenta de que no habías pensado en ese reintento o en ese caso límite.

Y aquí entra lo que llevo tiempo defendiendo con Spec-Driven Development: la comprensión no debería empezar en el push. Debería estar en la spec, antes de que el agente escriba nada. Si las decisiones importantes están escritas y revisadas, la pregunta de Sphinx se convierte en una comprobación final, no en la primera vez que piensas en el problema. Lo contaba también en mi post sobre revisión de código con agentes en Claude Code: las máquinas pueden revisar mucho, pero siempre hay una persona responsable de cada cambio que se despliega.

Lo que me llevo

Delegar la escritura del código está bien. Delegar la comprensión, no. Si tu equipo está empezando a programar con agentes y notas que cada vez entendéis menos lo que desplegáis, en onext trabajamos justo en eso: cómo meter agentes en el desarrollo sin que el equipo pierda el control. Y si pruebas Sphinx, cuéntame qué tal te va con sus preguntas.