Durante muito tempo, uma parte importante da conversa sobre produtividade em software girou em torno de escrever código mais rápido. Primeiro vieram frameworks, bibliotecas, geradores, boilerplates e plataformas. Depois vieram pipelines mais maduros, automação de testes, cloud, observabilidade e práticas melhores de entrega. Agora, com copilots, agentes e modelos capazes de gerar, revisar e explicar código, o custo de transformar intenção em implementação caiu de novo.
E caiu bastante.
O problema é que muita gente está olhando para essa mudança com a lente errada. Porque, em times minimamente maduros, o principal gargalo já não era digitar código há algum tempo. O gargalo estava — e continua estando — em entender o que precisa ser construído, encaixar isso no sistema existente, revisar impacto, validar comportamento, integrar com segurança e operar a mudança depois que ela chega em produção.
A IA deixou isso mais visível. Muito mais visível!
Se antes o time já sofria para revisar mudanças com profundidade, a geração mais rápida aumenta a fila. Se o sistema já tinha boundaries frágeis, a IA ajuda a produzir alterações locais mais rápido, mas não resolve o impacto sistêmico. Se o domínio já era mal entendido, o modelo pode gerar código plausível em cima de premissas erradas. Se observabilidade já era fraca, mais mudanças só aumentam a chance de descobrir problemas tarde demais.
É por isso que, para mim, a pergunta mais importante agora não é “quanto mais rápido conseguimos escrever código com IA?”. A pergunta é outra: Quanto de mudança adicional nosso sistema técnico e organizacional consegue absorver sem perder qualidade?
Produtividade individual não é o mesmo que capacidade sistêmica
Eu não sou cético em relação ao ganho de produtividade com IA. Ele existe. Em várias atividades, a diferença é nítida: explorar código desconhecido, gerar testes iniciais, montar alternativas de implementação, escrever documentação, revisar edge cases, resumir PRs, criar scripts auxiliares ou acelerar uma investigação.
O DORA 2025 vem mostrando esse movimento de forma interessante. O relatório de 2025 sobre desenvolvimento assistido por IA descreve a IA como um amplificador: ela amplia forças e fraquezas já existentes na organização. O ganho não vem simplesmente da ferramenta, mas da capacidade do sistema de trabalho em absorver bem essa nova velocidade.
Se uma pessoa consegue produzir mais rápido, mas o time não consegue revisar, integrar e operar com a mesma maturidade, o ganho local vira pressão sistêmica. O output sobe, mas o throughput real pode não acompanhar. O time parece mais rápido, mas começa a pagar em filas de review, retrabalho, aumento de batch size, bugs sutis e mais esforço de coordenação. É a diferença entre acelerar uma etapa do fluxo e aumentar a capacidade do sistema inteiro.
Essa distinção é antiga em engenharia, mas ficou mais importante agora. Quando uma etapa fica muito mais barata, o gargalo não desaparece. Ele se desloca.
Um cenário simples: a squad que dobrou o número de PRs
Imagine uma squad com cinco engenheiros, uma pessoa de produto e uma designer. Antes de adotar IA de forma mais intensa, esse time abria em média 8 PRs relevantes por semana. Havia algum atrito, claro, mas o sistema funcionava. As reviews eram cuidadosas, os testes protegiam uma parte razoável dos fluxos, e o time conseguia manter uma cadência previsível.
Agora esse mesmo time passa a usar IA no dia a dia. Investigações ficam mais rápidas. Refactors começam a sair da gaveta. Testes que antes ficavam para depois passam a ser gerados com menos esforço. Documentação técnica melhora. O número de PRs relevantes sobe para 18 ou 20 por semana.
Olhando apenas para volume, parece uma vitória. Mas o sistema inteiro não mudou junto.
A capacidade de review continua parecida. A maturidade dos testes não dobrou. O entendimento de domínio não dobrou. A observabilidade não ficou automaticamente melhor. O pipeline não ficou mais inteligente só porque a geração ficou mais barata. O PM agora recebe mais alternativas de solução, mas também precisa gastar mais energia para separar proposta boa de proposta apenas plausível.
Depois de algumas semanas, os sinais começam a aparecer. Reviews ficam mais superficiais. Alguns PRs pequenos carregam impactos maiores do que pareciam. O time começa a discutir mais correções posteriores. A sensação é estranha: todo mundo está produzindo mais, mas a previsibilidade não melhorou na mesma proporção. Esse é o ponto em que eu digo que o novo gargalo não é escrever código. É absorver mudança com qualidade.
A IA não commoditizou software inteiro
Eu acho importante separar as coisas. A IA está tornando mais barato produzir partes do trabalho de engenharia. Ela ajuda a materializar propostas, navegar código, gerar scaffolding, criar testes iniciais, explicar trechos, sintetizar documentação e acelerar investigações. Isso é valioso. Mas isso não significa que ela commoditizou software inteiro.
Software real continua exigindo decisões de domínio, escolhas arquiteturais, trade-offs, integração com sistemas existentes, gestão de risco, rollout, observabilidade, segurança e responsabilidade sobre o que acontece depois que a mudança entra em produção.
O que a IA reduz é o atrito de produzir uma proposta. O que continua caro é decidir se aquela proposta é correta para o contexto.
Esse ponto conversa diretamente com o artigo Structured Prompt-Driven Development: quando o prompt vira artefato de engenharia. Ali, a ideia principal é tratar prompt não como conversa descartável, mas como artefato que captura intenção, restrições e contexto. Isso é importante justamente porque o problema não é apenas gerar código. O problema é garantir que aquilo que foi gerado esteja alinhado ao domínio, à arquitetura e às salvaguardas do sistema. Quando produzir ficou mais fácil, intenção e contexto ficaram mais valiosos.
O gargalo migra para revisão
Revisão é um dos primeiros lugares em que esse deslocamento aparece.
Se a geração acelera, mas a revisão continua dependendo da mesma capacidade humana, a fila cresce ou a profundidade cai. Em alguns casos, as duas coisas acontecem ao mesmo tempo: PRs passam mais tempo abertos e, quando finalmente são revisados, recebem uma revisão mais superficial do que deveriam.
Esse é um problema importante porque review não é só inspeção de sintaxe. Em times bons, review é onde muita coisa invisível aparece: aderência ao domínio, consistência com padrões do sistema, compatibilidade com contratos, impacto em operação, legibilidade futura, segurança, performance e risco de regressão.
A IA pode apoiar parte dessa revisão, mas ela não elimina a necessidade de julgamento. Na verdade, pode aumentar a necessidade dele. Quanto mais fácil é gerar código plausível, mais importante fica a habilidade de identificar quando aquele código é apenas plausível — e não adequado.
Aqui mora uma armadilha elegante. O PR parece bom. O teste passa. O diff é razoável. Mas a mudança carrega uma premissa de domínio errada, ignora uma exceção histórica ou altera um comportamento que outro serviço dependia silenciosamente. O modelo não “errou” de forma óbvia. Ele apenas não tinha todo o contexto necessário para entender a consequência.
É por isso que revisão continua sendo gargalo. Não porque as pessoas sejam lentas, mas porque entendimento sistêmico não escala na mesma velocidade da geração.
O gargalo migra para integração
O segundo gargalo aparece na integração. Um código pode estar correto localmente e ainda assim gerar impacto ruim no sistema. Isso sempre foi verdade, mas fica mais crítico quando produzimos mais mudanças em menos tempo.
Imagine um e-commerce ajustando a regra de frete grátis para uma campanha. A IA ajuda a gerar rapidamente uma proposta de implementação. Ela sugere alterações no serviço de carrinho, adapta testes, produz um rascunho de documentação e até ajuda a montar o plano de rollout. Tudo parece eficiente.
Só que a regra impacta mais do que o serviço onde o código foi alterado. Ela mexe com pricing, checkout, exibição na página de produto, analytics e talvez uma fila downstream usada por outro time. Se esses contratos não estão claros, a mudança pode entrar rapidamente e quebrar de forma distribuída.
O problema não é a IA. O problema é a arquitetura de integração. Esse ponto conversa muito com o artigo Quando o microserviço está separado no repositório, mas não na cabeça do time. Separar serviços no código não significa separar entendimento. Se uma mudança local exige contexto sistêmico demais, a arquitetura continua cognitivamente acoplada. A IA pode acelerar a alteração local, mas não desfaz esse acoplamento.
Na prática, isso significa que quanto mais rápida fica a geração de código, mais importante fica ter boundaries claros, contratos explícitos, testes de contrato, observabilidade entre serviços e caminhos de rollback bem definidos.
Sem isso, a IA apenas aumenta a velocidade com que mudanças locais chegam a um sistema mal preparado para absorvê-las.
O gargalo migra para entendimento de domínio
Existe outro ponto ainda mais delicado: domínio. Fred Brooks já dizia, há décadas, que a parte mais difícil de construir software é decidir precisamente o que precisa ser construído. Essa frase ficou ainda mais atual agora. Se o custo de escrever caiu, entender o que deve ser escrito ficou proporcionalmente mais importante.
A IA pode gerar uma implementação bonita para uma regra mal formulada. Talvez criar testes coerentes com uma premissa errada. Pode produzir documentação convincente para uma decisão ruim. Pode transformar ambiguidade em código com uma velocidade impressionante. Isso não é necessariamente um ganho.
Se o time não entende bem o domínio, a IA pode acelerar a cristalização de mal-entendidos. O output fica mais polido, mas a compreensão não necessariamente melhorou.
Esse é um risco especialmente grande em sistemas de negócio complexos: financeiro, marketplace, logística, billing, antifraude, elegibilidade, pricing, fiscal, compliance. Nesses domínios, a dificuldade raramente está em escrever um if. A dificuldade está em saber exatamente qual regra deveria existir, onde ela deveria morar, quais exceções importam e que comportamento legado não pode ser quebrado.
Quando o entendimento de domínio é raso, a IA pode gerar mais rápido. Mas gerar mais rápido a coisa parcialmente errada continua sendo dívida.
O gargalo migra para observabilidade
Outro lugar em que a absorção de mudança aparece é produção. Mais mudanças exigem mais capacidade de observar efeitos. Se a geração acelera, mas a observabilidade continua fraca, o time só descobre problemas tarde demais.
Isso vale para software tradicional e vale ainda mais para sistemas com agentes. No artigo Observabilidade para agentes: por que logs e traces tradicionais já não bastam, a tese era que sistemas com IA não podem ser observados apenas por latência, erro e infraestrutura. Também precisamos observar trajetória, contexto, ferramentas e qualidade da decisão.
A mesma lógica vale aqui em sentido mais amplo: se o fluxo de mudança acelera, a capacidade de observar degradação precisa acelerar junto.
Não basta saber que o deploy terminou. Eu preciso saber se comportamento mudou, se alguma métrica de negócio desviou, se a taxa de erro subiu em um segmento específico, se um contrato implícito foi quebrado, se o rollback é seguro e se o time consegue entender rapidamente o que aconteceu.
Sem observabilidade suficiente, mais velocidade de geração vira mais velocidade de surpresa.
Um exemplo de mundo real: DORA e o paradoxo da IA
Os relatórios recentes do DORA ajudam a colocar números nessa discussão. Em 2024, o DORA mostrou um cenário bem contraintuitivo: a adoção de IA estava associada a maior produtividade individual, flow e satisfação, mas também a impactos negativos em estabilidade e throughput de entrega. Um relatório específico sobre IA generativa em desenvolvimento chegou a apontar que um aumento de 25% na adoção de IA estava associado a queda de 1,5% em throughput de delivery e queda de 7,2% em estabilidade.A leitura mais interessante não é “IA piora software”. Essa seria uma conclusão pobre.
A leitura interessante é: IA muda a dinâmica do sistema. Ela acelera produção local e pressiona os mecanismos de absorção. Se esses mecanismos não são bons — batch size pequeno, testes robustos, revisão madura, plataforma consistente, observabilidade boa — o ganho individual pode se transformar em instabilidade sistêmica. Em 2025, o DORA também trouxe uma leitura mais madura: a IA aparece como amplificador. Organizações com boas bases conseguem capturar melhor o ganho. Organizações com sistemas frágeis amplificam a própria fragilidade.
Para mim, essa é a leitura correta. A IA não substitui fundamentos. Ela cobra fundamentos com mais força.
Um exemplo de mundo real: produtividade medida no código pode enganar
Outro dado interessante vem de estudos e análises de produtividade com IA em escala. Há relatos de aumento de volume de código, aumento de PRs e redução de tempo em partes do ciclo. Ao mesmo tempo, pesquisas em projetos maduros de open source mostraram resultados menos óbvios: em um experimento com desenvolvedores experientes trabalhando em projetos que conheciam bem, o uso de ferramentas de IA aumentou o tempo de conclusão das tarefas em 19%, apesar de os próprios participantes esperarem o contrário.
Esse contraste é útil porque mostra que “IA aumenta produtividade” não é uma afirmação universal. Depende do contexto, do tipo de tarefa, da maturidade do código, do conhecimento prévio do desenvolvedor, do custo de validação e do padrão de qualidade exigido.
Em uma base simples, com tarefas bem delimitadas, a IA pode acelerar muito. Em uma base madura, complexa, com padrões rigorosos e alto custo de revisão, a história pode ser diferente.
Essa diferença reforça a tese do artigo: o gargalo não está apenas na geração. Está no custo de compreender, validar e integrar a mudança.
A nova dívida técnica: mudança demais para um sistema absorver
Eu chamaria esse fenômeno de uma nova forma de dívida técnica.Não é necessariamente a dívida clássica do código ruim, embora ela continue existindo. É a dívida criada quando o time passa a produzir mais mudanças do que consegue absorver com qualidade.
Ela aparece quando PRs crescem mais rápido que a capacidade de review. Quando testes gerados aumentam quantidade, mas não protegem o comportamento certo, quando documentação aumenta, mas não melhora entendimento, quando agentes geram soluções locais sem respeitar constraints globais, quando o time aceita outputs plausíveis sem construir compreensão equivalente. Essa dívida é perigosa porque, no começo, parece produtividade.
O time entrega mais. Gera mais. Explora mais. Documenta mais. Mas, aos poucos, os juros aparecem em retrabalho, regressões, incidentes pequenos, perda de clareza, dependência de especialistas e aumento do tempo necessário para entender uma mudança.
É uma dívida de absorção.
Como uma arquitetura saudável absorve mudança
Uma arquitetura preparada para esse novo cenário não é necessariamente a mais sofisticada. É a que cria bons mecanismos de absorção.
Ela reduz o contexto necessário para mudanças comuns. Esse ponto conecta diretamente com o artigo A próxima geração de arquitetura será julgada por tempo de entendimento, não só por tempo de resposta. Se uma pessoa precisa fazer arqueologia técnica para validar um PR gerado em minutos, o sistema não ganhou tanta produtividade quanto parece.
Ela usa plataforma para encapsular o que é repetitivo. Esse ponto conecta com Reduzir carga cognitiva é uma decisão arquitetural. A plataforma não deveria existir apenas para padronizar por gosto, mas para impedir que cada squad precise reaprender CI/CD, observabilidade, segurança e runtime a cada mudança.
Ela trata contexto como parte do sistema. Isso conecta com Context engineering: quando o problema deixa de ser prompt e vira arquitetura. Se a IA depende de contexto para gerar bem, então contexto crítico não pode ficar apenas na cabeça das pessoas ou perdido em conversas.
Ela torna intenção e restrições revisáveis. Aqui entra de novo o SPDD. Prompt, ticket, ADR, RFC, teste de contrato e documentação viva são mecanismos para fazer o sistema lembrar o que a conversa humana tende a esquecer.
E ela observa produção com granularidade suficiente para detectar degradação antes que ela vire incidente grande.
A métrica errada ficou mais perigosa
Se antes já era ruim medir produtividade por volume de código, agora isso ficou ainda mais perigoso.
Código ficou mais fácil de gerar. Documentação ficou mais fácil de gerar. Testes ficaram mais fáceis de gerar. Propostas ficaram mais fáceis de gerar.Isso significa que volume ficou uma métrica ainda mais fraca.
Um time pode produzir mais PRs e ainda assim piorar estabilidade. Pode gerar mais testes e ainda não cobrir os riscos certos. Pode criar mais documentação e ainda não melhorar entendimento e pode entregar mais “movimento” sem entregar mais capacidade real.
A pergunta que eu passaria a fazer é outra: o aumento de output reduziu lead time sem aumentar retrabalho? Melhorou estabilidade? Melhorou clareza? Reduziu dependência de especialistas? Aumentou confiança de deploy? Reduziu tempo de entendimento?
Se a resposta for não, talvez a organização esteja apenas deslocando custo de um lugar para outro.
Fechando a ideia
A IA reduziu o custo de escrever código, mas não eliminou o custo de mudar sistemas reais. E sistemas reais não mudam apenas quando alguém escreve uma função. Eles mudam quando uma ideia atravessa domínio, arquitetura, revisão, testes, integração, rollout, observabilidade e operação sem quebrar o que importa.
É por isso que o novo gargalo não é escrever código. É absorver mudança com qualidade.
Quanto mais barato fica produzir mudança, mais importante fica ter uma arquitetura, uma plataforma e um sistema de trabalho capazes de metabolizar essa mudança com segurança. A diferença entre times que vão capturar valor real com IA e times que só vão produzir mais ruído não estará apenas na ferramenta escolhida. Estará na maturidade do sistema que recebe essa nova velocidade.
