Live data from Hacker News

Claude Sonnet 4.5

anthropic.com

551–560 of 819 posts

Re: Claude Sonnet 4.5

#551
post #542

It is time to acknowledge that AI coding does not actually work. ok, you think it's a promising field and you want to explore it, fine. Go for it. Just stop pretending that what these models are currently doing is good enough to replace programmers. I use LLMs a lot, even for explaining documentation. I used to use them for writing _some_ code, but I have never ever gotten a code sample over 10 lines that was not in…

every attempt I've attempted thus far has failed at first run, but it was close to a solution that could be adapted and fixed. This has been especially helpful in areas where I'm charting very unfamiliar territory for very narrow scoped problems.

But hearing your 10 line constraint gives me a very https://en.wikipedia.org/wiki/Infinite_monkey_theorem vibe to the challenge.

Re: Claude Sonnet 4.5

#552

Earlier quoted context omitted.

That minutiae was always borderline irrelevant, the skill was always making somebody money, possibly with software. The reality is that more software will be pushed than before, and more of it will need to be overseen by a professional.

The real question is what kind of pay that work will demand. It's will be great to still be employed as a senior dev. It will be a little less great with a $110k salary, 5 day commute, and mediocre benefits being the norm.

In most countries, even for highly skilled workers, this is the norm (i.e. most countries outside of the US). I know some very good engineers (e.g. dealing with large revenues (1bil plus) owning core systems) on this kind of money. Not everyone gets the lucky break.

At least for many on this forum you got a chance to earn good money while the sun was shining. AI threatens even the people that didn't.

Re: Claude Sonnet 4.5

#553
post #537

When I see how much the latest models are capable of it makes me feel depressed. As well as potentially ruining my career in the next few years, its turning all the minutiae and specifics of writing clean code, that I've worked hard to learn over the past years, into irrelivent details. All the specifics I thought were so important are just implementation details of the prompt. Maybe I've got a fairly backwards view…

If anything is depressing, it's the amount of people who think these models actually "can code". Because they can't. Also, Clean Code is a really bad ideology, you should regret wasting time on it regardless of LLM code generation.

You just called yourself out- I don't think most people are aware of a "Clean Code" handbook. I had to google it.

When most people think of "clean code", they are not thinking about whatever got you so worked up.

Re: Claude Sonnet 4.5

#554

Anecdotal evidence. I have a fairly large web application with ~200k LoC. Gave the same prompt to Sonnet 4.5 (Claude Code) and GPT-5-Codex (Codex CLI). "implement a fuzzy search for conversations and reports either when selecting "Go to Conversation" or "Go to Report" and typing the title or when the user types in the title in the main input field, and none of the standard elements match, a search starts with a 2s de…

I'm not trying to be offensive here, feel the need to indicate that. But that prompt leads me to believe that you're going to get rather 'random' results due to leaving SO much room for interpretation. Also, in my experience, punctuation is important - particularly for pacing and grouping of logical 'parts' of a task and your prompt reads like a run on sentence. Making a lot of assumptions here - but I bet if I were…

> but these types of prompts and approaches are why I believe so many people think these models aren't useful.

100% agree. The prompt is a 'yolo prompt'. For that task you need to give it points in what to do so it can deduce it's task list, provide files or folders in context with @, tell it how to test the outcome so it knows it has succeeded and closing the feedback loop, and guide it in implementation either via memory or via context with which existing libs or methods it should call on.

For greenfield tasks and projects I even provide architectural structure, interfaces, etc.

After reading twitter, reddit and hn complaints about models and coding tools I've come to the same conclusion as you.

Re: Claude Sonnet 4.5

#555
post #537

When I see how much the latest models are capable of it makes me feel depressed. As well as potentially ruining my career in the next few years, its turning all the minutiae and specifics of writing clean code, that I've worked hard to learn over the past years, into irrelivent details. All the specifics I thought were so important are just implementation details of the prompt. Maybe I've got a fairly backwards view…

If anything is depressing, it's the amount of people who think these models actually "can code". Because they can't. Also, Clean Code is a really bad ideology, you should regret wasting time on it regardless of LLM code generation.

