O mercado adora janelas de contexto gigantescas nos modelos de linguagem. Existe uma crença de que adicionar dados produz respostas precisas. Projetos reais de software mostram o oposto disso: injetar repositórios massivos no prompt causa saturação. Observando isso, pesquisadores da Chroma nomearam essa degradação de Context Rot em 2025. Ou seja, modelos de inteligência perdem o foco em conversas demoradas. Informações obsoletas gastam espaço escasso na memória de trabalho. O que leva a gente a pensar que aumentar o limite de tokens apenas mascara a desorganização primária da equipe.
Processar arquivos inúteis em todas as requisições torna a operação proibitiva sob restrições de custo corporativo. A gente gasta recursos computacionais para que a máquina leia códigos que não serão alterados. Evitando assim o excesso de dados, que não gera inteligência. Gera ruído e lentidão.
A logística do canteiro de obras
Considere a logística de um grande canteiro de obras. Imagine receber todo o material de uma obra nova de uma só vez no primeiro dia. Tijolos, sacos de cimento e vigas de aço acumulados bloqueariam a movimentação dos operários. Instruções de módulos distantes bloqueiam a leitura das regras de negócio atuais.
O excesso de dados não gera inteligência; gera ruído e lentidão.
Sobrecarga cognitiva afeta o desenvolvedor e o modelo. O profissional precisa revisar códigos gerados em meio a alucinações causadas por dados desconexos. Redesenhar o fluxo de trabalho exige separar o estoque de materiais da mesa de trabalho. A ideia é que o prompt receba apenas o necessário para a ação imediata.
A fundação técnica do fluxo
Piyush Bhargava, meu colega de Thoughtworks, encontrou gargalos operacionais parecidos nos clientes da empresa. Ele publicou um artigo técnico em dezembro de 2025 detalhando soluções. O material explica a aplicação do Spec-Driven Development em bases legadas. Depois, publicou outro artigo sobre o framework que pensou para resolver esse problema (ARCUS). Esse framework obriga a definição de requisitos antes da programação inicial. Desenvolvedores precisam resolver ambiguidades logo nos primeiros estágios.
Utilizamos essa abordagem para limpar o caminho antes da automação. O foco sai da escrita frenética de código e passa para a definição do que deve ser construído. Precisamos de filtros que barrem o ruído antes mesmo de o modelo processar o comando.
A divisão do contexto na prática
Piyush pensou no framework que chamou de ARCUS. A gestão de contexto no ARCUS funciona como um filtro de duas etapas.
Vamos pensar em um bug que precisamos corrigir em um cálculo de imposto em um checkout de e-commerce.
1 - A primeira camada (construída em uma etapa inicial de bootstrap e posteriormente atualizada por um fluxo de detecção de desvios e reconciliação após a conclusão de cada ciclo de SDLC) reside na pasta .context/ do repositório.
Ela guarda o mapa do sistema e as capacidades de negócio mapeadas. O arquivo repo_map.md funciona como a planta técnica do prédio.
No caso do e-commerce: ele indica que a lógica de impostos mora no diretório /services/tax-engine. Já o repo_scope.md é o dicionário de regras de negócio. Essa camada confirma que o software tem a capacidade de cálculo de tributos retidos. IA usa isso para saber onde as coisas estão sem precisar ler o código todo.
2 - A segunda camada (construída como parte da especificação da story) foca na tarefa imediata. Nesse caso, a correção do bug.
Ela contém o Story Context. Este é um recorte cirúrgico dos dados. O agente de especificações (Specify) identifica a intenção de corrigir o imposto.
Ele busca no nível anterior apenas os ponteiros para os contratos financeiros e regras tributárias. Módulos de logística ou avaliações de produtos permanecem ocultos. Assim, a gente alimenta a máquina com o sinal exato da tarefa.
O canteiro de obras sob controle
O ARCUS resolve o problema do material desordenado de forma mecânica. A logística funciona como a de uma pessoa que coordena as entregas no canteiro de obras. Esta pessoa garante que o cimento e os tijolos cheguem apenas no dia da fundação. Materiais pesados como as vigas de aço ficam no depósito e só aparecem quando a estrutura do andar exige.
A ideia é que a organização impeça o depósito desordenado de insumos. O framework atua como esse filtro logístico que libera a peça certa para o momento atual. Ele impede que as instruções de todo o projeto sufoquem o operário no início da construção. Dessa maneira, a IA recebe apenas o sinal necessário para o trabalho de agora. O canteiro permanece limpo e o fluxo de execução segue sem obstáculos físicos ou informacionais.
Design organizacional e manutenção
Manter o contexto exige disciplina coletiva. O mapa do sistema não deve ser um artefato esquecido em um canto do repositório. Tratar a engenharia de contexto como parte da arquitetura de longo prazo é o diferencial. Com isso, o time gasta menos tempo corrigindo alucinações da IA. A gente cria uma estrutura onde o conhecimento institucional é versionado e acessível.
Arquivos de configuração precisam abandonar o formato de tutoriais longos. Textos base devem apenas apontar direções curtas. A governança desses metadados garante que a automação não se torne um fardo técnico no futuro.
A instrução como mapa
Diversas plataformas utilizam mecanismos próprios para carregar ordens. Algumas IAs utilizam configurações locais no sistema de arquivos. Outras aceitam parâmetros em painéis administrativos. Aprendemos que regras estáticas falham diante de ecossistemas corporativos legados instáveis.
Substituir manuais inteiros por índices muda o comportamento do modelo. A ferramenta passa a rastrear caminhos curtos ao invés de processar parágrafos. Limitar as opções entregues diminui os erros na hora de gerar código. A ideia é que referências exatas permitem abrir dados no instante da necessidade.
Menos leitura e mais foco
Com a engenharia de contexto, impõem-se limites práticos aos assistentes de programação. Diretrizes teóricas perdem a validade diante do sistema real operando. O foco na entrega técnica exige que a gente pare de lutar contra a saturação do prompt. No final, dominar essa orquestração intelectual devolve o controle aos times de engenharia. A gente para de esperar milagres da tecnologia e volta a projetar software de verdade. O diferencial está na capacidade de dar a IA o sinal correto.
Separating noise from signal for your AI: strategies to clean context and focus on technical delivery
The market loves gigantic context windows in language models. There is a belief that adding data produces precise answers. Real software projects show the opposite: injecting massive repositories into the prompt causes saturation. Observing this, Chroma researchers named this degradation Context Rot in 2025. In other words, intelligence models lose focus in lengthy conversations. Obsolete information wastes scarce space in working memory. This leads us to think that increasing token limits merely masks the primary disorganization of the team.
Processing useless files in every request makes the operation prohibitive under corporate cost constraints. We waste computational resources so the machine reads code that will not change. That means excess data does not generate intelligence. It generates noise and slowness.
The logistics of the construction site
Consider the logistics of a large construction site. Imagine receiving all the material for a new build at once on the first day. Accumulated bricks, cement bags, and steel beams would block the movement of workers. Instructions from distant modules block the reading of current business rules.
Cognitive overload affects the developer and the model. Professionals need to review generated code amidst hallucinations caused by disconnected data. Redesigning the workflow requires separating the material stock from the workbench. The idea is that the prompt receives only what is needed for immediate action.
The technical foundation of the flow
Piyush Bhargava, my colleague at Thoughtworks, found similar operational bottlenecks in the company’s clients. He published a technical article in December 2025 detailing solutions. The material explains the application of Spec-Driven Development in legacy codebases. Later, he published another article about the framework he designed to solve this problem (ARCUS). This framework forces requirement definition before initial programming. Developers must resolve ambiguities early in the first stages.
We use this approach to clear the path before automation. Focus shifts from frantic code writing to defining what must be built. Teams require filters that block noise even before the model processes the command.
Context division in practice
Piyush designed the framework he called ARCUS. Context management in ARCUS operates as a two-step filter.
Let us think about a bug we need to fix regarding tax calculation in an e-commerce checkout.
The first layer (built as a bootstrap step and later refreshed as a drift detection and reconcile workflow after every SDLC cycle completion) resides in the .context/ folder of the repository. It stores the system map and mapped business capabilities.
File repo_map.md is the technical floor plan of the building. In the e-commerce scenario, this document indicates that tax logic lives in the /services/tax-engine directory. Meanwhile, repo_scope.md is the business rule dictionary. This file confirms the software has the retained tax calculation capability. AI uses this to know where things are without reading the entire code.The second layer (built as part of the story specification) focuses on the immediate task. In this case, the bug fix. It contains the story context.
This represents a surgical data selection. The specifications agent, Specify, identifies the intention to fix the tax. The tool searches the previous level only for pointers to financial contracts and tax rules. Logistics modules or product reviews remain hidden. In other words, we feed the machine with the exact signal of the task.
The construction site under control
ARCUS resolves the messy material problem mechanically. Logistics operates like a person coordinating deliveries at the construction site. This professional ensures cement and bricks arrive only on foundation day. Heavy materials like steel beams stay in storage and only appear when the floor structure demands them.
The idea is that organization prevents the disorderly deposit of supplies. This framework is a logistical filter releasing the right piece for the current moment. It prevents full project instructions from suffocating the worker at the start of construction. Bottom line, AI receives only the necessary signal for the work right now. Work sites remain clean, and execution flow continues without physical or informational obstacles.
Organizational design and maintenance
Maintaining context demands collective discipline. System maps must not become forgotten artifacts in a repository corner. Treating context engineering as part of long-term architecture is the differentiator. Using this, teams spend less time fixing AI hallucinations. We create a structure where institutional knowledge is versioned and accessible.
Configuration files need to abandon the long tutorial format. Base texts must only point in short directions. Metadata governance ensures automation does not become a technical burden in the future.
Instruction as a map
Various platforms use their own mechanisms to load orders. Some AIs utilize local configurations in the file system. Others accept parameters in administrative panels. We’ve learned that static rules fail in the face of unstable legacy corporate ecosystems.
Replacing entire manuals with indexes changes model behavior. Tools start tracking short paths instead of processing paragraphs. Limiting delivered options reduces errors when generating code. The idea is that exact references allow opening data at the exact moment of need.
Less reading and more focus
With context engineering, practical limits are imposed on programming assistants. Theoretical guidelines lose validity when facing the real operating system. Focus on technical delivery requires us to stop fighting prompt saturation. In the end, mastering this intellectual orchestration returns control to engineering teams. We stop expecting technological miracles and return to designing real software. Real competitive advantage is the ability to give the machine the right signal.