Developers spend most of their time reading long Markdown files, hunting for basic mistakes hidden in overly verbose, expert-sounding prose. It’s exhausting.

Those requirements exist regardless of whether you write them down in Markdown files or not. Spec-driven Development is just making what needs to be built explicit rather than assuming the whole team know what the code should do.

Practically every company already uses 'spec-driven development', just with incredibly vague specs in the form of poorly written Jira tickets. Developers like it because it gives them freedom to be creative in how they interpret what needs to be done, plus they don't need to plan things and their estimates can be total nonsense if they want, and Product Owners and BAs like it because it means they can blame shift to the dev team if something is missed by saying "We thought that was obvious!"

Every team should be capturing requirements at a level of detail that means they know how the code should work. That doesn't need to be done up front. You can iterate. Requirements are a thing that grow with a project. All that spec-driven development is doing is pushing teams to actually write them down.

You can get away with incredibly vague "specs" in tickets most of the time because of a shared understanding of the system and product – of the kind that an LLM won't have (without very careful and well-organised in-repo documentation). When it works, which in my experience is quite a lot, it's very efficient. Sometimes it fails, sure. Sometimes it's annoying because you actually do need more detail than is provided and have to ask for it in a conversation. In my experience that's a low cost because it happens much less often and isn't too laborious when it does.

But crucially, the details here are coming from the issue authors. Do you really think that issue authors are going to be reviewing LLM-generated specs? I don't think so. And so engineers will be the intermediary. If that's going to be me, I would rather mediate between the issue author, some kind of high-level plan, and code. Not the issue author, a high-level plan, code-like specs, and code. There is one extra layer in the latter that I don't see the value of.

> Developers like it because it gives them freedom to be creative in how they interpret what needs to be done, plus they don't need to plan things and their estimates can be total nonsense if they want

I like it because it moves me closer to the product, the thing actually being built. You seem to be asking to move the clock back to where there was a stricter division of labour. Maybe that's necessary in some industries, but none that I've worked in.

> Developers like it

Do they?