No fim de julho, Deepak Singh, VP de developer agents na AWS, colocou o problema em uma frase que vale ler devagar. "Alguns times estão tendo ganhos de 15% a 30% de produtividade. Outros estão multiplicando por três a dez vezes. E estão usando exatamente as mesmas ferramentas."
Essa diferença não cabe em nenhuma conversa sobre qual modelo escolher, qual IDE assinar ou qual plano de vendor contratar. O resultado varia em uma ordem de grandeza com o mesmo tooling. O que muda não é a ferramenta. O que muda é como o time reorganizou o trabalho em volta dela.
Paul Nashawaty documentou o pano de fundo dessa variação no SiliconANGLE, em 31 de julho de 2026. Aproximadamente 65% das organizações reportam que times de engenharia passam apenas 0 a 20% do tempo em inovação de fato. O restante vai para manutenção, migrações, revisões e troca de contexto. Quando a IA entra nesse ambiente e acelera só a parte de geração, o gargalo não desaparece. Ele migra.
O que separa 25% de dez vezes
A diferença entre os times que multiplicam e os que ganham um quarto não é acesso. É redesenho.
Steve Tarcza, diretor de desenvolvimento de software na Amazon, articulou o mecanismo com clareza: "Os times que se concentram em registrar esse conhecimento, seja em arquivos de direcionamento, documentação ou especificações, desbloqueiam os agentes para assumir muito mais trabalho." O agente não fica mais capaz por causa de um modelo novo. Ele fica mais capaz porque passou a ter contexto claro sobre como a equipe trabalha, quais são os padrões de arquitetura e o que se espera de cada entrega.
Times que inserem IA nos fluxos existentes sem redesenhar o planejamento e as especificações ficam com os 15% a 30%. Times que reconstroem o fluxo ao redor das capacidades da IA ficam com os três a dez vezes. O ganho não está no modelo. Está na reorganização do processo em volta do modelo.
Para onde o rigor foi
A percepção mais comum sobre IA em engenharia é que ela reduz a necessidade de rigor. Está errada.
A tese do V-Bounce de Cory Hymel explica por quê. O paradigma 70/30 distribui o valor em desenvolvimento AI-native de forma precisa: cerca de 70% está nas pontas do ciclo, onde ficam intenção, especificação, julgamento e validação. Os 30% restantes estão na execução que a IA acelera. O rigor não sumiu. O fundo do ciclo encolheu, e o rigor foi para onde o pensamento mora.
O SDLC AI Radar 2026, relatório da LTIMindtree que cruza mais de cem fontes globais, confirma esse mapa. A IA não elimina a necessidade de disciplina. Ela a move. Para dois lugares distintos.
Para cima, na cadeia, o rigor vai para planejamento mais claro, especificações mais sólidas e o que o relatório chama de context engineering, o trabalho deliberado de documentar arquitetura, padrões e prioridades de negócio para que os agentes operem com informação suficiente. O relatório resume em uma frase: "Planning is the new coding."
Para baixo, na cadeia, o rigor vai para validação contínua, fronteiras de contenção e supervisão em tempo de execução. A velocidade de geração exige um processo equivalente de verificação, senão o throughput se converte em incidentes.
O rigor não desapareceu. Mudou de endereço.
O gap que revela onde a infraestrutura ainda falta
Se as ferramentas de 2026 já suportam autonomia alta para sessões longas de codificação, por que 73% das mudanças de código ainda requerem revisão humana? O SDLC AI Radar documenta essa assimetria e chama de "deployment autonomy gap": a capacidade da ferramenta está à frente do nível de autonomia que os processos permitem.
Na minha leitura, esse gap não é um problema da ferramenta. É um diagnóstico de infraestrutura. Reduzir a revisão humana sem construir a infraestrutura que justifica essa redução seria irresponsável. O que fecha o gap não é confiar mais nos modelos. É construir o que permite confiar: especificações que ancorem o que o código precisa fazer, contexto registrado sobre como a arquitetura funciona, e testes que verifiquem comportamento, não apenas sintaxe.
Quando isso está no lugar, o agente tem o que precisa para trabalhar com menos intervenção. Quando não está, o humano precisa compensar na revisão o que o agente não teve como saber na geração.
O que o "Add to Order" da Amazon mostra
Tarcza descreveu um caso concreto. A feature "Add to Order" da Amazon foi lançada dois meses antes do previsto depois que o time adotou planejamento centrado em especificação com execução dirigida por IA.
O mecanismo é direto. Com a especificação pronta antes da geração, o agente trabalha contra um alvo definido. A revisão confirma em vez de descobrir. Cada iteração tem um ponto de partida identificável e um critério de aceitação claro. O ciclo fecha mais rápido não porque o modelo ficou mais inteligente. Porque o trabalho de intenção foi feito antes de o modelo começar a gerar.
Essa é a redistribuição do rigor na prática. Menos tempo corrigindo na saída, mais tempo especificando na entrada.
Os times que multiplicam o resultado não são os que compraram a ferramenta mais cara. São os que entenderam que a ferramenta precisava de um processo novo para funcionar. E construíram esse processo.