Quando a Especificação É o Produto, Quem Governa a Especificação?

Shubham Saboo, PM do Google, publicou esta semana uma thread que viralizou sobre a transformação do papel de Product Manager. A tese central: PMs estão deixando de ser “camada de tradução” entre negócio e engenharia para se tornarem “formadores de intenção”. Specs bem escritas, alimentadas por contexto adequado, geram código funcional em minutos. O PM do futuro não traduz requisitos. Formula intenções.

Saboo acerta no diagnóstico. Erra no que deixa de fora.

A Mudança É Real

O Spec-Driven Development (SDD) não é especulação. ThoughtWorks, Martin Fowler, GitHub e a própria Anthropic documentam esse paradigma emergente ao longo de 2026. A evidência acumulada é difícil de ignorar: ciclos de PR caíram 75% com ferramentas como GitHub Copilot. 84% dos desenvolvedores usam ferramentas de IA, e essas ferramentas já escrevem 41% de todo o código novo.

Saboo descreve três novas competências para o PM nesse mundo: modelagem de problemas, curadoria de contexto e avaliação (o que ele chama de “gosto”). As três são legítimas. Modelar bem um problema é metade da solução. Curar contexto corretamente evita que o agente alucine. Avaliar output com critério separa protótipo de produto.

Até aqui, concordo. O que segue é onde a análise dele fica incompleta.

O Que a Thread Não Menciona

Saboo trata a curadoria de contexto como uma habilidade pessoal do PM. Uma questão de competência individual. Escolher os documentos certos, estruturar o prompt com precisão, avaliar se o resultado atende à intenção.

Essa descrição funciona para um protótipo. Funciona para um hackathon. Funciona quando o custo do erro é retrabalho, não incidente.

Não funciona quando a spec vira código de produção em uma hora.

Quando a distância entre “requisito escrito” e “sistema operando” colapsa de semanas para minutos, cada ambiguidade na especificação se torna um defeito potencial em produção. Cada contexto omitido é uma superfície de ataque. Cada suposição implícita é uma falha latente.

O Google DORA 2025 mediu isso com precisão: um aumento de 90% na adoção de IA correlaciona com 9% mais bugs e 91% mais tempo de revisão de código. A velocidade de geração subiu. A qualidade não acompanhou. O trabalho não desapareceu; migrou da escrita para a revisão.

O Problema “Quase Certo”

A pesquisa do Stack Overflow de 2025, com mais de 49 mil desenvolvedores, identificou o que 66% deles chamam de problema “quase certo”. O código gerado por IA parece correto. Compila. Passa nos testes básicos. Mas carrega erros sutis que só se manifestam em produção, sob carga, em edge cases que a spec não cobriu.

A confiança dos desenvolvedores em código gerado por IA caiu para 60%. Em 2024, era significativamente maior.

A Veracode testou mais de 100 LLMs e encontrou que 40% a 48% do código gerado contém vulnerabilidades de segurança. Não bugs de lógica. Vulnerabilidades exploráveis.

Quando Saboo fala em “curadoria de contexto”, está descrevendo um processo que, sem controles formais, produz output plausível mas potencialmente incorreto. Em velocidade industrial.

A Fragilidade do Agente

A VentureBeat documentou em 2026 três fragilidades recorrentes em agentes de IA: janelas de contexto frágeis, refatorações que quebram dependências silenciosamente, e falta de consciência operacional. O agente não sabe que o serviço que ele está integrando teve uma mudança de API na semana passada. Não sabe que o banco de dados tem uma constraint não documentada. Não sabe que aquela função “simples” é chamada por 47 outros módulos.

Mais de 40% dos projetos de IA agêntica falham antes de chegar à produção, segundo dados da Composio (2025) e Company of Agents (2026). A causa mais frequente não é limitação técnica do modelo. É a distância entre o que a spec descreve e o que o ambiente de produção exige.

A Red Hat publicou em fevereiro de 2026 uma análise direta: “vibe coding” é inadequado para produção com dados regulados. A frase é mais polida do que o diagnóstico merece.

Curadoria de Contexto É Governança Sem as Partes Difíceis

