Matt Pocock / diagnosing-bugs
¿Por qué los arreglos de un agente arreglan tantas veces lo que no era?
Porque hay un arreglo plausible disponible mucho antes de entender la causa.
Lo que conviene recordar
- Diagnosticar y reparar son trabajos distintos. Mezclarlos es como se publican parches de síntoma.
- Dar tu teoría pronto es la forma más rápida de que te la confirmen en vez de ponerla a prueba.
- Pide la evidencia que distingue esa causa de la siguiente más probable.
- Se solapa con systematic-debugging de superpowers. Prueba ambas y quédate con una.
01Qué cambia en la práctica
Ante una traza de error, un agente casi siempre produce un cambio que hace desaparecer el mensaje. Eso no es arreglar el defecto, y la diferencia suele aparecer una semana después con un error más raro.
Exigir una causa declarada antes del cambio hace inspeccionable el razonamiento. Si la causa está mal, se ve al momento, que es mucho más barato que descubrirlo por una regresión.
02Dónde decepciona
No puede diagnosticar lo que no observa. Sin logs, sin reproducción y sin entornos disponibles, se limita igual que una persona.
En fallos triviales es más lenta que arreglarlos, así que resérvala para los que ya te costaron una tarde.
Instalación y primera ejecución
- Instálala con el CLI de skills desde mattpocock/skills, con licencia MIT.
- Dale la observación, no tu teoría: qué esperabas, qué pasó y cómo reproducirlo.
- Exige una causa declarada y evidencia antes de aceptar ningún cambio.
Preguntas que la gente hace de verdad
- ¿En qué se diferencia de pedir un arreglo?
- Exige una causa declarada y con evidencia antes de tocar código, así los parches de síntoma se ven en vez de colarse.
- ¿Comparto mi teoría del fallo?
- Al principio no. Da observaciones y una reproducción, o te devolverán tu propia teoría confirmada.
- ¿Cómo se compara con systematic-debugging?
- Misma intención, más estructura allí. Elige una para que el agente reciba instrucciones únicas.
Fuentes
Versiones legibles por máquina de esta página