SDD Empresarial: O Problema Organizacional Que Ferramentas Não Resolvem

Hari Krishnan publicou na InfoQ, em fevereiro de 2026, a análise mais completa até agora sobre adoção de Spec-Driven Development em empresas. Identificou sete problemas que ferramentas como SpecKit, Kiro, Tessl e OpenSpec não resolvem. Cada um deles é, na essência, um problema de governança disfarçado de problema de ferramentas.

Isso não é surpresa. Como exploramos em A Camada de Especificação, cinco equipes independentes convergem em especificações como superfície primária de controle para agentes. Convergência de praticantes confirmou a tese regulatória. Faltava o teste de escala: o que acontece quando SDD sai de um repositório e de uma equipe para dezenas de repositórios e centenas de engenheiros?

A resposta de Krishnan é honesta. Não funciona. Pelo menos não ainda.

O gargalo mudou de lugar

Adrian Cockcroft, ex-VP do Netflix e referência em arquitetura de sistemas distribuídos, resume a situação com precisão: “A surpresa de trabalhar com enxames de agentes é que o problema não é escrever código. Agentes fazem isso extremamente bem. O gargalo é gerenciá-los.”

A frase de Cockcroft condensa o argumento central deste artigo. SDD pressupõe que especificações são o mecanismo de controle para agentes. Correto. Mas quem escreve as specs? Quem as revisa? Quem resolve conflitos entre specs de repositórios diferentes? Quem garante que uma spec de produto não contradiz uma spec de infraestrutura?

Numa equipe de cinco pessoas trabalhando num único repositório, essas perguntas se respondem sozinhas. A pessoa que escreveu a spec está sentada ao lado da pessoa que a implementa. Conflitos se resolvem em conversas de corredor. O contexto é compartilhado por osmose.

Numa empresa com 200 engenheiros, 40 repositórios e 12 equipes de produto, as perguntas não têm resposta natural. E ferramentas de SDD não foram projetadas para respondê-las.

Sete problemas, uma raiz

Krishnan nomeia sete lacunas de adoção empresarial. Vale listá-las porque, juntas, desenham o contorno do problema real.

Ferramentas centradas no desenvolvedor. SpecKit, Kiro e similares assumem que o autor da spec é um engenheiro trabalhando sozinho. Product managers, arquitetos e líderes técnicos ficam de fora do fluxo.

Suposição de mono-repositório. O modelo mental é um repositório, uma spec, um agente. Empresas operam com dezenas ou centenas de repositórios. Nenhuma ferramenta atual coordena specs entre repositórios.

Separação de artefatos pouco clara. Onde termina o requisito de produto e começa a especificação técnica? A fronteira é ambígua, e ambiguidade em escala produz inconsistência.

Integração deficiente com backlogs. Specs vivem no repositório. Requisitos vivem no Jira ou Linear. Os dois mundos não conversam. Engenheiros duplicam informação ou trabalham com contexto parcial.

Padrões de colaboração indefinidos. Quem revisa uma spec? Com que critério? O processo de revisão de código é maduro. O processo de revisão de specs não existe.

Variância de especificações. Sem padrão organizacional, cada equipe escreve specs de forma diferente. Auditoria se torna impossível quando não existe formato consistente.

Ambiguidade em brownfield. Ferramentas de SDD funcionam bem para projetos novos. Em projetos legados, com anos de dívida técnica e especificações implícitas no código, o ponto de partida é obscuro.

Nenhum desses problemas é sobre sintaxe, formato ou capacidade de modelos. Todos são sobre processos, papéis e coordenação. Problemas organizacionais.

A falácia da evolução linear

Existe uma narrativa sedutora no ecossistema de SDD: vibe coding leva a plan mode, que leva a SDD. Uma progressão natural e inevitável. Krishnan a adota. O mercado a amplifica.

A narrativa é falsa. Ou, no mínimo, perigosamente simplificada.

Vibe coding é exploração. Plan mode é estruturação de tarefas dentro de uma sessão. SDD é governança de artefatos declarativos que restringem execução. São práticas diferentes, com finalidades diferentes, que atendem a contextos diferentes. Um desenvolvedor fazendo prototipagem rápida com vibe coding não está “no estágio inicial” de uma jornada que culmina em SDD. Está usando a ferramenta certa para o contexto.

