This works well for problems that are purely algorithmic in nature. But problems often have solutions that don't fall into those categories, especially in UI/UX. When people tell me that LLMs can solve anything with a sufficiently details spec, I ask them to produce such a spec for Adobe Photoshop.
The quality x price curve is not linear. Expensive materials and engineering often produce only incremental quality improvements, if any. Sometimes the improvements are only cosmetic. So Apple's headphones would need to be a lot closer to the best of the best than 80-90% in order to justify their price.
I think Apple is more responsible. One of Flash's chief benefits to the customers who paid the big bucks was that it 'just worked' everywhere. Once Apple stopped supporting Flash on the iPhone, that story was a lot less attractive.
The bugs were definitely Adobe's fault: as with most tech companies, they were far more interested in expanding the feature set than they were on fixing the bugs and stabilizing the platform.
Does anyone know if the company is still active. Haven't seen any updates for a while now. I like the product a lot, but products like this need security updates at the very least.
I discussed approaches in my earlier reply. But what you are saying now makes me think you are having problems with too much context. Pare down your CLAUDE.md massively and never let you context usage get over 60-65%. And tell CLAUDE not to commit anything without explicit instructions from you (unless you are working in a branch/worktree and are willing to throw it all away).
Those kinds of errors were super common 4-6 months ago, but LLM quality moves fast. Nowadays I don't see these very often at all. Two things that make a huge difference: work on writing a spec first. github.speckit, GSD, BMAD, whatever tool you like can help with this. Do several passes on the spec to refine it and focus on the key ideas.
Now that you have a spec, task it out, but tell the LLM to write the tests first (like Test-Driven Development, but without all the formalisms). This forces the LLM to focus on the desired behavior instead of the algorithms. Be sure to focus on tests that focus on real behavior: client apis doing the right error handling when you get bad input, handling tricky cases, etc. Tell the system not to write 'struct' tests - checking that getters/setters work isn't interesting or useful.
Then you implement 1-3 tasks at a time, getting the tests to pass. The rules prevent disabling tests, commenting out tests, and, most importantly, changing the behavior of the tests. Doesn't use a lot of context, little to no hallucinating, and easily measurable progress.
Wrong. If you know nix then you know "leverages the unique way that Flox environments are rendered without performing a nix evaluation" is a very significant statement.
I don't think its for everyone, the paper metaphor either works for you or it doesn't.
That said, the other big benefit for me is it breaks a lot less often than hyprland and its ecosystem seems to (and I don't just mean bugs here, I also mean things like config file format changes). And this isn't a slam on hyprland - I was only ever mildly annoyed by its breakage.
So the Safari developers are overworked/under-resourced, but Google somehow should have infinite resources to maintain things forever? Apple is a much bigger company than Google these days, so why shouldn't they also have these infinite resources? Oh, right, its because fundamentally they don't value their web browser as much as they should. But you give them a pass.