Live data from Hacker News

Claude Sonnet 5

anthropic.com

631–640 of 822 posts

Re: Claude Sonnet 5

#631
post #617

Earlier quoted context omitted.

> a very steep price that you may not actually account for Could you elaborate on this steep price that you have in mind? What does it consist of?

Technical debt and skill atrophy Technical debt due to accumulated excessively verbose, badly architected, often redundant, feature-bloated code which always looks good, even upon earnest review, but actually sucks and becomes extremely difficult to maintain in ways which are not obvious in code review. The issue is this: your tooling can help, and can make you feel better, and you might think you wrote all the promp…

> ...badly architected, often redundant, feature-bloated code which always looks good, even upon earnest review, but actually sucks and becomes extremely difficult to maintain in ways which are not obvious in code review.

I can only judge from my own experience but with or without LLMs, these are the codebases that I have worked with during most of my career. To me, much of the question is whether LLMs produce worse code than the me and my colleagues have done in the past and I don't think that's the case. It is however very common that people hold LLMs to a higher standard than human colleagues and then it's not a useful comparison.

Re: Claude Sonnet 5

#632
post #620
post #617

Earlier quoted context omitted.

> a very steep price that you may not actually account for Could you elaborate on this steep price that you have in mind? What does it consist of?

The cost is skill atrophy. When was the last time you wrote something entirely from scratch by hand without AI assistance? It’s a skill entirely separate from prompting and reviewing. And it atrophies when you stop using it.

> The cost is skill atrophy

I hear what you're saying but I'm not sure I buy it in the context of this thread (a response to someone who is 54 and has been coding since they were eight).

I am in a similar boat, having been coding full-time for fourty years. The way I use the current tools is that I own all architectural and design decisions but let Claude Code fill in the blanks. I reckon the quality of the output is about 90% of what it would have been had I done everything myself, but I get a lot more done (easily 3-5X).

Will I forget how to write a "for" loop just because I haven't been writing many of them by hand lately? Those skills are so deeply ingrained that I seriously doubt it. I can ride a bike after a multi-year break, or converse in a language I haven't regularly spoken for several decades. Or write using pen & paper even though I hardly ever do it. I don't see why coding would be any different.

Re: Claude Sonnet 5

#633

The cost per task chart is telling me that I should _never_ use Sonnet 5 above medium effort level - Opus always performs better for a given cost. So I guess the takeaway is that if Sonnet 5 medium isn't good enough for you, switch models, not effort levels.

They're actively trying to use lobbying power to make open weight models illegal. So I'm just not going to use their services at all anymore. I don't think they're a net gain if you're a skilled senior, and the hidden cost in terms of technical debt and skill atrophy is just being swept under the rug. I'll be okay without their bullshit generator.

> I don't think they're a net gain if you're a skilled senior

I've had Claude Code running a /loop for the last week driving down complex crashing bugs in a prototype compiler entirely unilaterally. I occasionally glance over.

A few of those crashing test cases were ones I've spent more than a week trying to track down myself. I have 30 years of experience of doing this.

It's worked 24/7.

So far it has fixed over 500 of them.

Will there be technical debt? Yes. But nothing that remotely compares to the cost I'd have incurred of fixing all of those myself.

It is hard to reconcile those gains without thinking that if people are saying these are not a net gain, they haven't really tried learning how to get the full benefit. If you sit and watch a model work and keep intervening all the time, then sure, they're not going to be a net gain.

Re: Claude Sonnet 5

#634
post #607

Earlier quoted context omitted.

The boot must taste so good for you to lick it so ravenously.

It's a shame HN refuses to seriously engage with the topic of AI safety. Either you think model intelligence will continue to improve or you don't. If you think it won't continue to improve, sure, open models are great. If you think it will continue to improve, then we are all fucked if models continue to be open on release.

Fucked how? The models capacity is great for defense too.

Re: Claude Sonnet 5

#635

Earlier quoted context omitted.

