Design-First: O Protocolo Que Falta na Sua Colaboração com IA

TV
Thiago Victorino
9 min de leitura
Design-First: O Protocolo Que Falta na Sua Colaboração com IA
Ouvir este artigo

Peça a um assistente de IA para construir um serviço de notificações. Em segundos, ele entrega código funcional. Escolheu BullMQ como fila. Definiu três tentativas com backoff exponencial. Criou um endpoint REST. Tudo compila. Tudo parece correto.

O problema: você não tomou nenhuma dessas decisões. A IA tomou por você. Silenciosamente. Embutidas no código que apareceu pronto na tela. Escopo do serviço, limites de componentes, fluxo de dados, tratamento de erros. Cada uma é uma decisão arquitetural. Cada uma foi resolvida sem consulta.

Rahul Garg, engenheiro principal da Thoughtworks, publicou no site de Martin Fowler um padrão que ataca esse problema diretamente. Ele chama de Design-First Collaboration. A premissa é simples: nenhum código até que o design esteja aprovado.

A Armadilha da Implementação

O pipeline tradicional de software tem estágios distintos: pensar, projetar, codificar. Você pode questionar se esses estágios são sempre lineares, mas eles existem como atividades separadas. A IA de codificação colapsa os três em um único passo. Você descreve uma intenção. O código aparece.

Garg chama isso de “Armadilha da Implementação.” O nome é preciso. A IA não pula o design. Ela toma decisões de design e as esconde dentro do código. O humano descobre a governança depois do fato, quando já é tarde para mudar sem custo.

Os dados confirmam que isso é um problema real, não teórico. A Ox Security analisou projetos em 2025 e encontrou anti-padrões em código gerado por IA em 80% a 100% dos casos. O Gartner projeta que 75% dos líderes de tecnologia enfrentarão débito moderado ou severo de codificação acelerada por IA até 2026. E 41% de todo código novo globalmente já é gerado por IA.

Como exploramos em Quando a Especificação É o Produto, Quem Governa a Especificação?, o Spec-Driven Development acelerou ciclos de PM, mas transferiu o risco para a especificação. Design-First ataca o mesmo problema por outro ângulo: em vez de governar a spec, governa a conversa entre humano e IA antes que qualquer código exista.

Cinco Níveis, Um Princípio

O framework de Garg tem cinco níveis que espelham o que duas pessoas fariam num quadro branco antes de escrever código:

Nível 1: Capacidades. O que o sistema precisa fazer? Apenas funcionalidades e requisitos de alto nível. Nada sobre como.

Nível 2: Componentes. Quais são as partes do sistema? Nomes, responsabilidades, fronteiras. Ainda sem detalhes de interação.

Nível 3: Interações. Como os componentes se comunicam? Fluxos de dados, sequência de operações, dependências.

Nível 4: Contratos. Quais são as interfaces? APIs, schemas, formatos de mensagem, tratamento de erros. Especificidade suficiente para que dois times implementem de forma independente e se integrem.

Nível 5: Implementação. Agora, e somente agora, código.

Cada nível é um portão. O humano avalia, questiona, redireciona. A IA avança para o próximo nível apenas com aprovação explícita. A restrição central é expressa em uma única frase no prompt: “não gere código até que eu aprove o design.”

Na prática, isso é um protocolo de governança. Cada nível é um ponto de decisão onde o humano retém autoridade. A IA não perde capacidade. Ganha estrutura.

O Custo de Mudar Tarde

A curva de Boehm, que mapeia o custo crescente de mudanças conforme um projeto avança, é contestada em contextos modernos de desenvolvimento ágil. Mas a IA pode estar re-intensificando esse efeito.

Quando código aparece em segundos, a tentação é aceitá-lo e seguir em frente. O custo percebido de “começar de novo” é zero: basta pedir ao agente que reescreva. Mas as decisões de design embutidas no código original já informaram testes, integrações, e expectativas da equipe. Refazer o código sem refazer o design propaga as mesmas decisões invisíveis.

