A primeira geração que aprendeu a programar conversando já está no mercado

A descrição se repetiu com pequenas variações em quinze conversas com líderes técnicos de empresas brasileiras de porte diferente: a pessoa júnior de 2026 entrega a primeira versão de uma feature em um terço do tempo que a pessoa júnior de 2021 levava, e leva três vezes mais tempo para consertar quando a feature quebra em produção por um motivo que não está na tela.

Não é falta de inteligência e não é preguiça. É onde a prática aconteceu.

O que se aprende escrevendo errado

Depurar é a atividade que ensina o modelo mental de um sistema. Você tem uma hipótese, testa, a hipótese está errada, e ao descobrir por que estava errada você aprende como a coisa realmente funciona por baixo.

Esse ciclo é lento, frustrante e é o mecanismo inteiro do aprendizado. Quando a primeira versão do código já sai plausível, o ciclo não acontece. Não porque alguém pulou etapa de propósito, mas porque a etapa deixou de ser necessária para o resultado imediato.

O efeito aparece depois, e aparece num lugar específico: na capacidade de formular hipótese sobre onde o problema está antes de olhar. Um engenheiro experiente olha um stack trace e já tem três suspeitos. Essa lista de suspeitos vem de anos errando.

O que as empresas estão fazendo

As respostas variam e a maioria é ruim.

A resposta mais comum é proibir ou restringir a ferramenta em período de onboarding. Funciona no papel e falha na prática, porque a pessoa usa em casa. Além disso, treina para um ambiente que não é o ambiente real de trabalho.

A segunda resposta é code review mais rígido. Ajuda, mas desloca o custo: o revisor sênior vira gargalo e passa a fazer, em revisão, o trabalho de ensino que não aconteceu antes.

A terceira, e a que apareceu com melhores resultados relatados, é mudar o tipo de tarefa dada nos primeiros meses. Em vez de "implemente esta feature", a tarefa é "este bug existe, encontre a causa". Nenhuma linha nova precisa ser escrita para completar o exercício. O produto do trabalho é a explicação.

Duas empresas relataram usar um formato ainda mais direto: o júnior recebe um sistema com uma falha plantada de propósito, sem acesso ao commit que a introduziu, e tem um dia para explicar o que acontece. Custa tempo de gente sênior para montar. É a única coisa que os entrevistados descreveram como tendo efeito claro.

O outro lado

Vale registrar o que os mesmos líderes disseram sem que eu perguntasse.

Essa geração lê código alheio com muito menos resistência do que as anteriores. Ler o código de outra pessoa era, historicamente, a tarefa que ninguém queria. Quem aprendeu conversando com um assistente passa o dia lendo código que não escreveu e desenvolveu tolerância para isso.

Eles também são melhores em explicitar requisito. Quem precisa descrever o que quer em texto, várias vezes por dia, para obter um resultado utilizável, treina exatamente a habilidade que falta em boa parte da engenharia sênior: dizer com precisão o que o sistema deve fazer antes de escrever qualquer coisa.

Três dos entrevistados disseram, com palavras diferentes, que preferem revisar a especificação escrita por um júnior de 2026 do que a de um júnior de 2019.

O ajuste que falta

O que essa discussão tem de novo é menos do que parece. Toda camada de abstração produziu a mesma ansiedade e o mesmo padrão: quem aprendeu na camada de cima entende menos da de baixo até precisar, e aí aprende de forma mais dolorida.

A diferença desta vez é a velocidade com que a camada nova foi adotada, sem que ninguém tivesse tempo de redesenhar como se forma alguém.

Continua valendo o mesmo remédio de sempre. Dê problemas cuja solução não pode ser gerada, apenas investigada. O resto se resolve.