Menos Vaga Para Júnior: O Efeito Colateral Da IA Que Ninguém Está Gerenciando

Numa conversa recente com outro tech lead — dessas que acontecem mais por acaso do que por agenda, tomando café entre uma reunião e outra — o assunto chegou onde sempre chega ultimamente: quanto cada time está usando IA para escrever código, e o que isso está fazendo com o volume de trabalho que sobra para todo mundo. Em algum momento ele perguntou algo para o qual eu não tinha resposta pronta: "quando foi a última vez que você abriu uma vaga de júnior de verdade?" Fiquei pensando na pergunta depois, não porque tivesse algo constrangedor guardado, mas porque percebi que nunca tinha parado para examinar o padrão com atenção.

Não vou fingir aqui que tenho um dado interno da minha própria equipe para compartilhar, nem uma decisão de contratação que tomei e da qual poderia falar com autoridade. O que fiz depois dessa conversa foi ler. E o que encontrei em pesquisa de mercado publicada ao longo de 2026 foi mais desconfortável do que eu esperava: não é impressão isolada de um tech lead entre outro. Existe um conjunto de pesquisas, de fontes e metodologias diferentes, convergindo para o mesmo sinal — o mercado está reduzindo a contratação de desenvolvedor júnior, e o motivo apontado quase sempre é o mesmo: copiloto de IA permitindo que sênior dê conta de mais trabalho sozinho.

O que me prendeu não foi só o dado em si, mas a conexão que ele força com outro assunto já discutido neste blog: a crise de dívida técnica gerada por código produzido com IA sem revisão criteriosa — o que ficou conhecido como vibe coding, tratado com mais profundidade em um post desta mesma semana sobre a fatura que esse código está deixando para trás. Se times inteiros vão precisar, nos próximos anos, de gente capaz de ler código que não escreveu e consertar sem reescrever do zero — e se essa habilidade historicamente nasce do trabalho que júnior faz nos primeiros anos, lendo código alheio e corrigindo bug em sistema que não construiu —, cortar contratação de entrada agora pode estar cortando, ao mesmo tempo, o funil de gente que vai saber resolver o problema que a própria IA está criando.

Este post não chega a uma resposta fechada, e digo isso de forma direta porque não tenho uma. O que tento fazer aqui é organizar o que a pesquisa disponível mostra, explicar o mecanismo por trás do corte, conectar isso com a questão da dívida técnica, e levantar as perguntas que acho que todo líder de engenharia deveria estar fazendo para o próprio time — mesmo sem uma resposta pronta para elas.

---

O Que As Pesquisas De 2026 Estão Mostrando, Juntas

Comecei pela pesquisa que mais circulou: um levantamento da LeadDev, citado por diversas publicações de 2026, segundo o qual 54% dos líderes de engenharia entrevistados planejam contratar menos júnior nos próximos ciclos. A justificativa não é corte de custo genérico — é que copilotos de IA permitem que sênior dê conta, sozinho, de um volume de trabalho que antes exigiria um time maior, incluindo gente em início de carreira. Não é afirmação de que júnior ficou inútil; é conta de capacidade que mudou de lado.

Esse número não está isolado. Uma pesquisa da IDC em parceria com a Deel — sem acesso direto ao relatório original, apenas dados citados por veículos secundários de 2026 — aponta que 66% das empresas em escala global planejam reduzir contratação de nível de entrada por causa de IA. É um escopo mais amplo que o da LeadDev, cobrindo empresa em geral e não só liderança de engenharia, diferença que vale registrar antes de tratar os dois números como a mesma medida.

O terceiro dado é o mais gritante em magnitude, e por isso o que mais exige cuidado ao repetir: uma reportagem do site Agent Wars, publicada em 15 de março de 2026, cita que a contratação de nível de entrada em empresas de ponta em IA caiu 73% ano a ano, enquanto a contratação geral nessas mesmas empresas caiu apenas 7% no mesmo período. A discrepância é o que importa aqui — não é que essas empresas contratem menos gente no geral, é que contratam desproporcionalmente menos gente em início de carreira, redistribuindo a vaga para quem já chega sênior.

O quarto dado carrega mais peso metodológico, mas também exige a ressalva mais explícita. Um estudo conduzido por pesquisadores de Harvard, analisando dados de 62 milhões de trabalhadores — citado por múltiplas fontes secundárias de 2026, sem acesso direto ao paper original — encontrou queda de 9% a 10% no emprego de desenvolvedores júnior em até seis trimestres após a adoção de IA generativa pelas empresas analisadas. É um estudo que, pela cobertura, tenta isolar o efeito da adoção de IA de outras variáveis de mercado, o que o torna mais rigoroso que uma pesquisa de opinião. Ainda assim chega até mim por cobertura terciária, não pelo paper em si — trato como o dado mais sério do conjunto, mas também o que menos deveria repetir como se tivesse lido a fonte primária.

