Uma user story bem escrita comunica intenção. Descreve quem quer o quê e sob quais condições a entrega é considerada satisfatória. Durante duas décadas, esse formato funcionou como contrato informal entre produto e engenharia porque o receptor era um desenvolvedor humano, capaz de preencher lacunas com contexto de domínio e perguntas feitas no stand-up. O formato sobreviveu não por ser preciso, mas por ser suficiente dentro de um sistema em que a ambiguidade residual era resolvida pelo time. Quando o receptor passa a ser um agente, essa ambiguidade deixa de ser resolvida. Pra mim, é amplificada.
Na minha análise, o problema não é que user stories sejam ruins. O problema é que foram desenhadas pra um canal que tolera imprecisão e compensa com interação. Um desenvolvedor que lê "como administrador, quero exportar relatórios em PDF pra compartilhar com stakeholders" sabe que precisa perguntar sobre filtros, paginação, formatação de datas, tratamento de campos vazios e permissões de acesso. Um agente que recebe a mesma story gera uma implementação que satisfaz a leitura literal da frase, e a distância entre o escrito e o esperado vira código que compila e passa em testes triviais, mas que está errado de formas que só aparecem em revisão ou em produção. O Thoughtworks Technology Radar posicionou spec-driven development no anel de Assess em 2025, o que indica reconhecimento de que o canal entre humanos e agentes precisa de uma camada adicional de formalização.
A spec executável ocupa esse espaço intermediário. Não substitui a user story, que continua sendo o artefato de captura de intenção de negócio, mas a transforma em algo que um agente consegue consumir sem compensação inferencial. Define mapeamentos de entrada e saída junto com pré e pós-condições, além de invariantes de domínio e contratos de interface, incluindo máquinas de estado quando o comportamento é sequencial. O formato é tipicamente markdown estruturado, legível por humanos e parseável por agentes, e a construção é iterativa: o agente gera uma primeira versão a partir da story e o humano revisa até que o documento represente com fidelidade o comportamento esperado. O ciclo lembra pair programming, mas o artefato produzido não é código. É o contrato que governa a geração do código.
O ecossistema de ferramentas que se consolidou entre 2025 e 2026 reflete a maturação dessa prática. O GitHub Spec Kit, que ultrapassou 71 mil stars e suporta mais de 20 plataformas de agentes, formaliza o fluxo em quatro fases: specify, plan, tasks, implement. Cada fase produz um artefato em markdown que serve como checkpoint revisável. O Kiro da AWS, que saiu de preview pra disponibilidade geral em novembro de 2025, integra spec-driven development diretamente no IDE, com geração de testes baseados em propriedades extraídas da especificação e rollback de etapas quando a implementação diverge do contrato. A diferença de custo entre os dois modos no Kiro é reveladora: requests de spec custam 0,20 dólares contra 0,04 dólares dos requests normais, uma relação de 5x que reflete o consumo adicional de tokens exigido pela fase de planejamento estruturado. O custo existe, mas o trade-off é previsibilidade.
Na minha avaliação, o que torna esse fluxo diferente de um waterfall disfarçado é o comprimento do ciclo de feedback. No waterfall, a especificação era produzida meses antes da implementação, e a distância temporal entre os dois artefatos garantia divergência. No spec-driven development, a spec é produzida minutos antes da implementação, pelo mesmo agente ou por agentes coordenados, e a validação acontece antes do merge, não depois do deploy. A spec não é documentação que envelhece. É contrato validado em CI contra a implementação que governa. Quando a implementação muda, a spec muda junto, ou o pipeline quebra. Essa bidirecionalidade é o que separa especificação executável de documentação tradicional.
O impacto na dinâmica entre produto e engenharia é estrutural. A user story continua sendo escrita pelo product manager com vocabulário de negócio. A tradução dessa story em spec executável passa a ser um ato de engenharia, feito por um desenvolvedor assistido por agente ou por um agente supervisionado por desenvolvedor, e é onde a ambiguidade é identificada e resolvida antes de chegar ao código. Na prática, o que eu observo é que perguntas que antes apareciam durante o desenvolvimento, gerando interrupções e retrabalho, passam a aparecer durante a especificação, quando o custo de responder é uma frase a mais no documento em vez de uma refatoração no pull request. O efeito é que a taxa de rejeição de PRs cai porque o contrato já foi negociado antes da primeira linha de código, e o time de produto ganha visibilidade sobre o que será implementado num formato que consegue ler e validar sem precisar entender a implementação.
O trade-off real é que spec-driven development exige uma disciplina de especificação em times que abandonaram especificação formal porque ela era cara e ficava desatualizada. A diferença é que o custo de produzir a spec caiu quando o agente faz o trabalho pesado de estruturação, e o problema de desatualização desaparece quando ela vira artefato de CI em vez de documento estático. Já vi isso funcionar em pipelines que mantenho: o agente estrutura com precisão sintática o que recebe, mas não tem como saber que a regra de negócio mudou na última reunião com stakeholders. Pra mim, a ponte entre produto e código no mundo agêntico não é automática, mas assistida, e o valor está nas etapas que continuam exigindo julgamento humano.