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

Toolkit to help you get started with Spec-Driven Development

github.com

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Toolkit to help you get started with Spec-Driven Development

#31

Post by BobbyTables2 »

MoreQARespect wrote: post #23
shubhamjain wrote: post #9

> Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them. Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. Nothing against AI, I love it as a tool, but this "you-don't-need-code" approach shows similar signs. Quick win…

>Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. It never really went away. The problem is that there is a dearth of teaching materials telling people how to do it properly: * E2E test first * Write high level integration tests which match requirements by default * Only start writing lower level unit tests…

Not even sure the problem is just education.

For something complex, it’s kinda hard to write and debug high level tests when all the lower level functionality is missing and just stubbed out.

We don’t expect people to write working software that cannot be executed first, yet we expect people to write (and complete) all tests before the actual implementation.

Sure for trivial things, it’s definitely doable. But then extensive tests wouldn’t be needed for such either!

Imagine someone developing an application where the standard C library was replaced with a stub implementation… That wouldn’t work… Yet TDD says one should be able to do pretty much the same thing…

Re: Toolkit to help you get started with Spec-Driven Development

#32

Post by siva7 »

MoreQARespect wrote: post #23
shubhamjain wrote: post #9

> Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them. Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. Nothing against AI, I love it as a tool, but this "you-don't-need-code" approach shows similar signs. Quick win…

>Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. It never really went away. The problem is that there is a dearth of teaching materials telling people how to do it properly: * E2E test first * Write high level integration tests which match requirements by default * Only start writing lower level unit tests…

TDD failed because it was sold as a method on how to write better tests yet in reality it was a very challenging skill to learn on how to write software that involved a fundamental change in how you approached requirements engineering, software development, iterations and testing. Even with a skilled team the cost to adapt TDD would be very high for an uncertain outcome. So people tried shortcuts like you described and you can't blame them. The whole movement was flawed and unrealistic in its expectations and communications.

Re: Toolkit to help you get started with Spec-Driven Development

#33

Post by CPLX »

BobbyTables2 wrote: post #29
CPLX wrote: post #22

Earlier quoted context omitted.

What's wrong with TDD? This is a serious question, not starting an argument.

Try it and you’ll quickly see…

I have. I don’t hate it, though I don’t think it’s a magic bullet either.

Re: Toolkit to help you get started with Spec-Driven Development

#34

Post by isodev »

JimDabell wrote: post #8
isodev wrote: post #6

Can I use it without the uv tool? I’d rather my open source projects remain open as in libre.

uv is Apache and MIT-licensed. It’s as “open as in libre” as it gets.

But made by a corp in the “Extend” phase of embrace-extend-extinguish. No thanks. Fanboys love a new tool but let’s for once look ahead a bit before jumping in.

Re: Toolkit to help you get started with Spec-Driven Development

#35

Post by trjordan »

dennisy wrote: post #14
trjordan wrote: post #4

I don't think we ever get away from the code being the source of truth. There has to be one source of truth. If you want to go all in on specs, you must fully commit to allowing the AI to regenerate the codebase from scratch at any point. I'm an AI optimist, but this is a laughable stance with current tools. That said, the idea of operating on the codebase as a mutable, complex entity, at arms length, makes a TON of…

Tern looks very interesting. On your homepage there is a mention that Tern “writes its own tools”, could you give an example on how this works?

If you're thinking about, e.g. upgrading to Django 5, there's a bunch of changes that are sort of code-mod-shaped. It's possible that there's not a codemod for it it that works for you.

Tern can write that tool for you, then use it. It gives you more control in certain cases than simply asking the AI to do something that might appear hundreds of times in your code.

Re: Toolkit to help you get started with Spec-Driven Development

#36

Post by throwaway290 »

insin wrote: post #12

This isn't just me not reading your comprehensive guide [1]. It's me recognising you couldn't even be bothered to write it yourself. [1] https://github.com/github/spec-kit/blob/main/spec-driven.md

It's a write only world. They want you to ask copilot for summary. The spice must flow

