Três semanas atrás eu estava olhando uma página do Notion às dez e meia da noite. Um cliente tinha enviado um briefing para uma plataforma de agendamento personalizada. O briefing tinha quatro pontos de bala e um emoji. Literalmente só: "como Calendly mas para tosadores de cães 🐶". Era só isso. Sem fluxos de usuário. Sem casos extremos. Sem ideia se eles queriam um SaaS ou uma instalação de um único inquilino. E precisavam de uma spec até sexta.
Eu costumava temer esses momentos. Agora quase fico ansioso por eles.
Porque construí um fluxo em torno do Claude que transforma esse tipo de caos em uma spec estruturada e defensável em poucas horas. Refinei isso em talvez 40 projetos na Seahawk no último ano e meio, e me salvou de pelo menos três reescritas do tipo "mas eu achava que faria X" que teriam custado dinheiro real.
Deixa eu te guiar por isso direito.
---
Por Que um Briefing Vago é Na Verdade um Bom Ponto de Partida
A coisa sobre briefings vagos é: eles contêm sinal. A coisa do Calendly para tosadores te diz indústria, produto de comparação, e escala implícita (pequeno negócio, não enterprise). Isso não é nada.
O erro que costumava fazer era tentar imediatamente detalhar o briefing por conta própria. Eu faria suposições, as colocaria em um documento, e depois um cliente assinaria algo que era 40% meus palpites. Isso é um desastre esperando para acontecer.
Claude não tem esse problema. Ele pergunta. Ou melhor, quando você o prompta corretamente, ele gera as perguntas que você deveria ter feito.
Meu primeiro movimento em qualquer novo projeto é colar o briefing bruto no Claude e pedir para ele identificar cada suposição que eu teria que fazer para construir a coisa. Não features. Suposições. O resultado geralmente é 15-25 perguntas, e cerca de um terço delas são coisas que eu teria passado por cima.
Para o projeto dos tosadores de cães, Claude trouxe à tona coisas como: o tosador tem múltiplos funcionários, ou é uma operação solo? O agendamento precisa levar em conta o tamanho do pet afetando a duração do compromisso? Há um depósito ou captura de pagamento no momento do agendamento? Eu não tinha pensado na coisa do tamanho do pet. Nem o cliente, como se revelou. Pegamos isso na chamada de descoberta em vez da sprint três.
---
A Estrutura de Prompt Que Realmente Funciona
Tentei muitos jeitos diferentes de fazer prompt para trabalho de spec. Coisas genéricas como "me ajude a desenhar um app de agendamento" te dá lixo genérico. O que funciona é um input estruturado que dá ao Claude contexto suficiente para restringir sua saída.
Aqui está o template grosseiro que uso agora:
- Definição de papel. Digo ao Claude que ele está agindo como um gerente de produto sênior que já entregou B2B SaaS antes e é alérgico a scope creep.
- Briefing bruto. Cole verbatim, porém rústico seja.
- Restrições. Faixa de orçamento, tech stack se conhecido (usamos WordPress/WooCommerce por padrão para a maioria dos sites de clientes, Laravel personalizado para qualquer coisa mais pesada), timeline, tamanho do time.
- Formato de saída. Peço um documento estruturado com seções específicas: declaração do problema, personas de usuário, fluxos de usuário centrais, lista de features (MVP vs. pós-lançamento), perguntas em aberto, e riscos.
A parte de restrições é o que a maioria das pessoas pula. Importa enormemente. "Orçamento: £8.000, timeline: 8 semanas, dois desenvolvedores e um designer part-time" produz uma spec muito diferente do mesmo briefing sem restrições. Sem elas, Claude vai alegremente especificar um produto que levaria seis meses e £60k para construir. O que é legal de ler e inútil para entregar.
---
Iterando na Especificação com Prompting Adversarial
Conseguir um rascunho inicial da especificação é a parte fácil. O valor real está na iteração.
Depois que o Claude produz o documento inicial, faço o que chamo de uma passada adversarial. Literalmente peço a ele: "Agora argumente contra essa especificação. Onde o escopo ampliado é mais provável de acontecer? O que subestimamos? Qual feature dessa lista vai causar mais débito técnico em 12 meses?"
A Seahawk tinha um cliente fintech em 2022 que queria um dashboard para rastrear portfólios de micro-investimentos. A especificação inicial parecia sólida. A passada adversarial sinalizou que a feature "atualizações de preços em tempo real" no MVP estava fazendo muito trabalho pesado e provavelmente exigiria uma arquitetura WebSocket que nosso timeline e orçamento não consideravam. Pegamos. Reduzimos para polling a cada 60 segundos no MVP, com tempo real como feature da fase dois. Cliente aceitou. Teríamos detectado sem a passada adversarial? Talvez. Mas provavelmente não até alguém estar três semanas no desenvolvimento.
O passo adversarial adiciona talvez 20 minutos ao processo. Vale a pena toda vez.
---
Traduzindo Especificação em User Stories
Quando a especificação está sólida o suficiente para não me envergonhar dela, passo para a geração de user stories. É aqui que o Claude realmente brilha, porque escrever boas user stories é tedioso e fácil de fazer mal.
Alimentei a especificação de volta ao Claude e peço por user stories no formato padrão: "Como [papel], eu quero [ação] para que [resultado]." Também peço para ele sinalizar critérios de aceitação para qualquer coisa não-trivial, porque "como um organizador eu quero bloquear tempo de férias" tem um número surpreendente de casos extremos (blocos recorrentes? qual timezone? isso notifica clientes com agendamentos existentes?).
Algumas coisas que insisto:
- As histórias devem ser escritas para uma persona específica, não um "usuário" genérico
- Cada história recebe uma estimativa de complexidade aproximada (P/M/G, nada mais granular que isso nesta fase)
- Qualquer coisa no bucket "G" é sinalizada para decomposição adicional antes de ir para Jira
Esse último ponto importa. Uma história G em uma reunião de planejamento de sprint é basicamente uma granada. Conseguir Claude para surfacear isso cedo significa que temos uma conversa antes de alguém começar a construir.
---
Onde Defino o Limite com o Claude
Quero ser honesto sobre isso, porque vejo muitas análises entusiasmadas sobre IA fazendo tudo agora.
Claude não é bom em decidir coisas. É excelente em expor opções e trade-offs, mas a decisão real sobre se construir um sistema de notificação customizado ou usar Novu (que usamos em três projetos agora e recomendaríamos) ainda exige alguém que conhece o projeto, o cliente e as capacidades do time.
Também achei que não é confiável em nada envolvendo versões específicas de biblioteca ou comportamentos de API nicho. Para discussões amplas de arquitetura é ok. Para "essa versão específica do WPGraphQL vai lidar com esse padrão de query específico sob carga," prefiro testar do que confiar.
E honestamente? O próprio prompting exige skill. Um júnior no meu time tentou usar o mesmo workflow e recebeu especificações mediocres de volta, porque o framing de constraint e role não era apertado o suficiente. A ferramenta amplifica quem a usa. Não é uma crítica, apenas vale a pena ser realista sobre isso.
---
Organizando a Saída em um Documento Vivo
A especificação que Claude produz não é o artefato final. É input.
Meu deliverable real para um cliente é um documento Notion que é construído a partir do output do Claude mas reorganizado em um formato que faz sentido para sign-off. Tipicamente:
- Resumo executivo (3-4 sentenças, sem jargão)
- Escopo (o que está dentro, o que está explicitamente fora)
- Personas de usuário (2-3 no máximo, mais que isso é ruído nesta etapa)
- Fluxos principais (escritos como passos numerados, não prosa)
- Tabela de features (colunas: feature, MVP ou fase 2, esforço aproximado, responsável)
- Perguntas em aberto (tudo aquilo que bloqueia uma decisão, com uma pessoa nomeada responsável por respondê-la)
- Riscos e mitigações
Essa seção de perguntas em aberto é algo que comecei a fazer depois que um projeto em 2020 saiu dos trilhos porque todo mundo assumiu que alguém já tinha resolvido a política de retenção de dados. Nomear uma pessoa contra cada pergunta em aberto significa que isso não fica ali indefinidamente.
O documento do Notion é compartilhado com o cliente, ele comenta diretamente nele, e fazemos uma chamada de 45 minutos para passar por tudo. Nada vai para um desenvolvedor até que cada pergunta em aberto tenha uma resposta.
---
The Actual Time Savings, Honestly Stated
Antes deste workflow, uma especificação para um projeto de complexidade média (digamos, um portal de membros ou um build de e-commerce customizado) me levava um dia e meio. Escrever, questionar a mim mesmo, reescrever. Enviar um rascunho para um colega, receber comentários, incorporá-los.
Agora são mais próximos de duas a três horas para o rascunho assistido por Claude, depois talvez mais uma hora de edição humana e polimento para o cliente. No total, três a quatro horas.
Isso não é uma economia trivial ao longo de um ano. Na Seahawk estamos entregando specs em talvez dois ou três projetos por mês. Mesmo numa estimativa conservadora, são 50-70 horas por ano que não estou gastando escrevendo specs de primeira versão do zero.
Mas o ganho maior, honestamente, é qualidade. A passagem adversarial em particular pega coisas que eu teria perdido. O surfacing de suposições no começo significa que as chamadas de discovery são mais produtivas porque estamos discutindo decisões reais, não eu me esforçando para preencher lacunas que não tinha notado.
---
FAQ
Este workflow funciona para ferramentas internas tanto quanto para projetos de cliente?
Sim, e às vezes funciona melhor para coisas internas porque você conhece o usuário melhor do que qualquer briefing de cliente pode dizer. Usei essencialmente o mesmo processo quando estávamos especificando a própria ferramenta de rastreamento de tempo interna da Seahawk no ano passado. A entrada de constraint foi fácil porque eu conhecia o orçamento (£0 em despesas externas, um desenvolvedor, três semanas) e as personas eram literalmente pessoas do escritório.
Um founder não-técnico consegue usar isto sem um desenvolvedor?
Até certo ponto. Os passos de surfacing de suposições e user story funcionam bem sem conhecimento técnico. Onde fica complicado é na passagem adversarial e na estimativa de esforço. Você precisa de alguma experiência para saber quando Claude está subestimando a complexidade. Se você é não-técnico, faça esse passo com alguém que já entregou software antes, mesmo que seja só uma chamada de uma hora.
Como você lida com informações confidenciais de cliente quando usa Claude?
Eu anonimizo tudo que é sensível antes de entrar no prompt. Nomes de cliente viram "[Client]", qualquer dado de identificação pessoal é removido. Eu também uso Claude via API para qualquer coisa genuinamente sensível, onde os termos de tratamento de dados empresariais da Anthropic se aplicam, em vez do produto de consumidor. Vale a pena ler a política de uso da Anthropic antes de você decidir o que é apropriado para seu contexto.
A spec sempre sobrevive ao primeiro contato com desenvolvedores?
Não. E não deveria. A spec é uma função de forcing para ter as conversas certas cedo, não um contrato que congela o pensamento. O que digo aos clientes é: a spec é um entendimento compartilhado do que estamos construindo hoje. Isso vai mudar. O que faz é tornar essas mudanças visíveis e deliberadas em vez de acidentais.
---
Uma spec não é um documento. É um argumento. Você está argumentando que entende bem o suficiente o problema para construir algo que vale a pena construir. Claude não faz esse argumento por você. Mas é um parceiro de sparring notavelmente útil enquanto você descobre o que realmente quer dizer.
Isso vale duas horas do tempo de qualquer pessoa.