El código que compila no es el entregable: qué validamos antes de que el cliente lo vea

Un LLM puede escribir una función que compila, pasa sus propios tests y hace exactamente lo que el prompt pedía. Ninguna de esas tres cosas garantiza que sea lo que el cliente necesitaba. Ese hueco —entre "el modelo respondió algo correcto" y "esto es entregable"— es el que nos interesa, porque es donde se cuelan los errores más caros: los que llegan a producción con buena pinta.

El problema no es la calidad del modelo

Cuando algo generado por IA falla en producción, la primera reacción suele ser "el modelo se equivocó". Casi nunca es así. El modelo respondió bien a la pregunta que se le hizo. El problema está antes: en que la pregunta no incluía todo el contexto que el entregable necesitaba, y nadie comprobó la diferencia entre ambas cosas antes de dar por cerrado el ticket.

Un ejemplo típico: pedimos a un asistente que implemente un endpoint de cancelación de pedidos. El código que produce cancela el pedido, actualiza el estado en base de datos y devuelve un 200. Compila, pasa los tests que el propio modelo escribió para sí mismo, y en una revisión rápida parece terminado. Lo que no hace —porque nadie se lo pidió explícitamente y el modelo no tiene forma de saber que existe— es liberar el stock reservado, notificar al servicio de facturación o respetar la ventana de cancelación que el negocio exige. Nada de eso es un fallo del modelo. Es un fallo de haber tratado la respuesta como el entregable en lugar de como un borrador.

Por qué el propio LLM no puede ser el que valida

Hay una tentación razonable: si el modelo escribió el código, que el modelo revise su propio trabajo antes de entregarlo. No funciona, y no es un límite técnico coyuntural sino estructural. El modelo que generó la solución comparte el mismo punto ciego que produjo el problema. Si no tenía el contexto de negocio para escribir el caso de liberación de stock, tampoco lo va a tener para detectar que falta.

Esto se parece a por qué un desarrollador no debería ser el único revisor de su propio pull request: no es cuestión de talento, es que la persona que escribió el código ya decidió, sin darse cuenta, qué casos eran "obvios" y cuáles no merecía la pena cubrir. Con un LLM el efecto es más pronunciado porque el modelo no tiene memoria de negocio entre sesiones ni entiende implícitamente las reglas que nunca se escribieron en el prompt.

Los cuatro filtros que aplicamos antes de dar algo por entregable

Revisión humana obligatoria, sin excepción por tamaño del cambio. No existe un cambio "tan pequeño que no hace falta revisarlo". La mayoría de los incidentes que hemos visto con código asistido por IA no vinieron de features grandes, sino de cambios de una línea que un revisor humano habría cuestionado en cinco segundos: un >= que debía ser >, un valor por defecto que no aplicaba al caso de un cliente concreto.

Tests end-to-end escritos por una persona, no por el modelo que generó el código. Un test que escribe el mismo asistente que escribió la función tiende a validar lo que la función hace, no lo que debería hacer. Preferimos que el criterio de aceptación se escriba primero, en lenguaje de negocio, y que el test E2E se derive de ahí, independientemente de cómo se implementó la solución. Un ejemplo simplificado con Playwright:

test('cancelar un pedido libera el stock reservado', async ({ page }) => {
  await crearPedido(page, { producto: 'SKU-123', cantidad: 2 });
  const stockAntes = await consultarStockReservado('SKU-123');

  await cancelarPedido(page, ultimoPedidoId);

  const stockDespues = await consultarStockReservado('SKU-123');
  expect(stockDespues).toBe(stockAntes - 2);
});

Ese test no existe en ningún prompt. Existe porque alguien conocía la regla de negocio y decidió que había que comprobarla, con independencia de qué herramienta escribió el endpoint.

Validación explícita contra criterios de aceptación, no contra "funciona". "Funciona" describe que el código no lanza una excepción. Un criterio de aceptación describe qué tiene que ser cierto para que el negocio considere resuelto el problema. Son cosas distintas y conviene no dejar que la primera sustituya a la segunda solo porque es más fácil de comprobar. Antes de cerrar cualquier tarea generada o acelerada con IA, la lista de criterios de aceptación del ticket original se revisa uno por uno, explícitamente, no de memoria.

Demo en staging antes de producción, con quien pidió la funcionalidad presente. No una captura de pantalla enviada por Slack: una sesión en vivo donde la persona que definió el requisito ve el flujo completo funcionando con datos parecidos a los reales. Esto detecta un tipo de error que ningún test automatizado detecta bien: la interpretación razonable pero incorrecta de un requisito ambiguo. El modelo interpretó "cancelar dentro de las primeras 24 horas" de una forma gramaticalmente correcta que no era la que el negocio quería decir.

Lo que la IA sí cambia, y lo que no

Donde un asistente de IA aporta valor real es en la velocidad del primer borrador: bocetar el endpoint, generar los tests unitarios triviales, proponer el esquema de la migración. Eso comprime en minutos lo que antes tomaba horas. Ninguno de los cuatro filtros anteriores desaparece por eso. Se mantienen exactamente igual que si el código lo hubiera escrito una persona junior el primer día, porque en la práctica esa es la analogía correcta: rápido, capaz, sin contexto de negocio acumulado, y sin la responsabilidad de decidir qué se entrega.

El riesgo real no es que un modelo escriba código malo. Escribe código razonable con más frecuencia de la que muchos equipos esperaban hace un par de años. El riesgo es tratar esa razonabilidad como sinónimo de terminado, y saltarse el paso en el que alguien, con el contexto completo del negocio, decide si eso es lo que había que construir. Ese paso no se automatiza porque no es un problema técnico: es un juicio, y los juicios los sigue haciendo un humano.