When Everyone Can Build, the Specification Becomes the Control Plane

One of the easiest mistakes in the current AI cycle is to treat vibe coding as a developer-productivity story.

It is certainly that. A developer can use an agent to explore a repository, create a plan, write code, run tests, and open a pull request. But the more important change is happening outside the traditional development organization. A claims analyst, credit-policy manager, operations lead, product owner, or adviser-support team can increasingly describe a problem and receive a working application, automation, or analytical tool in return.

OpenAI reported in June 2026 that knowledge workers represented about 20 percent of Codex users and were increasingly using it to build lightweight tools that previously required engineering support. That is one vendor’s usage data, not a census of enterprise development, but it captures the direction: the boundary between understanding a business problem and being able to build software around it is getting thinner. OpenAI: Codex for knowledge work

That changes the control problem.

The old governance model assumed that code entered through an engineering workflow, where developers, architects, security teams, and reviewers could resolve what the requirements left unclear. Democratized development weakens that assumption. The answer is not to force every useful idea back through the old bottleneck. It is to move the primary control point earlier—from reviewing code after it exists to governing the specification that tells people and agents what may be built.

When software creation is democratized, the specification becomes the enterprise control plane.

This post explains why spec-driven development has become much more important, what changed in the tooling during 2025 and 2026, and what a fully integrated enterprise specification should contain. The goal is not more paperwork. It is executable clarity before autonomous execution.

Vibe Coding Exposed a Specification Problem

A prompt can describe an idea. It is a poor place to preserve an institution.

Consider a commercial-lending operations manager who asks an AI coding agent to build a covenant-exception dashboard. The request may describe the screens, the spreadsheet currently used, and the desired email notification. A capable agent can produce a convincing application from that information.

The application can still be wrong in ways that are difficult to see in a demonstration. It may interpret a covenant differently from credit policy. It may allow a relationship manager to approve an exception that requires independent credit authority. It may retrieve borrower information through an unapproved interface, retain documents too long, or use a generic notification service that creates an incomplete audit record.

None of those failures requires obviously bad code. They arise because the system was asked to infer the enterprise around the code.

That is the weakness of prompt-driven development. The prompt becomes a temporary mixture of requirements, assumptions, architecture, policy, and personal memory. The generated code then becomes the most concrete description of what the system actually does. Review starts after the implementation has already collapsed many unresolved questions into technical decisions.

Spec-driven development reverses that sequence. It treats the specification as the primary artifact and the code as one implementation of it. Requirements, constraints, interfaces, tests, approvals, and operating expectations are made explicit before an agent is allowed to improvise their answers.

That does not make the work rigid. It makes ambiguity visible while changing it is still cheap.

Spec-Driven Development Has Crossed From Idea to Toolchain

Spec-driven development is not new. What is new is that agentic development systems can now use specifications directly enough to make them operational.

GitHub’s Spec Kit reached version 1.0 after its first year and describes a model in which code serves the specification. Its current agentic flow moves from a constitution through specification, clarification, planning, task decomposition, analysis, implementation, and convergence. Presets, workflows, and versioned bundles let organizations package their own method around that flow. GitHub: Spec Kit

Kiro has developed a similar practical structure around versioned requirements.md, design.md, and tasks.md artifacts. Its current specifications support both requirements-first and design-first work, parallel execution based on task dependencies, and synchronization when requirements or designs change. The important point is not that every enterprise should use those exact files. It is that the specification is becoming an active part of execution rather than a document left behind when coding begins. Kiro: Specifications

The coding agents around those specifications have also changed. Current platforms combine persistent repository instructions, specialized agents, reusable skills, MCP-connected context, and deterministic hooks. OpenAI supports parallel, long-running agent work; GitHub’s cloud agent can research, plan, implement, test, and open a pull request; Anthropic combines always-on instructions, skills, MCP, subagents, and hooks. OpenAI: Introducing the Codex app

This matters because autonomy multiplies ambiguity.

One agent misunderstanding a requirement can create a defect. Five agents working in parallel from the same weak prompt can create five internally consistent pieces that solve different versions of the problem. A specification gives parallel work a shared contract.

The instruction layer is also becoming less proprietary. AGENTS.md provides a predictable, open location for repository-specific guidance, while Agent Skills packages instructions, scripts, references, and templates into portable, version-controlled units that compatible agents can load when needed. Both patterns make it more realistic for an enterprise to preserve its development method independently of a single model or interface. Linux Foundation: Agentic AI Foundation

