Top
Best
New

Posted by todsacerdoti 8 hours ago

Verified Spec-Driven Development (VSDD)(gist.github.com)
135 points | 66 commentspage 3
rsrsrs86 4 hours ago|
That’s how I do it, minus the marketing.
beders 6 hours ago||
> Define the contract before writing a single line of implementation. Specs are the source of truth.

There is only one source of truth and that is the source code. To define and change contracts written in an ambiguous language and then hope the right code will magically appear, is completely delusional.

Iteration is the only game in town that is fast and produces results.

mitchbob 6 hours ago||
Upvoted for the Sarcasmotron.
politician 8 hours ago||
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 not be able to cope with because it runs too late in the VSDD process.

I've seen this exact process play out in my own work. The AI generates code and tests that pass with high code coverage and honors invariants set by spec. I look at the code and find a rats nest / ball of mud that will cost 10x more tokens to enhance should I ever need to add a feature.

So, I think you're on to something, but I think the process might be discounting extensibility and resilience under change.

NeutralForest 7 hours ago||
> 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 ever need to add a feature.

Agreed, I don't know if there are good forcing functions to avoid complexity. The providers have a huge incentive to have you waste your tokens (for example when it re-outputs the complete file when you ask for a tiny change).

0x457 4 hours ago|||
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 <-- this very loop starts

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

skydhash 4 hours ago||
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...

bonesss 7 hours ago|||
“Test Driven Design” is another way to frame it.
DaylitMagic 7 hours ago||
I see what you're saying. Modularity and interfaces are really important between the different aspects of what's being developed. And it is worth putting time into the question "if another will use this, what would they potentially use it for, and why?". It doesn't mean that it needs to be built now - but considering that and ensuring that the planned code executes against that is a good strategy.
desireco42 7 hours ago||
Claude or something different... there is life beyond Claude I assure you and it is quite good and colourful.
esafak 6 hours ago||
This is AI slop not worth my time. What would be interesting is if the author shared her practical experience in implementing it. Let's see some of those specs. What tricky bugs did it catch? The author's latest repo hasn't even been passing CI, so what does that say? https://github.com/dollspace-gay/Tesseract-Vault/commits/mai...
dollspace 5 hours ago||
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.
esafak 5 hours ago||
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.
dollspace 4 hours ago||
[dead]
relativeadv 6 hours ago||
yes, all of the typical signs and symptoms appear to be there. Lists upon sublists of verbose overengineered plausibly thoughtful writing.

If you can't be bothered to write it, why should i be bothered to read it?

galoisscobi 7 hours ago|
I think this word salad doesn’t have enough buzzwords. Throw in a few more acronyms too.