Dev & EngARTIGO

Claude Opus 5.5 monta pipeline de imagem em tempo real no navegador, sem libs externas

Simon Willison usou um único prompt para o Claude Opus 5.5 gerar um artifact que pinta fotos com detecção de bordas de Sobel, rodando inteiro no navegador sem bibliotecas.

Opus 5.5 escreve o código, Artifacts roda na hora: o que a dupla destrava

O Claude Opus 5.5 é um modelo de raciocínio da linha Anthropic; sozinho, ele só devolve texto e código dentro de um chat. Quem transforma esse código em algo que roda de verdade é o Claude Artifacts, o sandbox embutido no Claude.ai que executa o código gerado, como o canvas usado neste experimento, direto no navegador. Na prática, isso dispensa configurar servidor ou processo de build para ver o resultado funcionando.

Simon Willison publicou no blog dele, em 23 de outubro de 2026, um experimento batizado de Quick Study: um prompt único para o Opus 5.5 no modo "High" pedindo um artifact que abre uma foto e, em poucos segundos, "pinta" uma versão dela usando canvas e um pincel simulado.

A combinação destrava algo específico: ir da ideia ("quero um filtro de pintura que rode no navegador") a um protótipo funcional sem abrir editor, sem npm install, sem configurar bundler. O modelo escreve o algoritmo de visão computacional (detecção de bordas de Sobel) e a animação do pincel; o Artifacts expõe isso como uma página que já roda ali, dentro do próprio chat.

Pré-requisitos: modelo, plano e quase zero dependências

Para reproduzir o experimento é preciso acesso ao Claude Opus 5.5 com o esforço "High". Também é preciso a função Artifacts habilitada na conta, e um navegador atual com suporte a Canvas API e FileReader, o que já cobre praticamente qualquer navegador de 2026.

Willison é explícito sobre a dependência de código: nenhuma biblioteca externa além do Google Fonts. Nada de p5.js, OpenCV.js ou three.js: o Sobel e a lógica de pintura saem inteiramente do que o Opus 5.5 escreveu na hora, em JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) → puro sobre um <canvas>.

Vale o contraste com o experimento anterior do próprio Willison, linkado no post: para simular uma ilustração em aquarela, ele usou outro modelo da família (Claude Fable) apoiado em P5.js, biblioteca de desenho generativo. Dessa vez a régua ficou mais dura: zero bibliotecas de desenho, só a API nativa do navegador.

Passo a passo: do prompt ao canvas pintando sozinho

O prompt publicado por Willison é curto e direto:

Construa um artifact em que você abre uma foto e ele rapidamente (em poucos segundos) pinta uma versão dessa foto usando um elemento canvas e um pincel simulado.

Build an artifact where you open a photo and it rapidly (in a few seconds) paints a version of that photo using a canvas element and simulated paintbrushSimon Willison, autor do Quick Study

Para reproduzir esse fluxo num projeto típico, o caminho seria:

  1. Abrir uma conversa no Claude.ai com o modelo Opus 5.5 e o esforço de raciocínio em "High"
  2. Colar o prompt acima, sem contexto adicional (é o único input que Willison registrou)
  3. Deixar o Claude gerar o artifact: um arquivo com <input type="file"> para carregar a foto, um <canvas> para desenhar e um script que primeiro aplica o kernel de Sobel para achar as bordas e depois anima traços de pincel seguindo essas bordas
  4. Rodar o artifact ali mesmo, soltando uma foto e observando o resultado se formar em alguns segundos
  5. Exportar o HTML gerado e hospedar como página estática, já que não há dependência de servidor nem de build

O post não traz o código-fonte completo do artifact, só a descrição e o resultado, então o trecho abaixo é uma reconstrução do tipo de lógica que o Sobel exige, não uma transcrição do código de Willison:

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

javascript
function sobel(pixels, width, height) {
  const gx = [-1, 0, 1, -2, 0, 2, -1, 0, 1];
  const gy = [-1, -2, -1, 0, 0, 0, 1, 2, 1];
  const edges = new Float32Array(width * height);
  for (let y = 1; y < height - 1; y++) {
    for (let x = 1; x < width - 1; x++) {
      let sx = 0, sy = 0, i = 0;
      for (let dy = -1; dy <= 1; dy++) {
        for (let dx = -1; dx <= 1; dx++) {
          const idx = (y + dy) * width + (x + dx);
          sx += pixels[idx] * gx[i];
          sy += pixels[idx] * gy[i];
          i++;
        }
      }
      edges[y * width + x] = Math.sqrt(sx * sx + sy * sy);
    }
  }
  return edges;
}

Em cima desse mapa de bordas, a parte "pincel simulado" do prompt pede uma segunda camada: um loop que desenha pequenos traços (ctx.lineTo, ctx.stroke) seguindo as regiões de maior gradiente, espaçados no tempo com requestAnimationFrame para dar a sensação de pintura acontecendo aos poucos, em vez de a imagem aparecer pronta de uma vez.

Onde a mágica esbarra: o que Willison não mostrou

O post de Willison é um registro curto: ele publica o prompt, descreve o resultado em uma frase e cita a técnica (Sobel) usada. Não há link para o artifact ao vivo, nem código publicado, nem medição de tempo real de execução: a promessa de "alguns segundos" vem do próprio prompt, não de um benchmark que ele tenha rodado e reportado.

Isso importa para quem for reproduzir o fluxo. Sobel em JavaScript puro, pixel a pixel, sem WebGL nem Web Workers, tende a pesar em fotos de alta resolução ou em celulares mais fracos. Não há garantia na fonte de que o artifact escala além da demo original, nem de que o resultado visual é consistente entre fotos diferentes, como um retrato contra uma paisagem com pouco contraste.

Outro ponto que fica de fora: o prompt não especifica paleta de cores, estilo de traço nem resolução de saída, decisões que o Opus 5.5 tomou sozinho e que Willison não documentou. Reproduzir o experimento com o mesmo prompt pode gerar um resultado visualmente diferente a cada execução, porque o modelo preenche essas lacunas de um jeito novo toda vez.

Pra quem vale a pena (e pra quem não)

Esse tipo de combinação vale para prototipagem rápida: testar uma ideia de filtro de imagem, demonstrar um algoritmo clássico de visão computacional (o próprio Sobel é conteúdo de curso introdutório de processamento de imagem) ou gerar um protótipo visual sem montar projeto, sem bundler, sem instalar nada.

Não vale como caminho para produção. Quem precisa de processamento de imagem em escala, com performance previsível e cross-browser garantida, vai querer WebGL via shaders ou WebAssembly, não um canvas 2D rodando Sobel pixel a pixel gerado por um LLM↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → numa sessão só. Também não serve a quem precisa auditar o código: sem o fonte publicado, não dá para saber que decisões de implementação o Opus 5.5 tomou, nem revisar a qualidade do que Willison só descreveu pelo resultado visual.

Fonte: Simon Willison

Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.

Alan AndradeColunista

Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.

Mais de Alan Andrade
Ver perfil →
Leia também