All posts

OpenSpec Is Automating Its Best Feature

Specs survive only inside workflows. OpenSpec's announced agent harness aims to automate its loop. Right bet, if the human review seams survive.

Misha Druzhinin
Diagram of OpenSpec's explore, propose, apply, and archive loop, with the two human review seams between steps highlighted in orange.

OpenSpec’s best feature was never its specs. It was the workflow. On October 15, 2026, OpenSpec founder Tabish (@0xTab) announced the project is “about to get 10x better.” The new version is built around a custom agent harness, shaped by a year of user feedback.

Our read: OpenSpec is moving from a workflow you run by hand to a workflow that runs itself. That’s the right bet. More than five decades of spec-driven development show that specs only survive inside workflows. The risk is that OpenSpec’s workflow was valuable because of its manual pauses. Automation exists to remove pauses.

Key Takeaways

  • In spec-driven development’s history, spec documents mostly failed: heavy formal methods, IEEE requirement documents, model-driven code generation. Spec workflows survived: TDD, BDD, API-first, pull requests.
  • OpenSpec’s real innovation is its change-based loop: explore, propose, apply, archive. The archive step merges each approved change into the living spec, which keeps it from going stale.
  • The announced agent harness could turn that loop from a discipline into an engine that enforces it.
  • The risk: the workflow’s value lived in its human seams. Automate those and you get rubber-stamped specs.
  • Judge the preview on one thing: does it automate the busywork and keep the decisions human?

Why do spec documents fail while spec workflows survive?

A spec stays alive only when a workflow forces people to touch it on every change. That pattern holds across five decades. Formats come and go. The ones without a working loop around them go stale.

Spec as document Spec as workflow
Examples VDM, Z, IEEE 830, UML/MDA TDD, BDD, OpenAPI, pull requests
When the spec is touched Once, up front On every change
What keeps it current Good intentions A step nobody can skip
Typical fate Stale or abandoned Still in use

The spec-as-document era

  • Heavy formal methods (1970s onward). Building on Hoare logic (1969), VDM and Z notation specified whole systems mathematically. Outside avionics and rail signalling, the spec was often judged too costly to write, so most teams skipped it. Bertrand Meyer’s lighter Design by Contract fared better, because its pre- and postconditions live inside the code as assertions.
  • Requirements documents (1970s to 1990s). Waterfall-era processes and IEEE 830 specifications produced binders of “the system shall…” sentences. They were written once, approved once, and out of date by the time code shipped.
  • Models as source (1990s to 2000s). CASE tools, UML, and the OMG’s Model-Driven Architecture (2001) promised code generated from models. Round-tripping broke. Developers edited the generated code, and the models were abandoned.

All three bet on the artifact. None included a routine that kept the artifact connected to the code as it changed.

The spec-as-workflow era

  • Test-driven development (early 2000s). Kent Beck’s lasting contribution is a loop more than a file format: red, green, refactor. The spec survives because writing it is step one of every change.
  • Behavior-driven development (2006) and Specification by Example (2011). Given / When / Then matters less than the routine around it. Teams agree on examples before work starts, then run them as tests in CI. It’s the same idea behind how we design evals for AI agents.
  • API-first design (2011 onward). Swagger, later OpenAPI, won because contract, review, generate, implement became the default order of work between teams.
  • Pull requests. The most successful spec-review practice in software is rarely called one. Propose a change, discuss it, approve it, merge it into the source of truth.

When AI agents started writing code, the field split along the same line. Birgitta Böckeler’s review of Kiro, Spec Kit, and Tessl sorts tools by how tightly the spec stays tied to code: spec-first, spec-anchored, or spec-as-source. That’s a question about the artifact. The more useful question is which tools got the workflow right.

What OpenSpec got right

OpenSpec got the shape of the loop right, not the format of the specs. Its Markdown requirements and WHEN/THEN scenarios borrow directly from BDD. The value is in the core loop, documented in the Fission-AI/OpenSpec README:

/opsx:explore  →  /opsx:propose  →  /opsx:apply  →  /opsx:archive
    think            agree              build           merge into truth

Four design choices make it work:

  1. The unit of work is a change, not a whole system. propose creates a change folder with proposal.md, spec deltas, design.md, and tasks.md. You never write “the full spec” up front. That’s why OpenSpec works on existing codebases, where most real work happens.
  2. Agreement happens before code. propose and apply are separate commands with a human in between. That gap is where you review intent while changing direction is still cheap.
  3. Archive closes the loop. /opsx:archive merges the approved delta into the canonical specs. Document-era specs lacked this step. Pull requests had it for code; OpenSpec brings it to intent.
  4. It’s light enough to run every time. No dedicated IDE and no heavyweight phase gates. Slash commands work across 30+ AI assistants, including Claude Code, Cursor, Codex, and GitHub Copilot.

OpenSpec is essentially the pull-request loop applied to intent, with an agent doing the typing. The specs are a byproduct. The project has passed roughly 72,000 GitHub stars. Its rivals lean on process instead: Kiro ships a dedicated IDE, and Spec Kit adds phase gates.