Como contexto de adoção, dois números do GitHub ajudam a entender a escala do que está mudando o denominador: 92% dos desenvolvedores usam alguma ferramenta de IA para codar, e 77% usam assistente de IA diariamente. Não é minoria experimentando — é a maioria do mercado operando com IA embutida na rotina. Esse pano de fundo dá sentido aos quatro números anteriores: quando quase todo mundo usa copiloto todo dia, a pergunta de quem decide orçamento deixa de ser "vamos adotar IA" e passa a ser "quanto trabalho humano essa adoção ainda exige, e de que nível".

---

Por Que O Corte Recai Especificamente Sobre A Vaga De Entrada

O mecanismo por trás desse padrão não é misterioso. Copiloto de IA é mais eficaz em tarefa historicamente distribuída para júnior: implementar função bem especificada, escrever teste repetitivo, adaptar um padrão existente, gerar boilerplate. É o tipo de tarefa que servia de porta de entrada — contida o suficiente para fazer sem supervisão constante, mas que ainda ensinava algo sobre a base de código.

Quando um sênior tem copiloto capaz de gerar boa parte desse código de forma aceitável, a conta de "preciso de mais uma pessoa no time" muda. Em vez de abrir vaga de júnior para absorver o volume crescente de tarefa pequena, o sênior absorve esse volume sozinho, apoiado na ferramenta, e revisa o resultado — trabalho diferente de escrever do zero, mas que cabe na agenda de quem já está lá. É esse deslocamento que a pesquisa da LeadDev parece capturar: não é substituição direta de pessoa por ferramenta, é redistribuição de quem absorve o volume.

Isso conversa com algo que já discuti em um post sobre como a entrevista técnica está mudando na era dos agentes de código: o que uma empresa de fato contrata mudou de forma. Se a entrevista migra de "resolva este problema do zero" para "revise este código, decida se confia nele", a barreira para quem não tem experiência prévia de revisão real fica mais alta — precisamente a habilidade que quem nunca trabalhou tem menos chance de já carregar.

Há também um efeito de escala visível na discrepância do dado da Agent Wars — 73% de queda em vaga de entrada contra 7% em vaga geral. Empresa em ritmo agressivo de adoção de IA parece concluir que o time ideal hoje é menor e mais concentrado em gente que já opera sem treinamento extensivo. Isso é coerente com uma leitura que já fiz sobre o novo papel do desenvolvedor em 2026: a demanda por trabalho de baixo nível de abstração caiu, a demanda por julgamento e supervisão subiu, e quem ainda está construindo esse julgamento — todo mundo em início de carreira, por definição — fica de fora da fatia que cresceu.

Vale uma ressalva antes de seguir: nenhuma dessas pesquisas mede se o corte é permanente ou uma correção temporária enquanto o mercado calibra quanto valor incremental júnior ainda entrega com apoio de IA. Pesquisa de intenção — como a da LeadDev e a da IDC/Deel — mede plano declarado, não resultado consolidado ao longo de anos, o que é diferente de medir efeito já realizado, como tenta ser o estudo de Harvard.

---

A Ponta Que Fica Sem Conexão: Dívida Técnica E Formação De Sênior

Aqui chega a parte que mais me incomodou ao ler os dois assuntos lado a lado. Já escrevi, no post desta semana sobre a dívida técnica deixada pelo código gerado com vibe coding, sobre um volume crescente de código em produção que ninguém no time entende de verdade — gerado rápido, revisado superficialmente, funcionando até não funcionar mais, exigindo alguém capaz de entrar, ler a intenção original e consertar sem reescrever tudo. Esse trabalho tem um nome antigo, de décadas antes de qualquer IA generativa: manutenção. E manutenção de código legado, historicamente, é exatamente onde desenvolvedor júnior aprendia a virar sênior.

Pense num cenário hipotético só para ilustrar o mecanismo — não é relato de um time real. Imagine um desenvolvedor em início de carreira que passa os primeiros anos lendo módulo escrito por outra pessoa, descobrindo por que uma decisão estranha foi tomada cinco anos atrás, corrigindo bug num sistema que não desenhou. É trabalho menos glamouroso do que construir do zero, mas é o que ensina a diferença entre "código que funciona" e "código que alguém vai conseguir manter daqui a dois anos" — a habilidade central de quem se torna sênior de verdade.

