Live data from Hacker News

Verified Spec-Driven Development (VSDD)

gist.github.com

51–60 of 122 posts

Re: Verified Spec-Driven Development (VSDD)

#51
Looks moderately interesting, but I refuse to upvote vibe-written submissions. Of course documents like this have their uses, but:

- They cannot easily be attributed to a human author, and therefore debates and discussions on the substance of the ideas tend not to get too far

- They (tend to) take well-established concepts, glue them together, and describe the result in reverential tones, regardless of the relative triviality of the solution. Hard to rule that out here tbh.

I am not saying any of that is what's happening here. What I am saying is that I'm not going to waste my time reading something I can't easily vet for quality.

Author (not OP) has written plenty of its* own words on Bluesky over the last few weeks. If it's written anything longhand about this stuff I'd be interested to read it. But for now "anti-slop bias" designed into the system has not reached the prose.

*respecting pronouns

Re: Verified Spec-Driven Development (VSDD)

#52
post #6

Everything in this post stems from the assumption that you already know what you're doing, which is probably true for things you've built before. But I hope we can agree that you can't spec out something you have no clue how to build, let alone write the tests before you've even explored the boundaries of the problem space. That's completely unreasonable. My second point is that this approach is fundamentally wrong f…

A lot of interesting replies below this comment that I won't be able to respond to individually.

I'll just leave this here:

https://en.wikipedia.org/wiki/P_versus_NP_problem

Re: Verified Spec-Driven Development (VSDD)

#53
post #19

Earlier quoted context omitted.

How do you propose we measure signal? Lines of code is renowned for being a very bad measure of anything, and I really can't come up with anything better.

The OP said that they kept what they liked and discarded the rest. I think that's a reasonable definition for signal; so, the signal-to-token ratio would be a simple ratio of (tokens committed)/(tokens purchased). You could argue that any tokens spent exploring options or refining things could be signal and I would agree, but that's harder to measure after the fact. We could give them a flat 10x multiplier to capture…

I'm going to call it out as bullshit, you can't dig out "what you like" from "hundreds agents running all the time".

Re: Verified Spec-Driven Development (VSDD)

#54
post #15
post #6

Everything in this post stems from the assumption that you already know what you're doing, which is probably true for things you've built before. But I hope we can agree that you can't spec out something you have no clue how to build, let alone write the tests before you've even explored the boundaries of the problem space. That's completely unreasonable. My second point is that this approach is fundamentally wrong f…

Nothing of what you write here matches my experience with AI. Specification is worth writing (and spending a lot more time on than implementation) because it's the part that you can still control, fully read, understand etc. Once it gets into the code, reviewing it will be a lot harder, and if you insist on reviewing everything it'll slow things down to your speed. > If the cost of writing code is approaching zero, t…

This. Waterfall never worked for a reason. Humans and agents both need to develop a first draft, then re-evaluate with the lessons learned and the structure that has evolved. It’s very very time consuming to plan a complex, working system up front. NASA has done it, for the moon landing. But we don’t have those resources, so we plan, build, evaluate, and repeat.

Re: Verified Spec-Driven Development (VSDD)

#55
post #40
post #6

Everything in this post stems from the assumption that you already know what you're doing, which is probably true for things you've built before. But I hope we can agree that you can't spec out something you have no clue how to build, let alone write the tests before you've even explored the boundaries of the problem space. That's completely unreasonable. My second point is that this approach is fundamentally wrong f…

There’s a real tension here. If you are vibe-coding, this approach is definitely going to kill you buzz and lose all the rapid iteration benefits. But if you are working in an existing large system, vibe coding is hard to bring into the core. So I think something more formal like OP is needed to reap major benefits from AI.

This is just AI-written slop, but even if you're vibe coding and want to go for rapid iteration, you still benefit by having the AI write out a broad plan of what it's going to do and looking it over before telling it to implement it. One-shot vibe coding is totally worthless, but the more you're aware of what the AI is thinking about and ready to revise its plans, the better it can potentially do.

Re: Verified Spec-Driven Development (VSDD)

#57
post #54
post #15

Earlier quoted context omitted.

Nothing of what you write here matches my experience with AI. Specification is worth writing (and spending a lot more time on than implementation) because it's the part that you can still control, fully read, understand etc. Once it gets into the code, reviewing it will be a lot harder, and if you insist on reviewing everything it'll slow things down to your speed. > If the cost of writing code is approaching zero, t…

This. Waterfall never worked for a reason. Humans and agents both need to develop a first draft, then re-evaluate with the lessons learned and the structure that has evolved. It’s very very time consuming to plan a complex, working system up front. NASA has done it, for the moon landing. But we don’t have those resources, so we plan, build, evaluate, and repeat.

That "first draft" still has to start with a spec. Your only real choice is whether the spec is an actual part of project documentation with a human in the loop, or it's improvised on the spot within the AI's hidden thinking tokens. One of these choices is preferable to the other.

Re: Verified Spec-Driven Development (VSDD)

#58
post #35

Short take: replace TDD with BDD, and might add DDD as a spice. Otherwise this is a fairly good article. Why not TDD? Since a lot of developers use LLMs to create tests today, plus a lot of the training data contains information on how to do this. Making it something that it either can figure out to do by itself or that it will cheat. Both equally bad. A somewhat controversial take is that you should simply avoid wri…

could you say more about removing agents.md?

Probably referencing this: https://news.ycombinator.com/item?id=47034087
Post reply on HN