The parts you keep quoting are the rhetorical questions in the opening, not the actual arguments. The article is written for those who might assume these things mean something about Electron or Claude, not to argue those assumptions are actually true the whole way through. E.g. in an article starting:
"We have cheap elevators, why aren't all floor connections using them?
The state of elevators can be summed up by this fact: The OTIS Elevator Company Factory Building cost $x million to build, but it still has stairs"
The only thing this section asserts is "stairs seem to still be chosen". It's not actually asserting anything else yet, it's grabbing the attention of those who commonly assume this must mean a lot of things. It sounds exactly like something someone who would want to say Elevators and OTIS are useless bad crap would start with, but intentionally stops short of that conclusion from these to instead take things in a different direction which is still compatible with this information.
The assertions on Electron actually start later on here, and do not source from the design decisions of the Claude desktop app:
> There are downsides though. Electron apps are bloated; each runs its own Chromium engine. The minimum app size is usually a couple hundred megabytes. They are often laggy or unresponsive. They don’t integrate well with OS features. (These last two issues can be addressed by smart development and OS-specific code, but they rarely are.
These are not sourced from the design decisions of Anthropic. The first is an assertion of fact of what Electron is, a bundled instance which runs a full browser engine resulting in a large minimum app size. The next two assertions are actually not assigned to Electron itself, rather development effort. The only poorly sourced assertion here is that such apps are rarely well optimized, but if you take issue with that it does not actually impact the rest of what the article talks about.
The article then spends some time talking about why Electron is actually a common choice despite this, which eventually leads to the actual assertions about Electron's usage in the Claude app:
> But we’re still leaning on Electron. Even Anthropic, one of the leaders in AI coding tools, who keeps publishing flashy agentic coding achievements, still uses Electron in the Claude desktop app. And it’s slow, buggy, and bloated app.
There are 3 assertions here.
1. Anthropic has shown all sorts of flashy things with AI coding tools
2. The app is still using Electron
3. The app is slow, buggy, and bloated.
These assertions are not interdependent, they are just observations of the app. The article is still not arguing Electron can only be slow/buggy (though it has previously asserted it must be bloated by nature) nor is the app asserting why Anthropic has made these design choices yet. It is still following the train of thought one might be biased to from the original thought but carrying it further to perhaps unexpected conclusions.
The question in the reader's mind the article seeks to next pre-emptively answer is now stated: "So why are we still using Electron and not embracing the agent-powered, spec driven development future?". Most likely the reader has "make it a native app" as the first path, but the article already laid out 2/3 of these things can be solved with a smartly written Electron app. In either case, the article is not asserting why the Claude desktop team chose/chooses a particular design choice, it's seeking to answer why having great coding agents isn't necessarily a free answer to slowness, bugginess, and bloat in a cross platform app.
This is where the article finally makes its core argument:
> For one thing, coding agents are really good at the first 90% of dev. But that last bit – nailing down all the edge cases and continuing support once it meets the real world – remains hard, tedious, and requires plenty of agent hand-holding.
Using quotes from Anthropics implementation of the C compiler to back up this claim and then continue discussing how the benefits of a common approach over an optimised approach still exists outside of the raw code writing portion of the problem. At this point the article is still avoiding that the Claude desktop team must want a native app as a design goal, only speaking to why coding agents aren't the cure-all for the particular problem set (regardless of approach).
This is why the article concludes:
> For now, Electron still makes sense. Coding agents are amazing. But the last mile of dev and the support surface area remains a real concern.
Rather than:
> For now, it's clear coding agents must suck because Anthropic hasn't used them to come up with a more efficient alternative to the obviously poor choice of Electron or rewrite the app as separate native apps - which must obviously be their goal because coding agents are supposed to be able to write code