Cuando una barrera de protección grita: haz triaje antes de arreglar
Las barreras de protección solo sirven si respondes bien a ellas, y el patrón de fallo es predecible: la compilación se pone en rojo, entras en un poco de pánico, y le pegas el error a la IA con un "arréglalo." A veces funciona. A menudo produce un arreglo que hace desaparecer el texto rojo sin abordar lo que realmente estaba mal — la IA debilita la prueba, amplía un tipo, o envuelve la llamada que falla en un try/catch que traga el problema.
Antes de dejar que "arregle" algo, dedica diez segundos al triaje. En realidad solo hay tres tipos de fallo de barrera de protección:
- Un error real que acabas de introducir. La comprobación está haciendo su trabajo. Arregla el código, no la comprobación.
- Una prueba que ahora está desactualizada. Cambiaste el comportamiento a propósito, y la aserción antigua ya no coincide. Actualiza la prueba para afirmar el nuevo comportamiento correcto — de forma deliberada, no reflexiva.
- Una comprobación inestable (flaky) o incorrecta. Genuinamente raro. Sé desconfiado contigo mismo aquí; este es el cajón donde la gente tira errores reales porque es el que les permite seguir adelante.
La instrucción que mantiene a la IA honesta es hacer que diagnostique antes de cambiar nada:
The test "never discounts below zero" is failing.
First, tell me WHY it fails — what does the code do now vs. what
the test expects. Then tell me which is correct: the code or the
test. Do NOT change anything until I confirm.
Esa única pausa es la diferencia entre una barrera de protección que te protege y una barrera de protección que has entrenado silenciosamente a la IA para derrotar. Una comprobación en rojo es información; lo peor que puedes hacer es pagar por ponerla en verde sin leer lo que te estaba diciendo.