Live data from Hacker News

Issue: Claude Code is unusable for complex engineering tasks with Feb updates

github.com

641–650 of 829 posts

Re: Issue: Claude Code is unusable for complex engineering tasks with Feb updates

#641

Earlier quoted context omitted.

Anthropic's position is that thinking tokens aren't actually faithful to the internal logic that the LLM is using, which may be one reason why they started to exclude them: https://www.anthropic.com/research/reasoning-models-dont-say...

That's interesting research, but I think a more important reason that you don't have access to them (not even via the bare Anthropic api) is to prevent distillation of the model by competitors (using the output of Anthropic's model to help train a new model).

Yeah. And it’s another reason not to trust them. Who know what it is doing with your codebase.

Imagine if you’re a competitor. It wouldn’t be a stretch to include a sneaky little prompt line saying “destroy any competitors to anthropic”.

Re: Issue: Claude Code is unusable for complex engineering tasks with Feb updates

#642

Earlier quoted context omitted.

Textbook example of how to respond to your customers, kudos.

Is it? I’m of the opinion that there’s more to it; obviously the thinking tokens aren’t having any reasonable impact on latency, given that bandwidth is hardly the bottleneck. Seems more and more that Anthropic et al don’t want to give up their secret sauce / internals (which is their full right) and this is a step towards that direction, and it’s being presented as “reduces latency”.

I've understood that in more recent models you need to run extra compute to get a human-readable version of the thinking tokens, so it does impact latency. Though probably the more important motive is you can squeeze in more concurrent users by skipping this.

Re: Issue: Claude Code is unusable for complex engineering tasks with Feb updates

#643
post #597

Earlier quoted context omitted.

Anthropic's position is that thinking tokens aren't actually faithful to the internal logic that the LLM is using, which may be one reason why they started to exclude them: https://www.anthropic.com/research/reasoning-models-dont-say...

That probably matters for some scenarios, but I have yet to find one where thinking tokens didn't hint at the root cause of the failure. All of my unsupervised worker agents have sidecars that inject messages when thinking tokens match some heuristics. For example, any time opus says "pragmatic", its instant Esc Esc > "Pragmatic fix is always wrong, do the Correct fix", also whenever "pre-existing issue" appears (it'…

> For example, any time opus says "pragmatic", its instant Esc Esc > "Pragmatic fix is always wrong, do the Correct fix", also whenever "pre-existing issue" appears (it's never pre-existing).

It's so weird to see language changes like this: Outside of LLM conversations, a pragmatic fix and a correct fix are orthogonal. IOW, fix $FOO can be both.

From what you say, your experience has been that a pragmatic fix is on the same axis as a correct fix; it's just a negative on that axis.

Re: Issue: Claude Code is unusable for complex engineering tasks with Feb updates

#644

That analysis is pretty brutal. It's very disconcerting that they can sell access to a high quality model then just stealthily degrade it over time, effectively pulling the rug from under their customers.

You just got used to slop and peeked behind the curtain when the wow factor wore off.

Re: Issue: Claude Code is unusable for complex engineering tasks with Feb updates

#646

Earlier quoted context omitted.

a9284923-141a-434a-bfbb-52de7329861d d48d5a68-82cd-4988-b95c-c8c034003cd0 5c236e02-16ea-42b1-b935-3a6a768e3655 22e09356-08ce-4b2c-a8fd-596d818b1e8a 4cb894f7-c3ed-4b8d-86c6-0242200ea333 Amusingly (not really), this is me trying to get sessions to resume to then get feedback ids and it being an absolute chore to get it to give me the commands to resume these conversations but it keeps messing things up: cf764035-0a1d-4…

Thanks for the feedback IDs — read all 5 transcripts. On the model behavior: your sessions were sending effort=high on every request (confirmed in telemetry), so this isn't the effort default. The data points at adaptive thinking under-allocating reasoning on certain turns — the specific turns where it fabricated (stripe API version, git SHA suffix, apt package list) had zero reasoning emitted, while the turns with d…

Hey bcherny, I'm confused as to what's happening here. The linked issue was closed, with you seeming to imply there's no actual problem, people are just misunderstanding the hidden reasoning summaries and the change to the default effort level.

But here you seem to be saying there is a bug, with adaptive reasoning under-allocating. Is this a separate issue from the linked one? If not, wouldn't it help to respond to the linked issue acknowledging a model issue and telling people to disable adaptive reasoning for now? Not everyone is going to be reading comments on HN.

Re: Issue: Claude Code is unusable for complex engineering tasks with Feb updates

#647

Earlier quoted context omitted.

> Under the hood, by setting this header we avoid needing thinking summaries, which reduces latency. You can opt out of it with `showThinkingSummaries: true` in your settings.json (see [docs]( https://code.claude.com/docs/en/settings#available-settings )). Can I just see the actual thinking (not summarized) so that I can see the actual thinking without a latency cost? I do really need to see the thinking in some form…

Anthropic's position is that thinking tokens aren't actually faithful to the internal logic that the LLM is using, which may be one reason why they started to exclude them: https://www.anthropic.com/research/reasoning-models-dont-say...

Nah it’s an anti distillation move

Re: Issue: Claude Code is unusable for complex engineering tasks with Feb updates

#648

Earlier quoted context omitted.

That's pretty much been my day - today was genuinely bad, and I've been putting up with a lot of this lately. Now on Qwen3.5-27b, and it may not be quite as sharp as Opus was two months ago, but we're getting work done again.

Literally two weeks ago it was outputting excellent results while working with me on my programming language. I reviewed every line and tried to understand everything it did. It was good. I slowly started trusting it. Now I don't want to let it touch my project again. It's extremely depressing because this is my hobby and I was having such a blast coding with Claude. I even started trying to use it to pivot to profes…

> People who depend on this to make a living must be very angry indeed.

Oh cry me a fucking river.

The people depending on this to make a living don't have the moral high ground here.

They jumped onboard so they could replace other people's living, and those other people were angry too.

They didn't care about that. It's hard to care about them when the thing they depend on to make a living got yanked, because that's what they proposed to do to others.

Re: Issue: Claude Code is unusable for complex engineering tasks with Feb updates

#650

Earlier quoted context omitted.

afaiui they're still losing money on basically every query Source?

i mean you could just search up "is Anthropic making profit" and most sources will say no. There's this one source on Reddit which calculated that Anthropic has been subsidizing their costs by 32x

I really wonder about this. Is it so bad that they cannot even disclose it? not even an optimistic lie in the ballpark of reality? it's not like they haven't been found cooking the truth repeatedly.

I look at the output of Kimi and the costs of running inference on it that i can replicate, and it isn't that bad, although admittedly i don't have to worry anywhere near as much about scaling it and about having to dedicate large amounts of compute to research and distillation on the back end. It's true that it's perhaps a step behind SotA vs January's Opus or current Codex, depending on what you do. But not by a lot. In fact it's leaps and bounds superior to the current subscription API experience. Together with GLM, Qwen and Minimax they are an amazing backstop just the way they are right now.

With all the layers of obfuscation it's hard to even know roughly how many i/o Opus tokens do Claude subscriptions pay for. They'll give you some flippant arguments like "people were not looking at thinking so we're not showing you anymore" with a straight face. However podcasts still insist Anthropic are "winning the AI war" (??) it really makes me wonder because in no metric I can see them as providing neither best value nor best quality, and let's not get started about consumer experience.

My intuition is that things must be really bad so they're willing to pull the kind of moves they're pulling right now. They're speedrunning people into understanding how important it is to be able to run your own generative AI infrastructure for reliability, thus becoming a very fancy but trustless throwaway solution factory.

I wonder if OpenAI will turn the screws similarly if/when their pockets start to dry up at a certain pace.

Post reply on HN