Spec-Driven Development Is Winning. It Still Needs Someone to Run It.

Spec-Driven Development Is Winning. It Still Needs Someone to Run It.

Something real is happening in enterprise software delivery.

Over the last year, spec-driven development has moved from a niche engineering pattern into a serious enterprise conversation. The idea is simple, and it is right: stop asking AI to generate production software from loose prompts. Start giving it structured specifications that humans can review, systems can execute, and teams can measure.

That shift matters.

A good specification gives AI-assisted development a stronger foundation. It reduces ambiguity. It gives developers, architects, product owners, and reviewers a shared reference point. It creates something better than a prompt and more durable than a conversation. It gives the work a shape.

But in a real enterprise engineering organization, the spec is not the whole operating model.

It is one layer.

The question is not only whether a feature matched a specification. The bigger question is whether the organization is getting better at deciding what should be specified, how it should be delivered, and whether it produced the outcome the business actually needed.

That is where the next layer becomes necessary.

What spec-driven development does well

Spec-driven development brings discipline to AI-assisted software delivery.

Instead of relying on a developer to repeatedly prompt an AI tool until the output looks right, the team creates a structured specification first. That specification becomes the contract for implementation. It can define the behavior, constraints, acceptance criteria, data expectations, integration points, test coverage, and review standards.

That is a major improvement over prompt-driven coding.

It gives the AI agent something more concrete to execute against. It gives the human reviewer something clearer to inspect. It gives the team a better chance of producing code that matches the intended behavior.

In practical terms, spec-driven development helps answer an important question:

Did this unit of work match what we said we wanted?

That is a valuable question. Every enterprise delivery team needs a better way to answer it.

But there is another question above it.

Did we choose the right work, define the right outcome, deliver it safely, and improve the organization’s ability to do it again?

That question lives above the individual spec.

The layer above the spec

Intent-Driven Engineering operates at that higher layer.

It is not a replacement for spec-driven development. It is the operating model that connects business intent, engineering execution, AI-assisted delivery, governance, and measurable impact.

Spec-driven development helps govern a single delivery loop.

Intent-Driven Engineering helps govern many delivery loops running across multiple pods, repos, systems, and teams.

The difference is altitude.

A spec helps a team build a feature correctly. An intent helps an organization understand why the feature exists, what outcome it is expected to create, how it should be measured, and whether the delivery system is improving over time.

That matters because enterprise software delivery is rarely one clean feature in one clean repository.

It is usually a portfolio of work moving through multiple teams, dependencies, environments, governance checkpoints, and production constraints. One pod may be moving fast. Another may be blocked by unclear requirements. Another may have strong code generation but weak testing. Another may be using AI tools heavily but producing no measurable business improvement.

The organization needs a way to see across all of that.

That is the role of Intent-Driven Engineering.

From intent to impact

The core loop is straightforward:

Define Intent.

Compile Action.

Deliver Impact.

At the team level, that becomes a repeatable delivery path:

Intent.

Repo understanding.

Plan.

Code.

Test.

Review.

Deploy.

Measure.

The important part is not just that AI helps write code. The important part is that the organization creates a repeatable path from business intent to validated production outcome.

That path gives teams a common operating rhythm.

It also gives leadership something more useful than activity metrics. Lines of code, prompt counts, tool usage, and feature throughput all have their place, but none of them prove that the organization is delivering better outcomes.

Intent-Driven Engineering focuses on outcome-based measurement.

Two metrics matter most.

Intent-to-Impact Velocity

Intent-to-Impact Velocity measures how long it takes a defined business intent to become a validated operational outcome.

Not how fast code was generated.

Not how many prompts were used.

Not how many pull requests were opened.

The measure is simpler and more meaningful: how long did it take for the original intent to become something real, delivered, verified, and useful?

That changes the conversation.

A team that generates code quickly but stalls in review, UAT, DevOps, or production has not really improved delivery. It has only moved the bottleneck.

A team that ships fast but creates instability has not improved the system either. It has created future work.

Intent-to-Impact Velocity keeps the focus on the full delivery path, not just the coding phase.

Enterprise Execution Index

Enterprise Execution Index measures the organization’s ability to deliver safe, fast, repeatable change.

