It's incredibly easy for new engineers to pick up. On the spectrum between "features easy for beginners but nightmarish for experienced engineers" and "features complex for beginners but great for experienced engineers" it always makes the tradeoff for the former.
Go is awesome and has great ecosystem. I think if you want to just deliver Go is one of the best language out there. Of course as long as the project makes sense(I.e no client side/GUI stuff, there it gets messy)
It can do everything, it's a nightmare to write correctly and is so full of warts that really only a mother could love it.
Go is "elegant" and properly designed, which leads to fundamental unassailable limitations; like its GUI story or writing a backend for other languages (cgo is so slow and -build-mode=c-shared is a hog).
No operator overloading makes it difficult for numerical/scientific work - Python is stronger here.
"just get stuff done" is your crappy dump truck which is welded together out of spare bits and is barely hanging on, this is how I feel about C++.
Go is a lot more elegant and well designed, but it requires "smooth roads" (An OS and Runtime) and goes fast... it's more like a Dodge Hellcat..
EDIT: if we consider speed a function of development time rather than runtime, of course at runtime C++ can be as fast as it gets.
The dump truck that is C++ definitely goes just as fast if not faster than that Hellcat, though.
To me it seems more like C++ is the metal shop's old school 3-axis mill: effective and dangerous. Can do almost anything, including easily maim you unless you're continually vigilant.
Go seems like a CNC machine: just as effective, much less dangerous because it relies on digital safeguards and embedded controllers. You need to go to extreme lengths to make it do something it wasn't designed to do.
Python seems like lego. Shit simple to build things with, lets you start building immediately, fantastic for prototypes, but finished product is still just press-fit plastic bricks
It's no wonder then that Google used to be all in on Python in the 2000s as a language for juniors and then invented another language with similar users in mind. With AI becoming what it is they probably did not need to do the latter.
Python owes a lot to that initialish Google push where for a few years you couldn't get a job at google without knowing python or you could easily get a job if you knew python. Maybe both.
How are ads "stealing dollars" from you lol? It's entirely within Disney's rights to put ads on their streaming service. Maybe you don't like ads, but that's pretty far from them stealing money from you.
Ok, so the plan is to stop z.ai, DeepSeek, and all other non-American labs from developing models entirely, full stop? How do you plan to enact this large scale system of international coordination? Asking politely?
Everything is low-effort writing if your judgement is ideologically charged. Just read the damn post, it's very good, there's nothing low effort, but you need to read it as one single piece, not dissect it looking for hints of LLMisms, killing the article in the process.
Also if you think LLMisms so bad it's spam, you also don't get a free pass. From the guidelines:
If a story is spam or off-topic, flag it. Don't feed egregious comments by replying; flag them instead. If you flag, please don't also comment that you did.
Who said I was "ideologically charged"? I like AI and I use it every day. I simultaneously hate AI writing. It is impossible to parse. If you can read it fine, good on you, but you seem to fundamentally misunderstand that other people perceive the world differently than you do. No one is "dissecting" this article under a microscope, it's obvious.
Understanding isn't a prerequisite for following the community guidelines. Everyone here is guilty of this, me included to be feeding this pointless discussion, and it's a bit disappointing from the mods not to terminate this thread. Either that or kill the main post. Keeping both up is contradictory.
As I already stated, it's only against your personal interpretation of the rules -- an interpretation that has curiously few other subscribers. Saying "the community guidelines mean what I want them to mean, now stop talking" is not a way to argue your point.
Care to say why my interpretation is wrong other than lack of subscription, because from where I'm standing, I'm the only one weaving any form of logical interpretation while your argument is basically "what a loser"
This isn't even a problem: the author is just confused why Anthropic didn't bake all of Claude Code documentation into the harness, but of course it makes no sense to pollute context like that.
> Agents suck at communicating plans
True, communication could be better.
> Agents take any excuse to stop working
Just use /loop.
> Agents are only useful when they take unnecessary risks
Just use a sandbox. OK, technically, this one isn't literally solved by Anthropic/OpenAI, but it is solved by a million agent sandbox startups.
Just using subagents was a pretty useful gain. My only issue is sometimes I forgot to tell the agent to use them. Probably need a hook or skill to do it so I don't need to remember.
I’ve been using "you’re an orchestrator and we’ll work on xxx" in new sessions so that Claude launches sub agents instead of doing things by itself. It’s been working fine for me so far
I think you mean "sandbox" like what is in the Codex TUI. Parent poster meant a VM or container (or bubblewrap/firejail) that doesn't let the agent to edit files outside of specific paths or run dangerous commands, so you can turn the whole confirmation off.
what other sandbox do you need besides running a harness in a container with the right folder mounted and some due diligence like -nonewprivileges? are we talking host network sandboxes here? I think he's just referring to a rogue agent running rm -fdr --no-preserve-root, and that's safe in a container.
Ask your favorite LLM what a malicious script dropped into the right place in your .git directory can do to you the next time you run git outside of the sandbox.
And of course, if the agent has access to the network (which is probably required in order to talk to the AI server), then you have to think about what other things on your local network it could get into.
I see. We are picturing a malicious LLM here that Im basically trusting. But zero trust is a thing.
Those can still be handled by system tooling, setattr in the .git dir that prevents executable permission, container binded to a network on a VLAN that is in DMZ.
I could even whip out selinux policies that would let me know if the LLM tried to drop an executable where it's not allowed.
I was suggesting to ask that question in a separate context, just as a means to understand the potential risks involved. I wouldn't ask this within a coding agent context.
Lately I've been asking a lot of these sorts of questions while setting up a sandboxed environment for my agents (generally, claude and pi). I was quite surprised to learn how many different ways there are to configure git run a script out of the .git directory. And the various AIs know all about this.
At this point my agents get read-only access to my .git directories.
When i used subagents with codex, it made tasks take literally 10x longer with a worse result.... seems unncessary.
The big thing that no one talks about will and always be having an agent help refine requirements with you and understand real world users... thats what real devs know and do - its the difference between slop and good.
Isn't this the exact opposite? When people were saying that saying, the connotation was that IBM was an old, stodgy company that had been around forever. (These days I often think "No one got fired for choosing AWS"). Typesafe is a hot new startup that could, to my eyes, easily burst into flame or die in the next year.
My gut is that the market for "ai as a tool" aka Claude Code/Codex/computer use/etc is a significantly bigger one than "models behind the scenes of some service". I've seen people use evals a lot in the latter case and very little in the former case (outside of people's whose job is basically to review the new releases). I haven't personally met anyone with something like "here are a bunch of tickets + a snapshot repo checkout, please try to solve them all" eval approach.
Though honestly I'm also surprised by the hype around Jev from a POV of "wait, are so many people just building on these by using them for classification tasks vs something more multi-step or generative?"
Agree. Switching models with a keypress is for developer coding.
Jev and this decisions api are mostly useful for inference at scale in a workload where cost and latency matter… and that’s where evals become crucial. Could coding tools use it? Sure, but that’s probably a special case.
For every production use case I build a eval suite which I use for prompt tuning and model evaluation and config. How else do you establish your model and prompt combination works? How do you upgrade to a newer model or decide on a fallback?
This same suite can simply be run very handoff to switch to a new prod model.
"Nerf"ing models isn't real in the vast majority of reported cases. Benchmarks like this or the 100 other "let's see if nerfing is real" copies would have shown it by now if it was.
I made a graphic to explain why people feel like the models get nerfed:
The idea is that new models can handle up to a certain level of complexity, at which point they fall apart. Every new model can handle more complexity, so there's a wonderful time upon release when you feel like you can do anything, only for you to hit the complexity ceiling a few days later when you saturate it. Rinse and repeat for the next model.
Anthropic has admitted to nerfing in the past. There have also been inference bugs. On top of that, model performance changes as they move compute to schwaggier providers as well.
does it really matter wherever its the harness or the model for the vibe coder user claude code?
fwiw, i think almost all regressions are down to a/b testing in the harness by anthropic, but it is objectively indistinguishable beyond "the coding agent ceases to be usable" and i'm back to traditional coding for a few hours until its back to normal again
Yes. The agent allows you to switch models, so you could sidestep a bug in one model by temporarily using other models.
The /r/antigravity SubReddit is full of users who very much notice bugs with the tool/agent. We should be thankful that Claude Code is pretty stable by comparison.
It absolutely matters because something like Claude Code has no guarantee that there won't be changes between updates but a model pinned at the API version level that is getting enterprise traffic absolutely does have that guarantee and would be a much more widespread problem...
I’m typing from my phone and im not going to review the semantics of Anthropic’s storied history of performance issues.
It’s not just ant. There are so many small knobs that providers can claim isn’t nerfing but “load management” or “improving user experience”. One example from OpenAI is reducing juice to reduce time to first token.
Two postmortems, neither quite "admitted to nerfing":
Sept 2025, infra bugs: "A small percentage of Claude Sonnet 4 requests experienced degraded output quality" [0], alongside "We never reduce model quality due to demand, time of day, or server load." [1]
April 2026, Claude Code: default reasoning effort was lowered from high to medium, plus a caching bug and a verbosity prompt. Per Anthropic, "The models themselves didn't regress, and the Claude API was not affected." [2]
So users were right that quality dropped, but the confirmed causes were bugs and a product default, not deliberate model degradation.
Sorry, you are correct - I modified my original post. I get frustrated every time there's a model release and 1 week later everyone is saying NERF! NERF! 99.9% of the time these people are wrong, but you are right that it's technically not 100% due to a few edge cases.
I am more skeptical about the compute provider claim - do you have any evidence of that?
I've seen that looping and glitching behaviour in over-quantized (~Q4 or lower) local models like Llama and Qwen 3.x. Thus, it is likely that they quantize the model after release to save on compute costs (while giving a favourable result at launch). That quantization can result in changes to the model's behaviour (you are changing the weights) that could be interpreted as nerfing.
Nerf is real, i think we initially get full precision models and later quants. My own logs show it clearly for opus 4.5 to 5, consistently a few months post launch, models start making quant based mistakes, like slipping in inappropriate tokens (e.g. chinese ones in english text) which doesnt happen at all in the first few months and regularly later. Additionally frontier problems previously done well start being done poorly, until later model variants where performance mostly holds, likely due to them training on your data reguardless of what boxes you tick.
My local models don't display that degradation, sensed or measured. They consistently perform equally to what I expect of them, precisely because they don't change.
How does twitter explain that? Is my internal model for expectation of capacity magically not drifting for local models but somehow is for anthropic api call based models?
Off topic for sure, but why do people insist on using X/Twitter in this day and age?
The majority of people are not on it, and the links are gated by a ton of toxic dark patterns and horrible UX trying to force people to sign up or log in.
I try to click on the image to enlarge and make the text readable, and I'm greeted with a login screen instead of a larger image.
There is an absolutely massive tech community on Twitter and its by far the place to get real time updates on tech news (yes - better than HN). It isn't all a far right cess pit and that is easy to avoid by just using the following tab
If you click through to [1] that seems like a clear downwards trend (beyond the usual noise) about two weeks before the release of Opus 4.7, Opus 4.8, and Opus 5.5. Opus 5 is the only launch that looks clean without the previous model being nerfed beforehand
Sure, maybe it isn't the model getting nerved but the harness getting updates that make it better with the new model but substantially worse with the old (at that point still current) model.
The test doesn't differentiate. But neither can the average user, who will also be using the normal auto-updating harness. You still get degrading quality right before each new release
Yes, but then the model wasn't nerfed, the harness/overall product just had a plain old regression.
This is very different from a nefarious inference-side degradation to save cost, promote the new model or anything else frequently proposed as motivation.
That's a good observation, though I'd say here that two things could be true at the same time. But, I do personally believe that most of the reported nerfing is the case of your chart + latent evidence-less complaining. Honeymoon phases are real.
You can't just dismiss something backed by careful measurements by throwing a truism at it. What is this honeymoon phase? Can you quantify it? If not, how are you sure it's real?
Where are these careful measurements? Are you 100% sure they don't change the harness between runs and have a large enough sample size to be statistically significant?
I'm not sure I'm arguing what you think I'm arguing. I'm not arguing against measurements. I'm saying that it's relevant to recall that honeymoon phases exist in the general human behavior, whether it applies here or not.
I have not been doing increasingly complex things since Opus 4.6 when models got really good.
My work at my job has stayed the same. But the model quality has varied.
They definitely tune the models in production after launch, if not only to share load during high traffic times. It’s not a crazy conspiracy that the same model can be stupider at different times.
> I have not been doing increasingly complex things since Opus 4.6 when models got really good.
This is a more a statement on the work you do and how you work versus the models. I'm doing more complex work since Fable (and now for way cheaper thanks to Opus 5.5)
With 4.6 I would still babysit a lot more code quality and so on. With the newer model I see myself talking about features at a higher level, and then not having to nitpick PRs to death. Which means most of my time is now spent talking to the model about the product instead of the implementation of the product.
What sorts of things, if you can say? Is it a similar sized/complexity codebase? Most projects do become larger and/or more complex over time. And most people's standards do creep up as they learn.
It's not about doing more complex things - complexity is more dictated by how large your codebase is, etc.
> It’s not a crazy conspiracy that the same model can be stupider
Sorry, I really do think it's a conspiracy. If nerfing were real, it would be trivial to prove. DeepSWE, SWEBench, and other benchmarks are all available for anyone to run. A "nerfing" hypothesis has to survive the fact that a statistically significant dip in benchmarks has never been observed.
Nerfing is certainly real and I don't see how you could argue it isn't.
A/B testing alone would result in a performance nerf for one group.
8-bit quantized models will barely show degradation on benchmarks. The performance is reliably at 99% of the non-quantized model. 4-bit quantization retains somewhere around 95-98% performance on benchmarks. But if you've ever used a 4-bit model, it feels lobotomized.
And just consider what a compny serving these models would do if they were at capacity. Would they stop serving the model altogether? Of course they wouldn't...
Denying that models experience purposeful degradation is gaslighting.
It's probably -only- for subscriptions. The frontier labs seem to use the subscription models on a dial to serve and prioritize the API users better, because they get more profit there.
Admittedly, I didn't click your link, however, based on what you've stated, there is some inaccuracy. All these big companies take your requests and the context, and route it based on the content, cost, etc.
What Anthropic presents as Opus 5.5 isn't actually a single model...it's Anthropic's ecosystem as a whole. If you are lucky, you get the top model handling your issues all the time, however, that never happens. What really happens is that your request and content are graded along with your subscription (example: API? subscription, if so, what tier? how much has the user used it? Do we trust the user? how much? how much are they paying? are they asking something we think is dangerous?) and your request and context are routed accordingly.
Anthropic isn't alone in this behavior, Open AI does it as well, just look at the respective subreddits on reddit for both if you need some examples, or just play around with the various models from both companies.
There are a few folks who've done some analysis on this (their findings were posted on reddit and X), and a bigger multi-national study is apparently coming, though I admittedly don't know their findings.
I guess the tl;dr is that Anthropic and Open AI are actually selling you "best-effort" routers, so you may or may not get the best in class model, and only they get to determine if you do or do not. No guarantees.
That’s right, and it’s been like this ever since we stopped programming in assembly language. Programmers’ brains used to grow manly and strong on a strict diet of manual memory management and custom stack frame handling. Once we transitioned to soft, weak modern languages like C it’s been all downhill.
if that's the theory people won't keep using 4.6. Personally I've felt the nerf for 4.8, when 5.0 is (near) launching. And my theory of a model being nerfed several days / weeks after launching has to do with the number of users. At launch there won't be too many users so the computing power per user is huge. As time goes, users and agent has been adjusted to newer model, the computing power per person gets reduced
It's very much real but not necessarily malicious. We track upstream providers pretty closely. Sometimes it's a just matter of a single GPU runtime layer bug/update to break inference outputs. The model weights don't necessarily change/get quantized.
I suspect they play with their quants and perform weight sensitive tensor/parameter tuning among other things to get serving faster and some of the time for some workloads it surfaces. I feel this has a high probability of being correct and an explanation for some of this.
I refuse to believe they "play with their quants" once a model version is labelled and shipped. What does that even mean; could you explain it please? These models aren't just used through claude/codex, they are used through API access and it's quite expensive. Previous regressions were related to harness regression, and platform issues. Not some Nerf conspiracy 99% of the vibe bros believe in.
Note: I know what quantization is so don't hold back.
I would guess that if they do use such methods, it'd be to handle peak loads that go beyond their compute capacity, while they run the models at full capability when there's excess capacity
like before Anthropic signed the Colossus deal, the usage limits were insane and everyone was complaining, I wouldn't be surprised if they'd rather try to make inference faster that way than try to just limit people, at least for those on subscriptions
Trimming parameter size that can be reduced while surviving regression evals. They have so much data they know exactly where to shave the models. Most people will never see it in their work loads. It won’t affect core benches because that is part of the regression evaluation.
During peak hours requests queue and inference slows. During off-peak they can move systems over to training.
Where is the evidence they are "nerfing" the models due to request volume?
Edit: I don't know they do, I mean they could repurpose systems if they are idle. Inference demand is global, and providers like Azure have global routing options that are cheaper. Night time in the USA could be serving inference demand on the other side of the globe.
It's all just conjecture, your hypothesis about moving systems equally so.
But you seem adamant that there's no chance the providers serve slightly quantized models for subscription users during high loads, or otherwise tweak models for requests from those users.
It's tricky to prove either way, but the chance is not zero.
reply