Um agente de IA lê uma função inteira, explica com precisão o que ela faz e, na sequência, propõe uma mudança que derruba um módulo em outro canto do sistema. Isso não é falha de leitura. É falta de engenharia de contexto, a prática de entregar ao modelo não uma pilha de arquivos, mas o recorte estrutural certo, entidades, dependências e regras de negócio, para a tarefa em questão. Sem esse recorte, o problema que parecia estar no modelo se repete a cada geração de ferramenta nova. 

Engenharia de contexto: o que trocar de modelo não resolve 

Os modelos de linguagem evoluíram de forma notável nos últimos anos. Ainda assim, times de engenharia relatam a mesma frustração através de sucessivas gerações de ferramentas. Respostas tecnicamente convincentes que ignoram como o sistema realmente funciona, mudanças que quebram um módulo distante, regras de negócio atropeladas, código novo que duplica o que já existia em outro lugar do mesmo sistema. 



Os dados do primeiro ciclo de IA em engenharia contam essa história com números. A adoção disparou, mas a confiança dos desenvolvedores no que a IA produz caiu nos últimos dois anos. Uma análise da GitClear sobre 211 milhões de linhas de código encontrou oito vezes mais blocos duplicados em 2024 do que nos anos anteriores, e a refatoração caiu para menos de 10% das mudanças, contra 25% em 2021. Copiar superou refatorar, o comportamento típico de quem não entende o sistema em que está mexendo. Se o problema persiste mesmo com modelos cada vez melhores, ele provavelmente não está no modelo. Está no que o modelo recebe. 

Ler uma função não é entender um sistema 

Um modelo de linguagem lê texto. Um sistema não é texto. É o comportamento que emerge de milhares de relações entre partes, somado a regras de negócio implícitas, convenções da equipe e decisões de arquitetura tomadas ao longo de anos que raramente estão escritas em algum arquivo. 

É por isso que a IA consegue explicar perfeitamente o que uma função faz e, no mesmo fôlego, propor uma mudança que compromete o sistema inteiro. Ela leu o trecho. Não teve acesso ao resto do organismo. 

Onde mora o grafo de dependências do seu sistema 

Funções que chamam funções. Serviços que dependem de filas. Tabelas lidas por módulos que nunca aparecem juntos no mesmo diretório. Eventos que disparam efeitos em cadeia. O conhecimento mais crítico de um sistema é o mapa dessas relações, e em sistemas longevos esse mapa quase nunca existe por escrito. Ele vive espalhado no código e na memória de quem o construiu. 

Pedir a uma IA que altere um sistema sem lhe dar acesso a esse mapa é como colocar um recém-chegado brilhante para operar um organismo que ele nunca examinou por inteiro. 

A armadilha de mandar arquivo demais 

A resposta intuitiva a esse diagnóstico costuma virar colar mais arquivos na conversa. Essa abordagem cria dois problemas ao mesmo tempo. O primeiro é custo. Quanto mais conteúdo enviado, maior o consumo de tokens, e a fatura cresce sem que a qualidade acompanhe. O segundo é ruído. Quanto mais material irrelevante o modelo recebe, maior a chance de ele se apoiar no trecho errado para justificar a resposta. 

Contexto não é volume, é recorte. A informação certa, na estrutura certa, para a tarefa em questão. Quem manda tudo paga o desperdício duas vezes, na fatura de tokens e no retrabalho que vem depois. 

Por que parecer relevante não é ser relevante 

Boa parte das ferramentas atuais tenta resolver esse recorte com busca por similaridade, localizando na base de código os trechos que mais se parecem com a tarefa pedida. Para documentos de texto, essa abordagem funciona bem. Para código, ela engana com frequência. Duas funções quase idênticas podem cumprir papéis opostos, e a dependência que realmente importa pode estar escondida em um módulo que não se parece em nada com o trecho editado. 

O que interessa é outra coisa: quem chama quem, quem depende de quem, que fluxo atravessa quais componentes. Isso não se descobre por semelhança de texto. Descobre-se pela estrutura real do código, onde as relações entre funções, classes, módulos e serviços podem ser mapeadas de forma explícita, verificável e auditável. É a diferença entre achar que algo é relevante e saber que de fato é. 

O peso da IA em sistemas legados 

É nos sistemas mais longevos, justamente os que sustentam a operação e pagam as contas, que tudo isso vira crítico. Depois de oito, dez, quinze anos, a documentação ficou para trás do código, parte de quem construiu seguiu outros caminhos e acoplamentos que faziam sentido na época não estão explícitos em lugar nenhum. Nada disso é sinal de má gestão, e sim o preço natural de um sistema que deu certo e durou. 

O peso econômico dessa realidade já está medido. Estudos de mercado estimam que de 21% a 40% do gasto total de TI é consumido por dívida técnica (Deloitte, 2026), com medições mais amplas chegando à metade do investimento em tecnologia (McKinsey), e desenvolvedores dedicam cerca de 13,5 horas por semana a ela (Stripe). Aplicar IA nesse tipo de ambiente sem um mapa estrutural amplia o risco. Com o mapa, a relação se inverte, e a IA passa a ser uma alavanca para recuperar o próprio conhecimento do sistema, suas dependências, regras de negócio e documentação derivada do código que existe, não do que alguém se lembra dele. 

O que muda quando a IA recebe a estrutura real do sistema 

Quando a tarefa chega acompanhada do recorte estrutural exato, os componentes envolvidos, suas relações e nada além, o comportamento da ferramenta muda de natureza. 

Menos alucinação estrutural: Com as relações reais à vista, cai o risco de mudanças que ignoram dependências e regras de negócio. 

Menos tokens, menos custo: O modelo recebe o recorte da tarefa, não arquivos inteiros, o que gera economia direta e mensurável no consumo. 

Análise de impacto antes da mudança: Saber o que depende do trecho alterado permite avaliar consequências antes de aceitar o código, não depois do incidente. 

Mais código aproveitado: A distância entre o que a IA gera e o que chega à produção diminui, e é justamente nela que o investimento em IA se perde ou se paga. 

Para que você possa se aprofundar ainda mais, recomendamos também a leitura dos artigos abaixo: 

Código gerado por IA: o risco que ninguém parou para medir 

Economia de tokens na engenharia de software: como reduzir custo de IA sem perder qualidade 

Critérios de aceite na era da IA: por que Definition of Ready virou controle de custo e de conformidade 

Contexto, validação e análise de impacto como disciplina única 

Contexto estrutural certo na entrada. Critérios de aceitação e validação de código gerado por IA na saída. Registro do que foi usado, decidido e produzido no caminho. Tratadas juntas, essas três práticas transformam a IA de um gerador veloz de sugestões em um instrumento de engenharia rápido e confiável ao mesmo tempo. 

A pergunta que as equipes mais maduras estão fazendo já não é qual modelo usar. É o que o modelo precisa saber sobre o sistema, e como a equipe vai verificar o que ele fez. Essa é a visão que orienta o trabalho da CSP Tech com IA em ambientes de engenharia complexos, onde sistemas legados, integrações sensíveis e regras de negócio construídas ao longo de anos não podem ser tratadas como texto solto para um modelo interpretar sozinho. 

Se a sua equipe já usa IA para gerar código e ainda convive com mudanças que quebram o que não deveriam tocar, vale mapear onde o contexto está faltando antes de trocar de ferramenta outra vez. 

Fale com a CSP Tech: https://www.csptech.com.br/contato