1. O problema que o Paper veio resolver
2. O que é o Paper e como ele funciona
3. Por que o canvas morreu — e por que está ressuscitando
4. A armadilha da slot machine: quando a execução fica barata demais
5. Design e código no mesmo material
6. O que as empresas precisam entender sobre esse movimento
Primeiro o vibe-coding chegou e reorganizou o ciclo de desenvolvimento de software. Depois vieram ferramentas que comprimiram o fluxo de design de produto em minutos. Agora, uma pergunta mais profunda está tomando forma: como pensar espacialmente quando os agentes executam cada vez mais rápido? O Paper, ferramenta lançada em fevereiro de 2026, propõe uma resposta: um canvas conectado a código, a dados e a agentes de IA — construído na mesma linguagem que o produto final.
O Paper não é mais um aplicativo de design. É uma aposta de que o canvas é o lugar certo para os humanos fazerem o que os agentes ainda não conseguem: segurar ambiguidade, comparar caminhos e decidir o que importa. E enquanto o mercado debate se designers deveriam saber programar ou se engenheiros deveriam revisar código, o Paper sugere que a pergunta errada está sendo feita.
Para times de produto, inovação e tecnologia, entender o que o Paper representa é entender onde a criação de software está indo — e o que muda para quem precisa construir coisas que humanos vão usar.
Durante quase duas décadas, o design de produto e o desenvolvimento de software viveram em universos paralelos. O designer desenhava telas em Figma ou Sketch. O engenheiro recebia esses arquivos e recodificava tudo do zero. O resultado quase nunca era idêntico ao mock — e esse ‘drift’ entre intenção e implementação virou custo invisível em todo time de produto.
Com a chegada dos agentes de IA, esse problema não desapareceu: ele se agravou. Os agentes conseguem gerar código rapidamente, mas operam dentro de um repositório, sem visão do conjunto. Um chat não consegue segurar múltiplas versões de uma interface lado a lado. Um log de conversa não substitui a capacidade de observar dois caminhos ao mesmo tempo e escolher o melhor.
Nesse cenário, o canvas ganhou um papel novo — não o de ferramenta de desenho, mas de superfície de raciocínio espacial. O Paper foi criado exatamente para ocupar esse espaço.
O Paper é um aplicativo desktop de canvas construído sobre padrões web — HTML, CSS e DOM. Isso significa que o que você vê no canvas não é uma representação visual do seu produto: é o produto em si. Componentes React podem ser importados, APIs podem ser consultadas diretamente na tela e o ambiente local pode ser conectado via MCP servers.
A arquitetura do Paper tem três movimentos centrais. O primeiro é a conexão bidirecional com o código: é possível puxar uma seção do aplicativo real para o canvas, iterar visualmente com ou sem ajuda de agentes, e enviar as decisões de volta para o repositório como código — não como uma imagem de uma mudança, mas a mudança em si.
O segundo é a integração com agentes. Por ser um app desktop, o Paper suporta MCP servers, o que permite que modelos de linguagem acessem arquivos locais, conectem com repositórios e interajam diretamente com o canvas. Qualquer agente — Cursor, Claude Code, Codex — pode ler e escrever HTML no Paper.
O terceiro é o suporte à exploração: tela infinita, múltiplas versões lado a lado, manipulação direta de elementos. O tipo de raciocínio que um chat nunca vai conseguir oferecer.
O canvas perdeu terreno na produção por um motivo simples: abstração. Ferramentas como Figma e Sketch eram, nas palavras dos criadores do Paper, “belas mentiras”. O designer desenhava uma representação visual de um div, não o div em si. No momento em que o primeiro commit era feito, o design morria.
O código venceu não porque era melhor para pensar, mas porque era o único artefato que sobrevivia ao processo de implementação. Com isso, o canvas ficou confinado à fase de exploração — válido para descoberta, irrelevante para entrega.
O Paper muda essa equação ao construir o canvas sobre os mesmos padrões do produto. Quando a superfície de design e a superfície de código são feitas do mesmo material, o artefato de design não precisa mais ser ‘traduzido’. Ele já é o produto.
Um dos pontos mais provocativos do manifesto do Paper é o que seus criadores chamam de “armadilha da slot machine”: o reflexo de prompt → esperar → output → repetir. O ciclo é rápido e gera resultados. Mas, ao mesmo tempo, favorece pular a fase espacial do raciocínio — a fase onde múltiplas direções ficam visíveis ao mesmo tempo e onde as decisões mais importantes são tomadas.
Quando a execução fica barata, o gargalo sobe de nível. Deixa de ser sobre quem escreve código mais rápido e passa a ser sobre quem consegue manter contexto e coerência através de decisões complexas. O designer sênior ou o arquiteto de produto que consegue segurar um sistema inteiro na cabeça, comparar caminhos e decidir o que importa se torna o recurso escasso — não a mão de obra de execução.
Em contrapartida, profissionais cujas funções se concentram em tarefas operacionais repetitivas — wireframing de baixa fidelidade, montagem mecânica de telas, ajustes responsivos — enfrentam uma pressão diferente. Essas tarefas são exatamente aquelas que os agentes já executam com eficiência crescente.
A aposta central do Paper é que a separação entre design e implementação é, em grande parte, um artefato histórico — não uma necessidade estrutural. O canvas tradicional falhou na produção porque escolheu uma linguagem própria (camadas, componentes abstratos) em vez da linguagem do produto (HTML, CSS, DOM). O Paper elimina essa escolha.
Quando o canvas fala a mesma língua que o código, os modelos de linguagem conseguem conectar os pontos sem drift. Agentes podem puxar dados reais, conectar a APIs e ler o ambiente local. A especificação deixa de ser um documento estático e se torna um artefato vivo — o que os criadores do Paper chamam de “living spec”: uma superfície onde design, código e dados convivem no mesmo lugar.
Além disso, o formato DESIGN.md — padrão de transferência de arquivos entre ferramentas — representa uma tentativa de criar um protocolo comum para esse fluxo bidirecional. É uma ideia jovem, mas que aponta para onde o ecossistema de ferramentas está indo: interoperabilidade entre canvas e codebase como padrão, não como exceção.
O Paper não é apenas uma ferramenta nova para designers. É um sinal de uma reconfiguração mais ampla em como software é criado — e de onde o valor humano se concentra nesse processo. As empresas que entenderem essa mudança antes das outras vão conseguir estruturar times, fluxos e ferramentas de forma mais eficiente.
O primeiro ponto é sobre papéis: a distinção rígida entre ‘designer’ e ‘engenheiro’ está se tornando menos relevante do que a distinção entre ‘quem decide’ e ‘quem executa’. Com agentes acelerando a execução, a escassez se desloca para quem consegue manter coerência sistêmica, comparar alternativas e tomar decisões de produto com qualidade.
O segundo ponto é sobre ferramentas: adotar ferramentas que reduzem o drift entre design e código não é apenas uma decisão de produtividade — é uma decisão de qualidade. Produtos construídos com menos drift entre intenção e implementação têm mais chance de funcionar bem para quem vai usá-los.
Em suma, o Paper representa o canvas amadurecendo para um papel que ele nunca conseguiu ocupar antes: não só explorar, mas também entregar. Para líderes que precisam estruturar como seus times constroem software na era dos agentes, o momento de mapear essa transição é agora. Conheça o AI Strategy do Distrito e entenda como definir prioridades, governança e roadmap para que sua organização capture o valor dessa nova geração de ferramentas.