Re: Toolkit to help you get started with Spec-Driven Development

#37

Post by moi2388 »

jmann99999 wrote: post #30
CPLX wrote: post #22

Earlier quoted context omitted.

What's wrong with TDD? This is a serious question, not starting an argument.

My issue with it has always been that I just don't think the way TDD requires. I think in terms of building features. TDD generally requires thinking in terms of proving behavior. I still can't wrap my head around first writing a test that fails and then writing minimal code to make it pass (I know I am simplifying it). Different strokes for different folks. I'm sure it works great for some people but not for me.

Well, all it does is basically enforce you code with testing (abstraction) in mind, and only focus on what you need.

So you build feature A. Great.

Why not write a test to instantiate the feature? It will fail, because you haven’t built it yet. Now go build it.

I assume you build the interface first already, before every little detail of the methods?

Also, you really don’t have to stick to the TDD principles that much. It’s basically to ensure: 1. You have a test which can fail (it actually tests something) 2. You actually have a test for your unit 3. You actually only code what you’re supposed to

This is great for juniors, but as you have more experience, these individual steps lose value, but the principles remain I think.

Also, I would never write tests for every method (as TDD might have you believe), because that’s not my “unit” in unit testing.

Re: Toolkit to help you get started with Spec-Driven Development

#38

Post by MoreQARespect »

BobbyTables2 wrote: post #31
MoreQARespect wrote: post #23

Earlier quoted context omitted.

>Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. It never really went away. The problem is that there is a dearth of teaching materials telling people how to do it properly: * E2E test first * Write high level integration tests which match requirements by default * Only start writing lower level unit tests…

Not even sure the problem is just education. For something complex, it’s kinda hard to write and debug high level tests when all the lower level functionality is missing and just stubbed out. We don’t expect people to write working software that cannot be executed first, yet we expect people to write (and complete) all tests before the actual implementation. Sure for trivial things, it’s definitely doable. But then e…

>Imagine someone developing an application where the standard C library was replaced with a stub implementation… That wouldn’t work… Yet TDD says one should be able to do pretty much the same thing…

No it doesnt say you should do that. TDD says red green refactor that is all. You can and should do that with an e2e test or integration test and a real libc to do otherwise would be ass backwards.

Yours is the exact unit testing dogma that I was referring to that people have misunderstood as being part of TDD due to bad education.

Re: Toolkit to help you get started with Spec-Driven Development

#39

Post by MoreQARespect »

nchmy wrote: post #28
MoreQARespect wrote: post #23

Earlier quoted context omitted.

>Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. It never really went away. The problem is that there is a dearth of teaching materials telling people how to do it properly: * E2E test first * Write high level integration tests which match requirements by default * Only start writing lower level unit tests…

Would you be able to share any links that expand upon your recommended approach? It makes complete sense to me as a self-taught dev, and is what I've always done (most recently, an e2e test of a realtime cdc etl pipeline, checking for/logging and fixing various things along the way until I was getting the right final output). I rarely write unit tests. It would be good to read something more formal in support of what…

no, but i have a feeling i should write one because i keep running into this misunderstanding.

it makes it really hard to recommend TDD when people believe they already know what it is but are doing it ass backwards.

Re: Toolkit to help you get started with Spec-Driven Development

#40

Post by Maxious »

rendall wrote: post #5
lngr wrote: post #3

Earlier quoted context omitted.

Yes, I love it. I have used it a while with Claude Code, Codex CLI and Windsurf. It's awesome with Claude Code. Codex CLI produces just garbage. Windsurf results vary, even when I use it with Claude models. I now use it with Windsurf for the specify and plan modes, and Claude for the implementation.

I'm a bit confused by this. Codex does not appear to be one of the options?

>AI assistant to use: claude, gemini, copilot, cursor-agent, qwen, opencode, *codex*, windsurf, kilocode, auggie, roo, codebuddy, amp, or q

https://github.com/github/spec-kit/tree/main?tab=readme-ov-f...

Post reply on HN