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.
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.
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.
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:
Not all of the above tools handle the relationship between spec and code the same way.
Spec-First:
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.
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.
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.
For a visual explanation of this decision framework and tool landscape, watch this walkthrough:
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 our Knowledge Hub for detailed guides on workflows, best practices, and OpenSpec.
Originally published on https://intent-driven.dev
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.