Hacker News Reader

Comment by tconfrey | Hacker News Reader

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/

View on HN

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.

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.

You can have small design up front as-well. You write down one or two pages, let the LLM generate code and tests. Keep iterating. If you believe in 100% LLM coded applications, then it makes sense to manage the English input as specifications. Instead of throwing the prompts away, you neatly organize them. Plus you can add additional constraints when the AI does something you don't like.

But I don't trust LLMs to program anything critical, and only do sandbox/tests/demo's. Things where code quality is less important.

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.

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.

Reply on news.ycombinator.com