Seus Sistemas Já Têm Pontos Cegos. A IA Apenas os Agrava.

Em 2022, antes de as ferramentas de codificação generativa fazerem parte do nosso trabalho diário de engenharia, eu escrevi sobre minha filosofia de seleção de ferramentas. Isso se manteve melhor do que eu esperava. Naquela época, argumentei que se deveria começar pelos problemas que realmente estavam sendo resolvidos, conhecendo suas fraquezas, e priorizando como usar as ferramentas em vez de simplesmente pular para qualquer ferramenta que pareça a melhor e esperar que funcione. Conheça a si mesmo e seus objetivos, para que você possa definir expectativas adequadas para suas ferramentas.

Na época, eu estava pensando na proliferação de SaaS, não em código gerado por IA. Mas hoje minha filosofia é ainda mais urgente e ainda mais importante de defender.

Muitos de nós leram o relatório DORA 2025, que constatou que, ao contrário do ano anterior, a adoção de IA agora correlaciona-se positivamente com o rendimento de entrega. A constatação subjacente foi que a instabilidade de entrega continuava a crescer, e eles testaram se os ganhos de velocidade compensavam isso. Não compensam. Isso corresponde à nossa experiência. Nosso time adotou desenvolvimento de software agente e viu um aumento de 48% no rendimento ao longo de dois trimestres, seguido por um aumento de 16% nos problemas de estabilidade. Dez pessoas é uma amostra pequena, mas também é uma amostra a partir da qual consigo ver o quadro completo, e o padrão se manteve. 

A adoção de IA não é mais realmente uma questão. Você está começando ou está no meio disso. O que muda agora é que os líderes de engenharia são esperados a adotar IA e também provar que está dando retorno. O CEO, o conselho e o financeiro querem saber como otimizar seu investimento em IA. Eles estão perguntando se as ferramentas que você escolheu estão resolvendo problemas reais de forma eficiente. 

A Lacuna Sempre Existiu. A IA Apenas a Ampliou.

Como CTO, passo boa parte do meu tempo conversando com outros líderes de engenharia, incluindo clientes, prospects e colegas, para comparar conquistas e reclamações sobre o que estamos vivenciando com IA. Depois de suficientes dessas conversas, comecei a perceber padrões na adoção de IA e seus resultados.

A principal observação não é minha. A DORA tem liderado isso há dois anos: a IA amplifica tudo o que já está acontecendo na organização, tanto pontos fortes quanto fraquezas. Um time com arquitetura limpa e hábitos de revisão saudáveis fica mais rápido. Um time que lidou com uma bola de dívida técnica apenas o suficiente para enviar código agora percebe que a dívida técnica está se tornando um bloqueio importante. O que essa formulação deixa de fora, porém, é por que isso pega tantas equipes desprevenidas. A IA não escondeu essas fraquezas; os sistemas nos quais confiamos nunca as revelaram.

A pilha de tickets e relatórios que a maioria das organizações de engenharia usa foi construída para responder às perguntas que os humanos têm, na velocidade humana, por pessoas que entendiam aproximadamente o que “concluído” significava para uma determinada tarefa. Nunca foi um registro perfeito. Sempre foi uma aproximação, preenchida por alguém que resumia algo mais confuso por baixo. Agora, a IA adiciona volume e novos insumos que geram nova atividade. Nenhum dos sistemas (ou ferramentas) usados para métodos tradicionais, não baseados em IA, de desenvolvimento foi criado para isso. 

Independentemente disso, ainda somos responsáveis pelos mesmos objetivos. Você ainda controla velocidade, qualidade, gastos e como sua equipe está realmente se saindo. Você simplesmente não pode mais aceitar os dashboards do ano passado como verdadeiros. 

Há uma objeção válida aqui. relatório ROI DORA 2026 descreve uma curva em J: uma queda de produtividade logo após a adoção, impulsionada pela curva de aprendizado, o custo de verificação de código gerado por IA e processos subsequentes que ainda não se atualizaram. Eles a chamam de “custo de tuition” da transformação, e alertam os líderes a não confundirem isso com falha. É justo. Mas tuition e um problema real parecem idênticos em um dashboard construído a partir de tickets. Se você não consegue distinguir em qual está, não está sendo paciente. Está adivinhando.

Precisamos voltar ao básico. Conheça a si mesmo. Conheça sua equipe. Saiba quais problemas você está resolvendo. 

Como Você “Conhece a Si Mesmo” com IA?

A partir das minhas conversas, identifiquei cinco áreas principais onde os sistemas convencionais, construídos para trabalho gerado e relatado por humanos, são cegos. Ignorá‑los faz com que você corra o risco de amplificar suas fraquezas ao continuar adotando IA.

Ponto Cego 1: Teatro da Velocidade

Mais commits e mais PRs podem parecer progresso, e muitas vezes são. A IA eleva ambas as contagens automaticamente. A estudo de caso da Stanford mostrou que a adoção de IA aumentou a contagem de PRs em 14%. Mas o que você está perdendo é quanto dessa atividade é trabalho de funcionalidade que é entregue versus manutenção, retrabalho ou churn de uma refatoração que não se manteve.

