Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Verified Spec-Driven Development (VSDD)

gist.github.com

Post reply on HN
Print view View original

61–70 of 122 posts

Re: Verified Spec-Driven Development (VSDD)

#61

Post by robot-wrangler »

_pdp_ wrote: post #52
_pdp_ wrote: 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

That seems barely related and settles nothing? Bottom line is simple, saying "you can't spec out something you have no clue how to build" is saying you cannot desire coldness unless you understand how to build a refrigerator. It's just the difference between what and how. If you don't know the difference between implementation and specifications, just try a whole day of answering "what" and "why" questions with "how" answers and see how it goes.

Re: Verified Spec-Driven Development (VSDD)

#62

Post by jFriedensreich »

Its an interesting direction if you see it under the umbrella of diminishing costs: You build a product once with vibe coding and a design/ product hat. Once you know what works you rebuild it 100% in a framework like this. You do this every time from scratch when the tech debt or the mismatch between architecture and needs are too big.

Re: Verified Spec-Driven Development (VSDD)

#63

Post by _pdp_ »

mirekrusin wrote: post #53
politician wrote: post #37

Earlier quoted context omitted.

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".

One of our projects has 1.2K open pull requests.

https://i.postimg.cc/Jnfk9b8g/Xnapper-2026-02-28-22-25-42.pn...

We probably accept 1-2 per day.

I personally discard code for the tiniest of reasons. If something feels off moments after I open the PR, it gets deleted. The reason we still have 1.2K open PRs is because we can't review all of them in time.

The most likely solution is to delete all of them after a month or two. By that time the open PRs on this project alone will be at least 10-20 more.

Re: Verified Spec-Driven Development (VSDD)

#64

Post by xcubic »

melvinroest wrote: post #32

I've been doing something less formal. I stumbled upon Riaan Zoetmulder's free course on deep learning and medical image analysis [1] and found his article on spec-driven development [2]. He adapts the V-Model by specifying three things upfront: requirements, system design and architecture. The rest gets generated. He mentioned a study where they show that LLM assistance slowed down experienced open source devs on la…

I am not following, can you give a concrete example of your workflow?

Re: Verified Spec-Driven Development (VSDD)

#65

Post by _pdp_ »

robot-wrangler wrote: post #61
_pdp_ wrote: post #52

Earlier quoted context omitted.

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

That seems barely related and settles nothing? Bottom line is simple, saying "you can't spec out something you have no clue how to build" is saying you cannot desire coldness unless you understand how to build a refrigerator. It's just the difference between what and how . If you don't know the difference between implementation and specifications, just try a whole day of answering "what" and "why" questions with "how…

Writing tests for a known solution (verification) is straightforward. But speccing out and testing something you haven't even figured out how to build yet (discovery) is a fundamentally harder problem.

Try speccing out a flux capacitor. I'll wait.

https://chatbotkit.com/reflections/verification-is-easier-th...

Re: Verified Spec-Driven Development (VSDD)

#67

Post by ErrantX »

manmal wrote: post #54
virgilp wrote: 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.

So, rollback and try again with the insight.

AI makes it cheap to implement complex first drafts and iterations.

I'm building a CRM system for my business; first time it took about 2 weeks to get a working prototype. V4 from scratch took about 5 hours.

Re: Verified Spec-Driven Development (VSDD)

#68

Post by zozbot234 »

ErrantX wrote: post #67
manmal wrote: post #54

Earlier quoted context omitted.

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.

So, rollback and try again with the insight. AI makes it cheap to implement complex first drafts and iterations. I'm building a CRM system for my business; first time it took about 2 weeks to get a working prototype. V4 from scratch took about 5 hours.

AI is also excellent at reverse engineering specs from existing code, so you can also ask it to reflect simple iterative changes to the code back into the spec, and use that to guide further development. That doesn't have much of an equivalent in the old Waterfall.

Re: Verified Spec-Driven Development (VSDD)

#69

Post by robot-wrangler »

_pdp_ wrote: post #65
robot-wrangler wrote: post #61

Earlier quoted context omitted.

That seems barely related and settles nothing? Bottom line is simple, saying "you can't spec out something you have no clue how to build" is saying you cannot desire coldness unless you understand how to build a refrigerator. It's just the difference between what and how . If you don't know the difference between implementation and specifications, just try a whole day of answering "what" and "why" questions with "how…

Writing tests for a known solution (verification) is straightforward. But speccing out and testing something you haven't even figured out how to build yet (discovery) is a fundamentally harder problem. Try speccing out a flux capacitor. I'll wait. https://chatbotkit.com/reflections/verification-is-easier-th...

> Try speccing out a flux capacitor. I'll wait.

One way to spec that is presumably something like "X% more efficient than current best-in-class", "made of Y,Z with no exotic materials", "takes no longer than T days to create" and so on.

Anyway, being "anti" spec isn't even wrong because it's just a completely incoherent position. There's always a spec.. including any informal prompt you kick off your agents with. Call it a "structured prompt" if that soothes you and your agents, then let's move on to the interesting part where we decide how much structure is optimal

Re: Verified Spec-Driven Development (VSDD)

#70

Post by melvinroest »

xcubic wrote: post #64
melvinroest wrote: post #32

I've been doing something less formal. I stumbled upon Riaan Zoetmulder's free course on deep learning and medical image analysis [1] and found his article on spec-driven development [2]. He adapts the V-Model by specifying three things upfront: requirements, system design and architecture. The rest gets generated. He mentioned a study where they show that LLM assistance slowed down experienced open source devs on la…

I am not following, can you give a concrete example of your workflow?

In my agent file I explain that I have a static analyzer which generates a callgraph. On starting the agent runs ~/.agent/tools/__callgraph__/generate_callgraph.py

It then gets to see callgraph.current.md and upon subsequent sessions callgraph.diff.md.

Here is an example of some output that I currently have in callgraph.current.md

  ## src/components/Header.tsx

  - **export Header({ ... }: Props)** (start 9, end 54) → `useAuth`

  ## src/components/HelpTooltip.tsx

  - **export HelpTooltip({ ... }: Props)** (start 15, end 42) → (none)

  ## src/components/ResultsTable.tsx

  - **getHeaderLabel(col: { id: string; columnDef: { header?: unknown } }): string** (start 45, end 51) → (none)
  - **getCellValue(colId: string, original: KeywordResult): string** (start 53, end 74) → (none)
  - **export ResultsTable({ ... }: Props)** (start 76, end 406) → `getCellValue`

  ## src/components/SettingsDrawer.tsx

  - **export SettingsDrawer({ ... }: Props)** (start 158, end 336) → (none)
For example:

ResultsTable calls getCellValue.

In these cases it's just one function but you also have stuff like

  **export Dashboard()** (start 36, end 635) → `getTopKeywords`, `normalizeText`, `searchKeywords`, `searchKeywordsMulti`, `searchSemantic`, `searchSemanticMulti`
For the Python version it also gives the parameters and types along with it. I think the next thing I'd need to do is give self-defined type definitions. Doing things this way allows an LLM to not read all that much but to be able to reason relatively well over what the code does. The caveat is that you abstracted your code well. If you didn't, the LLM doesn't know your implementation.

I probably should also add return types.

Post reply on HN