- Texto apresenta princípios de engenharia de contexto e um fluxo de trabalho prático para obter resultados com modelos de linguagem atuais em codebases de produção de grande porte
- O ponto central é a Frequent Intentional Compaction, que estrutura e comprime o contexto ao longo de todo o processo de desenvolvimento para estabilizar a qualidade de julgamento e a trajetória do agente
- Em 3 etapas — pesquisa → planejamento → implementação — cria artefatos de pesquisa prévia e documentos de plano, e posiciona a revisão humana em pontos de alta alavancagem para reduzir slop e retrabalho
- Na prática, mostra em uma codebase Rust de 300 mil LOC, a BAML, casos em que conseguiu realizar em pouco tempo tarefas complexas como correção de bugs e suporte a cancelamento/WASM, provando a eficácia também em ambientes brownfield
- Conclui que AI coding não é um brinquedo, mas um tipo de artesanato de engenharia sofisticado, e que a mudança de processo/cultura no nível da equipe é a chave da vantagem competitiva
Contexto: limites da IA em codebases complexas e a motivação do problema
- A maioria dos desenvolvedores já sabe bem que ferramentas de AI coding não funcionam tão bem quanto o esperado em codebases reais de produção
- Existem pesquisas mostrando que ferramentas de AI coding reduzem a produtividade em codebases grandes e em tarefas complexas
- Segundo uma pesquisa de Stanford, boa parte do código adicionado por ferramentas de IA acaba gerando trabalho repetitivo, no formato de revisar novamente código insuficiente previamente gerado pela própria IA
- Agentes de AI coding são eficazes em projetos novos ou mudanças pequenas, mas em codebases grandes podem até reduzir a produtividade do desenvolvedor
- Por isso, a reação comum no mercado costuma ser cautelosa: “agora é difícil, quando saírem modelos mais inteligentes”
- Mas, ao aplicar engenharia de contexto em uma grande codebase Rust real de 300.000 LOC, foi possível superar o nível de mercado tanto em produtividade quanto em qualidade usando apenas modelos já existentes
- O ponto-chave é a compactação intencional frequente (frequent intentional compaction), isto é, manter ao longo do desenvolvimento um contexto estruturado e gerenciado para a IA
- No fim, ‘AI coding’ é uma área que exige artesanato técnico
Base conceitual: “Specs are the new code” e pesquisas sobre produtividade
- Duas apresentações no AI Engineer 2025 levaram a uma mudança de mentalidade
- Na apresentação Sean Grove's "Specs are the new code", ele defende abandonar prompts conversacionais e preservar especificações como código
- Abandonar os prompts e commitar apenas o código gerado é comparado a fazer check-in só do binário, sem o código-fonte
- Estudo de Stanford sobre o impacto da IA na produtividade dos desenvolvedores sugere que, mesmo aumentando a produção no curto prazo, a IA pode ter seu efeito líquido reduzido por queda de qualidade e retrabalho
- Ao analisar commits de 100 mil desenvolvedores, o estudo observou que ferramentas de IA aumentam retrabalho e podem anular o ganho de produtividade
- A visão proposta é que elas funcionam bem em greenfield, mas frequentemente têm efeito contrário em brownfield e em tarefas de alta dificuldade
Princípio: o conceito de Frequent Intentional Compaction
- O contexto é mantido sempre entre 40–60% da janela, adotando uma estratégia contínua de compressão para minimizar excesso de conteúdo, omissões e informações erradas
- O que se comprime é o ruído de logs de busca de arquivos, rastreamento de fluxo de código, histórico de mudanças, logs de teste/build, JSONs grandes etc.
- Os artefatos gerados em cada etapa são preservados como artefatos estruturados, garantindo a qualidade da entrada do turno seguinte
- Ex.: criar um documento de progresso com resumo do andamento, objetivos e abordagem, etapas concluídas e o ponto atual de falha
Fluxo de trabalho: Research → Plan → Implement
- Na etapa de Research, investiga arquivos relacionados, fluxos e hipóteses de causa, produzindo um documento resumido de pesquisa
- Quando necessário, usa subagentes para explorar escopo e resumir em um contexto novo
- Na etapa de Plan, escreve um plano de implementação detalhando os arquivos a alterar, a forma da mudança e os procedimentos de validação e teste
- O plano é usado como ponto de revisão de alta alavancagem, mais do que o code review em si
- Na etapa de Implement, executa o plano por etapas e, após validar cada fase, recompacta o estado no documento de plano, acumulando o progresso
- Em tarefas complexas, faz realinhamento de contexto a cada ponto de convergência entre etapas
Antipadrões e amadurecimento gradual
- A abordagem ingênua expõe o problema de um contexto contaminado no fluxo de chat, levando a ciclos de desculpas ou desvios
- Um método um pouco melhor é reiniciar a sessão e adicionar “prompts de instrução”, mas isso ainda não resolve o controle fundamental do ruído
- A compressão intencional é uma forma melhor de reconstruir o contexto usando resumos de progresso (em arquivo) e mensagens de commit
- O texto apresenta um exemplo de formato ideal de artefato de compressão, com meta de otimizar precisão/completude/tamanho/trajetória
Visão técnica da otimização de contexto
- Como LLMs são funções sem estado, a qualidade depende inteiramente do contexto de entrada
- A ordem do pior cenário é informação errada > omissão > excesso de ruído
- Quanto menor o contexto, melhor; por isso, a chave é comprimir para obter máxima consistência com entrada mínima
- Também menciona perspectivas alternativas, como estratégias simples de execução de agente em loop (ex.: processo “Ralph”)
Papel dos subagentes: não é roleplay humano, é controle de contexto
- Subagentes executam busca/resumo/organização em contextos independentes, mantendo limpa a janela do agente principal
- A resposta ideal volta no formato de um artefato compactado e estruturado com objetivo/status/caminho
- Com subagentes, o custo de exploração fica localizado, aumentando o foco do contexto principal de trabalho
Caso 1: correção de bug no BAML aprovada de primeira
- Em BAML, uma codebase Rust de 300 mil LOC, é mostrado o caso de uma pessoa recém-chegada que enviou e teve aprovada em poucas horas uma PR de correção de bug
- A qualidade foi elevada ao iterar várias vezes sobre o documento de pesquisa, e a implementação baseada no plano final passou de primeira
- O caso atende boa parte dos objetivos em adequação a brownfield, eliminação de slop e manutenção do alinhamento
Caso 2: 35k LOC para suporte a cancelamento/WASM no BAML
- Duas pessoas demonstraram uma grande mudança adicionando recurso de cancelamento e suporte a compilação para WASM em 7 horas
- Pela estimativa da equipe, era um trabalho de 3–5 dias para cada item, encurtado pelo pipeline de pesquisa/planejamento/implementação
- Algumas PRs foram mescladas imediatamente; outras permaneceram abertas no nível de demo funcional, demonstrando a possibilidade de resolver tarefas muito difíceis
Limites e aprendizado com falhas
- A tentativa de remover a dependência de Hadoop no Parquet Java ficou como caso de fracasso por investigação insuficiente da árvore de dependências
- Conclusão: nem todo problema se resolve com 7 horas de prompting, e a participação de um especialista de domínio é necessária
- A alavancagem da revisão humana cresce na ordem pesquisa > plano > código, e uma linha errada na pesquisa pode se expandir para milhares de linhas de erro
Prioridade para documentação no alinhamento da equipe
- O texto propõe a visão de que a essência do code review está em manter o alinhamento mental (mental alignment)
- Uma sequência de PRs grandes pode causar perda de entendimento do produto e ansiedade na equipe, então specs/planos/pesquisa reduzem o custo de alinhamento
- Engenheiros conseguem ler um documento de plano de 200 linhas com mais frequência e precisão do que 2 mil linhas de código
- Mesmo ao lidar com issues em áreas desconhecidas, um prompt de pesquisa pode servir como guia rápido
Resumo geral e estrutura de custos
- Todos os objetivos foram atendidos: compatibilidade com brownfield, resolução de problemas complexos, minimização de slop e manutenção do alinhamento da equipe
- Do ponto de vista de custo operacional, uma equipe de 3 pessoas opera com custo mensal de tokens do Opus em torno de US$ 12 mil
- Ressalta que há exceções, mas que, no geral, trata-se de uma metodologia que funciona
Mudanças futuras e productização
- Agentes de coding vão virar commodity, e a verdadeira dificuldade está na transformação organizacional e de workflow
- Em um mundo em que a IA escreve 99% do código, a reforma total da forma de colaboração será o ponto de inflexão da competitividade
- Para apoiar isso, foi lançado em beta privado o “pós-IDE” chamado CodeLayer
- A proposta é ser o Superhuman for Claude Code e acelerar o desenvolvimento agêntico spec-first
3 comentários
Encerrando a publicidade...
Encerrando com a apresentação de um serviço chamado CodeLayer...
Comentários do Hacker News
Foi uma leitura interessante e havia ideias originais. Mas acho que esse tipo de afirmação tem problemas. Sean previu que a IA vai evoluir a ponto de, no futuro, documentos de especificação virarem o código de verdade. A afirmação é que, dentro de 2 anos, as pessoas vão abrir arquivos Python em IDEs com a mesma frequência com que hoje alguém abre um editor hexadecimal para olhar assembly. Ele diz que no começo isso foi desconfortável, mas que acabou aceitando focar nos testes em vez de ler linha por linha do código em PRs, tratando a especificação como a fonte real. Porém, por causa do problema de não determinismo dos LLMs, não dá para esperar sempre uma implementação razoável, por melhor que seja o prompt. Compiladores são determinísticos e, mesmo quando têm bugs, dá para reproduzir e depurar; com LLMs não é assim
Mesmo trabalhando com desenvolvedores juniores, a implementação é determinística até certo ponto. Já com modelos de IA, mesmo dando instruções claras, surgem repetidamente implementações completamente diferentes
O engraçado é que, na verdade, o próprio documento de especificação já é não determinístico. Se você tentar escrever requirements em inglês de forma que ninguém possa interpretar errado, no fim aquilo vira uma linguagem de programação
Concordo com a preocupação de que “o prompt pode ser perfeito, mas nem assim há garantia de que o LLM o transforme numa implementação razoável”. Na verdade, prompts escritos em linguagem natural muitas vezes são inerentemente ambíguos e incompletos. Por isso, é uma boa direção quando se quer um resultado criativo, mas, se linguagem natural fosse adequada para definir requisitos de software, a engenharia de software já teria resolvido isso décadas atrás. Fiquei empolgado com LLMs, mas acho exagero tentar resolver tudo com isso. Em termos de especificação de requisitos, isso parece algo semelhante aos antigos sistemas formais e tentativas de verificação matemática, só que no extremo oposto. Mesmo que também termine em fracasso parcial, vejo isso como um experimento que pode trazer novos insights sobre desenvolvimento de software. Em alguns domínios vai gerar valor real, em outros pode ser completamente descartado. Tempos interessantes
Na prática, quase ninguém escreve especificações ou documentação técnica claras e detalhadas. E, mesmo quando existem, não me parece que isso vá se popularizar em 2 anos. Um redator técnico que realmente entende software em profundidade ficaria satisfeito em não olhar o código e apenas passar prompts para um agente de IA? Eu não concordo. Isso se aproxima da típica mentalidade de “engenheiros tratando pessoas como máquinas”
A afirmação de que “graças aos compiladores você não precisa olhar assembly em um editor hexadecimal a cada build” também depende de ferramentas melhores, claro, mas na prática, em pesquisa científica de HPC, era comum inspecionar assembly diretamente com Intel VTune e afins para verificar se o compilador realmente vetorizou os loops críticos
Já usei esse padrão em dois codebases diferentes. Um era um grande repositório monolítico de apache airflow com 500 mil linhas, e o outro era um projeto pessoal em flutter começado do zero. Eu realmente não conhecia flutter nem dart. Mesmo assim, senti que esse método funcionava. Em projetos greenfield, quase bastava rodar /create_plan e aproveitar todo o suporte do agente. O importante é revisar com cuidado os documentos que a IA produz. Basta verificar você mesmo se ela cobriu os edge cases que te preocupam, e se as escolhas técnicas fazem sentido. Por exemplo, você percebe na hora se há uma decisão ruim, como quebrar um padrão de sqlite e recomendar postgres. Em geral, dá para ajustar o plano imediatamente conversando com o agente. No trabalho, eu precisava usar GitHub Copilot, então tive de escrever os prompts de outra forma, mas ainda faço resumos deliberados entre etapas. O Copilot não suporta subagentes como o Claude Code, mas ainda assim a produtividade se mantém razoavelmente bem.
Também queria compartilhar uma experiência pessoal. Pouco antes da era do suporte de IA para programação, eu estava bem deprimido porque sentia que meu trabalho estava ficando chato demais. Trabalhar em grandes codebases, com vários repositórios, equipes e estilos de pessoas, sempre vinha cheio de tarefas tediosas. O melhor da programação com IA foi justamente lidar com essas pequenas tarefas de forma fluida. Eu sinto muita realização em construir algo que funciona bem, mas repetidamente essa alegria sumia por causa dessas miudezas. Agora consigo entregar bons resultados com consistência, e me sinto orgulhoso de mim mesmo
Eu criei um pacote que uso para trabalhar em grandes codebases: [GitHub.com/iambateman/speedrun]. Primeiro, com /feature, eu insiro a descrição da funcionalidade, ele começa a analisar o codebase e faz perguntas. Quando respondo, ele escreve um plano em markdown. Nesse processo surgem de 8 a 10 arquivos markdown, com o que deve ser feito e até exemplos de código. Depois vem uma etapa de “code critic”, que tenta encontrar erros, mas na verdade erra em uns 60% dos casos. Eu filtro os erros sem sentido desse feedback. A essa altura, já existe uma pasta limpa com as mudanças que eu quero e a descrição da funcionalidade. Aí basta dizer ao Claude Code “pode prosseguir” e ele começa a trabalhar em etapas. Esse método evita que as coisas saiam do rumo e me dá confiança no resultado. Uso esse workflow várias vezes por dia em tarefas grandes, e, para trabalhos relativamente específicos, uso só o Claude Code normal. Acho um workflow bem eficiente
Eu realmente não entendo por que alguém gostaria de passar por um processo tão complicado. Acho que programar normalmente, usando LLM só como apoio leve, é mais produtivo do que isso
O grande problema de usar LLM em codebases grandes é que ele repete os mesmos erros. Tenho curiosidade de saber como você acompanha continuamente as decisões de arquitetura no contexto de cada tarefa
Parece muito legal. Há uma etapa intermediária de pseudocódigo, e fiquei curioso se definir previamente o workflow ou processo realmente ajudou. Também ouvi dizer que é importante manter cada arquivo com menos de 100 linhas; queria saber se você teve uma impressão parecida
Este texto parece uma cápsula do tempo do momento em que eu desisti completamente de gerenciar contexto no meu Claude Code. Eu criava especificações separadas em pastas para cada parte do código e mantinha logs por funcionalidade. Gerenciei vários subsistemas de um servidor de API em Python, como contas, notificações e assinaturas. À medida que a situação ficava mais complexa, o Claude deixou de entender corretamente a lógica de negócio, e o gerenciamento de contexto ficou extremamente difícil. Por exemplo, quando eu queria construir um sistema simples de RBAC, precisava fornecer até diagrama UML e exemplos explicando a relação entre conta e perfil para que ele ao menos se comportasse mais ou menos como eu esperava
Há muitas declarações e afirmações sobre uso de IA, mas quase ninguém publica o processo concreto ou os prompts. Falar de forma convincente é fácil; para ser realmente útil, é preciso deixar o log dos prompts. Commits gerados por IA também deveriam incluir um registro de quais prompts foram aplicados, para que, assim como examinamos o log de commits, possamos acompanhar diretamente o log de prompts e entender como o código foi escrito
O autor se gaba de ter pesquisado e implementado 35 mil linhas de código em 7 horas, mas na prática há 40 commits ao longo de 7 dias. Fico me perguntando se ele trabalhou só uma hora por dia. E é engraçado que um dos commits mais recentes seja “ignorar alguns testes”
Havia uma frase dizendo: “Algumas semanas depois, junto com @hellovai, adicionamos 35k LOC ao BAML para introduzir suporte a cancelamento e compilação WASM. A equipe original estimava que cada recurso levaria de 3 a 5 dias”. Então eles estavam assumindo que um engenheiro sênior escreveria de 4 a 6 mil LOC por dia? (antes do genAI?)
O fato omitido aqui é que um engenheiro sênior provavelmente teria resolvido isso com apenas 2 mil LOC
E, na verdade, o próprio autor admite em outro lugar que esse trabalho levou uma semana https://news.ycombinator.com/item?id=45351546
Concordo totalmente com a parte de “no começo foi desconfortável, mas desisti de ler todo o código do PR e passei a verificar só os testes com cuidado. A especificação virou a fonte real”. Sinto que nosso papel está migrando de escrever diretamente os detalhes de implementação para definir e validar o comportamento. Recentemente, precisei adicionar upload recursivo a um operator Python de S3-to-SFTP, e havia muitos flags de caminho complicados. Meu processo foi o seguinte: 1) extrair o comportamento existente em uma especificação clara, isto é, fazendo os testes unitários passarem 2) expandir a especificação para a nova funcionalidade 3) passar o problema e os testes para o agente de código. No fim, percebi que eu não precisava entender o código antigo em absoluto. Meu foco era apenas se o novo código seguia corretamente a especificação. No futuro, nosso valor estará em verificar a correção; o código em si será um detalhe com o qual os agentes vão lidar sozinhos
Concordo com “nosso papel está migrando de escrever detalhes de implementação para definir e validar comportamento”. Na verdade, dá até para dizer que esse sempre foi o trabalho principal. Graças a linguagens de alto nível, compiladores e outras abstrações, o tempo gasto escrevendo detalhes de implementação vem diminuindo continuamente
A frase “meu foco era apenas se o novo código funcionava conforme a especificação” me lembra a Lei de Postel (Postel's Law). O comportamento observado de sistemas amplamente usados acaba se tornando de fato a interface pública e a especificação do sistema, incluindo todos os defeitos e erros de implementação. Também é preciso testar se o lado cliente do código realmente segue bem a especificação e, se houver desvios, detectá-los e tratá-los
Claude Plays Pokemon mostrou a mesma coisa. A IA é fraca para julgar se algo está funcionando bem; ela tende a ficar andando em círculos. Mas, se um humano corrige a direção de tempos em tempos, a combinação pode ser poderosa
Se você tentar definir todos os aspectos do comportamento de verdade, no fim estará praticamente escrevendo quase todo o código. Se houver uma única linha no PR cujo significado você não entenda imediatamente, provavelmente você não definiu o comportamento completo o suficiente
Houve a afirmação de que “nos próximos anos, documentos de especificação virarão o código real, e quase não haverá motivo para abrir arquivos Python”. Para isso se concretizar, a geração de código por IA teria de ser 99,9% correta, com alucinações quase inexistentes. Nós confiamos em compiladores e não olhamos assembly porque temos certeza de que o resultado será sempre o mesmo e sem erros (há bugs ou problemas de otimização raramente, mas quase sempre são corrigidos de uma vez). Hoje, se o código gerado por IA se comporta de modo diferente da especificação, isto é, do código original, no fim uma pessoa ainda precisa corrigir
Fiquei muito impressionado com a dica de dividir a implementação e tratá-la ou revisá-la por unidade de trabalho.