Spec-Driven Development: OpenSpec vs Tiden
A spec alone won't tell you whether the product still works after a change, what else it touched, or who signed off. Here's how OpenSpec and Tiden compare.
Spec-driven development (SDD) tells a team how to write intent down before an agent builds. But a spec on its own will not tell you whether the product still works after the change, what else the change touched, or who signed off on it. Tiden supports the full spec-driven flow of planning, review, implementation and verification. It also adds what SDD frameworks leave out: a living specification kept as a graph, cross-impact analysis, risk-based regression and an evidence trail. At worst, Tiden complements a team's existing SDD practice. At best, it replaces a stack of loosely connected tools.
Two spec styles: change specs and a system graph
OpenSpec is a free, open-source framework that adds a lightweight spec layer to a repository, so a developer and an AI agent agree on what to build before code is written (OpenSpec). Its core idea is delta tracking: each change is captured as a scoped diff against a source-of-truth spec.
A change in OpenSpec lives in its own folder with four artifacts (OpenSpec schema): proposal.md, specs/ (delta spec), design.md, tasks.md.
Delta specs mark only what changes, using ADDED, MODIFIED, REMOVED and RENAMED operations. On archive, the deltas merge into the main specs and the change folder moves to an archive. The workflow is clean and practical for evolving existing codebases, and it is change-scoped. Each change is described on its own, and the system-level spec is whatever the merges leave behind.
Tiden takes a different approach. It maintains one living specification for the whole system, structured as a graph of behaviors, relationships and dependencies. The graph stays up to date as the code changes, the way a codebase does.
Why a graph changes what is possible
A flat set of spec files can describe a change. A graph can answer questions about the system. When a change touches one behavior, the graph shows which other behaviors, integrations and flows depend on it, something a delta spec cannot see because it only describes the change itself. That impact map tells Tiden where to spend test effort, so regression follows risk. And because the spec covers the whole product, gaps between behavior and tests are visible across the entire system.
The same model keeps agents grounded. Stale specs mislead agents, which will confidently execute a plan that no longer matches reality (Augment Code). With Tiden, agents work from current, connected context, and product managers, QA and engineers review and work from that same living model. People and agents share one source of truth.
Spec-driven development is supported in Tiden
Tiden does not ask developers to change how they plan. The spec-driven flow works inside it:
- Plan. Developers can plan with an agent in their normal workflow. Specifications can also be generated inside Tiden with the backlog or review status to be developed later.
- Review. Specs are reviewed before implementation, individually or together with the team, in plain language.
- Implement. The approved spec guides the build with any coding agent.
- Verify. Tiden checks what was delivered against the original intent and shows what was fulfilled, what was missed and what evidence supports the result. Whether that intent is right for the business stays with humans.
A reviewed plan does not guarantee the agent follows it. In one internal Tiden engineering example, a plan was reviewed before a multi-component change, and the agent still deviated and simplified the task without being asked. Approval of a spec does not prove the implementation satisfies it, which is why verification has to be part of the system.
What spec-driven development does not give you on its own
SDD frameworks solve one problem: getting intent written down before the agent builds. Several capabilities that teams need are outside their scope:
- Keeping specs current. Spec drift, where the implementation changes and the spec does not, is a documented failure mode of SDD (TechMagic). OpenSpec's own docs say that when the code is right and the spec is stale, the delta spec must be updated before archive, because archiving merges the spec into the source of truth (OpenSpec docs). Keeping specs aligned is a manual step.
- Independent verification. OpenSpec's
/opsx:verifychecks implementation against the artifacts in one change folder. It looks at completeness, correctness and coherence. It belongs to the expanded workflow, and the default core profile does not include it. The check is run by the AI assistant itself, typically the same one that wrote the code, so verification is not independent (verify skill file). Tiden verifies against existing tests and adds tests over time to raise coverage. - System-level checks. A community proposal, Issue #880 on the OpenSpec repo, asks for a command that checks code against the living specs, because verify only covers the change artifacts. That request describes a need for system-level checks that the framework does not yet provide. Tiden does.
- Regression and cross-impact. A delta spec describes one change. Nothing in the format tells a team what else that change can break.
- Enforcement and records. OpenSpec's output is advisory, and the report is a to-do list for reconciliation (OpenSpec docs). There is no quality gate and no lasting record of what changed, why and who approved it.
Together, these gaps explain why SDD alone does not make agent-written code safe to release. It improves the input to the agent. It does not govern the output.
Side by side comparison
| OpenSpec (change specs) | Tiden (system spec graph) | |
|---|---|---|
| Spec unit | One change folder: proposal, delta spec, design, tasks | One living specification for the whole system, kept as a graph |
| How the system view forms | Deltas merge into main specs on archive | Maintained continuously, like code |
| Keeping it current | Manual reconciliation before archive | Updated and verified on every change |
| Cross-impact of a change | Not part of the format | Graph shows what a change can affect |
| Verification | Optional /opsx:verify on one change, run by the agent | A system of tests checks every change against captured intent |
| Regression | Outside the change, not checked | Impact mapping and risk-based regression |
| Planning and review | Proposal and design files in the repo | Specs generated, reviewed and approved in Tiden, individually or as a team (optional) |
| Enforcement | Advisory | Quality gate with evidence-based sign-off |
| Record | A report in the chat | Lasting evidence trail of what changed, why and who approved it |
| When it runs | When someone runs it | As part of the development loop |
| Production error monitoring | Not in scope | Error tracking that routes issues back to requirements and adds tests |
Use only Tiden or both together
Teams that already write OpenSpec specs have intent in a form Tiden can take in. A simple way to combine them is to use OpenSpec to write the change spec and Tiden to prove it holds, on every change, with any agent. In that setup Tiden complements the practice and fills the gaps listed above.
Teams that want one system across the SDLC can plan, review and verify in Tiden alone. Either way, the question that matters is the same: after the latest merge, does the product still do what was intended, and what else did the change touch?