Addressing Common Objections to Spec-Driven Development
Adopting new development methodologies raises valid questions about productivity, quality, and adaptability. This evidence-based FAQ addresses common objections to Liatrio's Spec-Driven Development (SDD) using a concrete example: implementing a cspell pre-commit hook for spell-checking. By analyzing specifications, task lists, proof artifacts, and validation reports, we demonstrate how well-executed SDD works in practice.
Does Spec-Driven Development Add Unnecessary Overhead?
Structured processes often face criticism for introducing bureaucratic overhead. However, the cspell hook implementation proves that SDD structure is an investment, not a cost. By mandating upfront clarity, it prevents ambiguity and rework—the true sources of delay—ultimately increasing development velocity.
Upfront Planning Prevents Waste
The specification clearly established Goals and Non-Goals, defining what's out of scope. This protected the team from scope creep and unexpected requirements, concentrating effort exclusively on agreed-upon value.
Structured Work Creates Velocity
Git history shows implementation took under 6 minutes—from first commit (09:57:02) to final commit (10:02:41). This remarkable speed was enabled by a clear plan breaking work into four distinct tasks.
Unambiguous Blueprint
SDD creates a direct, verifiable link between initial goals and final outcomes. The validation report confirms every stated goal was met without deviation, eliminating friction from misaligned expectations.
Non-Goals Defined Clear Boundaries
Explicitly Out of Scope:
- Spell checking code files
- Automatic dictionary updates
- CI/CD spell checking
- IDE integration
Additional Exclusions:
- Multi-language support
- Auto-fixing errors
- Generated files checking
- CHANGELOG.md checking
By setting these boundaries, the team ensured effort was concentrated exclusively on delivering agreed-upon value without distraction.
How Do We Know the Feature Actually Worked?
A primary benefit of SDD is generating objective, verifiable evidence proving features are complete and correct. This moves assessment from subjective opinion to factual verification. The cspell implementation generated multiple layers of proof—from validation reports to individual commit traceability—guaranteeing the final product meets every requirement.
100% of functional requirements passed validation with documented evidence
Unambiguous PASS conclusion in comprehensive validation report
Test proof showed system correctly identified and suggested fixes
Coverage Matrix: Evidence for Every Requirement
Verifiable Proof from Test Output
test-spell-check.md:9:4 - Unknown word (recieve) fix: (receive)test-spell-check.md:10:4 - Unknown word (seperate) fix: (separate)CSpell: Files checked: 1, Issues found: 2 in 1 file.This artifact proves the hook correctly identified the file, misspelled words, and provided correct suggestions. This is not a description of what happened—it's a record of what happened, providing undeniable evidence of system behavior.
What Happens If Requirements Change?
Planning-heavy processes face criticism for rigidity and inability to adapt. The cspell hook example proves that SDD provides a structured framework for managing change gracefully. Its emphasis on clarity, iterative planning, and modularity makes it inherently adaptable to inevitable project changes.
Clarity as Foundation
Initial specification provides stable baseline. Explicit Non-Goals make it easy to identify scope changes versus clarifications, enabling structured prioritization conversations.
Iterative Planning
Clarifying Questions phase demonstrates dialogue approach. User feedback refined requirements before finalization, proving planning is collaborative, not dictatorial.
Modular Adaptation
Task structure allows small-scale changes without disrupting workflow. Git history shows pragmatic in-flight adjustments based on real-world testing discoveries.
Real Example: Incorporating Feedback
"we don't need validation tests in python, that's overkill, remove that."
This user feedback during task generation was immediately incorporated. The final task list reflects this change, preventing wasted effort on unnecessary work. The plan adapted to stakeholder input before implementation began.
In-Flight Adjustments
Even with excellent planning, discoveries happen during development. Commit message 26e8c10 shows: "Added missing dictionary terms found during testing." This proves the process allows pragmatic adjustments without rigidity.
Clear Scope Boundaries
Non-Goals establish what's out of scope, making change identification straightforward
Feedback Integration
Planning phase incorporates stakeholder input before implementation starts
Modular Tasks
Small, focused units allow adjustments without disrupting entire workflow
Conclusion: Evidence-Based Success
The cspell pre-commit hook implementation provides concrete evidence that Spec-Driven Development effectively mitigates common concerns about overhead, verifiability, and rigidity when executed properly.
High-Velocity Development
Upfront planning investment created unambiguous scope, leading to focused development. Complete implementation achieved in under 6 minutes with clear task breakdown.
Guaranteed Verifiability
Emphasis on proof artifacts produced auditable evidence chain. All 11 functional requirements met and validated with documented proof for stakeholder review.
Graceful Adaptability
Process demonstrated flexibility by incorporating feedback during planning and implementation phases. Modular structure enabled pragmatic in-flight adjustments without disruption.
The SDD Advantage
SDD provides a robust framework that enhances clarity, guarantees verifiability, and gracefully accommodates change. The initial investment in structured planning and documentation delivers more predictable, successful outcomes with reduced rework and increased stakeholder confidence.
Complete validation coverage
From first to final commit
Clear boundaries prevented drift
Key Takeaway: The evidence from this real-world implementation demonstrates that SDD's structured approach is not overhead—it's an investment that pays dividends through clarity, velocity, and quality assurance.
Why Do AI Responses Start with Emoji Markers (SDD1️⃣, SDD2️⃣, etc.)?
You may notice that AI responses begin with emoji markers likeSDD1️⃣,SDD2️⃣,SDD3️⃣, orSDD4️⃣. This is an intentional feature designed to detect a silent failure mode calledcontext rot.
What Is Context Rot?
Research from Chroma and Anthropic demonstrates that AI performance degrades as input context length increases, even when tasks remain simple. This degradation happens silently—the AI doesn't announce errors, but gradually loses track of critical instructions.
How Verification Markers Work
Each prompt instructs the AI to always begin responses with its specific marker (SDD1️⃣ for spec generation, SDD2️⃣ for task breakdown, etc.). When you see the marker, it's anindicator that critical instructions are probably being followed. If the marker disappears, it's an immediate signal that context instructions may have been lost.
What You Should Expect
Normal responses will start with the marker:SDD1️⃣ I'll help you generate a specification... orSDD3️⃣ Let me start implementing task 1.0.... This is expected behavior and indicates the verification system is working correctly. The markers add minimal overhead (1-2 tokens) while providing immediate visual feedback.
Technical Background
This verification technique was shared by Lada Kesseler at AI Native Dev Con Fall 2025 as a practical solution for detecting context rot in production AI workflows. The technique provides:
- Immediate feedback: Visual confirmation that instructions are being followed
- Low overhead: Minimal token cost (1-2 tokens per response)
- Simple implementation: Easy to spot in terminal/text output
- Failure detection: Absence of marker immediately signals instruction loss
For detailed research and technical information, see thecontext verification research documentation.