Amor pelo processo: por que justificar antes de codificar é essencial para designer-developers

O que parece um exercício de disciplina é, na verdade, uma defesa contra a IA: ferramentas como Claude Code e Cursor aceleram tanto a construção que um enquadramento fraco vira um 'erro rápido e escalável'. Em 2026, mais de 80% dos devs já usam IA diariamente, mas nenhuma delas sabe o que justifica uma animação no Search Assist. O write-first design não é sobre escrever antes de desenhar ou codar. É sobre forçar o designer-developer a articular, em prosa simples, por que um usuário precisa ver aquela transição, e o que muda no comportamento dele se ela for removida.

Essa escrita expõe o que protótipos rápidos escondem: lacunas lógicas, suposições não testadas, e a confusão entre 'é bonito' e 'resolve algo'. Como mostrou o diretor do Slack em nosso artigo de 9 de junho, até IA-assistida, a prototipagem só vale se vier *depois* da decisão, não para ilustrar, mas para validar. O documento de design, então, deixa de ser um artefato final e vira um rastreador de intenção: cada parágrafo é uma âncora contra a deriva técnica.

A cobertura anterior tratava write-first como prática de design (2026-06-11) ou validação pré-código (2026-06-09), mas sempre com foco em equipes separadas ou em etapas isoladas. Agora, o artigo atual radicaliza: a regra aplica-se *individualmente* ao designer-developer, sem handoff, sem checkpoint externo, sem escapatória. A mudança não é conceitual, mas operacional: o 'porquê' agora precisa vir *antes de qualquer linha executável*, mesmo que a IA gere código em segundos. Isso transforma o documento de design em um contrato consigo mesmo, não mais um alinhamento com colegas, mas um teste de integridade profissional.

Equipes gastam 10, 20 horas semanais em retrabalho causado por ineficiências em sistemas de design, muitas vezes por decisões tomadas no Figma sem raciocínio explícito. Quando a IA reduz o tempo de codificação em até 55,8%, essa fricção não some: ela se desloca para o pensamento. Justificar antes de construir não atrasa o time. Ela evita que metade do sprint seja gasta defendendo animações que ninguém notou, e que, como no caso do Search Assist, não moveram nenhuma métrica. É a única forma de garantir que o prazer de construir e o valor de entregar sejam a mesma coisa.