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

11–20 of 33 posts

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

#11

Post by yoaviram »

Sharing my experience with SpecKit in case anyone finds it useful.

I've been using Speckit for the last two weeks with Claude Code, on two different projects. Both are new code bases. It's just me coding on these projects, so I don't mind experimenting.

The first one was just speckit doing its thing. It took about 10 days to complete all the tasks and call the job done. When it finished, there was still a huge gap. Most tests were failing, and the build was not successful. I had to spend an equally long, excruciating time guiding it on how to fix the tests. This was a terrible experience, and my confidence in the code is low because Claude kept rewriting and patching it with many fixes to one thing, breaking another.

For the second project, I wanted to iterate in smaller chunks. So after SpecKit finished its planning, I added a few slash commands of my own. 1) generate a backlog.md file based on tasks.md so that I don't mess with SpecKit internals. 2) plan-sprint to generate a sprint file with a sprint goal and selected tasks with more detail. 3) implement-sprint broadly based on the implement command.

This setup failed as the implement-sprint command did not follow the process despite several revisions. After implementing some tasks, it would forget to create or run tests, or even implement a task.

I then modified the setup and created a subagent to handle task-specific coding. This is easy, as all the context is stored in SpecKit files. The implement-sprint functions as an orchestrator. This is much more manageable because I get to review each sprint rather than the whole project. There are still many cases where it declares the sprint as done even though tests still fail. But it's much easier to fix, and my level of trust in the code is significantly higher.

My hypothesis now is that Claude is bed at TDD. It almost always has to go back and fix the tests, not the implementation. My next experiment is going to be to create the tests after the implementation. This is not ideal, but at this point, I'd rather gain velocity, since it would be faster for me to code it myself.

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

#12

Post by raphinou »

Seems I've been doing something like spec driven development on my last project. I keep a spec of the solution developed, and include it in every request sent to the ai, and it yields good results in my case. I'm still the developer in charge, but I can easily hand off non subtil or general code generation. It's clearly helped me code faster, though I had to spend quite some time on the spec, which still clarified a lot of things for me too. In the end I enjoy this approach.

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

#13

Post by htrp »

iamsaitam wrote: post #10

> When I asked Kiro to fix a small bug (it was the same one I used in the past to try Codex), it quickly became clear that the workflow was like using a sledgehammer to crack a nut. The requirements document turned this small bug into 4 “user stories” with a total of 16 acceptance criteria, including gems like “User story: As a developer, I want the transformation function to handle edge cases gracefully, so that the…

they did train it on the amazon way

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

#14

Post by pessimizer »

iamdeedubs wrote: post #4

In my experiments with SpecKit I was always left wondering "when does it merge all this specs into a single ground truth". I never got there and it felt like a huge missing step. Now I'm left trying to define/design what a "spec" for communication between humans and coding agents would look like, to power what Birgitta called spec anchored.

> Now I'm left trying to define/design what a "spec" for communication between humans and coding agents would look like, to power what Birgitta called spec anchored.

I feel that now with AI this is something that we have to finally do. Define how we write out a spec and record an architecture semi-formally, and in a way that is human-readable and human-manageable. And in a way that can 1) be consumed partially by an LLM context, rather than entirely (because it may be too big), and 2) have that partial ingestion be enough for it to do real work, either on the spec itself on or on the code, without deviating from the core intentions and architecture.

We tried and failed with the UML and Rational Rose type stuff, I think because it didn't record intentions well enough, was mostly pictures and not words, and seemed to be something that you would create after you finishd a project rather than fill in the details and guide you while you were building it. Hence, the whole idea fell away because it wasn't useful for anything but documentation, maintenance or refactoring; you were already selling the product before the spec became at all useful.

I'm left looking at vague leftfield ideas like https://c4model.com/.

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

#15

Post by tconfrey »

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/

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

#16

Post by robertclaus »

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.

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

#17

Post by 9rx »

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/

Functional specs and design documents are just programming in a natural language. In the olden days it took a human to "code" that into a programming language, but now that compilers (i.e. LLMs) are getting better at compiling natural language, it might look like you're able to skip a step (to varying degrees of success).

Whereas agile doesn't care what language you build your software in. It's about taking managers out of the picture; encouraging developers to get involved with what are normally considered "managerial" tasks. The 12 Principles goes into more detail about the things developers might need to do if there are no managers.

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

#18

Post by CuriouslyC »

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, saves a bunch of time in terms of boiler plate generation and gives you very high reproducibility.

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

#19

Post by CuriouslyC »

gsadaka wrote: post #3
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…

I have also struggled to find real world examples for these approaches. Following a BDD approach with a coding CLI works a lot better, as it documents the features as code rather than verbose markdown files no one will read. Having a checklist for an AI to follow makes sense, but that's why agents.md exists. Once the coding patterns and NFRs are documented in it, the agent follows them as well as they would follow a…

This focus on markdown specs is the dumbest thing. Have a spec DSL that can be validated and transformed into real code. I've already got this working with CUE (you can even define gherkin rules as part of the spec and it'll codegen them), I just need to split the CLI out from the enterprise product it's embedded in.

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

#20

Post by CuriouslyC »

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…

Memory is a bad idea right now, because it requires well tuned retrieval to deliver value, and one sized retrieval systems don't work, full stop. Most memory systems are designed around a homogenous chat paradigm and produce negative results in heterogenous chat environments or non-chat based agentic workflows.

The right way to do "memory" is to feed it to a "metacognition/default mode" network that builds a theory of mind / task ideation structure async from the main agent, then injects context relevant steering into the agent for each prompt based on this metamodel. So, "agentic memory" basically.

Post reply on HN