And why would the responsibility lie solely on consumers to act perfectly

To answer your question though, to me your workflow seems cumbersome. Cursor is more integrated and more frictionless.

E2EE is not mandatory and public rooms don't usually use it.

One time there was a leak from a university database and as a result there were a few news articles over the years about people that had their identity stolen likely due to that leak. It's not just credit card charges. They have had loans taken in their names, stuff bought on store credit or something (nowadays that's not so easy), stuff stolen from library in their name...

They had to deal with the fallout for years, always fearing that there's a new letter waiting at home regarding some unpaid expense or from debt enforcement agency that they have to contact and try to make it go away. It shouldn't be too hard if you have an open case with the police but it's not always that easy.

Also, if the leaked data is sensitive (e.g. private conversations, records about mental health etc.), you can face extortion or the data may get published.

One other thing that I know of personally is that victims of harassment very much don't like to have their contact info leaked to the harasser.

"Overall, our results suggest that context files have only marginal effect on agent behavior, and are likely only desirable when manually written."

And trying to just hand-wave it to Claude, to somehow "improve it" or "simplify it", without detailed questions hasn't been very successful. It can work for some things, though.

I'd avoid such generalizations. It's a divisive topic, but from what I've seen here, there's always lots of criticism (regarding implementation at the minimum) in the comments and it definitely isn't clear that most would be jumping head first into anything.

2. I agree in general when talking about more complex operations. Simple transformation and filtering rarely needs intermediate variables for readability or debugging. And the naming of result variable already describes the final collection.

3. Never had to deal with this kind of code but I haven't used Kotlin.

I actually think the first code block is easier to read. It's a familiar (to me) and simple pattern that is quick to read. I don't get how it would require more "decoding" than the second example which is more disjointed and needs more "parsing" for such a trivial case. Maybe it's about what you're used to?

I agree there are downsides to chaining. With more complex operations it can complicate debugging, and readability can suffer, so chaining is not a good fit there.