Technical Context
I looked at this discussion as a practitioner, not an outside observer: the market is clearly shifting toward Spec-Driven Development. However, a mature stack hasn't formed around a single tool yet, but rather a combination of approaches. In real-world scenarios, SpecKit, Claude Code with the /plan command, and the CLAUDE.md file frequently emerge as the foundational layer for context management.
I specifically noted one crucial detail: openspec and get-shit-done still seem niche or raw in this space, whereas SpecKit has become the de facto standard. The reason is simple: it offers a clear SDD structure—constitution, specification, task breakdown, and validation gates—which can be integrated into the engineering process rather than just shown in a demo.
I also see a downside to specs. SpecKit consumes a massive amount of tokens because it runs the model through multiple phases: principles, specification, decomposition, then code and tests. For large features, this quickly turns into an expensive context funnel, especially when using powerful models like Claude Opus or equivalents with strong reasoning capabilities.
That is exactly why I agree with the idea from the discussion that "specs are tests." When I design AI architectures, I almost always try to tie the specification to a verifiable artifact: tests, API contracts, acceptance criteria, or data schemas. Otherwise, the team just gets a pretty document instead of a manageable delivery.
Impact on Business and Automation
From a business perspective, I don't see this as a trendy workflow, but as a shift in the development management model. SDD is profitable where the cost of failure is high: internal platforms, multi-module B2B products, integration loops, and regulated processes. In such cases, AI integration works much better when the model doesn't "write code based on inspiration" but follows a predefined specification.
Who wins? Teams with strong engineering discipline that already have architectural rules, CI/CD pipelines, a testing strategy, and a dedicated product owner. Who loses? Those who want to slap AI automation on top of chaotic legacy code without proper system boundaries or a human to maintain the architecture.
Based on my experience at Nahornyi AI Lab, the biggest mistake when integrating artificial intelligence into development is trying to automate code generation before the system invariants are defined. When this happens, CLAUDE.md becomes bloated, /plan starts generating overly generic steps, and the token burn masks a lack of actual solutions. On the outside, the agent appears busy, but on the inside, technical debt is piling up.
Therefore, I wouldn't pitch SDD as a universal replacement for standard development. I would pitch it as an AI-driven integration into the engineering cycle: for greenfield projects, massive features, modules with clear contracts, and teams willing to pay for predictability.
Strategic Outlook and Deep Dive
I believe the next phase of SDD won't be "even more specifications," but rather stricter context compression. The winning stack won't be the one writing the longest specs, but the one that can break down a system into small domain boundaries, feed the agent only the necessary rules, and return the result to the main architecture without context bloat.
This is exactly where Claude Code with /plan and a concise CLAUDE.md often proves more practical than a heavy, universal framework. I've already seen this pattern in Nahornyi AI Lab projects: a brief architectural manifest, narrow task packages, tests acting as specifications, and specialized sub-agents for bounded contexts. This approach yields the best balance of quality, speed, and cost.
My prediction is simple: SDD is here to stay, but in its mature form, it will merge with AI architecture, where a specification is no longer just a document, but an executable contract. For businesses, this is excellent news. It means AI development will transition from expensive improvisation to a repeatable, production-ready approach.
This analysis was prepared by me, Vadym Nahornyi—leading expert at Nahornyi AI Lab in AI architecture, automation, and practical AI implementation for real businesses. If you want to know whether SDD suits your product, how to reduce token burn, or how to build architecture without chaos, I invite you to discuss your project with me and the Nahornyi AI Lab team.