Spec-Driven Development на практике | SDD, BMAD, OpenSpec, вайб кодинг | Podlodka Podcast #486

Motivation and critique of “Spec-Driven Development” (SDD)

• The speakers argue that SDD is often misunderstood as:
  • “write huge specs and regenerate everything from a source of truth.”
• They warn about over-relying on models:
  • “LLM writes code” is described as undesirable because it introduces multiple failure modes.
• Practical blockers include:
  • Token cost
  • Context window limits

Core technical limitation: context window + “lost in the middle”

• SDD intersects with how LLMs handle long contexts.
• Even if an API advertises a large context window, usable context often degrades earlier due to:
  • Lost middle syndrome: older information in the middle of the context is forgotten or ignored.
  • Performance and reliability sagging well before the maximum token count.
• Practical guidance implied by the discussion:
  • Avoid pushing planning/code sessions toward the full window; anecdotal discussions suggest noticeable degradation above roughly 50–60% of the window.

Why SDD can help: controlling what the agent must remember

• Instead of one long chat, SDD structures work into multiple sessions.
• Each coding run receives an optimized subset of context.
• “Ideal session” framing:
  • About 100k tokens of focused task context (the “white wall” analogy: read the relevant instructions, then code).
  • SDD attempts to preserve the right information at the beginning of a session and avoid later compression/eviction.

Plan → Code split (“PlanMode” / planning agent)

• A major implementation idea mentioned:
  • PlanMode:
    • First run: produce a plan in one session.
    • Second run: inject that plan and proceed with coding.
• It’s described as relatively primitive, but effective—essentially a basic form of SDD.

Spec hierarchy and terminology (session vs sprint vs project vs epic)

• The discussion emphasizes that terminology is frequently confusing:
  • “spec” can mean different things depending on scope.
• They distinguish:
  • Coding-session spec: what to implement in a single coding session (small, concrete, acceptance-criteria oriented).
  • Sprint/story/epic/project specs: larger scopes requiring different abstraction levels and coordination.
• Suggested worldview:
  • Treat “spec” as an artifact that provides the right context for the current step the agent is performing.

“Intent” sizing and spec content rules (what to write)

• At the coding-session level, “Intent” should be small:
  • Roughly ~300 tokens mentioned.
• Larger intent typically corresponds to bigger units (story/epic/project).
• They propose that coding-session requirements should be expressible as structured inputs/outputs.
• Input/Output matrix concept:
  • Encode acceptance criteria as concrete transformations/cases (e.g., filter behavior like “0 transfers”, “up to N”, etc.).
• If requirements don’t fit that format:
  • Add additional acceptance criteria sections.

What not to do (negative scope)

• A recurring SDD practice is to include a section for:
  • Non-scope / “do not do”
• Rationale:
  • LLMs tend to invent extra features without explicit guidance.
  • Explicit “no” reduces “agent fantasizing” and irrelevant additions.

Human-in-the-loop (HITL) and progressive discovery

• Workflow described:
  • Humans review specs and/or code at key checkpoints.
• Recommended checkpointing:
  • Review early in the session (before many code decisions are locked in).
  • Do it “by default” in their practice for each task history.
• Progressive discovery:
  • Don’t force everything into one master spec.
  • Let the agent propose, then iteratively refine based on review/feedback.
• Tracer bullet idea:
  • Build a “thin vertical slice” early to validate architecture decisions and reduce later rework.

Relation to OpenSpec / BMAD / BImad tools

• Guest: Alexey Verkhovsky, associated with “BMOD/BMAD” (spelling varies in subtitles).
• OpenSpec is discussed as an SDD approach/framework:
  • More about the complexity of concept/tooling than complete mechanics in this summary.
• BMAD/BImad workflow templates mentioned include “skills,” such as:
  • “Quick def” for very small fixes.

Evaluation: skepticism toward benchmarks and synthetic evals

• They argue many benchmarks are misleading because they:
  • test microtasks and synthetic scenarios
  • not real large codebases with human-authored history
• Instead, they advocate a “social practice / Lenin criterion” style:
  • Apply the change in a real project context
  • Compare before/after on the actual repo:
    • code review
    • tests
    • observed defects

Task suitability: when SDD fits and when it doesn’t

• SDD is presented as useful when:
  • the task has information asymmetry
  • careful integration across parts is required
  • the change is large enough that naive “just code it” becomes error-prone
• For trivial changes (e.g., “fix 3 lines in one file”):
  • Normal review is often sufficient
  • SDD ceremony may be unnecessary

UI / design integration and token efficiency

• UI agents are described as a major headache.
• They discuss integrating Figma-like inputs via tools such as MCP (mentioned conceptually).
• Main point:
  • Don’t feed pixel-perfect screenshots when token cost matters.
  • Prefer structured/layout information (e.g., containers hierarchy).
  • If needed, export to HTML and generate UI code from the structure rather than images.

Cost/token and subscription constraints

• Token costs are treated as a central practical limitation.
• Anecdotal optimization:
  • sometimes using less expensive models is sufficient.
• They note subscription/payment tiers are used in reporting (details are not deeply technical).
• In enterprises, subscriptions may be replaced by API pricing.

Myths answered (explicitly discussed)

• Myth: SDD is for solo developers only
  • Response: it can be used in teams, but requires orchestration and shared integration context.
• Myth: spec must always be evergreen and perfectly in sync with code
  • Response: because of lossy compression and context limits, maintaining an “evergreen spec” as a single source of truth is problematic.
  • Instead, specs are treated as step-specific context artifacts, which may need archiving later.

Main speakers / sources

• Yegor Tolstoy — podcast host
• Stanislav Tsyganov — podcast host
• Alexey Verkhovsky — guest; author of a popular SDD framework/toolkit referenced as BMOD/BMAD/BImad/PlanMode/OpenSpec (subtitles vary in spelling)