Git WorkTrees let you check out multiple branches simultaneously in separate directories — each with its own working state. Combined with SubAgents in OpenCode, this unlocks genuine parallel feature development inside a Spec-Driven Development workflow.

The key is knowing where each step of the OpenSpec workflow belongs: proposal on main, implementation in worktrees, archive after merge.

Propose on the Main Branch

Always run /opsx:propose (or /opsx:explore + continue) on the main branch, never inside a worktree branch.

OpenSpec’s proposal step analyses your active changes alongside the source-of-truth specifications to detect conflicts and gaps. If you propose from a worktree branch, OpenSpec only sees that branch’s delta — it loses visibility into other in-flight changes and the authoritative specs on main. Proposing on main keeps everything in view.

Once a proposal is created, you can immediately start on the next proposal for a different feature, still on main. Proposals are lightweight — they don’t touch implementation yet.

Apply with SubAgents and WorkTrees

With proposals ready on main, hand each one off to a SubAgent with its own WorkTree. Each SubAgent works in an isolated branch, applying its change independently. Because worktrees share the same git object store, you get true parallelism without duplicating the repository.

Before a worktree branch is eligible to merge, run Verify inside that same SubAgent session. Verify checks that the implementation matches the proposal’s spec, design, and task artifacts. Running it within the worktree ensures verification before merge so that we can address any issues flagged in the report within that worktree.

Merge First, Then Archive

Once a worktree branch passes Verify, merge it back to main before running Archive. Archive syncs the change’s delta specs into the source-of-truth specifications on main. If you archive while still on a worktree branch, the spec merge runs against an incomplete view of main — other merged features aren’t visible yet — and conflicts become likely.

The rule: merge → archive, in that order, every time. You can Archive each change individually after its merge, or merge all completed worktrees first and then run Bulk-Archive in one pass.

Commit Discipline

More commits means more recovery points. Aim to commit at every logical boundary:

• After the change proposal is created, or after each proposal artifact is generated individually (spec, design, tasks)
• After each logical code change inside the worktree branch
• After running Archive (the spec sync is a meaningful state change)

There is no such thing as too many commits in this workflow. If a SubAgent session goes wrong mid-apply, a dense commit history gives you a clean point to resume from rather than starting over.

Video

For a reference skill that automates the bulk-apply workflow, see the openspec-bulk-apply-change skill.

For worktree-based skills, Superpowers is worth exploring — it provides a skill framework designed to work with git worktrees.

Read the full article on intent-driven.dev →

Originally published on intent-driven.dev on April 01, 2026

What is a Brownfield Project?

The term “Legacy code” has many definitions, the most relatable IMHO is how Michael Feathers defines it in his book Working Effectively with Legacy Code. Any code that does not have tests is effectively legacy.

Similarly “Brownfield”, in the context of SDD, can be defined as projects that were not built based on specs. The only artifact that is available to us is the implementation or the code itself.

Can We Reverse-Engineer Specs?

In theory, we can reverse-engineer it. A quick way to achieve it is by using tools like repomix to pack the code into smaller sizes and give it to an LLM along with context of the SDD tool we are using. This can help generate the overall spec.

In practice, however, AI-generated specs are often inaccurate. The model doesn’t fully capture the original developer’s intent or the subtle nuances embedded in the code. The result is a spec that looks plausible on the surface but diverges from reality. This can’t be trusted as a foundation for future development.

The Issues with Reverse-Engineering

Reverse Engineering the spec itself can be quite involved. And even if we do, reviewing the specs may not be practical.

In the context of Test-Driven Development, when dealing with legacy code which does not have tests, should we start by writing all the tests first? That is not practical. In Feathers’ work in Working Effectively with Legacy Code the approach taken is largely to cover the area of code change with tests to first establish current behavior (characterization tests). Then we can test drive the remaining code.

Similarly it is a lot more practical to incrementally author specs for brownfield projects.

There is also the problem of alignment loss. A reverse-engineered spec is a derived artifact. When new features are developed against a misaligned spec, the risk of regressions and unintended side effects rises sharply, because the spec no longer reflects the real ground truth of the system.

Why Incremental is Better

The incremental approach focuses specs on a single, upcoming change rather than attempting to capture the whole codebase at once. Before making a modification, you author a spec for just that area — the change you are about to make. This is far more economical: the scope is bounded, the context is fresh, and the resulting spec accurately reflects intent.

