Quando o código fica quase de graça, o gargalo migra para demanda, integração, validação e alinhamento

Quando a produção de código fica quase gratuita, o gargalo da entrega de software sai do “escrever código” e vai para outro lugar: definir o problema certo, juntar os fragmentos em um todo que funcione, validar que está realmente correto e alinhar a organização. Isso é a Teoria das Restrições se repetindo na indústria de software. A manufatura já passou por esse caminho há 40 anos: sempre que uma etapa fica mais barata, o gargalo não desaparece — ele apenas se desloca para a próxima etapa mais cara. Entender isso explica uma confusão generalizada: ferramentas de programação com IA implantadas em toda a empresa, código sendo escrito visivelmente mais rápido, mas a velocidade de entrega praticamente inalterada.

Um CIO de um grupo industrial me mostrou seus dados dos últimos seis meses. O time de TI, com mais de 80 pessoas, adotou ferramentas de programação com IA em larga escala. Olhando apenas a produção de código, o volume de commits por pessoa e a velocidade de merge subiram mais de 30%. Mas a percepção do lado de negócios é completamente diferente: uma funcionalidade simples de sequenciamento inteligente de produção ainda leva pelo menos 3 meses do início ao lançamento. Ele esperava uma aceleração de 2x com as ferramentas, mas no fim só comprou “código sendo escrito mais rápido”. As palavras dele foram diretas: “Gastei milhões em licenças e o que comprei foi desenvolvimento mais ocupado e negócios mais ansiosos.”

Ele assumiu errado onde estava o gargalo. O gargalo real era outro: cada nova funcionalidade precisa passar pelo MES, ERP, sistema de qualidade, terminais de chão de fábrica, além de um conjunto de regras de reporte regulatório — a integração e os testes conjuntos consomem a maior parte do prazo. Já o código gerado por IA não tem nenhuma etapa formal de aceitação entre ele e o ambiente de produção. Por mais rápido que o código seja escrito, ele só está fazendo fila atrás do gargalo errado.

1. A manufatura já sabia disso há 40 anos: o gargalo muda de lugar

Para entender o presente, primeiro empreste os óculos que a manufatura usa há quatro décadas.

Em 1984, o consultor israelense Eliyahu Goldratt, formado em física, escreveu o romance A Meta (The Goal), sobre um gerente de fábrica à beira da falência tentando salvar sua operação. A tese central do livro cabe em uma frase: a produção de qualquer sistema é determinada pelo seu elo mais estreito (a restrição, ou seja, o gargalo). Alargar os elos que não são gargalo não aumenta a produção em nada; só alargar o gargalo em si acelera o todo. E, assim que você alarga o gargalo, ele imediatamente migra para o próximo ponto mais estreito. Isso é a Teoria das Restrições (Theory of Constraints, TOC).

Depois de 40 anos de automação na manufatura, a história quase se resume a uma “crônica de gargalos que mudam de lugar”. Quando o CNC barateou o corte, o gargalo migrou para a troca de moldes e o controle de qualidade; quando as linhas flexíveis aceleraram a troca de moldes, o gargalo foi para o sequenciamento da produção e a coordenação da cadeia de suprimentos; quando o MES tornou o sequenciamento mais preciso, o gargalo passou a ser a previsão de demanda e a programação entre fábricas. A cada etapa que se automatiza, a próxima vem à tona. A automação nunca elimina gargalos — ela só os realoca.

Essa regra não é exclusividade da indústria. Em julho de 2026, no podcast da a16z Software in the Age of Agents, Steven Sinofsky, ex-presidente do Windows na Microsoft, chegou de forma independente à mesma conclusão usando exemplos de software empresarial. Nas palavras dele:

“The long tail got no shorter. It just got longer in a different way.” (A cauda longa não ficou nem um pouco mais curta. Ela apenas ficou mais longa de uma forma diferente.)

Ele citou o atendimento da Amazon: cortar o telefone e deixar o chatbot emitir diretamente o reembolso do produto parece economizar mão de obra, mas nos bastidores surge imediatamente a necessidade de análise de causa raiz para “evitar que problemas semelhantes voltem a ocorrer”, que é mais complexa do que atender ligações. O processo de reembolso de despesas segue a mesma lógica: depois que o OCR automatiza o lançamento, o trabalho do financeiro passa a ser otimização de desempenho de viagens e comparação dinâmica de preços — o trabalho não desaparece, apenas sobe do “lançamento” para a “análise e decisão”. Um veterano da Microsoft, sócio da a16z, sem usar a teoria de Goldratt, chegou à mesma conclusão que a indústria manufatureira teve há 40 anos. Um veio do chão de fábrica, o outro do software empresarial — dois caminhos independentes apontando para a mesma regra.

Mas é preciso acrescentar uma ressalva a essa regra, para que não seja lida como verdade absoluta. É verdade que alguns gargalos foram eliminados de vez: datilógrafos, telefonistas, tipógrafos de chumbo — essas ocupações não “subiram”, desapareceram de fato. Para distinguir se um trabalho será realocado ou eliminado, o ponto-chave é observar se a capacidade produtiva liberada pela automação gera novas demandas (o que a economia chama de paradoxo de Jevons) ou simplesmente faz essa demanda encolher. A maioria dos trabalhos ao redor dos sistemas centrais das empresas se enquadra na primeira categoria: quanto mais rápido a contabilidade roda, mais análises — e mais detalhadas — o chefe quer ver. Então a conclusão aqui se resume a uma frase: mover pessoas e orçamento da camada que foi automatizada para a camada que acabou de surgir. (A realocação da cauda longa na perspectiva do software empresarial é desenvolvida por completo no artigo extra “A Adesividade do Software Empresarial”.)

