When the Spec Is the Product, Who Governs the Spec?

Shubham Saboo, a PM at Google, recently published a thread that crystallized something the industry has been circling for months. His argument: the PM role is shifting from “translation layer between business and engineering” to “intent formation.” AI agents can turn well-formed specs into working code. The PM’s job becomes problem shaping, context curation, and evaluation.

He is right. And the implications are bigger than he thinks.

The Shift Is Real

Spec-Driven Development (SDD) has moved from blog-post theory to documented practice. ThoughtWorks included it in their 2026 Technology Radar. Martin Fowler’s team published analysis of spec-first workflows. GitHub shipped a Spec Kit framework. Anthropic’s engineering blog describes spec-driven agent orchestration as their internal default.

The numbers back it up. 84% of developers now use AI coding tools, producing 41% of all new code (GitHub, Stack Overflow 2026 surveys). PR cycle times dropped 75% in Copilot-assisted workflows. What used to take a team two weeks can now reach a working prototype in hours.

Saboo’s “context curation checklist” captures the new PM discipline well: define the problem space clearly, provide the right context at the right level of abstraction, set boundaries, evaluate output quality. This is genuinely useful advice.

But it stops at the demo.

The Missing Half

When a spec drives code generation directly, the spec becomes the control surface. Not the code. Not the test suite. The spec.

This changes the risk profile of product management in ways Saboo’s framework does not address. Consider what his checklist omits:

Compliance traceability. Regulated industries need to demonstrate that requirements flow from policy to implementation. When an agent generates code from a spec, who certifies that the spec itself satisfies regulatory constraints? SOC 2, HIPAA, PCI-DSS all require documented control flows. A PM’s “context curation” is not an audit trail.

Security review of generated output. Veracode tested over 100 LLMs in 2025 and found that 40-48% of AI-generated code contains security vulnerabilities. The agent does not flag its own blind spots. It produces plausible, functional, insecure code with complete confidence.

Failure mode management. VentureBeat’s 2026 coverage of agentic AI in production found consistent patterns: brittle context windows, broken refactors, missing operational awareness. Agents optimize for the spec as written. They do not account for the spec’s silences.

Institutional knowledge preservation. When agents mediate the relationship between PMs and engineers, organizational knowledge stops accumulating in human teams. The spec becomes the single point of truth, but specs decay when nobody maintains the understanding behind them.

The Quality Crisis Hiding in Speed

The productivity numbers are real. So are the quality numbers, and they tell a different story.

Google’s DORA 2025 report found that a 90% increase in AI tool adoption correlated with 9% more bugs and 91% more time spent in code review. Not less. More. The speed increase in code generation created a downstream bottleneck in code verification.

Stack Overflow’s 2025 survey of 49,000+ developers found that 66% cite the “almost right” problem as their primary concern with AI-generated code. Trust in AI output declined to 60%. Developers are producing more and trusting it less.

The “almost right” problem is particularly dangerous at the spec level. A spec that is 95% correct looks complete. It passes human review because the missing 5% involves edge cases, failure modes, or regulatory nuances that only surface under production load. The agent implements the spec faithfully. The spec was wrong. Nobody catches it until a customer does.

Red Hat’s February 2026 analysis put it bluntly: “vibe coding” is unsuitable for production systems handling regulated data. The gap between a compelling demo and a compliant deployment is not a tooling problem. It is a governance problem.

40% Failure Before Production

Here is the number that should concern every PM excited about SDD: over 40% of agentic AI projects fail before reaching production (Composio 2025, Company of Agents 2026 surveys).

Not 40% underperform. 40% never ship.

The failure pattern is consistent. Teams achieve rapid prototyping results. Stakeholders see a demo and approve production deployment. Then the project hits the wall of operational requirements: error handling, monitoring, rollback procedures, access controls, data validation, compliance documentation.

These are not PM skills. They are not “taste.” They are governance, operations, and engineering discipline. Saboo’s framework assumes the hard part is forming the right intent. In practice, the hard part is everything that happens after the intent produces working code.

Spec Governance as Infrastructure

The organizations getting this right treat spec governance as infrastructure, not as a PM competency.

What does that look like in practice?

Spec review as a formal stage. Before any agent touches a spec, it passes through security, compliance, and architecture review. Not after code generation. Before. The spec is the artifact that matters. Reviewing generated code is reviewing a symptom.

Boundary enforcement in the spec itself. Explicit “never do” lists, permission tiers, and compliance constraints embedded in the specification. Not as guidelines for the PM, but as machine-readable constraints the agent must respect.

Automated verification of generated output. Conformance test suites derived from specs, run automatically against every generation cycle. Not manual review (which does not scale) but programmatic validation that the output matches the spec and the spec matches the policy.

Audit trails from requirement to deployment. Every spec version, every generation run, every review decision, every production change linked in a chain that a compliance officer can follow. This is table stakes in regulated industries. SDD makes it harder to maintain, not easier.

Human-in-the-loop at governance checkpoints, not everywhere. The goal is not to slow everything down. It is to place human judgment where it matters most: at the points where a wrong spec becomes a production incident.

The Taste Trap

Saboo argues that “evaluation and taste” become the PM’s most important skill. There is truth in this. Someone needs to judge whether the output is good.

But taste is subjective, inconsistent, and unauditable. You cannot demonstrate to a regulator that your PM had good taste. You cannot replay a taste decision when an incident occurs. You cannot scale taste across a 200-person product organization.

Governance is not a replacement for taste. It is the structure that makes taste decisions visible, reviewable, and accountable. An organization that relies on PM taste alone for spec quality is an organization running production systems on individual judgment with no safety net.

Where This Goes

SDD is not going away. The economics are too compelling. A well-formed spec that produces working code in hours will always beat a months-long development cycle for the right class of problems.

The question is whether organizations build the governance layer that makes SDD safe for production, or whether they continue treating it as a PM workflow improvement and absorb the consequences.

The data suggests consequences are already accumulating. More bugs, more review time, declining trust, 40%+ failure rates. These are not teething problems. They are the predictable result of compressing development cycles without expanding governance to match.

Saboo captured the front half of the SDD shift accurately. The back half, where specs become production artifacts that need the same governance rigor as code, is where most organizations have not yet arrived.

The spec is the product now. Treat it like one.

At Victorino Group, we help organizations build governance infrastructure for AI-driven development. When specs drive production systems, spec quality is not a PM skill. It is an organizational capability. Reach us at contact@victorinollc.com.