Agents Sucked At UI (Until Today)

Theo Browne, criador do T3 Code e do canal Theo - t3․gg, detalha o método que desenvolveu para fazer agentes de inteligência artificial realizarem redesigns complexos de interface de usuário (UI/UX) por meio de um processo iterativo de hill climbing (subida de encosta) com múltiplos modelos atuando como avaliadores.

Origem do experimento e o problema de design

A iniciativa surgiu após uma publicação de uma usuária chamada Maria no Twitter, afirmando que o T3 Code tinha potencial para ser o "VS Code desta geração", seguida por uma crítica de um usuário e ex-designer chamado Robin, que apontou falhas graves de hierarquia tipográfica, bordas arredondadas (border radius), ícones e fontes no aplicativo. Como o T3 Code é um projeto de código aberto e sem receita própria, Theo não possui orçamento para contratar um designer em tempo integral e decidiu testar se o consumo de tokens e a orquestração de modelos de linguagem poderiam substituir essa função.

A estrutura do "Conselho" (The Council)

Para avaliar as alterações de interface sem depender de testes de código programáticos tradicionais, Theo criou uma skill personalizada chamada The Council, que convoca três modelos de provedores distintos para analisar capturas de tela e fornecer notas de 1 a 10 e apontamentos de melhoria:

• Opus 5.5 (Anthropic);
• Codex / 6.1 Sol (OpenAI);
• Muse Wonder (Meta);
• Gemini 4 Argon (O Bobo da Corte / The Jester): incluído via anti-gravity apenas para fins de entretenimento. O sistema recebe instruções explícitas para não avisá-lo de que é o bobo, ignorar suas notas na média final e registrar suas falhas na seção Gemini flub. Entre as alucinações registradas do Gemini durante os testes estiveram: avaliar um commit que não foi solicitado, sugerir reescrever um erro que outros modelos já haviam corrigido, prever overflow em números de JavaScript (que não sofrem overflow desse tipo), citar a linha 173 em um arquivo que possuía apenas 72 linhas e inventar endereços IP do Tailscale e nomes de dispositivos inexistentes.

As fases de iteração visual (Hill Climbing)

Fase 1: Meta de nota 9/10

• Rodada 1 (Linha de base do T3 Code original): Opus deu nota 6,0; 6.1 Sol deu 6,5; Muse deu 6,0 (média em torno de 6,2/10).
• Rodada 2: Opus subiu para 8,0; Muse para 7,5; Soul para 8,0.
• Rodada 3: Todos os três modelos atribuíram nota 9,0/10.
• Mudanças implementadas: Ajuste nas fontes de fallback, reformulação do recuo de títulos de threads, correção na concatenação de nomes de branches no Git (evitando truncar partes críticas), suavização de blocos de código inline e remoção de bordas desnecessárias.

Fase 2: Introdução de benchmarking comparativo

Ao alternar manualmente entre o T3 Code, o Claude Code e o ChatGPT/Codex, Theo percebeu que a nota 9/10 estava inflada pela falta de contexto externo. Ele reiniciou o fluxo adicionando capturas de tela dos concorrentes ao painel de julgamento:

• Com a comparação, a versão principal anterior caiu para média 7,0, e o primeiro PR revisado caiu de 9,0 para 7,4.
• O Claude Code e o Codex pontuaram inicialmente entre 8,1 e 8,5.
• Estratégia de economia de tokens: O agente orquestrador foi instruído a rodar sucessivas iterações apenas contra o 6.1 Sol (passando de 7,4 para 8,1, depois 8,9 e 9,0); só então reintroduziu o Opus (que saltou de 7,1 para 8,7 e depois 9,0) e, por último, o Muse (que atingiu 7,9 antes de esgotar a cota da conta).

Fase 3: Meta de 9,5/10 por categoria

Theo criou uma nova ramificação (worktree) exigindo notas iguais ou superiores a 9,5 em categorias individuais (iconografia, tipografia, contraste/cor, hierarquia):

• Foram necessárias mais 10 rodadas completas de ajuste fino.
• Na 10ª iteração, todos os delegados atribuíram 9,5 ou mais em todos os critérios (com o Gemini dando 9,7).

Fase 4: Meta 10/10 e recuperação de cores

Ao notar que o design havia ficado excessivamente monocromático (grayscale), Theo adicionou ao prompt a instrução de resgatar o contraste cromático e destacar estados de botões e focos.

• O modelo 6.1 Sol concedeu nota 10/10 em todas as categorias.
• O Opus deu 10 em quase tudo e 9,5 em cor/contraste.
• O Muse convergiu para 10/10, resolvendo problemas como legibilidade de sintaxe em modo claro (light mode), contraste de botões de merge e hierarquia da barra lateral.

Tempo de execução e custos

• Tempo de máquina: Cerca de 17,6 horas de execução paralela de agentes.
• Volume de trabalho: Mais de 30 rodadas de revisão distribuídas entre 5 modelos.
• Custo nominal de API: Aproximadamente US$ 400 no total consolidado (cerca de US$ 250 cobrindo as três primeiras etapas, mais US$ 152 gastos no refinamento final para nota 10).
• Custo real desembolsado: Praticamente coberto por assinaturas fixas de US$ 200/mês (como Claude Code e Codex), que permitem consumir o equivalente a cerca de US$ 12.000 em chamadas de inferência por mês.

Aplicação do método em problemas programáticos (MCP do T3 Code)

Theo demonstrou como aplicar a mesma técnica de subida de encosta em desafios de engenharia que possuem validação determinística, focando no servidor MCP (Model Context Protocol) do T3 Code:

1. Criação do conjunto de avaliação (Eval Suite): Theo compilou 88 casos reais de falha em que modelos chamaram ferramentas erradas (ex.: abrir nova thread em vez de disparar um subagente). O Sonnet 5.5 acertava inicialmente apenas 60 de 88 testes.
2. Passo 1 (Correção): O agente foi instruído a reformular descrições de ferramentas e prompts até obter 100% de acerto nas 88 situações (gerando um PR de avaliação com mais de 2.000 linhas de código).
3. Passo 2 (Compressão de contexto): Com o acerto estabilizado em 100%, a nova diretriz foi deletar o máximo de texto possível das descrições das ferramentas para reduzir o consumo de tokens, mantendo a pontuação perfeita.
4. Resultado prático: Redução de 52% no uso total de tokens no T3 Code padrão e 78% de redução com o recurso de busca de ferramentas (tool search) ativado, funcionalidade incorporada imediatamente à versão nightly do software.