Essa história está mais perto do software do que você imagina. Em 2013, Gene Kim praticamente transportou a história de fábrica do Goldratt para a operação de TI e escreveu O Projeto Fênix (The Phoenix Project): como um CIO usou a Teoria das Restrições para salvar um departamento de TI que estava prestes a arrastar a empresa inteira para o buraco. Ou seja, “aplicar o pensamento de gargalo da manufatura ao software” é um caminho já validado, não uma metáfora improvisada.

2. De volta ao software: escrever código está se tornando a parte mais barata

Quatro números deixam claro que o “custo de produção de código está tendendo a zero”. Some a isso um conjunto de dados de estrutura de mercado do primeiro semestre de 2026, e você vê o quão caro isso realmente é.

Copilot: A pesquisa interna do GitHub revelou que, em arquivos com o Copilot habilitado, cerca de 46% do código é escrito pelo Copilot. Atenção ao critério: essa é a proporção dentro dos arquivos habilitados, não 46% de todo o código do GitHub.
Stripe: O agente de codificação interno “Minions” produz e faz merge de mais de 1.300 PRs por semana. Steve Kaliski, engenheiro da Stripe, disse pessoalmente ao demonstrar o sistema publicamente em fevereiro de 2026: “Eu, pessoalmente, já não me lembro da última vez que comecei uma tarefa no editor.” O ponto de partida do trabalho do engenheiro migrou da IDE para tópicos no Slack, Google Docs e tickets. Há um detalhe crucial que vale guardar: cada PR passa por revisão humana antes do merge. A Stripe automatizou a “escrita”, mas deixou a “aprovação” para as pessoas. Voltaremos a isso na seção 4.
NVIDIA: Jensen Huang afirmou publicamente que 100% dos engenheiros da NVIDIA usam ferramentas de programação com IA como o Cursor — “trabalhar sem IA” simplesmente não é mais aceito na NVIDIA.
Nota de mercado do primeiro semestre de 2026 — três gigantes em disputa (ponto de vista complementar, não um novo argumento): A Anysphere, controladora do Cursor, foi avaliada em US$ 29,3 bilhões na rodada Série D em novembro de 2025; em abril de 2026, uma nova rodada em negociação apontava para US$ 50 bilhões; em junho de 2026, a SpaceX anunciou a aquisição integralmente em ações por US$ 60 bilhões. Enquanto isso, o Claude Code, da Anthropic, atingiu US$ 2,5 bilhões em ARR (receita anual recorrente) em fevereiro de 2026, e o ARR total da Anthropic chegou a US$ 30 bilhões em abril — só o Claude Code, um único produto, já supera a receita de toda a empresa no início de 2025. O GitHub Copilot segue como o padrão de fato em termos de base instalada. Somados, os três players já representam um mercado que se aproxima do total dos fornecedores tradicionais de software empresarial.

Sobrepondo os três primeiros dados, a conclusão é dura: o custo unitário de produzir uma linha de código está se aproximando rapidamente de zero. Sobrepondo o último dado, acrescentamos uma realidade: o preço unitário desse negócio está se aproximando rapidamente do teto do software tradicional. O dinheiro na camada das ferramentas já foi mais ou menos todo capturado; o dinheiro da próxima camada — validação, alinhamento, orquestração — está apenas começando a ser precificado.

A pergunta afiada vem em seguida: já que escrever código quase não custa nada, por que o software ainda é tão caro, tão lento e tão difícil de entregar? A resposta é exatamente a que a Teoria das Restrições dá: você alargou o gargalo da etapa “escrever código”, mas o gargalo apenas se moveu. Para onde?

Três: O gargalo foi parar em quatro lugares

Desta vez, o gargalo se concentra em quatro etapas. Cada uma delas é algo que a IA não consegue tocar no curto prazo.

Primeira: definir o problema certo. A IA consegue escrever em segundos “a funcionalidade que você disse que queria”, mas não consegue escrever “a funcionalidade que você realmente precisa”. A maioria dos projetos de software falha porque o que foi construído não é usado por ninguém — desde o início, não se pensou a fundo em qual problema estava sendo resolvido. Agora que a produção de código ficou barata, “transformar uma dor de negócio vaga em uma especificação clara, solucionável e que valha a pena resolver” (problem formulation) virou a capacidade mais escassa e mais cara. Quem vem da manufatura conhece bem esse cenário: se o roteiro de processo e o desenho de engenharia estão errados, não importa o quão eficiente seja o chão de fábrica — o resultado é produção em massa de refugo.

Segunda barreira: integração de sistemas. A IA é excelente para gerar “um trecho de código”, “uma função”, “uma página”. Mas um sistema pronto para produção é a integração de centenas de fragmentos, que precisam trocar dados entre si, tratar casos de borda, manter consistência e resistir a falhas. Gerar fragmentos é barato; montar os fragmentos em um todo confiável é caro. Essa barreira tem raiz no alinhamento organizacional e de arquitetura — exatamente o que a Lei de Conway e o Team Topologies abordam (veja os dois primeiros artigos desta série). Voltando ao CIO do setor industrial citado no início: o tempo do projeto dele não foi gasto escrevendo código, e sim na integração entre os sistemas MES, ERP, controle de qualidade e reporte.

