I disagree with a lot of the assertions the article makes.

IME: LLMs don't "thrive" in messy open-ended spaces. They handle spaces like that better than traditional code, and traditional code handles structured spaces a lot better, but LLMs still do perform better in structured spaces than unstructured ones. Giving them lists of tools, schemas for data, consistent examples, etc always produces better results than not doing this.

The correlate thesis you have to make is: Do humans work better in unstructured spaces. This can be true for highly creative and individual work, but generally (and especially in the enterprise SaaS world) the opposite is true. The Structure is how you keep the users of the product aligned on one pattern of usage. E.g. giving people the ability to just create whatever ticket fields they want in Linear ends up being useless because you'll end up with 10 fields that do similar things; the friction structure introduces is necessary because while it can cost a few seconds up-front as users learn how things are done, it saves time down the line as your organizational tools (filtering, dashboards, reports, etc) are aligned on the structure.

Its also 100% the case that oftentimes companies buy SaaS tools not to solve their problems, but to help them better structure the problems they have so they're even solvable at all. Think about Sentry: The end-goal of Sentry is to solve issues in web applications, for sure. But that's not why people buy it. I could do that without Sentry; but Sentry adds structure to the errors, it adds deterministic workflows to the errors, and it provides excellent SDKs to report them. Sentry's value isn't actually in the end-goal; its value is in the structure it adds every step before the end-goal. Accelerating the inputs by adding formality to them ends up accelerating the end-goal.