A IA não elimina o trabalho. Ela o esconde.

Em 2025, a METR — organização que mede capacidade de IA — pagou 16 desenvolvedores experientes para trabalhar em repositórios de código aberto que já conheciam bem. 246 tarefas reais, cada uma sorteada para ser feita com ou sem ferramentas de IA. ^{[1] afirmação da fonte original}

Antes de começar, os desenvolvedores previram que a IA reduziria o tempo de cada tarefa em 24%. Depois de terminar — já tendo sentido na pele o que aconteceu — continuavam achando que tinham ganhado 20% de velocidade.^{[1] afirmação da fonte original}

Esperavam ganhar

24%

Previsão deles mesmos, antes de começar a tarefa.

Acharam que ganharam

20%

Percepção deles mesmos, depois de terminar.

O cronômetro mediu

−19%

Tempo real: mais lento com IA, não mais rápido.

First principles é isto: em vez de perguntar “a IA substitui programador?”, perguntar do que é feito o trabalho de programar — e só depois ver qual pedaço a IA realmente pega.

1. 01

   Entender o problema.

   O que precisa existir, para quem, e o que não pode quebrar no caminho.

2. 02

   Decidir a forma.

   Arquitetura, limites, o que é simples de propósito e o que é complexo por necessidade.

3. 03

   Escrever.

   Transformar a decisão em código que roda.

4. 04

   Verificar.

   Ler, testar, rodar, perguntar 'isso está certo?' e ter como responder.

5. 05

   Responder pelo resultado.

   Quando quebra em produção, alguém precisa saber por quê — e ser essa pessoa.

Um desenvolvedor de 22 anos de carreira, num tópico com quase 700 comentários, aplicou o teste: apontar uma IA para um código complexo e pedir para ela explicar um trecho já mostra o limite — “não é só sintaxe. Pode não ser entendimento de verdade. Mas é mais do que sintaxe.”^{[3] afirmação da fonte original}

1. 1

   Efeito direto: escrever fica mais rápido.

   A IA gera em segundos o que levaria horas. Esse pedaço — item 3 da lista — de fato encolhe.

2. 2

   Efeito seguinte: sobra mais para verificar, e verificar não encolheu.

   Quem revisa não escreveu aquele código: não tem o histórico de decisões que só existe na cabeça de quem construiu passo a passo. Verificar o trabalho de outro exige reconstruir esse contexto do zero — e é mais devagar exatamente quando há mais volume para revisar.

3. 3

   Terceiro efeito: a responsabilidade não migrou para lugar nenhum.

   A IA não assina o commit, não é chamada às 3 da manhã e não explica ao cliente por que o sistema caiu. Item 5 da lista continua 100% humano — só que agora sobre um código que a pessoa não escreveu.

Isso tem nome fora da programação. Eliyahu Goldratt, físico virado consultor industrial, publicou em 1984 A Meta (The Goal) — um romance sobre uma fábrica à beira do fechamento que vendeu mais de sete milhões de cópias e ainda é ensinado em escola de negócios. O livro criou a Teoria das Restrições: todo sistema tem um gargalo, e a velocidade do sistema inteiro é a velocidade do gargalo — nunca a soma da capacidade de cada etapa.^{[6] afirmação da fonte original}

O ponto que mais se perde é este: acelerar uma etapa que não é o gargalo não acelera o sistema. Só empilha estoque na frente do gargalo verdadeiro.

1. 01

   Identificar a restrição.

   No fluxo de um dev com IA, a restrição não é mais escrever — é entender, verificar e decidir se o que foi gerado está certo.

2. 02

   Explorar a restrição.

   Garantir que a capacidade de verificação nunca seja gasta revisando bobagem, quando podia estar checando a decisão que realmente importa.

3. 03

   Subordinar tudo o mais à restrição.

   O passo que a maioria das empresas está pulando: deixar a IA gerar no ritmo que a verificação aguenta, não no ritmo que a IA aguenta. É a regra que a pressão para 'apertar enter' 12 horas por dia está violando — código empilhado na frente de um gargalo que ninguém redimensionou.

4. 04

   Elevar a restrição.

   Investir em aumentar a capacidade de verificar — testes melhores, revisão mais bem desenhada, gente treinada para isso — em vez de continuar investindo só em gerar mais rápido, que já não é o problema.

