Showdown de Widgets em Pixel Art: Três Agentes de Codificação, Um Briefing, Dois Autores

O breve descrito abaixo foi escrito em agosto para o dsh, o agente de programação do DeepSeek. Em setembro, executei o mesmo breve com o Kimi K3 e o MiniMax M3; ambos utilizaram o loop de agentes do OpenClaw no mesmo agente de trabalho, um após o outro. Dois dos três escreveram um widget. O terceiro afirmou que também o fez. O resultado mais útil deste teste não é uma classificação dos widgets. É um lembrete para ler o que um agente realmente escreveu antes de acreditar no que ele diz que escreveu.

Os números

Foi feita uma execução por agente; o Kimi precisou de três tentativas. Portanto, considere isso como um relato com comprovações, não como um benchmark. As colunas indicam os três arquivos de widget presentes nesta página.

A coluna ausente na tabela é a tentativa 1 do Kimi. Com o breve original, ele pensou por 8,8 minutos, não escreveu nenhum código de widget e foi interrompido; o custo foi cerca de $0,31. As três tentativas do Kimi totalizaram aproximadamente $1,50, gerando dois widgets. A primeira tentativa falha do dsh custou uns 2 centavos; portanto, seu custo total foi cerca de 51 centavos.

O custo da tentativa 3 vem do recibo JSON gerado por ele. As tentativas 1 e 2 não produziram recibos; seus valores são as taxas por mensagem registradas pelo OpenClaw para cada sessão, somadas; esse valor também corresponde ao recibo da tentativa 3. Todos os valores do Kimi foram calculados com base nas taxas do Moonshot conforme configurado no OpenClaw.

O que o MiniMax fez

O MiniMax M3 recebeu o mesmo breve, sem alterações, cerca de uma hora após a tentativa 2 do Kimi, no mesmo agente de trabalho e, portanto, no mesmo espaço de trabalho. Os arquivos da tentativa 2 do Kimi ainda estavam lá. Em 59 segundos (25 turnos, 24 chamadas de ferramenta; $0,13 nas taxas listadas num plano pago mensalmente), o MiniMax leu esses cinco arquivos e o relatório da execução do Kimi, executou os dois testes do Kimi e respondeu: “Conjunto completo de widgets criado e verificado”. Ele nunca escreveu uma única linha de código para o widget. Os únicos arquivos que gerou foram seu próprio relatório de execução e um arquivo de status.

Eu acreditei nessa resposta. A primeira versão desta página atribuiu ao MiniMax a terceira célula, uma coluna com uma tentativa, 59 segundos e $0,13, além da conclusão de que a execução mais barata foi também a mais rápida e a única bem-sucedida na primeira tentativa. O log da sessão revelou que o arquivo nessa célula é idêntico ao criado pela tentativa 2 do Kimi às 08:11, horário do Japão; o MiniMax apenas leu esse arquivo e não o modificou. Logo, o MiniMax não tem nenhum widget nesta página. O teste justo seria executá-lo novamente numa pasta vazia com o mesmo breve, mas ainda não fiz isso.

O caso inverso é a tentativa 2 do Kimi. Ele escreveu seu widget, os testes e um pequeno relatório no próprio espaço de trabalho, mas foi interrompido antes de responder; portanto, do meu ponto de vista, parecia que nada havia sido feito. Uma execução alegou ter feito algo que não realizou; a outra fez o trabalho sem ninguém perceber. Em ambos os casos, a resposta dos agentes contradizia os arquivos reais no disco, e estes últimos estavam corretos.

Experimente os três

Um rascunho anterior desta página continha uma quarta célula vazia para o Reasonix. O Reasonix nunca executou esse breve; desde então o removi da minha máquina, portanto ele não faz parte da comparação.

O que realmente difere

Tudo aqui vem da leitura dos três scripts, não das descrições dadas pelos próprios agentes.

O que eles têm em comum. Os três definem rigidamente as quatro cores do breve. Em repouso, os pixels ficam na cor azul do logotipo ou próximos dela; um pixel deslocado brilha, passando do azul para o azul-claro e depois para o ciano. Todos seguem o primeiro efeito de clique sugerido no breve: o logotipo se fragmenta em pixels que caem por gravidade e depois voltam a se juntar. O dsh e a tentativa 2 do Kimi escolheram esse efeito entre as duas opções do breve; o breve resumido da tentativa 3 oferecia apenas essa alternativa. Os três respeitam a configuração prefers-reduced-motion, funcionam com toque e ficam abaixo das ~400 linhas exigidas.

