A piada de Solow de 1987 — “vemos os computadores em todo o lado, exceto nas estatísticas da produtividade” — ganhou remake em 2025, com orçamento maior. Centenas de milhões de pessoas consultam IAs diariamente. Eu mesmo uso, e uso muito. Mas quando olhamos para os números oficiais do PIB, a revolução parece ter acontecido só na conta de investimento: betão, chips, turbinas. Não nos salários, não na produtividade agregada, não no tal “retorno”.
Segundo o Observador.pt, que destrinçou o tema com rigor, Jason Furman calculou que no primeiro semestre de 2025 o investimento em equipamento de processamento de informação representou cerca de 92% do crescimento do PIB americano. Retire-se isso e a maior economia do mundo cresceu 0,1% anualizado — um erro de arredondamento. A charrua está toda nas estatísticas. A colheita, não.
Como programador, isso me interessa por um motivo direto: nós somos, no papel, os maiores “consumidores” desta tecnologia. Se alguém deveria ver ganho de produtividade no chão de fábrica digital, somos nós. Spoiler: também não estamos vendo.
O paradoxo de Solow, agora com LLM
Em 1987, Robert Solow disse a frase. Em 2025, segundo o Observador.pt, as projeções divergem por uma ordem de grandeza: a Goldman Sachs estima um ganho de 7% no PIB mundial por IA; a McKinsey vê até 3,4 pontos percentuais adicionais de crescimento anual; e Daron Acemoglu, fazendo a aritmética tarefa a tarefa, chega a 0,66% de PTF no total ao longo de uma década — cerca de 0,05% ao ano.
Quando estimativas de gente séria diferem por um fator de cem, a pergunta que vale não é “quem tem razão” — é por que o objeto é tão difícil de ver. A resposta tem três peças, e cada uma tem implicações práticas brutais para quem programa.
O PIB mede o custo da revolução, não o retorno
O PIB captura com fidelidade o investimento: GPUs H100, data centers, eletricidade, turbinas a gás. Jason Furman estimou 4% do PIB americano em software e equipamento de processamento. A St. Louis Fed calcula 39% do crescimento marginal dos últimos quatro trimestres vindo de IA — contra 28% do setor tecnológico no pico da bolha dot-com. Cinco hyperscalers anunciaram cerca de 700 mil milhões de dólares este ano, perto de 5% do PIB americano.
Mas há uma armadilha contábil que pouca gente percebe: o PIB é produto interno bruto. Conta o investimento antes da depreciação. E este capital é invulgarmente mortal. Um aterro ferroviário serviu um século; uma GPU de fronteira é amortizada em três a cinco anos. Uma fatia significativa da linha que hoje explode é, por construção, o abate contabilístico de amanhã. Como notou secamente Acemoglu e o Observador.pt reproduziu: a eletricidade soma ao PIB medido quer aumente ou não o bem-estar de alguém.
Quando o produto fica grátis, ele desaparece do PIB
William Nordhaus traçou o preço da luz artificial ao longo de dois séculos: caiu por um fator de milhares. Resultado? A iluminação é arredondamento no PIB. Agricultura caiu de quase metade para 2% do PIB dos países ricos — não por falhar, mas por ter demasiado sucesso. Alimentou toda a gente tão barata que deixou de pesar.
A IA executa o mesmo truque, mas com a cognição. Para nós, devs, isso já é tangível: o custo de tokens colapsa mais depressa do que qualquer fator de produção na história económica — para cêntimos por milhão de tokens. Erik Brynjolfsson mostrou que pessoas exigem milhares de dólares anuais para abdicar de ferramentas cuja pegada no PIB é quase nula. A Wikipédia destruiu o negócio das enciclopédias e o PIB medido caiu enquanto o acesso ao conhecimento explodia. A IA é a Wikipédia a acontecer a tudo o que é cognitivo, ao mesmo tempo. Preparemo-nos para um bem-estar enorme e uma aritmética modesta.
A doença de Baumol: o software vive do que não automatiza
Baumol demonstrou que quando um setor fica radicalmente mais produtivo, os setores complementares que não seguem o mesmo ritmo encarecem relativamente. Um quarteto de cordas precisa de quatro músicos hoje, como no tempo de Haydn. Traduzindo para o nosso mundo: a IA está deixando a parte cognitiva do trabalho de dev absurdamente mais barata — gerar código, escrever testes, ler documentação, explicar uma API. Mas as partes humanas e institucionais seguem iguais ou piores:
- Code review manual
- Reuniões de planning e refinamento
- Compliance e auditoria (SOC2, HIPAA, LGPD)
- Aprovações regulatórias
- Janelas de deploy e change advisory boards
- Onboarding em ambientes regulados
- Espera por fornecedores e terceiros
O crescimento medido converge, mecanicamente, para a taxa de crescimento das partes mais estagnadas. E eis o corolário cruel para a IA: quanto mais depressa ela revoluciona o automatizável, mais barato ele fica, e mais o PIB passa a ser composto pelo resto. A IA acelera o seu próprio desaparecimento estatístico. O paradoxo não é defeito da tecnologia. É um teorema sobre o índice.
Lei de Amdahl: a IA acelera a inteligência, não a cadeia
Michael Kremer batizou esse mecanismo com o nome do anel de vedação que destruiu o Challenger. Lei de Amdahl: se a IA torna instantâneos 90% de um processo e os 10% restantes continuam lentos, a aceleração total está limitada a dez vezes. Na prática, muito menos — porque o gargalo migra precisamente para os elos humanos, institucionais e regulatórios que a IA não consegue tocar.
É exatamente o que observo no meu dia a dia e o que vejo nos times que acompanho:
- A IA escreve a função em segundos. O PR fica parado três dias esperando review.
- O diagnóstico do bug leva um prompt. A correção em produção leva seis semanas — CAB, janela de deploy, plano de rollback.
- A documentação é gerada em minutos. A aprovação no time leva um sprint inteiro.
- O protótipo sai numa tarde. A integração com o sistema legado leva dois meses.
Acelerou-se a inteligência. A cadeia, não. O PIB mede a cadeia.
Na Prática: medindo onde o tempo realmente vai
Pare de confiar em “velocidade de geração de código” como métrica de produtividade. Meça o ciclo. Aqui está um script que rodei num projeto real para mapear onde o tempo vai do commit ao deploy — e revelar, na prática, o “elo mais fraco” da Lei de Amdahl:
# pipeline_metrics.py
# Mapeia o ciclo completo: commit → review → CI → staging → prod
# Resultado revela o "elo mais fraco" da Lei de Amdahl aplicada a software
from dataclasses import dataclass
@dataclass
class StageTiming:
stage: str
duration_hours: float
is_automated: bool # partes que a IA poderia zerar
def amdahl_speedup(stages):
total = sum(s.duration_hours for s in stages)
auto = sum(s.duration_hours for s in stages if s.is_automated)
manual = total - auto
# speedup teorico se a IA zerasse as partes automatizadas
fraction_auto = auto / total if total else 0
theoretical = 1 / (1 - fraction_auto) if fraction_auto < 1 else float('inf')
return {
"total_cycle_hours": total,
"automated_fraction": round(fraction_auto, 3),
"manual_bottleneck_hours": manual,
"theoretical_max_speedup": round(theoretical, 2),
"insight": (
f"Mesmo com IA instantanea nas partes automatizadas, "
f"o ciclo fica limitado a {theoretical:.1f}x. "
f"O gargalo sao {manual:.1f}h em etapas manuais."
),
}
# ciclo real observado num time com deploy regulado
stages = [
StageTiming("code_generation_ia", 0.5, True),
StageTiming("code_review_humano", 24.0, False),
StageTiming("ci_pipeline", 0.5, True),
StageTiming("qa_manual", 16.0, False),
StageTiming("deploy_staging", 1.0, True),
StageTiming("change_advisory_board", 72.0, False), # CAB quinzenal
StageTiming("deploy_producao", 0.5, True),
StageTiming("smoke_tests_producao", 2.0, True),
]
result = amdahl_speedup(stages)
for k, v in result.items():
print(f"{k}: {v}")
Saída típica desse cenário:
total_cycle_hours: 116.5
automated_fraction: 0.043
manual_bottleneck_hours: 112.0
theoretical_max_speedup: 1.04
insight: Mesmo com IA instantanea nas partes automatizadas, o ciclo fica limitado a 1.04x. O gargalo sao 112.0h em etapas manuais.
1.04x. Esse é o ganho teórico máximo da IA nesse pipeline. Não importa o quão bom o modelo é. Não importa se o Copilot vira grátis. Não importa se o GPT-7 atinge AGI. O gargalo é o CAB que se reúne de quinze em quinze dias. Antes de gastar com a próxima geração de modelo, meça o seu pipeline. Aposto que 80% das vezes o gargalo não é onde você pensa.
Erros Comuns: o que devs e gestores entendem errado
1. Confundir LOC geradas com produtividade. Linha de código é métrica de 1970. Se a IA gera 10x mais linhas mas o deploy leva o mesmo tempo, você tem débito técnico 10x maior. Mais código para manter, mais código para auditar, mais código que vai morder no futuro.
2. Ignorar o custo de revisão. Acelerei meu output de código, mas o PR review virou gargalo. Em times pequenos funciona; em times de 30+ devs, é suicídio de throughput. A IA moveu o problema, não o resolveu.
3. Substituir humanos no code review por IA. Code review não é burocracia — é onde o modelo é validado. Substituir humanos aqui é o atalho que vira incidente em produção no sábado à noite. A IA deve amplificar o revisor humano, não substituí-lo.
4. Otimizar só o lado “inteligente” do ciclo. A tentação é gastar budget com a melhor assinatura de LLM. Mas 95% do ciclo são esperas humanas. Otimize o CAB, o PR review, a janela de deploy. A GPU é a última prioridade, não a primeira.
5. Medir produtividade em tokens. “Economizamos X milhões de tokens este mês” não é métrica de negócio. Meça as quatro métricas DORA: lead time for changes, deployment frequency, change failure rate, time to restore. Se a IA melhora essas, ela está gerando valor. Se ela melhora só “velocidade de escrever código”, está inflando métrica de vaidade.
FAQ — Perguntas que um dev realmente faz
A IA vai mesmo aumentar a produtividade ou é hype?
Vai aumentar sim — mas nas métricas erradas que o PIB captura. O ganho real aparece em throughput cognitivo pessoal (cada dev entrega mais), não em throughput organizacional (o time entrega mais rápido). O segundo depende dos gargalos institucionais que vimos acima.
Então não vale a pena adotar Copilot/Cursor/Claude?
Vale, mas entenda que o ganho aparece como margem de qualidade, não como velocidade pura. Você pode gastar o tempo economizado em testes, design, code review mais denso, código mais defensivo, exploração de alternativas. O ROI não é “fazer mais em menos tempo” — é “fazer melhor no mesmo tempo”.
Por que o PIB não capta isso?
Por dois motivos. Primeiro, boa parte do ganho de IA é excedente do consumidor, não transação — usar o ChatGPT de graça não conta no PIB, mas vale milhares de dólares/ano (Brynjolfsson mediu). Segundo, o ganho concentra-se nos setores estagnados (serviços, burocracia, saúde) que crescem devagar por construção.
O que devo medir no meu time para mostrar valor real da IA?
As quatro métricas DORA: lead time for changes, deployment frequency, change failure rate, time to restore service. Se a IA melhora essas quatro, ela está gerando valor. Se ela melhora só “velocidade de escrever código”, está inflando vaidade.
Devo me preocupar com a “mortalidade” do capital de IA?
Indiretamente, sim. A depreciação acelerada de GPUs (3 a 5 anos) significa que o custo de inferência deve cair ainda mais — o que é excelente para quem consome (todos nós, devs) e péssimo para provedores que apostam em preço alto sem diferencial técnico real. Cuidado com lock-in em APIs caras sem hedge de custo.
O que eu levo disso
O paradoxo de Solow não é escândalo — é aritmética. O PIB nunca foi construído para ver uma revolução cognitiva distribuída, gratuita e complementar; foi feito para contar transações e investimento físico. A revolução está acontecendo, mas nas métricas erradas, no lugar errado, na conta errada.
Como dev, minha leitura pragmática: a IA é real e útil. Mas o ganho organizacional exige mexer nos gargalos humanos e institucionais, não só comprar melhores modelos. Se o seu CAB se reúne de quinze em quinze dias, a IA não vai te salvar. Se o code review é gargalo, a IA não vai te salvar. A IA amplifica times bem arquitetados e esconde os mal arquitetados — e essa é a melhor definição de produtividade que eu conheço.
A charrua está nas estatísticas. A colheita vai aparecer — em métricas que o PIB não sabe contar: nas noites que você dorme porque o deploy rolou sozinho, no bug que não aconteceu porque o code review foi denso, no domingo que você não foi chamado porque o smoke test cobriu. Isso não está no PIB. Mas está no seu calendário.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.