What the agent harness changes

The harness is meant to change who keeps the workflow running. Until now, OpenSpec ran on human discipline. You had to remember to propose before coding, read the proposal, apply it, and archive. The host agent didn’t know a workflow existed. It received slash-command prompts, and nothing stopped it from skipping a step or drifting mid-implementation.

The announcement promises a “completely new way to experience OpenSpec.” Its stated goals: developers stay involved in key decisions, understand what agents did, and trust the output. If the workflow is the product, owning the runtime that executes it is the logical next step. Here’s what we’d expect it to do:

  • run explore, propose, apply, verify, and archive as a pipeline, not as commands you have to remember (/opsx:verify already exists in OpenSpec’s expanded command profile);
  • enforce what used to be convention: no code before an approved proposal, verification before archive, an archive on every merge;
  • move the human from running steps to approving them.

That’s the honest reading of the claim. The specs won’t be ten times better. The workflow stops depending on human memory.

Why automating the workflow is the right bet

Automating the workflow is right for three reasons.

Discipline doesn’t scale, but automation does. Workflows that depend on people remembering steps get skipped under deadline pressure. That’s how each document-era approach died. TDD survived through CI. OpenAPI survived through code generation.

Agents need workflows more than humans do. A developer drifting from the spec is a code-review problem. Picture an agent drifting across 40 files in three parallel sessions: that’s a structural problem. Only something that controls the loop can keep agents on track. We made a similar argument about designing an agent’s shape before its prompts.

It’s defensible. Slash commands and Markdown templates are easy to copy. Host tools keep shipping their own plan modes. A workflow engine is much harder to absorb. OpenSpec’s Stores feature (in beta), which shares planning across repositories, points the same way.

Where could automation break the workflow?

The workflow’s value lived in its seams, and automation is designed to remove seams. That’s the central risk.

The pause between propose and apply was where a human paid attention. Running archive was a deliberate statement: this is now the truth. The manual steps added friction, but that friction was the review.

Automate the pipeline end to end and you risk a spec-shaped autopilot:

  • Rubber-stamped proposals. If they’re generated and auto-approved, spec review becomes a formality.
  • An archive of outcomes, not decisions. If archive merges whatever got built, the source of truth records what the agent did, not what you decided.
  • Rigor on paper only. Every step technically runs, and nobody is watching.

That would invert OpenSpec’s purpose. The workflow existed to keep human intent ahead of agent-written code. Take the human out of the seams and you’ve rebuilt vibe coding with extra Markdown. That’s the kind of mess our AI cleanup service exists for. As we argued in reliability takes design, the answer is better design, not more steps.

Five checks for the preview

The question to ask isn’t “how much does it automate?” It’s “which seams stay human?” We’d check five things:

  1. Is propose to apply still a real gate? Automated drafting is welcome. Automated approval defeats the purpose.
  2. Does it surface the few decisions that matter? Asking for approval on everything teaches people to approve without reading.
  3. Is verification mechanical? Checking code against WHEN/THEN scenarios, and showing where they diverge, is the most valuable thing a harness could add. It sharpens the human seam instead of removing it.
  4. Does archive stay intentional? The truth should be what was approved, not just what was produced.
  5. Is it still portable? The original workflow ran in any agent. If the engine only runs inside OpenSpec’s harness, the workflow becomes a feature of one tool. OpenSpec’s own README compares itself with Kiro on exactly this.

Frequently Asked Questions

What is OpenSpec?

OpenSpec is an open-source, MIT-licensed spec-driven development framework for AI coding assistants, built by Fission AI. It adds a lightweight spec layer so developers and agents agree on what to build before code is written. Its propose, apply, archive workflow runs across 30+ AI tools.

What did OpenSpec announce in October 2026?

On October 15, 2026, founder Tabish (@0xTab) announced a new version of OpenSpec built around a custom agent harness. An early preview is planned for the following week. The stated goals are keeping developers involved in key decisions, making agent work understandable, and increasing trust in the output.

How is spec-driven development different from TDD or BDD?

Spec-driven development applies the same idea, agreeing on behavior before implementation, to AI agents. TDD and BDD use executable tests as the spec. AI-era tools like OpenSpec use structured Markdown requirements and scenarios that both people and agents read, implement, and verify against.

The bottom line

More than five decades of spec-driven development teach one lesson: specs survive only when a workflow forces people to touch them. OpenSpec built its product around that lesson more directly than Kiro or Spec Kit. Propose, apply, archive is the pull-request loop for intent, and it was the real product all along.

The harness is the right next step: stop relying on people to run the workflow and let it run itself. But the workflow’s value lived in its pauses. If OpenSpec automates the busywork and keeps the human seams sharp, it becomes the workflow layer for agentic coding. If it automates the seams too, it becomes a tidy log of decisions an agent made for you.

One thing to do this week: take one in-flight change and run it through propose and apply by hand. Write down which pause actually caught a mistake. That’s the seam to protect when the harness arrives.

Sources