Durante mais de uma década, o processo de construção de software seguiu um ritual: designer cria no Figma, engenheiro implementa no código, ambos esperam que o resultado seja fiel ao original. Raramente era. O Paper, lançado em fevereiro de 2026, parte de uma premissa diferente: design e código são feitos do mesmo material.
O que o Paper muda
Paper é uma aplicação desktop onde o artefato de design e o código coexistem no mesmo ambiente. Não é um plugin do Figma que gera código. Não é um editor de código com preview visual. A implementação técnica usa HTML, CSS e DOM nativos como substância. APIs e ambientes locais são conectados via MCP (Model Context Protocol).
O formato DESIGN.md
O DESIGN.md é a especificação viva do produto — um documento único onde design, código e dados coexistem e se atualizam juntos. O problema histórico era o drift: a especificação no Figma ficava desatualizada enquanto o código avançava. O DESIGN.md resolve isso tornando o arquivo de design e o código a mesma coisa.
O impacto na organização do trabalho
Quando a execução fica barata — quando gerar uma tela funcional é questão de minutos, não dias — o gargalo sobe para onde ele sempre deveria estar: decisão estratégica. O que construir? Para quem? Por quê? Com quais trade-offs?
A distinção entre designer e engenheiro perde relevância operacional. O que decide, o que entende o produto, o que faz as escolhas corretas de UX e arquitetura — esse é o perfil que cria valor.
O que isso significa para empresas que desenvolvem produto
Times que ainda estruturam seu processo em silos (design aqui, código ali, QA depois) vão enfrentar atrito crescente conforme ferramentas como Paper normalizam o fluxo integrado. A pergunta relevante não é se devem usar Paper. É se o processo de construção de produto está adaptado para um mundo onde design e código são o mesmo material.
Pronto para implementar IA de verdade?
A KTANA transforma pilotos em sistemas que operam em produção.
