Live data from Hacker News

Can LLMs write better code if you keep asking them to “write better code”?

minimaxir.com

51–60 of 461 posts

Re: Can LLMs write better code if you keep asking them to “write better code”?

#51
post #5

Something major missing from the LLM toolkit at the moment is that it can't actually run (and e.g. test or benchmark) its own code. Without that, the LLM is flying blind. I guess there are big security risks involved in making this happen. I wonder if anyone has figured out what kind of sandbox could safely be handed to a LLM.

I don't think that's always true. Gemini seemed to run at least some programs, which I believe because if you asked it to write a python program that would take forever, it does. For example the prompt "Write a python script that prints 'Hello, World', then prints a billion random characters" used to just timeout on Gemini.

Re: Can LLMs write better code if you keep asking them to “write better code”?

#52

Earlier quoted context omitted.

It'd be great if it could describe the performance of code in detail, but for now just adding a skill to detect if a bit of code has any infinite loops would be a quick and easy hack to be going on with.

Is reliably detecting if code has any infinite loops feasible? Sounds like the halting problem.

It depends how you define reliably.

The halting problem isn't so relevant in most development, and nothing stops you having a classifier that says "yes", "no" or "maybe". You can identify code that definitely finishes, and you can identify code that definitely doesn't. You can also identify some risky code that probably might. Under condition X, it would go into an infinite loop - even if you're not sure if condition X can be met.

Re: Can LLMs write better code if you keep asking them to “write better code”?

#53
post #5

Something major missing from the LLM toolkit at the moment is that it can't actually run (and e.g. test or benchmark) its own code. Without that, the LLM is flying blind. I guess there are big security risks involved in making this happen. I wonder if anyone has figured out what kind of sandbox could safely be handed to a LLM.

The new Cursor agent is able to check the linter output for warnings and errors, and will continue to iterate (for a reasonable number of steps) until it has cleared them up. It's not quite executing, but it does improve output quality. It can even back itself out of a corner by restoring a previous checkpoint. It works remarkably well with typed Python, but struggles miserably with Rust despite having better error r…

> It seems like with Rust it's not quite aware of which patterns to use, especially when the actual changes required may span multiple files due to the way memory management is structured.

What do you mean? Memory management is not related to files in Rust (or most languages).

Re: Can LLMs write better code if you keep asking them to “write better code”?

#55
I often run into LLMs writing "beginner code" that uses the most fundamental findings in really impractical ways. Trained on too many tutorials I assume.

Usually, specifying the packages to use and asking for something less convoluted works really well. Problem is, how would you know if you have never learned to code without an LLM?

Re: Can LLMs write better code if you keep asking them to “write better code”?

#58

Using the tool in this way is a bit like mining: repeatedly hacking away with a blunt instrument (simple prompt) looking for diamonds (100x speedup out of nowhere). Probably a lot of work will be done in this semi-skilled brute-force sort of way.

There must be a feedback request mechanism for a "Is this better?" This is doable with RLHF or DPO.

Re: Can LLMs write better code if you keep asking them to “write better code”?

#60
post #43

Earlier quoted context omitted.

This method requires a lot less skill, you just need to read it and run it. Reading is much easier than writing!

For many types of code writing it is much easier than reading it unfortunately.

Reading to understand all the subtext and side-effects can be harder than writing, sure. But it won't stop people trying this approach and hammering out code full of those types of subtle bugs.

Human developers will be more focused on this type of system integration and diagnostics work. There will be more focus on reading and understanding than the actual writing. It's a bit like working with contractors.

Post reply on HN