English

Prueba el bug antes de arreglarlo

Nunca dejes que la IA arregle un bug cuya existencia no ha probado. Cuando llega un reporte de bug, el prompt tentador es "aquí está el error, arréglalo" — y el agente producirá con gusto un parche de apariencia plausible. Pero sin una reproducción tienes dos incógnitas en lugar de una: no sabes si el parche ataca la causa real, y no sabrás si el bug regresa en silencio el próximo mes. Una oración extra en tu prompt elimina ambas.

Por qué "solo arréglalo" es adivinar

Un agente de código que solo recibe un mensaje de error hace pattern matching hacia la causa más probable. A menudo acierta. Cuando falla, el modo de falla es feo: el código cambia, el mensaje de error desaparece (o se mueve), y todos asumen que el bug está muerto. No tienes ninguna señal que separe arreglado de enmascarado.

Un test que falla invierte la situación. Antes de cualquier arreglo, el agente debe escribir un test que reproduzca el comportamiento reportado y ejecutarlo para verlo fallar. Esa ejecución fallida es evidencia: el bug es real, quedó capturado en forma ejecutable, y la aserción del test documenta cómo se ve el comportamiento correcto. Solo entonces empieza el arreglo — y "listo" significa que ese mismo test pasa, no que "el diff se ve razonable".

Este es el ciclo clásico test-first del test-driven development aplicado a arreglar bugs, y es el reflejo estándar en equipos con código auto-verificable: primero escribe un test que exponga el bug, y solo entonces intenta arreglarlo. Los agentes hacen que la disciplina sea casi gratis — el test te cuesta una oración de prompt en lugar de veinte minutos de tu tiempo.

El patrón de prompt

En lugar de:

users report login fails after session timeout. fix it

escribe:

users report login fails after session timeout. check the auth flow
in src/auth/, especially token refresh. write a failing test that
reproduces the issue, run it and confirm it fails, then fix the code
until that test passes. show me both test runs.

Tres piezas que cargan el peso:

La fila del medio es la que más importa. Un test de reproducción que pasa a la primera significa que el agente malentendió el bug — mejor descubrirlo antes del "arreglo".

Por qué esto le queda especialmente bien a los agentes

Los agentes trabajan mejor con una verificación que puedan ejecutar: una señal que devuelve pasa o falla cierra el ciclo, así que el agente itera contra el test en lugar de detenerse cuando el código "se ve terminado". El test que falla es exactamente esa verificación — el agente arregla, ejecuta, lee el resultado y sigue hasta que está en verde. Convertiste un juicio subjetivo ("¿este parche se ve bien?") en una condición verificable por máquina.

El mismo principio aparece en las guías de todos los proveedores: dale al agente criterios de verificación y exige evidencia, no afirmaciones de éxito.

Movidas de usuario avanzado

• Conserva el test para siempre. El test de reproducción se convierte en test de regresión. Si el bug vuelve, el CI lo atrapa en minutos en lugar de que un usuario lo atrape en producción.
• Nómbralo por el bug. test_login_fails_after_session_timeout (o el ID del issue) convierte tu suite de tests en un historial buscable de cada bug que mataste.
• Estaciona los bugs conocidos sin arreglar con una falla esperada. En pytest, marca la reproducción con @pytest.mark.xfail — la documentación menciona "un bug aún no arreglado" como uso canónico. El bug queda visible en cada corrida sin romper el build; cuando alguien lo arregla, se quita la marca.
• Separa escritor y revisor. Que una sesión del agente escriba el test que falla, y una sesión nueva escriba el arreglo. El que arregla no puede hacer trampa con un test que no escribió, y un contexto fresco no estará sesgado hacia el código que causó el bug.
• Exige causa raíz, no supresión del síntoma. Agrega "address the root cause, don't suppress the error" — si no, un agente decidido puede hacer pasar un test con un caso especial para ese input exacto.

Recursos

• Self-Testing Code — Martin Fowler — "primero escribe un test que exponga el bug, y solo entonces intenta arreglarlo"
• Test-Driven Development — Martin Fowler — el ciclo rojo → verde → refactor que este tip toma prestado
• Claude Code best practices — provide verification — "write a failing test that reproduces the issue, then fix it"
• pytest: skip and xfail — cómo marcar una reproducción de "un bug aún no arreglado"
• GitHub Copilot coding agent — get the best results — cómo delimitar tareas para que el agente verifique su propio trabajo