Contexto estrutural é a informação sobre como as partes de um sistema se relacionam entre si: o que chama o quê, o que depende de quê, o que quebra quando algo muda. É diferente do conteúdo dos arquivos, que descreve o que cada parte faz isoladamente. Uma IA que recebe apenas os arquivos que serão alterados pode produzir código sintaticamente correto e ainda assim quebrar outra parte do sistema, porque nunca soube que aquela parte existia. O risco não está no que o modelo vê, está no que ele não sabe que existe, e por isso ele não é resolvido escolhendo um modelo mais capaz: nenhuma capacidade de raciocínio compensa uma dependência que ninguém mencionou. A conclusão prática incomoda quem espera resolver isso com ferramenta: dar o contexto certo é um problema de conhecimento do sistema, não de poder computacional.

A alteração simples que nunca é simples

Lucio Figueiredo Matias, Head of Operations da CSP Tech, descreve um caso que se repete com pequenas variações em praticamente todo sistema que acompanhou de perto. Alguém pede para ajustar a forma como o sistema autentica um usuário. Trocar uma validação, ajustar um campo, resolver rápido. Parece uma mudança pequena.

Autenticação, porém, quase nunca é isolada. Ela costuma tocar o controle de acesso, que decide o que aquele usuário pode fazer depois de entrar. Toca a geração e a validação de tokens, que outras partes do sistema também consultam. Toca o banco de dados, onde ficam registradas sessões e permissões.

Toca os logs, que precisam continuar registrando o que aconteceu do jeito certo. E, em muitos casos, toca integrações externas que dependem daquele mesmo fluxo para funcionar.

A observação que Lucio extrai do caso é a que dá título a este artigo: quem enxerga só o arquivo a ser alterado vê a função, não vê o sistema. E uma IA que recebe apenas aquele arquivo isolado, sem o mapa do que depende dele, corre o mesmo risco que um desenvolvedor recém-chegado correria no primeiro dia. Pode escrever código correto do ponto de vista da sintaxe e ainda assim quebrar algo em outro lugar, porque nunca soube que aquele outro lugar existia.

A tese deste guia: reduzir contexto e acertar o contexto são problemas diferentes, e podem entrar em conflito. Cortar volume sem conhecer as relações produz um contexto pequeno e errado, que é o pior dos dois mundos, porque custa menos e erra mais. O objetivo não é enviar menos informação, é enviar a informação certa, e saber qual é a certa exige um mapa das relações que o conteúdo dos arquivos não contém.

Similaridade não é dependência

Aqui está a confusão conceitual mais comum do tema, e ela merece ser desfeita com cuidado, porque leva empresas a acreditar que já resolveram um problema que sequer endereçaram.

A forma mais difundida de dar contexto a um modelo é buscar trechos semelhantes ao que se está pedindo e enviá-los junto. É uma abordagem legítima e resolve bem certas classes de problema. Ela é, porém, cega para o tipo de relação que importa numa alteração de sistema, por uma razão simples: proximidade textual e dependência estrutural são propriedades diferentes.

•     Dois arquivos podem ser muito parecidos e não ter relação nenhuma. Dois formulários de cadastro escritos no mesmo padrão se parecem, e alterar um não afeta o outro em nada.

•     Dois arquivos podem ser completamente diferentes e fortemente acoplados. O módulo que valida token e o serviço de integração externa que o consome não se parecem em nada, e um depende do outro de forma crítica.

A busca por semelhança encontra o primeiro caso e ignora o segundo. Como o segundo é justamente o que quebra em produção, a sensação de ter resolvido o contexto convive com a permanência do problema. É por isso que times relatam que a IA passou a errar menos em tarefas isoladas e continua quebrando coisas quando a alteração atravessa o sistema.

O mapa que falta, e o que ele responde

Análise de impacto é a prática de identificar, antes de alterar, o que uma mudança pode afetar. É uma disciplina antiga de engenharia de software, anterior a qualquer discussão sobre IA, e que caiu em desuso na medida em que os sistemas cresceram além do que uma pessoa consegue manter na cabeça. A ironia é que ela voltou a ser indispensável justamente quando a execução acelerou.

O mapa de relações que sustenta a análise de impacto responde a três perguntas que nenhum arquivo isolado responde:

