ODD vs SDD: what Organic Driven Development is and why Gentle-AI dropped Spec-Driven Development

ODD (*Organic Driven Development*) is the way of working with coding agents that Gentle-AI uses by default since version 4: the agent first understands what you asked for, decides how much structure the task needs, and only writes planning documents when the work is large. SDD (*Spec-Driven Development*) is the opposite: every feature goes through fixed phases (specification, plan, tasks, implementation) before any code changes.

This article explains both with facts checked in their repositories, where ODD comes from, the main criticisms of SDD, a table to choose between them and how to apply the ODD idea in Claude Code without installing anything.

First, what ODD actually stands for

If you have seen ODD described as *Objective-Driven Development*, that is not the name its author uses. In Gentle-AI's repository and docs, ODD is Organic Driven Development. "Organic" because the process grows with the task: a three-line fix produces no documents and a multi-session feature produces exactly one.

The ODD acronym is also used for unrelated things: *Observability-Driven Development* (designing around metrics and traces), *Outcome-Driven Development* (there are Claude skills with that name aimed at non-developers) and *Outline-Driven Development* (a diagram-first Claude Code plugin). When people talk about "ODD vs SDD" for AI agents, they almost always mean Gentle-AI's.

What SDD (Spec-Driven Development) is

SDD makes the specification the center of agent work: before asking for code, you write (or have the agent write) what is being built, why, and with which acceptance criteria. The agent then derives a technical plan, a task list and the implementation from it. The goal is to replace *vibe coding*, where the agent makes decisions for you in every message.

The three best-known tools:

In Spec Kit (checked in its README, version 1.2.x from October 2026) the minimal flow is six commands in the agent chat: /speckit-constitution once per project and then, for each feature, /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement and /speckit-converge, repeating the last two until the report says *Converged*. Kiro writes requirements with the EARS pattern: "WHEN [event] THE SYSTEM SHALL [behavior]".

Birgitta Böckeler (Thoughtworks) separates three levels of SDD in her October 2025 analysis on martinfowler.com:

• Spec-first: the spec is written before the task and guides it. Every tool does this.
• Spec-anchored: the spec is kept afterwards and used to evolve the feature.
• Spec-as-source: the spec is the only file you edit; code is regenerated. That is Tessl's bet.

Where SDD hurts in daily work

SDD solves a real problem, but its cost shows up as soon as you use it for normal tasks. Böckeler tried Kiro and Spec Kit and reported three issues:

1. Disproportion. For a small bug, Kiro turned the fix into four user stories with 16 acceptance criteria.
2. Too much Markdown to review. Spec Kit produced many files that repeated each other and the existing code. Her verdict: "I'd rather review code than all these markdown files".
3. The agent does not always follow the spec. Even with long documents and checklists, she saw the agent ignore notes about existing classes and recreate them as duplicates.

The tools themselves have been adjusting. Spec Kit's current README adds a separate bug-fixing flow (specify extension add bug, with /speckit-bug-assess, /speckit-bug-fix and /speckit-bug-test) and states that no full SDD feature workflow is required first. OpenSpec sums up its philosophy as "fluid not rigid" and "iterative not waterfall".

Where ODD comes from: Gentle-AI