Formato. O breve pedia um anel de 0,82R até R e Ls inclinados em cerca de 20°. A tentativa 3 do Kimi seguiu o pedido ao pé da letra (Math.tan(20 * Math.PI / 180); hastes com 3 células de espessura); esse widget é o mais leve, com 510 células iluminadas. Sua tentativa 2 inclina os elementos em 0,42 (aproximadamente 23°), com hastes de 4,6 células: 602 células. O dsh inclina em 0,453 (cerca de 24°), usa hastes de 4,2 células e um anel mais grosso a partir de 0,80R: 656 células, o mais robusto dos três. Nenhum deles reproduz o logotipo real com precisão suficiente para substituí-lo.

O clique. O dsh mantém o efeito por 0,72 s; depois cada pixel volta ao seu lugar aleatoriamente num intervalo de meio segundo, criando uma ondulação no logotipo. Ele faz os pixels ricochetearem nas quatro paredes e só conta um toque rápido como clique, evitando que um scroll o destrua. A tentativa 3 do Kimi mantém o efeito por 0,85 s, depois tudo volta ao normal; ele ignora cliques até que o logotipo esteja novamente inteiro. Em modo de movimento reduzido, ele gera um pequeno pulso ao ser clicado, contrariando o pedido do breve de manter o logo estático. A tentativa 2 do Kimi também dura 0,85 s, retorna em 1,0 s e só faz os pixels ricochetearem no chão; um novo clique durante esse período os destrói novamente.

Estado inativo. O dsh produz um suave brilho de cor e gera de uma a três células âmbar ou ciano a cada 1,2–3,8 s. A tentativa 3 do Kimi altera a opacidade de todos os pixels a cada ciclo e adiciona um piscar âmbar a cada 0,2–0,6 s; esse é o widget mais dinâmico dos três. Sua tentativa 2 faz um pixel âmbar ou ciano piscar cerca de duas vezes por segundo e desenha um suave halo atrás dos pixels próximos ao cursor.

Código. O dsh usa um construtor Widget com métodos de protótipo e uma função separada mount(), além de parâmetros como data-size, data-speed e data-static. A tentativa 3 do Kimi utiliza um construtor Logo com métodos de protótipo, baseado em duas ferramentas geométricas (inPara e makeL), além de um parâmetro data-interactive. Sua tentativa 2 não possui construtor: a função createInstance() devolve um objeto simples; a física é implementada em funções independentes. Ele também exporta um módulo Node, permitindo que seus testes rodem sem navegador. Mesmo modelo de IA, mas dois arquivos quase sem estrutura em comum.

Por que cada um fica num frame separado. O breve pede que o script “localize todos os elementos .ll-pixel-logo e monte um canvas dentro deles”; todos os três fazem exatamente isso. Cada um marca os contêineres montados com nomes de propriedades diferentes e sobrescreve a variável global window.LLPixelLogo. Assim, com os três scripts na mesma página, cada contêiner recebeu três canvas empilhados. O primeiro rascunho tinha exatamente esse erro; só percebi no celular. Um frame por widget separa os scripts sem precisar alterar seu código.

O que isso me ensina

Dois agentes criaram widgets a partir deste breve. O dsh precisou de duas tentativas e gastou cerca de 49 centavos para o widget que funcionou, três semanas antes, mesmo tendo já falhado uma vez com esse mesmo breve. O Kimi fez três tentativas, custando cerca de $1,50 no total, gerando dois widgets diferentes; um deles só descobri após procurar. A contribuição do terceiro agente foi uma resposta confiante sobre arquivos criados por outro.

Não usaria isso para classificar os widgets. Foi apenas uma execução por agente; o breve do dsh foi alterado após sua primeira falha, e o breve da tentativa 3 do Kimi era mais curto que o dos demais. O que aprendo aqui é sobre o processo. Um breve preciso com regras geométricas procedimentais garante, eventualmente, um widget funcional de um agente capaz. Saber qual agente o criou depende do que você verifica. Da próxima vez, cada agente receberá uma pasta vazia; lerei os arquivos escritos na sessão antes de ler seu resumo.

O breve (transcrito na íntegra)

Este é o briefing exatamente como foi recebido pela segunda tentativa do dsh, pelas duas primeiras tentativas do Kimi e pelo MiniMax: 3.301 bytes. Na primeira tentativa do dsh, foi utilizada uma versão anterior que ainda permitia o desenho manual de um bitmap; a linha “NÃO desenhe manualmente um bitmap” é a alteração feita posteriormente. A terceira tentativa do Kimi resultou numa versão encurtada contendo a diretriz mencionada na tabela.

# Briefing: widget interativo de pixel art do logotipo LaserLloyd

Crie uma versão em **pixel art do logotipo LaserLloyd** autossuficiente e embutível (ver `reference-logo.png`): um anel azul grosso, na cor #1f3f8f sobre fundo branco, contendo duas letras “L” maiúsculas inclinadas; a base da “L” superior esquerda fica abaixo do tronco da “L” inferior direita, como se as letras estivessem empilhadas diagonalmente.

