Janela de contexto grande não é memória: trate contexto como orçamento

O agente não erra só quando falta informação.

Às vezes ele erra de um jeito mais irritante: ele leu quase tudo. Leu a spec, o README antigo, um teste quebrado, uma issue meio abandonada, três arquivos parecidos e aquele comentário de dois anos atrás que ninguém mais deveria levar a sério.

Depois ele entrega uma resposta confiante, cheia de referências corretas, mas com a prioridade errada.

Esse é o ponto que muita gente ainda está digerindo quando fala de janelas de contexto enormes. Colocar mais texto dentro do modelo ajuda, claro. Para investigação, migração, refactor grande e leitura cruzada de repo, isso pode economizar bastante tempo.

Mas "o texto estava na janela" não é a mesma coisa que "o modelo usou aquilo como memória de trabalho confiável".

Para código, essa diferença dói.

Contexto não é memória

Memória de trabalho, no nosso dia a dia, não é só lembrar que algo existe. É conseguir manter intenção, prioridade e restrição enquanto você mexe no problema.

Quando você está corrigindo um bug, não basta saber que existem vinte arquivos relacionados. Você precisa lembrar qual comportamento é contrato público, qual teste descreve o caso real, qual comentário está desatualizado e qual limite de produto não pode ser quebrado.

Um modelo com janela grande consegue carregar muita coisa. O que ele não ganha automaticamente é julgamento sobre o peso de cada pedaço.

É aí que nasce a falsa segurança.

A gente pensa: "beleza, mandei o repo inteiro, agora ele sabe". Só que o agente pode estar misturando documento de onboarding com decisão atual, exemplo antigo com padrão novo, log de erro com hipótese, instrução obrigatória com detalhe opcional.

O problema não é burrice do modelo. É falta de orçamento.

Contexto é orçamento

Quando você trata contexto como orçamento, a pergunta muda.

Não é "cabe mais coisa na janela?".

É "vale gastar atenção do agente com isso agora?".

Essa pergunta parece pequena, mas muda o workflow. Em vez de despejar tudo e torcer, você passa a montar um pacote de trabalho:

• qual é o objetivo;
• quais arquivos precisam ser lidos primeiro;
• qual evidência importa;
• qual saída é aceitável;
• quais partes não devem ser mexidas;
• como a mudança será validada.

Isso não precisa virar burocracia. Na maioria das vezes, uma spec curta resolve melhor do que um prompt enorme.

Algo como:

Objetivo: corrigir o bug em que o botão "Salvar" fica habilitado antes da validação.

Leia primeiro:
- app/components/ProfileForm.tsx
- app/lib/validation/profile.ts
- tests/profile-form.test.ts

Critério de aceite:
- o botão só habilita quando email e nome passam na validação;
- não alterar o fluxo de upload de avatar;
- manter as mensagens de erro atuais.

Validação:
- pnpm test tests/profile-form.test.ts
- pnpm lint

Repara que isso não tenta explicar o sistema inteiro. Ele recorta o problema.

E esse recorte é justamente o trabalho de engenharia que não dá para terceirizar por completo.

Ler demais também tem custo

A janela grande costuma ser vendida como liberdade. Na prática, ela também aumenta a área onde a confusão pode se esconder.

Mais arquivos podem trazer contexto útil. Também podem trazer conflito.

Um README pode dizer uma coisa, o código pode fazer outra, o teste pode estar cobrindo um comportamento legado e a issue pode descrever o desejo de produto, não o contrato atual. Se você joga tudo isso no agente sem hierarquia, ele precisa adivinhar qual verdade vence.

E quando a resposta vem errada, revisar fica mais difícil. Ela parece bem informada. Cita arquivos reais. Usa nomes certos. Propõe uma mudança plausível.

Esse é o tipo de erro que passa no olhar cansado.

O custo invisível de ler demais aparece em alguns lugares:

• latência maior antes de chegar no ponto;
• resposta mais longa do que o necessário;
• plano que tenta agradar todos os sinais do contexto;
• alteração que toca arquivo demais;
• explicação convincente para uma decisão que ninguém pediu;
• revisão humana mais lenta, porque agora você precisa descobrir de onde saiu cada conclusão.

Não é argumento para usar menos IA. É argumento para usar melhor.

O pacote mínimo para um agente trabalhar bem

O fluxo que mais funciona para mim é pensar no agente como alguém rápido, mas sem o histórico emocional do projeto.

Ele não sabe por que aquele módulo ficou feio. Não sabe qual cliente quebrou quando o time tentou limpar a API. Não sabe que aquele teste com nome estranho é o único que protege uma regra importante.

Então o pacote precisa dar direção.

Eu gosto de separar em cinco partes.

Primeiro, a intenção. Uma frase simples: "quero reduzir o tempo de carregamento da tela X sem mudar a API pública". Se essa frase não existe, o agente vai inventar uma.

Segundo, os arquivos obrigatórios. Não precisa listar o repo inteiro. Liste os pontos de entrada e deixe o agente pedir mais se precisar.

