Em setembro, um engenheiro anônimo publicou no X (antigo Twitter) um desabafo que passou de milhões de visualizações. Segundo o relato, na empresa onde ele tinha acabado de entrar, as pessoas trabalhavam 12 a 13 horas por dia praticamente apertando Enter. Passavam o dia aprovando código gerado por IA, sem tempo para ler o que subia para produção. Muita gente leu aquilo como crise de identidade de programador. Para quem responde por sistemas críticos, a leitura é outra. Cada aprovação feita às cegas é um trecho do sistema que ninguém sabe explicar. E é assim que nasce um legado. 

O gargalo mudou de lugar, e a conta foi para a revisão 

Durante décadas, escrever código foi a parte cara do trabalho. A IA barateou essa etapa de forma brutal, mas não barateou a etapa seguinte. Alguém ainda precisa ler, entender, testar e assumir responsabilidade pelo que foi gerado. 

A análise publicada pelo DORA em março de 2026, Balancing AI tensions, descreve exatamente esse deslocamento. A partir de mais de mil respostas abertas de engenheiros, a pesquisa mostra que o tempo economizado na escrita costuma ser gasto de novo em auditoria e verificação. E verificar é uma tarefa cognitiva diferente de criar. Quem escreve com ajuda da IA entrega um pull request enorme em minutos; quem revisa continua tendo que conferir cada linha. O ganho de um vira carga do outro. 

O mesmo texto retoma um achado do relatório DORA de 2025 que deveria estar na mesa de todo gestor de engenharia. Segundo esse achado, maior adoção de IA aparece associada, ao mesmo tempo, a mais throughput e a mais instabilidade na entrega. O time entrega mais e quebra mais. A explicação do DORA é direta. A IA funciona como amplificador. Em organizações com boa plataforma interna, testes sólidos e fluxos claros, ela ajuda. Em times com ferramentas fragmentadas e infraestrutura frágil, ela só acelera a produção de dívida técnica. 

Nada disso significa que os times deixaram de revisar. A pesquisa Agents on a leash, publicada pelo Stack Overflow em maio de 2026, mostra que o uso de agentes de IA no trabalho quase dobrou, de 31% para 59%. Mesmo assim, 63% dos profissionais disseram que raramente ou nunca deixam um agente operar sozinho. O humano continua no circuito. A questão é que estar no circuito não garante compreensão. Aprovar um PR de 800 linhas em quatro minutos também é "revisão humana", pelo menos no registro da ferramenta. 

O que é dívida de compreensão 

Dívida de compreensão é a distância entre o que o sistema faz e o que alguém do time consegue explicar sobre ele sem passar horas investigando. Ela cresce toda vez que um código entra em produção sem que ninguém tenha realmente entendido por que ele foi escrito daquela forma, que regra de negócio ele implementa e o que quebra se ele mudar. 

A dívida técnica tradicional costuma ser uma escolha consciente. O time sabe que pegou um atalho e, em tese, sabe onde ele está. A dívida de compreensão é mais traiçoeira porque não deixa rastro. O código pode até estar bem escrito, seguir o padrão de estilo, passar nos testes. O problema não está no arquivo. Está na cabeça das pessoas, onde aquele conhecimento nunca chegou a entrar. 

Por que ela não aparece no painel de entrega 

Os indicadores que a maioria das empresas acompanha medem volume e velocidade, como itens concluídos, PRs mergeados e frequência de deploy. Todos sobem quando a IA entra. Nenhum deles mede se o time entende o que está entregando. 

A dívida só se manifesta mais tarde, e quase sempre num momento ruim. Pode ser um incidente em produção às duas da manhã, uma mudança regulatória que exige alterar uma regra de cálculo ou a saída da única pessoa que conhecia aquele módulo. É nessa hora que a empresa descobre que o sistema funciona, mas ninguém sabe dizer como. 

Sinais de que o seu time já está acumulando 

Alguns sintomas costumam aparecer antes da crise, e vale observá-los com atenção: 

• PRs grandes aprovados em poucos minutos, com poucos ou nenhum comentário de revisão. 

