Why Intent-Driven Engineering May Not Need Another Spec Framework

Why Intent-Driven Engineering May Not Need Another Spec Framework

Intent-Driven Engineering Turns Claude Code Into a Repeatable Enterprise Software Delivery System — Without Forcing Developers Into Another Workflow

The software industry is quickly trying to answer an important question:

How do we make AI-generated software development repeatable, governable, auditable, and scalable?

One answer gaining attention is spec-driven development.

The idea makes sense.

Before an AI coding agent starts generating software, give it a structured specification describing what needs to be built. Projects such as OpenSpec and other spec-driven approaches attempt to formalize that process.

There is real value in this thinking.

But I believe there is another question worth asking:

If Claude Code already provides the development environment, repository intelligence, agents, skills, commands, MCP integration, hooks, planning, testing, and execution capabilities, do we really need another framework sitting between the developer and the AI?

For many organizations, I believe the answer may be no.

What we need isn’t necessarily another specification system.

What we need is intent, context, orchestration, validation, and governance around the AI development engine we already have.

That is where Intent-Driven Engineering fits.

Spec-Driven Development Solves a Real Problem

First, this should not be viewed as an argument against specifications.

AI coding agents perform better when they understand:

• What needs to be built

• Why it needs to be built

• What is in scope

• What is out of scope

• Architectural constraints

• Acceptance criteria

• Validation requirements

• Expected outcomes

Giving an agent a vague prompt such as:

“Build an order API.”

forces the model to make numerous decisions itself.

A structured artifact is far better.

For example:

Business Intent

    ↓

Feature Intent

    ↓

Scope

    ↓

Constraints

    ↓

Acceptance Criteria

    ↓

Implementation

That part of spec-driven development is absolutely correct.

The question is not whether structure is valuable.

The question is:

How much infrastructure do developers need around that structure?

The Risk: Solving Developer Complexity With More Developer Complexity

Enterprise software development is already complicated.

Developers work across:

• IDEs

• Git repositories

• Jira

• Confluence

• CI/CD platforms

• Cloud environments

• security tools

• observability platforms

• architecture standards

• internal frameworks

Now AI arrives.

We should be careful not to respond by giving developers yet another workflow to learn.

Another configuration model.

Another specification hierarchy.

Another CLI.

Another set of lifecycle commands.

Another directory structure.

Another abstraction developers must understand before they can deliver software.

At some point, the mechanism designed to simplify AI development can itself become another source of complexity.

That is the architectural concern.

Claude Code Already Provides the Execution Environment

Claude Code changes the equation because it is not simply a code generator.

It is a repository-aware software engineering environment.

From the developer’s perspective, much of the required AI development infrastructure already exists.

Claude Code can work with:

• Repository context

• CLAUDE.md instructions

• Plans

• Slash commands

• Skills

• Subagents

• Hooks

• MCP servers

• Terminal commands

• Builds

• Tests

• Git

• Pull-request workflows

• CI/CD automation

And it operates where developers already work.

The developer can remain inside the repository and development environment rather than moving between multiple AI workflow systems.

That matters.

The best enterprise AI workflow may ultimately be the one developers barely notice.

Intent-Driven Engineering Takes a Different Approach

Intent-Driven Engineering starts with a simple idea:

Tell the AI what outcome matters before telling it what code to write.

The basic workflow can be extremely lightweight.

Business Intent

      ↓

Intent File

      ↓

Context

      ↓

Plan

      ↓

Implementation

      ↓

Validation

      ↓

Delivery

The Intent File might simply be:

/intents/customer-order-status.md

Inside it:

# Intent

Allow authenticated customers to retrieve

the status of an existing order.

## Desired Outcome

Customers can retrieve order status through

the existing REST API.

## Scope

- Add GET order status endpoint

- Use existing authentication

- Follow existing controller patterns

## Out of Scope

- New authentication mechanisms

- Database schema changes

- UI changes

## Acceptance Criteria

- Valid order returns HTTP 200

- Unknown order returns HTTP 404

- Unauthorized request returns HTTP 401

- Existing tests continue to pass

That may be all Claude needs to start its engineering process.

No separate specification platform is necessarily required.

The Repository Becomes the Operating Model

This is an important distinction.

Instead of introducing another platform, the repository itself can contain the AI operating model.

