Ese código feo sostiene la estructura
¿Ese código feo que estás a punto de borrar? Podría estar sosteniendo la estructura. A los agentes de IA les encanta derribar cercas que no entienden — un prompt de "simplifica este archivo" eliminará sin dudar el bucle de reintentos que protege contra una API inestable, o el caso especial de zona horaria que costó tres incidentes en producción. La complejidad acumulada a veces tiene una razón, y a veces no. Tu trabajo es averiguar cuál es el caso — antes de que el diff se integre.
La regla: la cerca de Chesterton
En 1929, G.K. Chesterton describió a un reformador que encuentra una cerca cruzando un camino y quiere quitarla. Su respuesta: "Si no ves su utilidad, ciertamente no dejaré que la quites. Vete a pensar." Solo cuando puedes explicar por qué se puso la cerca te has ganado el derecho a quitarla.
El principio aplica uno a uno a la revisión de borrados generados por IA. El agente no construyó la cerca, no recuerda el incidente que la motivó, y optimiza por "más limpio" — el perfil exacto del reformador descuidado de Chesterton. La solución no es prohibir los borrados; es exigir la arqueología primero.
Las 3 preguntas antes de borrar
Antes de eliminar algo raro, responde estas preguntas — y haz que tu agente también las responda:
| Pregunta | Comando que la responde |
|---|---|
| ¿Por qué se escribió? | git blame -w -C <file>, luego git show <commit> para el mensaje y el issue vinculado |
| ¿Cómo evolucionó? | git log -L <start>,<end>:<file> (o -L :<funcname>:<file>) — cada commit que tocó esas líneas |
| ¿Qué depende de esto? | git grep <symbol> sobre los archivos rastreados, más el buscar-referencias de tu editor |
Si alguna respuesta es "ni idea", no estás listo para simplificar. Lee más contexto primero, y luego corta con confianza.
Leer el blame como detective
-wignora los espacios en blanco, para que un commit de reformateo no oculte al autor real.-Csigue líneas movidas y copiadas entre archivos — pásalo hasta tres veces para perseguir código a través de refactors. Sin él, el blame se detiene en el último commit de "mover archivos".--ignore-revs-fileomite commits ruidosos conocidos (reformateos masivos, barridos de lint) listados en un archivo — muchos repos mantienen un.git-blame-ignore-revspara esto, conectado conblame.ignoreRevsFile.- El mensaje del commit importa más que su diff. Un diff de una línea con "fix: handle DST transition for AU/Lord Howe" te dice que la cerca sostiene la estructura.
Nivel avanzado: que el agente haga la arqueología
- Escríbelo en las instrucciones de tu agente (CLAUDE.md, AGENTS.md o tu prompt de revisión): "Antes de borrar o simplificar lógica existente, ejecuta
git blamesobre las líneas afectadas y cita el mensaje del commit original en tu explicación." - Exige una justificación por cada borrado. Pide al agente una tabla: líneas eliminadas → commit original → por qué ahora es seguro. Si no puede llenar la tercera columna, rechaza ese hunk.
- Usa
git log -L :<funcname>:<file>como primera llamada del agente — el historial de una función suele ser de 3 a 10 commits y cabe fácil en el contexto. - Convierte las cercas valiosas en tests. Si una rama rara protege un caso límite, escribe el test que falla y lo demuestra, y luego borra. Ahora la cerca está documentada y es verificable, y el próximo agente no podrá quitarla en silencio.
Recursos
- git blame — documentación oficial (
-w,-C,--ignore-revs-file) - git log — la opción
-Lde historial por rango de líneas - git grep — buscar en archivos rastreados
- G.K. Chesterton, "The Drift from Domesticity" (The Thing, 1929) — el pasaje original de la cerca
- Chesterton's Fence: A Lesson in Thinking — Farnam Street
¿Construyendo una funcionalidad con IA? Yeda AI diseña, audita y entrega sistemas LLM en producción.