Voltando a Saboo. Seu checklist de “curadoria de contexto” inclui: selecionar documentação relevante, estruturar o prompt, validar o output. Lido com olhos de governança, isso é um framework leve de controle de qualidade.

O que falta? Compliance. Trilhas de auditoria. Revisão de segurança. Gestão de modos de falha. Versionamento de specs. Rastreabilidade entre requisito, código gerado e teste que valida. Política de rollback quando o código gerado causa regressão.

A diferença entre “curadoria de contexto” e “governança de especificação” é a diferença entre um post-it na mesa do PM e um processo auditável. Ambos descrevem o que deve entrar no prompt. Só um deles sobrevive a uma auditoria de segurança.

A Erosão Silenciosa

Existe um custo que nenhuma thread de LinkedIn vai mencionar: a erosão do conhecimento institucional.

Quando o PM formulava requisitos e um engenheiro implementava, a conversa entre os dois gerava entendimento mútuo. O engenheiro aprendia o domínio do negócio. O PM aprendia as restrições técnicas. Esse conhecimento bidirecional se acumulava na organização.

Com agentes mediando essa relação, o PM formula, o agente executa, o código aparece. A conversa desaparece. O PM não precisa entender as restrições técnicas porque o agente “resolve”. O engenheiro (se ainda estiver no loop) não precisa entender o domínio porque recebeu uma spec pronta.

O resultado, no curto prazo, é velocidade. No longo prazo, é uma organização onde ninguém entende o sistema completo. O PM entende a intenção. O agente entende o código. O engenheiro, se restou, entende fragmentos. A visão sistêmica evapora.

Isso não é abstração. É o tipo de risco que aparece quando alguém tenta mudar a arquitetura e descobre que ninguém lembra por que as decisões originais foram tomadas.

O Que Governança de Especificação Exige

Se a especificação é o produto (e em SDD, é), então precisamos tratá-la com o rigor que tratamos código de produção.

Concretamente:

Versionamento formal. Specs mudam. Cada versão precisa ser rastreável. Quando o código gerado causa um bug, a pergunta “qual versão da spec gerou isso?” precisa ter resposta.

Revisão por pares. Se código precisa de code review, specs que geram código precisam de spec review. Com critérios explícitos: completude, consistência, tratamento de edge cases, implicações de segurança.

Testes de conformidade. Suítes de teste derivadas diretamente da spec. Não “o código funciona?”, mas “o código faz o que a spec diz, e só o que a spec diz?”

Trilhas de auditoria. Quem escreveu a spec. Quem revisou. Qual contexto foi fornecido ao agente. Qual modelo gerou o código. Quando, e com quais parâmetros.

Política de limites. O que o agente pode decidir sozinho. O que precisa de aprovação. O que está proibido. Sem essas fronteiras, o agente preenche lacunas com inferência. E inferência sem constraint é a definição operacional de risco.

Nada disso é novo. São práticas de engenharia de software que existem há décadas. A novidade é que precisam ser aplicadas a um artefato que, até ontem, era um documento informal de requisitos que ninguém auditava.

A Oportunidade que Saboo Sinaliza Sem Perceber

O argumento de Saboo, lido com generosidade, aponta para algo importante: o PM que domina a formulação de intenções e a curadoria de contexto tem uma vantagem real. Concordo. Essa é uma competência valiosa.

Mas a competência individual do PM não substitui governança organizacional. Um piloto excelente ainda precisa de checklist de voo. Um cirurgião brilhante ainda segue protocolo cirúrgico. Não porque são incompetentes, mas porque sistemas complexos exigem verificações que não dependam da memória ou do julgamento de uma pessoa.

O PM que escreve specs impecáveis e o PM que escreve specs medíocres produzem, ambos, código em minutos. A diferença entre os dois só aparece em produção. E quando aparece, frequentemente já é incidente.

Governar a especificação não é burocratizar a inovação. É reconhecer que, quando a spec dirige a máquina, a qualidade da spec é infraestrutura crítica.

Na Victorino Group, ajudamos organizações a construir governança para desenvolvimento assistido por IA. Se suas specs estão gerando código sem controles formais, o risco já existe. A questão é quando ele se materializa. Entre em contato: contato@victorino.com.br