Depurar con IA: prompts que encuentran la causa

Depurar con IA funciona mejor cuando le das al modelo lo que le darías a un colega sentado a tu lado: el error completo, el código que lo lanzó, lo que esperabas, lo que pasó en su lugar y lo que ya descartaste. El modelo no puede ejecutar tu programa ni ver tus datos, así que todo lo que sabe del error sale de lo que pegas. El hábito más útil es pedir la causa antes que la solución.

Pégalo todo, no solo el error

Las dos pestañas de abajo describen el mismo error. Un script lee un archivo CSV exportado desde Excel y falla con KeyError: 'email', aunque el archivo tiene claramente una columna de correo.

Solo el errorInforme completo

EditCopy

Arregla esto: KeyError: 'email'

Try it

Example replyReplies vary between models and runs.

Un KeyError significa que el diccionario no tiene ninguna clave llamada 'email'. Puedes evitar el error usando .get(), que devuelve None en lugar de lanzar una excepción:

email = row.get("email")

O comprobarlo antes:

if "email" in row:
    email = row["email"]

La primera respuesta acierta en qué es un KeyError, y su consejo aquí es dañino. Con row.get("email") el fallo desaparece y todos los correos pasan a ser None. El modelo respondió a la versión más común del error porque eso es todo lo que describía el prompt.

El informe completo funcionó por dos líneas. "Solo falla la primera columna" y "guardado desde Excel como CSV UTF-8" son las pistas que apuntan a la marca de orden de bytes, y ninguna está en el mensaje de error. Rara vez sabes cuál de tus detalles es la pista, y por eso los pegas todos.

Las cinco cosas que incluir

1. El error completo. Todo el traceback o la salida de la consola, no una paráfrasis. Los números de línea y la cadena de llamadas muestran dónde empezó el fallo, que a menudo está a unos cuantos niveles de donde salió a la superficie.
2. El código que lo lanzó. La función que falla y el código que la llama. Si el error menciona una línea, asegúrate de que esa línea esté en lo que pegas.
3. Lo esperado frente a lo real. Una frase para cada cosa. En los errores sin mensaje (una salida incorrecta, una página en blanco, una consulta lenta), esto es todo el informe del error.
4. Tu entorno. La versión del lenguaje, el sistema operativo y las versiones del framework y las bibliotecas cuando puedan importar. Los errores de codificación, de rutas y de fechas suelen depender de la plataforma.
5. Lo que ya probaste. Evita que el modelo vuelva a sugerirlo, y el resultado de cada intento es una evidencia. "Si quito la parte del correo funciona" redujo el error del CSV a una columna.

Pide la causa antes que la solución

Pedir una solución invita al modelo a cambiar código hasta que el error desaparezca. Pedir la causa le pide razonar por qué ocurre el error, y la solución se deriva de ahí. Pide una lista breve de causas ordenadas, con una forma de comprobar cada una, y luego haz tú las comprobaciones. Esta plantilla hace eso:

Ordena las causas, sin solución todavía

EditCopy

Fill inlenguajeesperadoreal

PartsTaskContextInputFormat

Task

Ayúdame a encontrar la causa de un error en mi código de JavaScript. No escribas todavía una solución.

Context

Esperado: la lista de usuarios aparece cuando carga la página Real: página en blanco, y este error en la consola del navegador

Input

TypeError: Cannot read properties of undefined (reading 'map')function UserList() { const [users, setUsers] = useState(); useEffect(() => { fetch("/api/users") .then((res) => res.json()) .then((data) => setUsers(data)); }, []); return ( <ul> {users.map((u) => ( <li key={u.id}>{u.name}</li> ))} </ul> ); }

Format

Enumera hasta tres causas probables, la más probable primero. Para cada una, da una comprobación de una línea que pueda ejecutar para confirmarla o descartarla.

Try it

Example replyReplies vary between models and runs.

1. El componente se renderiza antes de que existan datos. useState() empieza como undefined, y React renderiza el componente una vez antes de que se ejecute el efecto, así que users.map se llama sobre undefined. Eso por sí solo produce exactamente tu error, en cada carga. Comprobación: añade console.log(users) justo antes del return. Si registra undefined y el error sale justo después, es esto.
2. La API devuelve algo que no es un array. Si devolviera un objeto como { users: [...] }, el error sería otro (users.map is not a function), así que no es el error que pegaste. Aun así, puede ser el siguiente problema una vez arreglada la causa 1. Comprobación: console.log(data) dentro del segundo .then.
3. La petición falla. Todavía no interviene: como el primer renderizado lanza el error, React nunca ejecuta el efecto, así que la petición ni siquiera se envía. Comprobación: la pestaña Red no muestra ninguna petición a /api/users, lo que además confirma la causa 1.

La respuesta hace algo que una respuesta centrada en la solución se salta: descarta causas porque el error que producirían es distinto del que pegaste, o porque el código nunca llega lo bastante lejos para que ocurran. Por eso importa también el texto exacto del error. Pedirle al modelo que enumere causas antes de responder es una forma ligera de cadena de pensamiento: primero va el razonamiento y la conclusión se apoya en él.

Haz una reproducción mínima

Una reproducción mínima es el programa más pequeño que todavía muestra el error: datos escritos a mano en lugar de una llamada a la base de datos, una función en lugar de todo el módulo. Construirla muchas veces encuentra el error antes de preguntarle a nadie, porque cada pieza que quitas o mantiene el error (no estaba implicada) o lo hace desaparecer (sí lo estaba). Cuando no lo encuentra, la reproducción es el prompt ideal: lo bastante corta para que el modelo lea cada línea, y libre de código sin relación que podría mandarlo a perseguir el problema equivocado.

Si el error depende de los datos, incluye algunas filas que lo provoquen. Un modelo puede razonar sobre [{"id": 1, "name": null}]; no puede razonar sobre "algunas filas en producción".

Cuando las soluciones dejan de funcionar

Si la tercera solución del modelo falla igual, pedir una cuarta difícilmente irá mejor. Dos cosas ayudan más:

• Dale evidencias nuevas. Añade un print o una línea de log que muestre los valores reales en el punto del fallo, ejecútalo y pega la salida. Una evidencia que contradice la teoría del modelo es el camino más rápido hacia una teoría mejor.
• Empieza una conversación nueva. Los hilos de depuración largos se llenan de teorías abandonadas y versiones antiguas del código, y el modelo puede seguir construyendo sobre ellas. Un chat nuevo con el código actual, el error, las evidencias y una línea que diga "ya descartado: X e Y" suele llegar más lejos en una sola respuesta.

Ten cuidado con las respuestas muy seguras sobre el comportamiento de una biblioteca. Un modelo puede describir una opción o una función que no existe; consulta alucinaciones de la IA para ver cómo comprobarlo. Cuando el código no está roto pero no entiendes por qué hace lo que hace, un prompt para explicar código es la mejor herramienta.