A ideia central da palestra é simples de enunciar e difícil de praticar: especificar antes de codar, sempre da esquerda para a direita — negócio, abstração, execução, validação e release, em loop fechado. Para isso, o palestrante apresentou o SPDD (Structured-Prompt-Driven Development), projeto open source ligado ao trabalho da ThoughtWorks e a Martin Fowler, disponível como CLI (linha de comando), nos moldes do Claude Code, Codex ou Copilot.
O fluxo tem seis passos, todos executados por comandos da própria ferramenta:
- Criar requisitos seguindo o princípio INVEST;
- Validação humana da lógica central e do escopo;
spdd analyse-context, que varre lacunas nos requisitos;spdd prompt-gen, que monta um prompt estruturado usando a estratégia REASONS e gera o arquivo Markdown versionável — o artefato central da metodologia;spdd code-gen, que gera o código a partir dessa especificação;spdd test-gen, que gera os casos de teste.
O ponto que o palestrante chamou de "regra de ouro" é a disciplina de atualização:
"Sempre quando a realidade divergir, você volta para o prompt."
Quando um ajuste emergencial obriga a mexer direto no código (o "hotfix de incêndio"), existe o comando spdd sync, que reconcilia código e documento — um handshake bidirecional que a apresentação batizou, citando a especialista da ThoughtWorks Birgitta, de Spec Anchorage.
Três habilidades foram listadas como pré-requisito para adotar o método: desenhar antes de gerar, travar a intenção antes do código ("porque o modelo alucina") e revisar interativamente o arquivo de prompt a cada mudança. Como retorno, o palestrante citou determinismo — menos alucinação e menos interpretação divergente — e rastreabilidade de decisões. Como custo, apontou a mudança de mindset e a necessidade de um tech lead ou arquiteto acompanhando, já que o documento mistura requisitos de negócio e técnicos. Já em cenários de correção urgente, a recomendação foi direta: não tentar seguir o processo completo.
Nas perguntas da plateia, dois pontos práticos se destacaram. Sobre como organizar os arquivos, a orientação foi granularizar por feature, criando interdependência explícita entre os documentos. Sobre integração com QA usando Gherkin e Robot Framework, o palestrante considerou viável, "desde que bem escrito e bem definido". Já sobre o problema de handoff entre janelas de contexto de agentes — perder trabalho ao trocar de sessão —, a resposta foi honesta:
"Confesso para você que em estruturas maiores surgiu esse problema da troca do contexto entre as janelas [...] não é uma bala de prata."
A mensagem final resumiu o tom pragmático da sessão: teste o método, e se não resolver seu problema, tente outro.