Terceira barreira: validação. O volume de código dispara, mas a confiabilidade varia. Quem decide que “está correto”? Testes, code review, observabilidade e deploy em canário — o peso dessas atividades de “validação” só aumenta. Essa é a barreira mais subestimada e a que mais espelha o setor industrial. Vou tratar dela em detalhe na seção 4.

Quarta barreira: alinhamento organizacional. Quando a equipe ganha agentes de IA, quem decide o que fazer, quem revisa, quem responde pelo resultado? Isso é mais uma extensão da Lei de Conway e do Team Topologies: o alinhamento organizacional em si vira gargalo. O artigo 11 da série vai abordar especificamente: quando os nós da organização não são todos humanos, como a governança vira diferencial competitivo.

3.5 — Evidência da mainstreamização no 1º semestre de 2026: o que o CIO do início viu já é fato no nível empresarial

Seis meses depois, o CIO do início desta história me contou uma mudança: ele levou o problema de “código escrito rápido, mas entrega que não anda” para a reunião mensal de gestão do grupo, e o grupo criou um escritório de integração interdepartamental, colocando os responsáveis pelas interfaces dos sistemas MES, ERP, qualidade e reporte na mesma mesa para alinhar tudo. A história desse CIO não é mais um caso isolado — no primeiro semestre de 2026, as maiores empresas de serviços profissionais do Ocidente já transformaram isso em estratégia de grupo.

EY (Ernst & Young) é a primeira “empresa pioneira” a implementar orquestração de agentes de IA em toda a organização, com um “cliente zero” interno. A Microsoft, na sua revisão do ano fiscal de 2026 (FY26), destaca o caso como referência: a EY implementou o Microsoft 365 Copilot para 150 mil funcionários, gerando uma economia de aproximadamente 2,5 milhões de horas e 250 milhões de dólares em custos operacionais; em seguida, expandiu o Microsoft 365 Frontier Suite para mais de 400 mil funcionários em todo o mundo. Os números concretos após a integração com os sistemas internos de produção são: redução de 95% no lead time de ponta a ponta, queda de 37% nos custos de operações financeiras e diminuição de até 90% na carga de trabalho manual nos processos de negócio críticos. Em um ano, a EY transformou o benefício de ferramentas que “aceleram a escrita de código com IA” em ganhos reais de “agilidade na execução de processos de negócio entre domínios”. Atenção: a história da EY não é sobre quantas linhas de código foram escritas, mas sobre como a empresa redesenhou a orquestração entre sistemas, processos e funções.

Atos, integradora global de sistemas de origem francesa, tornou público em junho de 2026 sua prática de “cliente zero”: implantou o Microsoft 365 Copilot para seus 56.000 funcionários em 54 países, usando o Microsoft Agent 365 como um plano de controle de governança unificado para gerenciar até 19.000 agentes de IA internamente. Isso é a prova mais direta de que “o alinhamento organizacional é o gargalo” — gerenciar as entradas, permissões, observabilidade e limites de segurança de 19.000 agentes é muito mais difícil do que fazer 19.000 agentes escreverem código. A própria Atos destaca: “Governança e segurança são o primeiro obstáculo da IA agêntica.”

KPMG, no mesmo período, anunciou uma parceria global com a Microsoft para levar o Agent 365 e o Copilot a mais de 100.000 profissionais em todo o mundo. Esse é um movimento emblemático que eleva a orquestração de agentes de “projeto de TI” para “infraestrutura de operações de negócios”.

Três coisas aconteceram de forma concentrada no mesmo mês — não é ritmo de marketing, é o nível real da TI empresarial: a conclusão comum das principais empresas de serviços profissionais do Ocidente é que orquestração de agentes, validação entre domínios e observabilidade de conformidade são o próximo grande gargalo da era da IA — e também o destino do próximo grande orçamento. Isso se alinha diretamente com a frase final da segunda seção: “o dinheiro da próxima camada está apenas começando a ser precificado.”

→

Fase 2 · Embedding em fluxos cross-domain (meio da EY / Atos) Agentes embutidos no fluxo de negócio Não apenas na IDE Lead time drasticamente reduzido EY: 95% faster Trabalho manual -37%~90% EY finanças / processos de negócio Integração entre sistemas Donos de interface juntos ~16~19% dos usuários de IA

→

Fase 3 · Governança de agentes (Atos 56K funcionários) 19,000 agent Governança unificada Agent 365 Plano de controle Permissões/observabilidade Limites de segurança Auditável/em conformidade Essencial em setores regulados Poucas cabeças em execução

Mesma regra: cada faixa alargada, a próxima bloqueia; codificar → fluxo entre domínios → orquestração de agentes
Proporção é indicativa, baseada na revisão FY26 da Microsoft, anúncio de junho da Atos/Microsoft, Índice de Tendências de Trabalho 2026 da Microsoft

Voltando ao CIO do início: o gargalo real dele era outra coisa — cada novo recurso precisava passar por MES, ERP, sistema de qualidade, terminais de chão de fábrica, além de um conjunto de requisitos de reporte regulatório. Integração e testes conjuntos consumiam a maior parte do cronograma. Seis meses depois, ele criou o “escritório de integração” — na prática, trilhou sozinho o mesmo caminho que EY / Atos já haviam percorrido. A diferença é que ele trilhou sozinho; as líderes ocidentais já transformaram isso em estratégia de grupo. É por isso que a frase inicial “o gargalo foi escolhido no lugar errado” é tão importante: o gargalo que você imagina já foi deixado para trás pela realidade, empurrado para a próxima etapa do processo.