For example:

repository/

│

├── CLAUDE.md

│

├── intents/

│   └── feature.md

│

├── .claude/

│   ├── skills/

│   ├── agents/

│   └── settings.json

│

├── src/

├── tests/

└── .github/

Now the pieces have clear responsibilities.

CLAUDE.md

Defines repository-wide engineering rules.

Intent files

Define the desired outcomes.

Skills

Package repeatable engineering workflows.

Agents

Provide specialized engineering capabilities.

Hooks

Enforce lifecycle behavior.

MCP

Retrieves enterprise context.

Tests and CI/CD

Determine whether the result is acceptable.

The repository becomes both the software project and the AI execution environment.

Intent Is the Steering. Claude Code Is the Engine.

A simple way to describe the architecture is:

Claude Code is the engine. Intent is the steering.

We can extend that model.

Intent

  =

Direction

Claude Code

  =

Engineering Engine

MCP

  =

Enterprise Context

Skills + Agents

  =

Reusable Capability

Hooks

  =

Process Enforcement

Tests

  =

Verification

CI/CD

  =

Governance and Delivery

Together these components create something much larger than AI-assisted coding.

They create an AI software delivery system.

From Prompting to an Operating Model

The enterprise problem is not really:

How do we write better prompts?

The larger question is:

How do we turn AI software generation into a repeatable engineering process?

That requires several layers.

Business Intent

        ↓

Structured Intent

        ↓

Approved Context

        ↓

Planning

        ↓

Specialist Agents

        ↓

Implementation

        ↓

Automated Validation

        ↓

Testing

        ↓

Pull Request

        ↓

Deployment

        ↓

Observability

That workflow can be implemented directly around Claude Code.

Developers don’t necessarily need to learn a second AI development framework to participate.

This Is Where Intent Differs From a Traditional Specification

A traditional specification frequently describes what the system should contain.

Intent emphasizes what outcome the system should achieve.

Consider the difference.

Specification-oriented thinking

Create:

OrderStatusController

OrderStatusService

OrderStatusRepository

Add:

GET /orders/{id}/status

Intent-oriented thinking

Customers need to retrieve the current

status of an order securely.

Reuse the existing architecture.

Do not introduce another persistence mechanism.

The implementation is successful when

the defined acceptance criteria pass.

The second approach leaves implementation decisions to the repository-aware engineering system while still constraining the outcome.

That is particularly powerful when the AI can inspect the repository itself.

Repository Awareness Changes Specification Requirements

This is one of the biggest differences between traditional software specification and modern agentic development.

Historically, humans needed extensive documentation because the developer receiving the requirements might not understand the system.

A repository-aware AI agent can inspect:

• Existing controllers

• Existing services

• Existing APIs

• Testing conventions

• Error handling

• Security patterns

• Dependencies

• Architecture

• Previous implementations

Therefore the intent artifact does not necessarily need to repeat information already present in the repository.

This leads to an important principle:

Don’t describe to the AI what it can reliably discover for itself.

That reduces duplication.

It reduces stale documentation.

And it reduces tokens.

Don’t Spend Any Token Before It’s Time

This also connects directly to one of the principles behind Intent-Driven Engineering:

Don’t spend any token before it’s time.

The same principle applies to developer complexity.

Don’t introduce another abstraction before it is necessary.

Don’t retrieve context before it is necessary.

Don’t invoke specialist agents before they are necessary.

Don’t generate implementation details before the intent is understood.

And don’t create another developer-facing platform if the existing engineering environment can already support the workflow.

Structure is valuable.

Ceremony is not automatically valuable.

What About Governance?

This is often where people assume a larger specification framework becomes necessary.

But enterprise governance does not have to depend upon developers manually following a specification process.

It can be automated.

Imagine every repository automatically checking:

Intent exists                     PASS

Acceptance criteria defined       PASS

Approved MCP sources used         PASS

Architecture rules followed       PASS

Build completed                   PASS

Unit tests completed              PASS

Security validation completed     PASS

Human approval received           PASS

PR checks completed               PASS

Deployment policy satisfied       PASS

That is governance.

And much of it can be implemented using:

• Skills

• Hooks

• CI/CD pipelines

• repository policies

• automated tests

• MCP restrictions

• GitHub rules

• security tooling

The developer doesn’t need to manually operate a governance system.