Finally, the knowledge connection is maturing. The July 2026 MCP specification introduced a stateless protocol core intended to improve reliability and scalability, while the Enterprise-Managed Authorization extension became stable in June 2026, allowing organizations to control MCP server access through their identity provider. Those developments do not make MCP a governance system, but they make it a more credible transport for connecting agents to governed policies, requirements, code catalogs, issue systems, and operational evidence. Model Context Protocol: July 2026 specification update

Together, these changes produce a recognizable operating model: persistent instructions establish the rules, specifications define the outcome and work, enterprise knowledge supplies authoritative context, specialized agents execute bounded tasks, deterministic gates enforce controls, and production evidence updates the specification.

That is not a better prompt. It is a different development system.

Enterprise SDD Is More Than a Requirements File

The three-part structure of requirements, design, and tasks is a useful development core. A regulated enterprise needs a larger specification stack around it.

The top layer is an enterprise constitution. It defines the rules that should not have to be rediscovered for every feature: risk tiers, ownership, approved technology, security principles, data-handling expectations, accessibility, records obligations, human-authority boundaries, and the kinds of action an AI-generated system may never take on its own.

Below that sits the business and process specification. This is where the domain owner defines the purpose, users, workflow, business rules, exceptions, and acceptance criteria. In a property-and-casualty claims tool, it should distinguish a recommendation from an adjudication, define when a claim leaves straight-through processing, and identify which decisions remain with an adjuster.

The policy and control specification translates institutional obligations into system behavior. It identifies approval authority, segregation of duties, prohibited outcomes, evidence requirements, and escalation conditions. This is where “follow credit policy” becomes a set of testable statements about limits, exceptions, reasons, and approvals.

The data and interface contracts identify what information may be read, changed, retained, and disclosed. They define schemas, APIs, events, lineage, entitlements, effective dates, and source precedence. This layer is especially important in financial services because the same customer or contract fact may exist in several systems while only one is authoritative for a particular decision.

The architecture and nonfunctional specification defines security, resilience, performance, observability, cost, deployment, and recovery expectations. A prototype can tolerate an unavailable service or a manually repaired record. A production claims, lending, wealth-management, life-insurance, or card-processing workflow cannot quietly inherit those assumptions.

The verification and evidence specification says how the organization will know the implementation satisfies the other layers. It includes conventional tests, policy tests, threat cases, evaluation sets, traceability, review evidence, and the conditions for release.

The generated test suite is not automatically independent evidence. Consequential controls still need challenge by people or systems that did not invent the implementation.

The final layer is the operations and change specification. It defines monitoring, rollback, incident handling, service ownership, and the changes that require reassessment. A specification that ends at deployment will drift away from the system as models, policies, data sources, dependencies, and business rules change.

The stack is deliberately broader than code. It describes the system the enterprise intends to operate, not merely the feature a developer intends to implement.

The Enterprise Knowledge Store Makes the Specification Real

A specification cannot carry every policy, procedure, standard, prior decision, and reusable component inside one document. It should point into a governed enterprise knowledge store that can supply the right material for the particular feature, user, jurisdiction, product, and effective date.

That store may combine document retrieval, a knowledge graph, a policy service, requirements repositories, architecture catalogs, code search, and operational records. Its implementation matters less than whether it can identify the authoritative source, owner, effective date, applicability, superseded material, implementing controls, and dependent systems.

A vector search result is not automatically an enterprise rule.

A connector does not make a source authoritative.

A newer document is not necessarily the effective policy.

The knowledge store therefore needs identity, entitlement, provenance, versioning, effective dating, applicability, and source precedence—not simply semantic similarity.

This is where previously built code belongs as well. The store should expose approved services, libraries, API clients, policy checks, test harnesses, interface contracts, and reference implementations. The safest generated authentication component is usually the one the enterprise has already reviewed. Spec-driven development should bias agents toward reuse and require an explicit reason when they depart from an approved pattern.

In that model, the agent does not “know the company.” It retrieves a bounded, attributable view of what the company has decided, and the specification records which decisions governed the implementation.

SDD Does Not Remove Risk. It Moves Risk Into the Open.

Spec-driven development is not a guarantee of correct software. A bad specification can produce bad software with exceptional efficiency.

