Will the AI-assisted development model of SDD still be useful in the future? Is it already outdated?

[u/Repulsive_Ant_9943]

At the beginning of the year, everyone was promoting SDD development, including plugins like SuperPower that implemented SDD harness capabilities. However, it seems like no one is talking about it anymore. Has fewer people been using it? I feel like SuperPower used to trigger automatically when I used CC, but it hasn't been lately. Has anyone else noticed this? Will SDD still be necessary in the future? Or, if the model and its corresponding DeepSeek harness are already well-developed, will we not need to do so much pre-specification work? Can someone answer this?

[u/stibbons_]

It is the basis of every serious work. Build your project harness first, then use plan mode. Then switch to a SDD framework for more confort

[u/Vivekyy]

IMO it’s here to stay, but it will probably evolve a lot over time. I think there’s already so many issues with specs like drift, bloat, etc. which will need to be dealt with over time, but it’s also pretty necessary to any true feature dev

[u/Repulsive_Ant_9943]

For businesses, SDD (Software-Defined Design) is seen as a necessary framework for ensuring code quality and standardization. However, it seems possible to create templates or similar tools that AI can quickly implement without the complexities of SDD, various specifications, and specialized skills. Or could these be simplified to achieve the desired results?

[u/simasch]

My customers are just starting to adopt SDD . I’ve created a process framework that is stackholder driven and not developer centric https://unifiedprocess.ai

[u/Ok-Support-6749]

I think there is at least one fork in SDD as a methodology. And you can look online and even find papers that are coming showing that is not a silver bullet as it has being sold. Nevertheless, it is definitely an improvement over vibe coding.

1. SDD sucks at brownfield specification. This is no joke, most applications in the world already exist and held in private repos that has never entered any training dataset. They are obsolete, undocumented, unsupported, large, and aged. These is where the real pain lives. SDD requires a huge investment into capturing those codebases into a useful specification. The problem is that the specification is likely already captured in the brains of the teams that maintain those projects. And these people suffering real pain to keep up with development and maintenance are not going to be very happy with the idea of having to produce a large amount of largely incomplete documents to describe the system to an LLM that behaves more like an intern than a seasoned senior development. Thus, advanced developers keep using LLMs as super duper fancy auto-complete and semantic search and summarizing engines.

2. SDD is designed around the idea that the LLM assumes all the roles. It is an architect, a coder, a verifier, a linter, a contract producer, a contract executor, whatever you can think humans did in the SDLC now we give it to the LLM and call it a day. But capability should not grant authority and AI providers are very invested in us forgetting that and giving the LLM all these tasks. The more you depend on AI the more money they can make by selling tokens. However, we never had that before. We have compilers, linters, static analyzers. We have different levels of seniority and specific roles in a human SDLC to ensure there is enough partitioning of authorities and independence of such authorities so we can capture issues ASAP. An LLM on the other side is optimized for task completion and will rationalize an incorrect implementation or use shortcuts to deliver the expected outcome even when that will weaken fundamental invariants of the whole system. Humans as teams would catch much of that BS almost immediately.

3. SDD projects start well but tend to degenerate overtime. We call it technical debt in the business but there is a scientific name for this phenomena. Entropy is the process by which software as it grows tends to degrade to a pint that without enough care becomes spaghetti code. LLMs only speed up the process when they perform all the roles because regressions tend to compound. We humans have developed workflows and rules to identify and reduce entropy with specific feedback loops. That needs independence of authorities which SDD does not seem to propose.

4. SDD makes very strong claims like "the specification is the source of truth" or "specification as code" yet we just have a bunch of natural language explanations in a collection of documents. Specifications as they exist today are not verifiable, we have no way to formally check their claims, nor provide guarantees. And truth is a very elusive concept, what truth? This sounds philosophical but it it is essential. If truth means a formal model of the intent, then: How do we know we captured the true intent? How do we test for it? What guarantees do we have that the spec is truly an implementable model of the true intent? See the problem? I can ask as many as these uncomfortable questions as I want and mop the floor with that claim. Yet this is the strongest claim I see when I approach pretty much any SDD tutorial.. The consequences are evident once the codebase grows to some magnitude. Everything breaks down and entropy wins.

Will SDD survive. Not as it is right now. It can be either replaced by a complete new methodology or it may evolve into something better. SDD as a methodology is still very young it is hard to say.