I feel ya, but there's a better way. I've been writing detailed specs to direct LLMs, and that's what changed everything for me. I wrote about it at length: https://www.cleverthinkingsoftware.com/spec-first-developmen...
So, specs is more like an historical archive of decisions taken. I prefer to take a change request (ticket) transform it into a list of requirements, then apply that against the code rather than iterating through old specs in order to produce a new version of the code.
So it becomes f(z, k) where z is the specs for the change and k the old code, instead of f(a, b, c, …, z) (without k) where a and the others are updated specs and z is the new one.
ADDENDUM
In other words, specs are like memos while the code is the company policy handbook. No one edits past memos, you just issue new one, and then edit the handbook.
So I rather have code versions (git commits, …) that links to change requests, which link to discussion and analysis. Not dealing with a pile of documents.
I’d rather shared infrastructure fit a stability and correctness spec than fit the whims of some random programmers throwing a fit and refusing to adapt.
I suppose you’re fine with bridges built haphazardly and airplanes with doors that fall off.
There’s real infrastructure under the software that powers critical logistics. Such systems really should just be simple and straightforward.
You want ornate meta software structures? Have at it on your personal laptop like a proper h4xx0r
If you’re a real practitioner of the craft you’ll do it for free in your basement. If you’re just trying to unicorn you’re just a traditional capitalist and that’s boring.