@danjones000@microwords.goodevilgenius.org

Post #1470158

2026-01-07 05:11 UTC

This is a pretty bad take. We trust compilers not just because they work well, but because we can actually trust them to always do what their told to do. Compilers are deterministic. Given the same code, a compiler will produce the same machine code on the same machine 100% of the time, without fail. LLMs are not designed to do that, and never will be. If they were, they'd just be compilers, but that has never been a design goal of LLMs. There will never be a point in time where you can just trust the code output by an LLM the way you can a compiler, because they are non-deterministic. @t3rcermillenium@mastodon.social @Chip_Unicorn@im-in.space

Replies (2)

@t3rcermillenium@mastodon.social 2026-01-07 06:12

@danjones000 @Chip_Unicorn I understand these points. But do LLMs really need to be deterministic and generate the same code every time? As long as the output satisfies some defined criteria and passes a set of tests, does it matter what the generated code looks like? In all likelihood, subsequent debugging, maintenance and new feature addition will also be done by an LLM. Does the code even need to be human readable? I’m starting to think not.

Open ##1470159
@urwumpe@hessen.social 2026-01-07 10:30

@danjones000 @t3rcermillenium @Chip_Unicorn I still wonder why hours of prompt engineering is suddenly considered better than learning which tiny keyword, annotation, trait or precompiler definition is needed to produce the exact behaviour with a compiler that your specs demand. 🤣 Its like the old "Java is too slow" argument... well, if you just write C code with Java, it takes the word slow to new dimensions. If you write Java code while knowing how the JVM behaves, its pretty fast.

Open ##1470163