Quando o modelo não degradou, mas o agente piorou

Existe um padrão recorrente em comunidades de desenvolvedores que usam agentes de código com intensidade: a sensação de que o modelo "piorou". A resposta virou slop. O agente está cometendo erros que antes não cometia. Algo mudou.

Às vezes isso é real. Mas existe uma hipótese alternativa que poucos testam: a harness mudou, não o modelo.

A distinção que faz diferença

O Mario Krebs, criador do Pi, um agente de código minimalista, articulou esse ponto de forma direta. Ele mantém controle total sobre sua harness e usa os mesmos modelos que todo mundo. Não experimenta as degradações que outros usuários do Claude reportam. Sua conclusão: a maior parte das reclamações de degradação é psicologia (entusiasmo inicial que cede ao uso real) ou mudança de harness, não mudança de modelo.

A evidência que ele cita é concreta: o Claude Code mudou o gerenciamento de thinking traces em sessões idle. Thinking traces mais velhos foram removidos para reduzir latência, mas isso afetou o que o agente conseguia lembrar dentro da sessão. O comportamento do agente mudou não porque o modelo mudou, mas porque a harness mudou como o contexto é gerenciado.

Para quem está rodando um sistema em produção, essa distinção importa muito. Se você atribui a degradação ao modelo, você fica esperando a Anthropic corrigir algo que talvez não seja deles para corrigir. Se você entende que é a harness, você pode investigar e controlar.

Por que harnesses mínimas são mais estáveis

O ponto central que o Mario defende é que estabilidade operacional vem de minimismo, não de features. Uma harness que faz só o que precisa fazer, e que você controla completamente, vai se comportar da mesma forma amanhã que hoje. Uma harness com muitas features, que muda com frequência para adicionar funcionalidade, vai mudar o comportamento do agente mesmo que o modelo não mude.

Isso ressoa com o que aprendo construindo sistemas como o Athena e o Nexus ZDT. A escolha de não usar frameworks pesados como LangChain para coisas que podem ser feitas diretamente não é por demérito dos frameworks. É porque cada camada de abstração é um ponto de mudança que você não controla. Quando uma versão nova do framework muda um comportamento padrão, seu sistema muda junto, mesmo que você não tenha tocado no código.

A consequência prática é que sistemas mais simples são mais previsíveis. Não no sentido de que são menos capazes, mas no sentido de que você sabe o que está acontecendo quando algo muda.

O que o contexto tem a ver com tudo isso

A outra observação que o Mario faz é que a maioria dos problemas de comportamento de agente "vem do contexto". Não da qualidade do modelo em abstrato, mas do que o modelo tem acesso quando precisa tomar uma decisão.

Um agente que não tem visibilidade do histórico relevante vai cometer erros que parecem ser falta de capacidade mas são falta de contexto. Um agente que tem contexto poluído com informação desatualizada vai agir com base nessa informação errada com a mesma confiança que usaria para informação correta.

Controlar o contexto é controlar o comportamento. Isso exige que você entenda exatamente o que está no contexto em cada momento, o que significa não delegar essa decisão para uma harness que muda fora do seu controle.

O que "o código não precisa ser perfeito" significa na prática

Existe outra observação que o Mario faz que é relevante para quem está construindo soluções empresariais com IA: a principal fonte de valor não é o novo produto que você lança para o mundo. É o que você faz de forma mais produtiva internamente.

Empresas pequenas com equipes habilitadas a usar agentes para suas próprias tarefas internas conseguem ter a capacidade operacional de equipes muito maiores. O patamar de qualidade de código necessário para uma ferramenta interna que economiza tempo é diferente do patamar necessário para um produto que vai ser vendido. O código pode ser imperfeito. O que importa é que gera resultado útil.

Isso tem implicações diretas para como você prioriza. Ferramentas internas de apoio aos processos do Nexus ZDT, do GITFLOW, do Athena não precisam ser produtos polidos. Precisam ser funcionais e economizar tempo de quem as usa. Esse critério diferente muda o que vale construir.

O que eu separo do hype

A distinção que o Mario faz entre auto-research real (com critério de sucesso objetivamente mensurável) e "RLHF loop" como marketing (iterar sobre um spec até o agente declarar que está pronto) é útil. A diferença é: o primeiro tem uma função objetiva que o próprio agente pode avaliar. O segundo tem uma função subjetiva que o agente avalia sobre si mesmo.

Sistemas que melhoram autonomamente existem e funcionam. Mas o critério de funcionamento precisa ser externo ao sistema, não auto-declarado.

Qual comportamento do seu sistema você atribuiu ao modelo sem verificar se a harness mudou entretanto?