IA não torna um time produtivo

Marcelo Scheidt
Marcelo Scheidt
Autor verificado Autor verificado
24 agosto

Depois de escrever sobre cloud, microserviços e a ilusão de escala, um padrão ficou difícil de ignorar: toda vez que uma tecnologia nova aparece, ela é tratada como se fosse a resposta. Com a IA, a história se repete. Só que mais rápido, e com muito mais dinheiro em jogo.

E surge a pergunta que quase ninguém faz antes de adotar: como vamos saber se a IA está realmente nos tornando mais produtivos?

A resposta é menos confortável do que parece.

A sensação de velocidade não é velocidade

Um estudo controlado da METR acompanhou desenvolvedores experientes resolvendo tarefas nos próprios repositórios. Metade das tarefas com IA, metade sem. O resultado foi o oposto do esperado: com IA, eles foram 19% mais lentos (fonte completa aqui).

O detalhe que importa não é esse. É o seguinte: os próprios desenvolvedores achavam que tinham sido 20% mais rápidos.

Não é um erro pequeno de medição, mas um abismo entre o que sentimos e o que aconteceu.

Isso deveria incomodar qualquer um que pretende medir o impacto da IA perguntando às pessoas se a IA as ajudou. A percepção de produtividade é uma das medidas menos confiáveis que existem. E é justamente a que a maioria das empresas está usando.

Produzir mais não é entregar mais

A IA é excelente em gerar. Mais código, mais pull requests, mais commits. E é exatamente aí que mora a armadilha.

Um time pode dobrar a quantidade de código e não entregar nada de novo para o cliente. Pode abrir o triplo de PRs e travar o próprio processo de review. Pode escrever mais rápido e produzir mais retrabalho depois.

Velocidade de digitação nunca foi o gargalo da engenharia. O gargalo é decidir o que construir, entender o domínio, revisar, integrar e sustentar. A IA acelera principalmente a parte que já era rápida.

É o mesmo erro da ilusão de escala, com outra roupa: confundir movimento com progresso.

A IA é um espelho

As pesquisas mais recentes do setor apontam todas para a mesma direção. A IA não nivela os times. Ela amplia a distância entre eles.

Times maduros, com fluxo de entrega claro, testes automatizados, review consistente, ownership definido, adotam IA e ficam melhores. Times imaturos adotam a mesma IA e ficam mais rápidos em produzir bagunça. A instabilidade que já existia passa a aparecer antes, e maior.

A IA não corrige a desorganização de um time. Assim como a cloud não corrigia. Assim como os microserviços não corrigiam.

Ela só torna mais visível (e mais cara) uma imaturidade que já estava lá.

O que medir, então

Se a IA amplifica aquilo que o time já é, a pergunta certa deixa de ser “quanto a IA nos acelerou”. Passa a ser: o time está entregando o que foi combinado, no prazo, com qualidade?

Isso não mudou com a IA. Nunca mudou.

Numa consultoria, produtividade não é quantidade de código. É previsibilidade: entregar o escopo contratado no tempo previsto. É qualidade: o que foi entregue não volta como retrabalho. É consistência: conseguir repetir isso projeto após projeto, cliente após cliente.

A IA entra como uma variável dentro dessa conta. Não como a conta inteira. Você não mede a IA. Você mede a entrega, e observa o que a IA faz com ela.

O risco não é a IA não funcionar. É ela funcionar rápido demais num time que ainda não sabe para onde está indo.

Porque quando isso acontece, a IA não amplia o acerto. Ela amplia o erro.

Publicado em: Artigos
Marcelo Scheidt
Marcelo Scheidt
Autor verificadoAutor verificado

Senior Principal Engineer na Zallpy, Engenheiro de software com mais de 15 anos de experiência em engenharia de sistemas, arquitetura e infraestrutura, atuando na definição de visão técnica e estratégias arquiteturais para soluções complexas e de larga escala. Atualmente é Senior Principal Engineer na Zallpy, onde lidera a evolução arquitetural de múltiplos domínios, apoia executivos na tomada de decisão técnica, conduz análises de maturidade e risco, e desenvolve liderança técnica por meio de mentoria a engenheiros seniores, sempre conectando arquiteturas cloud-native, práticas modernas de DevOps e excelência em engenharia aos objetivos de negócio.

Senior Principal Engineer na Zallpy, Engenheiro de software com mais de 15 anos de experiência em engenharia de sistemas, arquitetura e infraestrutura, atuando na definição de visão técnica e estratégias arquiteturais para soluções complexas e de larga escala. Atualmente é Senior Principal Engineer na Zallpy, onde lidera a evolução arquitetural de múltiplos domínios, apoia executivos na tomada de decisão técnica, conduz análises de maturidade e risco, e desenvolve liderança técnica por meio de mentoria a engenheiros seniores, sempre conectando arquiteturas cloud-native, práticas modernas de DevOps e excelência em engenharia aos objetivos de negócio.