o que este componente chama, e o que chama este componente?

o que quebra se eu alterar este comportamento?

que partes do sistema precisam ser testadas junto com esta mudança?

Note que a terceira pergunta é de qualidade, não de arquitetura. Sem mapa de relações, a decisão sobre o que testar depende da memória de quem está fazendo a alteração, o que funciona até a pessoa que tinha essa memória sair da empresa. É a mesma razão pela qual defeitos aparecem longe da mudança que os causou e ninguém consegue associar os dois, tema que tratamos no artigo sobre rastreabilidade de defeitos deste blog.

O precedente que a empresa já aceitou na camada de dados

Vale observar que esse problema já foi reconhecido e resolvido em outra camada da mesma empresa. Alterar uma coluna quebra relatório, painel e tabela derivada que ninguém lembrava que dependiam dela, e o mecanismo da falha é idêntico: a dependência existe, não está escrita em lugar nenhum e só aparece quando quebra.

A diferença é que, no dado, a resposta já está construída. A documentação da Databricks descreve a linhagem no Unity Catalog como capturada automaticamente em tempo de execução, com granularidade até o nível de coluna, visualizável no explorador de catálogo e agregada entre os workspaces ligados ao mesmo metastore, respeitando as permissões de cada usuário. Existe ainda a linhagem externa, que permite registrar metadados de origens e de ferramentas de consumo que operam fora da plataforma, fechando o grafo até quem consome o dado na ponta. Em outras palavras: a empresa que investiu em governança de dados aceitou, sem discussão, que precisa de um mapa de relações para responder o que quebra se algo mudar.

A pergunta que essa simetria levanta: por que a mesma empresa que exige linhagem automática para o dado opera o código sem mapa nenhum de dependências, e agora com uma IA produzindo alterações em velocidade maior. Não é uma questão de rigor desigual, é de maturidade desigual entre as duas disciplinas. A camada de dados chegou primeiro porque a dor apareceu primeiro. Na camada de código, a dor acabou de chegar, trazida pela aceleração.

O mapa parcial que a sua empresa já tem e não usa (consultoria Jira)

Antes de construir qualquer coisa, vale reconhecer que boa parte das empresas já possui uma evidência de acoplamento acumulada e desprezada: o histórico do próprio trabalho.

Quando os itens de trabalho carregam módulo, tipo e vínculo ao requisito, o histórico revela quais partes do sistema mudam juntas ao longo do tempo, quais áreas concentram defeitos após determinadas alterações e quais mudanças costumam gerar retrabalho em outro lugar. Isso não substitui um mapa estrutural, porque é observacional e não causal, mas indica onde olhar primeiro. No Jira, esse histórico de transições está disponível para consulta programática, o que permite tratá-lo como fonte de análise e não apenas como registro.

Há um ganho aqui que costuma passar despercebido e que vale explicitar para quem já implantou rastreabilidade por outro motivo. A classificação de itens que defendemos em nome de conformidade e aprendizado tem um segundo retorno, não cobrado por ninguém: ela produz evidência de acoplamento. Times que classificam bem descobrem, sem esforço adicional, que certos módulos aparecem sempre juntos nos mesmos incidentes.

O que muda na prática quando o contexto é estrutural

A terceira linha é a mais subestimada. Revisar uma entrega assistida por IA verificando apenas o que foi alterado deixa passar a classe de erro mais cara, que é a omissão: a mudança que deveria ter acontecido em outro componente e não aconteceu, porque o modelo não sabia que ele existia. Erro por omissão não aparece na revisão de código, aparece em produção.

A terceira linha é a mais subestimada. Revisar uma entrega assistida por IA verificando apenas o que foi alterado deixa passar a classe de erro mais cara, que é a omissão: a mudança que deveria ter acontecido em outro componente e não aconteceu, porque o modelo não sabia que ele existia. Erro por omissão não aparece na revisão de código, aparece em produção.

Quando isso não compensa

•     Sistema pequeno e conhecido por quem o mantém. Quando o mapa cabe na cabeça das pessoas que trabalham nele todos os dias, construí-lo formalmente traz pouco. O ponto de virada é quando o conhecimento passa a depender de quem já saiu.

