Live data from Hacker News

Verified Spec-Driven Development (VSDD)

gist.github.com

41–50 of 122 posts

Re: Verified Spec-Driven Development (VSDD)

#41

This is a decent approach. My concern with TDD is that writing tests necessarily implies designing an API upon which those tests operate. Here, the agent is instructed to "not write code, write tests", and yet, in doing so it defines an API. This will cause the AI to hallucinate the API. Layering in yet more tests on top of this will cause that API to deform in strange ways that pass tests but that the adversary will…

> My concern with TDD is that writing tests necessarily implies designing an API upon which those tests operate It really forces you to do outside-in testing; I usually describe the kind of API I want when chatting with the agents. For example, the CLI options, the routes that might be useful for an API, etc. > I look at the code and find a rats nest / ball of mud that will cost 10x more tokens to enhance should I ev…

In "proper" TDD you you supposed go:

- write a test for method that does not exist, it just calls the method and nothing else

- write method that does nothing

- add/extend test that uses that method - modify method until tests passes

- go back to loop start until you're done

I always hated it. When I work with LLM i first massage interface that tests, then tests, then implementation until all these tests pass.

> for example when it re-outputs the complete file when you ask for a tiny change).

well with sonnet 3.5 and 4.5 (can't say about 4.6) it often will get stuck in a loop trying to update just the required parts and iether waste tons of tokens doing these updates or waste tons of tokens to a point where restring file from git is required. Tokens get wasted regardless.

Re: Verified Spec-Driven Development (VSDD)

#42
post #38

Earlier quoted context omitted.

The runners are failing because it moved them from github hosted to self hosted and its requiring fixes, but you would know that if you actually paid attention to the commits and werent just looking for cheap dunks. Have a good one.

I looked at the past few pages of your repo's history and half the time it is broken. Is this continued failure despite using a verified spec, or did you not use one? If not which repo should we look at instead? I am sorry but I see nothing from you to engage here.

[dead]

Re: Verified Spec-Driven Development (VSDD)

#43

I’ve gotten the absolute best results from LLMs just acting like the software engineer I’ve aspired to be the past 15 years. Normal dev things. Scope the ticket properly, break it down. Test well. Write the correct docs. LLM specific things are going to be gone next week

I feel this very recently. I just pretend the agent is a junior dev and tell them to do things I don’t have time for. Reviewing the changes at my convenience is a lot like checking in on a junior dev, too. On the other hand I do feel like I get better results with the same teeing up that a junior dev requires, so I try to remove as many unknowns/dependencies as possible (or else explicitly tell it to leave some things as stubs) before sending him off to do something

Re: Verified Spec-Driven Development (VSDD)

#44
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…

If the price of code is zero then changing the spec also costs zero in terms of code and. This is what always was the problem with specs before. You'd write one, run it through the prover, write the code, then have to throw out the whole thing because there was a business case you didn't account for.

Now the bottom 98% can be given to a robot with a clear success signal other than 'it looks about right'.

Re: Verified Spec-Driven Development (VSDD)

#45

LLM-assisted development feels a lot like trend-driven development. When dealing with technique and heterogenous prompts and goals, it’s easy to gain somewhat of a gambler’s fallacy with respect to a particular technique. Spec-driven development feels pretty questionable to me. I’m sure it works fine for feature work that is predictable or has been done before, but then I wonder why you’d waste your time with it. Pri…

Or maybe people who like talking much more than they like code are now very excited about the possibility that talking has eaten software development. This is exactly backwards. For many tasks, formal languages are better, more real, more beautiful than English. No matter how many millions of tokens you have, you will never talk the formulas of Fermat, Euler, and Gauss into irrelevance. And the same is true of good c…

> a lot of code is ugly and utilitarian too,

And as everyone who can abstract well knows: Ugly code that have staying power have a reason to be ugly. And the best will be annotated with HACK and NOTE comments. Anything else can be refactored and abstracted to a much better form. But that requires a sense of craftsmanship (to know better) and a time allowance for such activity.

Re: Verified Spec-Driven Development (VSDD)

#47
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…

code is orthogonal to spec. you can iterate on the code and iterate on the spec. the spec is not meant to be constant, it's a form of ECC for the artifacts of the coding pipeline.

Re: Verified Spec-Driven Development (VSDD)

#48
post #41

Earlier quoted context omitted.

> My concern with TDD is that writing tests necessarily implies designing an API upon which those tests operate It really forces you to do outside-in testing; I usually describe the kind of API I want when chatting with the agents. For example, the CLI options, the routes that might be useful for an API, etc. > I look at the code and find a rats nest / ball of mud that will cost 10x more tokens to enhance should I ev…

In "proper" TDD you you supposed go: - write a test for method that does not exist, it just calls the method and nothing else - write method that does nothing - add/extend test that uses that method - modify method until tests passes - go back to loop start until you're done I always hated it. When I work with LLM i first massage interface that tests, then tests, then implementation until all these tests pass. > for…

I like tests, but I don't bother with TDD because it's so ceremonial. I design the API, or at least sketch it out (using a whiteboard or drafting some notes, and doing research). Then I iterate and refine. I only bother with tests once I can commit or when it's no longer viable to tests manually (edit-compile-run cycle). And a lot of time I follow the table pattern.

https://www.oreilly.com/library/view/simplicity/979888865170...

Re: Verified Spec-Driven Development (VSDD)

#49
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?
Post reply on HN