It is a composite view of the delivery system, including:

Intent clarity.

Time to validated delivery.

Production stability.

Human hours reduced.

Automation coverage.

Observability.

Governance.

Cross-team dependency reduction.

Recovery and iteration speed.

This matters because speed without control is not transformation. It is risk.

At the same time, control without speed is not transformation either. It is ceremony.

The Enterprise Execution Index gives leaders a way to see whether the operating model is actually improving. Are teams getting clearer? Are handoffs shrinking? Are dependencies being reduced? Are tests and observability improving? Are production issues going down? Is AI reducing human effort, or just moving the work into new forms of review and cleanup?

That is the level of measurement enterprise AI delivery needs.

Why both layers matter

Spec-driven development and Intent-Driven Engineering solve different problems.

Spec-driven development helps ensure that a specific unit of work is built against a clear specification.

Intent-Driven Engineering helps ensure that the organization is selecting the right work, executing it through a repeatable model, and measuring whether it created impact.

Both are necessary.

A strong spec without organizational intent can still produce well-formed work that does not matter.

A strong intent without disciplined specification can still produce ambiguity, drift, and inconsistent execution.

The best model connects both.

Intent defines the business outcome.

The spec structures the work.

The repo-aware delivery loop executes the change.

The review process validates quality.

The deployment path proves operational readiness.

The measurement layer confirms impact.

That is the full system.

Where this becomes real

This is not just a theory about how AI-assisted delivery should work.

On the Zayo ZSP Platform Modernization program, this operating model was applied to the delivery of thirteen TM Forum-standard APIs as AWS production microservices. The work used a repeatable path from intent through implementation, testing, review, deployment, and measurement.

The important lesson was not simply that AI could accelerate parts of delivery.

The lesson was that acceleration only matters when it is attached to a clear operating model.

The same pattern applies across larger engineering groups. When multiple pods are using AI-assisted development tools, they need more than access to the tools. They need shared entry points, shared standards, shared skills, shared agents, shared governance, and shared measurement.

Otherwise, every team creates its own version of “AI delivery.”

That may look innovative at first, but it does not scale cleanly.

Intent-Driven Engineering gives the organization a common structure without removing team-level autonomy. Teams can still work inside their own repos, workflows, and delivery contexts. But the enterprise gains a consistent way to define intent, execute work, measure outcomes, and improve the delivery system over time.

The operating model matters

A lot of organizations are discovering that simply deploying AI coding tools does not automatically create ROI.

That should not be surprising.

The tool can help generate code. It can help explain systems. It can help create tests, refactor components, draft documentation, inspect errors, and accelerate many parts of the software lifecycle.

But the tool does not decide whether the organization has clear intent.

It does not automatically fix weak acceptance criteria.

It does not remove unclear ownership.

It does not solve environment instability.

It does not align twelve pods around a common definition of done.

It does not prove that delivered work created business impact.

Those are operating-model problems.

And when AI is added to a weak operating model, the weakness usually becomes more visible. Sometimes it even moves faster.

That is why the next phase of enterprise AI delivery will not be won by code generation alone. It will be won by organizations that can connect intent, specification, execution, governance, and measurement into one repeatable system.

The practical takeaway

Spec-driven development is a major step forward.

It gives AI-assisted delivery a better contract. It helps teams move beyond loose prompting. It creates more reliable execution paths and stronger review surfaces.

But enterprise delivery still needs a layer above the spec.

It needs a way to decide what work matters.

It needs a way to measure whether that work created impact.

It needs a way to compare execution maturity across teams.

It needs a way to improve delivery capability month over month.

It needs a way to make AI-assisted development measurable, governable, and repeatable.

That is the role of Intent-Driven Engineering.

Spec-driven development helps answer whether the code matched the spec.

Intent-Driven Engineering helps answer whether the organization is getting better at turning business intent into delivered impact.

Both layers matter.

The spec helps the team build the thing right.

The intent helps the enterprise build the right thing, prove it worked, and get better at doing it again.This version keeps your core claim but removes the “industry scoreboard” feel. It reads more like a durable Wix article: architectural, practical, and executive-friendly without sounding like a rebuttal post.