¿Evaluar contra qué?

Si la IA escribe el código y el trabajo pasa a ser revisarlo, falta la otra mitad de la pregunta. Cómo audito código generado sin leerlo línea por línea, y por qué el criterio tiene que estar escrito antes.

Hace un tiempo escribí que "anda de milagro" es un insulto: si un sistema funciona, no es milagro — es que alguien, en algún momento, pensó el criterio de diseño con el que funciona.

Hace poco me crucé un planteo que llega a algo parecido por otro camino: la IA no está degradando la ingeniería, está dejando en evidencia la que ya teníamos. Antes podías ser malo pero lento; ahora podés ser malo pero rápido.

El planteo es de Fco Javier Vives Berenguer, en LinkedIn. Coincido, y este post es lo que me quedó dando vueltas después de leerlo.

Coincido con el diagnóstico. Pero deja una pregunta abierta, y es la que me interesa: si el trabajo pasó de escribir a evaluar, ¿evaluar contra qué?

Porque "revisá lo que genera" no es una instrucción. Es una responsabilidad sin criterio adjunto.

#Auditar, no leer

El primer cambio práctico es que no leo el código generado línea por línea.

No es una postura, es economía: si la IA escribe en dos minutos lo que yo escribía en dos horas, y después lo leo con la misma profundidad con la que lo habría escrito, no gané nada. Moví el tiempo de lugar.

Así que lo trato como trato el PR de un compañero. Audito decisiones, no caracteres.

Con una diferencia respecto de revisar a una persona: intensifico las pruebas de casos de uso. Ahí es donde se compensa lo que no leí en detalle. Un dev con contexto del sistema falla distinto que un modelo sin él — la persona omite lo que da por sabido, el modelo produce algo plausible que puede no corresponder a este sistema en particular. Contra lo plausible-pero-incorrecto, ejecutar casos reales rinde mucho más que leer.

#Qué miro, en orden

La intención. Qué está tratando de hacer este código, y cuántas cosas distintas está tratando de hacer a la vez. Es la misma pregunta que uso para decidir si un DTO se está reutilizando de más: ¿cuántas intenciones hay realmente en juego acá? Un modelo tiende a producir algo que sirve para todo, porque no tiene motivo para separar lo que vos separarías.

El acoplamiento. Qué quedó atado a qué. Lógica de negocio que se filtró al controller, infraestructura que se coló en el dominio, una dependencia que cruza un límite que el proyecto venía respetando.

Los puntos de fallo. Qué pasa cuando algo no está, no responde o llega distinto. El código generado suele ser excelente en el happy path — es lo que más ejemplos tiene de dónde aprender.

Los tests. No si existen: si prueban algo. Un test que pasa siempre no es cobertura, es decorado. Y ojo con los que en realidad verifican el mock en vez del comportamiento: esos dan la sensación más peligrosa de todas, que es la de estar cubierto.

La modularización. Si lo generado respeta la forma que el sistema ya tiene, o si inventa una manera nueva de hacer algo que el proyecto ya resolvía de otra forma. Dos maneras de hacer lo mismo conviviendo es deuda técnica recién nacida.

#El resultado sigue siendo mío

Esto es lo que más me ordena la cabeza: la herramienta es nueva, y por eso tomo recaudos — pero el resultado no deja de ser mi responsabilidad.

"Lo generó la IA" no va a funcionar como explicación. No funciona hoy y no va a funcionar en la revisión de dentro de seis meses, por la misma razón por la que no funciona "me lo dijeron de palabra": lo que queda escrito es el código, y el código lo firmaste vos.

Si algo sale mal, no salió mal el modelo. Salió mal la decisión de aceptarlo.

#La calculadora no acabó con los matemáticos

Me atrapa la idea de una IA haciendo el trabajo pesado. Y no creo que mate al desarrollador — creo que lo potencia, y al que labura bien lo potencia todavía más.

La calculadora no terminó con las matemáticas: movió el trabajo un nivel para arriba. Nadie extraña calcular raíces a mano, y a nadie se le ocurre que eso haya hecho más tontos a los matemáticos.

Con la máquina de escribir el ejemplo es menos cómodo, y por eso mismo es más útil: ahí el rol sí cambió de forma. Los pools de dactilografía desaparecieron. Lo que no desapareció fue la necesidad de que alguien decidiera qué se escribía y si estaba bien escrito. La herramienta absorbió la ejecución; el criterio se mudó, no se evaporó.

Con esto pasa igual. La parte que se automatiza es la de escribir. La que queda es la de decidir si lo escrito sirve — que siempre fue la parte difícil, solo que antes venía disimulada dentro de las dos horas de tipeo.

#El criterio tiene que existir antes

Y acá está el punto que me parece que el diagnóstico original no termina de cerrar.

Si la IA expone cuánta ingeniería había realmente, lo que expone en concreto es cuánto de tu criterio estaba escrito y cuánto vivía en la cabeza de alguien. Un equipo con convenciones explícitas, límites definidos y tests que prueban comportamiento revisa código generado sin despeinarse: ya sabe contra qué compararlo. Un equipo donde "sabemos cómo se hacen las cosas acá" nunca se escribió, no tiene contra qué evaluar — y a la velocidad a la que ahora entra el código, el criterio implícito no llega.

Esa es la auditoría real. No es sobre la IA. Es sobre si alguna vez pusiste por escrito cómo se hacen las cosas.

(Buena parte de este sitio es, en el fondo, ese ejercicio: dejar el criterio anotado antes de necesitarlo.)

#ai #code-review #quality #team-practices