Para lidar com isso, observe a divisão entre trabalho de funcionalidade e manutenção, e monitore a frequência de implantações e o tempo de entrega em relação à sua própria linha de base histórica, não a média da indústria. Sem essa divisão, você está reportando progresso que não pode realmente comprovar.

Ponto Cego 2: Dívida de Revisão

A capacidade de revisão não escala automaticamente junto com a produção. O imposto de verificação não é uma fase que você supera; é parte do custo permanente do desenvolvimento agente. Uma pesquisa recente de líderes de engenharia constatou que 80% das equipes gastam pelo menos 10% do seu tempo em revisão, e aproximadamente uma em cada dez gasta mais de 40%. Sob essa carga, as equipes oscilam entre um backlog crescente e a aprovação automática, e nenhum dos dois é uma solução real.

A restrição ao lançamento não é mais a velocidade com que o código é escrito. É quão rápido um ser humano pode realmente estar confiante de que uma mudança está correta, quão rápido e com precisão os defeitos podem ser detectados e corrigidos. Observe como a carga de revisão é realmente distribuída entre sua equipe; caso contrário, você corre o risco de sobrecarregar seus engenheiros seniores, atrasar seus lançamentos ou causar grandes problemas de produção.

Ponto Cego 3: Trabalho Oculto

Refatorações e mudanças de arquitetura têm o hábito de se esconder dentro de outros tickets, se é que aparecem no sistema de tickets. A IA produz mais desse tipo de trabalho, não menos. Um agente não hesita em tocar em doze arquivos para corrigir um bug, enquanto um humano pode pausar e reconsiderar. Trabalho que ignora o sistema de registro também ignora o planejamento, o que significa que seu modelo de capacidade está errado, e toda previsão construída sobre ele também está errada.

Para entender quanto trabalho está realmente sendo feito, você precisa observar quanto está realmente mudando na base de código e no histórico de pull requests. Sem isso, seu plano de capacidade é construído com base no que as pessoas lembraram de registrar, não no que realmente fizeram.

Ponto Cego 4: Deriva de Qualidade

A mesma pesquisa constatou que quase metade dos líderes de engenharia têm dificuldade em detectar problemas de segurança semana a semana. Complexidade, duplicação e dependências que não se encaixam se acumulam em muitas pequenas mudanças individualmente razoáveis. Nenhuma delas parece alarmante isoladamente. No mesmo estudo de caso da Stanford, a qualidade do código caiu 9% e sua variância mais que triplicou. Enquanto a média mudou um pouco, a dispersão (a parte que você percebe) mudou muito. Em volume de IA, elas se acumulam mais rápido do que a maioria dos processos de revisão as detecta. A deriva tende a aparecer como um alerta de plantão rastreado até uma dependência que ninguém se lembra de ter revisado. Quando isso acontece, há uma boa chance de que um cliente já tenha notado primeiro.

Observe as linhas de tendência em descobertas de segurança, dependências e falhas e recuperações — não o commit individual. Complexidade e duplicação que surgem ao longo de várias semanas importam mais do que qualquer mudança que seja sinalizada na revisão. Sem isso, você detecta a deriva da maneira que a maioria das equipes ainda faz: depois que já causou um incidente.

Ponto Cego 5: Gastos Não Comprovados

Uma vez que a adoção de IA deixa de ser um debate, os gastos com IA e o ROI se tornam a questão em que todos se concentram. As Finanças querem saber o que é capitalizável versus operacional. A liderança quer saber o que o investimento resultou. A maioria das equipes ainda toma decisões sobre ferramentas, licenças e número de funcionários com base na intuição, não em prova da ligação entre dinheiro e trabalho entregue.

Observe para onde o esforço de engenharia realmente flui na própria base de código, trimestre a trimestre — não para onde o roadmap diz que deveria fluir. Sem esse vínculo, você está defendendo o orçamento do próximo ano com anedotas, e anedotas não sobrevivem a uma conversa difícil com o CFO.

Comece com o que Você Não Pode Ver

A pergunta das Finanças sobre gastos capitalizados e uma página de plantão às 2h da manhã parecem não estar relacionadas, mas não estão. Ambas podem ser “estimadas” a partir da atividade. Mas ambas são realmente respondíveis, com evidências, a partir do próprio código.

A resposta da DORA a tudo isso é o próprio sistema de engenharia: qualidade da plataforma, clareza do fluxo de trabalho, alinhamento da equipe. Isso mesmo, e também não é o primeiro passo. Você não pode consertar um sistema que não pode ver. Cada uma dessas cinco áreas é algo que você precisa observar antes de poder defender investimento nelas.

O primeiro passo útil não é uma nova ferramenta ou um novo processo. É conhecer a si mesmo, honestamente, e determinar quais dessas cinco áreas são pontos cegos onde você carece de evidências reais. A maioria dos líderes pode identificar imediatamente (e está atenta a) problemas em uma dessas áreas. Contudo, são as áreas onde você tem menos informação que são mais propensas a surgir e prejudicá-lo à medida que continua a adotar IA.