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

Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

martinfowler.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#21

Post by josefrichter »

I like the part that uses custom slash commands as way to wrap your input into some well-structured prompt template for given type of task. I like the part that also injects relevant pieces of "broken down AGENTS.md" as I see it.

I don't like the part that tries to leave no knot untied, which creates that sledgehammer for cracking a nut, as mentioned in the article. But I am sure it's easy to add another custom slash command like "/experiment" or "/stub" that would bring those context management benefits without the bloat, in situations when you don't know yet what and how you want to build something.

And then maybe "/wrap-up" to tie all the untied knots once you're sufficiently happy. Kinda like surgeon stepping aside after the core part of the operation.

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#22

Post by josefrichter »

yodon wrote: post #2

This pretty much aligns with my experience with SpecKit - I'm excited by it, and enjoying working with it, but have had a hard time finding guidance on advanced real world use cases. All the tutorials I've found are little more than "here's how to install it - now let's make a todo list app from scratch!!" Would be great to see how others are handling real world use cases like making incremental improvements or refac…

yeah you need to read through its templates and "source code" to understand what it does - which is not necessarily a bad thing for this type of project.

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#23

Post by ilteris »

CuriouslyC wrote: post #18
tconfrey wrote: post #15

I've been watching this trend toward SDD. Makes sense but it feels like the process pendulum is swinging back toward the pre-agile era of functional specs and design documents. Not quite Big Design Up Front[0] but maybe increasingly working software == comprehensive documentation[1]? Waterfall anyone?! [0] https://en.wikipedia.org/wiki/Big_design_up_front [1] https://agilemanifesto.org/

Spec driven development is a good idea, but the current implementations are trash because they hand off markdown files to an agent who might as well be wiping its ass with them for all the reproducibilty you get. If you're going to have agents generate specs they should be structured and transformable via code gen in to actual stub code and tests. It's only a little bit more work than unstructured markdown specs, sav…

Do you have any documents how this could be achieved? Thanks

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#24

Post by beaker52 »

robertclaus wrote: post #16

Plotly's new Plotly Studio product is a spec-anchored approach to building data applications. Each chart or dataset gets its own prompt/spec. The question of how much detail to include in a spec is really hard. We actually split it into two levels - an input prompt describing details the user cares about in that component and an output spec describing what was built to allow verification.

At that point, isn’t it just a description of the chart or dataset?

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#25

Post by beaker52 »

tharkun__ wrote: post #5

Distinguished Engineer and AI-assisted delivery expert at Thoughtworks. And then talk about memory banks. Yeah, I recognize that from work where "AI has taken off" as well. Guess what: As memory banks grow or accumulate the AI gets confused and doesn't quite deliver. So far, a human that actually knows their product still prevails and is necessary to actually guide any AI effort. AIs have been trying to bullshit me s…

What exactly are you trying to say about their role description and the talk of memory banks?

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#26

Post by CuriouslyC »

ilteris wrote: post #23
CuriouslyC wrote: post #18

Earlier quoted context omitted.

Spec driven development is a good idea, but the current implementations are trash because they hand off markdown files to an agent who might as well be wiping its ass with them for all the reproducibilty you get. If you're going to have agents generate specs they should be structured and transformable via code gen in to actual stub code and tests. It's only a little bit more work than unstructured markdown specs, sav…

Do you have any documents how this could be achieved? Thanks

Take a look at the CLI subproject of https://github.com/sibyllinesoft/arbiter. It does all this. I am in the process of making a version of the CLI that's standalone with a fully open license, I'm just swamped ATM getting a side hustle ready for No Kings.

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#28

Post by fabianlindfors »

The note on how all those tools seem to mostly be spec-first and vague about spec maintenance was interesting to me. Me and my cofounder have been going all-in on spec-as-source, as we think it's really the most interesting use of specs, but it's also challenging to get of the ground. If anybody has any thoughts on this, I'd love to hear them.

Also in case somebody wants to try a spec-as-source tool, we'd love feedback: https://specific.dev

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#29

Post by bonesss »

tconfrey wrote: post #15

I've been watching this trend toward SDD. Makes sense but it feels like the process pendulum is swinging back toward the pre-agile era of functional specs and design documents. Not quite Big Design Up Front[0] but maybe increasingly working software == comprehensive documentation[1]? Waterfall anyone?! [0] https://en.wikipedia.org/wiki/Big_design_up_front [1] https://agilemanifesto.org/

Behaviour Driven Design, following Test Driven Design practice, can create a living specification. Human readable domain exploration, human-readable criteria, and direct links to the test harness to demonstrate conformance and domain capabilities.

This gives you verifiable set of spec documents (BDD reports for integration tests, acceptance tests, domain requirements, etc with green/red status), to iterate and collaborate on without requiring undue upfront work separated from the actual product. ‘Agile’, JIT, YAGNI-aware, specifications, no waterfall necessary.

Re: Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl

#30

Post by conartist6 »

fabianlindfors wrote: post #28

The note on how all those tools seem to mostly be spec-first and vague about spec maintenance was interesting to me. Me and my cofounder have been going all-in on spec-as-source, as we think it's really the most interesting use of specs, but it's also challenging to get of the ground. If anybody has any thoughts on this, I'd love to hear them. Also in case somebody wants to try a spec-as-source tool, we'd love feedba…

if the spec is truly the source, it's because you've invented a formal programming language that evaluates the spec.

Anything short of that and the spec is the spec, the source is the source.

Now you get to learn about what good code looks like, like the rest of us!

Post reply on HN