Um desenvolvedor com mais de dez anos de estrada publicou no Hacker News uma sensação que muita gente de TI talvez ainda esteja tentando nomear: a IA não apenas acelerou o trabalho. Em alguns fluxos, ela mudou o centro do trabalho.
Segundo o relato, o autor trabalha com aplicações web, stacks comuns de React/Svelte e backends em Node. No começo, os agentes de código pareciam uma ferramenta excelente. Ajudavam a fazer mais rápido, erravam às vezes, mas entregavam valor. Depois, com modelos mais capazes, a rotina dele foi escorregando para outro lugar: menos código escrito na mão, menos desenho mental de fluxo, mais especificação longa, supervisão e revisão do que a máquina produzia.
A frase mais forte do relato não é sobre medo de demissão. É sobre perda de atrito bom. Ele diz que a principal emoção virou um “tédio extremo”. Para quem sempre gostou da parte de pensar, montar, quebrar a cabeça e finalmente fazer a peça encaixar, isso bate diferente.
O problema não é só “a IA vai roubar meu emprego?”
A discussão pública sobre IA em desenvolvimento costuma cair rápido em dois extremos: ou a ferramenta vai substituir todo mundo, ou é só autocomplete vitaminado. O caso é interessante justamente porque foge desse binário.
No relato, o dev continua empregado. A produtividade parece alta. A empresa ganha mais entrega. O ponto dolorido é outro: se o trabalho que dava senso de progresso vira especificar, esperar, revisar e corrigir, a identidade profissional também muda.
Isso não é pouca coisa. Muita gente entrou em tecnologia porque gostava de construir. Não só de “entregar valor”, no vocabulário de reunião, mas de resolver o quebra-cabeça. Quando a parte gostosa vira uma camada cada vez menor do dia, a pergunta deixa de ser apenas econômica e passa a ser prática: que tipo de profissional eu estou virando?
Produtividade maior pode esconder trabalho menos satisfatório
A pesquisa de 2025 do Stack Overflow ajuda a colocar o relato em contexto. O uso de ferramentas de IA no desenvolvimento cresceu: 84% dos respondentes usam ou planejam usar IA no processo, e 51% dos profissionais dizem usar diariamente. Ao mesmo tempo, a confiança não acompanhou esse entusiasmo. Mais devs declararam desconfiar da precisão da IA do que confiar nela.
Esse detalhe importa. Se a ferramenta escreve mais código, mas exige verificação constante, o profissional não desaparece. Ele muda de função dentro do próprio fluxo. Sai um pouco do papel de autor direto e entra mais no papel de editor, arquiteto, QA, product thinker e segurador de contexto.
Para algumas pessoas, isso é ótimo. Menos repetição, mais espaço para pensar em produto, arquitetura e impacto. Para outras, pode parecer que tiraram justamente a parte que dava prazer no trabalho. O mesmo recurso que economiza horas também pode transformar o dia em uma fila de decisões pequenas, revisões e prompts.
O risco para júnior é diferente do risco para sênior
Para quem já tem repertório, virar revisor de agente pode ser desconfortável, mas ainda existe uma base forte por trás: experiência, leitura de arquitetura, noção de risco, faro para bug estranho, conversa com negócio. O problema fica mais espinhoso quando olhamos para quem está entrando.
O caminho tradicional do júnior sempre teve muito aprendizado em tarefas menores: ajustar tela, consertar bug simples, mexer em CRUD, escrever teste, entender um pedaço do sistema, levar revisão e melhorar. Se parte desse trabalho vira “coisa que o agente faz em minutos”, a escada de entrada fica mais estreita.
Não quer dizer que não exista mais vaga para iniciante. Quer dizer que a régua muda. O iniciante que só “pede para a IA fazer” pode parecer produtivo por algumas horas e perigoso na semana seguinte. O iniciante que entende o problema, lê código, testa, explica trade-off e sabe quando desconfiar da resposta começa a se diferenciar.
O que muda no dia a dia de quem quer continuar relevante
A resposta fácil seria “aprenda IA”. Só que isso é vago demais. O caso aponta para algo mais concreto: aprender a operar um fluxo em que a IA produz, mas você continua responsável.
Na prática, isso significa melhorar três músculos:
- Especificação: explicar o problema, limites, casos de borda e critérios de aceite antes de pedir código.
- Revisão: ler diff de verdade, rodar teste, desconfiar de solução bonita demais e procurar o bug que não aparece no demo.
- Contexto: entender produto, usuário, arquitetura e histórico do sistema para não aceitar uma resposta que resolve só o prompt.
Esse é um tipo de senioridade menos glamouroso do que “codar mais rápido”, mas provavelmente mais valioso. O agente pode gerar a implementação. Ele ainda não carrega sozinho a responsabilidade de decidir se aquela implementação deveria existir daquele jeito.
Também dá para usar a folga para subir o nível
Nos comentários do Hacker News, algumas respostas puxaram o autor para outro enquadramento: se a IA liberou banda mental, talvez o próximo passo seja construir algo mais difícil, atacar problemas maiores ou se aproximar mais de produto. Essa leitura faz sentido, desde que não vire frase motivacional jogada em cima de uma dor real.
Nem todo time dá espaço para usar a produtividade extra com calma. Às vezes a empresa apenas aumenta a esteira. Mais entrega, mais cobrança, mais tickets, menos respiro. Aí a promessa de “liberar tempo para pensar” vira só “fazer mais no mesmo horário”.
Por isso o debate é importante para o profissional e para a liderança. Se a adoção de agentes só troca código manual por revisão cansada, o time pode até parecer mais rápido por um tempo, mas perde aprendizado, senso de propriedade e prazer técnico. Se a adoção vier com espaço para especificar melhor, revisar melhor e atacar problemas mais relevantes, a história fica bem mais interessante.
A pergunta boa para fazer agora
Se você trabalha com desenvolvimento, talvez a pergunta não seja “a IA vai acabar com a minha carreira?”. A pergunta mais útil é: qual parte do meu trabalho ainda melhora quando eu estou mais atento do que a ferramenta?
Pode ser arquitetura. Pode ser produto. Pode ser segurança. Pode ser comunicação com cliente. Pode ser depurar um incidente real, daqueles que não cabem em prompt bonitinho. Pode ser ensinar alguém mais novo a não confiar cegamente em uma resposta convincente.
O relato do Hacker News não prova o futuro da profissão. É um caso individual, com o recorte de um dev experiente em um ambiente específico. Mas ele captura uma mudança que já chegou ao chão de fábrica de muita equipe: escrever código deixou de ser a única forma visível de produzir software.
Quem conseguir transformar essa mudança em critério, contexto e responsabilidade provavelmente vai continuar tendo espaço. Quem só trocar o teclado pelo botão de aceitar sugestão pode até parecer rápido, mas vai ficar mais frágil justamente quando o trabalho pedir julgamento.