Terceiro, a evidência. Pode ser erro de teste, log, print, diff esperado, comportamento atual e comportamento desejado. Evidência é diferente de opinião. "Está ruim" ajuda pouco. "Esse teste falha com timeout depois da chamada Y" ajuda muito.

Quarto, os limites. O que não pode mudar? Qual pasta é fora de escopo? Qual dependência não deve ser adicionada? Qual comando não deve rodar?

Quinto, a validação. O agente precisa saber como provar que terminou. Sem isso, ele tende a encerrar com uma explicação bonita, não com uma evidência revisável.

Esse pacote não deixa o agente perfeito. Mas deixa o erro mais fácil de localizar.

Peça plano antes de pedir patch

Um hábito simples melhora bastante a qualidade: antes de editar, peça um plano curto.

Não um plano de consultoria. Três ou quatro passos bastam.

O plano mostra se o agente entendeu o centro do problema. Se ele começa propondo mexer em arquivo errado, você corta antes do diff. Se ele ignora o teste principal, você corrige o rumo. Se ele quer resolver com refactor grande, você lembra o limite.

Depois do plano, vem o patch.

Depois do patch, vem a evidência.

Essa ordem parece óbvia, mas muita gente pula direto para "faz aí". Aí o agente entrega uma mudança enorme, e a revisão vira arqueologia.

Eu prefiro checkpoints pequenos:

Antes de editar:
- explique quais arquivos pretende alterar e por quê.

Depois de editar:
- mostre o resumo do diff;
- diga quais comandos rodou;
- aponte o risco restante.

Você não precisa controlar cada token. Precisa controlar as decisões.

Handoff precisa virar artefato

Outro ponto importante: conversa não é lugar confiável para guardar decisão de projeto.

Se a tarefa passa de uma sessão para outra, ou se outro dev vai continuar depois, deixe um artefato.

Pode ser um comentário no PR, uma nota em docs/decisions, um arquivo state.md, um checklist na issue ou até um bloco no próprio prompt versionado. O formato importa menos do que a existência de um rastro.

O que não funciona é depender da sensação de continuidade.

"O agente já sabe" é uma frase perigosa.

Talvez saiba. Talvez tenha visto. Talvez tenha perdido a prioridade no meio de duzentos mil tokens. Talvez a próxima sessão não tenha nada da conversa anterior.

Um handoff bom responde:

• o que foi decidido;
• o que foi tentado;
• o que falhou;
• qual arquivo mudou;
• qual comando validou;
• qual dúvida ainda precisa de humano.

Isso vale para agente e vale para gente também.

Ferramenta confiável mostra o caminho

Tem uma lição boa em ferramentas pequenas que rodam localmente no navegador ou em workflows locais de ML: elas costumam deixar claro o que entra, o que sai e onde os dados ficam.

Você cola um SQL, recebe um diagrama. Você aponta para uma pasta de vídeos, gera índice local. O escopo é visível.

Agente de código deveria seguir a mesma disciplina.

Não porque precisa ser limitado para sempre, mas porque trabalho confiável tem fronteira. Entrada clara. Saída esperada. Evidência no final.

Uma ferramenta que promete ler o universo pode parecer poderosa. Uma ferramenta que mostra exatamente como chegou no resultado costuma ser mais útil no dia seguinte, quando você precisa revisar, explicar ou desfazer.

O tradeoff honesto

Janela grande é boa.

Seria estranho negar isso. Muita tarefa que antes exigia pedaços artificiais agora cabe em uma conversa só. Dá para comparar implementação, teste, doc e log sem ficar copiando fragmento o tempo todo.

O problema é usar tamanho como substituto para recorte.

Se o agente precisa investigar um bug espalhado, dê mais contexto. Se ele precisa migrar uma API usada em vários lugares, deixe ele ler mais. Se ele precisa entender uma convenção do repo, mostre exemplos reais.

Mas não transforme cada tarefa em "leia tudo e descubra".

Isso é confortável no começo e caro no final.

O dev continua sendo responsável por dizer o que importa. A IA pode acelerar leitura, escrita, comparação e tentativa. Ela não remove a necessidade de enquadrar o problema.

O takeaway

Quem usa agente bem não é quem enche a janela.

É quem transforma contexto em orçamento.

Pouco desperdício. Intenção clara. Fontes certas. Limites explícitos. Prova suficiente para revisar sem adivinhar.

Contexto grande compra espaço. Não compra memória perfeita.

E, no trabalho real de repo, a diferença entre essas duas coisas é onde mora boa parte da qualidade.

Source notes

• Garrit Franke, "Don't trust large context windows": base para a tese de que janela grande não substitui handoff e recorte.
• Discussão recente no Hacker News: sinal de que a dor é prática entre devs usando agentes e modelos com contexto amplo.
• Gabriel Weinberg, "No, everyone is not using AI for everything": apoio para tratar adoção de IA como cálculo de atrito e confiança.
• SQL->ER diagram tool e workflow local de indexação de vídeos: exemplos de ferramentas com entrada, saída e fronteira operacional mais claras.