Esta seção também ecoa o estudo atualizado que a METR publicou em fevereiro de 2026: na pesquisa inicial, desenvolvedores seniores foram 19% mais lentos com IA; em fevereiro de 2026, com uma nova rodada de experimentos em amostra maior, os mesmos desenvolvedores seniores inverteram para 18% mais rápidos (intervalo de confiança de -38% a +9%, evidência fraca); já os desenvolvedores recém-chegados tiveram -4% de aceleração. O sinal virar de negativo para positivo é exatamente a mudança de nível observada no primeiro semestre de 2026 — a IA passou de “atrasar” para “acelerar”. Traduzindo: se a aceleração se concretiza ou não, depende fortemente de você ter instalado aquela porta de verificação/alinhamento. É exatamente isso que EY / Atos estão fazendo — com a porta instalada, a aceleração é liberada; sem a porta, a aceleração é só um número bonito no papel.

Quatro: O corte mais profundo — verificação, e o que o “Jidoka” da Toyota realmente ensina

Das quatro gargalos, o mais mal interpretado é a verificação. Muita gente entende como “já que a IA escreve rápido, então é só rodar mais rodadas de teste”. Isso só está meio certo. Para entender por que a verificação ficou mais cara, primeiro é preciso explicar direito o conceito da Toyota que é mais citado — e mais distorcido — de todos: Jidoka (autonomação).

Antes de tudo, vamos corrigir um equívoco amplamente difundido. Jidoka não é “substituir pessoas por IA ou máquinas”, nem é “transformar a pessoa em máquina, trabalhando sem parar como uma máquina”. As duas leituras estão invertidas.

A palavra “autonomação” já carrega a resposta na própria escrita. Em japonês, “自動化” (jidōka) é a automação comum; a Toyota propositalmente usa “自働化” (jidōka com o radical de pessoa no kanji “働”), enfatizando a “automação com toque humano”. O significado exato é: quando a máquina ou a linha de produção detecta uma anormalidade, ela para automaticamente, permite que uma pessoa intervenha, resolva a causa raiz e só então retome a produção. Há dois mecanismos em paralelo: a máquina tem detecção de anomalias embutida e para sozinha; e qualquer pessoa na linha que perceba algo errado puxa o cordão andon (andon), parando a linha inteira imediatamente. A qualidade não é verificada no fim da linha, mas embutida em cada etapa do processo, resolvida ali mesmo.

Aqui há uma conclusão contraintuitiva que se aplica diretamente ao software: quanto mais profunda a automação, maior o peso do controle de qualidade e da intervenção humana — não o contrário. A autonomação liberta as pessoas do “trabalho repetitivo” e as reposiciona em “detectar anomalias, parar a linha, resolver a causa raiz”. A Toyota dá aos operadores de chão de fábrica o poder de parar a linha inteira justamente porque sabe: por mais forte que seja a automação, alguém precisa poder gritar “para!” quando algo dá errado. É exatamente isso que o slogan “dar inteligência às máquinas” quer dizer: dar à máquina a capacidade de parar e chamar um humano. O humano continua sempre presente, responsável por resolver a causa raiz.

O software está a percorrer esse mesmo caminho, e a passo acelerado. O estudo da GitClear sobre a qualidade de código assistido por IA já observou sinais de aumento de blocos de código duplicados e de churn de código a curto prazo: a IA escreve rápido, mas também escreve “aparentemente correto”. No primeiro semestre de 2026, a CodeRabbit analisou 470 PRs open source no seu próprio benchmark e descobriu que PRs colaborativos com IA têm, em média, 1,7 vezes mais problemas do que PRs humanos, com incidência concentrada em erros de lógica, omissões no tratamento de exceções e falhas de segurança. O número apresentado por Addy Osmani, engenheiro responsável na Google, é ainda mais contundente: a taxa de erros lógicos em código gerado por IA é 75% superior à dos humanos. O mercado de revisão de código com IA já movimenta cerca de 420 milhões de dólares em ARR em 2026, e 44% das equipas de desenvolvimento já utilizam alguma forma de IA para rever PRs — só a CodeRabbit conta com cerca de 140 mil developers pagantes no GitHub. Isto é o mercado a votar com os pés: o baixo custo da geração de código é pago com o custo da validação. Quando grandes volumes de código deixam de ser escritos linha a linha por alguém, o mecanismo tradicional de confiança — “o developer sabe o que está a fazer” — deixa de funcionar. O que precisas, então, é de uma versão de software do andon e do mecanismo de paragem de linha.

Testes (unitários, de integração, ponta a ponta) deixam de ser “algo bom de se ter” e viram requisito obrigatório — sem passar, não há merge;
Code review muda o foco de “verificar o estilo do código” para “verificar a intenção e os limites”: o que exatamente esse código está tentando resolver, e os casos de borda foram cobertos?
Ferramentas de code review assistidas por IA (CodeRabbit, Greptile, Copilot Reviews) assumem a primeira triagem — mas é preciso conhecer seus limites: IA revisando código gerado por IA deixa passar um tipo específico de problema. Primeira rodada com ferramenta, segunda com humano;
Observabilidade (monitoramento, logs, rastreamento) vira padrão, porque o comportamento em produção diz mais do que o próprio código;
Lançamento gradual / feature flags fazem o que a IA gerou ser validado primeiro em um escopo pequeno, e só depois de confirmado é que se expande.

Voltando aos 1.300 PRs da Stripe na segunda seção: escrever fica com o agente, mas a porta do merge fica toda com revisão humana. Esse é o exemplo vivo do jidoka no software: automatizar a produção, manter a aceitação nas mãos das pessoas e dar a elas o poder de “barrar”. Produzir ficou barato, controlar qualidade ficou caro — essa é uma regra que não muda há 40 anos.

