So we are cycling back to kind of Waterfall Development ? No more agility ? The trend is dead by AI ?
Verified Spec-Driven Development (VSDD)
111–120 of 122 posts
Re: Verified Spec-Driven Development (VSDD)
#112Earlier 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…
You claim to disagreeing with OP but you seem to be describing basically the same core loop of planning and execution. Doing OODA faster has always been the key thing to creating high quality outcomes.
No, OP literally claims "you can't spec out something you have no clue how to build"; I claim that on the contrary, you absolutely can - you don't need to know "how to build" but you need to clarify what you want to build. You can't ask AI to build something (and actually obtain a good "something") until you can say exactly what the said "something" is.
You iterate, yes - sometimes because the AI gets it wrong; and sometimes because you got it wrong (or didn't say exactly what you wanted, and AI assumed you wanted something else). But the less specific and clear you are in your requirements, the less likely it is you'll actually get what you want. With you not being specific in the requirements, it only really works if you want something that lots of people are building/have built before, because that will allow the AI to make correct assumptions about what to build.
Re: Verified Spec-Driven Development (VSDD)
#113[dead]
Re: Verified Spec-Driven Development (VSDD)
#114Does anyone know what Chainlink is?
I am guessing it is an issue tracker created by the same author.
Github link: https://github.com/dollspace-gay/chainlink
Re: Verified Spec-Driven Development (VSDD)
#115Some of the ideas here are codified in a simpler way in my TDD framework, CodeLeash ( https://codeleash.dev ). The key difference is CodeLeash puts guardrails outside the model, as Claude Code hooks. It can’t forget or skip steps, it gets forced through a process. There are bypasses but they raise alarms that the model is also forced to review. Putting guardrails outside the model forces deterministic process followi…
Cool but it is not a framework for working with AI, it is an _opinionated_ framework for building full-stack apps right? As in, I can't use any of it if I'm building, say, a Spark data processing pipeline. Or a ML framework. Or automation software that runs on custom processors.
The idea of "guardrails outside the model" is definitely appealing but I wonder if you can make it generalize well.
Re: Verified Spec-Driven Development (VSDD)
#116So we are cycling back to kind of Waterfall Development ? No more agility ? The trend is dead by AI ?
"Waterfall" got a bad rep because it meant "we stay months in the requirements gathering, then months design phase, then months in development, then months in validation". If you compress "months" to days/hours, what you obtain is something that nobody from the 90s would recognize as "waterfall"; it is not the end of agility, far from it.
Re: Verified Spec-Driven Development (VSDD)
#117Nice. It can work with something like https://github.com/github/spec-kit ?
My employer is trying to convince us to embrace spec-kit. But we are a Clojure shop: we iterate fast and produce results. We don't sit around and write specs and then hope working code plops out.
> We don't sit around and write specs and then hope working code plops out.
So what do you do then? Sit around hand-holding an AI agent while it implements code line-by-line? I'm being facetious, but my point is that if you're not doing some form of spec-driven development (that is, writing a plan and then letting an AI agent implement it mostly autonomously), then you might be operating at a slower pace than you think you are.
Re: Verified Spec-Driven Development (VSDD)
#118Some of the ideas here are codified in a simpler way in my TDD framework, CodeLeash ( https://codeleash.dev ). The key difference is CodeLeash puts guardrails outside the model, as Claude Code hooks. It can’t forget or skip steps, it gets forced through a process. There are bypasses but they raise alarms that the model is also forced to review. Putting guardrails outside the model forces deterministic process followi…
Cool but it is not a framework for working with AI, it is an _opinionated_ framework for building full-stack apps right? As in, I can't use any of it if I'm building, say, a Spark data processing pipeline. Or a ML framework. Or automation software that runs on custom processors. The idea of "guardrails outside the model" is definitely appealing but I wonder if you can make it generalize well.
You’re right of course, the framework is pretty rigidly tied to full stack.
But the underlying idea I think has power - find a process you can codify enforcement of rather than telling models how they should do things.
Spec driven development probably means creating tooling to track how code maps to specs, for example.. and then working out how to manage that as data. Then you can query the data to confirm all mappings between code and specs. That gets you out of the business of nicely and repeatedly asking very expensive and undependable models such queries :)
Re: Verified Spec-Driven Development (VSDD)
#119Some of the ideas here are codified in a simpler way in my TDD framework, CodeLeash ( https://codeleash.dev ). The key difference is CodeLeash puts guardrails outside the model, as Claude Code hooks. It can’t forget or skip steps, it gets forced through a process. There are bypasses but they raise alarms that the model is also forced to review. Putting guardrails outside the model forces deterministic process followi…
Nice, I had the same idea for a enforced TDD state machine! I wouldn’t tie it to all the other stuff though, but I might try it out.
Re: Verified Spec-Driven Development (VSDD)
#120Some of the ideas here are codified in a simpler way in my TDD framework, CodeLeash ( https://codeleash.dev ). The key difference is CodeLeash puts guardrails outside the model, as Claude Code hooks. It can’t forget or skip steps, it gets forced through a process. There are bypasses but they raise alarms that the model is also forced to review. Putting guardrails outside the model forces deterministic process followi…
Nice, I had the same idea for a enforced TDD state machine! I wouldn’t tie it to all the other stuff though, but I might try it out.
The TDD guard is the most isolated part of the whole thing, you could just take the files involved and ignore the rest. Maybe 6-7 files all referenced from the .claude/settings.json hook config.
Would be glad to see how you go!