Pedir uma funcionalidade pronta para um modelo de IA e esperar código que funcione é a versão de software do telefone sem fio. O pedido sai curto — "adiciona login", "cria o módulo de cobrança" — e o modelo preenche o que faltou com defaults razoáveis que quase nunca batem com a regra de negócio real. Funciona na demo. Trava três sprints depois, quando ninguém lembra por que aquela validação está ali, ou por que ela sumiu na última geração.
A indústria deu nome ao padrão de falha e à correção dele. O padrão de falha ganhou o apelido de "vibe coding": prompts soltos, requisitos implícitos, regras de negócio espalhadas e decisões enterradas no histórico do chat. A correção é o Specification-Driven Development (SDD) — inverter a ordem. A especificação vem antes do código, e é ela, não o prompt do momento, que vira a fonte de verdade que tanto pessoas quanto agentes de IA seguem. O artigo acadêmico "Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants", publicado no arXiv no fim de janeiro de 2026, resume a virada de chave: especificações tradicionais são lidas por humanos; especificações no modelo SDD executam como portões de validação.
Principais pontos
- A IA não programa melhor com prompt maior, e sim com contexto estruturado: requisitos claros, arquitetura definida e limites explícitos antes da primeira linha de código.
- "Vibe coding" cobra a velocidade no curto prazo em retrabalho, inconsistência e decisões não documentadas que ninguém consegue reconstituir depois.
- No SDD a especificação é a fonte de verdade, versionada junto do repositório e reutilizável por pessoas e agentes em cada nova sessão de desenvolvimento.
- O diferencial não está em "usar IA pra codar", e sim em transformar conhecimento de negócio em especificações que o agente segue, reutiliza e respeita.
- A maturidade da engenharia por trás da IA decide a qualidade do software gerado — não a marca da ferramenta nem o tamanho do modelo.
Para quem decide contratar desenvolvimento — sob medida ou via parceiro —, a pergunta deixou de ser "vocês usam IA pra programar?". Praticamente todo fornecedor usa. A pergunta que separa entrega durável de protótipo que apodrece é "como o conhecimento do meu negócio vira especificação que a IA segue, e onde isso fica versionado?". É exatamente nesse ponto que parceiros como a Vertis Tech entram em consideração: o trabalho começa por discovery técnico orientado a outcome, não por um prompt improvisado.
O que muda quando a especificação vira fonte de verdade
No desenvolvimento tradicional, o código é o artefato central e a documentação é um anexo que envelhece. No SDD a relação se inverte: a especificação é o artefato central, e o código é uma das suas saídas. A equipe — ou o agente de IA sob supervisão — primeiro descreve em detalhe o que o sistema deve fazer, deriva um plano de implementação, quebra em tarefas atômicas e só então gera o código.
Essa especificação não é um documento morto de Word. No SDD ela é executável no sentido de servir como contrato verificável: define comportamento esperado, casos de borda e critérios de aceite que validam se o código gerado realmente faz o que foi pedido. Ferramentas de codificação com IA convergiram para esse padrão ao longo de 2025 e 2026, cada uma com seu sabor. O GitHub Spec Kit, por exemplo, materializa parte disso no arquivo de "constitution" do projeto — um documento Markdown versionado que define princípios e diretrizes de arquitetura, vive no repositório ao lado do código e é injetado como contexto persistente no início de cada sessão do agente. A constitution é só a base: o fluxo segue para especificar o comportamento, derivar o plano técnico, quebrar em tarefas e só então implementar — cada etapa ancorada em artefatos versionados, não em prompt solto.
A consequência prática para o decisor é direta: quando a especificação é versionada, uma decisão de arquitetura tomada em janeiro continua valendo em julho, mesmo que a pessoa que a tomou tenha saído e o modelo de IA tenha mudado de versão. O conhecimento para de morar na cabeça de quem estava na call e passa a morar num artefato auditável.
Os modos de falha que a IA herda de requisitos ruins
O SDD não surgiu de moda. Ele é resposta a modos de falha concretos que apareceram quando agentes de codificação com IA viraram mainstream.
O primeiro é o desvio de intenção. Um pedido como "adiciona login" é subespecificado: não diz se é com senha, link mágico, SSO corporativo, se exige verificação em duas etapas, qual a política de bloqueio após tentativas falhas. O modelo escolhe defaults que parecem razoáveis e raramente coincidem com o que o time realmente queria. Quanto mais crítico o domínio, mais grave fica o desvio.
O segundo é a alucinação de interfaces. Sem um contrato explícito sobre quais APIs e bibliotecas existem no projeto, o modelo inventa chamadas plausíveis para funções que não existem, ou usa assinaturas de versões que o projeto não tem. O código compila na cabeça do modelo e quebra no ambiente real.
O terceiro é a erosão. À medida que o projeto cresce, cada nova geração reintroduz inconsistência: um padrão de nomenclatura aqui, outro ali; uma validação que existia e foi sobrescrita; uma regra de negócio que valia num módulo e foi ignorada no próximo. Sem uma especificação que ancore o que é invariável, o sistema decai a cada interação.
Os três têm a mesma raiz: o modelo está preenchendo lacunas de contexto com suposição. SDD ataca a raiz fechando as lacunas antes, na especificação, em vez de corrigir o sintoma depois, no code review.
As camadas que nascem antes do código
Um projeto conduzido por especificação não começa pela tela nem pelo schema do banco. Começa por camadas que, juntas, formam a base de contexto reutilizável tanto para as pessoas quanto para os agentes de IA:
Visão e requisitos
A visão responde "que problema de negócio esse software resolve e para quem". Os requisitos funcionais detalham o comportamento esperado — o que o sistema faz, em que ordem, com quais regras. Os requisitos não-funcionais definem o que costuma decidir o sucesso na operação real: desempenho sob carga, disponibilidade, observabilidade, custo de operação. É a camada que o prompt solto sempre pula.
Arquitetura e design detalhado
A arquitetura define as fronteiras: quais serviços existem, como se comunicam, onde mora o estado, como o sistema integra com o que já existe e funciona. O design detalhado desce ao nível de contratos de dados, modelos e interfaces. Para um agente de IA, essa camada é o que evita a alucinação de interface — ele passa a gerar código contra um contrato conhecido, não contra um palpite.
Segurança, testes e operação
Segurança desenhada desde o diagrama — e não remendada no fim — define papéis de acesso, tratamento de dado sensível e superfície de exposição. A camada de testes transforma critérios de aceite em portões verificáveis. A camada de operação descreve como o sistema é implantado, monitorado e revertido. Cada uma dessas camadas, escrita como especificação, vira contexto que o agente consulta em vez de inventar.
Por que prompt maior não resolve
Existe uma tentação de achar que basta escrever um prompt gigante, com tudo dentro, e o problema some. Não some, por dois motivos.
Primeiro, um prompt improvisado é efêmero. Ele resolve a tarefa daquela sessão e evapora. A próxima pessoa — ou a próxima sessão do mesmo agente — começa do zero, sem herdar as decisões. Especificação versionada é o oposto: é contexto persistente, recuperável, que toda sessão futura consulta.
Segundo, contexto não é só volume, é estrutura. Despejar trinta páginas de requisitos não-organizados num modelo costuma piorar o resultado, não melhorar: o sinal relevante se perde no ruído. O que move a agulha é contexto estruturado em camadas, onde cada decisão tem lugar definido e o agente recupera a parte certa no momento certo. A diferença entre jogar PDFs num modelo e construir uma base de conhecimento recuperável é a mesma diferença entre prompt improvisado e especificação versionada — em ambos os casos, a estrutura é que faz o trabalho.
É por isso que a tese central do SDD é tão pragmática: a IA não programa melhor porque recebeu um prompt maior. Ela programa melhor quando recebe requisitos claros, arquitetura definida e limites explícitos — e isso é trabalho de engenharia feito antes, não mágica de modelo feita depois.
O diferencial não é usar IA pra codar
Em 2026, dizer "usamos IA para desenvolver" virou commodity. O diferencial está no que acontece antes da IA escrever a primeira linha. É esse o ponto que o decisor precisa levar para a reunião de seleção de fornecedor: o que separa um fornecedor de outro não é mais usar IA, e sim a disciplina de transformar conhecimento de negócio em especificação que a IA segue, reutiliza e respeita.
Na prática da Vertis Tech, a mesma lógica aparece nos próprios processos internos: os agentes operam sobre Know-How e Playbook versionados — artefatos que capturam o que a empresa sabe fazer e como ela opera, editáveis e auditáveis —, não sobre prompts soltos. A IA aprende o contexto a partir de um artefato estruturado, não de improviso. É a mesma lógica do SDD aplicada à operação interna: contexto estruturado, não prompt do momento.
Quando o software gerado por IA precisa durar anos, com governança de código clara, a maturidade da engenharia por trás da ferramenta — não a escolha da ferramenta — é o que decide a qualidade do resultado.
Como a Vertis Tech ajuda em desenvolvimento de software com IA
A Vertis Tech é fábrica de software brasileira focada em CRM, automação e IA aplicada. Cada projeto é dimensionado conforme a especificidade do processo, as integrações necessárias, a sensibilidade dos dados e a maturidade de engenharia exigida pelo escopo. A depender do projeto, a abordagem pode contemplar:
- Discovery técnico orientado a outcome antes de codar, para mapear visão, requisitos e limites que viram a base de contexto do projeto — em vez de comprometer recursos a partir de um pedido subespecificado.
- Especificação versionada junto do código, desenhada para que decisões de arquitetura e regra de negócio sobrevivam a trocas de equipe e a mudanças de versão dos modelos de IA.
- Stack moderno e auditável (TypeScript, Postgres, modelos de IA atuais), pensado para projetos que precisam durar anos com governança de código clara.
- Agentes de IA que rodam sobre contexto estruturado, no padrão dos sistemas internos da Vertis — Know-How e Playbook versionados, não prompt improvisado.
- Integração com sistemas legados, definindo contratos de dados explícitos para que o código gerado dialogue com o que já existe e funciona.
- Segurança e governança desde o primeiro diagrama, com papéis de acesso e rastreabilidade desenhados na especificação, não remendados no fim.
Perguntas frequentes
Specification-Driven Development é o mesmo que voltar ao modelo cascata?
Não. No cascata, a especificação era um documento longo, lido uma vez e abandonado, e mudá-la era custoso. No SDD a especificação é viva e versionada, evolui com o produto e serve como contexto executável que o agente de IA consulta a cada sessão. A iteração continua ágil; o que muda é que ela parte de uma fonte de verdade clara, não de um prompt do momento.
Isso não desacelera o desenvolvimento, já que se escreve antes de codar?
Há tempo dedicado antes da primeira linha de código, sim. A contrapartida é a redução do retrabalho que o desvio de intenção, a alucinação de interface e a erosão tendem a gerar quando o código nasce de pedido vago. Como regra prática, quanto mais crítico e duradouro o sistema, mais o esforço de especificação se justifica. Para um protótipo descartável, o cálculo é outro.
Qual ferramenta de SDD devo adotar?
A escolha da ferramenta — entre as várias que surgiram no mercado — importa menos do que a disciplina de engenharia que ela sustenta. Uma especificação clara, versionada e reutilizável move a qualidade independentemente de qual stack de agente a executa. Vale começar pela pergunta "como vamos estruturar e versionar nosso contexto" antes de "qual produto vamos comprar".
Como avaliar se um fornecedor realmente trabalha orientado a especificação?
Peça para ver onde mora o contexto do projeto. Se a resposta for "está nos prompts" ou "está com o time", o conhecimento é frágil. Se for um artefato versionado, com requisitos, arquitetura e critérios de aceite que o agente consulta, há disciplina de engenharia por trás da IA. Essa pergunta costuma separar entrega durável de geração de código improvisada.
Specification-Driven Development não é a promessa de que a IA vai escrever software perfeito sozinha. É o reconhecimento honesto de que a qualidade do que a IA gera é proporcional à qualidade do contexto que ela recebe — e que construir esse contexto é trabalho de engenharia, feito antes, por gente que entende o negócio. A ferramenta mudou; o que decide o resultado continua sendo a maturidade de quem a conduz.