Cinco: o prêmio de “definir o problema”: a habilidade que vale mais do que prompt

Se a validação é o gargalo subestimado, “definir o problema” é a habilidade severamente subestimada.

O prompt engineering já teve seu momento de fama, e muita gente acha que “saber escrever prompt” é a competência central. Mas o prompt é só a técnica de “expressar o problema”. O que é realmente escasso está um passo antes: problem formulation — transformar uma dor de negócio vaga em um problema claro, solucionável e que vale a pena resolver. Esse passo, a IA não consegue fazer tão cedo, porque ela depende de você primeiro dizer a ela “qual é o problema”.

Quem é veterano na manufatura sente na pele o peso desse passo. Se uma planta de engenharia ou uma rota de processo sai errada, não importa o quão eficiente seja a usinagem e a montagem a jusante — você está produzindo erros em massa. No software é a mesma coisa: se a especificação de requisitos sai errada, a IA vai te ajudar a fabricar, dez vezes mais rápido, um monte de coisa que ninguém quer.

O critério é direto: pare de competir em “velocidade de escrever código” e treine a “clareza de decompor problemas”. Dentro da organização, isso significa transformar “definição de requisitos” e “validação e aceite” em cargos formais, em vez de deixar o dev fazer por tabela. Agora que a IA barateou a implementação, são esses dois cargos que têm o retorno mais rápido.

Seis: Como é o gargalo real em quatro setores

Se você aplicar a ideia de “migração de gargalo” a quatro setores, o gargalo de nenhum deles está em escrever código.

Manufatura. A linha principal é o CIO mencionado na abertura. Funcionalidades como programação inteligente de produção, rastreabilidade de qualidade e otimização de consumo de energia não são tecnicamente difíceis — muitos dos modelos já estão prontos. O gargalo está na integração e nos testes conjuntos entre os sistemas MES / ERP / controle de qualidade / relatórios, além da validação em campo nos terminais da fábrica. Nesse tipo de projeto, o código costuma ser escrito rápido, mas a integração entre MES/ERP e os demais sistemas consome várias vezes mais tempo do que a codificação em si. Só colocando o posto de aceitação nos terminais da fábrica e na etapa de integração é que os defeitos podem ser interceptados ali mesmo, em vez de vazarem para a produção e só então aparecerem.

Telecom / Operadoras. Um processo de mudança de plano ou de ativação de um circuito dedicado empresarial atravessa vários domínios: canais, faturamento, CRM, ativação de rede e agendamento de instalação e manutenção. A IA acelerou o desenvolvimento em cada um desses domínios, mas é a integração ponta a ponta entre eles e a validação de consistência que consomem a maior parte do cronograma. As operadoras têm ainda um gargalo único: conformidade e conciliação. Um centavo errado na fatura já é uma ocorrência grave — o peso da validação aqui é maior do que em qualquer outro setor. Tomando como exemplo a ativação de um circuito dedicado empresarial: a IA agilizou o desenvolvimento em cada domínio, mas a integração ponta a ponta somada à conciliação de faturamento ainda costuma tomar mais da metade do cronograma.

Finanças. Um ajuste em uma regra de risco de crédito ou de combate à lavagem de dinheiro atravessa apps, sistemas core, motor de risco, data lake e reportes regulatórios. O peso da validação aqui é altíssimo, porque um erro significa um incidente de conformidade. O gargalo está em explicabilidade, auditabilidade e rastreabilidade: por mais precisa que seja a regra gerada por IA, se ela não passar pelo “por que essa decisão?” do regulador, não vai para produção. A iteração de regras de combate à lavagem de dinheiro é um exemplo clássico — pegue uma regra de detecção de “transação suspeita de alto valor”: a IA consegue gerar o rascunho da regra e a engenharia de features em poucas horas, mas a revisão de explicabilidade que vem depois é que é o verdadeiro osso duro de roer. O regulador exige que cada alerta venha acompanhado de contribuição de features, caminho de decisão do modelo e casos históricos similares — só com esses três elementos a regra vai para produção; se qualquer um deles não bater, a regra volta para a prancheta. A IA acelera a escrita da regra, mas a revisão de explicabilidade do modelo somada ao alinhamento com o reporte regulatório costuma consumir a maior parte do ciclo inteiro.

E-commerce. Uma funcionalidade de promoção ou campanha de grande volume atravessa catálogo, checkout, marketing, estoque e atendimento ao cliente. A IA acelera a geração de páginas e APIs, mas o gargalo migra para teste de carga, consistência de estoque, proteção contra fraude/abuso de cupom e conciliação. O que derruba o site na noite da grande promoção nunca é código que foi escrito devagar — é borda que não foi validada. A preparação para a grande promoção é um microcosmo disso: a IA gera a página promocional rapidinho, mas o teste de carga ponta a ponta e a validação de consistência de estoque costumam tomar a maior parte das horas de preparação.

Os pontos em comum entre os quatro setores são claros: o que a IA acelera é o “escrever”; o que trava é o “integrar, validar e alinhar”. Investir a capacidade de desenvolvimento economizada nessas três frentes é que é, de fato, ganhar eficiência.

