Live data from Hacker News

Toolkit to help you get started with Spec-Driven Development

github.com

11–20 of 43 posts

Re: Toolkit to help you get started with Spec-Driven Development

#11

> Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them. Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. Nothing against AI, I love it as a tool, but this "you-don't-need-code" approach shows similar signs. Quick win…

There was a really good article on this here a few days ago that didn't get much traction. It was about how programming is a learning feedback loop and because of that there are good and bad ways to use LLMs:

"The readymade components we use are essentially compressed bundles of context—countless design decisions, trade-offs, and lessons are hidden within them. By using them, we get the functionality without the learning, leaving us with zero internalized knowledge of the complex machinery we've just adopted. This can quickly lead to sharp increase in the time spent to get work done and sharp decrease in productivity."

https://martinfowler.com/articles/llm-learning-loop.html

Re: Toolkit to help you get started with Spec-Driven Development

#13

> Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them. Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. Nothing against AI, I love it as a tool, but this "you-don't-need-code" approach shows similar signs. Quick win…

Well done on conflating BDD and TDD then, I suppose.

Re: Toolkit to help you get started with Spec-Driven Development

#14
post #4

I don't think we ever get away from the code being the source of truth. There has to be one source of truth. If you want to go all in on specs, you must fully commit to allowing the AI to regenerate the codebase from scratch at any point. I'm an AI optimist, but this is a laughable stance with current tools. That said, the idea of operating on the codebase as a mutable, complex entity, at arms length, makes a TON of…

Tern looks very interesting.

On your homepage there is a mention that Tern “writes its own tools”, could you give an example on how this works?

Re: Toolkit to help you get started with Spec-Driven Development

#17
post #4

I don't think we ever get away from the code being the source of truth. There has to be one source of truth. If you want to go all in on specs, you must fully commit to allowing the AI to regenerate the codebase from scratch at any point. I'm an AI optimist, but this is a laughable stance with current tools. That said, the idea of operating on the codebase as a mutable, complex entity, at arms length, makes a TON of…

The reason code can serve as the source of truth is that it’s precise enough to describe intent, since programming languages are well-specified. Compilers have freedom in how they translate code into assembly and two different compilers ( or even different optimization flags) will produce distinct binaries. Yet all of them preserve the same intent and observable behaviour that the programmer cares about. Runtime performance or instruction order may vary, but the semantics remain consistent.

For spec driven development to truly work, perhaps what’s needed is a higher level spec language that can express user intent precisely, at the level of abstraction where the human understanding lives, while ensuring that the lower level implementation is generated correctly.

A programmer could then use LLMs to translate plain English into this “spec language,” which would then become the real source of truth.

Re: Toolkit to help you get started with Spec-Driven Development

#18
We started experimenting with this on a large-ish feature, with several repos involved. Off to a good start. The constitution that’s created as the first step is valuable in its own right. Something that can be used for onboarding both engineers and LLMs. Version 1 generated by specify was already quite good and we iterated from there. We had previously created a Claude.md that took the whole codebase into account, which I think helped.

I’m perhaps less sold on the idea of the spec being the source of truth — would have to do some design iterations and see if that holds up. I do like that it imposes some structure/rigor on the design process.

Re: Toolkit to help you get started with Spec-Driven Development

#20
post #4

I don't think we ever get away from the code being the source of truth. There has to be one source of truth. If you want to go all in on specs, you must fully commit to allowing the AI to regenerate the codebase from scratch at any point. I'm an AI optimist, but this is a laughable stance with current tools. That said, the idea of operating on the codebase as a mutable, complex entity, at arms length, makes a TON of…

>Adversarially have an AI read through that huge implementation log and surface where it's struggling.

That's a good idea, have a specification, divide into chunks, have an army of agents, each of them implementing a chunk, have an agent identify weak points, incomplete implementations, bugs and have an army of agents fixing issues.

Post reply on HN