¿Ya no tiene sentido revisar línea a línea el código que genera la IA?

Cuando gran parte del código lo escribe un agente a partir de una especificación, ¿hasta qué punto sigue teniendo sentido que el propio desarrollador revise ese código línea a línea — comprobando el casting de un método, qué librería concreta se usó, el nombre de cada variable — en lugar de centrarse solo en si los tests pasan y la funcionalidad cumple lo esperado? ¿Ese hábito de "mirar el código con lupa" ya pertenece a una forma de trabajar superada?

La respuesta tiene matices: la revisión detallada pierde valor en un momento del flujo, pero no desaparece — se traslada a otro momento y a otra persona.

Revisar el código en el nivel más granular —el casting exacto de un tipo, qué librería auxiliar se eligió para una tarea trivial, el estilo de una función interna— cada vez tiene menos sentido si la especificación y los tests ya están bien definidos. Ese nivel de detalle era necesario cuando el propio desarrollador escribía el código a mano y podía introducir un error humano en cualquier línea. Cuando el código sale de un agente que parte de un contrato claro y de tests que definen el comportamiento esperado, gran parte de esa fiscalización deja de aportar información nueva: si los tests pasan y el contrato se respeta, el "cómo" interno importa mucho menos que antes.

Esto no significa que la revisión de código desaparezca del todo — sigue existiendo, pero cambia de forma y de responsable. En lugar de que el mismo desarrollador que generó el código lo revise línea a línea mientras programa, ese código pasa por una revisión de otra persona en modo code review clásico, centrada en el diseño y en si la solución encaja con el resto del sistema, no en microdetalles de sintaxis.

Lo que de verdad aporta valor hoy no es fiscalizar cada línea generada, sino invertir el tiempo antes: en definir bien el contexto y la especificación de la que parte el agente, y después: en validar que el resultado final cumple exactamente lo que se esperaba, con los tests como verificación objetiva.

Hay excepciones claras donde la revisión detallada sigue siendo necesaria: código que toca seguridad, manejo de datos sensibles, rutas críticas de rendimiento, o cualquier lógica de negocio donde un matiz de implementación cambia el resultado (por ejemplo, redondeos en cálculos financieros). Ahí el "cómo" sí importa, y ningún test superficial lo cubre por sí solo.

Fuera de esos casos, el criterio práctico es: si un test bien escrito puede detectar el problema, delega esa verificación al test y dedica el tiempo humano a la especificación y a la validación funcional. Si un test no puede detectarlo (por ser una decisión de diseño, seguridad o coste), esa parte sigue necesitando ojo humano línea a línea.