Gentle-AI is a Gentleman Programming project (Alan Buscaglia's community) under the MIT license. It is not an agent of its own: it is an installer plus instructions, skills, memory (Engram) and review that get injected into the agent you already use. Its README lists support for 18 agents, including Claude Code, Codex, Cursor, Gemini CLI, OpenCode and Kiro.

Its history with SDD explains the change:

We checked the dates against the repository tags, and the retirement document in odd/tasks/remove-sdd-odd-only-main.md, whose stated goal was to make ODD "the only development workflow". That document is also a real example of the format ODD uses for large work; the repository holds 53 of them in odd/tasks/.

How ODD works: the 7-step protocol

ODD runs on every request, without you asking for a plan or picking a mode. The docs (docs/usage.md) define seven steps:

1. Authorize. Does the request ask for a change? If it is only a question, a review or a proposal, the agent touches nothing.
2. Explore the existing code and requirements, proportionately to the request.
3. Resolve uncertainty. Optional research for a named doubt, one question for a real product decision and, at most, one challenge to a risky premise.
4. Classify. A task is small when it is understood, its risk is contained and it could be resumed from the request plus git diff. It is large only when that test fails: several sessions, external waits or requirements that would not survive context compaction. File or line counts never decide.
5. Track before the first write. For large work, create a feature document before the first change and say in one line which one and how many tasks it holds.
6. Implement task by task, test first when a meaningful runnable test exists, reviewable commits of about 400 lines (a heuristic, not a cap) and each task checked off only with observed proof.
7. Close by reporting the verified outcome, every failed or pending check and the next step.

The feature document: SDD only when it pays off

For large work ODD uses one file, odd/tasks/<feature>.md, in a fixed order:

# Feature name

## Specs
S1. Requirement with your exact strings, error messages and examples, verbatim.
    Acceptance criteria and how it is checked.

## Tasks
- [ ] T1 (S1) · route: inline · commit: pending

## Log
L1. Your original request, verbatim.
L2. Corrections, evidence and decisions appended over time.

Subagents get a reference to that document and their S#, never a paraphrase of your request. That is the practical difference with many SDD flows, where each phase restates what you said in other words. Gentle-AI's README reports that with a 73-line spec and 26 hidden checks, paraphrased handoffs left 13 failures and were still at 23 of 26 after two feedback rounds; the change that fixed it was passing the spec by reference (gentle-shell#1718).

What their benchmarks say (with caution)

The README publishes runs on its own harness, Gentle Shell. Each cell is a single run (n=1) and cost is API-equivalent, so treat it as a signal, not a study:

The pattern is what you would expect: small work gets much cheaper; risky work does not save money but gets it right sooner. The same README admits the large task took about three times longer than Codex CLI on the same model.

SDD vs ODD: key differences

The honest reading: ODD does not remove specs, it removes the obligation to write them for everything. A large feature still gets a spec with acceptance criteria; it just lives in one file and keeps your exact words.

When to use SDD and when ODD

• ODD fits daily work: bugs, tweaks, one- or multi-session features in an existing codebase, small teams or solo developers with an agent.
• SDD still makes sense when the spec is a deliverable in itself: a new project to agree with a client, large teams where several people or agents build against the same contract, or domains that need formal requirements traceability.
• Mixing is reasonable: a PRD and an architecture doc when the project starts (that is light SDD) and ODD for every ticket afterwards.

How to apply ODD in Claude Code

Option 1: install Gentle-AI

Gentle-AI installs the ODD instructions (plus its memory and review) into your agent. On macOS or Linux, per its README:

brew install gentleman-programming/tap/gentle-ai
gentle-ai install --agent claude-code --dry-run

--dry-run prints the plan without applying changes. On Windows it installs with Go 1.25.10 or later (go install github.com/gentleman-programming/gentle-ai/v4/cmd/gentle-ai@latest). Keep in mind it is not only ODD: it also sets up Engram, a persona, permissions and RDD (its code review, on by default; turn it off with gentle-ai review mode disable). Read the plan before applying it, especially if you already have a carefully written CLAUDE.md; the installer backs up managed files before changing them.

We did not install it for this article: the binary needs Go 1.25.10 and our environment had 1.24. What we did read is the text it injects into Claude Code (internal/assets/claude/orchestrator.md, about 2,700 words), whose first mandatory section declares ODD the default workflow.

Option 2: the ODD idea in your CLAUDE.md

If you do not want a whole ecosystem, copy the principle. This block is ours, inspired by Gentle-AI's protocol:

## How to work (proportional to size)

- If the request is a question, a review or a proposal, do not modify files.
- Before changing code, read the affected code. Ask only if a real product decision remains, and only once.
- Small task (understood and resumable from git diff): do it directly, test first when a useful test exists, no plan documents.
- Large task (several sessions or long requirements): before the first change, create docs/tasks/<feature>.md with
  ## Specs (my exact wording and acceptance criteria), ## Tasks and ## Log (L1 = my request, verbatim).
- Only mark a task done with an executed check. When finished, say what was verified and what is pending.

If you want more discipline than this, Superpowers enforces design, planning and tests before coding, and to keep tickets outside the repo there is It's a Plan. If skills are new to you, start with the Claude Code skills guide.

Common mistakes when moving from SDD to ODD

• Thinking ODD means "no plan". The plan exists for large work. If the agent starts a three-day feature without a document, it is not doing ODD.
• Classifying by file count. A rename across 40 files can be small; a 20-line change in authentication may not be. The question is whether it can be resumed from the diff and whether the risk is contained.
• Letting the agent summarize your request. ODD's edge is keeping your exact words. If ## Specs shows your requirements rewritten, ask it to copy the originals.
• Checking off tasks without proof. A ticked box without an executed test or check is a promise, not evidence.
• Running SDD and ODD side by side without saying so. If you have Spec Kit installed plus ODD instructions, state in CLAUDE.md which one wins, or the agent will mix both flows.

FAQ

Does ODD mean Objective-Driven Development?

Not in Gentle-AI, where this approach comes from. Its official name is Organic Driven Development. Other ODDs (Observability, Outcome or Outline-Driven Development) are different methodologies.

Does ODD replace SDD in general?

It replaces SDD inside Gentle-AI since v4.0.0. Outside of it, Spec Kit, Kiro and OpenSpec are still active and shipping. ODD is a stance on how much specification you need, not the end of specs.

Which SDD tools exist?

The most used are GitHub Spec Kit (MIT), AWS Kiro and OpenSpec (MIT). Tessl goes furthest, treating the spec as the source code.

Does ODD work with Claude Code, Codex or Cursor?

Yes. Gentle-AI configures Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Kiro and other agents. And you can apply the idea without installing anything, with a block in CLAUDE.md or AGENTS.md.

Does ODD force TDD?

It applies test-first by default when a useful runnable test and a clear expected outcome exist: one failing test per requested rule and one test protecting each existing command the change touches. When no meaningful test exists, the agent explains why and runs functional checks instead.

Conclusion

SDD brought order to agent work, but applied to everything it turns a three-line bug into a case file. ODD keeps what helps (explore before touching, a verbatim spec and acceptance criteria for large work, tests and evidence) and drops it where it adds nothing. To start, copy the CLAUDE.md block above and watch whether your next ticket stops producing documents nobody reads.

Sources: Gentle-AI (README and docs/usage.md, v4.2.0) · GitHub Spec Kit and its GitHub blog announcement · Kiro: spec concepts · OpenSpec · Birgitta Böckeler, "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl".