> it doesn't really matter in the end

if you have one of the top models in a disruptive new product category where everyone else is sprinting also, sure..

Code quality never really mattered to users of the software. You can have the most <whatever metric you care about> code and still have zero users or have high user frustration from users that you do have.

Code quality only matters in maintainability to developers. IMO it's a very subjective metric

It's not subjective at all. It's not art.

Code quality = less bugs long term.

Code quality = faster iteration and easier maintenance.

If things are bad enough it becomes borderline impossible to add features.

Users absolutely care about these things.

Okay, but I meant how you measure is subjective.

How do you measure code quality?

> Users absolutely care about these things.

No, users care about you adding new features, not in your ability to add new features or how much it cost you to add features.

Yes that was pretty much my own takeaway, too.

After some experience, it feels to me (currently primarily a JS/TS developer) like most SPAs are ridden by memory leaks and insane memory usage. And, while it doesn't run in the browser, the same think seems to apply to Claude CLI.

Lexical closures used in long-living abstractions, especially when leveraging reactivity and similar ideas, seems to be a recipe for memory-devouring apps, regardless of browser rendering being involved or not.

The problems metastasize because most apps never run into scenarios where it matters, a page reload or exit always is close enough on the horizon to deprioritize memory usage issues.

But as soon as there are large allocations, such as the strings involved in LLM agent orchestration, or in non-trivial other scenarios, the "just ship it" approac requires careful revision.

Refactoring shit that used to "just work" with memory leaks is not always easy, no matter whose shit it is.