You can use an LLM and demonstrably understand the code it produces.

marcus_cemes 10 hours ago | parent | next [-]

I find myself often trying to understand the madness of some of the code an LLM produces. Does that count? You're absolutely right! I made a mistake, and I'm sorry.. Then I end up questioning myself if it wouldn't have been easier to just do it myself. To be fair though, it's not limited to LLMs, I've felt that way other people's code too.

Jokes aside, there's a difference to understanding the code and understanding the reasoning that is behind the code, I feel that LLMs still struggle enormously with the later. They start writing, and sometimes realise halfway through that they can't backtrack and just keep writing rubbish. You can argue about spinning loops and iterative processes, as long as they are actually able to converge.

	▲	TZubiri 21 minutes ago \| parent [-]
		I noticed something about LLM code generation and this is as good as place to post the finding as any. It's fairly obvious, but as we know LLMs choose the highest probability next token, so when generating code, it does so from left to right, without ever reorganizing, which unless it uses a harness, that's not how WE write code, that's property 1. Property 2 is that it will write out as many boilerplate that occurs before the actual implementation as it can, because boilerplate is always the same, and implementation is high temperature/chaotic, there's many different ways an implementation can go. For example in python, you can write your code directly, or wrap it in a main loop and later add a main guard. LLMs will always write the main loop, since it's not competing with NOT writing a main loop, it's competing with the best option in the set of non-main loop solutions. This is trivial in this case because all non main solutions are present in the main loop solution set, but for solutions where the two sets are distinct, the LLM will have a bias towards solutions that share initial tokens, e.g: Solution 1: import lib1 and use function A 30% Solution 2: import lib1 and use function B 25% Solution 3: import lib2 and use function A 45% Despite solution 3 being weighted more heavily, the LLM will opt for solution 1, since solution 2 makes it choose the import lib1 token. This pushes towards mega-libraries instead of composable Unix libraries. Stuff like numpy, react or helper libraries get a boost since they are more like megaframeworks than specific libraries, and they get their import statements boosted.

▲

wannabe44 2 hours ago | parent | prev | next [-]

And forget it after the "demonstration".

▲

Supermancho 9 hours ago | parent | prev [-]

> You can use an LLM and demonstrably understand the code it produces.

Obviously.

Chatgpt: Write a bubble sort in java.

Now ask questions about what you don't understand.

The problem is comparing trivial examples to complex multi-agent hands-off workflows. Scale until you are at the edge of your comfort zone.

Pretending that all LLM codes is dangerous because you cant understand a solution to a problem you offloaded to a black box, is disingenuous.