I personally like the idea of separating the code and the "essential complexity". People can and probably should collaborate heavily on the latter, while the former gets better and better solved by the agents.
FYI, I know of folks who are working towards this, only sharing because that's on-topic, I am not affiliated: https://codespeak.dev/
Ah, yes. It's funny how processes, methodologies, architectures, etc. can come back around as the technology landscape changes. Spec-driven development (SDD) has its ties back to a process called waterfall (pre-dates Agile).
I like it with some caveats
- Make sure the first iteration of the spec is small, small, small. The biggest mistake on specs is thinking they have to be complete before the first line of code gets written. Gets something you can run and test as fast as possible.
- Keep the number of layers small at first. Only re-factor when you have to. Splitting things up has its own costs and that comes in complexity, payloads, http requests, runtimes, etc.
- SDD forces the shift-left model where you're going to have to face design choices very quickly. Those are can be tough architectural/feature questions that can grind your writing of the spec to a dead-stop. Don't let that stop you. Make a choice and keep moving.
I'll stop there. SDD has its place providing it doesn't become the focus of what you're building. Remember, the thing your building is a piece of software that supposed to do something. No one pays or cares about a spec ;).
I personally like the idea of separating the code and the "essential complexity". People can and probably should collaborate heavily on the latter, while the former gets better and better solved by the agents.
FYI, I know of folks who are working towards this, only sharing because that's on-topic, I am not affiliated: https://codespeak.dev/
Ah, yes. It's funny how processes, methodologies, architectures, etc. can come back around as the technology landscape changes. Spec-driven development (SDD) has its ties back to a process called waterfall (pre-dates Agile).
I like it with some caveats
- Make sure the first iteration of the spec is small, small, small. The biggest mistake on specs is thinking they have to be complete before the first line of code gets written. Gets something you can run and test as fast as possible. - Keep the number of layers small at first. Only re-factor when you have to. Splitting things up has its own costs and that comes in complexity, payloads, http requests, runtimes, etc.
- SDD forces the shift-left model where you're going to have to face design choices very quickly. Those are can be tough architectural/feature questions that can grind your writing of the spec to a dead-stop. Don't let that stop you. Make a choice and keep moving.
I'll stop there. SDD has its place providing it doesn't become the focus of what you're building. Remember, the thing your building is a piece of software that supposed to do something. No one pays or cares about a spec ;).