Vozes
Gergely Orosz: verificar virou o gargalo quando a IA codifica
Para o autor do Pragmatic Engineer, quando a IA escreve quase todo o código a engenharia não some: migra para verificar, ter domínio e pensar produto.
Gergely Orosz não é um cético de IA torcendo pelo fracasso. O autor da The Pragmatic Engineer, a newsletter de engenharia mais lida do setor, usa agentes de código todo dia e já mostrou como montar software de produção pelo celular com um agente conectado ao GitHub. Justamente por isso vale ouvir o que ele anda escrevendo em 2026, porque não é hype nem pânico. É uma observação incômoda de quem está dentro: quando a IA passa a escrever quase todo o código, o trabalho de engenharia não desaparece. Ele se desloca. E se desloca para o lugar mais chato e mais decisivo de todos, verificar.
O gargalo mudou de lugar
A tese de Orosz cabe numa inversão. Durante décadas, o gargalo do software foi escrever o código. Digitar, estruturar, fazer compilar. A IA resolveu essa parte com folga. Só que resolver a geração não acelera o processo inteiro, apenas empurra o gargalo para a etapa seguinte: entender e validar o que foi gerado.
E essa etapa é mais difícil do que parece. Ler código que você não escreveu exige reconstruir a intenção por trás de cada decisão. Um agente produz muito código plausível em minutos, mais do que qualquer humano consegue revisar com atenção no mesmo tempo. O resultado, quando ninguém freia, é conhecido: qualidade que degrada aos poucos, brechas de segurança que passam e uma dívida técnica que só aparece quando já é cara. Orosz é direto na receita: limite o uso de IA ao que o seu time consegue de fato verificar. Não ao que a ferramenta consegue gerar, ao que as pessoas conseguem entender.
Mais código não é mais valor
O ponto que mais desmonta o entusiasmo é sobre métricas. Os números que Orosz cita, de ferramentas como Cursor e Linear, mostram um salto real de volume: linhas de código por desenvolvedor por ano crescendo de forma expressiva, pull requests ficando bem maiores, times com agentes empurrando muito mais código para dentro do repositório. Impressiona no gráfico. Mas volume não é a métrica que importa.
Mais código gerado não é mais valor entregue. Muitas vezes é o contrário: mais superfície para revisar, mais lugar para bug se esconder, mais peso para manter.
Quem já operou software sabe que a linha de código é passivo, não ativo. Cada linha precisa ser lida, testada e mantida. Um agente que triplica o tamanho do pull request não triplicou o valor, triplicou o custo de revisão. É a mesma armadilha que este blog descreveu ao lembrar que escrever código ficou barato, mas código bom não: baratear a produção não baratea o entendimento, e é o entendimento que segura a operação de pé.
Para onde o valor migra
Se gerar virou commodity e verificar virou o gargalo, o valor humano se reposiciona. Orosz aponta a direção, e ela não é a que o medo do "vai substituir programador" sugere.
Ganha peso quem tem domínio do problema. Saber o que o sistema deveria fazer, quais são os casos de borda, onde um erro custa caro, isso a IA não infere sozinha e é exatamente o que torna a revisão possível. Ganha peso quem pensa como produto, não só como quem digita código, porque decidir o que não construir passou a valer mais do que construir rápido. E ganham os traços de tech lead: revisar com critério, dar direção, cortar o que não deveria existir. Ser um bom engenheiro, e não apenas um "coder", ficou mais requisitado, não menos.
Isso conversa com um consenso que vem se formando entre as vozes que este blog acompanha. Kent Beck disse que testar virou o superpoder do programador, porque o teste é o que te deixa confiar em código que você não escreveu à mão. Ethan Mollick argumenta que gestão virou o superpoder da era dos agentes, porque coordenar e definir o certo passou a valer mais que executar. Orosz completa o triângulo pelo lado da verificação: no fim, o profissional valioso é o que sabe julgar se o resultado presta.
O que fazer com isso na sua operação
Três movimentos concretos para quem coloca IA em produção, direto da leitura de Orosz.
Primeiro, calibre o volume à capacidade de revisão. Se o time gera mais código do que consegue entender, você não ficou mais rápido, ficou mais exposto. Defina um teto prático de quanto código gerado por IA entra por ciclo, atrelado a quantas pessoas conseguem revisar com atenção.
Segundo, invista no que torna a verificação barata. Teste automatizado, log claro, código legível e observabilidade não são luxo quando a IA gera em escala, são o que permite confiar no que ela produziu. Sem isso, cada linha gerada vira um risco que você aceitou sem olhar. Vale medir isso com um placar honesto, no espírito das métricas de fluxo e qualidade em produção, não pela quantidade de código, mas pela saúde do que chega ao usuário.
Terceiro, contrate e desenvolva domínio, não digitação. Se verificar é o gargalo, seu ativo mais escasso é gente que entende o problema fundo o bastante para dizer se a resposta da IA está certa. Essa é a competência que a automação valoriza, não a que ela apaga.
Orosz chama a transição de "luto", e o termo é preciso. Quem tinha orgulho de escrever cada linha precisa se reencontrar num papel novo, o de garantir que o que a máquina escreveu presta. Não é um papel menor. É o que separa uma operação de IA que entrega de uma que só produz volume. A pergunta que Orosz deixa para qualquer time sério é simples e desconfortável: você está gerando mais do que consegue verificar?
Se a sua empresa está acelerando com IA no código e quer garantir que verificação, testes e domínio acompanhem o volume, fale com a AI Boutique no WhatsApp. A gente ajuda a colocar IA em produção sem trocar velocidade por dívida.
Fontes
Perguntas frequentes
Qual é a tese de Gergely Orosz sobre IA e engenharia de software?
Orosz, que escreve a newsletter The Pragmatic Engineer, sustenta que a IA não elimina a engenharia de software, mas desloca o trabalho. Quando o agente passa a gerar a maior parte do código, gerar deixa de ser o gargalo e verificar se torna o gargalo. Por isso ele recomenda limitar o uso de IA ao que o time consegue revisar e entender de verdade, valorizar domínio do problema e traços de tech lead, e tratar o excesso de código gerado como risco, não como conquista. O ponto central é que mais código produzido não significa mais valor entregue.
Por que verificar código de IA é mais difícil do que escrever?
Porque ler e validar código que você não escreveu exige reconstruir a intenção por trás dele, e um agente pode produzir muito código plausível e rápido, mais do que um humano consegue revisar com atenção no mesmo tempo. Orosz alerta que rodar agentes com pouca supervisão gera degradação de qualidade e risco de segurança. A saída não é desligar a IA, é calibrar o volume ao que a equipe consegue verificar, e investir em testes, logs e domínio do problema para que a revisão seja viável.