Over time, this practice compounds. Each change leaves behind a spec that covers its slice of the system. As spec density grows in frequently touched areas, those sections start to behave like greenfield zones. The coverage builds naturally where it matters most.

For a deeper look at how this applies at scale, see my article on Enterprise Spec-Driven Development on InfoQ.

Brownfield Spec-Driven Development with OpenSpec

Use a Custom Profile and the Explore → Continue Workflow

When applying SDD to brownfield projects with OpenSpec, prefer using a custom OpenSpec profile over the default propose command. For more information on custom profiles, please see OpenSpec 1.2 release blog post.

The recommended workflow for brownfield is:

1. /opsx:explore — explore the change and understand the codebase before any spec is written
2. Review the exploration output
3. /opsx:continue (or fast-forward through artifacts) — progress through proposal, spec, design, and tasks one at a time

In brownfield projects reviewing each artifact individually gives you more control over what gets generated thereby keeping the spec grounded in the real codebase.

Pass Codebase Context During Explore with Repomix MCP

During the explore phase, pass context about the existing codebase using Repomix MCP. This educates the AI on the brownfield codebase before spec writing begins, so the resulting artifacts reflect the actual system rather than assumptions.

Example command:

/opsx:explore I would like to remove the maybe option in RSVP, use repomix mcp to understand existing code

Repomix packages your codebase into a format the AI can consume directly, giving the explore phase accurate grounding in what already exists.

For large codebases, tools like Repomix are especially helpful in managing context window usage.

Conclusion

Incremental approach gives you control, accuracy, and progressively growing coverage, without requiring a big upfront investment in reverse-engineering specs that may not hold up. You start where the work is, build specs that reflect genuine intent, and let the brownfield gradually transform over time.

To see this in action, watch the video below. It walks through a real-world example demonstrating how to use RepoMix to package an existing codebase, feed it to an AI model for analysis, and then author a targeted spec for the next change.

Read the full article on intent-driven.dev →

Originally published on intent-driven.dev on March 10, 2026

OpenSpec 1.2 is officially released.

The 1.2 release focuses on balancing workflow simplicity from 0.x releases with advanced customization introduced in release 1.0.

OpenSpec Profiles and Schemas

The primary addition in 1.2 is profiles, which manage the command workflow.

Profiles

• Core Profile: The new default uses a simplified process: explore, propose, apply, and archive. The propose command generates all change proposal artifacts at once.
• Custom Profile: Provides access to advanced commands, allowing you to step through proposal artifacts individually using the continue command, or generate them all at once using the fast-forward command.

Schemas

While profiles manage workflow, schemas control which artifacts are generated during the proposal phase. The default OpenSpec schema is “Spec-Driven,” which generates proposal.md, spec.md, design.md, and tasks.md.

Custom schema examples include:

• Minimalist: Reduces output to strictly spec and task artifacts.
• Event-Driven: Tailored for event-driven architectures with specialized artifacts.

Customizability

Release 1.2 balances keeping basic workflow easy to adopt while retaining customizability essential for enterprise-scale adoption.

Read the full article on intent-driven.dev →

Originally published on intent-driven.dev on February 25, 2026

An agentic harness is the execution layer that channels LLM capability into useful work. It does this by combining the model’s reasoning with tools, workflow control, memory, and guardrails. For sustained autonomous execution, it relies on sufficiently structured context that makes intent, constraints, and success conditions explicit. Without this structure, the agent may act in ways that are not aligned with the intended outcome. This results in constant supervision being necessary.

In order to achieve sustained autonomous execution without the risk of losing alignment between intent and implementation, we need to close the gap in shared understanding. The Intent Harness fills this void by helping transform ideas into well-articulated intent that an agent can execute with less supervision.

Intent Harness

Most useful ideas do not begin as fully formed specifications. They begin as intuition.

A team senses a feature that should exist. A product manager sees a pattern in customer behavior. An engineer notices an architectural weakness. A founder feels that a workflow should be simpler. Sometimes that intuition comes from expertise. Sometimes it is supported by data. Either way, it starts out incomplete.

That incompleteness is not a flaw. It is actually useful.

Intuition is valuable precisely because it leaves room to explore options, test assumptions, and discover better paths before committing to implementation. The problem is not that ideas begin vaguely. The problem is what happens when we send that vagueness straight into an execution system.

Without a disciplined process for clarification, the result is shallow prompting, weak task framing, and low-quality execution. The agent may still produce output, but that output remains tightly coupled to constant human supervision.

