Saltar para o conteúdo
SwankyForge
SwankyForge
Todos os artigos
Artigo10 min de leitura

A IA tornou mais barato escrever código. Não tornou, por si só, os projetos de software mais baratos.

Medições controladas mostram ganhos de velocidade modestos ou negativos com ferramentas de programação com IA, e escrever código é uma parte minoritária do tempo de um projeto, por isso um desconto honesto por IA é pequeno e pode ser localizado fase a fase.

Em julho de 2025, a organização de investigação sem fins lucrativos METR publicou um ensaio aleatorizado sobre ferramentas de programação com IA em trabalho real. Dezasseis programadores open-source experientes concluíram 246 tarefas nos seus próprios repositórios, e cada tarefa foi atribuída aleatoriamente a «IA permitida» ou «IA não permitida». Com IA, as tarefas demoraram mais 19%. Antes do estudo, os mesmos programadores esperavam que a IA os tornasse 24% mais rápidos. Depois, continuavam a acreditar que tinham sido cerca de 20% mais rápidos.

Essa diferença entre a velocidade sentida e a velocidade medida é a parte útil para quem compra software. Os fornecedores anunciam agora entregas aceleradas por IA e incluem-nas no preço. Parte da poupança é real. A maior parte da promessa diz respeito à escrita de código, aplicada a um orçamento que, na sua maioria, não é escrita de código.

Esta nota cobre o que dizem os dados de 2025, para onde vão as horas num projeto de machine learning e o que perguntar a um fornecedor que lhe apresente um desconto por IA.

O que dizem os dados de 2025

Quatro fontes, quatro métodos. Nenhuma sustenta a ideia de que um projeto custa metade porque o código foi escrito com um assistente.

Fonte Método Resultado
METR, julho de 2025 Ensaio aleatorizado: 16 programadores, 246 tarefas, repositórios com uma média de 22k+ estrelas e 1M+ linhas de código 19% mais lentos com IA; os programadores acreditavam ser cerca de 20% mais rápidos
Stack Overflow Developer Survey, julho de 2025 Inquérito, 26k–34k respostas por pergunta 84% usam ou planeiam usar ferramentas de IA; 46% desconfiam da sua exatidão, 33% confiam; 66% apontam «quase certo, mas não totalmente» como a principal frustração
Relatório DORA da Google, setembro de 2025 Inquérito a quase 5.000 profissionais de tecnologia 90% usam IA no trabalho; a adoção de IA está associada a maior débito de entrega e, ainda assim, a menor estabilidade de entrega
Bain Technology Report, setembro de 2025 Estudo setorial Equipas com assistentes registam ganhos de produtividade de 10–15%; escrever e testar código ocupa 25–35% do tempo entre a ideia e o lançamento

O resultado do METR tem limites que os próprios autores indicam com clareza: uma amostra pequena, programadores experientes em bases de código grandes que já conheciam, e ferramentas do início de 2025 (Cursor Pro com Claude 3.5 e 3.7 Sonnet). Não mostra que a IA torna toda a gente mais lenta. Mostra duas coisas mais restritas. Ganhos de velocidade autodeclarados não são evidência. E, em código maduro e complexo, o tempo gasto a escrever prompts, esperar, rever e corrigir pode anular o tempo poupado na escrita.

Os inquéritos apontam no mesmo sentido, por outro ângulo. O uso é rotineiro: 51% dos programadores profissionais no inquérito do Stack Overflow usam ferramentas de IA diariamente, e os inquiridos do DORA passam com elas uma mediana de duas horas por dia. A confiança não é: 45% dos inquiridos do Stack Overflow dizem que depurar código gerado por IA demora mais tempo, e 30% dos inquiridos do DORA declaram pouca ou nenhuma confiança no código gerado por IA. A síntese do DORA é que a IA amplifica aquilo que a equipa já é. Equipas fortes ficam mais rápidas. Equipas com testes fracos e feedback lento lançam mais alterações e partem mais delas.

