The AI Multiplier Effect: How LLMs Are Quietly Reshaping Software Teams

O Que Está Realmente a Acontecer

Uso ferramentas de IA de programação como parte central do meu fluxo de trabalho diário há mais de um ano. Trabalho em toda a stack: backends Node.js, frontends React, firmware embebido em C. E depois de tempo suficiente, alguns padrões tornaram-se claros o suficiente para escrever sobre eles honestamente.

A narrativa dos media oscila entre dois extremos: a IA vai substituir todos os programadores em poucos anos, ou é apenas autocomplete caro que engenheiros seniores não precisam realmente. Na minha opinião ambos estão errados. O enquadramento mais preciso: a IA é um multiplicador de força, e os multiplicadores de força alteram o tamanho e a composição ideais das equipas.

A Matemática da Produtividade

Antes das ferramentas de IA, conseguia confortavelmente 2 a 3 funcionalidades significativas por sprint. Agora esse número está mais perto de 4 ou 5, sem queda correspondente na qualidade.

Onde a IA ajuda concretamente:

• Geração de boilerplate. Um novo endpoint REST com validação, tratamento de erros e testes costumava levar 30–45 minutos. Agora são 5 minutos de prompts e 15 minutos de revisão e ajustes.
• APIs desconhecidas. Em vez de 20 minutos na documentação, tenho um exemplo funcional em 2 minutos que verifico e ajusto.
• Explicar código legado. "O que faz esta função e quais são os seus casos extremos?" numa base de código que não escrevi é muito mais rápido com IA do que tracejando manualmente.

Onde a IA não ajuda ou engana ativamente:

• Decisões arquiteturais. A IA gera confientemente código para a arquitetura errada. Não conhece as tuas restrições, a base de código existente, os requisitos de negócio, o ambiente de produção.
• Correção específica do domínio. Em software fiscal tens de ser exato nas regras. A IA pode dar código que parece correto mas está subtilmente errado num caso extremo de cálculo de imposto.

O Que Está a Acontecer às Equipas

Trabalho numa equipa que não cresceu em headcount durante cerca de dois anos. O throughput de projetos nesse mesmo período praticamente duplicou. Não precisámos de contratar para substituir programadores que saíram, porque os que ficaram, todos usando ferramentas de IA diariamente, absorveram a capacidade em falta.

Esta não é uma observação confortável de fazer publicamente, mas é o que estou a ver. E acredito que é mais generalizado do que as pessoas admitem abertamente.

Um programador sénior com 8 anos de conhecimento do domínio e bom julgamento arquitetural, usando ferramentas de IA eficazmente, pode agora produzir o output que antes requeria 2 ou 3 programadores. Um júnior usando as mesmas ferramentas, sem a camada de julgamento, produz código mais rápido, mas a qualidade do código é mais difícil de avaliar sem revisão.

O Paradoxo da Expertise

A expertise sénior está a tornar-se mais valiosa, não menos, porque é a camada que valida o output da IA. Mas o caminho tradicional para a expertise sénior era ser júnior primeiro, fazer o trabalho de baixo nível, cometer erros em contextos de menor risco.

Se a IA absorve a maior parte do trabalho júnior, como será o pipeline para expertise sénior daqui a 5 anos? Estou a observar programadores júnior que usam a IA como muleta, aceitando o seu output sem o compreender, e preocupo-me com as suas bases daqui a três anos.

A Questão de "Reinventar a Roda"

A minha regra geral evoluiu para algo como: se a IA consegue gerar algo corretamente em menos de 30 segundos, provavelmente não valia a pena escrever do zero. Usa o output da IA, verifica-o, segue em frente.

Mas há um corolário igualmente importante: o julgamento sobre qual padrão usar, e se o problema precisa sequer desse padrão, ainda requer um programador que compreenda profundamente o domínio. Uma vez pedi à IA para implementar "algo rápido para ordenar estes dados." Deu-me um bubble sort perfeitamente implementado. O código era impecável. A escolha do algoritmo estava errada por 3 ordens de magnitude para o tamanho real dos dados.

O Equilíbrio

O equilíbrio para o qual nos movemos parece algo assim: equipas mais pequenas e mais experientes, cada membro a produzir output que antes requeria uma equipa maior, com a IA a tratar a camada de execução de tarefas bem definidas e os humanos a tratar a camada de julgamento das mal definidas.

Os programadores que prosperam neste ambiente são os genuinamente curiosos sobre como as coisas funcionam, que reveem o output da IA criticamente em vez de o aceitar passivamente, e que investem em conhecimento profundo do domínio que a IA não consegue facilmente replicar.