Programador de software júnior

Os programadores de software de sistemas estão em 7.º lugar por emprego dentro do quintil de maior exposição no anexo do artigo, e o desenvolvimento de software é uma das duas profissões que os autores destacam como estudo de caso. Registos salariais do setor privado dos EUA da ADP que cobrem milhões de trabalhadores, de novembro de 2022 a junho de 2026. A queda de 11% é para os 22 aos 25 anos nos dois quintis mais expostos à IA; o mesmo grupo etário nos três quintis menos expostos cresceu cerca de 10%. Os trabalhadores experientes não mostram uma diferença comparável, e os autores afirmam não encontrar indícios de uma substituição generalizada em toda a economia. As conclusões são descritivas, não causais, e são medidas ao nível da profissão, não da tarefa.

Alteração verificável na contratação, nos efetivos, nas horas ou no âmbito do posto. O maior peso, mas a atribuição causal continua a ter de ser argumentada, não presumida.

Um recenseamento feito por obrigação legal: as mesmas 20 perguntas a cada organismo declarante, cada uma respondida com S ou N, com o produto indicado e as licenças dadas por escalões. «Gerar código com IA» tem S em 31 de 45, e os produtos indicados não existiam há três anos. Um S é o empregador a declarar que tem a ferramenta, não uma medição de quanto código ela escreve nem de quanto desse código é mantido, e um escalão de licenças não é uma contagem de pessoas a escrever código com ela. A pergunta não distingue um engenheiro com dez anos de experiência de um com dez meses; este registo fica associado aqui porque escrever código rotineiro — endpoints CRUD, formulários, integrações padrão, testes de padrões conhecidos — é exatamente esta tarefa, e não porque o inventário diga alguma coisa sobre programadores júnior.

Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.

Uma norma de engenharia que vincula as equipas de software do Home Office. Diz que as equipas devem usar IA onde ela ajude, que os resultados assistidos por IA têm de ser revistos e aprovados por um humano antes de chegarem à produção e têm de ser rastreáveis, e que as equipas manterão plena responsabilização por todo o código e todos os resultados assistidos por IA, porque as ferramentas de IA não podem substituir o juízo, a compreensão, o papel de dono ou a responsabilidade humanos pelas decisões, pelo desenho ou pelas alterações feitas aos sistemas. O «must» firme aplica-se à revisão humana; a frase sobre o desenho é uma declaração de responsabilização. Vincula os engenheiros de um único departamento governamental.

Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.

Um estudo universitário de modelos de linguagem a redigir especificações de requisitos num projeto de uma consultora informática, avaliado pelo analista especialista da empresa. Um subconjunto de histórias de utilizador ficou por tratar em todos os modelos, porque o conhecimento que os analistas detêm pode ser tácito e não estar escrito nos documentos de levantamento de requisitos; o analista estimou uma poupança de tempo de redação de 10% a 15%, e os autores concluem que os modelos podem ajudar na documentação inicial mas não podem substituir a intervenção humana. É um projeto com um especialista, e o papel estudado é o de analista de requisitos e não o de programador.

Ensaio em pequena escala num contexto real. Diz-nos que as condições de implementação estão a ser testadas, não que se verificam, por isso um piloto nunca chega sozinho; dois independentes chegam.

Uma grande empresa de tecnologia, com dados declarados por ela própria e sem definir como se mede «gerado» (completamento automático ou funções inteiras). Não diz nada sobre contratação; o passo de revisão ficou com os engenheiros.

Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.

Engenheiros da Google a descrever as suas próprias ferramentas internas. A Google atribuiu aleatoriamente 50% de todos os seus programadores a receber no IDE correções sugeridas por aprendizagem automática para builds falhados e comparou-os com os restantes durante 11 semanas; depois disso, cerca de 34% dos utilizadores que tiveram um build falhado num mês aplicaram essas correções, e a reparação de builds por aprendizagem automática foi ativada para todos os programadores da Google. O programador pré-visualiza cada correção e escolhe aceitá-la ou rejeitá-la. São erros de build e de compilação — o tipo que a publicação considera bem compreendido — e não falhas em tempo de execução cuja causa está longe do sintoma; a Google vende ferramentas de IA para programadores.

Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.