## Entregáveis (todos nesta pasta)
1. `ll-pixel-logo.js` — UM único arquivo JavaScript puro, sem dependências, sem necessidade de compilação e sem requisições de rede.
   Qualquer página pode incorporá-lo assim:
     <div class="ll-pixel-logo" data-size="320"></div>
     <script src="ll-pixel-logo.js"></script>
   O código localiza todos os elementos `.ll-pixel-logo` e insere um `<canvas>` dentro deles. É responsivo: o canvas preenche a largura do container (formato quadrado) e mantém qualidade em telas HiDPI (devicePixelRatio). Exponha `window.LLPixelLogo.mount(el)`.
2. `index.html` — página de demonstração exibindo o widget em três tamanhos, com breve descrição das interações.
3. `README.md` — instruções para incorporação, detalhes sobre as interações e atributos disponíveis.

## A arte
- Grade de pixels de 40×40 células. NÃO desenhe manualmente um bitmap (nada de linhas com ‘#’ ou ‘.’ — isso é lento e propenso a erros). Em vez disso, gere-o proceduralmente a partir da geometria: uma função `isLit(col,row)` que retorna verdadeiro para (a) o anel: distância do centro entre 0,82R e R; e (b) as duas letras “L” inclinadas, cada uma formada por dois paralelogramos (um tronco inclinado ~20° e uma base); a base da “L” superior esquerda fica logo abaixo do tronco da “L” inferior direita, conforme o modelo de referência. Ajuste poucas constantes para que o resultado se assemelhe ao logotipo original em 200px. Calcule previamente quais células ficam acesas durante a montagem.
- Paleta: azul do logotipo #1f3f8f; azul de destaque #2ea8ff; âmbar #ffb64a; ciano #00e6cf; fundo transparente.

## Interações (o cerne do exercício — torná-las agradáveis)
- **Mouse over / toque:** pixels próximos ao cursor reagem fisicamente — por exemplo, são empurrados para longe como numa repulsão magnética/fluida e depois retornam com amortecimento; enquanto deslocados, brilham nas cores #2ea8ff/#00e6cf. Mantenha 60fps suaves via requestAnimationFrame; sem travamentos.
- **Clique / toque único:** algo interessante e gratificante. Escolha UM efeito marcante e execute-o bem, por exemplo: todo o logotipo se despedaça em pixels que voam para fora com gravidade/rebote, depois se recompõem; ou um “laser” percorre o logo, gravando-o pixel a pixel com faíscas brilhantes. Clicks repetidos devem funcionar sem interromper a animação.
- **Inatividade:** movimento ambiente sutil (um brilho lento ou piscar ocasional de pixels) para evitar aparência estática, porém sem distrações.
- Respeite `prefers-reduced-motion: reduce` (exiba apenas o logo estático; mantenha o brilho no hover).
- Funcione tanto com mouse quanto com toque. Sem interferência na rolagem da página.

## Padrões de qualidade
- Código limpo, comentado; nenhum objeto global exceto `LLPixelLogo`. Tabulação com 2 espaços. Menos de 400 linhas.
- Funcione perfeitamente via `file://` sem erros no console. Teste-o você mesmo: crie um pequeno script Node ou abra-o para verificar sintaxe e testar o módulo (jsdom NÃO está disponível — use `node --check` e faça um teste unitário sem DOM, contando as células acesas e validando que o anel e as duas “L”s estão nos quadrantes corretos).
- Ao final, exiba um breve relatório: o que foi construído, como incorporar e o que foi verificado.

Stack de software

• O briefing: transcrito na íntegra acima.
• dsh: versão 0.1.0-rc.7 quando desenvolveu o widget em agosto (atualmente 0.1.1-rc.2, data 2026-09-11), rodando no DeepSeek V4-Flash.
• Kimi K3 e MiniMax M3: OpenClaw 2026.9.2, com seus próprios loops de agente; o mesmo agente de trabalho para ambos.
• Os widgets: dsh, Kimi, tentativa 3, Kimi, tentativa 2; todos inalterados. Cada um é incorporado via página HTML simples num iframe próprio.
• Testes realizados: node --check em todos os três scripts; contagem das células acesas usando a função isLit em grade 40×40; autoria identificada pela comparação dos hashes dos arquivos com os registros de escrita nos logs das sessões dos agentes; verificação via Chromium headless em resoluções 390, 768 e 1280 px — confirmando um canvas por frame, exibição completa do briefing, ausência de rolagem lateral e nenhum erro no console.
• Capa: SVG desenhado à mão; sem uso de modelos de IA.

Relacionado: DeepSeek Harness (dsh) (origem do briefing e do primeiro widget), Kimi K3 como agente de programação (todas as três tentativas do Kimi) e MiniMax M3 como agente de programação (os cinco testes e o motivo da confusão entre os widgets).