Ideia principal

Num time de desenvolvimento, o aprendizado acontecia por degraus. Ninguém entregava a arquitetura de um produto crítico a um júnior: davam a ele um bug limitado, um endpoint simples, um script, uma correção, um teste, uma refatoração modesta. Essas tarefas não eram só trabalho a fazer; eram os primeiros degraus da escada, aqueles em que dá para quebrar a cara sem colocar o sistema em risco, aprender a ler um código existente, a entender um ticket, a receber uma revisão, a descobrir que uma mudança local produz efeitos em outro lugar.

O boilerplate, os pequenos scripts, as correções simples, os testes padrão e as integrações óbvias são exatamente o que um assistente gera mais rápido e com mais segurança. A sobreposição não é acidental: essas tarefas formavam porque eram delimitadas e repetitivas, e é essa mesma propriedade que as torna automatizáveis.

A pergunta não é, portanto, saber se um assistente substitui juniores, mas o que acontece quando ele substitui as tarefas que os fabricavam.

Por que isso importa

Isso separa dois debates que se misturam. O emprego dos juniores é uma questão de vagas; a fabricação dos seniores é uma questão de cadeia de formação, e a segunda sobrevive mal mesmo que a primeira seja resolvida por contratação.

Isso também dá o critério para desenhar um uso sustentável: o que é entregue à ferramenta deve ser decidido em função do que ela tira da escada de aprendizado, não só do tempo que faz ganhar.

Nuances e limites

O aprendizado pode passar por outro caminho. Um assistente usado como tutor — explicar, comparar, fazer verbalizar, simular uma revisão de código — substitui uma parte do que o primeiro degrau ensinava, desde que haja disciplina, curiosidade e enquadramento para isso.

E nem todos os primeiros degraus formavam: uma parte do boilerplate não ensinava nada a ninguém, e automatizá-la não custa nenhuma competência.

Questões em aberto

• Quais tarefas de entrada numa profissão de software mantêm um valor de formação que nenhuma explicação reproduz?