As Novas Gerações Estão Muito Bem
A IA não comeu o valor do júnior. Ela expandiu esse valor.
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
“A IA comeu o valor marginal do júnior”. Esse foi o feedback que recebi do último post sobre esse tema. Segundo esse argumento, o trabalho de um engenheiro júnior funciona mais ou menos assim:
- Existe a necessidade de uma solução. Alguém mais experiente (um engenheiro sênior) planeja e desenha essa solução.
- O engenheiro sênior quebra o trabalho em várias tarefas pequenas, deixando claros os passos a serem seguidos. Cada tarefa vai para um engenheiro júnior.
- O engenheiro júnior executa, o que hoje em dia significa passar aquilo como prompt para uma ferramenta de IA e abrir um pull request (PR).
- O PR recebe feedback de engenheiros mais sêniores. O engenheiro júnior pega esse feedback e leva de volta para a ferramenta de IA, propondo mudanças.
- Repete até terminar.
Se o processo acima é o que acontece na prática, por que precisamos de um engenheiro júnior? Ele está só repassando pedidos (e às vezes adicionando ruído) de um lado para o outro, e custa um salário integral. É um argumento justo.
Antes de tirar conclusões, vamos olhar para uma história diferente. Ou talvez a mesma história, abordada de outra maneira.
No nosso produto, existia uma funcionalidade que vinha sendo pedida havia anos, mas que nunca tinha sido construída. Ela não era excessivamente complexa, mas também não era crítica. Ou pelo menos não era crítica para clientes suficientes para passar pelo corte de priorização. Isso significava que, ano após ano, alguns clientes ficavam frustrados por não ter algo de que precisavam.
Neste verão, atribuímos esse problema a um estagiário (o que é menos tempo de casa ainda do que um engenheiro júnior). O estagiário liderou o desenvolvimento dessa funcionalidade. Conversou com o product manager para entender o problema e os requisitos. Escreveu o documento de design sobre como abordar aquilo, alinhou com o time e construiu. Claro que fez isso com a ajuda da IA e do time com quem estava trabalhando.
Mas foi ele quem liderou. Lidou com as inconsistências, com o entendimento dos trade-offs, tanto na parte técnica quanto na de produto. Adaptou a abordagem conforme encontrava problemas. E entregou valor. A IA produziu boa parte do código, e ele foi dono das decisões. Um problema de cliente que não teria sido resolvido agora está resolvido. Por um estagiário, a um custo muito baixo para a empresa.
Todo engenheiro gerencia complexidade. O que muda é o quanto.
Além do fato de que qualquer empresa vai precisar de engenheiros sêniores no futuro, existem razões bastante pragmáticas pelas quais engenheiros juniores continuam sendo valiosos.
Engenheiros juniores continuam adicionando capacidade a uma organização. E isso porque o trabalho de um engenheiro não é escrever código (ou passar prompt para uma ferramenta de IA) seguindo uma especificação. É resolver um problema de cliente com software, gerenciando a complexidade técnica que existe em decidir como fazer isso. Isso vale para todos os engenheiros. Engenheiros staff gerenciam muita complexidade. Engenheiros juniores gerenciam pouca complexidade. Mas o papel é o mesmo.
Isso vai além de escrever código. Exige entender o problema e também a perspectiva do cliente. Exige entender que, se você constrói uma funcionalidade de determinada maneira, isso leva a um conjunto específico de trade-offs. E esses trade-offs estão além do que a IA consegue decidir, porque exigem um contexto mais amplo do que o código. Tomada de decisão técnica continua sendo muito importante, e engenheiros juniores contribuem com isso, permitindo que a organização faça mais.
Treinar ficou muito mais barato. A maior parte do custo de treinamento de um engenheiro com pouco tempo de carreira está em entender o contexto técnico da empresa, ou seja, as nuances de uma base de código e de uma arquitetura grandes, e em dar treinamento básico de software, como linguagem, ferramentas e padrões.
No passado, isso exigia ou uma proatividade considerável do engenheiro júnior, pesquisando temas e estudando, ou exigia esforço humano de verdade de colegas mais sêniores, que gastavam tempo explicando conceitos básicos. Esse esforço não foi eliminado, já que o contexto que vem de pessoas continua sendo essencial para produtividade em software. Mas boa parte desse trabalho pode ser encurtada com o uso de IA.
Ser AI-native é valioso. Não dá, como indústria, dizer que engenheiros precisam ser AI-native nas descrições de vaga e depois não contratar justamente as pessoas que mais se encaixam nessa descrição. Se a premissa é que a IA vai simplificar radicalmente a parte técnica do papel, então as pessoas que começaram a carreira com IA vão estar na melhor posição assim que adquirirem experiência.
Voltando ao exemplo do início, a funcionalidade que o estagiário entregou era pedida havia muito tempo. Não era importante o suficiente para ser priorizada, mas exigia julgamento demais para ser entregue à IA. Essas tarefas existem e vão continuar existindo em todo time. A IA expande o que cada nível consegue fazer, incluindo os juniores.
Mais importante do que isso, organizações de engenharia vão continuar precisando de julgamento técnico. E o julgamento futuro da sua organização deveria estar crescendo agora.
Comentários