The central risks become easier to name: incomplete requirements, stale policy, conflicting sources, weak acceptance criteria, spec-to-code drift, unbounded tool access, generated tests that merely confirm the implementation’s own assumptions, and human approvals that do not examine the consequential decisions.

That is still progress. Hidden assumptions are harder to challenge than explicit ones.

NIST’s Secure Software Development Framework is built around integrating secure practices into the development lifecycle rather than treating security as a final inspection. Its December 2025 draft of SSDF 1.2 emphasizes secure and reliable development, delivery, and improvement, while SP 800-218A extends the framework with practices specific to generative AI and foundation-model systems. NIST’s AI RMF organizes continuous risk management around Govern, Map, Measure, and Manage rather than treating approval as a one-time event. NIST: Secure Software Development Framework 1.2 draft

Modern SDD fits that direction when the specification is versioned, linked to controls and evidence, tested against the implementation, and updated from production behavior. It fails when the spec becomes another static artifact that everyone politely ignores after release.

The test of a specification is not whether it is complete enough to approve. It is whether it remains connected enough to govern.

What This Looks Like in a Financial Institution

Return to the covenant-exception application.

In a spec-driven model, the operations manager still begins with plain-language intent. The difference is that the platform turns that intent into a structured feature specification and then retrieves the relevant credit policy, approval matrix, borrower-data classification, standard identity pattern, notification service, logging requirements, and previously approved components.

The business specification defines a potential breach and the cases requiring action. The policy specification permits the application to identify and route an exception, but not waive a covenant. Data contracts identify the authoritative loan and borrower sources. Architecture requirements cover identity, connectivity, logging, and recoverable workflow state.

Verification uses known breaches, boundary cases, contradictory sources, and tests of delegated authority. Operations defines monitoring, rollback, ownership, and reassessment triggers.

Specialized agents can still work quickly. One can build the interface, another the service integration, another the policy tests, and another the deployment package. They are not collaborating through shared intuition. They are implementing the same contracts.

The resulting delivery record contains more than code. It contains the governing sources, approved specification, design decisions, tests, exceptions, reviewers, deployment identity, and evidence produced by the running system.

The same pattern applies to a life-insurance claims assistant, a wealth-management restriction checker, a property-claims triage tool, or a card-dispute workflow. The domain changes. The need to connect intent, authority, data, implementation, and evidence does not.

The CRO and CTO Own Different Parts of the Same Control Plane

The Chief Risk Officer should not own the development platform, and the CTO should not interpret every business policy. They do need a common operating model.

The business owner defines the intended outcome and accepts responsibility for whether the system solves the right problem. Risk, compliance, legal, and control functions define the boundaries, evidence, and challenge appropriate to the use case. Technology makes those decisions enforceable through templates, identity, repositories, approved components, knowledge connections, hooks, tests, deployment controls, and observability.

A useful division is simple:

The business owns intent. Risk owns boundaries. Technology owns enforceability.

The CRO’s contribution is a usable risk taxonomy, explicit authority limits, control objectives, source ownership, evidence standards, and a real exception process. The CTO’s contribution is a paved road on which those requirements are automatically attached to the work rather than remembered by each builder.

Neither executive should judge success by the number of prompts written or the amount of generated code. Better measures are the percentage of production changes linked to an approved specification, the percentage of controls tested automatically, reuse of approved components, unresolved spec-code drift, time required to assemble evidence, defect escape rates, and the speed with which policy changes propagate to affected systems.

That is how democratized development becomes an enterprise capability rather than a larger shadow-IT estate.

Conclusion: Govern the Intent Before the Code Exists

The old development model made code scarce and placed control around the people allowed to produce it. Agentic development makes code abundant. Rebuilding scarcity through approval queues would preserve control only by throwing away much of the value.

Spec-driven development offers a better answer. It lets more people describe and shape software while giving the enterprise a durable place to express policy, authority, architecture, data contracts, verification, and operating expectations. Modern agents, open instruction formats, reusable skills, deterministic hooks, and governed knowledge connections now make that model practical in a way it was not a few years ago.

The place to begin is not a universal specification bureaucracy. Choose one consequential workflow that business and technology both understand. Build the layered specification, connect it to authoritative knowledge and approved code, make the required tests and approvals executable, and keep the production evidence attached to the same record.

When everyone can build, reviewing the code is too late to be the primary control.

Govern the specification, and the code begins inside the enterprise rather than merely entering it at the end.