The Intent Harness exists to solve this. Being a layer above the Agentic Harness, its job is to help humans articulate intent clearly before execution begins. It achieves this by enabling dialog between humans and AI to establish shared understanding. Just as the agentic harness helps channel raw LLM capability into useful work, the intent harness helps channel raw intuition and ideas into well-engineered intent.

Spec-Driven Development plays a major role here by giving that intent a structured, reviewable form. It helps us harness intent without forcing us to prematurely lock down every detail.

That means creating a system that helps us:

• examine an idea from multiple angles
• challenge assumptions
• make constraints explicit
• define success criteria
• decide what should and should not be built
• break work into meaningful units before execution starts

Harness Engineering

If the questions we ask, the review discipline we apply, and the framework we use to think all shape the resulting intent, then the quality of that system is critical. Engineering the harness determines how well we articulate intent and how much reliable autonomy we can expect from our agents.

Weak intent engineering produces weak execution:

• specs become shallow
• task boundaries become fuzzy
• review becomes ceremonial
• agents need constant correction

Strong intent engineering produces better outcomes:

• clearer specifications
• better task decomposition
• earlier surfacing of ambiguities
• longer, more focused independent agent execution

This is why the conversation around AI-assisted delivery should not stop at model capability or coding-agent ergonomics. The real leverage increasingly comes from the quality of the harness that shapes intent before execution starts.

Looking at it from this angle, how we interpret bugs, mismatches, and execution failures also changes.

Image from my InfoQ article about Spec-Driven Development Adoption at Enterprise Scale.

A defect in implementation is not always just an implementation problem. Sometimes it is a signal that the harness itself needs improvement.

For example:

• a bug in code may point to a gap in the spec
• a gap in the spec may point to insufficient human review
• insufficient review may point to a pattern of high-volume, low-quality specs being generated
• the structure and quality of those specs may ultimately indicate a weak workflow

Seen this way, execution failures are not only quality issues in the output. They are also feedback on the quality of the system that produced the output.

That is an important shift.

It means we should not ask only, “Why did the agent get this wrong?”

We should also ask, “What in our elicitation, specification, review, or validation process allowed this ambiguity to survive?”

This is where the harness metaphor becomes genuinely useful. The purpose of the harness is not just to make the agent productive. It is to make the overall human–AI system learnable and improvable.

Closing thoughts

A good Intent Harness should do more than help teams generate artifacts. Its primary responsibility is to enable human and AI collaboration that helps elicit intent thoroughly, encourages meaningful review, and ultimately ensures alignment between intent and implementation.

This post is a living document. I intend to continue updating it.

Read the full article on intent-driven.dev →

Originally published on intent-driven.dev on February 23, 2026

Read the full article on InfoQ: Spec-Driven Development – Adoption at Enterprise Scale

In the OpenSpec 1.0 release post, I mentioned how config.yaml lets you tailor the OpenSpec workflow to your team’s needs. Custom schemas take that idea further. Instead of just configuring the workflow, you define the artifacts themselves, shaping what gets generated and in what order.

OpenSpec ships with a default schema called spec-driven. It produces four artifacts in sequence: proposal.md, specs.md, design.md, and tasks.md. Each artifact feeds into the next, creating a deliberate path from idea to implementation. This works well for general-purpose projects, but not every project may fit that mold.

Custom Schemas

I built a few custom schemas to explore what different workflows could look like: openspec-schemas on GitHub. Let us look at what is in this repository.

Example 1: The Minimalist Schema

Not every project needs four artifacts we discussed above. For well-scoped, low-risk changes, the minimalist schema strips the workflow down to two: specs.md and tasks.md.

Specs are authored as user stories with Given/When/Then acceptance criteria. Tasks follow directly from those specs. There is no separate proposal or design step. Details like tech stack and project constraints live in config.yaml, so the schema can stay lean without losing context.

This is a good fit when the scope is clear and the team does not need a formal proposal or design review before moving to implementation.

Example 2: Event-Driven Architectures

For complex systems built around asynchronous messaging, the event-driven schema adds discovery and modeling steps before the usual spec-design-task flow.

The workflow starts with event storming, capturing domain events, commands, actors, and bounded contexts. Next, event modeling transforms those into structured flows with Mermaid diagrams that visualize interactions and timelines. From there, the schema moves through specs.md and design.md into AsyncAPI spec generation, producing a validated asyncapi.yaml before any implementation tasks are created.

