Principais destaques
- Opus + Sol lidera o ranking: a dupla somou 44,2 de 60 pontos possíveis, com desempenho consistente em seis projetos de programação.
- Planejamento vale tanto quanto código: equipes lideradas pelo Astra perderam pontos ao deixar funcionalidades essenciais fora das tarefas delegadas, mesmo quando os modelos executores trabalhavam corretamente.
- O teste tem limitações importantes: falhas de cotas, execução desigual e dados incompletos de custos impedem transformar o resultado em um ranking definitivo dos melhores agentes de programação.
Uma equipe de inteligência artificial pode contar com modelos excelentes para escrever código e, ainda assim, entregar um aplicativo incompleto. O problema nem sempre está na capacidade de programar. Às vezes, começa antes da primeira linha de código: no planejamento.
Essa é uma das principais lições de um benchmark que colocou cinco combinações de modelos de IA para trabalhar em seis projetos de software, incluindo um emulador de videogames, um jogo inspirado em Pokémon e uma aplicação de análise de dados de saúde.
O resultado favoreceu a combinação Opus como líder e Sol como executor. Mas a diferença para a segunda colocada foi pequena, e os resultados também revelaram problemas que vão além da escolha do modelo.
🏆 A disputa foi decidida por poucos pontos
O experimento avaliou equipes formadas por um modelo líder, responsável por planejar, distribuir tarefas e revisar o trabalho, e um modelo executor, encarregado de implementar as funcionalidades.
Cada projeto recebeu uma nota de até 10 pontos, considerando não apenas a compilação do código, mas também o funcionamento efetivo dos recursos e os testes de uso.
| Equipe | Pontuação | Aproveitamento |
|---|---|---|
| Opus + Sol | 44,2/60 | 73,7% |
| Opus + Sonnet | 43,7/60 | 72,8% |
A diferença foi de apenas 0,5 ponto em 60 possíveis. Portanto, o resultado favorece Opus + Sol no conjunto testado, mas não demonstra uma superioridade ampla ou estatisticamente estabelecida.
As outras combinações avaliadas foram Astra + Sonnet, Astra + Sol e Opus + Muse full. Problemas de planejamento e interrupções por limites de uso prejudicaram parte dessas execuções.
🔎 O detalhe que importa: o modelo líder não precisava escrever todo o código sozinho. Sua função era decidir o que deveria ser feito, por quem e em qual ordem. Uma especificação incompleta podia comprometer o projeto inteiro, mesmo quando os executores cumpriam suas instruções.
🧠 O líder pode ser o maior gargalo da equipe
A arquitetura conhecida como AI coding orchestration organiza agentes de programação em uma estrutura de coordenação. Em vez de depender de um único modelo para todas as etapas, o sistema distribui responsabilidades e combina diferentes capacidades.
O líder divide o projeto em tarefas, coordena até três executores simultâneos e verifica os resultados. Os executores implementam as funcionalidades atribuídas.
A vantagem é permitir que diferentes partes de uma aplicação sejam desenvolvidas em paralelo. O risco é que o paralelismo amplifique os erros de planejamento.
Se o líder delega a construção de uma interface, mas esquece a comunicação com o dispositivo que ela deveria controlar, a equipe pode entregar uma aplicação visualmente convincente e funcionalmente incompleta.
💡 Mais agentes não significam automaticamente melhores resultados. A qualidade das tarefas delegadas determina o que a equipe realmente tenta construir.
No benchmark, as equipes tiveram até 20 rodadas de planejamento do líder e 50 atribuições de tarefas no total. Mesmo com esse espaço para organizar o trabalho, algumas decisões iniciais tiveram consequências importantes para as notas finais.
🎮 O emulador expôs o problema mais grave
Um dos projetos mais exigentes foi um emulador desenvolvido em Rust, com suporte pretendido para Game Boy, Nintendo DS e Nintendo 3DS, além de recursos como estados salvos e controles de reprodução.
As equipes lideradas pelo Astra tiveram dificuldades porque seus planos contemplavam a execução completa de jogos de Game Boy, mas limitavam parte do trabalho relativo ao DS e ao 3DS à inspeção de arquivos.
Inspecionar um arquivo de jogo não equivale a executar o jogo. A diferença parece óbvia, mas foi justamente o tipo de lacuna que derrubou as pontuações.
| Equipe | Nota no emulador |
|---|---|
| Astra + Sonnet | 1,9/10 |
| Astra + Sol | 2,2/10 |
| Opus + Sonnet | 7,1/10 |
A equipe Opus + Sonnet obteve a maior nota individual registrada entre os resultados destacados do teste: 7,1 pontos nesse projeto.
Isso não significa que o emulador tenha alcançado compatibilidade ampla com jogos comerciais. A avaliação também tinha limites nesse aspecto, e os testes não demonstraram suporte abrangente a grandes bibliotecas de jogos.
Ainda assim, o contraste mostra como o escopo de implementação pode ser tão importante quanto a habilidade de escrever código.
⌨️ Uma interface bonita não basta para controlar um teclado
Outro teste exigia um configurador para teclados compatíveis com QMK, com uma proposta visual inspirada no VIA, ferramenta conhecida nesse segmento.
O requisito central não era apenas apresentar opções de configuração na tela. O aplicativo precisava conseguir enviar as alterações ao teclado conectado.
As duas equipes lideradas pelo Astra receberam notas de apenas 2,8 pontos.
O motivo apontado pelo benchmark foi o planejamento: as tarefas delegadas excluíam a comunicação necessária com o dispositivo. Uma das especificações chegava a deixar de fora a abertura do dispositivo e o envio das mensagens de configuração.
⚙️ A falha foi de escopo, não uma proibição técnica: o teste impedia modificar hardware real durante a avaliação, mas não proibia desenvolver o caminho de comunicação necessário. As equipes poderiam ter implementado e testado esse recurso sem alterar fisicamente a configuração de um teclado.
Esse caso ajuda a distinguir dois tipos de falha em sistemas de programação com IA: o modelo pode não conseguir implementar algo ou pode simplesmente nunca tentar, porque o plano não incluiu a funcionalidade.
🛋️ Quando a orquestração funciona, os agentes corrigem uns aos outros
Nem todos os resultados foram negativos. O designer de ambientes em 3D ofereceu um exemplo mais claro de coordenação produtiva.
Durante os testes, selecionar uma cadeira fazia a área de visualização ficar em branco. Inicialmente, o líder Opus atribuiu o problema a uma possível inconsistência na captura de tela.
O avaliador reproduziu o erro. Um executor recebeu a tarefa de corrigir o destaque de seleção, e o líder verificou o aplicativo reconstruído depois da mudança.
Esse ciclo envolveu quatro etapas importantes:
- Identificar um comportamento inesperado.
- Reproduzir o problema em condições de teste.
- Delegar uma correção específica.
- Verificar se a nova versão realmente resolveu a falha.
A equipe Astra + Sonnet alcançou 9,3 pontos nessa categoria, com divisão de responsabilidades entre o modelo de ambiente, o editor e o renderizador.
Opus + Sol e Opus + Sonnet também tiveram resultados fortes, com notas próximas de 8,9 a 9,0.
O resultado sugere que a coordenação pode funcionar muito bem quando o projeto permite separar componentes, testar comportamentos concretos e corrigir problemas de integração.
🐾 O jogo inspirado em Pokémon trouxe outra surpresa
A tarefa seguinte exigia um jogo jogável até o primeiro ginásio, com suporte para salvar e carregar o progresso.
Astra + Sonnet alcançou a melhor nota nessa categoria, com 9,1 pontos.
Durante o percurso de teste, a equipe identificou um problema no roteiro: o jogo orientava o jogador a se curar em um local que não tinha um centro de cura funcional. O líder delegou a construção da porta, do personagem não jogável e da rota necessários para completar essa parte da experiência.
Foi um exemplo de revisão que ultrapassou a simples verificação do código. O objetivo era observar a experiência como um jogador a encontraria, identificando inconsistências no fluxo.
Mas nem todas as equipes conseguiram entregar algo avaliável.
🚨 Quando a infraestrutura interrompe o trabalho: Astra + Sol terminou essa tarefa com zero ponto após erros HTTP 429 e o esgotamento das tentativas de repetição, deixando a pasta do projeto vazia. Opus + Muse full também recebeu zero no jogo após erros de cota que bloquearam seus executores.
Esses resultados refletem o que foi entregue durante aquelas execuções específicas. Não provam que os modelos sejam incapazes de construir os jogos.
🐳 Nenhuma equipe conseguiu substituir o Docker
O benchmark também propôs um desafio de infraestrutura: criar uma alternativa ao Docker, incluindo gerenciamento de imagens de contêineres, isolamento de processos e controles de recursos.
Nenhuma das cinco equipes entregou uma solução que atendesse aos requisitos essenciais de isolamento e controle.
Os resultados ficaram em torno de 5 pontos ou menos nessa tarefa, com implementações parciais de gerenciamento de imagens.
A distinção é fundamental. Conseguir manipular imagens de contêineres não significa implementar um ambiente seguro e isolado para executar processos. Uma ferramenta que oferece apenas parte dessa experiência não pode ser considerada uma substituta funcional do Docker.
O teste também mostra que uma demonstração visual convincente pode esconder lacunas profundas de arquitetura. Em sistemas que precisam controlar processos e recursos, não basta construir uma interface ou reproduzir superficialmente o comportamento esperado.
💸 US$ 405 em gastos, mas sem um vencedor em custo-benefício
O custo foi outro ponto inconclusivo.
O levantamento registrou aproximadamente US$ 405 em gastos com as equipes de agentes, mas apenas oito das 30 execuções de tarefas tinham dados completos de utilização de tokens.
Sem registros consistentes, não é possível calcular de maneira confiável o custo de cada combinação ou determinar qual oferece o melhor retorno por dólar gasto.
Também faltaram condições importantes para uma comparação rigorosa:
- Cada combinação realizou apenas uma execução por tarefa.
- Todas compartilharam a mesma máquina, mas não tiveram orçamentos computacionais equivalentes.
- Não houve comparação com cada modelo trabalhando sozinho.
- Os papéis de líder e executor não foram invertidos para testar a mesma dupla na configuração oposta.
Essas limitações impedem separar com segurança a influência do modelo, da estratégia de coordenação, dos recursos disponíveis e das falhas operacionais.
📊 Afinal, qual equipe vale mais a pena?
Os dados permitem identificar candidatos promissores para diferentes cenários, mas não estabelecer um ranking universal.
| Cenário | O que o teste sugere |
|---|---|
| Desempenho geral nos seis projetos | Opus + Sol teve a maior pontuação total |
| Sistemas e programação em Rust | Opus + Sonnet se destacou no teste do emulador |
| Interfaces e experiências visuais | Astra + Sonnet obteve notas altas no designer e no jogo |
| Projetos que dependem de comunicação com dispositivos | É essencial revisar o plano e exigir testes de integração |
| Escolha pelo menor custo | Não há dados completos suficientes para decidir |
O principal aprendizado não é que um modelo específico venceu definitivamente os demais. É que a qualidade da coordenação pode determinar se a capacidade dos modelos será convertida em software funcional.
Uma equipe de agentes precisa saber dividir o trabalho, mas também reconhecer dependências, preservar requisitos obrigatórios e verificar resultados reais. Sem isso, adicionar executores pode apenas acelerar a produção de funcionalidades incompletas.
O próximo passo para avaliar essas equipes com mais rigor seria repetir os testes com orçamentos equivalentes, múltiplas execuções e comparações entre modelos isolados e coordenados. Até lá, Opus + Sol tem a melhor pontuação observada, mas a disputa continua aberta.
