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.