Como analisamos em Dívida Cognitiva: O Custo Invisível Que Nenhum Benchmark Mede, desenvolvedores que delegam código sem investigar as decisões por trás dele pontuam abaixo de 40% em testes de compreensão. Os que usam IA para investigação conceitual pontuam 65%. Design-First força a segunda abordagem: antes de ver código, você precisa entender as decisões que o produzirão.

O estudo METR reforça esse ponto por outro caminho: desenvolvedores experientes com assistência de IA foram 19% mais lentos, mas se percebiam 20% mais rápidos. A velocidade aparente mascara retrabalho real. Separar design de implementação torna o retrabalho visível antes que ele aconteça.

O Template de Prompt É a Contribuição Real

A análise acadêmica do framework é interessante. A contribuição prática é outra: o template de prompt.

Garg oferece um prompt que instrui a IA a seguir os cinco níveis em sequência, sem avançar sem aprovação. É uma única restrição inserida no início da conversa. Não requer infraestrutura, configuração, ou mudança de ferramenta. Funciona em qualquer assistente de IA baseado em chat.

Isso importa porque reduz a barreira de adoção a zero. A maioria dos frameworks de governança exige investimento em processos, ferramentas, treinamento. Esse exige copiar um parágrafo.

Três padrões companheiros complementam o Design-First dentro da mesma série de Garg: Knowledge Priming (carregar contexto estático do projeto antes da conversa), Context Anchoring (manter registros persistentes das decisões tomadas), e o próprio Design-First como portão de decisão. Juntos, formam uma stack mínima de governança para colaboração com IA.

O Elefante na Sala: IA Agêntica

Aqui está a limitação que o artigo de Garg não endereça.

Design-First foi concebido para pair programming baseado em chat. Um humano conversa com um agente. O agente responde. O humano avalia. Roda após roda, nível após nível.

A indústria está migrando para outro modelo. Agentes autônomos que operam em pipelines orquestrados, executam múltiplas tarefas em paralelo, e tomam decisões sem esperar aprovação humana para cada passo. Como analisamos em De In-the-Loop para On-the-Loop, empresas no percentil 95 de entrega não revisam cada diff. Projetam sistemas de validação que operam sem intervenção constante.

Nesse contexto, um framework baseado em aprovação nível a nível é insuficiente. Não porque esteja errado, mas porque não escala. Um engenheiro operando cinco agentes em paralelo não pode conduzir cinco sessões de design-first simultâneas.

A resposta provável é embutir o protocolo de design-first no próprio pipeline agêntico. O agente arquiteto define capacidades e componentes. O agente de contratos especifica interfaces. O agente de implementação codifica dentro dos limites definidos. Os portões de aprovação viram checkpoints automatizados, não conversas humanas.

Garg reconhece que não trata de IA agêntica. Essa honestidade é válida. Mas quem adota o framework hoje precisa saber que ele resolve o problema de ontem (pair programming com chat) melhor do que resolve o problema de amanhã (orquestração multi-agente).

O Que Levar Daqui

Design-First não é overhead de processo. É a forma mais barata de governança de IA disponível hoje. Um parágrafo no início de um prompt que força separação entre pensar e codificar.

Para quem opera no modelo de chat com assistentes de código, o framework de cinco níveis oferece estrutura imediata. Para quem já migrou ou está migrando para agentes autônomos, o princípio permanece válido mesmo que a implementação precise mudar: decisões de design devem ser explícitas, documentadas, e aprovadas antes que código exista.

Como argumentamos em Design Sem Governança É Decoração, design sem infraestrutura de governança é apenas aparência. O framework de Garg transforma esse princípio em ação concreta: um protocolo que qualquer desenvolvedor pode adotar hoje, sem investimento, sem ferramenta nova, sem aprovação de ninguém.

A restrição é o recurso. “Não gere código até que eu aprove o design” é uma frase. Também é um sistema de governança.


Fontes


A Victorino ajuda organizações a construir infraestrutura de governança para sistemas de IA, de protocolos de design a monitoramento em produção: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa