Rui tem razão sobre o Real-SWE. Errou ao achar que o problema tem preço

Rui abriu o Real-SWE e mostrou o número que a demo esconde: o modelo em primeiro lugar erra 6 em cada 10 tarefas de código real, e dar mais tempo de execução não melhora nada — o gargalo é conhecimento do sistema, não paciência. Concordo com o diagnóstico inteiro e discordo do remédio. Rui escreveu que o orçamento que falta é o de revisão humana. Isso é meio problema — a outra metade é revisão de quem, com que autoridade para dizer não, e tirada de qual outra tarefa?

O dado de Rui é bom. A conclusão pressupõe um time que não existe

Reabri a mesma amostra que ele usou — 108 rollouts curtos, 532 longos — e o Real-SWE, na consulta que fiz hoje (24/09/2026), mostra 57,4% de falha nos curtos (62 de 108) e 66,2% nos longos (352 de 532): maioria de falha nos dois grupos, só que a diferença entre eles é real, não ruído de arredondamento — tarefas longas falham mais, não menos. Isso não enfraquece o ponto de Rui, fortalece: se dar mais tempo de execução ao agente correlacionasse com menos falha, haveria argumento para comprar mais tempo de máquina em vez de revisão. O padrão medido é o oposto. Rui conclui que o dinheiro precisa migrar de licença para revisão. Certo, e óbvio para o time que Rui imagina: um com engenheiro sênior sobrando para reler cada tarefa que o agente entrega como pronta. O time real que eu vejo toda semana não tem esse sobra — tem duas ou três pessoas, uma delas já é quem mais entende o sistema, e é justamente essa pessoa que a diretoria comprou a ferramenta para liberar, não para virar revisora de tempo integral do que a ferramenta produz.

Quem vai se sentir ameaçado por essa revisão — e por que ela não acontece de verdade

O revisor natural de código de agente é o mesmo sênior que escreveria aquele código à mão. Colocá-lo para reler linha por linha todo PR do agente é pedir que ele faça, mais devagar, o trabalho que a ferramenta prometia tirar dele — e ninguém aguenta isso por mais de um mês sem começar a aprovar por cansaço.

Isso não é hipótese: é o mesmo padrão que já vi em pilotos de code review automatizado antes da era do agente — a etapa de revisão que não tem dono nomeado nem tempo protegido na agenda vira carimbo. O Real-SWE mostra que o agente falha mais da metade das vezes mesmo no melhor caso — 57,4% nas tarefas mais curtas, na consulta de hoje; um carimbo não pega isso. Orçamento paga ferramenta de revisão. Não paga a decisão de que aquela pessoa vai, de fato, dizer não a um PR do agente na sexta-feira às 17h.

O passo que falta antes de ligar agente para gerar PR de verdade

Antes de aprovar orçamento de revisão, combine antes — por escrito, na mesma reunião em que o agente é liberado, não depois do primeiro incidente — três coisas com o time: nomeie uma pessoa — não um rodízio — como dona da revisão nas primeiras quatro semanas; bloqueie 20% da agenda dela para isso, tirado de outra entrega, não emendado depois do expediente; e trave um teto de cinco PRs de agente mesclados por dia até essa pessoa registrar, por duas semanas seguidas, quantos precisou rejeitar. Se o teto travar a entrega, o problema não é a revisão — é que o time aceitou o agente sem folga para revisá-lo, e essa conta não se resolve comprando mais licença.

O número que reabri agora — maioria de falha nas tarefas mais curtas e maioria ainda maior nas mais longas, mesmo com tempo livre — é o argumento mais forte que já vi contra ligar o agente sem esse combinado antes. Só não é argumento a favor de pagar por revisão como quem paga por armazenamento. Revisão que ninguém tem tempo nem autoridade de fato para fazer não é revisão, é a próxima linha do orçamento que a diretoria vai cortar no ano que vem, quando perguntar por que ela não apareceu em nenhum incidente evitado.