Saltar para o conteúdo

KI e empregos de programador: Steve Yegge alerta que 50 por cento estão em risco

Programador a apontar para código num ecrã de computador numa equipa de trabalho num escritório moderno.

A automatização de tarefas de programação, impulsionada pela IA, está a permitir uma espécie de “contabilidade de cabeça” brutal nas administrações. Se uma equipa mais pequena, apoiada por IA, consegue entregar o mesmo que antes exigia um departamento inteiro, a pergunta reaparece com outra urgência: afinal, quantos programadores precisa uma empresa - e o que acontece a todos os restantes?

Porque é que as grandes empresas estão a preferir investir em GPUs em vez de pessoas

Por trás da revolução da IA decorre uma disputa orçamental simples, mas implacável. De um lado, estão os salários dos programadores. Do outro, os custos a disparar de centros de dados, GPUs e licenças de grandes modelos de IA.

Cada prompt enviado a um modelo tem um custo. Quanto mais as empresas embutem IA nos produtos e nos processos internos, maior fica a factura. Em paralelo, quando entram em cena boas ferramentas de IA, a produtividade por programador tende a subir de forma visível.

"Cada vez mais líderes chegam à mesma conclusão: é preferível ter poucos programadores com ferramentas de IA extremamente potentes do que muitos programadores com recursos médios."

Esta pressão económica está a empurrar as prioridades numa direcção clara:

  • O orçamento sai de pessoal e passa para infraestrutura de IA.
  • As equipas encolhem, mas ganham mais automatização.
  • Quem fica trabalha lado a lado com assistentes e agentes de IA.

As vagas de despedimentos no sector tecnológico já não se explicam apenas por “demasiado pessoal depois da pandemia”. A lógica que se impõe é outra: se a IA passa a absorver uma parte do trabalho, ajusta-se o tamanho das equipas à nova produtividade.

O alerta de Steve Yegge: 50 por cento dos empregos de programador podem tremer

Um dos sinais mais explícitos desta mudança vem de Steve Yegge. Trabalhou mais de uma década na Google e antes disso na Amazon, somando mais de 40 anos de experiência. Para ele, o sector aproxima-se de um ponto de viragem - e mais depressa do que muitos gostariam.

Numa conversa associada ao formato “The Pragmatic Engineer”, descreve um cenário capaz de inquietar muitos programadores: grandes empresas poderão reduzir as equipas de desenvolvimento em cerca de metade - não como um corte temporário, mas como um novo padrão.

"A aposta central é esta: com metade da força de trabalho, equipada com sistemas de IA fortes, consegue-se o mesmo output - ou até mais."

O próprio trabalho muda de natureza. O tempo gasto a escrever linhas de código à mão tende a cair, dando lugar a outras actividades, como:

  • redigir requisitos para agentes de IA,
  • validar código gerado automaticamente,
  • corrigir cadeias de erros que resultam de vários passos entre agentes,
  • decidir o que faz sentido automatizar - e o que é melhor não automatizar.

Yegge aponta ainda para uma clivagem crescente na profissão: de um lado, programadores que integram a IA no dia a dia e se tornam muito mais produtivos em pouco tempo; do outro, quem recorre a estas ferramentas de forma pontual ou com resistência, arriscando ficar encostado a funções periféricas.

Da máquina de escrever código ao realizador de IA

O quotidiano clássico - “abrir ticket, programar a funcionalidade manualmente, testar, fazer deploy” - vai sendo substituído, aos poucos, por um modelo diferente. Em vez de fazer tudo na ponta dos dedos, o programador passa a orquestrar vários agentes de IA, cada um a tratar de uma parte: gerar código, criar testes, produzir documentação, preparar scripts de migração.

Com isso, a responsabilidade desloca-se: menos ênfase na tarefa de digitar, mais atenção a arquitectura, garantia de qualidade e decisões estratégicas. Quem acompanha esta transição tende a proteger-se em funções onde a IA funciona mais como amplificador do que como ameaça.

Menos empregos em grandes empresas, mais equipas pequenas com enorme força

O outro lado interessante da redução nas grandes organizações é que as barreiras de entrada para equipas pequenas descem a pique. O que antes só era viável com uma equipa de desenvolvimento de 30 pessoas, hoje pode ser feito por alguns programadores bem preparados, apoiados por agentes de IA orquestrados.

"Hoje, equipas pequenas conseguem operar como mini-fábricas de software - metade humano, metade automatizado."

Vários movimentos encaixam-se entre si:

  • Sistemas de agentes assumem rotinas como testes, refactorings e documentação.
  • Infraestrutura cloud e ferramentas no-code reduzem custos fixos.
  • Um único programador consegue prototipar muito mais depressa e testar no mercado.

Em termos técnicos, isto faz lembrar a ruptura trazida pelo boom da cloud: na altura, as startups passaram a escalar rapidamente sem salas de servidores próprias. Agora, surge um efeito semelhante na “mão de obra”: a produção de software cresce sem exigir que o tamanho da equipa cresça na mesma proporção.