Porque é que escrever código mais barato não significa um projeto mais barato

Os dois números da Bain chegam para ver o teto. Se escrever e testar código ocupa 30% do tempo entre a ideia e o lançamento, e um assistente torna essa parte 30% mais rápida, o projeto inteiro fica 9% mais rápido: 0,30 × 0,30 = 0,09. Mesmo que o código passasse a ser gratuito e instantâneo, os outros 65–75% do trabalho continuariam lá. Os engenheiros conhecem isto como a lei de Amdahl: acelerar uma etapa de um pipeline está limitado pela fração de tempo que essa etapa ocupa.

O resto de um projeto é especificação, trabalho com dados, integração, revisão, testes, avaliação, implementação e operação. Cada um tem a sua razão para não encolher ao mesmo ritmo.

  • A especificação é uma conversa com as pessoas responsáveis pelo problema. Um assistente pode redigir o documento. Não pode decidir que a métrica é a margem e não a receita.
  • O trabalho com dados consiste sobretudo em descobrir o que significa uma coluna, quem é o dono da tabela e porque é que algumas linhas estão duplicadas. Escrever o SQL nunca foi a parte lenta.
  • A integração consome tempo com a API de outra equipa, credenciais, limites de pedidos e janelas de lançamento.
  • A revisão fica mais pesada. Mais código gerado por dia significa mais código para ler por dia, e o código quase certo é o mais caro de rever, porque parece acabado.
  • A avaliação e a operação seguem o calendário. Espera-se uma semana de tráfego, um fecho de mês ou que um grupo de controlo acumule dados suficientes.

A conclusão do DORA sobre estabilidade é a versão medida do ponto sobre a revisão. As equipas lançam mais alterações e, sem testes automáticos sólidos e ciclos de feedback rápidos, mais dessas alterações falham.

Para onde vão as horas num projeto de ML

A tabela abaixo é ilustrativa. É a nossa divisão aproximada para um projeto de machine learning de dimensão média, como um sistema de recomendação ou de previsão ligado a um produto existente, juntamente com os nossos pressupostos sobre quanto a assistência de IA poupa em cada fase. As percentagens são opiniões de planeamento, não medições. Substitua-as pelas suas e refaça a conta.

Fase Fração das horas Horas de 600 Poupança assumida com IA Horas poupadas
Descoberta: métrica, baseline, especificação 10% 60 0% 0
Acesso a dados, limpeza, pipelines de features 25% 150 15% 22,5
Modelação e experiências 15% 90 20% 18
Integração com os seus sistemas 15% 90 20% 18
Testes, avaliação, revisão de código 15% 90 0% 0
Implementação, monitorização, rollback 10% 60 10% 6
Demonstrações, aceitação, passagem de testemunho 10% 60 0% 0
Total 100% 600 64,5, cerca de 11%

O raciocínio por trás de cada linha:

  • A descoberta não ganha nada, porque o seu resultado são decisões, e as decisões vêm do negócio.
  • O trabalho com dados ganha uma poupança modesta. Os assistentes escrevem depressa consultas, parsers e verificações de validação, mas a maior parte das horas vai para esperar por acessos e compreender os dados.
  • A modelação e a integração têm a maior poupança, porque contêm mais código de padrão: ciclos de treino, clientes de API, serialização, configuração.
  • Testes e revisão dão um saldo nulo. Os assistentes escrevem depressa a estrutura dos testes, e o código gerado a mais acrescenta tempo de revisão. Equipas com boas suites de testes podem ganhar aqui; equipas sem elas podem perder.
  • A implementação poupa um pouco nos modelos de configuração. Esperar que um canary release recolha tráfego não fica mais curto.

À nossa tarifa publicada de engenheiro de ML, 50 € por hora, 600 horas são 30.000 € e 64,5 horas são cerca de 3.200 €. É essa a ordem de grandeza de um desconto honesto por IA num projeto com este perfil: real, vale a pena tê-lo, e muito longe de metade. Também calha dentro do intervalo de 10–15% da Bain, o que é uma verificação de plausibilidade e não uma prova.

