Quando eu li o artigo “Structured-Prompt-Driven Development (SPDD)”, publicado no site do Martin Fowler por Wei Zhang e Jessie Xia, a primeira coisa que me chamou atenção não foi a sigla. Foi o problema que o texto tenta resolver.
Structured Prompt-Driven Development (SPDD) é uma abordagem que trata prompts como artefatos de engenharia de primeira classe. Em vez de depender de conversas improvisadas com o modelo, a proposta é estruturar prompts para capturar requisitos, entidades do domínio, abordagem, restrições e critérios de validação, mantendo esse material versionado e sincronizado com o código ao longo do tempo. A ideia central é simples: se o prompt influencia de forma relevante o que será implementado, ele não deveria ser tratado como conversa descartável.
A premissa do artigo é muito simples e muito verdadeira: assistentes de código baseados em LLM realmente aceleram o trabalho individual, mas esse ganho local não se transforma automaticamente em throughput do sistema inteiro. Requisitos ambíguos viram código ambíguo mais rápido, reviews passam a lidar com um volume maior de mudança, problemas de integração aparecem com mais frequência e o risco de colocar algo inadequado em produção cresce junto. O próprio texto coloca isso de forma bem direta: o desafio não é gerar mais código, e sim tornar mudanças geradas com IA governáveis, revisáveis e reutilizáveis.
Eu gostei desse enquadramento porque ele desloca a conversa para o lugar certo. O gargalo de times maduros quase nunca está em digitar código. O gargalo costuma estar em alinhamento, entendimento do domínio, acoplamento entre partes do sistema, revisão, validação, teste e segurança para mudar. Quando eu olho por esse ângulo, o artigo deixa de parecer apenas mais uma proposta de “melhor forma de promptar” e passa a parecer uma tentativa séria de resolver um problema de engenharia de software assistida por IA. E é exatamente aí que, para mim, ele fica interessante.
O centro do artigo não é prompting. É governança
O SPDD é definido no artigo como um método de engenharia que trata prompts como artefatos de entrega de primeira classe. Em vez de depender de conversas improvisadas e descartáveis com o modelo, a proposta é transformar prompts em ativos que podem ser versionados, revisados, reutilizados e melhorados ao longo do tempo. Esses prompts deixam de ser apenas instruções para o LLM e passam a capturar requisitos, linguagem de domínio, intenção de design, restrições e decomposição da tarefa. O objetivo é fazer com que o modelo gere código dentro de um contorno mais explícito e, portanto, mais previsível e mais fácil de validar. Esse ponto me parece o mais forte do artigo.
Porque, no fundo, o SPDD não está tentando resolver o problema de “como pedir melhor”. Ele está tentando resolver o problema de como transformar uso individual de IA em capacidade organizacional.
Essa diferença importa muito. Enquanto o prompt continua sendo tratado como uma conversa efêmera, ele permanece preso ao contexto de uma pessoa, de uma sessão e de um momento. Quando ele passa a ser tratado como artefato versionado, ele começa a acumular intenção, decisões, restrições e memória do time. Isso muda o papel do prompt. Ele deixa de ser uma ponte improvisada para o modelo e passa a ser parte explícita do sistema de entrega.
Foi impossível ler isso sem pensar em coisas que eu já vinha discutindo no blog. Em Design Modular: O Alicerce das Arquiteturas Evolutivas, por exemplo, eu argumentei que modularidade não é só um detalhe estético do código, mas um mecanismo para preservar entendimento e permitir evolução com menos atrito. O SPDD me parece fazer algo parecido, só que no plano do contexto e da intenção: ele tenta modularizar o que o time quer dizer antes de delegar a implementação ao modelo.
O REASONS Canvas é menos “canvas de IA” e mais uma estrutura para deslocar ambiguidade para a esquerda
O artigo organiza a formulação do prompt por meio de um canvas chamado REASONS, composto por sete partes: Requirements, Entities, Approach, Structure, Operations, Norms e Safeguards. Os autores explicam que essa estrutura força o time a deixar explícitos o problema, as entidades do domínio, a abordagem escolhida, a forma como a mudança se encaixa no sistema, a decomposição em passos concretos, as normas de engenharia e as salvaguardas que não podem ser violadas. A formulação deles é muito clara: o canvas guia o prompt da intenção para o design, do design para a execução e da execução para a governança.
O que eu acho bom aqui não é a existência de um canvas em si. O que eu acho bom é o tipo de comportamento que ele induz.
Na prática, o REASONS me parece uma forma de mover ambiguidade para a esquerda. Em vez de deixar o modelo improvisar parte do raciocínio arquitetural durante a geração de código, a proposta é explicitar o máximo possível antes que a implementação aconteça. Isso não elimina incerteza, claro. Mas muda o lugar onde ela é tratada.
Esse ponto me chamou atenção porque ele conversa muito com o que já discuti em Context engineering: quando o problema deixa de ser prompt e vira arquitetura. Lá, a minha tese era que o problema real deixa de ser a frase do prompt e passa a ser o sistema de contexto ao redor dela. O REASONS Canvas vai na mesma direção, mas de forma ainda mais operacional: ele tenta estruturar, em um único artefato, o conjunto mínimo de intenção, domínio, arquitetura e restrições de que a geração de código precisa para ser menos aleatória.
A regra mais importante do artigo, para mim, é esta: quando realidade e prompt divergem, corrija o prompt primeiro
O artigo descreve o SPDD como um workflow em ciclo fechado, no qual prompt e código evoluem juntos. E existe uma regra central muito boa: quando a realidade divergir, o time deve corrigir o prompt primeiro e só depois atualizar o código. O texto também faz uma distinção interessante entre mudança de comportamento e refatoração. Se o comportamento esperado mudou, o canvas precisa ser atualizado primeiro. Se houve uma refatoração que alterou a estrutura da implementação, essa mudança deve ser sincronizada de volta para o prompt, para evitar drift entre intenção e código.
Eu gostei muito dessa ideia porque ela ataca um problema que já existia antes da IA, mas ficou pior com IA: a separação entre o que o sistema deveria fazer e o que ele acabou fazendo.
Em sistemas tradicionais, esse drift aparece em tickets velhos, documentação desatualizada, ADRs esquecidos e diagramas que não representam mais nada. Em sistemas assistidos por IA, esse mesmo problema ganha uma nova camada: o prompt pode virar uma espécie de documentação enganosa. Ele continua parecendo atual, mas já não descreve com precisão a intenção nem o contorno da implementação.
O SPDD tenta evitar exatamente isso. Em vez de tratar o prompt como “combustível de geração”, ele o trata como uma fonte de verdade viva. Para mim, esse talvez seja o ponto mais importante de todo o artigo.
O exemplo da billing engine é pequeno, mas o padrão é transferível
O artigo mostra a abordagem em um exemplo didático de evolução de um pequeno sistema de billing para LLMs. O caso percorre criação de requisitos, análise, geração de contexto, montagem do REASONS Canvas, geração de código, geração de testes, correções e sincronização entre prompt e implementação. Ao final, os autores relatam benefícios como melhor alinhamento de intenção, maior transparência das decisões de engenharia, sincronização entre prompt e código e acúmulo de conhecimento reutilizável ao longo das iterações.
Eu não acho que o valor do artigo esteja no domínio do exemplo. Billing é só um veículo didático. O que importa é o padrão.
Se eu trouxer isso para algo mais próximo do dia a dia de produto e arquitetura, a utilidade fica mais clara. Imagine uma mudança em um fluxo de checkout que envolva regra promocional, compatibilidade retroativa, restrições regulatórias e impacto em observabilidade. Sem uma estrutura como essa, parte do que define a mudança vai continuar espalhada entre ticket, conversa de Slack, memória de quem conhece o fluxo e revisão humana posterior. Com uma estrutura como REASONS, pelo menos existe uma tentativa concreta de capturar num único artefato o problema de negócio, as entidades do domínio, a abordagem escolhida, onde a mudança entra no sistema e que salvaguardas não podem ser quebradas.
O ganho, portanto, não é só para o modelo. É também para o review, para o onboarding, para a próxima iteração e para qualquer pessoa que venha depois e precise entender “o que estávamos tentando fazer aqui”.
As três habilidades destacadas no artigo mostram bem para onde o trabalho está migrando
Uma parte do texto que eu achei especialmente lúcida é quando os autores dizem que desenvolvedores precisam de três habilidades centrais para trabalhar bem com esse tipo de abordagem: abstraction first, alignment e iterative review. Em termos simples, isso significa pensar design antes de gerar, garantir alinhamento entre domínio e implementação, e tratar geração como um processo iterativo de refinamento e revisão.
Eu concordo bastante com isso.
Durante um tempo, houve uma leitura quase ingênua de que IA em desenvolvimento seria, acima de tudo, um acelerador de escrita de código. Só que, quanto mais barato fica gerar código, mais importante fica o trabalho de delimitar, enquadrar, revisar e sincronizar. O centro de gravidade sai do “escrever” e se move para o “dar forma ao problema”.
Isso vale especialmente para líderes técnicos. Ganho de produtividade individual é relativamente fácil de perceber. O mais difícil — e o que o SPDD tenta atacar — é transformar esse ganho em algo que o time inteiro consiga governar sem depender da memória e da habilidade ritualística de poucas pessoas.
Esse ponto conversa também com Model Context Protocol (MCP): O Futuro da Interação com Modelos de IA. No artigo sobre MCP, eu discuti como contexto persistente, modular e reutilizável tende a se tornar uma camada importante da arquitetura de sistemas com IA. O SPDD, embora não dependa de MCP, parte do mesmo impulso: sair da conversa solta e transformar contexto em ativo reutilizável do time.
Onde eu vejo mais valor prático no SPDD
Se eu tivesse que resumir o valor prático da abordagem, eu diria que ela ajuda a resolver quatro problemas muito concretos.
O primeiro é reduzir dependência de conhecimento tácito. Em vez de a qualidade do trabalho depender apenas de quem “sabe conversar bem com o modelo”, parte importante do contexto passa a ser explicitada em um artefato compartilhado.
O segundo é melhorar a qualidade do review. O review deixa de olhar só para o diff e passa a conseguir confrontar o código com a intenção, os limites e as salvaguardas que foram explicitados antes.
O terceiro é criar memória de time. O prompt não desaparece junto com a sessão. Ele passa a carregar parte do aprendizado acumulado sobre aquele fluxo ou módulo.
O quarto é reduzir variabilidade. Se todo mundo trabalha a partir de uma mesma estrutura de formulação, a diferença entre uma pessoa muito experiente com IA e outra menos experiente tende a diminuir.
Esses ganhos aparecem de forma bem coerente com a proposta central do artigo: transformar prompts em ativos governados, reutilizáveis e sincronizados com o código ao longo do tempo.
Onde eu tomaria cuidado
Dito isso, eu também acho importante não romantizar a abordagem.
O primeiro cuidado é o mais óbvio: o SPDD adiciona processo. Se eu aplicar esse nível de estrutura em qualquer tarefa minúscula, eu corro o risco de burocratizar algo que deveria ser simples. Para mim, o valor dessa abordagem tende a aparecer com mais força em mudanças relevantes, fluxos de domínio sensíveis, trabalho iterativo e contextos em que governança realmente importa.
O segundo cuidado é que prompt estruturado não compensa arquitetura ruim. Se o domínio está mal modelado, os boundaries são frouxos e a intenção já nasce ambígua, um canvas bonito ajuda, mas não faz milagre. Ele organiza a incerteza, mas não substitui clareza arquitetural.
O terceiro cuidado é que o exemplo do artigo é deliberadamente controlado. Isso ajuda a ensinar, mas a vida real é mais desordenada. Em times grandes, múltiplas dependências, prioridades mudando e pressão de prazo, manter sincronização entre intenção, prompt e código vai exigir disciplina de verdade. Ou seja: o sucesso do SPDD depende menos da técnica em si e mais da maturidade operacional da equipe.
Onde o SPDD se encaixa melhor
SPDD é um investimento de engenharia. A tabela abaixo ajuda a visualizar em que cenários esse investimento tende a se pagar mais — e em quais ele provavelmente não compensa.
| Avaliação | Cenário | Observações |
|---|---|---|
| ★★★★★ | Entrega padronizada em escala | Lógicas de negócio repetitivas que precisam de manutenção consistente ao longo do tempo, como a criação de muitas APIs parecidas ou a automação de fluxos centrais de negócio. |
| ★★★★★ | Alta conformidade e restrições rígidas | Ambientes em que regras regulatórias, padrões de segurança ou diretrizes arquiteturais precisam ser obedecidos com rigor, como sistemas core financeiros ou soluções multi-cliente e multi-canal. |
| ★★★★☆ | Colaboração em equipe e auditabilidade | Cenários com várias pessoas envolvidas, em que mudanças precisam ser totalmente rastreáveis e revisáveis de ponta a ponta. |
| ★★★★☆ | Consistência em mudanças transversais | Refactors complexos em que a lógica precisa permanecer sincronizada entre múltiplos microsserviços ou até entre linguagens diferentes. |
| ★★☆☆☆ | Hotfixes de produção | Situações em que o objetivo é “estancar o sangramento” e velocidade importa mais do que disciplina arquitetural. |
| ★★☆☆☆ | Spikes exploratórios | Quando o objetivo é validar uma ideia rapidamente, e não entregar software pronto para produção, o overhead de governança do SPDD tende a não se pagar. |
| ★★☆☆☆ | Scripts pontuais | Scripts descartáveis, limpezas temporárias de dados ou automações de uso único, em que o custo inicial da abordagem é alto demais para o valor gerado. |
| ★☆☆☆☆ | Buracos negros de contexto | Cenários em que o domínio é mal definido e as regras de negócio são vagas, tornando impossível estabelecer limites significativos para o modelo. |
| ★☆☆☆☆ | Trabalho puramente criativo ou visual | Tarefas guiadas por gosto, direção estética ou exploração visual, como estudos de interface ou copy de marketing, em que a estrutura do SPDD tende a agregar pouco. |
O que eu levaria desse artigo para o dia a dia
Se eu tivesse que transformar o artigo em uma mudança prática de comportamento, ela seria esta:
se a mudança é importante, pare de tratar o prompt como conversa descartável.
Se aquele fluxo vai evoluir, se a regra é sensível, se o domínio é importante, se várias pessoas vão mexer naquilo ao longo do tempo, então o prompt já deixou de ser apenas instrução para o modelo. Ele virou parte do sistema de entrega. E, se virou parte do sistema de entrega, eu acho razoável tratá-lo como trato outros artefatos importantes: com estrutura, revisão, versionamento e sincronização.
Essa, para mim, é a melhor leitura do artigo do Fowler. O SPDD não é interessante porque “organiza melhor prompts”. Ele é interessante porque reconhece algo que muita gente ainda está evitando encarar: em engenharia assistida por IA, intenção, contexto e restrições passam a ser ativos tão importantes quanto código. E o time que tratar isso com a mesma seriedade com que trata código, testes e arquitetura provavelmente vai capturar muito mais valor do que o time que continuar tratando prompt como conversa perdida no histórico do chat.
