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

Coding with LLMs in the summer of 2025 – an update

antirez.com

Post reply on HN
Print view View original

401–410 of 434 posts

Re: Coding with LLMs in the summer of 2025 – an update

#401

Post by krupan »

Herring wrote: post #237
cesarb wrote: post #210

Earlier quoted context omitted.

> Code and math are similar to chess/go, where verification is (reasonably) easy Verification for code would be a formal proof, and these are hard; with a few exceptions like seL4, most code does not have any formal proof. Games like chess and go are much easier to verify. Math is in the middle; it also needs formal proofs, but most of math is doing these formal proofs themselves, and even then there are still unprov…

Verification for code is just running it. Maybe "verification" was the wrong word. The model just needs a sense of code X leads to outcome Y for a large number of (high-quality) XY pairs, to learn how to navigate the space better, same as with games.

"just running it" is an enormously absurd simplification

Re: Coding with LLMs in the summer of 2025 – an update

#402

Post by RugnirViking »

generic92034 wrote: post #226
cheeze wrote: post #211

Earlier quoted context omitted.

I love Framework but it's still not enough IMO. My time is the most valuable thing, and a subscription to $paid_llm_of_choice is _cheap_ relative to my time spent working. In my experience, something Llama 3.3 works really well for smaller tasks. For "I'm lazy and want to provide minimal prompting for you to build a tool similar to what is in this software package already", paid LLMs are king. If anything, I think th…

> and a subscription to $paid_llm_of_choice is _cheap_ relative to my time spent working. In the mid to long term the question is, is the subscription covering the costs of the LLM provider. Current costs might not be stable for long.

That is, in every sense of the term, their problem.

I will switch to whatever is best for me at a good price, and if thats not sustainable then I'll be fine too; I was a developer before these existed at all, and local models only help from there.

Re: Coding with LLMs in the summer of 2025 – an update

#404

Post by Herring »

krupan wrote: post #401
Herring wrote: post #237

Earlier quoted context omitted.

Verification for code is just running it. Maybe "verification" was the wrong word. The model just needs a sense of code X leads to outcome Y for a large number of (high-quality) XY pairs, to learn how to navigate the space better, same as with games.

"just running it" is an enormously absurd simplification

If you can do better please go ahead?

Re: Coding with LLMs in the summer of 2025 – an update

#405

Post by oblio »

Der_Einzige wrote: post #342
oblio wrote: post #251

Earlier quoted context omitted.

Honesty doesn't look like this: > [...] get lost [...] > [..] We don't want you to be a part of it either. [...] He's being rude. Honesty would be, something like: > I (and probably many others) like programming a lot. Even if you're frustrated with it, I think a great deal of people will be sad if somehow programming disappeared completely. It might be best for you if you just found a job that you love more, instead…

Rudeness is a good rhetorical choice to make a point. Only stupid idiots would think differently.

Almost any form of speech/writing is a rhetorical choice.

Rudeness being considered a > rhetorical choice reflects poorly on its source's rhetorical prowess.

Re: Coding with LLMs in the summer of 2025 – an update

#406

Post by oblio »

pxeger1 wrote: post #336
oblio wrote: post #335

Earlier quoted context omitted.

One second, don't LLMs generally run in VRAM? If you put them in regular RAM, don't they have to go through the CPU which kills performance?

The mentioned CPU uses unified memory for its built in GPU / NPU. I.e. some portion of what could ordinarily be system RAM is given to the GPU instead of the CPU

Ah, now I see, didn't know that was feasible in the PC world. Glad that it's becoming an option.

Re: Coding with LLMs in the summer of 2025 – an update

#407

Post by keeda »

gf000 wrote: post #298
keeda wrote: post #283

Earlier quoted context omitted.

> After all the effort getting to the point where the generated code is acceptable, one has to wonder, why not just write it yourself? Because it is still way, way, way faster and easier. You're absolutely right that the hard part is figuring out the solution. But the time spent typing is in no way trivial or cognitively simple, especially for more complex tasks. A single prompt can easily generate 5 - 10x the amount…

