Live data from Hacker News

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

nickyreinert.de

471–480 of 604 posts

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

#471

Earlier quoted context omitted.

... 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.

If you don’t have a very strong mental model for what you are working on Claude can very easily guide in you into building the wrong thing. For example I’m working on a huge data migration right now. The data has to be migrated correctly. If there are any issues I want to fail fast and loud. Claude hates that philosophy. No matter how many different ways I add my reasons and instructions to stop it to the context, it…

Have you created a plan where the requisite is not to bother you with x and y, and to use some predetermined approach? What you describe sometimes happens to me, but it happens less when its part of the spec.

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

#472

Earlier quoted context omitted.

There's going to be a day when we look back at $200/mo price tags and say "wow that was cheap". The breakeven at this price is 6 minutes of productivity per work day for an engineer making $200k.

Everyone is arguing why I'm wrong or that I should have presented more data. You've got the real insight with this claim. This is the way the world is moving. Open source isn't even going where the ball is being tossed. There is no leadership here. You're spot on. If the cost to deliver a unit of business automation is: A. $1M with human labor B. $700k human labor + open source models C. $500k human labor + $10,000 i…

You are assuming (imagining) a cost relationship which doesn't exist and when researched was the opposite of what you claim.

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

#473
post #318
post #247

Earlier quoted context omitted.

> Stop trying to use it as all-or-nothing. You can still make the decisions, call the shots, write code where AI doesn't help and then use AI to speed up parts where it does help. You're assuming that finding the places where AI needs help isn't already a larger task than just writing it yourself. AI can be helpful in development in very limited scenarios but the main thrust of the comment above yours is that it take…

The problem I have with this take is it's focused on solving the right now problem. Yes, it's quicker to do it yourself this time, but if we build out the artifacts to do a good enough job this time, next time it'll have all the context it needs to take a good shot at it, and if you get overtaken by AI in the meantime you've got an insane head start. Which side of history are you betting on?

If you don't do it yourself and you don't get overtaken by AI, you've lost the head start to be better next time - humans learn, and they atrophy as well.

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

#474
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…

I have the same feeling.

Like there is no way in world that Gen AI is faster then an actual cracked coder shooting the exact bash/sql commands he needs to explore and writing a proper intent-communicating abstraction.

I’m thinking the difference is in order of magnitudes.

On top of that it adds context loss, risk of distraction, the extra work of reading after the job is done + you’ll have less of a mental model no matter how good you read, because active > passive.

Man it was really the weirdest thing that Claude Coded started hiding more and more changes. Thats what you need, staying closely on the loop.

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

#475
post #170

Earlier quoted context omitted.

> Why should anyone waste time on poorer results? Because in almost no real-world project is "programming time" the limiting factor?

No, it's rate at which you can solve problems, and weaker models waste your time because they don't solve problems at the same speed.

No, its the number of debug cycles you need to solve said problems. That's the major attribute that controls dev time. And models require far more than I need. You are paying money to take longer and produce worse code. If its different for you, that's a you problem.

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

#476

One of the biggest problem with Claude is, it tries to do things that I don't even ask. I really like to have full control over what I do. I feel sometimes, Claude has the urgency to keep going with what it is hardcore programmed for instead waiting for my feedback. Looks like, Claude consider everything to be oneshot. I maybe wrong, this is my personal experience

Claude Code has something about picking sensible choices instead of asking questions in the system prompt, that's probably the problem.

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

#477
post #68

Earlier quoted context omitted.

Open Source isn't even within 50% of what the SOTA models are. Benchmarks are toys, real world use is vastly different, and that's where they seriously lag. Why should anyone waste time on poorer results? I'd rather pay my $200/mo because my time matters. I'm not a poor college student anymore, and I need more return on my time. I'm not shitting on open weights here - I want open source to win. I just don't see how t…

> Why should anyone waste time on poorer results? Because in almost no real-world project is "programming time" the limiting factor?

amazing how often is this repeated on here are some sort of a gospel SWEs pass down to one another to continue this charade. I have worked in this industry for 30+ years on countless projects, last decade+ as consultant - at every single project (every single one) programming time was the limiting factor. there is a whole industry inside our industry dealing with “processes” and “how to estimate” (apparently we are incapable of doing that) and whatnot, all because the actual programming time is always a limiting factor and there isn’t an even close 2nd

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

#478
post #262

Earlier quoted context omitted.

Writing detailed specs and then giving them to an AI is not the optimal way to work with AI. That's vibecoding with an extra documentation step. Also, Sonnet is not the model you'd want to use if you want to minimize cleanup. Use the best available model at the time if you want to attempt this, but even those won't vibecode everything perfectly for you. This is the reality of AI, but at least try to use the right mod…

> Writing detailed specs and then giving them to an AI is not the optimal way to work with AI. It is NOT the way to work with humans basically because most software engineers I worked with in my career were incredibly smart and were damn good at identifying edge cases and weird scenarios even when they were not told and the domain wasn't theirs to begin with. You didn't need to write lengthy several page long Jira ti…

> It is NOT the way to work with humans basically because most software engineers I worked with in my career were incredibly smart and were damn good at identifying edge cases and weird scenarios even when they were not told and the domain wasn't theirs to begin with.

I have no clue what AI you're using, but both Claude and Codex, you just explain the outcome, and they are pretty smart figuring out stuff on complex codebases.You don't even need a paragraph, just say "doing this I got an error".

> NO guarantee either because these models are NOT deterministic in their output. Same prompt different output each time.

So, exactly like humans. But a bit more predictable and way more reliable.

> That's why every chat box has that "Regenerate" button.

If you're using the chat box to write code, that's a human error, not an LLM one. Don't blame "AI" for your ignorance.

> no matter how smart and expensive the model is, the underlying working principles are the same as GPT-2.

Sure. Every machine is a smoke machine if operated wrong enough. This tells me you should not get your insight from random YT videos. As a bit of nugget, some of the underlying working principles of the chat system also powered search engines; and their engineers also drank water, like hitler.

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

#479
Very similar experience, although I didn’t use claude for anything in production, but I did try some tests with some few topics and questions on things that I know, and while initially it works very well, but as soon as you dive deeper you get all sort of extra none sense that was never asked to add/do nor it’s useful, just workarounds after workarounds after duct tape solutions, several times I would say “no, why are you introducing xyz, that will cause this and that” to get similar answer of “thanks for pushing back, you are right bla bla”.

We probably hit peak generative AI last year, now they probably use AI to improve the AI so it’s kinda garbage in garbage out, or maybe anthropic is deprioritizing users while favoring enterprise or even government where it provides better quality for higher contracts.

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

#480
post #253

Earlier quoted context omitted.

I must be doing something very different from everyone else, but I write what I want and how I want it and Opus 4.7 plans it for me, then I carefully review. Often times I need to validate and check things, sometimes I’ve revised the plan multiple times. Then implementation which I still use Opus for because I get a warning that my current model holds the cache so Sonnet shouldn’t implement. And honestly, I’m mostly…

>Then implementation which I still use Opus for because I get a warning that my current model holds the cache so Sonnet shouldn’t implement. This is based on the premise that given detailed plan, the model will exactly produce the same thing because the model is deterministic in nature which is NOT the case. These models are NOT deterministic no matter how detailed plan you feed it in. If you doubt, give the model sa…

One of the simple "reasons" is to keep context clean; if you're doing planning, you're not loading source code, its just the plan. Also, it may happen that if you're running parallel manual sessions, cache expires after 1h, so a prompt on an idle session will re-trigger re-evaluating the whole context (something quite heavy on a 1M context window). This burns a lot of credit.
Post reply on HN