The system governs the workflow.

That is a much more scalable enterprise model.

The UI Should Observe the Process, Not Complicate It

There is still an important role for a UI.

But I would approach that UI differently.

Instead of forcing developers to perform their engineering work inside another specification application, the UI can become an Intent-Driven Engineering Control Center.

It observes what is already happening.

For example:

BUSINESS INTENT

      ↓

FEATURE / INTENT

      ↓

MCP CONTEXT

      ↓

PLAN

      ↓

AGENTS

      ↓

TASKS

      ↓

VALIDATION

      ↓

PR

      ↓

DEPLOYMENT

Then engineering leaders can see:

• Current intents

• Agent activity

• Context sources

• Task progress

• Build status

• Test results

• Pull requests

• Deployment status

• Token consumption

• Cost

• Governance

• Audit history

The developer continues working in Claude Code.

The organization gains visibility around the process.

That separation is important.

Developer Experience Matters

Enterprise architecture sometimes focuses heavily on governance and forgets the people actually writing the software.

If every AI engineering initiative requires developers to understand:

• another DSL

• another lifecycle

• another configuration system

• another UI

• another CLI

• another workflow

adoption becomes harder.

Intent-Driven Engineering should move in the opposite direction.

The ideal developer experience might eventually look something like this:

1. Open repository.

2. Select intent.

3. Claude reads repository standards.

4. Claude retrieves required context.

5. Claude creates a plan.

6. Developer approves or refines it.

7. Agents implement the work.

8. Hooks and tests validate it.

9. CI/CD governs delivery.

That’s it.

The complexity exists behind the developer rather than in front of the developer.

OpenSpec and Spec-Driven Development Still Have a Place

There will absolutely be environments where a formal specification framework makes sense.

Organizations may want:

• formal specification governance

• cross-tool compatibility

• independent specification artifacts

• highly regulated documentation

• structured change-management processes

• teams using multiple AI coding platforms

Those are legitimate requirements.

This is therefore not an argument that OpenSpec or specification-driven development is wrong.

It is an argument for asking a simpler architectural question first:

Can the tools we already have accomplish the outcome without introducing another layer?

If the answer is yes, simplicity has significant value.

The Bigger Opportunity

The more interesting opportunity is not creating another place where developers write specifications.

It is creating a repeatable operating model around AI engineering.

Imagine thousands of developers working across hundreds of repositories.

Each repository follows the same fundamental model:

Intent

+

Repository Standards

+

Approved Context

+

Reusable Skills

+

Specialized Agents

+

Automated Validation

+

CI/CD Governance

Developers retain flexibility.

Enterprises gain consistency.

AI agents gain context.

Architects gain governance.

Leadership gains visibility.

And the organization gains a repeatable software delivery system.

From AI Coding Tool to Enterprise Delivery System

Claude Code by itself is an extraordinarily capable engineering tool.

But an enterprise needs more than a capable agent.

It needs a system.

Intent-Driven Engineering provides the layer around the agent that makes execution:

Repeatable.

Auditable.

Governed.

Observable.

Measurable.

Scalable.

And it can potentially accomplish those goals without requiring every developer to adopt yet another development framework.

That may ultimately be the most important architectural principle:

The future of enterprise AI development may not belong to the organization with the most elaborate specification process.

It may belong to the organization that gives AI clear intent, the right context, strong boundaries, automated verification, and then gets out of the developer’s way.

The Intent-Driven Engineering Model

                BUSINESS OUTCOME

                       │

                       ▼

                     INTENT

                       │

                       ▼

               REPOSITORY CONTEXT

                       │

              ┌────────┴────────┐

              │                 │

             MCP           CLAUDE.md

              │                 │

              └────────┬────────┘

                       ▼

                     PLAN

                       │

                       ▼

              SPECIALIST AGENTS

                       │

                       ▼

                IMPLEMENTATION

                       │

                       ▼

                  VALIDATION

                       │

                       ▼

                 TESTS / HOOKS

                       │

                       ▼

                  PR / CI-CD

                       │

                       ▼

                   DEPLOYMENT

                       │

                       ▼

                OBSERVABILITY

Claude Code is the engine.

Intent is the steering.

The repository is the operating environment.

Automation provides governance.

And the developer gets to focus on delivering the outcome.