Se você é CIO do departamento de tecnologia da informação da China Telecom ou de algum banco de capital aberto, ao ler até aqui provavelmente vai pensar: será que a gente também é assim? Sendo honesto, o nível de maturidade está meio passo a um passo atrás das líderes dos EUA e da Europa, mas a estrutura é idêntica. No lado das operadoras, a ativação de linhas dedicadas para clientes corporativos e a integração ponta a ponta da conciliação de faturamento ainda são o maior gargalo de prazo. Com a IA acelerando o desenvolvimento em cada domínio, a consistência entre domínios virou o novo gargalo; várias províncias já colocaram um “escritório de integração” ou um “PMO transversal” sob o guarda-chuva do CIO. No lado financeiro, a iteração de campos para reportes regulatórios, a revisão de explicabilidade para a implantação de regras de combate à lavagem de dinheiro e o alinhamento de critérios para inspeções in loco do Banco Central e da Comissão Reguladora de Seguros costumam consumir mais de 60% do tempo de trabalho de uma funcionalidade. Em ambos os casos, não é falta de ferramenta — é a porta do alinhamento organizacional que não foi instalada. E essa porta é exatamente o que a EY e a Atos, na Europa e nos EUA, já instalaram.

Sete — E se a avaliação estiver errada? Os três erros de alinhamento mais comuns

Primeiro: confundir “escrever código rápido” com “entregar mais rápido”. Essa é a ilusão mais comum. O código é apenas um elo da cadeia de entrega; alargá-lo não acelera a cadeia inteira — só faz acumular mais trabalho em andamento atrás do gargalo. A Teoria das Restrições chama isso de estoque; no software, são PRs não aprovados e branches que nunca foram integrados. O resultado? Desenvolvedores mais ocupados, negócios mais ansiosos e nenhuma melhoria na entrega — exatamente a situação do CIO mencionado no início.

Segundo: acelerar a produção enquanto se desmonta o controle de qualidade. Esse é o erro clássico de violar o princípio do jidoka (autonomação). Alguns acham que “a IA escreve rápido e bem, então podemos simplificar o code review e cortar os testes”. Muito pelo contrário: quanto mais rápida a produção, mais crítico é o cordão andon. Os dados da CodeRabbit de 2026 mostram que PRs assistidos por IA têm uma densidade de defeitos 1,7 vez maior do que PRs humanos. Eliminar as etapas de validação é o mesmo que deixar uma linha de produção em velocidade máxima sem ninguém supervisionando — os defeitos vão se espalhar para o ambiente de produção ainda mais rápido.

Terceiro: investir dinheiro em pontos que não são o gargalo. A integração é o gargalo, mas você compra mais licenças de IA para codificação; a validação é o gargalo, mas você contrata mais desenvolvedores. A Teoria das Restrições já deixou isso claro: investir em não-gargalos não contribui em nada para a produção total — só piora o resultado no papel. A ordem correta é primeiro identificar o gargalo e só então concentrar os recursos nele.

Oito: O que os líderes devem tirar disso

Lição um: antes de comprar ferramentas, desenhe um mapa dos gargalos. Analise as três últimas entregas em que você travou e veja onde o tempo realmente foi parar. Foi na hora de escrever o código, ou em juntar as peças, na falta de validação, ou nos requisitos mal definidos? Se você não consegue apontar, está chutando no escuro ao nível da tecnologia. O mapa de gargalos vale mais do que qualquer lista de compras de ferramentas — ele consegue cortar pelo menos metade do investimento inútil em TI nas grandes empresas.

Lição dois: invista a capacidade ociosa em requisitos e validação. A IA acelera o desenvolvimento, o que significa que você pode liberar gente. Coloque essas pessoas oficialmente em duas funções: “definição de requisitos” e “validação e aceite”. Não deixe que continuem enfiados escrevendo mais código. O retorno dessas duas funções é o que mais cresce na era da IA.

Lição três: instale uma corda andon no software. A forma mais direta de colocar o jidoka em prática é criar barreiras rígidas no seu CI/CD: sem teste passando, nada de merge; review tem que olhar intenção e limites; canário primeiro em escala pequena; observabilidade como padrão. Quanto mais automatizada a produção, mais sólida essa barreira precisa ser. Isso é para evitar que “código grátis” vire “acidente grátis”.

Lição quatro: reposicione as pessoas, não as remova. O jidoka aponta para a mesma conclusão: quanto mais profunda a automação, mais as pessoas precisam estar em posições de “julgamento, aceite e análise de causa raiz”. Libertar as pessoas de tarefas repetitivas e realocá-las para validação e alinhamento — esse é o movimento central do design organizacional na era da IA, e é o que os próximos artigos desta série vão desenvolver.

Nove: o que você deve estar se perguntando

“Estamos só fazendo um piloto de IA em uma área específica, não precisamos mapear os gargalos da empresa inteira, certo?” Mesmo num piloto, é preciso enxergar com clareza: a etapa escolhida é realmente o gargalo? Se o ponto crítico está na integração ou na validação, pilotar IA na etapa de “escrever código” é jogar dinheiro num ponto que não é gargalo — exatamente o terceiro tipo de desalinhamento mencionado na Seção 7. Faça primeiro um diagnóstico de gargalos em escala reduzida; só assim o investimento em ferramentas se justifica.

“Os portais de validação não vão atrasar a entrega?” No curto prazo, há atrito; no longo prazo, é aceleração. A “rapidez” sem portais de aceitação é a rapidez que empurra defeitos para o ambiente de produção — e o custo de retrabalho multiplica por dez. A lição do jidoka (autonomação) é clara: o custo de resolver um defeito no local onde ele ocorre é uma fração mínima do custo de deixá-lo fluir para as etapas downstream.

