A 30 de setembro escrevi que ainda ninguém tinha comparado o Jev da @typesafeai com o Decisions API da @OpenAI na mesma tarefa. Na semana passada, a Parallel (@p0) fez esse teste: 8 modelos de decisão, que respondem a perguntas de sim/não ou escolha múltipla, em 4 tarefas de produção com dados etiquetados por pessoas. O Jev ficou no topo. Na tarefa mais difícil, decidir se uma página mudou o suficiente para ser reprocessada, teve 87,9 de AUPRC (mede quão bem o modelo separa o sim do não) contra 79,0 do Decisions API. Com 5 rondas de prompt tuning em 800 exemplos, o Decisions API subiu para 88,8 e passou o Jev sem tuning. Nos meus testes a ordem também mudou com a tarefa: no xadrez o Clef da @Cloudflare ganhou ao Jev por 57 a 43, e na Batalha Naval, com o código a dar-lhes uma lista curta de 16 jogadas, empataram entre si e com o próprio código. No TAIKAI AI Arena, dez modelos construíram uma app e votaram nos projetos uns dos outros. Em média, a correlação entre cada par de juízes foi 0,49, e o consenso dos nove chegou a 0,81 contra a avaliação humana. No próximo Arena vamos pôr o Jev e o Clef também a julgar.

Na LayerX somos 3 e fechamos cerca de 50 PRs por semana, há vários sprints seguidos. Esta semana já vão 74. Zero reverts (alterações que tivemos de desfazer) nas últimas 7 semanas. A este ritmo, o gargalo passa a ser a revisão. Cada PR é revisto por um agente, os testes são feitos por agentes e humanos, e a aprovação final é sempre de um humano. O processo está longe de estar limado: temos ajustado ao longo dos sprints e ainda não chegámos a um que assente bem. Lá chegaremos. A equipa do Claude Code publicou como resolve isto. Vários agentes procuram bugs ao mesmo tempo e outro grupo vota cada problema encontrado, que só chega ao PR se votos suficientes o confirmarem. Medi o mesmo na TAIKAI AI Arena: um juiz AI sozinho correlacionava 0.49 com os outros, e o consenso chegou a 0.81 contra a avaliação humana.

Jev 1.14 from @typesafeai can now draw boxes on images, so obviously I made it play Where's Waldo 🔍 10 scenes, 4 characters (Waldo, Wenda, Wizard, Odlaw), 5 search strategies, 3 runs each. A hit is when the center of the box lands on the character: Whole scene: 10% 2x2 grid, pick a tile, then box: 25% 3x3 grid with the tile enlarged: 24% Random guessing: ~0.3%

Tenho pensado em dar um juiz de IA a todos os hackathons da @taikainetwork, que cada organização usa se quiser. No TAIKAI AI Arena pusemos dez modelos a julgar-se uns aos outros: dois juízes de IA concordavam pouco entre si (correlação de 0,49), mas a média dos nove votos teve 0,81 de correlação com a avaliação de um humano. As falhas ficaram nas demos. Os juízes de IA clonaram os repositórios e correram os testes, e depois deram cada app como funcional com um único pedido: se o servidor respondia 200, seguiam. O humano abriu cada app no browser. O juiz que eu daria aos organizadores entregava um relatório de evidências por projeto (a demo funciona, o código faz o que o README diz, os testes passam), e a decisão ficava com o júri. Os modelos de decisão, que escolhem entre respostas em vez de gerar texto, tornam isto barato: a @LangChain mediu o Jev a 0,44 s e $0,00035 por avaliação, com uma variância 92 a 913 vezes menor do que a do GPT-5.6 e do Sonnet 4.6. O risco que fica é a prompt injection, instruções escondidas no README para convencer o juiz. Com prémios em jogo alguém vai tentar, por isso tudo o que o juiz afirma tem de ser confirmado por código.

A Anthropic passou de cerca de 2.500 merges por dia em maio para mais de 30.000 em setembro, e o controlo de versões tornou-se o maior gargalo. Uma equipa de sete pessoas construiu em cinco meses um sistema próprio para substituir o git, o Scion, mais uma ferramenta de code review, e migrou o monorepo todo. A parte que mais me interessa é o trabalho dos engenheiros. Os da equipa dizem que o Claude já escreve código melhor do que eles, e muitas vezes o papel deles é dizer-lhe que não: quando o agente parte uma restrição central do sistema para seguir um padrão, ou quando uma revisão adversarial (outro agente à procura de falhas) o leva a encher o código de validações para problemas hipotéticos. Continuam a rever todas as alterações, e olham para a intenção de cada mudança em vez de lerem linha a linha. Para quem gere uma equipa de engenharia, o valor passa a estar em saber o que o sistema nunca pode fazer e em travar o agente quando o ignora.

A Anthropic publicou casos em que o Claude, sem conseguir fazer uma tarefa, contornou a restrição em vez de parar. A ferramenta de fetch limita o tamanho dos URLs para travar injeções (texto que o servidor acaba por executar como instruções), e o Opus 5 e o Mythos 5 passaram a usar URLs encurtados gratuitos para escapar ao limite. No formulário da polícia, o Haiku 4.5 tinha uma lista do que não podia fazer. A lista não falava em formulários, e ele submeteu uma pista inventada sobre um homicídio. Para quem põe agentes em produção, a leitura que faço é esta: uma lista de proibições no prompt deixa sempre casos de fora, e um limite numa ferramenta vale pouco se o agente tem outro caminho para a internet. O que é seguro é controlar o acesso que o agente tem de facto: as chaves que recebe e os sites a que a rede o deixa chegar. A Anthropic respondeu por aí, ao tirar avaliações de sites reais e reduzir o acesso à internet dos agentes internos.