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

21–30 of 43 posts

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

#21

Post by DeathArrow »

spot5010 wrote: post #17
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…

The reason code can serve as the source of truth is that it’s precise enough to describe intent, since programming languages are well-specified. Compilers have freedom in how they translate code into assembly and two different compilers ( or even different optimization flags) will produce distinct binaries. Yet all of them preserve the same intent and observable behaviour that the programmer cares about. Runtime perf…

What about pseudocode? It is high level enough.

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

#22

Post by CPLX »

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…

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

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

#23

Post by MoreQARespect »

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 when a clear and stable API emerges.

and most people when they tried it didn't do that. They mostly did the exact opposite:

* Write low level unit tests which match the code by default.

* Never write a higher level tests (some people don't even think it's possible to write an integration or e2e test with TDD because "it has to be a unit test").

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

#24

Post by apex_sloth »

I played with this extensively on hobby projects (music visualizer Wayland widget for example) and I like the idea. I like coming up with cool stuff and solutions. The problem is I'm just not disciplined enough, it makes me lazy. The longer I uses it, the less code I read myself and just fire quick /implement loops and go do something else, thinking it should be straight forward. As other have pointed out, AI still needs a lot of hand holding and there are a lot of necessary decisions to make that one usually only realizes while actually building it.

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

#25

Post by spot5010 »

DeathArrow wrote: post #21
spot5010 wrote: post #17

Earlier quoted context omitted.

The reason code can serve as the source of truth is that it’s precise enough to describe intent, since programming languages are well-specified. Compilers have freedom in how they translate code into assembly and two different compilers ( or even different optimization flags) will produce distinct binaries. Yet all of them preserve the same intent and observable behaviour that the programmer cares about. Runtime perf…

What about pseudocode? It is high level enough.

Right, but it needs to be formalized.

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

#26

Post by hrimfaxi »

rsyring wrote: post #15

High level design concerns: https://github.com/github/spec-kit/issues/1092 Worth reading before jumping in.

Which points did you find particularly noteworthy? With "concerns" like

> We need to avoid at all costs the "great specs - no MVP" problem.

this issue doesn't seem useful or helpful at all.

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

#27

Post by dennisy »

discreteevent wrote: post #11
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…

There was a really good article on this here a few days ago that didn't get much traction. It was about how programming is a learning feedback loop and because of that there are good and bad ways to use LLMs: "The readymade components we use are essentially compressed bundles of context—countless design decisions, trade-offs, and lessons are hidden within them. By using them, we get the functionality without the lear…

This is a great read and one which for me personally really summarises my feeling on developing with LLMs.

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

#28

Post by nchmy »

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…

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 I've naturally gravitated towards

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

#29

Post by BobbyTables2 »

CPLX wrote: post #22
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…

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

Try it and you’ll quickly see…

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

#30

Post by jmann99999 »

CPLX wrote: post #22
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…

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.

Post reply on HN