Na corrida do sector tecnológico para industrializar a inteligência artificial (IA), um emprego que parecia sólido - o de programador - começa subitamente a parecer bem menos garantido do que há pouco tempo.
De Silicon Valley ao resto do mundo, engenheiros seniores dizem agora em voz alta aquilo que antes circulava em privado: as ferramentas de IA estão a transformar o trabalho de software a uma velocidade tal que muitas empresas já estão, de forma séria, a simular quantos programadores humanos continuam a precisar.
A nova escolha das big tech: GPUs ou engenheiros de software com IA?
Nos últimos dois anos, a estrutura de custos das grandes tecnológicas mudou de forma clara. O principal “peso” deixa de ser o número de pessoas e passa a ser a capacidade de computação. Treinar e executar modelos de IA de grande escala exige enormes clusters de GPUs, centros de dados especializados e licenças caras para modelos de ponta.
Cada nova funcionalidade baseada em IA lançada para milhões de utilizadores tende a disparar o gasto em cloud e hardware. As equipas financeiras olham para orçamentos em que infraestrutura e acesso a modelos absorvem uma fatia cada vez maior.
Ao mesmo tempo, assistentes de programação com IA e ferramentas de testes automatizados aumentaram o rendimento por engenheiro. Um programador, com um conjunto bem escolhido de “ajudantes” de IA, consegue hoje entregar trabalho que antes exigia uma pequena equipa.
Para muitos líderes tecnológicos, a pergunta desconfortável já não é “a IA aumenta a produtividade?”, mas sim “quantas pessoas continuamos a precisar se aumentar?”.
Perante a escalada dos custos de infraestrutura de IA, alguns executivos estão a optar por uma troca directa: manter menos engenheiros, equipá-los com ferramentas muito mais potentes e canalizar a poupança para GPUs, modelos e automação.
Esse raciocínio começa a influenciar planos de contratação, ciclos de promoção e decisões de reestruturação em todo o sector. O aperto pós-pandemia conta, mas a economia da IA passou a fazer parte da mesma conversa - e com peso crescente.
O alerta de Steve Yegge: um corte de 50% nas equipas de engenharia
Uma das vozes mais audíveis sobre esta mudança é Steve Yegge, engenheiro veterano que passou mais de uma década na Google, depois de anos na Amazon. Com quatro décadas na área, viu várias vagas tecnológicas remodelarem o mercado.
Ao falar no podcast e newsletter The Pragmatic Engineer, Yegge apresentou uma previsão dura: em muitas grandes empresas, afirma, poderá ser racional reduzir o número de engenheiros de software em cerca de metade.
Para Yegge, cortar aproximadamente 50% dos programadores tem menos a ver com poupar salários e mais com redireccionar orçamento para sistemas de IA que tornem a equipa restante dramaticamente mais produtiva.
Na sua leitura, a programação “à mão” perde protagonismo. Em vez disso, os engenheiros passam mais tempo a especificar tarefas, validar código gerado por IA, ligar serviços entre si e supervisionar agentes semi-autónomos capazes de produzir funções ou módulos completos em segundos.
Este desvio cria, diz ele, uma divisão clara. Quem adopta ferramentas de IA com convicção, aprende os seus limites e as usa de forma agressiva consegue multiplicar a produtividade. Quem as usa apenas como um “autocompletar sofisticado” arrisca ver o papel desvalorizado - ou eliminado.
De “escrever código” para “dirigir agentes”
A descrição do trabalho afasta-se da artesania pura do código. Yegge e outros descrevem um dia-a-dia novo: menos tempo a discutir sintaxe e mais tempo a desenhar arquitecturas, impor restrições e decidir o que a IA deve construir.
Os engenheiros tornam-se uma espécie de directores técnicos, a orquestrar múltiplos agentes de IA para tarefas como:
- Gerar código repetitivo e APIs padrão
- Escrever e actualizar testes unitários e de integração
- Produzir documentação e registos de alterações
- Executar análise estática e propor refactorizações
Os humanos continuam a arbitrar decisões, resolver casos-limite e assumir responsabilidade quando algo falha. Mas a digitação intensiva de código é cada vez mais “subcontratada” às máquinas.
Menos empregos nos gigantes, mais equipas minúsculas com alto rendimento
A vaga de despedimentos em grandes tecnológicas tem sido associada a crescimento mais lento e a correcções pós-Covid. A IA acrescenta outra camada: altera a quantidade de software que um grupo pequeno consegue entregar.
Yegge e outros comentadores antecipam um aparente paradoxo: as grandes empresas podem precisar de menos engenheiros internos, enquanto a actividade de software na economia, no seu conjunto, pode aumentar.
Quando três pessoas com boas ferramentas de IA conseguem entregar o que antes exigia trinta, a barreira para criar produtos robustos desce de forma abrupta.
Startups e empresas em fase inicial já conseguem montar sistemas multi-agente que programam, testam e documentam em paralelo. Ferramentas de orquestração permitem “operar” esses agentes como uma oficina automatizada, em que os engenheiros humanos guiam objectivos de alto nível em vez de rever cada ficheiro linha a linha.
Comentadores em programas tecnológicos como o TWiT têm apontado configurações experimentais em que um punhado de pessoas coordena dezenas de processos de IA para manter e evoluir bases de código relativamente complexas. A abordagem ainda é imperfeita, mas sugere como poderão ser organizações de software extremamente leves.
Ecos da revolução da nuvem
Há aqui um paralelismo com o início da era da cloud. Nessa altura, infraestrutura acessível permitiu que startups enxutas desafiassem incumbentes sem construir centros de dados. Hoje, a produtividade amplificada por IA permite que equipas muito pequenas ambicionem projectos que antes exigiam centenas de programadores.
Este novo equilíbrio também mexe com decisões de carreira. Alguns engenheiros estão a sair de grandes empresas por iniciativa própria, apostando que uma startup “IA-first” oferece mais autonomia e potencial de crescimento do que permanecer num gigante que corta funções enquanto investe pesado em automação.
O resultado é uma deslocação de talento do “centro” para a “periferia”: de plataformas enormes para empresas menores, mais rápidas, capazes de absorver ganhos de produtividade com IA sem camadas intermináveis de gestão.
O que acontece dentro das empresas que fazem a aposta na IA
Nos bastidores, equipas de liderança fazem contas pragmáticas. Uma versão simplificada do dilema é esta:
| Opção | Principal despesa | Resultado esperado |
|---|---|---|
| Mais engenheiros, menos GPUs | Salários, ferramentas tradicionais | Produção estável, adopção de IA mais lenta |
| Menos engenheiros, mais GPUs | Infraestrutura de IA, licenças | Mais produção por pessoa, maior dependência de automação |
Muitos grandes actores estão a inclinar-se para a segunda linha. Isso pode traduzir-se em congelar contratações, cortar vagas júnior ou reescrever descrições de funções para que um engenheiro “aumentado” por IA ocupe o lugar que antes era de duas ou três pessoas.
Os gestores estão sob pressão para demonstrar “alavancagem de IA”: provas de que o investimento em modelos e ferramentas se traduz em funcionalidades, velocidade de entrega ou redução de custos. Essa pressão tende a favorecer quem adopta rapidamente fluxos de trabalho com IA e a empurrar para segundo plano quem resiste.
Um efeito adicional, muitas vezes subestimado, é a mudança no próprio processo de governação tecnológica: com mais código a ser produzido por agentes, cresce a importância de revisões de arquitectura, políticas de segurança, regras de qualidade e auditorias. Em empresas reguladas (por exemplo, banca, saúde ou administração pública), a capacidade de demonstrar rastreabilidade e controlo pode tornar-se tão crítica quanto a velocidade de desenvolvimento.
Quem está mais em risco - e quem pode beneficiar?
As competências valorizadas estão a deslocar-se. Tarefas rotineiras, bem documentadas e altamente repetíveis são as mais fáceis de absorver por sistemas de IA. Isso inclui grandes partes de aplicações CRUD (criar, ler, actualizar e apagar), integrações padrão e estruturas de testes “de prateleira”.
Em contrapartida, funções com mais resiliência tendem a envolver conhecimento profundo do domínio, arquitecturas complexas, sistemas de alto risco ou contacto próximo com utilizadores e decisões de negócio. São mais difíceis de automatizar por dependerem tanto de julgamento, contexto e negociação como de código.
De forma geral, o impacto pode resumir-se assim:
- Mais expostos: programadores júnior focados quase só em tarefas rotineiras, manutenção de legado sem modernização, ou trabalho simples de integração.
- Em transição: engenheiros de nível intermédio que combinam construção de funcionalidades com algum desenho de sistemas e mentoria, mas ainda sem incorporar IA no fluxo diário.
- Melhor posicionados: seniores capazes de desenhar sistemas, fazer trade-offs, liderar equipas e tratar ferramentas de IA como multiplicadores - não como ameaça.
O número de 50% avançado por Yegge não é uma previsão exacta; serve sobretudo para sublinhar a direcção: empresas tenderão a preferir menos pessoas capazes de conduzir ferramentas poderosas, em vez de muitas a executar tarefas manuais semelhantes.
Conceitos-chave por trás desta mudança
Várias ideias técnicas explicam a ruptura. Algumas que vale a pena destrinçar:
Assistentes de programação com IA
Estas ferramentas integram-se em editores e IDEs para sugerirem linhas, blocos ou funções inteiras com base no contexto. Brilham em padrões repetidos muitas vezes, o que as torna fortes em código repetitivo, testes e refactorizações simples.
Sistemas multi-agente
Em vez de um único modelo responder a prompts, configurações multi-agente coordenam vários agentes especializados. Um escreve código, outro executa testes, outro propõe correcções. Um engenheiro humano distribui tarefas e supervisiona o ciclo, actuando como gestor de produção.
Amplificação de produtividade
O que assusta e entusiasma observadores como Yegge não é a ideia de a IA substituir todos os programadores, mas sim tornar cada um dos restantes várias vezes mais produtivo. Quando essa amplificação ultrapassa um certo limiar, os modelos de dimensionamento das equipas mudam.
Um ponto novo que se impõe aqui é a medição: à medida que a IA entra no processo, as empresas tentam quantificar ganhos com métricas (tempo de ciclo, defeitos em produção, custo por funcionalidade). Se essas métricas forem mal escolhidas, podem incentivar velocidade sem qualidade - aumentando dívida técnica e risco de segurança.
Cenários práticos: como pode ser uma equipa no futuro
Imagine uma equipa de back-end para um novo produto fintech daqui a cinco anos. Em vez de 25 engenheiros, a empresa contrata sete. Trabalham lado a lado com uma plataforma interna de agentes de IA que trata de geração de código, testes de regressão, actualizações de documentação e parte do scanning de segurança.
Dois engenheiros seniores concentram-se em arquitectura e conformidade, revendo com frequência a saída da IA em áreas sensíveis, como fluxos de pagamentos. Três engenheiros de nível intermédio são donos de serviços específicos: escrevem prompts, validam diffs e lidam com incidentes. Dois programadores júnior rodam por operações e trabalho orientado ao cliente, aprendendo o negócio enquanto, com apoio de IA, assumem gradualmente mais responsabilidades técnicas.
O volume total de funcionalidades entregues rivaliza com o que uma equipa muito maior produzia há uma década. Os empregos “em falta” não foram transferidos para outra área dentro da empresa; simplesmente deixam de existir ali como funções humanas.
Riscos, pontos cegos e efeitos de segunda ordem
Esta trajectória levanta riscos relevantes. Uma dependência forte de código escrito por IA pode esconder bugs subtis ou falhas de segurança que só aparecem muito depois de entrar em produção. As equipas podem ter dificuldade em manter sistemas cuja lógica original fica, em parte, “presa” em históricos de prompts e pesos do modelo, em vez de na memória humana e em decisões bem documentadas.
Existe ainda um problema de formação. Se o trabalho de programação de entrada for automatizado, onde ganham experiência os futuros seniores? As empresas poderão precisar de novos modelos de aprendizagem: estágios estruturados, projectos simulados e ambientes controlados onde juniores aprendam a fazer engenharia - incluindo revisão crítica e validação - sem colocar produção em risco.
Por outro lado, a redução do custo de produção de software pode libertar uma vaga de experimentação. Ferramentas de nicho, aplicações hiper-locais e sistemas internos personalizados tornam-se viáveis onde antes pareciam economicamente injustificáveis. Isso pode criar trabalho novo em design, gestão de produto, revisão de segurança e coordenação humano–IA, mesmo que os papéis clássicos de programador encolham.
A mensagem de veteranos como Yegge não é que as carreiras em software acabaram, mas que estão a ser rapidamente reconfiguradas em torno da IA - muito mais depressa do que muita gente esperava.
Para cada programador, isto implica tratar a IA menos como ameaça e mais como parte central do ofício: conhecer limites, criar hábitos de verificação e aprender a transformar uma ideia ainda vaga numa instrução concreta, bem delimitada, que as máquinas consigam executar com segurança.
Comentários
Ainda não há comentários. Seja o primeiro!
Deixar um comentário