> The code itself is basically disposable.

I'm finding this is the case for my work as well. The spec is the secret sauce, the code (and its many drafts) are disposable. Eventually I land on something serviceable, but until I do, I will easily drop a draft and start on a new one with a spec that is a little more refined.

▲

dotancohen 2 days ago | parent | next [-]

I just like to add that the database design is the real secret sauce, important even more than external APIs in my opinion.

▲

all2 2 days ago | parent | next [-]

This is something that I've stumbled into as well. DB models AND dataflow. Getting both of those well spec'd makes things a lot easier.

▲

mattmanser 2 days ago | parent | prev [-]

Well, not DB design really, you can achieve the same thing by defining your POCOs well. I switched entirely to code-first design years ago. If you haven't worked with a good ORM, you're really missing out, though I admit there was quite a bit of friction at first.

	▲	dotancohen 2 days ago \| parent [-]
		No, I really am talking about how the database is organised. Tables representing objects, normalisation, etc. Whether or not it is accessed through the application with an ORM.

▲

bjornsing 2 days ago | parent | prev [-]

So how do you best store and iterate on the spec? One way I guess would be to work on a branch an modify Claude.md to reflect what the branch is for. Is that a good approach? Are there others?