Cuando se le pide a una IA que analice algo con varios criterios, la respuesta natural es una tabla completa y limpia: todas las casillas rellenas y todas con el mismo tono de seguridad. Parece más útil. En realidad es menos fiable, porque ya no puedes distinguir qué ha contado de verdad y qué se ha inventado.
El problema de la tabla perfecta
Imagina que le pides, para cada hallazgo de una auditoría, cuatro datos: daño, radio, reversibilidad y precedencia. Algunos se pueden responder abriendo el código: cuántos sitios hay que tocar, en qué archivo y en qué línea. Ahí el modelo trabaja bien, porque puede ir a contar. Otros dependen de información que no está en el repositorio: quién usa ese endpoint, qué pasaría con datos ya guardados en producción, si hay integraciones externas. Para esos, un modelo que no sabe suele responder igual, con aplomo, rellenando con lo más probable.
El resultado es una tabla donde lo verificado y lo supuesto tienen exactamente el mismo aspecto.
La instrucción que cambia el resultado
La solución es una frase en el prompt: deja la casilla en blanco cuando no puedas responderla abriendo el código, y no la rellenes por aproximación. Con ella, el agente separa lo que ha comprobado de lo que no puede saber, y los huecos pasan a ser información: te indican exactamente dónde hace falta una persona.
Conviene acompañarla de otras restricciones: exigir que el radio se cuente y se liste con archivo y línea (nunca «varios»), y pedir que no ordene la lista ni arregle nada, para que no se salte los pasos que son trabajo tuyo.
Qué enseñan los huecos
En la práctica los huecos suelen caer en sitios muy reveladores: una decisión de diseño que aún no se ha tomado (por ejemplo, cómo identificar al autor de un comentario sin sesión), un dato que solo existe en producción, una medida de rendimiento que nadie ha hecho. Cada uno te dice qué decidir, qué medir o a quién preguntar.
También puedes pedirle un paso más: que explique por qué ha dejado cada casilla vacía. Esa explicación es fácil de contrastar con tu propio criterio y te ahorra interpretar el hueco.
Ojo con dos matices. Primero, no todos los modelos ni todos los niveles de esfuerzo dejan los mismos huecos: el umbral a partir del cual algo se considera una aproximación varía entre ejecuciones. Segundo, que un modelo sea cauto de más suele ser preferible a que invente, porque así concentras tu atención en lo realmente indeterminado.
Resumen rápido
Una tabla completa no es una tabla fiable. Pide huecos explícitos para lo que no se puede comprobar en el código, exige datos contados y no estimados, y dedica tu tiempo a los huecos: son la parte del trabajo que no se delega.