“E qual é a relação disso com a transformação de IA que estamos tocando?” A relação é direta. O erro mais comum em transformações de IA é assumir que o gargalo está em “escrever código / capacidade de produção” e, então, comprar um monte de ferramentas para alargar essa etapa. Primeiro faça o diagnóstico de gargalos; depois decida onde investir. É por isso que coloco a “avaliação de capacidade” e a “identificação de casos de valor” logo no início do Framework de Coaching em 7 Passos para Transformação de IA: primeiro, identifique onde está o gargalo; depois, fale de ferramentas.

Autoverificação reversa (não embeleze ao responder): na última entrega em que você travou, o tempo foi gasto escrevendo código ou juntando as peças, validando e alinhando? Suas ferramentas de IA geram um monte de código — quanto disso realmente chega à produção de forma estável e é usado por usuários de verdade? No seu CI/CD, existe uma barreira rígida do tipo “sem teste passando, sem merge”? Se você hesitou em qualquer uma das três perguntas, pare de comprar mais ferramentas de IA e primeiro descubra onde está seu gargalo.

Próximo passo

Este é o terceiro de 15 artigos da série “A Transformação da Engenharia de Software na Era da IA”. Partimos de Conway (a organização determina a arquitetura), passamos por Team Topologies (como desenhar a organização), e chegamos ao deslocamento do gargalo (quando o código é quase gratuito, para onde vai o gargalo?). O próximo artigo (nº 4) muda para uma perspectiva mais prática: como escolher as principais ferramentas de programação com IA. Mas a conclusão pode contrariar a intuição: a escolha, no fim das contas, é uma decisão organizacional — você deve escolher com base no seu nível de maturidade e governança, não em “quem escreve o código mais impressionante”.

A estrutura do mercado no primeiro semestre de 2026 já empurrou a urgência dessa questão para a mesa do CIO: a aquisição da Cursor pela SpaceX por US$ 60 bilhões, os US$ 2,5 bilhões de ARR da Claude Code, e o relatório conjunto da Gartner com a Microsoft apontando “governança de IA como o primeiro gargalo” — três sinais que, somados, indicam que o dinheiro na camada de “geração de código” já foi ganho. A próxima camada de valor está em validação, alinhamento e orquestração. Os próximos artigos (nº 9 da série, Maturidade das Ferramentas de Programação com IA; nº 11, Quando os Nós da Organização Não São Todos Humanos; e o extra Aderência do Software Empresarial) vão aprofundar cada um desses pontos.

Nota da série: Esta série acompanha continuamente a evolução mais recente das ferramentas de programação com IA, das estruturas organizacionais e dos paradigmas de engenharia de software, cobrindo as novas mudanças na Lei de Conway na era dos agentes de IA, a maturidade do ecossistema de ferramentas mais recente e outros temas. Siga a série para receber pesquisas atualizadas.

Se este artigo tocou exatamente no problema que sua empresa está enfrentando — “um ano de ferramentas implantadas, milhões em licenças gastos, e o ritmo de entrega não mudou” — vale a pena continuar lendo.

Sou ex-engenheiro da IBM e coach certificado pela ICF, com experiência na implementação de projetos de IA e transformação digital em operadoras e grandes empresas. Três caminhos possíveis:

Treinamento interno corporativo (¥30 mil/dia, 3 dias ≈ ¥90 mil): percorremos todo o fluxo de “redesenho de gargalos + capacidade de ferramentas vs. implantação em escala”, com análise aplicada ao cenário real da sua empresa.
Consultoria avulsa (¥5 mil/hora): foco na sua dúvida mais crítica (ex.: “nossa empresa comprou ferramentas de IA há um ano, por que a entrega não ficou mais rápida?”).
Palestras para governo/fóruns: temas relacionados à transformação de IA.

Contato: coach@iaiuser.com, ou deixe seu cenário específico nos comentários.

Leitura complementar da Série B: veja a Metodologia Principal v1.0 (Aprenda IA aos Poucos, 187).

Sobre esta série

“Transformação da Engenharia de Software na Era da IA” é uma série de pesquisa aprofundada voltada para CIOs, CDOs, CTOs e líderes de transformação digital nos setores de telecomunicações, finanças, manufatura e e-commerce, com 15 artigos no total. Baseada em mais de 200 artigos acadêmicos e relatórios do setor, oferece referências de decisão com níveis de evidência claramente indicados.

Sou ex-engenheiro da IBM e coach certificado pela ICF, com experiência na implementação de projetos de IA/digitalização para operadoras e grandes empresas. O que escrevo aqui são percepções práticas adquiridas ao lado de empresas que enfrentaram desafios reais.

Nos últimos anos, acompanhei projetos que vão desde linhas dedicadas para clientes corporativos / conciliação de faturamento em operadoras de telecomunicações, passando por regras antilavagem de dinheiro e envio de relatórios ao Banco Central em bancos de capital aberto, até integração entre MES / ERP / controle de qualidade em grupos industriais, além de testes de carga e governança de consistência de estoque durante a preparação para grandes promoções no e-commerce. O roteiro mais comum é: ferramentas implantadas ao longo de um ano, licenças custando milhões, e o ritmo de entrega não muda — o problema está exatamente no que este artigo aborda: “escolhemos o gargalo errado”.

Fontes de referência (todas verificadas)

