Live data from Hacker News

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

github.com

161–170 of 829 posts

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

#161

Running some quick analysis against my .claude jsonl files, comparing the last 7 days against the prior 21: - expletives per message: 2.1x - messages with expletives: 2.2x - expletives per word: 4.4x(!) - messages >50% ALL CAPS: 2.5x Either the model has degraded, or my patience has.

> expletives per word

Huh?

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

#162

Earlier quoted context omitted.

Disconcerting for sure, but from a business point of view you can understand where they're at; afaiui they're still losing money on basically every query and simultaneously under huge pressure to show that they can (a) deliver this product sustainably at (b) a price point that will be affordable to basically everyone (eg, similar market penetration to smartphones). The constraints of (b) limit them from raising the p…

They'll never get anyone on board if the product can't be trusted to not suck. And idk about the pricing thing. Right now I waste multiple dollars on a 40 minute response that is useless. Why would I ever use this product?

Yeah. I've been enjoying programming with Claude so much I started feeling the need to upgrade to Max. Then it turns out even big companies paying API premiums are getting an intentionally degraded and inferior model. I don't want to pay for Opus if I can't trust what it says.

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

#163

Not claude code specific, but I've been noticing this on Opus 4.6 models through Copilot and others as well. Whenever the phrase "simplest fix" appears, it's time to pull the emergency break. This has gotten much, much worse over the past few weeks. It will produce completely useless code, knowingly (because up to that phrase the reasoning was correct) breaking things. Today another thing started happening which are…

Certain phrases invoke an over-response trying to course correct which makes it worse because it's inclined to double down on the wrong path it's already on.

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

#165
Same experience. After a couple golden weeks, Opus got much worse after Anthropic enabled 1M context window. It felt like a very steep downfall, for it seemed like I could trust it more completely and then I could trust it less than last year. Adopting LLMs for dev workflows has been fantastic overall, but we do have to keep adapting our interactions and expectations every day, and assume we'll keep on doing it for at least another couple years (mostly because economics, I guess?)

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

#169
post #53

Earlier quoted context omitted.

> effectively pulling the rug from under their customers. This is the whole point of AI. Its a black box that they can completely control.

I hope local models advance to the point they can match Opus one day...

Considering the advances in software and hardware, I would expect that in 2 or 3 years.

And I hope we will eventually reach a point where models become "good enough" for certain tasks, and we won't have to replace them every 6 months.

(That would be similar to the evolution of other technologies like personal computers and smartphones.)

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

#170
I appreciate the work done here.

Been having this feeling that things have got worse recently but didn't think it could be model related.

The most frustrating aspect recently (I have learned and accepted that Claude produces bad code and probably always did, mea culpa) is the non-compliance. Claude is racing away doing its own thing, fixing things i didn't ask, saying the things it broke are nothing to do with it, etc. Quite unpleasant to work with.

The stuff about token consumption is also interesting. Minimax/Composer have this habit of extensive thinking and it is said to be their strength but it seems like that comes at a price of huge output token consumption. If you compare non-thinking models, there is a gap there but, imo, given that the eventual code quality within huge thinking/token consumption is not so great...it doesn't feel a huge gap.

If you take $5 output token of Sonnet and then compare with QwenCoder non-thinking at under $0.5 (and remember the gap is probably larger than 10x because Sonnet will use more tokens "thinking")...is the gap in code quality that large? Imo, not really.

Have been a subscriber since December 2024 but looking elsewhere now. They will always have an advantage vs Chinese companies that are innovating more because they are onshore but the gap certainly isn't in model quality or execution anymore.

Post reply on HN