Existe uma diferença entre usar IA e usar IA bem. A segunda exige pensar sobre o que você está fazendo — não só no prompt que você escreve, mas na estrutura que você constrói ao redor da ferramenta.

Venho desenvolvendo essa prática nos últimos meses, tanto no trabalho quanto em projetos pessoais. O que aprendi não é sobre qual modelo é melhor ou qual ferramenta tem mais funcionalidades. É sobre como organizar contexto para que a IA seja consistentemente útil — não só na primeira sessão, mas na décima.

O problema que ninguém comenta: contexto que desaparece

Modelos de linguagem não têm memória persistente por padrão. Toda sessão começa do zero. Isso significa que a IA que te ajudou a tomar uma decisão de arquitetura semana passada não sabe nada sobre isso hoje.

No início, eu resolvia isso colando contexto no começo de cada conversa. Funcionava, mas era manual, cansativo e inconsistente — às vezes eu esquecia de incluir algo relevante e a resposta ficava desconectada do projeto real.

O ponto de virada foi entender que o problema de contexto tem duas dimensões:

  1. Contexto estático — o que é o projeto, como está estruturado, quais são as convenções
  2. Contexto dinâmico — o que aconteceu em sessões anteriores, decisões tomadas, feedback dado

Cada um exige uma solução diferente.

CLAUDE.md: contexto estático como código

Todo projeto em que trabalho com IA tem um CLAUDE.md na raiz. É um arquivo markdown que descreve o projeto em linguagem simples — estrutura de diretórios, como rodar localmente, como fazer deploy, convenções de código, o que não fazer.

Quando abro uma sessão em qualquer projeto, esse arquivo é carregado automaticamente. A IA sabe o que é o projeto sem eu precisar explicar.

Isso não é documentação para humanos (é pra isso que serve o README). É contexto para a ferramenta. A distinção é sutil, mas importante: o CLAUDE.md é escrito pensando nas perguntas que a IA vai precisar responder — “onde estão os arquivos de configuração?”, “como funciona esse deploy?”, “o que é esse diretório .k8s/?”.

Na prática, um CLAUDE.md bem escrito elimina a maior parte das perguntas de orientação que eu precisaria fazer no início de cada sessão.

MemPalace: contexto dinâmico e memória entre sessões

O problema do contexto dinâmico é mais difícil. Resolvi com o MemPalace — um sistema de memória local-first integrado ao Claude Code via MCP (Model Context Protocol, um padrão aberto que permite que ferramentas de IA se conectem a serviços e fontes de dados externas).

A ideia é simples: durante uma sessão, a IA pode salvar memórias em arquivos estruturados. Na próxima sessão, essas memórias ficam disponíveis como contexto.

O que considero mais valioso:

Feedback que não se perde. Quando corrijo o comportamento da IA (“não faz assim, faz assado”), isso é salvo. Na próxima sessão, ela já sabe. Não preciso repetir a mesma correção.

Decisões de projeto. “Usamos Recreate em vez de RollingUpdate por causa do SQLite” — esse tipo de decisão contextual, que não é óbvia a partir do código, é armazenada como memória de projeto.

Preferências de trabalho. Coisas como “sempre criar uma branch antes de fazer mudanças”, “prefere commits pequenos e descritivos”, “abre um PR para mudanças não triviais” — isso vira comportamento padrão, não instrução que preciso repetir.

A estrutura que o MemPalace usa é hierárquica: wings (projetos), rooms (tópicos), drawers (memórias individuais). É indexado com busca semântica. Na prática, funciona como uma externalização de memória de trabalho — não a minha, a da IA.

Estrutura de prompt: o que aprendi

Bons resultados com IA dependem mais da estrutura do prompt do que do modelo.

Alguns padrões que funcionam consistentemente:

Contexto antes do pedido. “Estou num projeto Hugo com o tema hugo-trainsh, a branch atual é feat/X, o arquivo relevante é Y. Quero fazer Z.” Funciona melhor do que simplesmente “faz Z” porque elimina ambiguidade sobre o que a IA pode assumir.

