Toolkit to Help You Get Started with Spec-Driven Development

Is the key insight and biggest stumbling block for me at the moment.

At the moment (encourage by my company) I'm experimenting with as hands off as possible Agent usage for coding. And it is _unbelievably_ frustrating to see the Agent get 99% of the code right in the first pass only to misunderstand why a test is now failing and then completely mangle both it's own code and the existing tests as it tries to "fix" the "problem". And if I'd just given it a better spec to start with it probably wouldn't have started producing garbage.

But I didn't know that before working with the code! So to develop a good spec I either have to have the agent stopping all the time so I can intervene or dive into the code myself to begin with and at that point I may as well write the code anyway as writing the code is not the slow bit.

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

For spec driven development to truly work, perhaps what’s needed is a higher level spec language that can express user intent precisely, at the level of abstraction where the human understanding lives, while ensuring that the lower level implementation is generated correctly.

A programmer could then use LLMs to translate plain English into this “spec language,” which would then become the real source of truth.

That's a good idea, have a specification, divide into chunks, have an army of agents, each of them implementing a chunk, have an agent identify weak points, incomplete implementations, bugs and have an army of agents fixing issues.

"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 learning, leaving us with zero internalized knowledge of the complex machinery we've just adopted. This can quickly lead to sharp increase in the time spent to get work done and sharp decrease in productivity."

https://martinfowler.com/articles/llm-learning-loop.html

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").

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

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