Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I cancelled Claude: Token issues, declining quality, and poor support

nickyreinert.de

Post reply on HN
Print view View original

411–420 of 604 posts

Re: I cancelled Claude: Token issues, declining quality, and poor support

#411

Post by varispeed »

wg0 wrote: post #202

I write detailed specs. Multifile with example code. In markdown. Then hand over to Claude Sonnet. With hard requirements listed, I found out that the generated code missed requirements, had duplicate code or even unnecessary code wrangling data (mapping objects into new objects of narrower types when won't be needed) along with tests that fake and work around to pass. So turns out that I'm not writing code but I'm r…

You can quickly get something "working" until you realise it has a ton of subtle bugs that make it unusable in the long run.

You then spend months cleaning it up.

Could just have written it by hand from scratch in the same amount of time.

But the benefit is not having to type code.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#413

Post by estimator7292 »

ChicagoDave wrote: post #296

I think there’s a clear split amongst GenAI developers. One group is consistently trying to play whack-a-mole with different models/tools and prompt engineering and has shown a sine-wave of success. The other group, seemingly made up of architects and Domain-Driven Design adherents has had a straight-line of high productivity and generating clean code, regardless of model and tooling. I have consistently advised all…

IME it seems that output quality is directly proportional to the amount of engineering effort you put in. If a bug happens and you just tell the model to fix it over and over with no critical thinking, you end up with an 800 line shell script meant to change the IP address on an interface (real example). If you stop and engage your brain to reason about bugs and explain the problem, the model can fix it in an acceptable manner.

If you want to get good results, you still have to be an engineer about it. The model multiplies the effort you put in. If your effort and input is near zero, you get near zero quality out. If you do the real work and relegate the model to coloring inside the lines, you get excellent results.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#414

Post by Leynos »

skippyboxedhero wrote: post #266
ramoz wrote: post #109

Earlier quoted context omitted.

What provider do you use for Kimi

The provider is a massive issue. People moving off Claude tend to assume this is solved. Claude's uptime is terrible. The uptime of most other providers is even worse...and you get all the quantization, don't know what model you are actually getting, etc.

Kimi 2.5 was like using Sonnet 4 on a flaky ADSL line. I haven't tried K2.6 yet, but the physical unreliability of the connection was too off-putting.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#415

Post by _the_inflator »

janwillemb wrote: post #19

This is what worries me. People become dependent on these GenAI products that are proprietary, not transparant, and need a subscription. People build on it like it is a solid foundation. But all of a sudden the owner just pulls the foundation from under your building.

“In the future there might be the possibility that catastrophic event A could happen.”

Not the best argument.

Also there is nothing without dependencies. Loose coupling means coupling.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#416

Post by 2ndorderthought »

wilbur_whateley wrote: post #2

Claude with Sonnet medium effort just used 100% of my session limit, some extra dollars, thought for 53 minutes, and said: API Error: Claude's response exceeded the 32000 output token maximum. To configure this behavior, set the CLAUDE_CODE_MAX_OUTPUT_TOKENS environment variable.

I hope this doesn't come out wrong but. When this happens do agentic/vibe coders message their boss and say "sorry can't work until tomorrow?"

Re: I cancelled Claude: Token issues, declining quality, and poor support

#418

Post by sarchertech »

hirvi74 wrote: post #401
prmph wrote: post #370

Earlier quoted context omitted.

But, how do you know the code is good? If you do spot checks, that is woefully inadequate. I have lost count of the number of times when, poring over code a SOTA LLM has produced, I notice a lot of subtle but major issues (and many glaring ones as well), issues a cursory look is unlikely to pick up on. And if you are spending more time going over the code, how is that a massive speed improvement like you make it seem…

> But, how do you know the code is good? Honestly, this more of a question about scope of the application and the potential threat vectors. If the GP is creating software that will never leave their machine(s) and is for personal usage only, I'd argue the code quality likely doesn't matter. If it's some enterprise production software that hundreds to millions of users depend on, software that manages sensitive data,…

> I apply the Herbie Hancock philosophy when defining good code. When once asked what is Jazz music, Herbie responded with, "I can't describe it in words, but I know it when I hear it."

That’s the problem. If we had an objective measure of good code, we could just use that instead of code reviews, style guides, and all the other things we do to maintain code quality.

> I truly believe that most competent developers (however one defines competent) would be utterly appalled at the quality of the human-written code on some of the services they frequently use.

Not if you have more than a few years of experience.

But what your point is missing is the reason that software keeps working in the fist, or stays in a good enough state that development doesn’t grind to a halt.

There are people working on those code bases who are constantly at war with the crappy code. At every place I’ve worked over my career, there have been people quietly and not so quietly chipping away at the horrors. My concern is that with AI those people will be overwhelmed.

They can use AI too, but in my experience, the tactical tornadoes get more of a speed boost than the people who care about maintainability.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#419

Post by flyinglizard »

sarchertech wrote: post #406
janalsncm wrote: post #379

Earlier quoted context omitted.

How can a person reconcile this comment with the one at the root of this thread? One person says Claude struggles to even meet the strict requirements of a spec sheet, another says Claude is doing a great job and doesn’t even need specific specs? I have my own anecdata but my comment is more about the dissonance here.

One person is rigorously checking to see if Claude is actually following the spec and one person isn’t?

... or one person has a very strong mental model of what he expects to do, but the LLM has other ideas. FWIW I'm very happy with CC and Opus, but I don't treat it as a subordinate but as a peer; I leave it enough room to express what it thinks is best and guide later as needed. This may not work for all cases.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#420

Post by taytus »

spaceman_2020 wrote: post #402
taytus wrote: post #102

Earlier quoted context omitted.

I'd recommend Kimi k2.6 for your use. It is an excellent model at a fraction of the cost, and you can use Claude Code with it. I did a 1:1 map of all my Claude Code skills, and it feels like I never left Opus. Super happy with the results.

did you just copy-paste or is there a difference in the way kimi uses skills?

I don’t have the prompt at hand but basically I told Kimi (paraphrasing): I have these Claude code skills, and I know it uses different tool calls than you but read them and re-write them as your own tools.

I also created a mini framework so it can test that the skills are actually working after implementation.

Everything runs perfectly.

Post reply on HN