O outro número da Bain é o mais interessante. As empresas que redesenharam todo o processo em torno da IA, em vez de apenas distribuírem assistentes, reportaram ganhos de 25–30%. Essa poupança vem de mudar o que acontece entre as linhas de código: como se escrevem as especificações, como funciona a revisão, como se testam os lançamentos. É uma mudança de processo, e custa esforço antes de compensar. A Bain nota também que três em cada quatro empresas dizem que levar as pessoas a mudar a forma como trabalham é a parte mais difícil.

Como mudou o trabalho do programador

O trabalho passou da escrita para a especificação e a verificação. Um programador com um assistente gasta menos tempo na primeira versão e mais tempo em três coisas.

  1. Instruções precisas. O assistente faz o que a especificação diz, por isso uma especificação vaga produz agora, mais depressa, código plausível e errado.
  2. Ler e corrigir o resultado. É aqui que vive a frustração do «quase certo». Código errado que falha de forma ruidosa é barato. Código que passa no teste óbvio e falha no caso-limite é caro.
  3. As verificações que tornam a velocidade segura. Testes, conjuntos de avaliação, verificação de tipos, lançamentos faseados.

No trabalho de machine learning, o terceiro ponto é o que mais pesa. Uma alteração ao modelo que parece correta num notebook pode baixar uma métrica de negócio em produção. Um assistente pode escrever o harness de avaliação. Não pode decidir o que o conjunto de avaliação deve conter, nem quanto custa ao negócio uma regressão.

Onde aparecem as poupanças

A nossa visão, que é uma opinião e não uma medição: os assistentes reduzem tempo real em

  • protótipos e análises descartáveis, onde quase certo chega para aprender alguma coisa;
  • código com um padrão claro: clientes de API, classes de dados, configuração, migrações de esquema;
  • bibliotecas pouco conhecidas, onde o assistente substitui uma hora de leitura de documentação;
  • primeiras versões de testes e documentação, que depois uma pessoa corrige.

Poupam pouco em decisões, esperas, coordenação e revisão. Um desconto por IA credível deve ser coerente com essa divisão.

O que perguntar a um fornecedor que promete um desconto por IA

  • Onde exatamente é que a IA cortou horas? Peça a estimativa por fase, com e sem assistência. Um desconto que não pode ser localizado numa fase é um desconto comercial. Não há problema nisso, mas deve ter esse nome.
  • Quem revê o código escrito pela IA, e como? Pergunte se uma pessoa revê cada alteração, o que verifica e se o tempo de revisão está na estimativa.
  • Como se mede a qualidade? Testes nos caminhos críticos, um conjunto de avaliação para o comportamento do modelo, uma taxa de falha de alterações. Se a resposta for que o código funciona, pergunte como é que o sabem.
  • O que acontece quando o código gerado está errado em produção? Monitorização, rollback e um responsável de piquete fazem parte do plano, não de um pedido de alteração posterior.
  • Onde fica o repositório? Se o código estiver na conta do fornecedor até à fatura final, não consegue verificar nada do que está acima enquanto ainda importa.

Como tratamos isto

A nossa tabela de tarifas está publicada por função e por hora, por isso qualquer estimativa que damos pode ser verificada como horas vezes tarifa, fase a fase. Vê uma demonstração funcional todas as semanas, o repositório fica na sua organização desde o primeiro dia e cada marco só é faturado depois de o aceitar. Os intervalos típicos de projeto estão publicados ao lado da tabela de tarifas, e um teardown orça separadamente a descoberta, a prova de conceito e a produção. Se a assistência de IA torna uma fase mais rápida, isso aparece como menos horas na fatura, não como uma promessa na proposta.

Fontes

Tem um processo que custa demasiado?

Fale-nos dele. A primeira chamada é gratuita e, se a IA não for a resposta, dizemo-lo.

Falar sobre a sua tarefa