Custo de prototipagem desmonta o Double Diamond e valoriza o julgamento

O que quebrou no Double Diamond

O autor Patrick Neeman argumenta que o Double Diamond (lançado pelo Design Council em 2004) e o design thinking defendido por Tim Brown na Harvard Business Review em 2008 foram construídos sobre uma relação de custos que não existe mais: pesquisa e exploração eram baratas, e construir era caro, lento e quase irreversível. Por isso, o processo gastava horas baratas (pesquisa, journey maps, artefatos) para proteger horas caras (o build).

Ele traça a linhagem do design thinking até Herbert Simon, em The Sciences of the Artificial (1969), passando por Robert McKim, Rolf Faste, Peter Rowe e David Kelley no IDEO. O ponto em comum: engenharia, administração, engenharia mecânica e arquitetura - todos faziam coisas lentas, caras e difíceis de reverter, e nenhum deles construía software. O ADDIE, criado na Florida State para o Exército dos EUA nos anos 1970, segue a mesma lógica de restrições de custo.

Os artefatos do processo - repositórios de pesquisa, declarações de problema, journey maps, PRDs - seriam, segundo Neeman, apenas 'recibos de decisão', compressões feitas porque a etapa seguinte era cara e admitia uma única tentativa. Com o custo do build desabando, esses artefatos viram documentação contra um risco que deixou de existir.

O colapso dos preços

A evidência quantitativa citada: o Stanford HAI 2025 AI Index mostrou que consultar um modelo nível GPT-3.5 caiu de US$ 20 por milhão de tokens em novembro de 2022 para US$ 0,07 em outubro de 2024 - uma queda de 280 vezes em 18 meses. O relatório DORA 2025 do Google Cloud apontou que 90% de cerca de 5.000 profissionais de tecnologia usam IA no trabalho, em mediana de duas horas por dia.

Uma solução candidata que custava um sprint agora custa um prompt e uma tarde de revisão. Nesse preço, vale construir três direções ao mesmo tempo em vez de debater qual é a certa.

A divergência não morreu; migrou para o fim do processo. O relatório de IA de 2025 da Figma, com 2.500 designers e desenvolvedores, mostrou que entre projetos de IA que atingiram ou superaram expectativas, 60% exploraram múltiplas abordagens, contra 39% dos que ficaram abaixo. O autor relata ter comprimido o design sprint de cinco dias em uma sequência sintética de 20 minutos, incluindo teste. O que sobrevive dos workshops é o alinhamento humano: onze pessoas concordando sobre o problema no mesmo room ainda não tem substituto. A descoberta também permanece, mas em cadência contínua, não monopolizando a frente.

O orçamento de julgamento

Se fazer é barato, o custo migra para decidir o que é bom. Neeman cita o experimento randomizado da METR do início de 2025: 16 desenvolvedores open-source experientes, 246 tarefas, em repositórios onde trabalhavam havia cerca de cinco anos. Eles previram ganho de 24% em velocidade; medido, as tarefas levaram 19% mais tempo. Em fevereiro de 2026, a METR reportou que os desenvolvedores que retornaram passaram a registrar cerca de 18% de aceleração. A conclusão do autor: o gargalo está em revisar o que sai, não em produzir.

Ele chama isso de 'orçamento de julgamento' - a fatia da capacidade do time gasta em decidir o que é bom. O Double Diamond assumia julgamento pequeno e produção grande; a proporção se inverteu. O risco conhecido é o automation bias: vinte opções sem padrão de avaliação não produzem vinte escolhas, mas uma, ditada por o que a ferramenta colocar primeiro.

O modelo proposto

A reconstrução: encolher o primeiro diamante para um brief de uma página, com um resultado a mover e um critério de sucesso; manter e alargar o segundo, onde vão as pessoas e o julgamento. Escrever evals como engenheiros escrevem testes - o autor compara com a prática de escrever testes antes do código quando compilação ficou rápida e deploy barato, e defende que evals são a nova especificação.

Ressalva importante: onde o build continua caro e irreversível - dispositivos médicos, rails de pagamentos, itens regulados, hardware com moldes como despesa de capital, moda com calendário de temporada - a ordem original se mantém. Mas ele adverte que a ressalva é superutilizada: a maioria do software é reversível (flag, rollback, correção na terça). 'Gravidade não é o mesmo que irreversibilidade'; o teste é se você pode desfazer dentro de um dia.

Recomendações finais

Entre as práticas listadas: escrever o padrão de qualidade antes de gerar, pesquisa em cadência semanal, critérios de avaliação na design review (com referência à tese de Torres de que evals de IA são hábito de discovery), prototipar para responder uma pergunta decisiva e rastrear por um mês a proporção entre horas de produção e horas de avaliação - se avaliação ficar abaixo de um terço, o processo ainda está precificado para 2004. A conclusão: frameworks não morrem de crítica, morrem quando os preços sob eles mudam; a etapa cara agora está no fim, e um processo que protege o começo defende algo que ninguém vai quebrar.