Tem muita conversa sobre IA em desenvolvimento que ainda sai pela tangente. Fala de produtividade, fala de velocidade, fala de custo. Mas um relato aberto no Hacker News foi por outro lado: um desenvolvedor disse que percebeu que não escrevia código havia mais de um mês, mesmo trabalhando em tempo integral como dev. O trabalho dele tinha virado contexto, pedido e revisão.
É por isso que esse caso bateu. O desconforto não veio de alguém que odeia automação. Veio de alguém que já usava Copilot cedo, curtia deixar boilerplate e teste chato na mão da máquina, e depois sentiu que a parte que ele gostava de verdade tinha sido arrancada do trabalho.
o relato que apertou um nervo real
No post, o autor compara programar com jogar xadrez. Ganhar só faz sentido quando ele joga a partida. Quando o agente faz quase tudo, a sensação muda. Ele diz que deixou de passar dias dentro de um problema técnico e passou a operar como alguém que junta contexto, escreve o pedido certo e revisa a saída.
Duas frases explicam a dor melhor que qualquer tese grandona. A primeira: ele percebeu que não tinha escrito código por mais de um mês. A segunda: o papel novo parecia muito mais com gestão do que com engenharia de mãos no teclado.
Isso ajuda a entender por que tanta gente respondeu com identificação imediata. Não era só medo abstrato de substituição. Era a sensação de que o trabalho continuava existindo, mas com outra textura.
Alguns comentários foram no caminho oposto. Teve gente dizendo que o objetivo sempre foi entregar valor, não escrever código. Teve gente mais velha dizendo que a IA tirou parte do peso das frameworks novas e abriu espaço para tocar projetos que antes ficavam parados. A divisão não foi pequena. E justamente por isso o caso é bom: ele não fecha a conversa com slogan.
a promoção silenciosa para revisor

A parte mais útil desse debate apareceu quando ele saiu do desabafo e bateu num problema bem concreto: revisão virou trabalho principal, mas quase ninguém aprendeu a revisar direito nesse novo ritmo.
Um texto recente no Dev.to colocou isso em números. O autor contou 204 verificações automatizadas que faziam algum tipo de julgamento sobre código, configuração ou estado do sistema. Só 22 tinham sido testadas com um caso ruim conhecido para provar que sabiam falhar. Isso dá cerca de 11%.
O ponto dele é simples e muito bom: se o agente produz mais artefato e o humano vira revisor, então o gargalo não é mais só escrever. O gargalo é saber verificar. E muita verificação verde hoje ainda pode estar verde porque ninguém testou se ela detecta erro de verdade.
Esse argumento conversa direto com o relato do Hacker News. O cansaço não vem só de ler diff demais. Vem de tentar supervisionar mais coisa, mais rápido, com menos intimidade manual com o código.
onde isso acelera de verdade — e onde começa a conta escondida
Seria fácil transformar esse caso em manifesto anti-IA. Só que ele não pede isso. O próprio debate mostra que a ferramenta resolve coisa real.
Ela corta boilerplate. Ela ajuda a navegar framework ruim. Ela acelera tarefa pequena. Ela também permite que alguém mais experiente gaste menos energia com detalhe repetitivo e mais com arquitetura, integração e decisão.
O problema começa quando a empresa lê esse ganho como licença para enfiar mais throughput em cima do mesmo cérebro.
No relato, o autor diz que o que antes tomava semanas agora cabe em horas, mas a obrigação de entender tudo continua ali. Em outra resposta, um dev resumiu o dilema de um jeito duro: ou você aceita rápido demais, ou se queima revisando dezenas de milhares de linhas.
A conta escondida está aí. Não é só assinatura, token ou licença. É fadiga de revisão. É modelo mental mais raso. É a tentação de confiar no check verde, no resumo bonito e no “done” do agente sem voltar para o artefato.
o risco de virar apertador de aceite
Quando o trabalho vira supervisão, o erro também muda de lugar.
No texto do Dev.to, o autor descreve verificações que falharam de formas bem mundanas: um passo de deploy que dependia de ferramenta ausente, um processo que tratou trabalho concluído como falha por causa do código de saída, um classificador que leu o número errado dentro da mensagem. Nada disso parece futurista. Tudo isso parece rotina.
É exatamente esse o perigo. Se o time começa a aceitar código gerado, testes gerados e até revisão assistida sem checar a peça final, a sensação de controle pode subir enquanto a compreensão real cai.
No Hacker News, apareceu um comentário que resume bem a fricção: gente que usa IA para entregar mais rápido muitas vezes fica sem chão quando “a coisa estoura”. Pode soar exagerado, mas a observação conversa com o que muito time já conhece: construir depressa e operar depois são duas profissões diferentes.
o que vale fazer antes de largar o teclado de vez
Se esse caso te pegou, a saída não parece ser fingir que 2026 ainda é 2022. Mas também não parece ser terceirizar tudo e virar aprovador automático.
O caminho mais saudável hoje parece passar por cinco freios simples:
- manter zonas de trabalho sem agente para partes do sistema que pedem modelo mental fundo
- revisar o artefato final, não só o resumo, o diff mastigado ou o check verde
- tratar teste de revisão como coisa séria, inclusive com caso ruim conhecido
- usar IA como atalho em tarefa repetitiva, não como muleta para toda decisão
- preservar momentos de código manual para não deixar a musculatura técnica atrofiar
Isso não resolve a crise de identidade de quem entrou na área porque amava programar. Mas pelo menos separa duas perguntas que muita empresa mistura: “a IA acelera?” e “o time continua entendendo o que está colocando em produção?”
Hoje dá para responder “sim” para a primeira e “não tão bem quanto parece” para a segunda.
Se o trabalho do dev virou mais revisão, revisão precisa deixar de ser etapa invisível. Precisa virar habilidade central, com limite, critério e espaço real para discordar da pressa.
fontes
- https://news.ycombinator.com/item?id=49389408
- https://news.ycombinator.com/item?id=49449290
- https://dev.to/heinrichneb/ai-promoted-every-developer-to-reviewer-nobody-tested-the-reviewer-m4h
- https://www.geekhunter.com/pt/blog/estudar-programacao-na-era-da-ia/