Se a vaga de entrada está encolhendo na proporção que os dados da LeadDev, da IDC/Deel, da Agent Wars e de Harvard sugerem, esse aprendizado por exposição perde a massa de gente passando por ele — exatamente quando a demanda pela mesma habilidade, ler código gerado por IA que ninguém entende de verdade, está crescendo por causa do próprio volume de vibe coding acumulado. É uma tesoura fechando dos dois lados: menos gente entrando pelo caminho que ensinava essa habilidade, mais trabalho exigindo exatamente essa habilidade.

Não tenho certeza de que essa conexão está sendo tratada como prioridade de gestão em algum lugar, e é bem possível que não esteja, porque as duas conversas normalmente acontecem em fóruns diferentes. Quem discute corte de júnior fala de orçamento e produtividade por pessoa; quem discute dívida técnica de vibe coding fala de qualidade de código e incidente em produção. São discussões que raramente se cruzam numa mesma reunião, mas puxam o mesmo fio — porque quem vai resolver a dívida técnica em três ou cinco anos é, majoritariamente, quem hoje estaria entrando como júnior e não está entrando.

Isso não significa que a solução óbvia seja simplesmente reverter o corte e voltar a contratar júnior no volume de antes. O trabalho que sobra para júnior também mudou de natureza — boa parte da tarefa repetitiva que servia de treino inicial está sendo absorvida pela própria IA, então não seria possível recriar o modelo antigo só reabrindo vaga. O que fica claro é que ninguém parece estar desenhando deliberadamente um caminho alternativo de formação que substitua o que está sendo perdido. O corte acontece por conta orçamentária; a reposição do que ele tira em formação de talento, até onde encontrei, não recebe o mesmo grau de intenção.

---

O Que Muda Na Definição De "Trabalho De Entrada" Quando A Base Da Pirâmide Encolhe

Um ponto que vale examinar com mais cuidado é o que significa, concretamente, "trabalho de entrada" quando o volume de tarefa repetitiva cai. Já tratei, em um post sobre as habilidades que o desenvolvedor precisa construir na era dos agentes de código, como o centro de gravidade da profissão migra de escrever código para revisar, orquestrar e decidir sobre código que outra fonte — humana ou agente — produziu. Essa migração é real para sênior, mas cria um problema estrutural para quem está entrando: revisão criteriosa exige experiência prévia de ter escrito e sofrido com código ruim. É uma habilidade que parece exigir o próprio degrau que está sendo removido para chegar até ela.

Um segundo cenário hipotético ajuda a visualizar isso. Imagine uma empresa que decide, este ano, contratar metade do número de júnior que contratava antes, redistribuindo orçamento para dar mais copiloto e autonomia ao time sênior existente — decisão plausível dado o que os dados de 2026 mostram sobre o mercado, não uma decisão real que alguém tomou e da qual eu tenha conhecimento direto. Essa empresa resolve, no curto prazo, um problema de capacidade: entrega o mesmo volume com menos gente. Mas em três ou quatro anos, quando os sêniors atuais migrarem ou saírem, ela vai ter um buraco no meio da pirâmide — porque não formou o próximo lote capaz de assumir aquele nível de responsabilidade, e o mercado externo, se todo mundo fez o mesmo corte, também não vai ter esse lote disponível.

É esse tipo de risco que fica invisível em análise de curto prazo baseada só em produtividade por pessoa no trimestre atual. A métrica que melhora agora — menos gente, mesmo output, custo menor — é a métrica que esconde o custo que só aparece depois, quando o pipeline de formação já secou. Isso se relaciona com o que já escrevi sobre a carreira do desenvolvedor se deslocando para o papel de orquestrador de agentes: se o papel sênior do futuro é orquestrar e supervisionar múltiplos agentes em paralelo, falta responder de onde vem a próxima geração capaz de fazer essa supervisão com julgamento maduro — que normalmente vem de quem já fez, na prática, o trabalho que está supervisionando.

Há ainda uma dimensão de risco de concentração que merece nota. Se o corte de contratação júnior for um movimento correlacionado no mercado inteiro — o que os quatro dados citados sugerem, por aparecerem em fontes e metodologias distintas apontando na mesma direção —, não é um problema que uma empresa isolada resolve contratando mais júnior sozinha. Se o mercado inteiro reduz a formação ao mesmo tempo, a escassez futura de sênior qualificado afeta todo mundo junto, e reverter a estratégia sozinho só faz competir por um recurso mais escasso alguns anos à frente.

---

Perguntas Que Vale Levar Para Dentro Do Próprio Time

