Um desenvolvedor com mais de dez anos de experiência publicou um relato curto no Hacker News que resume uma ansiedade bem atual da área: ele continua empregado, continua produtivo, mas sente que parte do prazer do trabalho desapareceu desde que agentes de IA passaram a resolver boa parte da implementação.
Segundo o relato, a mudança não foi aquela cena caricata de “a IA vai roubar meu emprego amanhã”. Foi mais sutil. O dev diz que, nos últimos meses, passou a revisar menos código, escrever menos código do próprio punho e delegar features inteiras para ferramentas como Codex, descrevendo o que queria, a arquitetura esperada e os critérios de sucesso.
A frase que fica é incômoda justamente porque não parece exagero de rede social: no começo, os agentes eram “uma ferramenta muito boa”. Depois, quando ficaram bons o bastante, parte do desafio sumiu junto.
O caso não é sobre preguiça. É sobre perda de atrito
No post, o autor conta que trabalhava principalmente com React, Svelte e backends em Node. Ele gostava do fluxo de pensar em dados, mapear a solução na cabeça, construir a feature e sentir o encaixe das peças. Só que, com agentes escrevendo uma parte grande do trabalho, esse ciclo foi ficando menor.
O ponto sensível é este: muita gente entrou em tecnologia porque gosta de resolver problema construindo. Quando a etapa de construção vira coordenação de uma máquina que produz rápido, a satisfação muda de lugar. Para alguns, isso é libertador. Para outros, dá uma sensação de esvaziamento.
E dá para entender. A promessa sempre foi: “a IA tira o trabalho chato”. Só que, na prática, nem todo trabalho repetitivo é apenas chato. Às vezes ele também é o terreno onde o dev percebe detalhes, descobre bordas, ganha intuição e sente domínio sobre o sistema.
Produtividade sem participação pode virar tédio
Uma das respostas mais interessantes da discussão foi de outro usuário que disse ter passado por algo parecido, mas chegou a uma leitura diferente: ele percebeu que não amava apenas “digitar código”, e sim resolver problemas e desenhar soluções elegantes. Para ele, a IA reduziu o boilerplate, mas não tirou o desenho do sistema.
Essa distinção é importante para carreira. Se o seu trabalho vira só aceitar sugestões, colar trechos e torcer para o teste passar, a IA realmente empurra você para uma posição mais frágil. Mas se você continua definindo comportamento, decompondo o problema, revisando trade-offs, protegendo o sistema e sabendo quando a ferramenta tomou um atalho perigoso, o centro do trabalho não sumiu. Ele subiu de camada.
O desconforto aparece porque essa subida nem sempre é bonita. Ela pode parecer menos “mão na massa” e mais “gerente de obra do próprio código”. Tem dev que vai gostar. Tem dev que vai odiar. E tem muita empresa que ainda não sabe medir essa diferença.
A habilidade nova é saber comandar sem desligar o cérebro
Um post recente do GitHub sobre fluxo com agentes bate em uma tecla parecida: a produtividade não vem de trocar de ferramenta todo dia, mas de entender bem o “harness”, planejar melhor, prototipar, revisar e iterar com rigor. Em outro texto, o GitHub descreve agentes como parte de equipes híbridas, com humanos no centro da visão, do julgamento e da responsabilidade.
Traduzindo para o dia a dia: a pior forma de usar agente é pedir “faz aí” e virar aprovador automático. A melhor forma é tratar a ferramenta como um executor rápido que precisa de direção, contexto, limite e revisão.
Isso muda o tipo de treino que vale para o dev. Não basta decorar sintaxe, mas também não dá para abandonar fundamentos. Quem não entende arquitetura, estado, concorrência, banco, segurança, testes e experiência do usuário não consegue avaliar se a IA entregou uma solução boa ou apenas uma solução plausível.
Para júnior, o risco é pular a fase que forma intuição
Esse é o lado mais perigoso do assunto. Para um dev sênior, delegar código pode liberar tempo para decisões mais importantes. Para quem está aprendendo, delegar cedo demais pode roubar exatamente o atrito que ensina.
Um artigo da GeekHunter sobre estudar programação na era da IA chama isso de “ilusão de competência”: a pessoa entrega algo funcionando, mas não consegue explicar por que funciona, onde quebra ou como depurar quando a saída da IA vem errada. É uma armadilha bem real, especialmente em um mercado que já está mais duro para entrada.
Por isso, a recomendação prática não é “não use IA”. É usar com intenção. Em fundamentos, vale fazer parte do trabalho sem autocomplete inteligente. Em bugs, vale formular uma hipótese antes de jogar o erro no chat. Em features, vale pedir perguntas, alternativas e riscos, não apenas o código pronto.
O que sobra para o dev?
Sobra muita coisa, mas ela fica menos escondida atrás da digitação. Sobra entender o problema real, escolher o recorte certo, escrever especificações claras, revisar impacto, conversar com gente, testar comportamento, decidir trade-offs e assumir responsabilidade pelo que vai para produção.
Também sobra gosto. Sim, gosto mesmo. Saber quando uma solução está pesada demais, quando a abstração ficou artificial, quando a interface parece gerada, quando o código passou no teste mas está difícil de manter. Esse tipo de julgamento ainda não vem no pacote automático.
O relato do Hacker News não é uma sentença sobre o fim da programação. É um aviso mais útil: se o trabalho do dev virar só apertar “aprovar”, a carreira fica mais vazia e mais frágil. Se virar direção técnica de ferramentas poderosas, com revisão real e curiosidade viva, talvez o cargo mude bastante, mas não fica menor.
No fim, a pergunta não é se a IA vai escrever cada vez mais código. Ela vai. A pergunta é se você ainda vai saber dizer qual código deveria existir.
