Face ao aumento das despesas com IA, a resposta mais comum consiste em limitar o uso: tetos de consumo, número de licenças e validações antes do lançamento de agentes. Contudo, estas restrições indiferenciadas podem travar utilizações úteis e medir o indicador errado, segundo a análise.
- Limitar o uso com tetos e licenças pode travar utilizações úteis.
- O custo por token mede o consumo, não os resultados entregues.
- Medir o custo por pedido de fusão aceite revela o valor real do software entregue, desde que a qualidade seja acompanhada.
- Reservar modelos caros para tarefas complexas e usar modelos de pesos abertos para tarefas simples reduz os custos.
O custo por token (unidade de texto processada por um modelo de linguagem) mede o consumo, não os resultados. Uma parte das despesas corresponde a desperdício, como repetições de pedidos ou ciclos descontrolados, enquanto outra representa o trabalho real de entrega de software. Um contador não permite distingui-las, tal como um teto de despesas.
Medir o software entregue
Um indicador mais pertinente seria o custo por pedido de fusão aceite, ou seja, o custo total do desenvolvimento assistido por IA dividido pelo número de alterações que passam a revisão e são integradas no código, chamadas « pull requests » na gíria. É necessário acompanhar em paralelo os retoques e os defeitos, para que alterações mais baratas não mascarem uma queda de qualidade.
Se este custo baixar enquanto o uso aumenta, sem degradação da qualidade, os desenvolvedores transformam mais consumo em software útil. A questão não é, portanto, o número de tokens utilizados, mas a quantidade de trabalho concluído que o investimento produz. Para melhorar este equilíbrio, são avançados dois alavancagens: reservar a inferência dispendiosa para as tarefas que dela precisam, e reduzir o custo do trabalho corrente.
Adaptar o modelo à tarefa
O desenvolvimento agentico, no qual um agente escreve e modifica código de forma autónoma, não exige o modelo mais poderoso em cada etapa. Um modelo de ponta, ou um modelo de referência alojado no local quando a política da empresa o impõe, pode ser reservado para o planeamento complexo e o raciocínio inédito. As tarefas mais simples, como a geração de código, a criação de testes ou as refatorações repetidas, podem ser confiadas a modelos de pesos abertos (« open-weight »), explorados diretamente pela empresa.
Uma passagem, ou « gateway », pode orientar cada pedido de acordo com a sua complexidade, a sensibilidade dos dados, o seu custo e a sua latência. O primeiro modelo é assim utilizado apenas quando a situação o justifica. Como resume o autor, « Meter the exception, not the workload », ou seja: medir a exceção, e não a carga de trabalho.
Os modelos de pesos abertos tornam esta repartição cada vez mais praticável. Segundo os benchmarks de engenharia de software citados, os melhores entre eles podem aproximar-se do desempenho de ponta em certas tarefas. Esta constatação não garante a equivalência em todos os repositórios de código nem em todos os fluxos de trabalho. Recomenda-se, portanto, avaliar os candidatos no próprio código, nos próprios testes e nos critérios de aceitação antes de lhes confiar trabalho em produção.
Mudar a economia das utilizações repetidas
Resta determinar quem possui a capacidade de cálculo. Com uma inferência alugada, cada chamada acrescenta-se à fatura. Com uma capacidade própria, a maior parte do custo é assumida desde o início, de modo que cada chamada adicional se torna mais barata à medida que o uso aumenta.
