Spec Driven Development é a prática fundadora da engenharia Amazing. Toda feature começa com intenção, contratos e critérios de aceite versionados. O código vira consequência da spec, não aposta no que o prompt vai entender. Resultado: entregas previsíveis, sprint após sprint, com a mesma qualidade.
Quando a intenção não está escrita, cada pessoa interpreta o pedido do jeito que entende. Quando o agente é instruído por prompt solto, ele devolve o que parece plausível. Quando a spec aparece só depois do código, serve pra justificar o que foi feito, não pra guiar o que será construído.
O resultado: retrabalho descoberto tarde, casos de borda esquecidos, critério de aceite renegociado sprint a sprint. O time fica rápido em hit-and-miss, mas a entrega oscila em qualidade e o custo de manutenção cresce mais rápido que o produto.
Spec Driven Development muda a origem do ciclo. Em vez de interpretar, você executa. Em vez de adivinhar, o agente lê. Em vez de descobrir tarde, você decide antes.
Duas horas com product, engineering e quem vai usar o que está sendo construído. Saímos com objetivo mensurável, restrições de negócio e critério de sucesso escrito.
O sênior escreve o primeiro rascunho: intenção, fluxos, contratos de API, regras de negócio, casos de borda, comportamento em erro. QMD porque a spec vai rodar: exemplos viram testes, contratos viram validação automática.
A spec entra no repositório do projeto como qualquer outro artefato. Revisão por Pull Request, aprovação documentada, histórico versionado. Mudança posterior exige PR novo.
Os agentes Amazing leem a spec no início de cada task e executam contra ela. Testes nascem do mesmo artefato. Documentação acompanha sem esforço extra. O PR de implementação cita a seção da spec que cumpriu.
# Spec · Pix Automático # Versão 1.2 · aprovada 2026-04-07 intent: "Permitir agendamento recorrente de transferências Pix" contracts: post /pix/automatico body: pagador: CPF | CNPJ recebedor: ChavePix valor: decimal > 0 frequencia: daily | weekly autorizacao: token JWT returns: 201 → { id, status: "ativo" } 400 → validação falha 409 → já existe agendamento rules: ✓ rate limit 10/min por pagador ✓ pré-autorização expira em 180d ✓ audit trail obrigatório ✓ notifica pagador 24h antes acceptance: ✓ cria, cancela, consulta ✓ trata saldo insuficiente ✓ idempotente por chave ✓ BACEN compliance ok
SDD não é refino técnico. É o que faz prazo virar compromisso defensável, retrabalho virar exceção e onboarding parar de custar semanas.
mais output por sprint comparado a ciclos sem spec formal.
das features precisam de segundo ciclo por ambiguidade.
das features nascem testáveis e auditáveis por design.
para novos membros entenderem decisões e estado do projeto.
SDD é público, a ideia não é nossa. O que diferencia a Amazing é a combinação: spec como QMD executável, vault por cliente, harness que bloqueia divergência, squad dedicada orquestrando agentes que respeitam o contrato.
Nossa spec é QMD executável. Exemplos viram testes, contratos viram validação automática. Spec desatualizada quebra a build.
Se o código foge da spec, o hook barra o merge antes do humano olhar. Guardrail em runtime, não dependência da boa vontade.
Cada spec aprovada fica linkada ao vault do cliente. A próxima feature já nasce com contexto carregado.
Pix Automático entregue em um mês com cem por cento de cobertura e zero ponto aberto pelo BACEN. A spec foi o artefato que sustentou o prazo.
Ver o caso completoEm 30 minutos a gente monta o rascunho de uma spec em cima de uma feature sua. Você sai com o artefato no formato Amazing mesmo que não feche contrato.
