Introduction
At Yoma Fleet, we are always looking for ways to help our engineering teams build software that is not only fast to deliver, but reliable, maintainable, and aligned with what the business actually needs. In 2025, we introduced Vibe Coding as our AI-orchestrated development environment. In 2026, we are taking the next step: Spec-Driven Development (SDD). This guide explains what Spec-Driven Development is, why it matters in the age of AI coding agents, how the leading tools work, and how Yoma Fleet’s engineering team can apply it in practice: whether you are starting a new project, extending an existing feature, or modernizing a legacy system.
What Is Spec-Driven Development?
Spec-Driven Development is an approach where a specification document, the “spec”, is written before any code is generated. The spec becomes the shared source of truth that both human engineers and AI coding agents use to build, test, and validate software. The core insight is simple: AI coding agents are excellent at pattern completion, but they are not mind-readers. When you give an agent a vague prompt like “add photo sharing to my app,” the agent fills in thousands of unstated requirements with its own assumptions, and some will be wrong. A well-written spec eliminates that guesswork.
As GitHub’s engineering team puts it: instead of treating coding agents like search engines, we should treat them like literal-minded pair programmers who need unambiguous instructions.
There are three levels of how teams can apply SDD:
| Level | What It Means |
| Spec-First | A spec is written before the task begins, then set aside after the code is done. |
| Spec-Anchored | The spec is kept and updated alongside the code over time. It evolves as the feature evolves. |
| Spec-as-Source | The spec is the primary artifact. Humans only edit the spec; agents generate all code from it. |
Most teams starting with SDD today begin at the Spec-First level and grow into Spec-Anchored as their workflow matures.
Why SDD Matters for Yoma Fleet in 2026
In our work across Yoma Car Share, Yoma InnoSights, and our internal operations platform, we regularly face three development scenarios:
- New features in existing systems: Adding capabilities to a complex, running codebase is where misaligned assumptions cause the most damage. A spec forces clarity on how the new feature interacts with what already exists.
- Greenfield projects: When starting fresh, it is tempting to jump straight into code. A small investment in a spec ensures the AI builds what you actually intend.
- Legacy modernization: When rebuilding older systems, the original intent is often lost. A spec lets us capture essential business logic in a modern format before handing the rebuild to an AI agent. At Yoma Fleet, we also benefit from a shared specification because it solves the shared context problem: security requirements, compliance rules, coding standards, and integration constraints should be baked into every change, not added as afterthoughts or buried in a ClickUp thread no one can find.
The Spec-Driven Workflow
Regardless of the tool you use, the SDD process follows a clear sequence of phases. Each phase has one job, and you do not move forward until that phase is fully validated.
Phase 1 — Specify (The “What” and “Why”)
You provide a high-level description of what you are building and for whom. The focus here is on user journeys, experiences, and outcomes — not technical choices. Who will use this? What problem does it solve? What does success look like? The AI coding agent takes your description and generates a detailed specification document. This is a living artifact. As you learn more about your users and requirements, you update it. Example prompt to your agent:
> “We need a vehicle availability dashboard that lets fleet operators at Yoma Car Share see which cars are available, reserved, or under maintenance — by region, in real time. Operators should be able to filter by vehicle type and export the view as a PDF report.”
Phase 2 — Plan (The “How”)
Now you get technical. You tell the agent your architectural constraints, preferred stack, and any compliance requirements. The agent generates a comprehensive technical plan. If Yoma Fleet standardizes on certain technologies or patterns, this is where you state them. If there are performance targets or integration points, they go here. This phase also includes your constitution, a set of non-negotiable principles for the project. If your team is using GitHub Spec Kit, this is the /constitution command: it should run before /specify, so every later phase, spec, plan, tasks, and implementation, inherits the same rules from the start. For example:
- All APIs must use JWT authentication consistent with our existing auth service.
- Backend services must be written in Go.
- All database queries must go through our ORM layer, not raw SQL. The constitution ensures AI-generated code respects your engineering standards from the start.
Phase 3 — Tasks (Breaking It Down)
The agent takes the spec and plan and breaks them into small, reviewable tasks. Each task solves one specific piece of the puzzle and can be implemented and tested in isolation. Instead of “build the availability dashboard,” you get concrete items like “create a REST endpoint that returns vehicle status by region with pagination support.” This is similar to test-driven development; the tasks give the agent a way to validate its own work incrementally.
Phase 4 — Implement (Focused Execution)
Your coding agent works through the tasks one by one. Because the spec, plan, and tasks are all in place, you are reviewing focused, purposeful changes rather than thousand-line code dumps. The agent knows what to build, how to build it, and in what sequence. Your role at this phase is not just to accept outputs. It is to verify. Does each task result match the spec? Does the code meet the plan’s constraints? Are there edge cases the agent missed?
Tools: What Is Available in 2026
Three major toolkits have emerged in the SDD space. Here is how they compare for Yoma Fleet’s context.
| Tool | Format | Best for |
| GitHub Spec Kit (open source) | Seven slash commands, /constitution, /specify, /clarify, /plan, /tasks, /analyze, /implement, on top of Copilot, Claude Code, or Gemini CLI | New features in existing codebases or greenfield work on Copilot or Claude Code |
| Kiro (AWS) | VS Code extension and companion Kiro CLI, built around Requirements, Design, and Tasks documents in user-story format | Product-facing feature work where business analysts or product owners help write requirements, or terminal-first teams via Kiro CLI |
| Tessl (Agent Enablement Platform) | Governed package manager and registry for agent skills and context, installed and managed via the Tessl CLI; the original spec-as-source engine now lives inside it as the Tessl Framework, still in closed beta | Organizations that want to govern and reuse AI agent context at scale; the Tessl Framework specifically for teams exploring a spec-as-source pipeline |
GitHub Spec Kit (Open Source)
Spec Kit installs with a single command and creates a .specify/memory/constitution.md file alongside spec, plan, and task templates, plus agent-specific prompt definitions. The full workflow runs through seven slash commands: /constitution (define your non-negotiable engineering rules, the same constitution step in our Phase 2 above), /specify, /clarify (resolve ambiguities before planning), /plan, /tasks, /analyze (a read-only consistency check across spec, plan, and tasks before implementation begins), and /implement. Only /specify, /plan, /tasks, and /implement are mandatory for a lean pass; /clarify and /analyze are optional but recommended quality gates for anything beyond a small feature.
Kiro (AWS)
Kiro is a VS Code-based IDE extension, with a companion command-line tool, Kiro CLI, that carries over the same steering files and MCP configurations so teams can move between the IDE and the terminal without losing context. It guides you through three documents: Requirements, Design, and Tasks. It uses a familiar user story format (“As a fleet operator, I want to…”) with Given/When/Then acceptance criteria, making it accessible for teams that already write user stories in their sprint planning. Kiro is the most beginner-friendly of the three tools and has a lower setup overhead. However, it works best for mid-sized tasks; it can generate excessive documentation for small bug fixes.
Best for:Product-facing feature work where business analysts or product owners are involved in writing requirements alongside engineers, and terminal-first teams who want the same workflow outside an IDE.
Tessl (Agent Enablement Platform)
Tessl repositioned in January 2026 and is no longer marketed as a standalone spec-driven coding tool. It now describes itself as an Agent Enablement Platform: a governed package manager for agent skills and context, in effect an npm-style registry for the instructions and documentation your coding agents rely on. Teams install, version, and evaluate skills through the Tessl CLI and a public registry of thousands of evaluated skills and library-context tiles, with security scanning, ownership controls, and usage tracking layered on top. The original spec-as-source ambition has not disappeared. It now lives inside Tessl as the Tessl Framework, where specs in a specs/ folder generate and regenerate code directly, still in closed beta as of mid-2026 and, per independent review, still limited in scope. It is one feature inside a broader platform now, not the company’s core pitch.
Best for:Organizations that want to govern and reuse AI agent context and coding standards across teams. The Tessl Framework specifically suits teams willing to experiment with a fully spec-as-source model while it remains in closed beta.
Lessons from the Field
Thoughtworks Distinguished Engineer Birgitta Böckeler has been evaluating SDD tools in real codebases. Her findings offer practical guidance for teams like ours.
- Where SDD works well: Feature-sized tasks in existing systems, where the spec forces clarity on how new code connects to what already exists. Greenfield projects benefit from the upfront investment in the spec stage.
- Where to be careful: SDD tools can feel like overkill for small bug fixes or routine maintenance. A five-line fix does not need a requirements document. Use your judgment — SDD’s value is proportional to a task’s complexity and ambiguity.
- The review challenge: SDD tools generate many markdown files. The experience of reviewing a large spec, plan, and task breakdown can become tedious. At Yoma Fleet, we recommend treating spec review as a team activity — do it in a short sync session rather than in isolation. AI does not always follow instructions: Even with a full spec in place, AI agents can miss details, repeat existing code, or over-apply a rule from your constitution. Human review at every phase is not optional — it is the discipline that makes SDD reliable.
Best Practices for Engineering Teams
- Write the spec before the sprint, not during it. SDD’s upfront investment pays off in a sprint, treat spec creation as part of your backlog refinement process.
- Use the constitution for every project. Do not let engineering standards live only in your head or your wiki. Put them in the constitution where your agent can use them.
- Keep specs living documents. When requirements change, and they will, update the spec first, then update the plan, then update the tasks. This keeps the spec as the source of truth rather than letting the code drift away from the original intent.
- Match the workflow to the task size. SDD is most valuable for features that involve multiple systems or carry significant ambiguity. For straightforward bug fixes, a brief description to your coding agent is sufficient.
- Review at every phase. The spec, plan, and task breakdown are all yours to critique before implementation begins. Catching a misalignment at the plan phase costs minutes. Catching it after implementation costs days.
- Pair SDD with your existing CI/CD. Spec-driven tasks map cleanly to pull requests. Each task becomes a reviewable PR with a direct link back to the spec it implements.
Looking Ahead
The Yoma Fleet engineering team will be piloting Spec Kit on selected 2026 projects. As the SDD ecosystem matures, we are watching several developments closely: VS Code-native integrations for spec workflows, multi-agent task parallelization, and smarter spec maintenance tools that keep specs and code synchronized automatically. The direction is clear. We are moving from “code is the source of truth” toward “intent is the source of truth.” At Yoma Fleet, that means our specifications, clear, shared, and continuously refined, will increasingly drive what gets built, how it gets built, and how it gets maintained.
Conclusion
Spec-driven development is the next step in how we build software at Yoma Fleet, building on the workflows we introduced with Vibe Coding. The principles are straightforward: write the spec before the code, separate the what from the how, make engineering standards explicit in a constitution, review every phase before implementation begins, and treat the spec as a living document rather than a one-time artifact.
At Yoma Fleet, we build what we specify. And we specify what we mean.
