Matt Pocock / diagnosing-bugs
Por que a correção de um agente conserta tantas vezes a coisa errada?
Porque existe uma correção plausível disponível muito antes de a causa ser entendida.
O que vale lembrar
- Diagnosticar e reparar são trabalhos diferentes. Misturar é como correções de sintoma entram em produção.
- Entregar sua teoria cedo é o jeito mais rápido de tê-la confirmada em vez de testada.
- Peça a evidência que distingue essa causa da próxima mais provável.
- Sobrepõe systematic-debugging do superpowers. Teste as duas e fique com uma.
01O que muda na prática
Diante de um stack trace, um agente quase sempre produz uma mudança que faz o erro sumir. Isso não é consertar o defeito, e a diferença costuma aparecer uma semana depois com um erro mais estranho.
Exigir uma causa declarada antes da mudança torna o raciocínio inspecionável. Se a causa está errada, dá para ver na hora, o que é bem mais barato que descobrir por uma regressão.
02Onde decepciona
Ela não diagnostica o que não observa. Sem logs, sem reprodução e sem ambientes disponíveis, ela fica limitada como qualquer pessoa.
Em bugs triviais é mais lenta que simplesmente corrigir, então guarde para os que já custaram uma tarde.
Instalação e primeira execução
- Instale com o CLI de skills a partir de mattpocock/skills, sob MIT.
- Dê a observação, não a sua teoria: o que você esperava, o que aconteceu e como reproduzir.
- Exija uma causa declarada e evidência antes de aceitar qualquer mudança.
Perguntas que as pessoas realmente fazem
- Qual a diferença de só pedir a correção?
- Ela exige causa declarada e com evidência antes de mudar código, então patch de sintoma fica visível em vez de silencioso.
- Devo contar minha teoria do bug?
- No começo não. Dê observações e uma reprodução, ou você recebe sua própria teoria confirmada de volta.
- Como se compara ao systematic-debugging?
- Mesma intenção, mais estrutura lá. Escolha uma para o agente receber um único conjunto de instruções.
Fontes
Versões legíveis por máquina desta página