Ask HN: Why spec-driven development when code IS spec?
Code, as such, is a detailed, verifiable spec that a machine can execute. LLMs are already great at translating code to natural language and vice-versa. Why do we need a second, less detailed and less verifiable copy of the code?
7 comments
> Why do we need a second, less detailed and less verifiable copy of the code
Because it requires people to know how to read or specify code.
Spec driven development is similar to the no-code movement i.e. the specs are closer to functional requirements than this strict spec or code.
You can argue that you can just ask the LLM to explain back and forth but it can still be too much.
Because it requires people to know how to read or specify code.
Spec driven development is similar to the no-code movement i.e. the specs are closer to functional requirements than this strict spec or code.
You can argue that you can just ask the LLM to explain back and forth but it can still be too much.
> You can argue that you can just ask the LLM to explain back and forth but it can still be too much.
But then you'd get an explanation tailored to your specific perspective instead of a generic one, right?
But then you'd get an explanation tailored to your specific perspective instead of a generic one, right?
> But then you'd get an explanation tailored to your specific perspective
Assuming you know how to ask the right questions and make sense of it. Tailored to whose perspective, especially in a team, which then might make it worse.
Assuming you know how to ask the right questions and make sense of it. Tailored to whose perspective, especially in a team, which then might make it worse.
The answer is exactly on you question. Code is detailed. It need to has every implementation detail, a spec is high level view demoted of all unnecessary details!
What do we gain by maintaining a high level view instead of asking an LLM to explain the code at a high level when required?
It captures the why and what of the system from a business or user perspective. Existing code don't inherently capture the original business problem or design choices that led to that code.
Fair enough! Business and user perspectives are meta-data that explain the intent behind the code. I disagree with the point that intent should be the source of truth, though. Intent, like you explained, is high level and lacks the details to be an unambiguous source of truth.