• Tempo para encontrar a causa de incidentes crescendo, mesmo em código recente. 

• Perguntas sobre o funcionamento de um módulo sendo respondidas com "vou perguntar para a IA" em vez de "funciona assim porque...". 

• Documentação gerada automaticamente que descreve o óbvio e omite a regra de negócio. 

• Pessoas novas no time que conseguem entregar rápido, mas não conseguem explicar o que entregaram. 

Nenhum desses sinais, isolado, prova que há um problema. Juntos, indicam que a velocidade de produção passou a velocidade de entendimento. 

Como o código gerado por IA vira o legado de 2028 

Sistema legado não é sinônimo de sistema antigo. Na prática, legado é o sistema que ninguém tem coragem de mexer, porque ninguém entende o suficiente para prever o impacto de uma mudança. Por essa definição, um sistema escrito em 2026 pode virar legado em dois ou três anos. Basta que ele seja construído mais rápido do que é compreendido. 

O efeito no orçamento é previsível. A pesquisa da McKinsey com a Serviceware, Recalibrating technology budgets for the AI era, de março de 2026, separa os gastos de tecnologia em dois grupos. "Run" é o que mantém os sistemas funcionando, e "change" é o que cria capacidade nova. As empresas que a McKinsey chama de heavy IT sustainers comprometem a maior parte do orçamento só com manutenção. Já as que o estudo classifica como deliberate modernizers direcionam 57% do orçamento de aplicações para modernização e novas capacidades. 

Há um detalhe na pesquisa que conversa diretamente com a dívida de compreensão. A McKinsey descreve um grupo que investe em mudança, inclusive em IA, mas empilha as novas capacidades sobre os sistemas existentes. O resultado é mais custo de operação e mais dívida técnica, não menos. Código que ninguém entende segue exatamente esse caminho. Ele entra como "change" e, em pouco tempo, passa a morar na coluna de "run". Cada ajuste passa a exigir investigação, cada incidente demora mais para fechar e cada evolução vem acompanhada de medo de quebrar algo. 

O que a aviação aprendeu com a automação 

Em 1983, a psicóloga Lisanne Bainbridge publicou um artigo curto na revista Automatica chamado Ironies of Automation. Ela estudava controle de processos industriais, muito longe de qualquer IDE, mas o diagnóstico serve com precisão incômoda para o momento atual. 

A primeira ironia é que, quanto mais se automatiza, mais o papel do humano se reduz a monitorar. E monitorar por longos períodos um sistema que quase sempre funciona é justamente uma tarefa em que pessoas são ruins. A atenção cai, os desvios passam. 

A segunda ironia é mais cruel. Quando a automação falha, o humano precisa assumir o controle numa situação anormal, que exige mais competência do que a operação de rotina. Só que essa competência se deteriora exatamente porque deixou de ser praticada no dia a dia. O sistema automatizado cobra, na hora mais difícil, a habilidade que ele mesmo tirou do operador. 

Troque "operador de planta industrial" por "engenheiro que aprova código de IA" e a descrição continua de pé. O engenheiro vira monitor da esteira. Sua capacidade de ler e raciocinar sobre o sistema enfraquece por falta de uso. E, no dia em que algo quebra de um jeito que a IA não resolve, é dele que se espera o diagnóstico. 

A aviação comercial enfrentou esse dilema bem antes do software. Os aviões ficaram altamente automatizados, e o setor não respondeu reduzindo o treinamento dos pilotos. Respondeu com treinamento recorrente, simulação de falhas e checklists rigorosos, para que a competência manual continuasse viva mesmo quando raramente é usada. A própria Bainbridge apontava que sistemas mais automatizados podem exigir mais investimento em preparo humano, e não menos. 

Como revisar código gerado por IA sem transformar o time em monitor de esteira 

Proibir IA no desenvolvimento não resolve. O caminho é desenhar o processo para que a compreensão acompanhe a produção. Algumas práticas ajudam bastante nisso. 

A primeira é trabalhar em lotes pequenos. O próprio DORA recomenda essa disciplina como contrapeso aos riscos do desenvolvimento assistido por IA. Um PR que cabe na cabeça de quem revisa tem chance real de ser entendido. Um PR de centenas de linhas geradas de uma vez só será aprovado por confiança. 

