Earlier quoted context omitted.
The observability stuff can be nice for deployments but really, these libraries/frameworks don't actually do much more than provide some structure, which unless you're expecting a team with high turnover to maintain it, doesn't really matter all that much, especially if you're an experienced developer, you'll find better design/architectures fitting for your use case without them.
Hm I find this very much a "please reinvent the wheel" take. These frameworks provide structure for established patterns,but they also actually do a lot that you don't have to do anymore. If you are for example building an agentic application then these kind of frameworks make it very simple to create the workflows, do the chat with the model providers, provide structure for agentic skills, decision making and the hu…
But those are also very trivial to build, and you end up having to customize them for your need, and if the framework don't have those levers, better be prepared to either fork the framework, or spend time contributing upstream.
Or, start simple yourself with what you need, use libraries for the hairy parts you don't want to be responsible for the implementation of, then pipe these things together. You'll get a less compromised experience, and you'll understand 100% how everything works, which is the part people generally try to avoid and that's why they're reaching for frameworks.
> But if you like to move faster and using good building blocks then these frameworks really help.
I find that they help a lot with the "move faster" part in the beginning, but after that period, they slow you down instead. But I'm also a person that favors "slow software design and development" where you take your time to nail down a good design/architecture before you run. Slow is fast, and avoiding hairballs is the most important part if you're aiming for "move fast for longer" rather than "a sprint of fast".