> frequently accounts for edge cases I hadn't considered, saving unquantifiable amounts of future debugging time; And creates new ones you wouldn't even consider before, creating just as much, if not more future debugging :D

That's what the code review is for :-) But to echo the sibling comments, I've not caught a subtle edge case or bug in the generated code in more than a year and half. There are mistakes and failure modes for sure, but they are very glaring, to the extent that I simply throw that code away and try again.

That said, I've adopted a specific way of working with AI that is very effective for my situation (mentioned in my comment history, but echoes a lot of what TFA advises.)

Re: Coding with LLMs in the summer of 2025 – an update

#408

Post by zer00eyz »

Aurornis wrote: post #288
zer00eyz wrote: post #202

Earlier quoted context omitted.

> Once it becomes economical to run a Claude 4 class model locally you'll see a lot more people doing that. Historically these sorts of things happened because of Moores law. Moores law is dead. For a while we have scaled on the back of "more cores", and process shrink. It looks like we hit the wall again. We seem to be near the limit of scaling (physics) we're not seeing a lot in clock (some but not enough), and IPC…

> We seem to be near the limit of scaling (physics) we're not seeing a lot in clock (some but not enough), and IPC is flat. We are also having power (density) and cooling (air wont cut it any more) issues. This is exaggeration. CPUs are still getting faster. IPC is increasing, not flat. Cooling on air is fine unless you’re going for high density or low noise. This is just cynicism. Even an M4 MacBook Pro is substanti…

> IPC is increasing, not flat.

Benchmarks going up is not IPC increasing. These are separate things.

Please look IPC for the latest GPU's from Nvidia, the latest CPU's from AMD. The IPC is flat. See intel loosing credibility with failing processors due to power problems from clocking because IPC is flat.

> Even an M4 MacBook Pro is substantially faster than an M1

Again, clocking. m4 (non pro) vs m1 are so close in IPC on common tasks that its negligible. The performance gains between the two are from memory bandwidth not core performance.

> Server chips are scaling core counts

Parallelism is not the same as performance. Intel dropping the "core duo" 20 year ago was that RUNNING at 2ghz was an admission that single threading was ending. 20 years on were 20 cores deep (consumer), and only at 4ghz with "boost clocks" (back to that pesky power and cooling problem).

And this product still exists today: the N150 (close enough). Its has lower power consumption and more cores. And what was the single core performance gain? 35% Improvement in 20 years.

None of these things are running any of the LLM's that power the tools were talking about. Those are in the datacenter. 700 core CPU's, 400-800gbps top of rack switching are the bleeding edge. This is where "power" and cooling have hit the wall. The spacing requirements of a bleeding edge NVIDIA install are impacting the costs of interconnect between systems. Lots of fiber and needing to be spaced out because of power/heat adds up to a boat load of extra networking costs. Having half empty racks because of density is now a reality.

And you see these same issues at home: power demands of GPU's for consumers and workstations are thought he roof. Were past what the PCI spec can provide, all that power is heat and has to go somewhere. Sometimes it burns up poorly designed connectors. The latest gen is consumes even more power, to push clocks higher, for very little gain (see flat IPC nvida).

Re: Coding with LLMs in the summer of 2025 – an update

#409

Post by sn9 »

Herring wrote: post #404
krupan wrote: post #401

Earlier quoted context omitted.

"just running it" is an enormously absurd simplification

If you can do better please go ahead?

There's an entire field of formal verification that LLMs can take advantage of.

You can incorporate proofs with Coq or Dafny or use model checkers or TLA+ to actually verify your code.

This will be required for any software where correctness matters.

Re: Coding with LLMs in the summer of 2025 – an update

#410

Post by viraptor »

hhh wrote: post #365
viraptor wrote: post #267

Earlier quoted context omitted.

Any provider can run Kimi (including yourself if you would get enough use out of it), but only one can run Claude.

Two can run Claude, AWS and Anthropic. Claude rollout on AWS is pretty good, but they do some weird stuff in estimating your quota usage thru your max_tokens parameter. I trust AWS, but we also pay big bucks to them and have a reason to trust them.

In a way... But it's still just because Anthropic lets them. Things can change at any point.
Post reply on HN