5. 05

   Não deixar a inércia virar a nova restrição.

   Resolvido o gargalo de hoje, o próximo aparece em outro lugar — decisão de arquitetura, aprovação de negócio. Tratar a regra de ontem como se ainda valesse é o erro que o próprio Goldratt descreve como o mais caro de todos.

Esse é o mesmo argumento que virou best-seller de novo em 2013, quando Gene Kim e coautores escreveram O Projeto Fênix — uma releitura explícita de A Meta para TI, aplicando a mesma teoria a pipelines de deploy.^{[7] afirmação da fonte original} O que esta análise propõe é aplicar a mesma lente um degrau acima na cadeia: não o pipeline que leva código para produção, mas o próprio ciclo em que um humano escreve com IA e decide se aquilo pode seguir.

Há um nome antigo para isso. Em 1981 o filósofo Ivan Illich chamou de shadow work o trabalho que a economia formal passa para o cliente sem pagar por ele: o caixa eletrônico que substitui o caixa do banco, o posto de gasolina self-service, o check-in que você mesmo faz no totem do aeroporto.^{[5] afirmação da fonte original} O serviço não desapareceu. Só deixou de aparecer na folha de pagamento de alguém.

A revisão de código gerado por IA é o novo self-checkout. O trabalho de verificar não desapareceu quando a IA passou a escrever mais rápido. Só deixou de aparecer no painel que mede produtividade.

É o que aparece, com outras palavras, num comentário com quase sete mil votos, sobre um engenheiro que descreveu o uso obrigatório de IA no trabalho como desgastante: a pressão não é a IA ser incrível — é a pressão para lançar código que ninguém entende direito, que não foi testado de verdade e que “mal funciona”.^{[2] afirmação da fonte original} Ou, como resumiu outro comentário no mesmo tópico: “tecnicamente o trabalho ficou mais fácil, mas também tenho três vezes mais trabalho — então não ficou, não”.^{[2] afirmação da fonte original}

Painéis de produtividade contam o que é fácil de contar: linhas geradas, tickets fechados, pull requests por semana. Nenhum desses números diverge do que a IA de fato produz. O que eles não separam é quanto desse volume foi entendido, testado e assumido por alguém — versus só aprovado porque estava difícil de dizer que não.

Um comentário de liderança de engenharia no mesmo tópico do Reddit nomeia o risco direto: a IA dá a colaboradores menos experientes a capacidade de produzir soluções complexas que eles não entendem por completo — e isso tem vindo acompanhado de menos disposição para pesquisar, ler e aplicar o que foi aprendido.^{[2] afirmação da fonte original}

Do outro lado do mesmo problema, quem entrevista está sentindo o efeito espelhado: como avaliar um candidato quando não dá para saber se o código bonito na tela é entendimento ou aceite de sugestão. É a pergunta que abriu um tópico inteiro no Hacker News em setembro de 2026, sem resposta fechada.^{[4] afirmação da fonte original}

O senso comum pergunta “quanto código a IA consegue escrever”. A pergunta que rende mais, invertida por first principles, é outra: se o gargalo migrou de escrever para verificar, o que muda quando a empresa passa a medir, treinar e remunerar por isso — em vez de tratar verificação como um detalhe que sobra depois que “o trabalho de verdade” (escrever) já foi feito?

O mesmo desenvolvedor de 22 anos citado acima levou o argumento adiante comparando com a terceirização de escrita de código para o exterior, nos anos 2000: escrever sintaxe nunca foi o trabalho difícil, e terceirizar essa escrita para quem não entende a arquitetura e o motivo das decisões sempre criou um segundo conjunto de problemas^{[3] afirmação da fonte original} — antes, para uma equipe em outro fuso horário; agora, para um modelo que também não carrega esse contexto.

1. 01

   Trate verificação como etapa, não como demora.

   Se ninguém tem tempo alocado para verificar, ninguém verifica de verdade — só aprova.

2. 02

   Decida, por escrito, quem assina o que a IA escreveu.

   Sem um nome responsável por cada trecho relevante, a responsabilidade do item 5 simplesmente não existe em lugar nenhum.

3. 03

   Meça o tempo de revisão, não só o de geração.

   Um painel que só mostra o que ficou mais rápido está, por construção, cego para o que ficou mais devagar.

Sete perguntas para examinar onde o trabalho foi parar depois que a IA entrou na rotina — a sua e a da sua empresa.