Pedidos atômicos com intenção clara. Em vez de “melhora esse código”, prefiro “esse trecho faz X, mas tem o problema Y, quero que você resolva Z mantendo W”. A especificidade da intenção filtra sugestões irrelevantes.

Branch por feature. Não é só disciplina de git — também é um sinal para a IA. Quando digo “cria uma branch pra isso”, estou delimitando o trabalho. O que sai daquela sessão fica contido. Fica mais fácil revisar, reverter ou descartar.

Iteração curta. Prefiro pedir mudanças pequenas e revisar antes de pedir a próxima, em vez de mandar um prompt gigante com dez coisas pra fazer de uma vez. A IA é mais precisa em passos menores — e eu entendo melhor o que foi feito.

Três workflows que valem a pena construir: agentes integrados

O loop síncrono — pedir, a IA faz, revisar, repetir — funciona, mas tem um teto. O próximo nível são agentes autônomos: fluxos onde a IA toma uma série de ações sem precisar da sua entrada a cada passo. Estes são três workflows concretos que valem a pena construir se você trabalha com código regularmente:

Agente de revisão de código automatizado. Para cada PR aberto no Gitea, um agente lê o diff, faz uma revisão focada em problemas reais (não estilo), e comenta diretamente no PR. Não como substituto da revisão humana — como uma primeira passada que pega o óbvio antes de eu precisar olhar.

Agente de documentação. Quando um serviço muda sua API, um agente detecta as mudanças no código e atualiza a documentação correspondente. A coisa mais chata de manter atualizada no dia a dia.

Pipeline de geração de conteúdo assistida. Tenho uma ideia para um fluxo onde eventos externos disparam um agente que coleta dados, estrutura um rascunho, e publica para revisão humana antes de ir ao ar. Uma variante do que faço manualmente hoje, mas automatizada.

O bloqueio atual não é técnico — MCP e as APIs de agente do Claude já suportam isso. É tempo, e precisar de um caso de uso urgente o suficiente pra valer a pena implementar.

O que ainda é promessa

Sendo honesto sobre o que ainda não funciona bem:

Contexto muito longo. Quando uma sessão acumula muita ida e volta — muitos arquivos lidos, muitas edições — a qualidade da resposta começa a cair. O modelo “esquece” o começo. O workaround atual é dividir sessões longas em sessões mais curtas e focadas, mas não é elegante.

Julgamento sobre o que não fazer. IA é boa em fazer o que você pede. É menos boa em dizer “o que você está pedindo é uma má ideia por causa de X”. Às vezes ela aceita a premissa errada e executa perfeitamente uma solução para o problema errado. Isso ainda exige supervisão humana constante.

Estimativa de impacto. “Essa mudança afeta outras partes do sistema?” — ainda é uma pergunta que preciso fazer explicitamente, e a resposta depende de quanto contexto foi carregado. Não é automático.

O que realmente mudou

Não uso IA pra escrever código por mim. Uso para acelerar partes do trabalho que não são onde meu valor está — boilerplate, scaffolding, traduções, formatação, busca em arquivos que não conheço bem.

O trabalho que importa — entender o problema, tomar decisões de arquitetura, revisar o que foi gerado — continua sendo meu. Mas eu faço mais em menos tempo porque a parte mecânica é delegada.

O insight que mais ficou: IA só é tão boa quanto o contexto que você dá a ela. Investir em CLAUDE.md bem escritos, memórias estruturadas, prompts claros — isso não é overhead. É o trabalho que torna a ferramenta consistentemente útil, em vez de impressionante na primeira vez e frustrante na décima.

A maioria das pessoas ainda usa IA como um motor de busca: uma pergunta, uma resposta, sem continuidade. A distância entre isso e um workflow estruturado não é técnica. É só prática — e ela se acumula.