Their move to ColorOS away from the fully customized stock Android experience with OxygenOS was the nail in the coffin for me.
The overall experience turned terrible, and so many aspects of the OS were changed or worsened for all the wrong reasons. Everything from pulling the notification drawer and managing notifications, to the castrated home screen functionality, was such a disappointment.
>We need some way to make AI-driven coding strive for parsimony.
This is the single reason why my experience with agentic development honestly kind of sucks, and wastes so much of my time.
The simplest prompt can result in the most verbose garbage ever produced, and scope-creep nobody's every seen before.
AI has a huge cognitive load problem right now. It's no wonder why so many devs say they're completely exhausted after a few hours, and not in ways they were before they picked up agentic dev.
Bun's migration to Rust was nothing more than a marketing stunt to sell more Claude subs under the impression it can perform this kind of work at scale, assuming that most who were convinced by it wouldn't look under the hood at what really took place.
It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way.
Too many see it as this miraculous one-shot and are using it as a blueprint to justify more layoffs and buzzword salad in their boisterous LinkedIn announcements about how they're "completely overhauling their strategy" in engineering. Hogwash.
> "Users don’t care whether the code was written by AI or by hand, or which framework you used. They care that the product works."
1. Engineers should care about code quality so they can maintain it if their preferred AI providers are down or unavailable.
2. Code that's written well is easier for AI to navigate and modify.
3. Cognitive debt is real. I've been writing software for 20 years and without a doubt, I feel like my knowledge and edge are atrophying. This has been cited and confirmed by more than enough engineers who feel frustrated by this phenomenon.
4. Generating massive amounts of code significantly reduces accountability, making it impossible to review that code line-by-line unless you deliver your generated output in extremely small chunks (200-300 LOC per PR).
5. Since #4 is an objective reality, shipping code that hasn't been reviewed by a human is patently unethical, since the humans merging and deploying that code can't possibly know if there are lingering security holes or mishandling of sensitive information by their generated code.
6. One could say "well this is possible with hand-written code too", and they're right -- but the difference is, there was a human element in reviewing the code in good faith, rather than tossing thousands of LOC over a fence and telling their PAYING customers "good luck, hope it works!"
7. The other rebuttal is that tests and "guardrails" solve these problems. We all know that even the best test suite isn't foolproof. 100% coverage doesn't mean the tests are good, or will catch when something critical breaks.
8. AI guardrails are flaky at best: they're intended to be brief in order to save on context usage, but the more brief and numerous they are, the less accurate they'll be across a growing codebase. IME, many of the rules I've setup are obeyed by LLMs less than 100% of the time, which isn't enough to give me full confidence in them, because things will inevitably drift and fall through the cracks. Scale this to a team, and now you've got endless drift and disorder.
The arguments against AI have nothing to do with elegance, pretty code, formatting, or anything petty of the sort. It has everything to do with code quality and maintainability over time across teams of engineers who are accountable for their code, for products and services that people quite literally pay you for, trusting that what you're delivering them is stable, reliable, secure, and trustworthy.
If shipping speed is a higher priority than any of those, you have no business writing software to sell.
Quote: "This line of thinking boils down to, “Humans are valuable if they produce high-quality output.” This argument dangerously depends on the existing-but-narrowing human-AI capability gap. The gap certainly existed in the past (2023-era ChatGPT). It may still exist now. I do not know if it will hold in the future."
I still don't agree with this, because even the best engineers are producing poor output from AI, unless they spend a reasonable amount of time refactoring and cleaning up the output.
To expect a non-engineer to have the same wisdom to architect and structure their output in a sustainable way that will stand the test of time (and inevitable future changes), they're just fooling themselves.
For anyone who's been using LLMs long enough for development, we all know how sloppy the output is unless you have a mountain of formatting and organizational rules in place, and even then, it's anyone guess how well LLMs can actually follow them as a project scales.
Yes, value the human first, but there are strong reasons we've always emphasized mature patterns and idioms in codebases that help them remain maintainable so they can scale and transform with as little friction as possible, and without reaching a point where nobody has the stomach to keep working on it.
Just because we can try to have AI unwind the hairy mess, doesn't mean it's any easier for AI to navigate it than we do. It's a liability that the AI mistakes one naming conflict for another, when the context rot hits the fan — and after months of tossing unreviewed PRs over the finish line without a single thought, it's only a matter of time before your non-engineers are the worst offenders for introducing bugs and eroding the quality.
It doesn't matter how good the models appear to get (it truly is a facade), without judgment and wisdom, they still don't produce nearly the same quality as an experienced engineer, unless they're heavily steered.
Do they catch more potential bugs and edge cases than a human might? Definitely, but it's going to vomit its solutions in all the weirdest places doing it, and now suddenly you've got a 100k LOC pull request to (not) read.
This is pure cinema. I'm glad he's using his platform to call this out, it's rampant!
I usually just toggle Firefox's reading mode whenever a dickover like this pops up and they magically go away, allowing me to continue reading in peace.
I hate to say this, but this reeks of "We're owned by Anthropic now and we were put to task to prove Claude Opus as the ultimate AI model, so we were forced to do a full port of something millions of developers rely on to Rust in record time. Just ignore the slop and unsafe statements." (sweeps the broom)
This is nothing more than a marketing stunt from Anthropic. Nothing to see here.
Simple answer: it's easily reviewable by a human, which will always be an important step in the process of building software, no matter how many hype conferences tell you to stop checking AI output irresponsibly.
Specifically the line/page keys. I guess I've gotten used to MacBooks for so many years that I'm fine with pressing a modifier key and the arrow keys to navigate that way.
I'd rather do that than accidentally keep pressing "Home" instead of Backspace.
With this, I'd have to look down at my keyboard all the time to make sure I'm not mistakenly pressing those keys, because the hand is used to "resetting" on the edges of the keyboard to get a feel for the keys I expect to find on the edges: Enter, Shift, Arrow Keys, etc.
That keyboard layout is a deal breaker for me. Why do companies have to change things up all the time? Why can't they just go with T-shaped arrow keys and a standard layout?
It completely dwarfs the otherwise great hardware.
Judging by Anthropic's track record for sloppy, buggy software, I can't see this taking off quite as well as people might think, when compared to Figma and its captive customer base.
Figma actually put the work in to make a great product that performs well and offers anything you could imagine to design just about anything you need, with AI integrations and deep manual editing to sweat the details.
I agree somewhat, there's a common language for building products that most people understand and expect.
Innovation comes from the ways people differentiate, without straying too far from the tried-and-true patterns. It's the tiny decisions that situate UI elements and yes, reinvent the wheel sometimes, that can tip users over to whatever you're building because you did it better, or in a way "most" (the average) never thought of.
If people aren't creative in how it works, then really they're all just making the same, boring products, without truly competing against anyone in a meaningful way in the problem space. Visual appeal isn't a sole differentiator.