•     Componente isolado e sem consumidores. Alteração em código verdadeiramente autônomo não precisa de análise de impacto. O cuidado é confirmar que ele é isolado, em vez de supor.

•     Antes de existir disciplina de registro. Se o trabalho não é registrado de forma consistente, o histórico não serve como indício de acoplamento, e a análise precisará ser inteiramente estrutural. Nesse caso, arrumar o registro tem retorno próprio e independente.

Perguntas frequentes

Por que a IA quebra código que não estava no contexto?

Porque ela decide com base no que recebeu, e uma dependência não mencionada é, para ela, inexistente. O modelo pode produzir código sintaticamente correto e ainda assim quebrar outra parte do sistema que consome o comportamento alterado. Não é uma falha de raciocínio, é ausência de informação, e por isso não se resolve escolhendo um modelo mais capaz: nenhuma capacidade compensa o que não foi informado.

Qual a diferença entre busca por similaridade e relação estrutural?

Similaridade mede proximidade textual: encontra trechos parecidos com o que se procura. Relação estrutural descreve dependência real: o que chama o quê, o que consome o quê. São propriedades independentes. Dois arquivos podem ser muito parecidos e não se afetar, e dois arquivos podem ser completamente diferentes e fortemente acoplados. Como é o segundo caso que quebra em produção, contexto montado apenas por semelhança deixa passar exatamente o risco que importa.

O que é análise de impacto em software?

É a prática de identificar, antes de alterar, o que uma mudança pode afetar: quais componentes dependem do comportamento que será modificado, o que precisa ser testado junto e onde o efeito pode aparecer. É disciplina antiga de engenharia, que perdeu espaço à medida que os sistemas cresceram além do que uma pessoa consegue mapear mentalmente, e voltou a ser indispensável quando a execução assistida por IA acelerou o ritmo das alterações.

Contexto menor sempre reduz custo e melhora o resultado?

Reduz custo, mas não necessariamente melhora o resultado. Reduzir volume e acertar a seleção são problemas diferentes: cortar contexto sem conhecer as relações do sistema produz um envio pequeno e incompleto, que custa menos e erra mais, inclusive por omissão. A economia sustentável vem de enviar o recorte relevante, e identificar o que é relevante depende de conhecer as dependências, não de reduzir por regra.

Próximo passo

A pergunta com que Lucio encerra a reflexão dele serve de teste rápido para qualquer time: qual foi a última alteração aparentemente simples que acabou afetando várias partes do sistema? Se a resposta veio rápido, o mapa de relações do seu sistema existe apenas na memória de algumas pessoas. Solicite um diagnóstico com a CSP Tech e receba o mapa do seu caso: onde o acoplamento se concentra, o que o histórico de trabalho já revela sobre isso e que recorte a IA precisa receber antes de alterar cada parte.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Com contribuição de Lucio Figueiredo Matias, Head of Operations da CSP Tech, cuja observação sobre relações sistêmicas e contexto originou este artigo. Revisão técnica por especialistas de engenharia, dados e Atlassian da CSP Tech (parceira Databricks, Atlassian Gold Partner, Microsoft Gold Partner, participante do Anthropic Partner Network, 34 anos de mercado).

Fontes (oficiais, acesso ago/2026): Databricks Documentation (docs.databricks.com), quanto à linhagem no Unity Catalog capturada automaticamente em tempo de execução com granularidade de coluna, visualização no Catalog Explorer, agregação entre workspaces e respeito às permissões do usuário, e quanto à linhagem externa para registro de origens e ferramentas de consumo fora da plataforma. Atlassian, documentação da API do Jira quanto à disponibilidade do histórico de transições de itens para consulta programática (developer.atlassian.com). As observações sobre o comportamento de alterações em sistemas e sobre o exemplo de autenticação são atribuídas a Lucio Figueiredo Matias e constituem relato de experiência profissional, identificado como tal, e não resultado de estudo. Análise de impacto e acoplamento entre componentes são conceitos estabelecidos de engenharia de software, apresentados aqui sem atribuição a fonte específica por serem conhecimento consolidado da disciplina. Nenhum número de desempenho, economia ou redução foi citado neste artigo por ausência de fonte primária verificável.