Cinco Primitivas para Compor com IA

TV
Thiago Victorino
7 min de leitura
Cinco Primitivas para Compor com IA
Ouvir este artigo

Eugene Yan publicou em maio de 2026 um post curto com um título enganosamente simples: “How to Work and Compound with AI.” Dentro dele há uma prática de cinco passos com nomes de primitivas que mapeiam disciplinas operacionais que a maioria dos times ainda não construiu. Forneça bom contexto. Codifique gosto como config. Facilite verificação. Delegue tarefas maiores. Feche o loop.

O vocabulário importa. Quando você nomeia uma primitiva, ela vira algo passível de dono, agenda e auditoria. O inverso também vale: o que você não consegue nomear, você não consegue operar.

Leia a lista do Yan uma vez e provavelmente vai concordar com três das cinco. Engenharia de contexto está no ar. Harnesses de verificação são comuns. Delegação de tarefas maiores (edições multi-arquivo, planejamento, revisão de código) é o que todo agente de coding já vende. Essas três são as que as organizações já estão construindo.

As outras duas são as que estão ficando para trás.

Os dois elos operacionais que quase todos os times pulam

Codifique gosto como config. O enquadramento do Yan é operacional: “cada correção atualiza uma config que reduz erros futuros.” Gosto não é traço de personalidade do engenheiro sênior. É artefato escrito. Style guide, convenção de nomes, regra de segurança, voz da marca, padrão de refactor. O output do agente corrigido vira input da configuração que evita a mesma correção na próxima rodada.

A maioria dos times trata gosto como tácito. O revisor sênior conserta as mesmas cinco coisas em todo PR de agente e nunca escreve nenhuma delas. Isso não é processo de revisão. É imposto.

Feche o loop. Yan de novo: “cada artefato finalizado vira contexto para a próxima sessão.” Fechar o loop não é ritual de retrô. É operação de engenharia de contexto. O plano, o diff, a execução que falhou, o output corrigido, a nota de rollback: tudo isso vira o corpus inicial para o próximo plano.

A maioria dos times trata o loop como reunião. Forma errada. O loop é uma operação de escrita na memória de trabalho do agente.

Essas são as duas primitivas que transformam um chatbot bonito em um sistema que compõe. Sem elas, toda sessão recomeça do zero. Com elas, cada correção encolhe a próxima correção.

Por que a literatura existente sobre contexto não as nomeia

Os playbooks do Azure SRE Agent e do Manus (já escrevemos sobre os dois) descrevem arquiteturas de contexto brilhantes: higiene de KV-cache, espaços de ação hierárquicos, planos externalizados, sistema de arquivos como contexto estendido. Eles te dizem como carregar, paginar e comprimir. Não te dizem como o gosto entra no sistema nem como artefatos voltam para ele.

Isso é feature, não bug, daqueles documentos. Eles descrevem comportamento de uma sessão. Yan descreve o loop multi-sessão. As duas visões são complementares, não competidoras. Você precisa do gerenciamento estilo RAM do Azure para manter uma sessão sã. Você precisa do fechamento de loop do Yan para fazer a próxima sessão ser mais inteligente que a anterior.

Se você leu nossos posts anteriores sobre engenharia de contexto e sentiu que algo ainda faltava, é isso que faltava. As primitivas que conectam sessões.

Gosto codificado como config: o que isso é, na prática

Cinco formas concretas que vimos funcionar:

  1. Arquivos de estilo. Estilo de código, estilo de prosa, estilo de nomenclatura. Versionados, commitados, carregados no contexto do agente como parte das instruções de sistema.
  2. Playbooks de refactor. “Quando ver padrão X, proponha Y.” Escrito a partir das correções que o revisor sênior repete.
  3. Regras de voz da marca. Enquadramento positivo, palavras banidas, termos em watchlist. Escrito a partir das rejeições do marketing.
  4. Regras de segurança. Dependências permitidas, APIs banidas, manuseio de segredos. Escrito a partir da lista vermelha do time de segurança.
  5. Regras de domínio. “Cliente X usa termo A, não termo B.” Escrito a partir dos transcripts de suporte onde o agente errou.

A disciplina não é escrever as regras uma vez. É escrever a regra no momento em que a correção acontece. Todo comentário de PR que diz “aqui a gente não faz assim” é uma escrita de config que não aconteceu. Multiplique por 200 PRs por mês e você tem o custo do gosto não codificado.

Teste operacional: quando um engenheiro novo entra, o agente consegue fazer o onboarding lendo as regras? Se sim, gosto está codificado. Se não, gosto vive em cabeças, e cada cabeça que sai leva embora as regras que carregava.

Fechamento de loop: o que isso é, na prática

A forma é prosaica, e é por isso que as pessoas pulam.

Depois de toda execução relevante de agente, três artefatos voltam para um lugar conhecido:

  1. O plano que foi seguido (ou modificado no meio do caminho).
  2. O diff ou output produzido.
  3. As correções aplicadas pelo revisor humano.

Mais um, frequentemente esquecido: a nota de rollback ou retrabalho. Se o artefato teve que ser desfeito, por quê? Registrar rollbacks evita que a próxima sessão reconstrua, com confiança, a mesma coisa quebrada.

Esses quatro artefatos alimentam a próxima sessão. Não como “memória” vaga. Como contexto carregado. O agente que inicia a próxima sessão lê os últimos cinco planos, as últimas cinco notas de rollback e os arquivos de config ativos. A sessão começa com o resíduo da sessão anterior já na memória de trabalho.

É isso que “compor” significa no enquadramento do Yan. Não é digitação mais rápida. É ponto de partida mais afiado.

Onde isso conecta com governança

As duas primitivas puladas são também as duas sobre as quais auditores eventualmente vão perguntar.

Gosto codificado é o artefato que um regulador pode revisar para entender “o que esse time entende por qualidade?” Se sua resposta é “pergunte para a Sara”, você está a uma demissão da Sara de perder seus padrões.

Fechamento de loop é o artefato que prova que o sistema aprendeu com seus erros. Todo regime de governança que importa (SOX, SOC 2, as próximas ondas de fiscalização do EU AI Act) quer evidência de ação corretiva. “A gente consertou a mesma coisa 50 vezes em 2026” não é registro de ação corretiva. “Codificamos a correção como config no terceiro dia e a taxa de erro caiu para zero” é.

Os times que pulam essas primitivas não estão só perdendo eficiência. Estão acumulando dívida de auditoria.

Faça isso agora

Escolha um workflow de agente em curso. Revisão de código, redação de conteúdo, drafts de e-mail para clientes. Qualquer coisa onde um humano fica corrigindo a saída do agente.

Pelas próximas duas semanas, faça duas coisas:

  • Toda correção vira escrita de config. Abra o arquivo de instruções do agente. Adicione a regra. Commit. Recarregue o agente.
  • Todo artefato finalizado é logado. Plano, output, correções, notas de rollback. Uma pasta. Um arquivo por execução.

No fim da segunda semana, conte dois números: quantas vezes a mesma correção repetiu (deve tender a zero), e quantas vezes a sessão nova fez uma pergunta já respondida no log (também deve tender a zero).

Se nenhum dos dois números está caindo, você não fechou o loop. Você só adicionou uma pasta.

As cinco primitivas não tem dificuldade igual. Contexto, verificação e delegação são problemas de ferramental. Gosto codificado e fechamento de loop são problemas de disciplina. Ferramenta você compra. Disciplina você instala.


Fontes

A Victorino ajuda equipes a operacionalizar as duas primitivas mais ignoradas: gosto codificado e fechamento de loop: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa