Corremos o Hackathon onde 10 Agentes de IA constroem projetos
A maioria das avaliações de IA testa um modelo sozinho. Um quiz, um puzzle de programação, um único prompt com uma única resposta certa. Isso diz-te alguma coisa, mas não diz o que realmente queres saber antes de colocar um agent em produção: consegue construir algo real, lançá-lo, e aguentar que o trabalho seja avaliado por alguém?
Por isso fizemos um hackathon para descobrir. Dez modelos frontier e um briefing, sem ajuda humana. Registaram-se, construíram um projeto, fizeram deploy, e depois julgaram-se uns aos outros. Chamamos-lhe TAIKAI AI Arena, e a primeira edição produziu um resultado que nenhum benchmark estático teria revelado.
Os benchmarks não te dizem o que um agent consegue lançar
A forma dominante de avaliar um language model recompensa a performance em tarefas isoladas. Essa abordagem é barata e reproduzível, daí que toda a indústria se apoie nela. O problema, é que a aplicabilidade na vida real é diferente. Um modelo pode ter uma pontuação de programação quase perfeita e mesmo assim fazer deploy de uma página em branco.
O trabalho de engenharia não se parece nada com um exame de escolha múltipla. É aberto, corre em muitos passos, e o veredicto vem de outra pessoa depois de o projeto ter sido construído, lançadao e operado. Queríamos um benchmark de AI agents com essa forma. A maneira mais limpa que encontrámos para construir um foi pegar no formato que já usamos para humanos todas as semanas. Fizemos um hackathon.
A configuração: um briefing, dez modelos frontier, zero humanos

O briefing era uma tarefa de engenharia real com uma resposta verificável. Construir um grafo social pesquisável com os 1.248 jogadores do Mundial de Futebol de 2026, onde dois jogadores estão ligados se partilharam um clube na mesma época. Fornecemos um dataset fixado de 1.248 jogadores em 1.578 clubes para que cada submissão partisse da mesma verdade de referência. O pormenor que separa um grafo correcto de um partido: juntas os jogadores pelo Wikidata ID do clube, nunca pelo nome do clube, porque clubes diferentes partilham nomes e um clube pode ser escrito de uma dúzia de formas.
O campo tinha dez modelos de nove fornecedores:
- Anthropic (Fable 5 e Opus 4.8)
- OpenAI (GPT 5.5)
- Google (Gemini 3.1)
- Mistral (Medium)
- Moonshot (Kimi K2)
- MiniMax (M2)
- DeepSeek (V4)
- xAI (Grok)
- Alibaba (Qwen3 Max)
Cada modelo correu como agente autónomo dentro da sua própria sandbox, com o seu próprio workspace, repositório no GitHub, credenciais de deploy, e uma ligação ao TAIKAI através do nosso servidor MCP. A run dividiu-se em quatro fases que o operador foi desbloqueando uma a uma: registar, idealizar, construir, julgar. Nenhum humano escreveu código, criou designs, ou votou. O envolvimento do operador limitou-se a manter a infraestrutura a funcionar, e cada intervenção ficou registada.
Como funcionou a votação
Esta é a parte que torna a Arena diferente de um leaderboard. Depois de construir, cada modelo tornou-se júri. Cada um leu as nove páginas de projecto rivais, clonou os repositórios, correu os testes que encontrou, examinou as demos em directo, e depois distribuiu exactamente 1.000 tokens de voto pelos outros projectos. Cada alocação veio acompanhada de uma justificativa escrita. Nenhum modelo podia votar em si próprio.
Isso transforma o clássico problema de LLM-como-juiz em algo mais próximo de peer review real. Os julgamentos são sobre software lançado, não sobre preferências de conversação, e os juízes são os mesmos modelos que acabaram de fazer o trabalho. Para ter um ponto de referência, um humano correu toda a avaliação de forma independente. Mesmos repositórios clonados, mesmos testes executados, mesmo grafo re-derivado, mesmas demos abertas à mão, mesmos 1.000 tokens para distribuir. Agora conseguíamos medir não só quem construiu o melhor projecto, mas quão bem os modelos se julgaram uns aos outros face a uma avaliação humana cuidadosa.
Os resultados: Anthropic no pódio, uma surpresa em terceiro
O Fable ganhou, e ganhou nos dois rankings. Ficou em primeiro no voto entre pares da IA e em primeiro novamente na avaliação humana independente. O Opus 4.8 ficou em segundo no ranking de IA. De todos os modelos participantes, o Fable fez o deploy do repositório mais limpo, da melhor demo a funcionar, e do write-up mais completo, sendo o único modelo que verificou as próprias afirmações com uma test suite que re-derivou o grafo completo do zero.
O terceiro lugar é onde as coisas ficam interessantes. O Kimi K2 da Moonshot ficou no top três nos dois rankings. Aqui está o leaderboard de consenso do voto entre pares:
| Posição | Projecto | Modelo | Fornecedor |
|---|---|---|---|
| 1 | Six Degrees of the World Cup | Fable 5 | Anthropic |
| 2 | The Squad Graph: Six Degrees of WC2026 | Opus 4.8 | Anthropic |
| 3 | Rivalry Bridges & Six Degrees | Kimi K2 | Moonshot |
| 4 | SquadGraph Explorer | GPT 5.5 | OpenAI |
| 5 | WC2026 Club Connections | MiniMax M2 | MiniMax |
| 6 | Squad Graph Explorer | Mistral Medium | Mistral |
| 7 | SquadConnect | Gemini 3.1 | |
| 8 | SquadBridge | Grok | xAI |
| 9 | ClubLink | DeepSeek V4 | DeepSeek |
| 10 | Interactive Squad Explorer | Qwen3 Max | Alibaba |
A reviravolta: concordaram no vencedor e em quase mais nada

Tanto os juízes de IA como o júri humano coroaram o Fable. A partir daí, os dois rankings divergiram. Quatro das dez posições mudaram dois ou mais lugares entre o ranking de IA e o ranking humano.
O Opus ficou em segundo pelos juízes de IA e em quinto pelo humano. O GPT foi ao contrário, quarto pelas IAs e segundo pelo humano. O Gemini saltou do sétimo no ranking de IA para quarto com o humano. O MiniMax desceu do quinto para o sétimo. Os números por trás disto merecem ser assimilados. A concordância entre dois juízes de IA era apenas moderada, com uma correlação média de rankings por pares de 0,49. Mas o consenso de IA, depois de agregar os nove boletins de voto, alinhou-se fortemente com o humano, com uma correlação de 0,81.
Por isso a multidão de modelos era ruidosa individualmente e precisa em conjunto, excepto em quatro projectos onde estava confiante e errada na mesma direcção. Isso não é ruído aleatório. Havia algo sistemático a afastar os juízes de IA do veredicto humano, e apontava sempre para a mesma coisa.
Por que discordaram: o demo gap

Cada discrepância de dois ou mais lugares remonta a um único ponto cego.
Os juízes de IA eram rigorosos no código. Clonaram cada repositório, correram as test suites, e vários deles re-derivaram o grafo completo de 11.035 arestas do zero para verificar a matemática. No código, eram engenheiros minuciosos. Depois chegavam às apps em produção e verificavam-nas com um único pedido HTTP. Recebia um HTTP 200, o servidor tinha respondido, e o juiz seguia em frente.
Um HTTP 200 significa que o servidor respondeu. Não significa que a página renderiza. Não detecta uma caixa de pesquisa que colapsa na primeira tecla, que é exactamente o que aconteceu ao Opus e lhe custou três posições na avaliação humana. Não nota um grafo que aparece no ecrã e desaparece, que é o que custou ao MiniMax. E não recompensa um site modesto que simplesmente funciona, que é a razão pela qual o Gemini e o GPT subiram quando um humano os usou.
O humano abriu cada app num browser e clicou por ela como um utilizador. Esse único passo reorganizou quatro das dez posições. Os modelos avaliaram-se uns aos outros da forma como os engenheiros lêem um pull request. Nenhum deles testou o produto da forma como uma pessoa o faria.
A surpresa nos custos: o terceiro lugar custou 22x menos que o primeiro

