Cómo detectar errores en el código generado por IA antes de que lleguen a producción

Un asistente de IA puede producir una funcionalidad que parece funcionar en segundos. Lo difícil ya no es generar el código: es saber si puedes confiar en él. Los modelos de IA se muestran seguros incluso cuando se equivocan, alucinan APIs que no existen y "arreglan" tan tranquilos una prueba que falla borrando la aserción. Si despliegas todo lo que el agente te entrega, en realidad no estás construyendo software; estás apostando.

La buena noticia: no necesitas leer cada línea como un revisor de código paranoico. Necesitas una red de seguridad por capas para que los errores obvios se detecten automáticamente y solo las decisiones interesantes lleguen a tus ojos. Aquí te explicamos cómo construir una, de lo más barato a lo más exhaustivo.

1. Lee el diff, no el chat

El hábito de mayor valor: revisa los cambios reales en los archivos, no el resumen que la IA hace de ellos. Herramientas como Claude Code, Cursor y Copilot muestran un diff antes de aceptar los cambios. Échale un vistazo con tres preguntas:

• ¿Tocó archivos que yo no esperaba? A veces los agentes "amablemente" editan la configuración, borran pruebas o reescriben funciones no relacionadas.
• ¿Inventó un import o una API? Una señal de alarma es una llamada a un método de una biblioteca que nunca has visto. Verifica que existe antes de confiar en él.
• ¿Debilitó algo? Manejo de errores eliminado, un tipo relajado, una comprobación comentada o una prueba que ahora apenas verifica nada.

Este vistazo de 30 segundos detecta la mayoría de los momentos de "la IA hizo algo tonto".

2. Deja que la máquina revise a la máquina

Los humanos son malos detectando un punto y coma que falta y excelentes detectando lógica defectuosa. Vuelca el trabajo aburrido sobre las herramientas para que tu atención vaya a donde importa. Tres capas baratas y gratuitas:

• Un linter (ESLint, Ruff, etc.) para el estilo y los errores comunes.
• Un verificador de tipos (TypeScript, mypy) para atrapar la clase de errores de API alucinada y de forma-de-datos-incorrecta.
• Un ejecutor de pruebas para el comportamiento.

El truco es hacer que estas comprobaciones sean no opcionales conectándolas a un hook de pre-commit para que se ejecuten antes de que se confirme cualquier commit. Aquí tienes un ejemplo mínimo usando Husky en un proyecto de JavaScript:

# .husky/pre-commit
npm run lint && npm run typecheck && npm test

Ahora, si el código de la IA falla el linter, rompe los tipos o falla una prueba, el commit simplemente se rechaza. El error del agente nunca llega a tu rama. (En Python, el equivalente es el framework pre-commit ejecutando ruff, mypy y pytest).

3. Haz que la IA escriba — y ejecute — las pruebas

Los asistentes de IA son genuinamente buenos generando pruebas, y las pruebas son la mejor defensa contra el siguiente cambio que rompa silenciosamente este. Pero hay una trampa: un agente que escribe y ejecuta sus propias pruebas puede hacer trampa logrando que la prueba pase trivialmente. Así que separa los pasos en tu prompt:

"Escribe pruebas para esta función que cubran la entrada vacía, el camino feliz y un caso límite. No modifiques la función en sí."

Luego ejecuta las pruebas tú mismo, o en CI, y confirma que realmente ejercitan un comportamiento real. Una prueba como expect(result).toBeDefined() es puro teatro; expect(addTax(100, 0.2)).toBe(120) es una comprobación de verdad. Lee al menos una aserción para asegurarte de que es del segundo tipo.

4. Añade una puerta de calidad en CI

Los hooks locales protegen tu máquina; una comprobación en CI protege el proyecto de todo el mundo (incluido tu yo futuro en una noche cansada). Añade un flujo de trabajo que vuelva a ejecutar el linter, los tipos y las pruebas en cada pull request, y configura la rama para que los merges se bloqueen hasta que pase. Esta es exactamente la idea que las grandes plataformas venden ahora como producto: Code Quality de GitHub, que entra en disponibilidad general en julio de 2026, añade puertas que bloquean un merge cuando la mantenibilidad o la cobertura caen, y Cursor replanteó su comando /review como una puerta de pre-commit a principios de este año. Puedes obtener el 80% del valor gratis con un simple trabajo de GitHub Actions o GitLab CI.

5. Mantén a un humano en el bucle para el 5% arriesgado

La automatización no puede juzgar si una funcionalidad es la funcionalidad correcta, si una decisión de arquitectura envejecerá bien, o si borrar esa función "sin usar" es seguro. Reserva tu atención real para: cualquier cosa que toque autenticación, pagos o borrado de datos; migraciones de base de datos; y cambios en código compartido del que dependen muchos otros archivos. Para todo lo demás, deja que la red de seguridad haga el trabajo.

Una regla práctica sencilla

Cuanta más autonomía le des a la IA, más fuertes deben ser tus puertas. Si estás aceptando cuidadosamente un cambio a la vez, una lectura rápida del diff puede bastar. Si dejas que un agente corra diez minutos sin supervisión, querrás linter, tipos y pruebas interponiéndose entre él y tu rama principal. Construye la red una vez y podrás dejar que la IA avance rápido sin que rompa cosas en silencio a tus espaldas.