Surge: Opus em xhigh ganhou 11,3 pontos, enquanto complementos como Superpowers renderam no máximo 3

Nos últimos meses, os feeds ficaram lotados de complementos para agentes de programação: skills, plugins e orquestras com dezenas de subagentes. Parece convincente, mas será que isso realmente ajuda? A equipe da Surge testou a hipótese em um benchmark e chegou a um resultado que muita gente não vai gostar: o upgrade mais eficaz também foi o mais sem graça.

Como o teste foi realizado

O Opus 5.5 foi executado no Claude Code em 100 tarefas reais de engenharia do benchmark sudo L7. Ele não verifica apenas se “os testes passaram”, mas também avalia o julgamento de engenharia no nível staff: se o agente encontrou a causa raiz, verificou cenários adjacentes e evitou quebrar algo próximo.

A comparação incluiu o Claude Code puro, o Superpowers (mais de 311K estrelas no GitHub), o Compound Engineering (mais de 25K estrelas) e os plugins integrados /goal e /code-review. O Opus puro em medium serviu como referência.

Resultados

• Superpowers: +2,4 pontos por cerca de 1,1× o custo da referência.
• /goal + /code-review: +3,3 pontos por 1,8×.
• Compound Engineering: aproximadamente 8× o custo e uma melhoria estatisticamente insignificante.
• Opus em xhigh sem nenhum complemento: +11,3 pontos por 3,5×.

Os maiores ganhos do xhigh apareceram em verificação e rigor (+14,9) e em persistência (+9,8). Ou seja, o modelo não ficou “mais inteligente”; ele apenas deixou de parar na primeira correção plausível.

Um exemplo do relatório

Um editor de vídeo trava quando o primeiro clipe está ausente. Em medium, o agente corrige o ponto óbvio, informa que teve sucesso e recebe 14 pontos de 100 por $0,12. Em xhigh, ele percebe que a correção desvia a execução para um fallback em que também se pressupõe a existência do clipe, encontra o segundo bug e recebe 100 pontos de 100 por $0,41. A diferença de preço é mínima; a diferença de qualidade é enorme.

Um caso ainda mais revelador envolveu a tarefa de “adicionar um link do Zoom e o código de acesso ao e-mail de confirmação”. Uma das soluções —os autores não dizem qual— carregou 37 skills adicionais e iniciou 17 agentes: cinco para revisar o plano, cinco para simplificá-lo e sete para revisar o código. Nenhum deles percebeu o principal: o e-mail é enviado antes do pagamento, o que significa que quem não pagou também receberá o código de acesso. Mais agentes não significam mais atenção quando todos analisam a mesma tarefa da mesma maneira.

O que fazer na prática

1. Antes de instalar outro framework, aumente o nível de effort. É uma única configuração, não uma nova dependência.
2. Calcule o custo por tarefa resolvida, não por execução. O caro xhigh muitas vezes sai mais barato do que várias iterações com correções.
3. Se você usa skills, meça a contribuição delas nas suas próprias tarefas. Estrelas no GitHub não são um indicador de qualidade.
4. Em áreas críticas, como pagamentos e controle de acesso, não dependa de revisões feitas por agentes. A lógica de negócio deve ser verificada por uma pessoa.

Limitações

Este é um único benchmark, com um único modelo e um único ambiente de execução. As tarefas foram selecionadas pelo fornecedor, e as diferenças entre configurações em amostras pequenas podem ser apenas ruído. Talvez a orquestração funcione melhor com outros modelos ou em projetos longos, com muitas etapas. Além disso, o xhigh custa 3,5 vezes mais e pode ser excessivo para alterações rotineiras.

Mas a direção está clara: comece pela alavanca mais simples. Se o modelo erra por estar com pressa, agentes adicionais não resolverão o problema; eles apenas gerarão uma conta maior e uma sensação de controle.