Você provavelmente já viu esse número. Emprego para devs caiu quase 20% desde o final de 2022. O período coincide exatamente com a adoção massiva de ferramentas de IA. Empresas que antes contratavam dez devs agora acham que precisam de dois seniores e uma assinatura do Claude Code.
Se você está aprendendo a programar agora, ou acabou de entrar no mercado, esse número parece desanimador. Parece que a janela está fechando antes de você conseguir entrar.
Mas existe uma pergunta que ninguém está fazendo direito: qual tipo de emprego júnior sumiu?
Porque não foi o júnior que é analítico, que questiona a demanda, que entende o sistema que está construindo. Foi aquele que executava tarefas mecânicas sem precisar compreendê-las — e que, convenhamos, nunca foi um programador de fato. Era alguém que sabia seguir instruções em código. A IA faz isso mais rápido, mais barato e sem reclamar do prazo. Faz sentido que as empresas tenham trocado.
O problema é que elas confundiram a definição de júnior com esse perfil. E agora estão colhendo as consequências de uma equação que parece eficiente no curto prazo e é desastrosa no longo.
A lâmpada piscando
O DHH disse algo recentemente que circulou bastante, mas que a maioria leu pela metade.
Em um podcast, ele descreveu a experiência de usar IA para escrever código no dia a dia com uma metáfora simples: uma lâmpada piscando. Às vezes ilumina tudo — você pensa "como ela sabia?", sensação quase mágica. Dois segundos depois, escuridão total.
No produto mais recente da 37signals, o Fizzy, 95% do código foi escrito por humanos. Tentaram usar IA em features complexas. Não funcionou — não porque o código estava errado, mas porque estava difícil de manter, difícil de entender, difícil de evoluir. Em times reais, código não é só o que funciona hoje. É o que alguém consegue ler, corrigir e construir em cima amanhã.
Mas o ponto mais revelador foi pessoal. DHH disse que se pegou pedindo pra IA escrever uma condição if — algo que ele sabe fazer de olhos fechados. O ato de raciocinar tinha sido completamente terceirizado. Ele mesmo se perguntou: isso está me tornando um dev melhor ou pior?
Essa pergunta é o centro de tudo.
A empresa que faz o Claude publicou um estudo que envergonha quem usa o Claude sem pensar
A Anthropic — sim, a empresa que faz o Claude — publicou um estudo controlado que responde essa pergunta com dados.
52 engenheiros, a maioria júnior, aprendendo uma biblioteca que nenhum deles conhecia. Metade usou IA, metade não. Depois, avaliação de compreensão.
Quem usou IA tirou 17% a menos. Em debugging a diferença foi ainda maior. Mas o detalhe que muda tudo: devs que usaram IA para entender conceitos se saíram bem. Quem usou IA para gerar código — ou seja, para não precisar pensar — foi mal. Muito mal.
A ferramenta não é o problema. Mas o modo de usa-la é.
Delegar tudo pra IA sem passar pelo esforço cognitivo é talvez a melhor reedição do fordismo que a indústria de software já inventou. Eficiente na linha de montagem, desastroso para quem deveria estar aprendendo a construir a fábrica. Você entrega features mais rápido, seu gestor fica feliz, e você não aprendeu absolutamente nada que vai te ajudar quando o problema for novo.
Não estou sendo reacionário aqui — seria hipócrita. Uso IA todo dia para as coisas que não são meu core, especialmente frontend. Mas existe uma diferença enorme entre usar IA como alavanca e usá-la como muleta. E essa diferença define quem vai continuar crescendo daqui a três anos.
Qualquer um pode cozinhar — mas nem todo mundo vira chef
Tem um filme da Pixar que eu sempre volto quando falo sobre isso.
No Ratatouille, o Gusteau tem um lema: qualquer um pode cozinhar. O filme passa duas horas mostrando que isso é verdade. Mas no final, é o Anton Ego — o crítico mais temido de Paris — quem entrega a frase que importa: não que qualquer um possa se tornar um grande artista, mas que um grande artista pode aparecer em qualquer lugar.
O Remy não virou chef porque memorizou receitas. Ele virou chef porque entendia por que os sabores funcionavam juntos. Quando provava algo novo, não estava consultando um banco de dados interno. Estava raciocinando.
A IA sabe todas as receitas. Literalmente. Leu mais código do que qualquer dev vai ler na vida inteira. Mas ela não sabe quando a receita está errada para esse contexto específico, nessa codebase específica, com essas constraints e esse histórico e esse débito técnico particulares.
O julgamento não se acumula passivamente. Ele se desenvolve. E Anders Ericsson, o pesquisador que dedicou a vida a estudar como pessoas se tornam realmente boas em algo, chamou isso de prática deliberada: não é o tempo que você passa fazendo uma coisa, é a qualidade do esforço cognitivo que você coloca nela. Você pode escrever código por anos e não melhorar se nunca se expuser à dificuldade de verdade. E você pode comprimir muito aprendizado se se expuser às situações certas — com atenção, com fricção, com a disposição de entender o que deu errado.
Terceirizar esse momento pra IA é burrice. É abrir mão do único processo que te tornaria melhor.
O que isso tem a ver com Rails — e com você
Rails tem uma filosofia muito específica: convention over configuration. O framework decide muita coisa por você. Esse é um dos seus maiores poderes — mas só funciona quando você entende quais decisões estão sendo tomadas e por quê.
Quando você deixa a IA gerar migrations, callbacks, scopes sem entender o que está acontecendo por baixo, você não está aprendendo Rails. Você está gerenciando saídas de texto. E quando algo der errado — e vai dar — você não vai ter nenhuma base para debugar, porque nunca construiu o modelo mental do que deveria estar acontecendo.
Na Academia do Ruby criamos as dinâmicas de aprendizado em torno disso. A própria Amál.IA existe para acelerar o entendimento — não para substituir o momento em que ele deve acontecer. Construir projetos faz parte. Entender o ActiveRecord também. Não é enrolação. É porque sabemos que a resposta que você decifra vale dez vezes mais que a resposta que você copia e cola.
Um bom sênior não aparece do nada. Se forma. É o júnior de cinco anos atrás que foi exposto a problemas reais, que quebrou a cabeça, que construiu julgamento ao longo do caminho.
Tenho colegas do meu estágio onde aprendi Ruby — pessoas que passaram por esse processo de verdade — que hoje são sêniores, trabalham no exterior ou lideram times de tecnologia. Não porque nasceram com algum dom especial. Porque foram expostos à dificuldade certa, no momento certo, sem atalho que roubasse o aprendizado deles.
Se as empresas pararem de contratar e treinar essa camada — e muitas já pararam — daqui a alguns anos vão competir por um mercado encolhendo de devs experientes enquanto a lâmpada continua piscando. E ninguém vai saber o que fazer no escuro. É um pouco o que aconteceu com COBOL: de repente o mundo percebeu que parou de formar as pessoas que sabiam operar sistemas críticos, e os poucos que restavam viraram ouro.
Analistas já têm nome pra isso: slow decay. Um ecossistema que parou de treinar seus substitutos.
A prova mais concreta que vi disso acontecendo às avessas — um processo que foi buscar exatamente o tipo de júnior que o mercado parou de procurar — está nesse artigo que analisei aqui na Academia. Vale a leitura.
Então, respondendo à pergunta do título: não, a IA não vai tirar seu emprego de programador júnior.
Mas vai tirar de quem era júnior no sentido errado. De quem existia pra executar, não pra pensar. De quem nunca precisou entender o porquê porque sempre teve um tutorial, um Stack Overflow, ou agora um ChatGPT pra dar a resposta pronta.
A régua de corte mudou: ou você entende a lógica do que está construindo, ou você é apenas um operador de ferramenta, que vai ser substituído por um CLI.
Ainda não há comentários. Seja o primeiro a comentar!