Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl • Hacker News Board

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#31

Post by fabianlindfors » Fri, Oct 17, 2025, 7:56 PM UTC

conartist6 wrote: post #30

fabianlindfors wrote: post #28

The note on how all those tools seem to mostly be spec-first and vague about spec maintenance was interesting to me. Me and my cofounder have been going all-in on spec-as-source, as we think it's really the most interesting use of specs, but it's also challenging to get of the ground. If anybody has any thoughts on this, I'd love to hear them. Also in case somebody wants to try a spec-as-source tool, we'd love feedba…

if the spec is truly the source, it's because you've invented a formal programming language that evaluates the spec. Anything short of that and the spec is the spec, the source is the source. Now you get to learn about what good code looks like, like the rest of us!

With that, I was referring to the definition in the article: "The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code". That's how Specific works.

And I think that opens up a very interesting question about quality. If the human never touches the code, then "good code" gets replaced with "good specs" instead, and I don't think anybody knows what constitutes good specs in that context right now!

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#32

Post by conartist6 » Sat, Oct 18, 2025, 11:10 AM UTC

fabianlindfors wrote: post #31

conartist6 wrote: post #30

Earlier quoted context omitted.

if the spec is truly the source, it's because you've invented a formal programming language that evaluates the spec. Anything short of that and the spec is the spec, the source is the source. Now you get to learn about what good code looks like, like the rest of us!

With that, I was referring to the definition in the article: "The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code". That's how Specific works. And I think that opens up a very interesting question about quality. If the human never touches the code, then "good code" gets replaced with "good specs" instead, and I don't think anybody knows what constitut…

That is just so at odds with my way of thinking. The code is the spec -- the only spec that matters. The only way of describing the behavior that everyone can agree on the meaning of.

A design document can add color, but only the code tells you what the application does

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#33

Post by whazor » Sat, Oct 18, 2025, 12:15 PM UTC

tconfrey wrote: post #15

I've been watching this trend toward SDD. Makes sense but it feels like the process pendulum is swinging back toward the pre-agile era of functional specs and design documents. Not quite Big Design Up Front[0] but maybe increasingly working software == comprehensive documentation[1]? Waterfall anyone?! [0] https://en.wikipedia.org/wiki/Big_design_up_front [1] https://agilemanifesto.org/

You can have small design up front as-well. You write down one or two pages, let the LLM generate code and tests. Keep iterating. If you believe in 100% LLM coded applications, then it makes sense to manage the English input as specifications. Instead of throwing the prompts away, you neatly organize them. Plus you can add additional constraints when the AI does something you don't like.

But I don't trust LLMs to program anything critical, and only do sandbox/tests/demo's. Things where code quality is less important.