> I don't think they're a net gain if you're a skilled senior I'm a skilled senior (I'm 54 and been coding since I was about 8; I've been 100% AI-generated code for at least 6 months now and have produced a combination of speed and quality that has astonished me; my velocity is apparent at https://github.com/pmarreck/ ) and this has been a massive net gain, so your claim is now officially in sheer defiance of reality…

Have you really found claude to much more more capable than eg deepseek? Anthropic has little to no chance of producing a competitive business model in the long term.

The cheap models are cost-competitive if you are running them in long-running agentive tasks.

But they take a lot longer to reach the same goal for complex tasks, so the difference is still very real, and the cost-savings are still very much a question of how well you manage to characterise the tasks they will do quickly and pick and choose what to use when.

I kind of agree that I think the cheap models will eat away at the moat very effectively, but if it doesn't seem more capable to you, you're not giving it complex enough tasks to see what they can do.

(FWIW, I've burned billions of tokens on each of Deepseek, Kimi, GLM5.2, GPT, Sonnet, Opus, Haiku using the same harness, and we've kept stats on cost per task)

Re: Claude Sonnet 5

#636

Earlier quoted context omitted.

I think I might have written a comment similar to yours maybe 6 months or a year ago. I'm not quite sure to respond to these sorts of replies. I have used LLMs/Claude Code quite extensively professionally and was a very early adopter, have built tooling around LLM/agentic development, and genuinely embraced it. They aren't useless, but the short term gains you think you're getting come at a very steep price that you…

I think the uncomfortable debate is not about skill atrophy as a general phenomenon (it’s happening anyway, doesn’t matter how much we debate it) but rather, _which_ skills are atrophying and if these skills are now superfluous/worthless or not. If you don’t use a skill, it’s like a gene a species doesn’t need anymore, it will atrophy. Is that bad and if yes, why? Skill atrophy is not intrinsically bad. I don’t know…

One could argue that the cumulative atrophy of skill around writing CPU assembly has been problematic in some respects, but it’s also completely unreasonable to lament what we’ve gained in return.

As far as I’m concerned, so long as we can be happy with AI we can run locally, AI is no different to the rise of scripting languages or the pocket calculator. It’s only problematic if the calculator is rented to you as a service.

Re: Claude Sonnet 5

#637

Earlier quoted context omitted.

I believe you are miscalculating the effect of skill atrophy, there is benefit and actual experience gained by doing the work yourself. You are an experienced dev and already have a lot of tools and knowledge under your belt so at the moment it is hard to see the actual issue, as this is just a productivity multiplierfor you. But give it a couple of years working under these conditions, your tech savvy nature will be…

In a couple of years he will be 60, too. Then 65, then 70. Seniors will be able to stay in the game much longer than before, mark my words.

Indeed. I think it's a much bigger issue for juniors, who haven't yet had a chance to build that systems design muscle.

When an LLM is making a bad design decision but the engineer doesn't have the experience to spot it AND the consequences don't become apparent until much later (which is often the case) -- it's kinda hard to learn.

Re: Claude Sonnet 5

#638
post #632
post #620

Earlier quoted context omitted.

The cost is skill atrophy. When was the last time you wrote something entirely from scratch by hand without AI assistance? It’s a skill entirely separate from prompting and reviewing. And it atrophies when you stop using it.

> The cost is skill atrophy I hear what you're saying but I'm not sure I buy it in the context of this thread (a response to someone who is 54 and has been coding since they were eight). I am in a similar boat, having been coding full-time for fourty years. The way I use the current tools is that I own all architectural and design decisions but let Claude Code fill in the blanks. I reckon the quality of the output is…

I have a greater concern about societal skill atrophy.

I also am not about to forget how to for(;;), that said, as a result of some years invested in aligning old pre WGS84 mapping with modern GPS and improving digital mapping, there are fewer people per capita with the skills to navigate via paper maps in the absence of GPS.

Old farts coding since age 8 (in which I include myself with a decade+ over a sprightly young 54) will retain coding skills for as long as they apply them - the fear is that fewer and fewer others will develop and exercise such skills due to AI.

It remains to be seen if that's a bad thing long term.

Re: Claude Sonnet 5

#639

Earlier quoted context omitted.

I think the uncomfortable debate is not about skill atrophy as a general phenomenon (it’s happening anyway, doesn’t matter how much we debate it) but rather, _which_ skills are atrophying and if these skills are now superfluous/worthless or not. If you don’t use a skill, it’s like a gene a species doesn’t need anymore, it will atrophy. Is that bad and if yes, why? Skill atrophy is not intrinsically bad. I don’t know…

One could argue that the cumulative atrophy of skill around writing CPU assembly has been problematic in some respects, but it’s also completely unreasonable to lament what we’ve gained in return. As far as I’m concerned, so long as we can be happy with AI we can run locally, AI is no different to the rise of scripting languages or the pocket calculator. It’s only problematic if the calculator is rented to you as a s…

Hence only let your skill atrophy to the extent where if all you had were your local laptop you can still be competent. Relying on paid subscription services for your skill is a fool's errand.

Re: Claude Sonnet 5

#640

Earlier quoted context omitted.

I think I might have written a comment similar to yours maybe 6 months or a year ago. I'm not quite sure to respond to these sorts of replies. I have used LLMs/Claude Code quite extensively professionally and was a very early adopter, have built tooling around LLM/agentic development, and genuinely embraced it. They aren't useless, but the short term gains you think you're getting come at a very steep price that you…

I think the uncomfortable debate is not about skill atrophy as a general phenomenon (it’s happening anyway, doesn’t matter how much we debate it) but rather, _which_ skills are atrophying and if these skills are now superfluous/worthless or not. If you don’t use a skill, it’s like a gene a species doesn’t need anymore, it will atrophy. Is that bad and if yes, why? Skill atrophy is not intrinsically bad. I don’t know…

It’s not one single skill being lost, it’s about many and how they interact.

I just did a big refactor with opus, it went ok, some bugs. The normal stuff. One of the bugs was in a part of the code no longer needed, which Opus had just filled with comments more or less. Asking it fix the bug worked, but then I really looked at the code and realized just that, this is pointless now.

I’ve only been coding for 20+ years so I might be more susceptible than the author, but I’m quite terrified about losing skills in writing code, but also designing good structure, coherency and system overview. These are the things people claim you need more of with LLMs, but is what you outsource the most, even if you think you are describing it in detail.

We are all collectively growing the skill of complacency and laziness though, and those are not great ”skills” to have. And I’m just as guilty as anyone.

Post reply on HN