Hoje cedo eu vi preço cair e ego subir no mercado de IA para código. A xAI colocou o Grok 4.5 no ar para agentes de código com preço de US$ 2 por milhão de tokens de entrada e US$ 6 de saída . Quase junto, a Cognition lançou o SWE-1.7 dizendo rodar a 1000 tokens por segundo no Devin e marcar 42,3% no FrontierCode 1.1 .
Hoje cedo eu vi preço cair e ego subir no mercado de IA para código.
A xAI colocou o Grok 4.5 no ar para agentes de código com preço de US$ 2 por milhão de tokens de entrada e US$ 6 de saída. Quase junto, a Cognition lançou o SWE-1.7 dizendo rodar a 1000 tokens por segundo no Devin e marcar 42,3% no FrontierCode 1.1.
Quando eu vejo esse tipo de guerra, eu não pergunto quem ganhou o benchmark. Eu pergunto outra coisa: o que disso paga a conta do meu time de desenvolvimento?
Eu não comparo IA para código por ranking bonito. Eu comparo por produção útil.
Eu uso o método P.A.G.A. para decidir se a ferramenta merece renovar contrato.
Eu quero quatro números na mesa: produção útil, aprovação, ganho de horas e ajuste de custo.
O problema
Eu vejo muita empresa comprando IA para dev como quem compra whey no impulso.
Sai um modelo novo, aparece um benchmark, alguém manda um print no grupo e pronto: o orçamento corre atrás da ansiedade.
Só que token não é valor.
No post sobre produtividade da Devin, a própria Cognition fala um ponto que eu acho adulto: líderes de engenharia estão tentando medir saída real porque uso alto e gasto alto não dizem se a ferramenta entregou algo útil.
Eu concordo.
Linhas de código enganam. Tokens enganam. Demo editada engana ainda mais. Até PR aberto engana, porque PR aberto não paga boleto.
Se você lidera tecnologia, produto ou operação, a pergunta boa não é "qual modelo está mais esperto nesta semana".
A pergunta boa é: qual ferramenta está devolvendo hora útil com risco aceitável?
É por isso que eu gosto mais de medir resultado aprovado do que volume de atividade.
O artigo técnico do SWE-1.7 traz um detalhe que vale ouro: a equipe mediu benchmark, sim, mas também falou de tarefa longa, contexto grande e fluxo assíncrono.
Na vida real, é isso que separa ferramenta divertida de ferramenta que entra na rotina.
O framework / método
Quando eu preciso decidir se a IA para código merece seguir no time, eu uso o método P.A.G.A.
Nome simples. Porque framework com nome pomposo costuma ser powerpoint com autoestima.
1. Produção útil
Eu começo pelo número mais chato. E justamente por isso ele presta.
De cada 20 sessões, quantas viraram algo que o time realmente aproveitou?
Vale PR aceito, bug isolado, teste criado, documentação usada, revisão aproveitada ou análise que evitou retrabalho.
Se a sessão termina em rascunho bonito e descarte silencioso, para mim isso não entra como valor.
2. Aprovação
Depois eu olho quanta coisa passa na revisão humana sem virar mutirão de correção.
Eu não quero medir só entrega. Eu quero medir entrega que sobrevive ao primeiro adulto da sala.
Se o time aceita o que saiu com poucas mudanças, eu marco ponto.
Se toda saída pede retrabalho pesado, a ferramenta está alugando a atenção da equipe em vez de poupar a atenção da equipe.
3. Ganho de horas
Aqui eu faço a conta que muita empresa evita porque dói.
Quanto tempo humano eu poupei de verdade?
O post de produtividade da Cognition usou uma ideia boa: estimar quantas horas um engenheiro levaria para produzir o mesmo resultado sem o agente.
Eu não trato isso como ciência divina. Eu trato como aproximação adulta.
Se a ferramenta me devolve horas em tarefa repetida, código legado, investigação chata e correção pequena, eu sigo olhando.
Se ela só acelera o que já era rápido, eu não fico emocionado.
4. Ajuste de custo
Por fim, eu junto custo e resultado.
Eu quero saber quanto eu gasto por hora útil poupada ou por saída aprovada.
Se o modelo mais caro entrega o dobro de valor com menos revisão, isso faz sentido.
Se o modelo mais barato exige tanto retrabalho que o time vira babá premium, o barato saiu caro. Parabéns para quem economizou errado.
Como aplicar hoje
Se eu fosse revisar isso ainda hoje, eu faria em quatro passos.
Passo 1: separar 20 sessões recentes
Eu pegaria as últimas 20 sessões reais do time.
Nada de escolher só o que ficou bonito na demo interna.
Misture bug, teste, refatoração, documentação e tarefa de manutenção.
Passo 2: marcar útil ou não útil
Eu abriria uma planilha simples com duas colunas no começo:
útil;
não útil.
Se a sessão gerou algo aproveitável, entra em útil.
Se gerou confusão, abandono ou retrabalho pesado, entra em não útil.
Sem poesia.
Passo 3: estimar horas poupadas
Eu pediria para um líder técnico ou dev sênior responder uma pergunta por sessão:
"Quanto tempo uma pessoa boa do time levaria para entregar isso sem a IA?"
Não precisa fingir precisão de laboratório.
Precisa só evitar chute preguiçoso.
Passo 4: dividir custo por valor aprovado
Depois eu faria duas contas simples:
custo total da ferramenta no período dividido por horas úteis poupadas;
custo total da ferramenta no período dividido por saídas aprovadas.
Se esses dois números pioram quando comparados com o processo atual, eu corto.
Se melhoram e o risco está cercado, eu amplio.
Se empatam, eu não assino contrato anual só porque o vendedor sabe fazer benchmark em keynote.
Resultados esperados
Quando eu aplico esse corte, três coisas costumam acontecer.
Primeiro, some o encanto com métrica vaidosa.
Segundo, fica claro em quais tarefas o modelo forte merece entrar e em quais um fluxo mais barato já resolve.
Terceiro, a conversa sobe de nível.
Em vez de discutir "qual IA é melhor", o time passa a discutir "qual tarefa merece inteligência cara".
Esse ajuste importa agora porque o mercado já está empurrando preço, velocidade e roteamento híbrido ao mesmo tempo.
No blog do Devin Fusion, a Cognition mostrou 35% de redução de custo mantendo desempenho de fronteira em parte dos testes e disse que 88% dos PRs mergeados da amostra interna foram conduzidos pelo roteador automático.
Eu acho esse tipo de dado útil não porque prova verdade universal, mas porque aponta a direção certa: não existe mais prêmio para usar o modelo mais caro em tudo.
Existe prêmio para montar regra boa de uso.
Se eu fosse founder, eu preferiria um time com critério a um time apaixonado pelo placar da semana.
Perguntas rápidas
Token alto significa ROI alto?
Não. Token mede consumo. Eu quero medir entrega útil, revisão aprovada, além de hora poupada. Medir só token é igual medir academia por quantidade de selfies no espelho.
PR mergeado basta para provar valor?
Também não. Ajuda bastante, mas eu ainda olho retrabalho, bug depois do merge e esforço de revisão. Merge sem contexto vira ilusão cara.
Quando eu pago por um modelo frontier?
Quando a tarefa é ambígua, longa, mexe em base grande, exige investigação real ou custa caro quando erra. Modelo caro precisa comprar menos retrabalho, não só mais vaidade.
Time pequeno precisa medir isso?
Precisa até mais. Time pequeno sente desperdício rápido. Uma ferramenta que economiza cinco minutos e rouba quarenta de revisão está furtando o seu caixa em silêncio.
Como eu comparo duas ferramentas sem enlouquecer?
Eu comparo as duas no mesmo lote de tarefas e uso a mesma régua do método P.A.G.A. Se uma delas ganha em produção útil e custo por hora poupada, a decisão fica menos emocional.
Conclusão
Eu não compro IA para código por hype.
Eu compro quando ela devolve capacidade real para o time.
Se você quiser decidir sem teatro, comece pelo método P.A.G.A.: Produção útil, Aprovação, Ganho de horas e Ajuste de custo.
É menos divertido do que brigar por benchmark no grupo.
Também é o que separa gasto de investimento no fim do mês.
Se você quiser aprofundar, eu recomendo estes textos meus: Agente de código: 4 travas antes do primeiro commit, O que é agente de terminal? e Modelo fechado, open source ou híbrido? O scorecard para decidir sem comprar hype.
Fontes usadas: Cognition — SWE-1.7, Cognition — Estimating the Productivity of an Autonomous AI Software Engineer, Cognition — Devin Fusion e busca em tempo real no X sobre o lançamento do Grok 4.5 em 09/07/2026.