a16z (2026). Software in the Age of Agents. O podcast a16z. (A frase marcante do ex-presidente da Microsoft Windows, Steven Sinofsky: “A cauda longa não ficou mais curta, apenas ficou mais longa de uma forma diferente” — confirma de forma independente, sob a ótica do software empresarial, a lei da realocação de gargalos da TOC; fonte primária — áudio original do podcast. Nota de posicionamento: sócio da a16z / ex-executivo da Microsoft, viés de VC. Convidados verificados: Seema Amble, sócia do time empresarial da a16z; Steven Sinofsky, ex-presidente da Microsoft Windows (board partner); Elena Burger, redatora da a16z; exibido em julho de 2026.)
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (A fonte original da Teoria das Restrições (TOC), fonte primária; um romance ambientado no chão de fábrica de uma empresa manufatureira.)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press.（Transposição direta da TOC de Goldratt para a Operação de TI — a ponte entre manufatura e software; fonte primária.）
Toyota. Toyota Production System — Jidoka. toyota-global.com（自働化 = automação com toque humano: parada de linha em caso de anomalia + intervenção humana para análise de causa raiz; sistema Andon; fonte primária.）
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle.（O Copilot conclui cerca de 46% do código nos arquivos em que está habilitado, na métrica “arquivo habilitado”; fonte primária.）
Stripe (2026-02). Minions: os agentes de codificação one-shot e de ponta a ponta da Stripe. stripe.dev/blog.（Os Minions geram 1.300+ PRs por semana, com revisão 100% humana; nível 1 + vídeo How I AI de 2026-03, onde Steve Kaliski confirma pessoalmente: “nem me lembro da última vez que comecei uma tarefa no editor”）
NVIDIA / Jensen Huang. Declaração pública de que 100% dos engenheiros usam ferramentas de programação com IA como Cursor (fala em primeira mão)
Anysphere / Cursor (Rodada Série D em nov/2025 / negociação em abr/2026 / aquisição pela SpaceX em jun/2026). Valuation de US$ 29,3 bilhões → US$ 50 bilhões em negociação → US$ 60 bilhões na aquisição; ARR de US$ 1 bilhão+ no fim de 2025, US$ 2 bilhões+ no início de 2026. Nota de posicionamento: incorporada à SpaceX como subsidiária SpaceXAI; fontes de valuation: Accel / Coatue / a16z / Thrive / Nvidia / Google. Wikipedia + tech-insider.org + valueaddvc.com (múltiplas fontes cruzadas, secundárias).
Anthropic (fev/2026). ARR do Claude Code atingiu US$ 2,5 bilhões; ARR total da Anthropic chegou a US$ 30 bilhões em abr/2026. Nota de posicionamento: divulgação oficial da Anthropic + cobertura secundária da Time Magazine / Reuters. Assinaturas comerciais quadruplicaram em 2026, e o número de usuários ativos semanais dobrou desde janeiro.
GitClear (2025). Pesquisa sobre qualidade de código assistida por IA.（Observou aumento de código duplicado / churn de curto prazo sob assistência de IA, apoiando a tese de que “validar ficou mais caro”, nível secundário）
Microsoft (2026-07-28). Olhando para trás no FY26 da Microsoft: Da experimentação com IA à transformação de fronteira.（150 mil funcionários da EY usando Copilot + 2,5 milhões de horas / US$ 250 milhões em economia + 95% de aceleração no lead time + 37% de redução de custos financeiros + até 90% de redução de trabalho manual; artigo de retrospectiva do FY26, nível primário）**Nota de posicionamento: blog oficial da Microsoft, viés de fornecedor de ferramentas.
Microsoft / Atos (2026-06-09). Atos Group e Microsoft expandem colaboração estratégica para escalar IA agêntica segura. (56.000 funcionários da Atos + 19.000 agentes unificados sob governança do Agent 365; 54 países; primeira integradora de sistemas global francesa a implantar nessa escala, anúncio oficial de primeira linha + análise independente da Futurum Group em 2026-06-09) Posicionamento: anúncio conjunto da Microsoft e Atos, posição de fornecedor de ferramentas + integrador de sistemas.
Microsoft 2026 Work Trend Index (2026-05). 2026 Work Trend Index Annual Report. (Frontier Professionals representam 16–19%; Frontier Firms são a “zona ideal” onde capacidade organizacional e individual estão ambas em alto nível; número de agentes cresceu 15x ano a ano, 18x em grandes empresas; 66% dos usuários de IA relatam ter mais tempo para trabalho de alto valor, relatório de segunda linha)
METR (2026-02-24). *Estamos mudando o design do nosso experimento de produtividade para desenvolvedores.*（Em 2025-07, desenvolvedores seniores ficaram 19% mais lentos → Em 2026-02, os mesmos seniores aceleraram 18% (CI de -38% a +9%, evidência fraca); novos desenvolvedores aceleraram 4%; pré-print de nível 1 / atualização do experimento）
METR (2026-05-11). *Medindo o impacto autorrelatado da IA do início de 2026 na produtividade de trabalhadores técnicos.*（349 trabalhadores técnicos relataram valor mediano da IA entre 1,4x e 2x; existe um viés cognitivo de “autorrelato acima da medição real”, nível 2）
CodeRabbit (2026). Benchmark de 470 PRs de código aberto: PRs com colaboração de IA geram 1,7x mais problemas do que PRs humanos; mercado total de revisão de código com IA em 2026: US$ 420 milhões; aproximadamente 140 mil desenvolvedores pagantes. Classificação da fonte: dados próprios da CodeRabbit + avaliação do Git AutoReview em 29/04/2026 (nível secundário). Dados de Addy Osmani (engenheiro líder do Google): código gerado por IA apresenta taxa de erro lógico 75% maior — nível secundário / declaração em primeira mão.
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (O desempenho de entrega é determinado pela cultura, fluxo e feedback, não pela velocidade individual de codificação — nível primário.)