O ThoughtWorks Technology Radar, Volume 33 de novembro de 2025, posiciona SDD no anel “Assess”. Não “Trial”. Não “Adopt”. Assess: vale investigar, mas a maturidade ainda não justifica adoção ampla. O Radar explicitamente alerta sobre workflows “elaborate and opinionated” que podem não compensar o investimento.

Scott Logic testou SpecKit e documentou a experiência: 2.577 linhas de markdown para uma única feature. Dez vezes mais lento que prompting iterativo. A spec era tecnicamente correta. Era também impraticável.

Birgitta Bockeler, da ThoughtWorks (equipe de Martin Fowler), foi mais direta: “Eu prefiro revisar código a revisar todos esses arquivos markdown.”

A observação de Bockeler merece atenção porque expõe uma tensão real. Se o argumento central do SDD é que especificações substituem código como o artefato primário de engenharia, o custo de revisão dessas especificações precisa ser menor que o custo de revisar o código que elas produzem. Caso contrário, a spec adiciona uma camada burocrática sem reduzir o trabalho total.

O elefante na sala

Existe uma crítica que o artigo de Krishnan evita. Ela precisa ser dita: SDD, em sua forma mais prescritiva, soa como Waterfall com sintaxe nova.

Escreva a especificação completa antes de implementar. Separe design de execução. Garanta que a intenção está totalmente articulada antes que qualquer código seja escrito. Cada uma dessas prescrições aparecia nos manuais de desenvolvimento em cascata dos anos 1990.

A diferença, argumentam os proponentes, é que no SDD o agente implementa em minutos, não em meses. O custo de iteração desaparece. Errou a spec? Reescreva e regere.

O argumento tem mérito. Mas ignora uma realidade: em projetos complexos, a especificação completa é impossível antes da implementação. A implementação revela requisitos que a especificação não previu. Esse é o insight central do manifesto ágil, e décadas de prática o confirmam.

SDD funciona melhor quando a especificação é parcial e iterativa, não completa e anterior. O que nos traz de volta ao problema organizacional: como coordenar especificações parciais e em evolução entre dezenas de equipes?

Orquestração multi-repositório: a infraestrutura que falta

Krishnan propõe um modelo em três fases para SDD multi-repositório: Discover, Design, Task. Na fase Discover, o sistema mapeia o contexto entre repositórios. Na fase Design, a especificação é escrita considerando dependências cruzadas. Na fase Task, agentes executam tarefas restritas por repositório.

O modelo é sensato na teoria. Contexto de negócio fica nos boards de produto. Detalhes de implementação ficam nos repositórios. Specs fazem a ponte.

Na prática, nenhuma ferramenta implementa esse modelo hoje. MCP (Model Context Protocol) poderia servir como protocolo de integração entre backlogs e specs, conectando Jira ou Linear aos workflows de SDD. Mas as features enterprise do MCP ainda estão em pré-RFC (março de 2026). A infraestrutura não existe.

Isso é relevante porque, como documentamos em Especificações de Agentes São Artefatos de Governança, a convergência regulatória já pressupõe rastreabilidade entre especificação e execução. O Auton Framework, a Cloud Security Alliance e o IMDA de Singapura exigem, cada um à sua maneira, que a cadeia entre intenção e resultado seja auditável. Multi-repositório quebra essa cadeia. E ninguém oferece uma solução prática para reconstituí-la.

A evolução de papéis: real, porém aspiracional

Krishnan descreve novos papéis no ciclo de SDD. Product teams articulam contexto de negócio. Arquitetos codificam restrições técnicas em especificações. Engenheiros validam a saída dos agentes em vez de escrever código. QA constrói e valida harnesses de teste.

Cada uma dessas descrições é plausível. Nenhuma descreve uma realidade existente.

Nenhuma empresa, até onde dados públicos permitem verificar, opera com essa divisão de trabalho hoje. São projeções sobre como o trabalho deveria se reorganizar, não relatos de como já se reorganizou.

