This is just nuts. It’s why 99% of Software "Engineers" are just well-intentioned script kiddies, and why IT has such little credibility as an engineering discipline.

When a Civil Engineer writes a "spec"for a bridge they draw in centuries of engineering knowledge, experience, physics and rules. They don’t just whack out a sketch on the back of a fag packet, ask a bloke down the pub what he thinks and then start pouring concrete.

So if you’re following "Spec-Driven Development", which sounds a lot like what w’ve been doing for the last 70 years,at least have the smarts to have the spec reviewed until you have half a clue it’ll work.

1. Write a rough outline
2. Ask your LLM to explain it
3. Correct the gaps, ambiguities and errors in your original half-cocked idea
4. Ask your LLM to rewrite the spec with those corrections in mind
5. Review the spec (actual humans used to hold design reviews for this purpose, where others could feed their knowledge and experience in)
6. Ask the LLM to write a set of use cases
7. Get a prospective user to read them and provide feedback
8. Feed the LLM with the feedback
9. Keep doing this until the spec describes what you want.
10. Provide the LLM with architectural, design and coding standards. Ask it to rewrite the spec to include these.
11. Keep reviewing and providing feedback until the spec reads how it should read. If you don’t know, you’re poking and hoping. Good luck, maybe it works out, but this is "man in a shed" engineering
12. Once the spec makes sense, ask the LLM to propose a development plan.
13. Critique the plan, correct any wrong assumptions or critical path issues.
14. Ask it to update the spec and the plan
15. Ask it to carry out step 1.
16. Run the step 1 tests (you’re an engineer, surely you didn’t forget about tests???)
17. Iterate on step 1 until the tests pass
18. ask the LLM to update the plan based on the learnings from step 1
19. go to step 14 until you’re happy that all steps are complete and all tests are successful when run from start to finish
20. Now fill in the failure tests, happy-path testing isn’t good enough
21. when all tests pass, ask it to update the spec with a testing section that describes all test cases, with setup, process and outcomes
22. now you have a half-useful spec that you can use to build on.