This schema is purpose-built for teams working with message brokers and event-driven patterns, ensuring that the async contract is specified and validated before code is written.

Getting started with custom schemas

The quickest way to get started is with the OpenSpec CLI. To create a new schema from scratch:

openspec schema init my-workflow --description "My custom workflow" --artifacts "specs,design,tasks"

This scaffolds a complete schema folder under openspec/schemas/my-workflow/ with a schema.yaml and starter templates for each artifact.

To start from an existing schema and customize it:

openspec schema fork minimalist

This copies the schema into your project as minimalist-custom, ready for you to modify. You can also provide a custom name:

openspec schema fork minimalist my-lightweight

You can also grab schemas directly from the openspec-schemas repository by copying a schema folder into your project’s openspec/schemas/ directory.

Once a schema is in place, set the schema field in your config.yaml to activate it:

schema: minimalist

context: |
  Project: My project
  ...

OpenSpec resolves schemas in this order:

1. Project-level — openspec/schemas/<name>/schema.yaml in your repo
2. User-level — your global OpenSpec config folder (e.g. ~/.openspec/schemas/<name>/schema.yaml) for schemas shared across projects
3. Built-in — schemas bundled with the OpenSpec package (like spec-driven)

The first match wins. This means a project-level schema always takes precedence, so you can override a built-in schema without modifying the package.

Understanding what is inside a schema

If you want to understand how a schema works or build your own, here is what is inside. A schema is a folder containing a schema.yaml file and a templates/ directory with the Markdown templates it references. Using the minimalist schema as an example:

openspec/
├── config.yaml
└── schemas/
    └── minimalist/
        ├── schema.yaml
        └── templates/
            ├── specs/
            │   └── spec.md
            └── tasks.md

The templates/ directory contains the Markdown files referenced by the template field in each artifact definition.

The schema.yaml defines the artifacts, their output paths, templates, and dependencies:

name: minimalist
version: 1
description: Lightweight schema for well-scoped, low-risk changes
artifacts:
  - id: specs
    generates: specs/**/*.md
    description: Specifications authored as user stories with Given/When/Then acceptance criteria
    template: specs/spec.md
    requires: []
  - id: tasks
    generates: tasks.md
    description: Implementation checklist with trackable tasks
    template: tasks.md
    requires:
      - specs
apply:
  requires:
    - tasks
  tracks: tasks.md

Each artifact declares what it generates, which template to use, and what it requires before it can be created. The apply block tells OpenSpec which artifact gates implementation and which file tracks progress.

Video Walkthrough

Custom schemas let OpenSpec fit your process rather than the other way around. Pick one from the schemas repository or use it as a starting point to build your own.

Read the full article on intent-driven.dev →

Originally published on intent-driven.dev on February 12, 2026

View the full-size workflow diagram →

OpenSpec 1.0 is officially released.

In an earlier post, I wrote about how the OpenSpec workflow anchors development to specs as the source of truth, ensuring that what gets built stays aligned with what was intended. This spec-anchored approach has been central to OpenSpec from the beginning.

In this post, let us look at some of the major changes that come with the 1.0 release.

Explore Before You Build

One of the most significant additions is the Explore Mode. Before diving into implementation, you can now use OpenSpec to think through ideas which require more clarity, investigate problems, and clarify requirements.

Step-by-Step Generation

OpenSpec 1.0 introduces a more deliberate artifact creation process. Instead of generating everything at once, you can now step through each artifact such as proposal.md, design.md, etc. one at a time.

This step-by-step approach helps improve the review process as each artifact can be checked before the next one is generated.

Intent Verification

Before archiving a completed change, OpenSpec now includes a verification step. This checks that the implementation actually matches what was specified in the change artifacts. It’s a final checkpoint that catches any intent alignment issues.

Noteworthy mentions in 1.0 release

The config.yaml file in OpenSpec 1.0 looks really interesting.

Seamless Integrations

OpenSpec’s config system makes it straightforward to integrate with external tools. For example, you can connect OpenSpec with Linear using MCP to automatically sync issues and track progress. I had earlier achieved this by forking and modifying OpenSpec, that may not be necessary anymore.

Customizable Workflows

Beyond integrations, config.yaml lets you tailor the OpenSpec workflow to your team’s needs.

Video Walkthrough

Read the full article on intent-driven.dev →

Originally published on intent-driven.dev on January 26, 2026

There are three high-level topics that often come up during my discussions with people trying to adopt Spec-Driven Development (SDD):