Porque é que muitos programadores sénior estão a sair das grandes empresas

Ao mesmo tempo, uma parte dos profissionais mais experientes está a abandonar voluntariamente os gigantes tecnológicos. Com IA no conjunto de ferramentas, muitas vezes basta um núcleo pequeno para atacar uma nova ideia de produto a sério. Quem está cansado de fricções políticas e burocráticas dentro de grandes empresas vê no momento actual uma oportunidade rara.

O resultado é que uma fatia da capacidade de inovar migra de grandes organizações para startups, pequenas consultoras e até negócios de uma só pessoa. As grandes empresas ainda têm de digerir, a nível organizacional, o seu próprio ganho de produtividade - enquanto equipas pequenas já arrancam sem esse peso.

Quão real é o risco para o teu emprego de programador?

A previsão de “menos 50 por cento de programadores” não atinge todos com a mesma intensidade. Os primeiros a sentir pressão são os papéis mais assentes em rotina e tarefas repetitivas. Quem passa os dias a construir formulários CRUD semelhantes ou APIs padrão tende a notar o impacto mais cedo.

Função Risco com IA Motivo
Programador júnior sem especialização alto Muitas das suas tarefas são fáceis de automatizar.
Programador full-stack com experiência em IA médio É flexível e consegue orquestrar e integrar IA.
Arquitecto / Tech Lead baixo Decide sobre sistemas; a responsabilidade continua a ser profundamente humana.
DevOps / SRE médio Há muitas ferramentas, mas também elevada complexidade e responsabilidade.

Quem se apoia exclusivamente no conjunto de competências actual está a assumir um risco desnecessário. Quem, pelo contrário, traz já as ferramentas de IA para o trabalho diário aumenta o próprio output e acumula experiência numa área que está a ganhar um peso enorme.

Estratégias concretas para continuares relevante como programador na era da IA

Em vez de ficar apenas a olhar para a possível redução de empregos, vale mais analisar, com frieza, onde é possível mexer. Há três alavancas que se destacam:

  • Desenvolver activamente com IA: usar Copilot, chatbots e agentes todos os dias para acelerar tarefas repetitivas.
  • Construir conhecimento de domínio: compreensão do sector (finanças, medicina, indústria) transforma código “substituível” em valor estratégico.
  • Assumir responsabilidade por sistemas: arquitectura, segurança, privacidade de dados e operação são difíceis de automatizar.

Quem consegue explicar em reuniões o que um agente de IA consegue fazer, o que não consegue, como um modelo “alucina” e como mitigar esses erros, acaba por ganhar uma função mais relevante. As empresas precisam de pessoas capazes de enquadrar riscos e limites destas ferramentas.

O que termos como “agente” significam mesmo no dia a dia

A expressão “agente de IA” pode soar abstracta, mas normalmente refere-se a ferramentas bem concretas. Em geral, um agente combina três componentes:

  • um modelo de linguagem que compreende e gera texto,
  • acesso a ferramentas como bases de dados, clientes de API ou comandos de shell,
  • uma lógica que planeia e executa passos intermédios.

Na prática, um agente pode, por exemplo, escrever testes para uma nova funcionalidade, ajustar funções existentes, esboçar uma migração e, no fim, produzir documentação técnica. O programador passa a ser o revisor, o corrector e a rede de segurança.

Como poderá ser o dia a dia de uma equipa de desenvolvimento em 2030

Um cenário plausível: uma equipa de produto com quatro programadores, um designer e uma Product Owner. Em vez de passarem semanas mergulhados em pormenores, descrevem funcionalidades com precisão em linguagem natural. Vários agentes geram código, testes, mocks e especificações de API.

A equipa ocupa 60 por cento do tempo em review, garantia de qualidade, decisões de produto e no equilíbrio entre necessidades dos utilizadores, privacidade de dados e viabilidade técnica. Os restantes 40 por cento continuam a ir para desenvolvimento “clássico” - onde a automatização não chega, ou onde se trata de áreas especialmente sensíveis.

Para continuar competitivo num mundo destes, parecem necessários dois elementos: disponibilidade para reajustar a forma de trabalhar repetidamente e consciência clara de onde está o valor humano acima do output genérico da máquina.

A previsão de Steve Yegge pode soar radical à primeira vista. Olhando com mais atenção, o que descreve é uma deslocação: menos massa de programadores e mais equipas pequenas e eficazes, que usam a IA como uma segunda camada abaixo das suas próprias competências. Quem aprender cedo a comandar essa camada ficará numa posição muito melhor do que quem se limita a discutir se a IA “substitui programadores” - enquanto ela, discretamente, já vai ganhando espaço no repositório de código.


Comentários

Ainda não há comentários. Seja o primeiro!

Deixar um comentário