Optimization hinders evolution. - Alan Perlis

Write that garbage code as long as it works. PMF doesn't give a shit about your code quality.

Re: Claude Sonnet 4.5

#556

When I see how much the latest models are capable of it makes me feel depressed. As well as potentially ruining my career in the next few years, its turning all the minutiae and specifics of writing clean code, that I've worked hard to learn over the past years, into irrelivent details. All the specifics I thought were so important are just implementation details of the prompt. Maybe I've got a fairly backwards view…

characterize it in terms of truth, clarity of truth, simplicity, and correctness. I think we should always evaluate things along those dimensions. Is it true, does it produce truthful things. It makes the evaluation very objective.

Re: Claude Sonnet 4.5

#557

I used to treat writing code as a form of art, with attention to details and best practices, and using design patterns whenever possible. but it seems this will come to an end eventually as these agents become more stronger and capable each day, and will be better and faster than human coders.

I'm sympathetic, but it occcured to me that ccording to my amatuer studies, Germany lost WW2 in part because it had a craftsman mentality to manufacture war machines and ended up with a bazillion different part requirments and a shortage of skilled craftsmen, while America used Henry Ford's assembly line process to stamp out hundreds of thousands of identical machines sharing the same parts.

Now we are at the assembly line stage of software production with AI. Us craftsmen will have to find other ways to enjoy our crafts.

Re: Claude Sonnet 4.5

#558

Earlier quoted context omitted.

It... literally is? Or otherwise, can you share what you think the ratio is?

No, 1 is 1 more than 0. There’s a certain sense in which you could say that 1 is infinitely greater than 0, but only in an abstract, unquantifiable way. In this case, it doesn’t make sense to say you’re “infinitely more productive” because you’re producing something rather than nothing.

Only if you think that the phrase "two times more productive" is also nonsensical.

Re: Claude Sonnet 4.5

#559
post #40

Earlier quoted context omitted.

The Anthropic models have been vibe-coding tuned. They're beasts at simple python/ts programs, but they definitely fall apart with scientific/difficult code and large codebases. I don't expect that to change with the new Sonnet.

In my experience Gemini 2.5 Pro is the star when it comes to complex codebases. Give it a single xml from repomix and make sure to use the one at the aistudio.

I think a lot of it has to do with the super long context that it has. For extended sessions and/or large codebases that can fill up surprisingly quickly.

That said, one thing I do dislike about Gemini is how fond it is of second guessing the user. This usually manifests in doing small unrelated "cleaner code" changes as part of a larger task, but I've seen cases where the model literally had something like "the user very clearly told me to do X, but there's no way that's right - they must have meant Y instead and probably just mistakenly said X; I'll do Y now".

One specific area where this happens a lot is, ironically, when you use Gemini to code an app that uses Gemini APIs. For Python, at least, they have the legacy google-generativeai API, and the new google-genai API, which have fairly significant differences between them even though the core functionality is the same. The problem is that Gemini knows the former much better than the latter, and when confronted with such a codebase, will often try to use the old API (even if you pre-write the imports and some examples!). Which then of course breaks the type checker, so then Gemini sees this and 90% of the time goes, "oh, it must be failing because the user made an error in that import - I know it's supposed to be "generativeai" not "genai" so let me correct that.

Re: Claude Sonnet 4.5

#560

Earlier quoted context omitted.

That (thankfully) can't compound, so would never be more than a one time offset. E.g. if you report a score of 60% SWE-bench verified for new model A, dumb A down to score 50%, and report a 20% improvement over A with new model B then it's pretty obvious when your last two model blogposts say 60%. The only way around this is to never report on the same benchmark versions twice, which they include too many to realisti…

The benchmarks are not typically ongoing, we do not often see comparisons between week 1 and week 8. Sprinkle a bit of training on the benchmarks in and you can ensure higher scores for the next model. A perfect scam loop to keep the people happy until they wise up.

> The benchmarks are not typically ongoing, we do not often see comparisons between week 1 and week 8

You don't need to compare "A (Week 1)" to "A (Week 8)" to be able to show "B (Week 1)" is genuinely x% better than "A (Week 1)".

Post reply on HN