A distinção importa. Como exploramos em Quando a Especificação É o Produto, Quem Governa a Especificação?, a transição do papel de PM para “formador de intenção” já é um desafio. Adicionar a transição simultânea de arquitetos, engenheiros e QA multiplica a complexidade organizacional.

O conceito de agent harness, a infraestrutura que envolve o modelo e determina 85% da diferença entre resultado útil e inútil, ganha uma dimensão nova nesse contexto. Em escala empresarial, o harness não é apenas técnico. Inclui os processos de revisão, os padrões de especificação, os fluxos de aprovação e os mecanismos de coordenação entre equipes. É um harness organizacional, não apenas de código.

Classificação de falhas: onde governança se torna operacional

Um insight prático de Krishnan que merece destaque: falhas em SDD se dividem em duas categorias com implicações diferentes.

Falha spec-para-implementação. A spec estava correta, mas o agente errou a execução. O modelo falhou em conformar com a especificação. A resposta é técnica: melhorar o harness, ajustar o contexto, trocar o modelo.

Falha intenção-para-especificação. O agente implementou a spec fielmente, mas a spec estava errada. A intenção humana não foi capturada com precisão. A resposta é organizacional: melhorar o processo de revisão, envolver mais stakeholders, iterar a spec antes da execução.

Misturar as duas categorias é o erro mais comum. Equipes trocam de modelo quando o problema está na spec. Ou reescrevem specs quando o problema está no harness. A classificação correta da falha determina a ação correta.

Dados da Deloitte (2026) situam o problema em escala: apenas uma em cinco empresas tem um modelo maduro de governança para agentes de IA. As quatro restantes operam agentes sem clareza sobre quem é responsável quando algo falha. A taxonomia de falhas de Krishnan é útil precisamente porque essas organizações precisam de um framework para separar problemas de ferramentas de problemas de processo.

O que isso significa na prática

SDD em escala empresarial é um problema real que ferramentas atuais não resolvem. Não porque as ferramentas sejam ruins, mas porque o problema é organizacional.

Três ações se justificam para organizações explorando SDD além de protótipos.

Primeiro, separe governança de ferramentas. A decisão de adotar SpecKit ou Kiro é secundária. A decisão primária é: quem escreve specs, quem as revisa, quem as aprova e quem responde quando a spec erra? Sem essas definições, qualquer ferramenta produzirá especificações inconsistentes e não auditáveis.

Segundo, comece com classificação de falhas. Antes de investir em infraestrutura de SDD multi-repositório, instrumente seu processo atual para distinguir falhas de spec de falhas de execução. Essa distinção sozinha melhora a velocidade de resolução, independentemente da ferramenta.

Terceiro, trate a evolução de papéis como projeto, não como consequência. A transição de engenheiros que escrevem código para engenheiros que validam saída de agentes não acontece organicamente. Exige treinamento, métricas novas e, acima de tudo, disposição para aceitar que produtividade no curto prazo cairá antes de melhorar.

O ThoughtWorks coloca SDD em “Assess” por boas razões. A técnica é promissora. A evidência de escala é escassa. E a distância entre um desenvolvedor usando SDD num repositório pessoal e uma empresa usando SDD em produção é a mesma distância entre um protótipo e um sistema governado.

Especificações já são a superfície de controle para agentes de IA. Essa convergência, como documentamos em cinco análises independentes, é estrutural. Mas convergência técnica não é suficiente. A próxima fronteira é organizacional. E nenhuma ferramenta resolve isso por você.

Fontes

Krishnan, Hari. “Spec-Driven Development – Adoption at Enterprise Scale.” Fevereiro 2026.
Cockcroft, Adrian. “Why We Need a Purpose Driven Agent Based Developer Management Platform.” 2026.
ThoughtWorks. “Spec-Driven Development.” Technology Radar Vol. 33, Novembro 2025.
Bockeler, Birgitta. “Understanding SDD Tools.” Martin Fowler Blog, 2026.
Deloitte. “State of AI in the Enterprise.” 2026.

A Victorino ajuda organizações a transformar adoção de SDD em governança operacional para frotas de agentes: contato@victorino.com.br | www.victorino.com.br