Correções de bugs também são memória

Assistir alguém depurar com um agente de codificação por uma hora e você verá a mesma forma toda vez. Vinte trocas de hipóteses erradas, logs colados de um lado para o outro, três correções que não corrigem nada, e então a resposta real, que geralmente é embaraçosamente pequena. Um await ausente. Um cabeçalho que o proxy remove. Uma variável de ambiente que só existe localmente. A tarde inteira se comprime em três linhas de diff.

Então a conversa termina, e essas três linhas vão para a base de código enquanto tudo que as tornou encontráveis permanece no registro de chat. Dois meses depois, um projeto diferente encontra a mesma classe de bug, uma nova sessão de agente se abre sem saber que tudo isso aconteceu, e você paga pela busca toda novamente.

A geração é barata, o diagnóstico não

A razão pela qual as correções importam mais do que os componentes se resume a uma assimetria. Se você perder um componente, um novo agente regenerará um decente a partir de uma descrição curta, porque a geração tem um alvo amplo: muitas implementações são aceitáveis e o modelo conhece a vizinhança. O diagnóstico tem um alvo estreito. O valor nunca foram as três linhas. O valor estava em eliminar tudo o mais, e esse trabalho de eliminação não se transfere quando apenas o diff sobrevive.

É por isso que reencontrar um bug que você já resolveu parece tão ruim. Você não está irritado por escrever a correção duas vezes. Você está irritado por pagar pela busca duas vezes: as mesmas voltas erradas, o mesmo gasto de tokens, a mesma janela de contexto se enchendo de becos sem saída.

A anatomia de uma correção que vale a pena salvar

Um diff sozinho é quase inútil para um agente futuro, porque o agente futuro nunca o encontrará. O que torna uma correção um ativo em vez de um resíduo é tudo ao seu redor:

O sintoma, escrito da maneira que você procuraria. Não "bug de autenticação corrigido", mas a mensagem de erro, o comportamento observável, as palavras que alguém realmente digitariam quando isso acontecer novamente. A recuperação falha quando o rótulo descreve a solução em vez do problema.

A causa raiz em uma frase. Não a história da tarde, apenas o que estava realmente errado.

As abordagens falhadas. Esta é a parte que ninguém salva e a parte que mais salva. O conhecimento negativo é o que permite que a próxima sessão pule as primeiras cinco hipóteses erradas em vez de re-caminhá-las.

O ambiente. Versões de bibliotecas, tempo de execução, a combinação específica que tornou este bug possível, porque metade dessas correções só é verdadeira para um estado de pilha particular.

Salve isso, e uma correção deixa de ser uma cicatriz e começa a ser um bloco de construção.

Registros de chat são onde as correções vão morrer

O armazenamento padrão para tudo isso agora é o histórico de conversas, e o histórico de conversas falha de uma maneira específica: é somente para escrita. O conhecimento entra e nunca sai, porque não há caminho de "este erro parece familiar" para o tópico certo de seis semanas atrás. Você não pode grep por uma vibe.

Então o hábito que importa é a captura deliberada no momento em que a correção é feita, enquanto a causa raiz e as voltas erradas ainda estão na sua frente. Salve a correção uma vez, com seu sintoma e seu conhecimento negativo, e recupere-a em todos os projetos depois disso. Correções de bugs também são memória.

O que isso se acumula

Eu continuo voltando à mesma linha: o que persiste entre as sessões é memória, e qual deve ser sua pilha de memória deve ser sua maior prioridade. Componentes foram o primeiro ativo óbvio, mas as correções são onde a acumulação se torna barulhenta, porque cada diagnóstico salvo remove uma classe inteira de custo futuro em vez de apenas um passo de geração futura.

Uma equipe, ou até mesmo um desenvolvedor, que trata as correções dessa maneira acaba com uma vantagem estranha: seus agentes ficam melhores em sua pilha específica ao longo do tempo. Os modos de falha obscuros de sua infraestrutura deixam de ser exercícios de redescoberta. Depuração começa a parecer composição: reconhecer o sintoma, puxar o ativo, seguir em frente.

Essa é uma grande parte do motivo pelo qual estou construindo o Sirro, e escrevi sobre o lado do servidor disso em o que o envio de um servidor MCP hospedado me ensinou sobre a memória do agente. A versão curta: os agentes são intercambiáveis, e o que eles mantêm não é. Salve a correção. Seu eu futuro, em uma nova sessão com um erro que parece familiar, agradecerá você.