Não tenho uma resposta fechada para o que um líder de engenharia deveria fazer diante desse cenário, e seria desonesto fingir que tenho. O que vale a pena é levar um conjunto de perguntas concretas para dentro da própria equipe, mesmo sem solução pronta do outro lado.

A primeira é sobre intenção declarada versus prática real: o time está reduzindo contratação júnior porque fez uma análise deliberada de que o trabalho de entrada mudou de natureza, ou porque orçamento apertou e júnior é o corte mais fácil de justificar no curto prazo? São dois motivos que produzem a mesma decisão, mas exigem planos de mitigação diferentes depois.

A segunda é sobre o que substitui a exposição perdida. Se o volume de tarefa repetitiva que servia de treino inicial caiu, existe algum desenho deliberado de como alguém em início de carreira vai construir a mesma bagagem de leitura de código alheio — ou essa formação está sendo deixada ao acaso?

A terceira é sobre quem vai fazer a manutenção da dívida técnica acumulada daqui a três anos. Se boa parte do código em produção foi gerado com apoio pesado de IA e revisão superficial — o cenário descrito no post sobre vibe coding — e o time sênior atual for o único grupo capacitado a lidar com esse código quando quebrar, o que acontece quando esse grupo, sozinho, não dá conta do volume? Não é pergunta retórica; é uma conta de capacidade que parece estar sendo adiada.

A quarta é sobre horizonte de tempo. Toda pesquisa citada aqui mede intenção ou resultado de curtíssimo prazo, no máximo alguns trimestres. Nenhuma responde o que acontece daqui a cinco ou dez anos, quando a geração atual de sênior que aprendeu antes da adoção massiva de IA começar a se aposentar ou migrar de carreira. Vale perguntar se existe algum plano — mesmo rascunhado — para esse horizonte mais longo.

A quinta, talvez a mais difícil de responder com honestidade, é se a própria liderança sabe distinguir entre "este júnior específico não entrega valor suficiente para justificar o custo" e "júnior como categoria parou de fazer sentido economicamente". São afirmações muito diferentes, e a pesquisa agregada não ajuda a diferenciar uma da outra dentro de um time específico — só um exame direto do próprio contexto consegue.

---

Conclusão

Volto à pergunta que meu colega tech lead fez naquela conversa de corredor: quando foi a última vez que alguém abriu uma vaga de júnior de verdade. Não tenho resposta pronta para o meu próprio contexto, mas a pergunta ficou mais pesada depois de ler os quatro conjuntos de dados resumidos aqui. Não é número isolado nem relatório de marketing de uma consultoria querendo vender diagnóstico. São fontes e metodologias diferentes convergindo para o mesmo sinal: o mercado está reduzindo a formação de talento em início de carreira na hora exata em que outra tendência — o acúmulo de dívida técnica de código gerado por IA sem entendimento profundo — aumenta a demanda pelo tipo de habilidade que essa formação costumava produzir.

Não acho que a resposta correta seja um apelo genérico para "contratar mais júnior porque é o certo a fazer". Isso ignoraria a realidade econômica que qualquer líder de engenharia enfrenta, e que boa parte do trabalho que servia de treino inicial de fato mudou de natureza com a adoção de copiloto. O que vale reter é mais modesto e, ao mesmo tempo, mais urgente: essa decisão está sendo tomada, hoje, em escala de mercado, sem que a maior parte das empresas pareça medir o custo de formação sacrificado junto com o custo de folha de pagamento economizado. Uma coisa aparece no balanço deste trimestre. A outra só aparece daqui a alguns anos, quando for tarde para corrigir com facilidade.

Fecho sem call to action e sem fórmula pronta, porque genuinamente não tenho uma. Tenho a suspeita, reforçada por cada fonte que li nesta pesquisa, de que estamos otimizando uma métrica de curto prazo — produtividade por pessoa, custo por entrega — às custas de uma métrica que ninguém mede direito porque só aparece no resultado, anos depois: quantas pessoas capazes de assumir responsabilidade sênior o mercado vai ter disponíveis quando a geração atual precisar passar o bastão. Se essa conta está sendo feita em algum lugar com o rigor que os números de contratação recebem, ainda não encontrei essa análise publicada. Pode ser que exista e eu não tenha lido. Pode ser, também, que realmente ninguém esteja gerenciando esse efeito colateral ainda.

Fontes:

• CodeConductor — The Future of Junior Developers in the Age of AI
• Hakia — Junior Developer Crisis 2026
• Addy Osmani — What Happens in the Next Two Years
• Agent Wars — Junior Developer Hiring and the AI Talent Pipeline
• Kara AI — The Broken Ladder: Junior Developer Pipeline Collapse