This sucks and it makes me sad. The end of an era.
I really hope Anthropic doesn't follow, but I assume they will eventually because why wouldn't they? Google and Meta obviously will, with great enthusiasm.
Come on now, arguing it's a good feature is different than arguing that it should be turned on by default for everyone with no documented option to turn it off.
I like this feature as an OPTION that is DOCUMENTED. But that's not how it was rolled out. The CC team + processes clearly failed here. And this is far from the first example of this kind of slopiness.
I don't think it was malicious, but I do think it was quite obviously reckless/careless, and I feel like most of the comments here match that sentiment. Everyone and every team makes mistakes, but unfortunately I don't see the CC team really learning from those mistakes even though they keep happening.
CC is not a stable or reliable tool, it is bleeding edge, and that's a tradeoff you make when you pick it over other harnesses.
I will never stop being fascinated with takes like this. Maybe you're right. But people said very similar things over the last few years and many of those statements look unbelievably naive in retrospect.
Sure, AI can auto-complete the line, but it can't write full functions.
Sure, AI can write functions, but it can't complete full features.
Sure, AI can write full features, but it can't build full applications.
Sure, AI can write full applications, but it can't build them in the right way / ask the right questions / write beautiful maintainable code / do what _I_ do..
I more meant feature-level differences. For instance, Claude Code has agent teams, and Codex CLI does not. Or for a while, Codex had "/goal" and Claude Code did not (though now Claude Code has it too). To your point, it is usually possible to polyfill these gaps either with custom code/skills/hooks or with third party plugins.
This is "Feature Factory" thinking, and it is usually not ideal. Feature count is a poor metric to optimize against. Instead, ROI and delivered customer value should be the focus of product development investments.
I understand and sympathize with this point of view.
I would just say this: there is a difference between advice for using a product, and for _optimizing_ your use of a product. Between a user and a power user.
I think devs probably disproportionately like to see themselves as power users of any given tool, and thus with coding agents, there are 1000 "systems" being thrown out on GitHub on any given day. Generally speaking, it is safe to avoid these, especially if you're new to the tool.
But saying the fact that people are into optimizing their setups indicates some fundamental deficiency of the tool misses the point, I think.
Claude Code and Codex CLI (and OpenCode, and I'm sure many others) are _remarkably_ effective right out of the box. The teams behind these tools must make them _generically_ useful so that they are accessible to as many people, and as many use cases, as possible. That is part of why, when you become familiar with the tool, there is typically going to be a level of customization you can apply to it to optimize it for _your_ use cases, beyond the generic out of the box configuration.
Similarly, I don't think it would be fair to critique VS Code simply because most power users augment it with a suite of extensions. In fact, it's customizability/extensibility is part of what makes it great.
Just use a fallback, like Codex CLI. Takes a little effort upfront to ensure your configuration is wired correctly for both harnesses, but it is pretty easy to get them 90% identical (there will almost always be some experimental / edge case features that differ across harnesses, but in my experience those are negligible in practice).
Came here to say this -- humans are not always rational actors. I get asked questions all the time, which I have no special knowledge of, and which the asker could have easily Googled or ChatGPTed. And yet...
I feel like caching should be mentioned in tradeoffs, right? If you change the tool list frequently, that's a cache bust. In long sessions that seems like it could significantly affect costs.
I have read and heard takes similar to OP's probably 50+ times from different people in the last few months (and years, now), and I agree mostly.
But I can't get over the myopic nature of this perspective. Technological advances often change the nature of work, and therefore change the nature (or location) of the "struggle".
I can imagine some hunter-gatherers probably admonishing early farmers at the dawn of agriculture for losing the "struggle" of hunting and foraging for their own food. It's much easier to drive a car than tame, train, and ride a horse. And so on throughout time.
So now with AI, some things that were hard before are now easy. So we move on to the next hard thing that maybe before was impossible or unimaginable. There is still hard work to be done.
This (from the September 2025 post) now evokes the Curb theme:
> Like you, we have seen numerous reports that more and more firms are capping their total headcount in favor of leaning on more AI tools, leading to downsizing their intern and new-graduate hiring. This is resulting in increased sidelining of new college graduates. But we think this misreads the moment completely, so we’re heading in the opposite direction.
> While we are excited about what AI tools can help do, we have a different philosophy about their role. AI tools make great team members even better, and allow firms to set more ambitious goals. They are not replacements for new hires — but ways to multiply how new hires can contribute to a team.
I want to agree, I do. But this point is plainly wrong in my observations:
> The enterprise version of that is I don’t want a CRM unless at least two other giant enterprises have successfully used that CRM for six months. [...] You want solutions that are proven to work before you take a risk on them.
Perhaps not for every category of software and every company. But in practice, any SaaS app that is just CRUD with some business logic + workflows is, imo, absolutely vulnerable to losing customers because people within their customers' orgs vibe coded a replacement.
They are perhaps even more at risk because would-be new customers don't ever even bother searching to find them as an option because they just vibe code a competitor in-house.
The vulnerability lies primarily in the fact that most of these SaaS apps were talking about are _wrong_ to some meaningful degree. They don't fully fit how your company works, and they never did. There is something about them that you are forced to work around in some way. This is true because it is impossible to build a universally perfect product, to perfectly fit it to every business requirement of every user in every company.
But now it is relatively cheap to build the perfect version for your company in-house. Or maybe even just for YOU.
I think medium/long-term this will mean a redistribution of technical talent from SaaS companies to industry companies. Instead of paying millions for SaaS subscriptions, industry companies will spend fewer millions building precisely what they need in-house with the help of AI. Not every SaaS and not every company, but I already see this happening at my company right now.
But it is working primarily because of the Max subscription model. If I could use my Max subscription to get $5000 worth of tokens for only $200 via OpenCode or Pi, I would drop Claude Code today. I think a lot of people (and enterprises) are of a similar opinion. Not saying Claude Code would have no users, but its dominance would be greatly diminished.
I think the argument here ignores a critical fact: a huge factor in Claude Code's popularity is the Claude Max plans. These plans give you potentially thousands of dollars of tokens for a capped $200.
Speaking for myself, I long for the day I can dump the comparatively garbage experience of Claude Code for something more enjoyable and OSS like OpenCode. But the fact is that it is simply not economically viable to do so.
So the PMF is not really for Claude Code alone -- it is for Claude Code + Claude Max.
I don't really see why evals are assumed to be exclusively in the domain of data scientists. In my experience SWEs-turned-AI Engineers are much better suited to building agents. Some struggle more than others, but "evals as automated tests" is, imo, so obvious a mental model, and can be so well adapted to by good SWEs, that data scientists have no real role on many "agent" projects.
I'm not saying this is good or bad, just that it's what I'm observing in practice.
For context, I'm a SWE-turned-AI Engineer, so I may be biased :)
As someone who works with real licensed engineers (electrical, civil), I wish we would use the term "agentic software engineering" to describe this. Omitting "software" here betrays a very SWE-centric mindset.
Agents are coming for the other engineering disciplines as well.
Socials: - github.com/htxryan
Interests: Programming, Remote Work, Technology, Books, DevOps, Outdoor Activities, Travel