Blog

Autoengano é escolher acreditar numa ideia que já dá sinais de falsidade.

É tratar como verdade aquilo que, no fundo, eu sei que é frágil.

É chamar de fé o que é só desespero.

É recorrer à segurança imaginária da própria zona de conforto.

Oseias 7 descreve Israel instável. Reis são derrubados, conspirações fervem como forno aceso, alianças são feitas com Assíria e Egito na tentativa de sobreviver. Muito movimento. Muita articulação. Mas pouca maturidade.

A metáfora do “bolo não virado” explica tudo. Assado de um lado, cru do outro. Parece pronto, mas não está. Cresce por fora, mas é fraco por dentro. A ilusão é achar que isso basta.

Quando a base está comprometida, a falsa segurança inevitavelmente falha. Foi assim com Israel. É sempre assim.

Oseias alertou. Mudanças externas são frágeis. Para mudar de verdade, Israel precisava humildade. Humildade para admitir desgaste. Humildade para rever o fundamento antes que a aparência de força desmoronasse e revelasse um interior despreparado. Não teve. E acabou no exílio.

O que eu aprendi? Dá para crescer por fora e estar cru por dentro. Dá para confundir influência com maturidade. Dá para achar que movimento é transformação.

O capítulo me chama a parar antes de correr para a próxima saída. Antes de buscar outra estratégia, revisar o centro. Porque prontidão é diferente de parecer pronto.

Este texto compartilha algumas lições importantes para desenvolvedores que pretendem usar OpenClaw para construir agentes com memória e regras próprias.

Comecei a perceber um comportamento errático na Márcia, minha assistente de inteligência artificial. Ela opera sobre o OpenClaw e é responsável, entre outras coisas, por gerar resumos das minhas reuniões a partir das transcrições.

Existe um formato definido para os meus resumos. Um template claro. Sempre o mesmo padrão. Ela começou a ignorá-lo. Importante: quando eu pedia para adotar o template correto, ela refazia o resumo e acertava. Ou seja, o modelo era capaz. Não era limitação cognitiva. Por isso não era catastrófico. Era inconsistência estrutural.

No início, associei o problema a alucinação. Algo próprio do comportamento probabilístico das LLMs. Modelos variam. Oscilam. Nem sempre respondem da mesma forma ao mesmo estímulo.

Mas havia um detalhe que enfraquecia essa hipótese: quando eu reforçava o padrão explicitamente, ela refazia o resumo e acertava. O modelo era capaz. Ficou claro que o erro não estava na inteligência. Estava no contexto. Era engenharia de contexto.

A Márcia se comporta a partir de arquivos-chave no seu workspace. Ali estão suas regras, sua memória e suas diretrizes operacionais.

Optei por manter esse workspace no Git, como código-fonte de uma aplicação. Posso acessar o contexto dela de qualquer lugar, como fazemos com software tradicional. Toda vez que a Márcia altera seus arquivos de memória ou regras, ela faz commit e push para o repositório. Está instruída a operar assim. O contexto dela evolui, mas evolui versionado.

Então fiz o óbvio. Clonei o repositório. Abri o workspace no Cursor. Explorei os arquivos com calma. Fui lendo instrução por instrução. E, aos poucos, o problema apareceu.

Havia instruções conflitantes. Trechos deslocados. Regras sobrepostas. Pequenas incoerências acumuladas ao longo do tempo. Nada dramático isoladamente. Mas suficientes, em conjunto, para gerar comportamento inconsistente.

Não havia nada de misterioso. Havia desorganização estrutural.

O workspace da Márcia sofre do mesmo mal de qualquer código-fonte que evolui sem revisão arquitetural sistemática. As leis de Lehman continuam válidas. Sistemas em evolução tendem a aumentar em complexidade e desordem se não houver esforço deliberado de reestruturação. Agentes não escapam dessas leis.

Eu poderia ter ajustado tudo manualmente, arquivo por arquivo. Não fiz isso.

Escrevi arquivos explícitos de regras que deveriam ser obedecidas pelos agentes no Cursor. Regras persistentes. Porque entendi que esse tipo de desorganização tende a voltar a acontecer. Organização não pode depender de disciplina momentânea. Precisa virar norma formal. Transformei estrutura em contrato.

Depois disso, pedi a um agente no próprio Cursor que analisasse todo o workspace à luz dessas regras, identificasse inconsistências, elaborasse um plano de correção e aplicasse as mudanças. Não corrigi linha por linha. Defini critérios e deixei o agente executar a refatoração. É assim que se programa hoje.

Memórias alinhadas. Contexto limpo. O resumo voltou ao formato correto sem que eu precisasse intervir.

Lições. Trate agentes como software, não como magia. Versione o workspace do seu agente como versiona código-fonte. Formalize regras estruturais antes de corrigir sintomas. Refatore deliberadamente. A complexidade sempre cresce. Teste a hipótese estrutural antes de culpar o modelo. Projete contexto com a mesma disciplina com que projeta código.

Lembre-se: inteligência amplifica estrutura. Se a base está desalinhada, o erro escala.