A segunda é classificar o sistema por criticidade. Nem todo código merece o mesmo nível de escrutínio. Uma tela de relatório interno pode seguir com revisão leve. Regras de cálculo financeiro, integrações com sistemas core, tratamento de dados pessoais e fluxos regulados precisam de revisão profunda, com alguém capaz de explicar o que foi alterado e por quê. Deixar isso explícito tira a decisão do improviso e da pressão de prazo. 

A terceira é mudar o que se mede. Se o painel só acompanha volume, o time vai perseguir volume. Indicadores como taxa de falha de mudança, tempo de recuperação de incidentes, retrabalho em código recente e tamanho médio dos PRs dizem muito mais sobre a saúde da engenharia do que a quantidade de linhas aceitas. Vale incluir também uma prática simples, que não depende de ferramenta. Periodicamente, peça que alguém do time explique um fluxo crítico do começo ao fim, sem abrir a IA. Se ninguém consegue, a dívida já está lá. 

A quarta é preservar a prática deliberada, o equivalente ao treinamento recorrente dos pilotos. Isso passa por parear pessoas menos experientes com seniores na revisão de decisões de arquitetura geradas por IA e por reservar componentes complexos para desenvolvimento com mais participação humana. Também passa por registrar as decisões de desenho em algum lugar consultável, seja no Confluence, seja no próprio fluxo do Jira. O objetivo é que o conhecimento sobre o sistema more nas pessoas e na documentação, não apenas no histórico de prompts. 

Por fim, governança de IA no desenvolvimento precisa ser tratada como decisão de gestão. Hoje, na maioria dos times, ela fica a critério de cada desenvolvedor. Quem pode aprovar o quê, em qual parte do sistema, com qual nível de evidência. Sem esse acordo, cada pessoa calibra sozinha, sob pressão, quanto vai ler antes de apertar enter. 

Onde a CSP Tech entra nessa conversa 

Boa parte das empresas que atendemos não tem tecnologia como core business, mas depende de sistemas críticos para faturar, atender e cumprir obrigações regulatórias. Nesses ambientes, a pergunta não é se a IA vai entrar no desenvolvimento. Ela já entrou. A pergunta é quanto do que está sendo entregue hoje o time vai conseguir sustentar daqui a três anos. 

A CSP Tech trabalha justamente nessa camada. Em sustentação de ambientes críticos e desenvolvimento de sistemas core, o trabalho começa por entender onde o conhecimento sobre o sistema está concentrado, onde ele já se perdeu e quais fluxos não podem ficar sem dono. A partir daí, ajudamos a estruturar o processo de revisão por criticidade e a organizar a documentação e a rastreabilidade das decisões no Jira e no Confluence. Quando o gargalo é capacidade, reforçamos o time com squads que entram para entender o ambiente, e não só para aumentar o volume de entrega. 

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

Atlassian traz loops de agentes de IA para a engenharia de software 

Segurança do código gerado por IA: a lacuna que ninguém está validando 

Sustentação e manutenção evolutiva e adaptativa de sistemas legados: por que sem medir o esforço, a conta só cresce 

Velocidade que o sistema consegue sustentar 

A IA já mudou o custo de escrever software, e isso não vai voltar atrás. O que ainda está em aberto é quem vai conseguir manter, corrigir e evoluir o que está sendo escrito agora. Empresas que medem só velocidade de entrega vão descobrir o tamanho da dívida de compreensão no pior momento possível, com um incidente aberto e ninguém capaz de explicar o que aconteceu. As que tratam compreensão como parte do trabalho chegam em 2028 com sistemas que ainda conseguem mudar. 

Talvez o seu time tenha acelerado com IA e você já perceba PRs aprovados rápido demais, incidentes mais difíceis de diagnosticar ou módulos que só uma pessoa entende. Se for o caso, esse é um bom momento para olhar o cenário com calma. Converse com os especialistas da CSP Tech para mapear onde a dívida de compreensão já está se formando e definir o que precisa de mais governança antes que vire o próximo legado. 

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