À medida que a tecnologia acelera para industrializar a inteligência artificial, um tipo de vaga que antes parecia sólida passa, de repente, a parecer bem menos certa do que já foi.
Do Vale do Silício a outros polos, engenheiros seniores já dizem abertamente aquilo que muita gente comentava só nos bastidores: as ferramentas de IA estão mudando o trabalho em software em um ritmo tão alto que as empresas estão, de fato, simulando quantos programadores humanos ainda precisam manter.
A nova troca nas big techs: GPUs ou desenvolvedores?
Nos últimos dois anos, a lógica de custos das grandes empresas de tecnologia foi reconfigurada. O que mais pesa, cada vez mais, é computação - não o tamanho do quadro de pessoas. Treinar e operar modelos grandes de IA exige enormes conjuntos de GPUs, centros de dados especializados e licenças caras para modelos de ponta.
E cada funcionalidade com IA colocada no ar para milhões de usuários tende a provocar um salto no gasto com nuvem e com equipamentos. Times de finanças estão vendo orçamentos em que infraestrutura e acesso a modelos passam a ocupar uma fatia crescente.
Em paralelo, assistentes de programação com IA e ferramentas de testes automatizados aumentaram a entrega individual. Um único desenvolvedor, com a combinação certa de auxiliares de IA, já consegue executar tarefas que antes pediam uma equipe pequena.
"Para muitos líderes de tecnologia, a pergunta desconfortável deixou de ser 'a IA aumenta a produtividade?' e virou 'quantas pessoas ainda precisamos se ela aumentar?'."
Diante da escalada do custo de infraestrutura de IA, parte dos executivos está optando por uma troca direta: manter menos engenheiros, dar a cada um ferramentas muito mais poderosas e direcionar a economia para GPUs, modelos e automação.
Essa conta já começa a aparecer em planos de contratação, ciclos de promoção e decisões de reestruturação em boa parte do setor. O aperto após a pandemia influencia, mas a economia da IA entrou de vez na discussão.
O alerta de Steve Yegge: um corte de 50% no time de engenharia
Um dos nomes mais explícitos ao falar sobre essa virada é Steve Yegge, engenheiro veterano que passou mais de uma década no Google após anos na Amazon. Com quatro décadas em software, ele já viu várias ondas tecnológicas reordenarem a indústria.
Em participação no podcast e no boletim “O Engenheiro Pragmático”, Yegge apresentou uma previsão dura: segundo ele, muitas empresas grandes concluirão que faz sentido reduzir o quadro de engenharia para algo em torno da metade.
"Yegge argumenta que cortar cerca de 50% dos desenvolvedores tem menos a ver com economizar em salários e mais com redirecionar dinheiro para sistemas de IA que tornam o time restante dramaticamente mais produtivo."
Na leitura dele, o código escrito à mão perde protagonismo. Em vez disso, engenheiros passam a gastar mais tempo especificando tarefas, revisando código gerado por IA, conectando serviços entre si e supervisionando agentes semi-autônomos capazes de produzir funções ou módulos completos em segundos.
Esse movimento, ele diz, tende a abrir uma divisão nítida. Quem abraça as ferramentas de IA, entende suas limitações e as usa de forma intensa pode multiplicar a própria entrega. Já quem trata essas soluções apenas como um “autocompletar sofisticado” corre o risco de ter a função rebaixada - ou simplesmente deixar de existir.
De “escrever código” para “dirigir agentes”
A descrição do trabalho vai se afastando da artesania do código puro. Yegge e outros relatam uma rotina diferente: menos tempo preso à sintaxe e mais tempo definindo arquiteturas, estabelecendo restrições e escolhendo o que a IA deve construir.
Na prática, o engenheiro vira uma espécie de diretor técnico, coordenando vários agentes de IA em atividades como:
- Gerar código padrão e APIs comuns
- Escrever e atualizar testes unitários e de integração
- Produzir documentação e registros de mudanças
- Executar análise estática e sugerir refatorações
As pessoas continuam como árbitro das decisões, lidam com casos-limite difíceis e assumem a responsabilidade quando algo dá errado. Mas a digitação do código bruto é, cada vez mais, transferida para as máquinas.
Menos vagas nos gigantes, mais equipes minúsculas e muito produtivas
A sequência de demissões em grandes empresas de tecnologia tem sido associada, com frequência, a crescimento mais lento e ajustes pós-Covid. A IA acrescenta outra camada ao debate ao alterar quanto software um grupo pequeno consegue entregar.
Yegge e outros analistas apontam um paradoxo possível: as gigantes podem precisar de menos engenheiros internos, ao mesmo tempo em que a atividade de software no restante da economia pode crescer.
"Quando três pessoas com ferramentas de IA fortes conseguem entregar tanto código quanto trinta entregavam antes, a barreira para criar produtos robustos cai drasticamente."
Empresas pequenas e startups em fase inicial já conseguem montar sistemas de IA com múltiplos agentes que programam, testam e documentam em paralelo. Ferramentas de orquestração permitem operar esses agentes como uma oficina automatizada, em que engenheiros humanos orientam objetivos de alto nível em vez de revisar arquivo por arquivo.
Comentaristas em programas de tecnologia como a TWIT têm destacado configurações experimentais em que poucas pessoas coordenam dezenas de processos de IA para manter e evoluir bases de código relativamente complexas. O modelo ainda é imperfeito, mas sugere como podem funcionar organizações de software mais enxutas.
Ecos da revolução da nuvem
Há semelhanças com o início da era da nuvem. Naquele período, infraestrutura mais acessível permitiu que startups enxutas desafiassem incumbentes sem construir centros de dados gigantescos. Agora, a produtividade impulsionada por IA permite que times minúsculos persigam metas que antes exigiam centenas de desenvolvedores.
Esse novo equilíbrio afeta escolhas de carreira. Alguns engenheiros estão saindo de grandes corporações por conta própria, apostando que uma startup “IA em primeiro lugar” oferece mais autonomia e potencial de retorno do que permanecer em uma gigante que corta funções enquanto investe pesado em automação.
O resultado é um movimento de talentos saindo do “centro” para a “borda”: de plataformas enormes para empresas menores e mais rápidas, que conseguem absorver ganhos de produtividade com IA sem criar camadas infinitas de gestão.
O que acontece dentro de empresas que apostam na IA
Nos bastidores, lideranças fazem contas pragmáticas. Uma versão simplificada fica assim:
| Opção | Principal gasto | Resultado esperado |
|---|---|---|
| Mais engenheiros, menos GPUs | Salários, ferramentas tradicionais | Entrega estável, adoção de IA mais lenta |
| Menos engenheiros, mais GPUs | Infraestrutura de IA, licenças | Mais entrega por pessoa, dependência de automação |
Muitos grandes nomes estão se deslocando para a segunda linha. Isso pode significar congelar contratações, eliminar vagas júnior ou reformular descrições de cargo para que um engenheiro com IA ocupe um lugar que antes era de duas ou três pessoas.
Gestores também enfrentam pressão para demonstrar “alavancagem de IA”: evidências de que o investimento em modelos e ferramentas está virando funcionalidades, velocidade ou economia. Essa pressão favorece quem incorpora fluxos de trabalho com IA rapidamente e tende a deixar de lado quem não adere.
Quem corre mais risco e quem pode ganhar com isso?
As competências valorizadas estão mudando. Atividades rotineiras, bem documentadas e altamente repetíveis são as mais fáceis para sistemas de IA assumirem. Aí entram grandes partes de aplicativos CRUD básicos, código padrão de integração e estruturas comuns de testes.
Funções mais resistentes, por outro lado, costumam envolver conhecimento profundo do domínio, arquiteturas complexas, sistemas de alto risco ou contato próximo com usuários e com decisões de negócio. Tudo isso é mais difícil de automatizar por completo porque depende tanto de julgamento, contexto e negociação quanto de código.
Em linhas gerais, o efeito pode ser descrito assim:
- Mais expostos: desenvolvedores júnior focados quase só em tarefas rotineiras, manutenção de legado sem modernização ou integrações simples.
- Em transição: engenheiros de nível intermediário que alternam construção de funcionalidades com desenho de sistemas e mentoria, mas ainda não incorporaram IA de forma consistente no dia a dia.
- Melhor posicionados: engenheiros seniores que desenham sistemas, fazem escolhas e compromissos, lideram times e usam ferramentas de IA como multiplicadores - e não como ameaça.
O número de 50% citado por Yegge não é uma projeção exata, mas reforça uma direção: empresas tendem a preferir menos pessoas capazes de conduzir ferramentas muito poderosas, em vez de muitas pessoas executando tarefas manuais semelhantes.
Conceitos-chave por trás da mudança
Algumas ideias técnicas sustentam essa ruptura. Vale detalhar algumas:
Assistentes de código com IA
Essas ferramentas se integram a editores e IDEs para sugerir linhas, blocos ou funções inteiras com base no contexto. Elas se saem muito bem em padrões vistos repetidamente, o que as torna fortes em código padrão, testes e refatorações diretas.
Sistemas com múltiplos agentes
Em vez de um único modelo respondendo instruções, configurações multiagentes coordenam diversos agentes especializados. Um pode escrever código, outro executar testes, outro sugerir correções. Um engenheiro humano distribui tarefas e supervisiona o ciclo, atuando na prática como um gerente de produção.
Amplificação de produtividade
O que assusta e empolga observadores como Yegge não é a ideia de que a IA substitui todo desenvolvedor, e sim a possibilidade de tornar cada pessoa remanescente várias vezes mais produtiva. Quando essa amplificação passa de certo ponto, os modelos de equipe mudam.
Cenários práticos: como pode ser um time no futuro
Imagine uma equipe de servidor para um novo produto de fintech daqui a cinco anos. Em vez de 25 engenheiros, a empresa contrata sete. Eles trabalham ao lado de uma plataforma interna de agentes de IA que cuida de geração de código, testes de regressão, atualização de documentação e parte da varredura de segurança.
Dois engenheiros seniores ficam focados em arquitetura e conformidade, revisando com frequência o que a IA produz em áreas sensíveis, como fluxos de pagamento. Três engenheiros de nível intermediário assumem serviços específicos, escrevem instruções, conferem diferenças nas alterações e lidam com incidentes. Dois desenvolvedores júnior se revezam entre operações e trabalho voltado ao cliente, aprendendo o negócio e, aos poucos, assumindo mais responsabilidade técnica com apoio da IA.
O volume total de funcionalidades entregues compete com o que uma equipe bem maior produzia uma década antes. As vagas que “sumiram” não migraram para outro setor dentro da empresa; elas simplesmente deixaram de existir ali como funções humanas.
Riscos, pontos cegos e efeitos de segunda ordem
Esse caminho traz riscos claros. Dependência grande de código escrito por IA pode esconder falhas sutis ou vulnerabilidades de segurança que só aparecem muito depois do lançamento. E as equipes podem ter dificuldade para manter sistemas cuja lógica original fica mais nos históricos de instruções e nos pesos do modelo do que na memória do time.
Há ainda um buraco na formação. Se o trabalho de codificação de entrada for automatizado, onde futuros engenheiros seniores ganham experiência no começo da carreira? As empresas talvez precisem criar novos formatos de aprendizado, projetos simulados ou ambientes mais seguros em que juniores ainda consigam aprender fazendo.
Por outro lado, produzir software mais barato pode destravar uma onda de experimentação. Ferramentas de nicho, aplicativos hiperlocais e sistemas internos sob medida podem se tornar viáveis onde antes pareciam caros demais. Isso pode gerar trabalho novo em design, gestão de produto, revisão de segurança e coordenação entre humanos e IA, mesmo com a redução de papéis clássicos de desenvolvimento.
"A mensagem de veteranos como Yegge não é que as carreiras em software acabaram, mas que elas estão sendo rapidamente reconfiguradas em torno da IA - muito mais rápido do que muita gente esperava."
Para desenvolvedores individualmente, isso implica tratar a IA menos como ameaça e mais como parte central do ofício: conhecer seus limites, criar hábitos de verificação e aprender a transformar uma ideia ainda bruta em uma instrução concreta, clara e bem delimitada - algo que as máquinas consigam executar.
Comentários
Ainda não há comentários. Seja o primeiro!
Deixar um comentário