Opus 5.5 has reduced this to an acceptable level for me. Are you also using this plugin with that model?

Yes! Some of my benchmarks was against Opus 5.5, and it reduced output over 50% on vanilla settings. Check repo for data.

i am also worried that all my private data might eventually (once tech is advanced enough) be surfaced somewhere: photos, chats, emails. wondering if i should start cleaning up now or just give up

My way of thinking about that has been that if it happens to me, it happens to «everyone». So it's symmetric.

> This party is not far-left, it is just left.

Of all parties in Germany that have a shot at governing, it is the furthest left. Thus, „far-left“ is not wrong in my opinion.

By this logic Biden's administration was far left.

By this logic Trump's administration is centerist.

That’s a huge overstatement. If that were true, then banks would code their core financial services with that approach but they don’t.

If you read the next couple of paragraphs, the author addresses this:

> That said, Steam's policy has been recently updated to exclude dev tools used for "efficiency gains", but which are not used to generate content presented to players.

I only quoted the first paragraph, but there is more.

If you squash your PR before merging, then this alternative worked really well for me:

  git fetch --prune && git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D

Almost identical to mine, but you've got smarter awk use: `git prune origin && git branch -vv | grep 'origin/.*: gone]' | awk '{print $1}' | xargs git branch -D`

I think I probably copied this from Stack Overflow close to a decade ago. Seems like a lot of people have very similar variations.

i was initially confused because i couldn’t find it in the article, but then i found what you quoted here: https://martinfowler.com/articles/expert-generalist.html

Yeah, sorry my head got dizzy I didn't realize I clicked away from the linked article.

Is „Dyehoe“ in the title a typo? Otherwise I don’t get it

It's a pun, look up Alan Dye :)

What I liked about GraphQL was the fact that I only have to add a field in one place (where it belongs in the schema) and then any client can just query it. No more requests from Frontend developers like „Hey, can you also add that field to this endpoint? Then I don’t have to make multiple requests“. It just cuts that discussion short.

I also really liked that you can create a snapshot of the whole schema for integration test purposes, which makes it very easy to detect breaking changes in the API, e.g. if a nullable field becomes not-nullable.

But I also agree with lots of the points of the article. I guess I am just not super in love with REST. In my experience, REST APIs were often quite messy and inconsistent in comparison to GraphQL. But of course that’s only anecdotal evidence.

But the first point is also its demise. I have object A, and want to know something from a related object E. Since I can ask for A-B-C-D-E myself, I just do it, even though the performance or spaghettiness takes a hit. Then ends up with frontend that's tightly coupled to the representation at the time as well, when "in the context of A I also need to know E" could've been a specialized type hiding those details.

> Then ends up with frontend that's tightly coupled to the representation at the time as well, when "in the context of A I also need to know E" could've been a specialized type hiding those details.

GraphQL clients are built to do exactly that, Relay originally and Apollo in the last year, if I’m understanding what you’re saying: any component that touches E doesn’t have to care about how you got to it, fragment masking makes short work

> No more requests from Frontend developers like „Hey, can you also add that field to this endpoint? Then I don’t have to make multiple requests“.

Do people actually work like this is 2025? I mean sure, I guess when you're having entire teams just for frontends and backends then yea, but your average corporate web app development? It's all full stack these days. It's often expected that you can handle both worlds (client and server) and increasingly its even TypeScript "shared universe" when you don't even leave the TS ecosystem (React w/ something like RR plus TS BFF w/ SQL). This last point, where frontend and backend meet, is clearly the way things are going in general. I mean these days React doesn't even beat around the bush and literally tells you to install it with a framework, no more create-react-app, server side rendering is a staple now and server side components are going to be a core concept of React within a few years tops.

Javascript has conquered the client side of the internet, but not the server side. Typescript is going to unify the two.

> It's all full stack these days. It's often expected that you can handle both worlds (client and server)

Full stack is common for simple web apps, where the backend is almost a thin layer over the database.

But a lot of the products I’ve worked with have had backends that are far more complex than something you could expect the front end devs to just jump into and modify.

I think you are misreading the parent comment here.