> User stories are time-consuming to write and read and can silo engineers into a mechanical role where they code to the issue requirements instead of thinking about the user experience holistically at the product level.

A few problems with this:

1. User Stories, as described by Mike Cohn or in some other textbook description, are supposed to be light weight. They are time consuming to write only in so far it takes time to understand what is the 1-2 sentence summary of the thing to be done.

2. User stories are intentionally ambiguous to avoid "siloing engineers into a mechanical role where they code to the issue requirements." A User story says, "When you're done writing code, here's the thing that needs to happen. Tasks are useful when there isn't much ambiguity, but I've certainly worked with developers who take the approach "I wrote the database table task, I did the Java code task, I did the JavaScript front end task, I'm done" without sanity checking if everything works together.

3. A User Story literally says what the User Experience should be like. Even if that were the wrong approach, I fail to understand how telling developers "Here's what the User Experience should be like and why they want to do that thing" prevents them from thinking about the user.

Overall, even if there's some truth here, this is a silly article. Stating "User stories evolved over twenty years ago" isn't helpful, because tasks evolved even longer ago. User stories are supposed to be "short and simple" and "describe the task in plain language." I'm really left wondering if the things they call "tasks" and "user stories" are the same thing that I use for those terms.