Esta profissão tem a divisão mais nítida entre entrada e sénior de tudo o que está no primeiro lote. As tarefas que tornavam economicamente justificável criar lugares júnior são as que estão a ser automatizadas, enquanto as que definem o trabalho sénior não estão. O risco não é programar deixar de ser uma carreira — é estar a ser retirado o primeiro degrau da escada enquanto o topo fica intacto. Em concreto: tens de demonstrar critério, e não débito, e tens de o fazer antes de alguém esperar isso de ti.

A tua posição é comparativamente forte, mas depende de haver gente que aprendeu a julgar pela via lenta. Se o degrau de entrada continuar partido, a restrição que chega daqui a alguns anos não é a automatização — é não haver ninguém com a experiência necessária para rever o que as ferramentas produzem. Vale a pena pensar nisto como uma questão de contratação e de acompanhamento agora, e não mais tarde.

Ficar e reforçar-te

Ganhar critério mais depressa do que a escada espera

O que escasseia é alguém capaz de dizer se o código gerado está certo. Podes começar a demonstrá-lo no primeiro dia em vez de esperar dois anos.

Refazer o posto

Especializares-te onde a correção sai cara

Pagamentos, segurança, integridade de dados, infraestrutura — os domínios onde uma resposta errada e confiante custa dinheiro a sério mantêm as pessoas bem dentro do circuito.

Movimento lateral

Lugares que ficam entre a engenharia e o problema

Engenharia de soluções, experiência de programador, produto técnico — trabalhos onde o valor está em perceber ao mesmo tempo o sistema e o que alguém precisa dele.

Mudança de setor

Aplicar o pensamento de engenharia fora do software

Muitos setores quase não têm ninguém que perceba o seu domínio e ao mesmo tempo saiba construir. Essa combinação é rara e não compete com a geração.

Sim, mas por uma razão diferente da de há cinco anos. Aprender a programar servia para se conseguir produzir código. Agora o valor está em conseguir julgá-lo — e não se julga código que não se saberia escrever. A formação continua a funcionar; o que mudou é que o mercado de emprego de entrada já não te paga de forma fiável enquanto ganhas o critério. Conta com essa falha de forma explícita em vez de assumires que o primeiro emprego te vai ensinar.

A razão económica pela qual esses lugares existiam — débito barato sobre trabalho bem especificado — está a enfraquecer, e isso é uma mudança estrutural real e não um ciclo. Mas as equipas que deixam de contratar juniores por completo criam um problema a si próprias: daqui a alguns anos não têm ninguém que tenha aprendido a julgar o resultado pela via difícil. Conta com o lugar a ser redefinido à volta da revisão e do critério em vez da produção, e com menos lugares por equipa do que antes.

O sinal para os programadores em início de carreira não é a capacidade dos modelos, é quantos recém-licenciados a tua empresa recruta. Vê quantos juniores contratou este ano contra há dois. Várias organizações que cortaram a entrada de juniores disseram publicamente que eliminaram o caminho que produz seniores — essa admissão é o facto que vale a pena acompanhar.

Escrever código de rotina — a tarefa marcada como em automatização, e a que enchia os dois primeiros anos de um júnior. O desenho de sistemas e os requisitos não estão, mas é onde se chega depois desses dois anos, e nada substituiu o caminho.

Sim, e por uma razão que mudou: agora aprende-se a programar para conseguir rever código, não para o produzir. Rever bem um resultado fluente mas errado exige ter escrito a mesma coisa, por isso a aprendizagem continua a ter de acontecer pela via lenta, mesmo com o mercado desse resultado a encolher.