Como medir qualidade de código sem gastar um token de IA

A intuição, na era da IA, é tentadora: a cada pull request, peça para um modelo grande ler o diff e dar uma nota de qualidade. Parece moderno. Na prática, é uma péssima ideia — e é exatamente o que não fazemos no Octopus, a ferramenta de orquestração de agentes de IA que construímos.

Este artigo é sobre uma escolha contraintuitiva: usar IA o tempo todo no desenvolvimento, mas medir qualidade de código a custo praticamente zero de IA.

Por que “IA como juiz” é ruim para métrica

Pedir a um LLM para avaliar a qualidade de um PR tem três defeitos sérios:

Custa caro. Cada PR queima tokens. Multiplique por um time inteiro, todos os dias.
Não é determinístico. O mesmo código pode receber veredictos diferentes em duas execuções. Métrica que muda sozinha não é métrica — é opinião.
É lento e alucina. O modelo pode “achar” que a cobertura caiu sem ter como contar de fato.

Para medir, você quer um número confiável e reproduzível. LLM não é a ferramenta para isso.

A abordagem: deixe a stack medir, de graça

Cada linguagem já tem ferramentas que contam o que importa, com precisão e a custo zero de tokens. O Octopus aproveita isso:

Cobertura de testes — pela ferramenta de cobertura da própria stack.
Complexidade ciclomática — por um analisador estático.
Tamanho de módulo, ciclos de dependência, profundidade de aninhamento — análise estática.
Hotspots — cruzando o histórico do git (quanto um arquivo muda) com a complexidade dele.

Tudo isso roda como qualquer comando da build: rápido, determinístico, sem gastar um único token.

Dois deltas: tendência e impacto

Medir um número isolado diz pouco. O Octopus compara cada métrica de duas formas:

Contra a base (a main consolidada): a tendência de longo prazo do projeto.
Contra a main atual: o impacto específico deste PR.

Assim a conversa deixa de ser “o código está bom?” e vira “este PR melhora ou piora cada eixo?”.

Ratchet: nunca pior do que ontem

A regra padrão é uma catraca (ratchet): uma métrica não pode regredir em relação à base. Isso resolve o dilema dos projetos legados — eles não começam “no vermelho” por terem dívida acumulada; eles só não podem piorar. A qualidade sobe de forma incremental, sem exigir um mutirão de refatoração antes de qualquer entrega.

E onde entra a IA, afinal?

A IA não some — ela entra no lugar certo e só quando precisa. Quando uma métrica estoura o limite, aí sim um modelo barato é acionado para explicar o que aconteceu e sugerir uma correção. Direcionado ao problema, não varrendo o PR inteiro às cegas.

É a divisão de trabalho que faz sentido: ferramenta determinística para medir; IA para julgar e orientar quando há o que julgar. Pagar um LLM para contar linhas e ramos é desperdício; usá-lo para interpretar um hotspot é onde ele brilha.

A lição além de métricas

O padrão vale para muito além de qualidade de código: não jogue IA em todo problema só porque ela está à mão. Onde existe uma resposta exata e barata, use a ferramenta exata e barata. Reserve o modelo para o que exige julgamento. É mais rápido, mais previsível e — não por acaso — muito mais barato.

É assim que a Dravit constrói com IA: deliberada sobre onde ela agrega, e onde ela só encareceria. Quer levar IA para o seu fluxo de forma econômica e confiável? Vamos conversar.