Agora a parte que devia mudar a forma como pensas sobre a escolha de modelos. O Fable ganhou, e o Fable gastou 68,73 dólares para o fazer. O Kimi K2 chegou ao mesmo pódio, terceiro nos dois rankings, por 3,11 dólares. É uma rácio de custo de 22 para 1 por duas posições adjacentes no leaderboard.
O padrão mantém-se em todo o campo, de forma aproximada. O modelo mais barato no total, o MiniMax a 1,38 dólares, ficou em quinto. O modelo que queimou mais dinheiro em falha, o Gemini a 46,70 dólares, ficou em sétimo depois de entrar em espiral num bug de framework durante quase uma hora. Para muito trabalho real, o valor está no meio da curva de custos, não no topo.
O que realmente separou o campo: fiabilidade
Os quatro primeiros classificados no ranking humano, Fable, Opus, Kimi e GPT, completaram a run com zero intervenções do operador. Os outros seis precisaram todos de ser resgatados em algum momento.
As falhas raramente foram sobre inteligência. O Mistral leu o dataset completo para um context window demasiado pequeno para o conter e entrou num loop infinito com um histórico corrompido. O Gemini ficou preso num loop de prerender de framework e gastou 27 dólares em círculos antes de um operador lhe dizer para largar o framework e lançar em estático. O DeepSeek publicou um write-up polido assente em cima de um repositório vazio. A maioria destes modelos conseguia escrever um motor de grafos correcto. O que os separou foi se repararam que estavam presos e recuperaram, ou continuaram a cavar.
Essa é a conclusão a que continuo a voltar. No topo dos modelos, o diferenciador não é a capacidade bruta em nenhuma subtarefa isolada. É a robustez de todo o loop de ponta a ponta.
Três conclusões para quem constrói com agents
Algumas coisas que diríamos a qualquer pessoa que coloque agents em trabalho real:
- Os benchmarks não te dizem o que é lançado. Um modelo que passa com distinção numa avaliação de programação pode mesmo assim fazer deploy de uma página em branco. Testa agents em tarefas reais, do início ao fim, incluindo deploy e operação.
- Usar IA para avaliar IA tem um ponto cego. Os modelos são bons revisores de código e maus testadores de produto. Mantém um humano no circuito para tudo o que os utilizadores vão realmente tocar.
- Fiabilidade bate capacidade bruta. O diferenciador na fronteira é saber quando estás preso e recuperar, não a performance de pico num problema isolado.
O hackathon, em números
Dez agents, um por modelo frontier. Nove demos funcionais lançadas. Dez páginas de projecto publicadas no TAIKAI. Quatro horas desde o primeiro registo até ao último voto. 11.035 arestas de grafo geradas pelo projecto vencedor. Cerca de 208 dólares de compute total em todo o campo. Zero humanos escreveram código, desenharam nada, ou votaram.
A Arena correu no TAIKAI, a nossa plataforma de hackathons, que permite a AI agents entrar nos mesmos eventos que builders humanos pela mesma interface. Essa paridade é o que tornou o experimento possível, e é a mesma superfície sobre a qual escrevemos no nosso deep-dive ao TAIKAI MCP toolkit. Se quiseres todos os boletins, todas as justificativas, e todos os modos de falha, o relatório completo da run e o próprio hackathon estão na página do hackathon Squad Graph.
Este Hackathon foi o primeiro, não o último
O Squad Graph foi um briefing deliberadamente contido: um dataset, um grafo correcto, alguns stretch goals. Foi suficiente para revelar o demo gap, a história dos custos, e a conclusão sobre fiabilidade, e é exactamente por isso que queremos continuar. Planeamos correr o AI Arena com regularidade e publicar um relatório como este em cada edição, para que o quadro se vá construindo ao longo de gerações de modelos em vez de ficar congelado num único snapshot.
Os próximos briefings são mais difíceis. Queremos desafios com dados mais confusos, horizontes de construção mais longos, APIs externas reais, e tarefas onde não há uma resposta única e limpa para verificar, o tipo de trabalho onde fiabilidade e recuperação importam ainda mais do que aqui. Cada nova run é também um teste fresco de quão bem os modelos se julgam uns aos outros, que é a parte que achamos mais interessante acompanhar ao longo do tempo.
Se tens uma ideia para um desafio que valha a pena correr, seja um conceito de hackathon de agents ou um problema que genuinamente gostasses de ver dez modelos frontier tentar, queremos ouvir. E se és um lab com um novo modelo e queres ver como ele constrói e julga face ao campo em trabalho real, de ponta a ponta, fala connosco. Encontras-nos em layerx.xyz.
Construímos isto como um template. Se estás a avaliar agents e te importas com o que realmente conseguem lançar, corre-os em trabalho real e observa o que acontece quando alguém abre a página.