1. The Starting Point: Can I pick a story from my existing backlog in Jira, Azure DevOps (ADO), or GitHub Issues?
2. Roles and Handoffs: Do all my team members, including the Product Team, now require Git access just to view the specs?
3. All artifacts in a single monorepo: While colocation of artifacts may have its advantages, should we risk overcrowding the repository with business use cases, technical designs, tasks, and code?

While many of us eventually switch to entirely new workflows, adoption is much smoother when we provide onboarding ramps. It helps to see the value of SDD before making fundamental changes to how we work. In this article, I attempt to address these questions through a demo workflow using OpenSpec for SDD and Linear for product planning.

Starting Where the Backlog Lives

One of the most frequent questions I get regarding Spec-Driven Development (SDD) is: Where is the starting point? Should you pick a story from Jira, Azure DevOps, or Linear? The answer is: Wherever your backlog lives. If that is where your requirements start, that is where your SDD workflow can begin. With most SDD tools largely focused on maintaining all artifacts in a single place, it can take a while to figure out how we integrate them into our workflows. We may also need to sync progress back to the team and keep everyone in the loop without forcing non-developers into a code repository. In this walkthrough, I use Linear and OpenSpec to explore a workflow that lets us use a project management tool or board view alongside an SDD-based workflow.

Click here to view the workflow diagram →

It is easy enough to feed a ticket to an AI agent. But what happens as the agent makes progress? In a typical siloed workflow, the developer has to manually update the ticket status. In this walkthrough, I demonstrate how OpenSpec (via MCP) can handle the paperwork for you. As the agent moves through the Propose, Apply, and Archive stages, the corresponding Linear issue automatically shifts from Backlog to In Progress and finally to Done. This ensures that the source of truth for project status is updated in real-time, without manual intervention.

Roles and Handoffs

A common friction point in SDD is the Git barrier. Do Product Owners or stakeholders now need to learn Git to view the latest application specifications? By keeping the product backlog in Linear in sync with the specs in the repo, we can address this point to an extent.

• Product Owners can stay in the tools they love (like Linear) to define the business use case and monitor progress.
• Developers/Agents handle the technical detailing of the use cases and implementation within the repository.

This workflow uses the backlog as a communication bridge, allowing for human-AI collaboration without forcing every role into the codebase.

Separate the What from the How

An important point to think about is the separation of concerns.

• The What: The business use cases and acceptance criteria (stored in Linear or other product backlogs).
• The How: The technical design and detailed task list (stored in the Git Repo).

Maintaining this separation is a necessary first step in addressing another important point, which is about the suitability of SDD for non-monorepo code organization. If we can separate the “What” from the “How”, then whether the “How” is handled in a monorepo or several repos (example: frontend, backend, etc.) can be tackled later.

Click here to view the workflow diagram in full size

GitHub code: OpenSpec Linear MCP fork

What’s Next?

To keep this article focused, I have not yet touched on:

• Multi-repo use cases: How to manage specs that span across code repos.
• AI-Assisted Backlog Generation: Using AI to help write the stories in the first place.
• And more: Parallel implementation of stories, sync issues, etc.

I will be covering these in future articles.

I would love to hear your feedback. How are you integrating SDD into your existing toolset? Are you finding success in syncing your AI progress back to your project management boards?

Read the full article on intent-driven.dev →

Originally published on intent-driven.dev on January 11, 2026

Click here to view the diagram in full size

Before selecting a tool for Spec-Driven Development (SDD) it is good to get a bearing on our workflow and the level of rigor our project demands. This post intends to provide a practical way of thinking through which tool to use.

Context Engineering Approaches

Before we jump into Spec-Driven Development, itself let us quickly look at how it differs from “Plan Mode”. This is a question I often get asked and thought I will start with that first. There are two ways to look at Context Engineering.

Tactical (Plan-Mode)

What it is: Best for rapid problem-solving. We create a plan or to-do list to think through the solution, build it, and then discard the plan. The code is the only long-term asset. Now based on our preference for CLI vs IDE based tools, there are several choices. Here are some examples that I have used.

Tools:

• Claude Code (CLI): Plan mode creates temporary implementation plans
• Antigravity (IDE): Implementation plans that guide development. Even though the plan appears in your IDE window it is not part of your repo.

Strategic (Spec-Driven)

What it is: Here the specification is a first-class citizen. It is as important as the implementation itself. Maybe even more important in comparison to the code itself (Theoretically, we can generate the code all over again if we have the spec). These specs are persistent and version controlled or stored through other means.

Again here, based on our preference for CLI vs IDE based approaches we have several choices.

Tools:

• IDE
  • Kiro
• CLI
  • OpenSpec
  • SpecKit
  • BMAD-Method

Other Considerations

1. Levels of “Spec-Driven”

Not all of the above tools handle the relationship between spec and code the same way.

Spec-First:

• Tools: Kiro, SpecKit
• Philosophy: The purpose of the spec is to articulate intent. Over time, the code and spec might not be aligned.

Spec-Anchored:

• Tool: OpenSpec
• Philosophy: In addition to articulating intent, the spec remains aligned at all times with the implementation.

For a deeper dive into the spec-anchored philosophy, see my LinkedIn post on Spec-Driven Development with OpenSpec: Source of Truth Specification.

2. Rigor vs. Speed

How many steps do you actually want to follow?

• Lightweight (3-4 phases): OpenSpec
• Comprehensive (Full Agile lifecycle): BMAD-Method

More rigor is not always better, it depends on how much groundwork we have already done. If we already have stories in our familiar tools like Linear, GitHub boards, Jira, etc. then maybe better to choose a tool that works with smaller features. If we want to think through a solution from an overall nebulous idea, BMAD may be necessary.

3. Legacy Code and Lock-in

Compatibility: Greenfield vs. Legacy

• Greenfield-friendly: Most tools work well with new projects where you can establish patterns from day one
• Legacy-specialized: OpenSpec claims to be specifically designed to handle the complexity of existing codebases (brownfield and 0 to 1 projects)

Exit Strategy: Portability and Lock-in Since most of us are evaluating these tools, it may be a good idea to see if the approach allows being able to switch from one tool to another without context loss when we switch spec formats.

Video Walkthrough

For a visual explanation of this decision framework and tool landscape, watch this walkthrough:

Conclusion

Better not to overthink it, start with the tool that feels most aligned with your workflow, and adjust as you learn what works for your team.

Want to dive deeper into spec-driven development practices? Explore the Knowledge Hub for detailed guides on workflows, best practices, and OpenSpec.

Read the full article on intent-driven.dev →

Originally published on intent-driven.dev on December 26, 2025

Article Summary

The article contrasts two approaches to AI-assisted coding, arguing that workflow structure—not just technical limitations—determines success in maintaining alignment between original intent and final implementation.

The Vibe Coding Lifecycle

How Vibe Coding Works:

The workflow follows a linear loop: single-line prompt → general-purpose agent interpretation → code generation → human review → iteration. This approach optimizes for speed and momentum using chat-based interfaces.

Implicit Assumptions Accumulate:

Each prompt focuses on immediate concerns, causing agents to revise earlier decisions. “Constraints that were previously implied or loosely stated are weakened or forgotten.” Over time, corrections become fragile, creating a sustained negotiation loop where humans repeatedly restate intent.

The Spec-Driven Development Workflow

Spec-driven development emphasizes establishing clear intent before implementation through four phases with review gates:

Phase 1: What (Specify/Propose/Requirements)

• Feature requirements and acceptance criteria
• User needs and business goals
• Scope, boundaries, and non-goals
• Success metrics

Phase 2: How (Design/Plan)

• Architecture and technical approach
• Technology and pattern choices
• Data models, APIs, and interfaces
• Risks and dependencies

Phase 3: Task (Granular Steps with Checks)

• Small, verifiable work items
• Clear validation criteria per task
• Explicit dependencies and ordering
• Testing and verification strategy

Phase 4: Build (Implementation)

• Tasks executed sequentially or in parallel
• Validation against acceptance criteria
• Automated tests run
• Implementation reviewed against specs

Conversation Matters

The article explains that spec-driven development facilitates “structured conversation between humans and coding agents.” Specs function as scaffolding to “clarify and stabilize intent” rather than serving as documentation ends in themselves. This aligns with Agile values emphasizing collaboration.

Key Insight

Vibe coding prioritizes speed with minimal planning, suitable for prototypes and scripts.

Spec-driven development prioritizes intent alignment through structure and validation, better suited for production systems and team environments.

The critical differentiator is intent management: “Vibe coding accepts deviation as a cost of speed. Spec-driven development reduces deviation by introducing structure, review gates, and explicit intent articulation.”

Read the full article on intent-driven.dev →

Originally published on intent-driven.dev on December 15, 2025