[kenjackson]

Ask most folks about the code generated by the compiler or interpreter and you’ll get blank stares. Even game devs now barely know assembly, much less efficient assembly.

There is still a place for someone who is going to rewrite your inner-loops with hand-tuned assembly, but most coding is about delivering on functional requirement. And using tools to do this, AI or not, tend to be the prudent path in many if not most cases.

[jamesmccann]

I don't think these are comparable though. Compiler generation is deterministic and more or less provably correct. LLM code is a mile away from that.

[skydhash]

Apart from the whole argument about compilers being deterministic and not LLMS.

You don't collaborate on compiled code. They are artifacts. But you're collaborating on source code, so whatever you write, someone else (or you in the future) will need to understand it and alter it. That's what the whole maintainability, testability,... is about. And that's why code is a liability, because it takes times for someone else to understand it. So the less you write, the better it is (there's some tradeoffs about complexity).

[kenjackson]

You can make LLMs deterministic, but that's not a priority right now. In the same way we used to not capture dev environments and end up in situations where you couldn't rebuild a binary exactly because the OS version, the compiler version, the CRT version, etc... all changed -- of course that's a 20 year old problem now, but was a legitimate problem as recently as 2000.

And again, we're at a point in time where we do collaborate on the source code artifacts. But maybe we won't in the future. It assumes that we see AI progress, I can see a world where asking questions of the AI about the code is better than 99% of developers. There will be the John Carmack's of the world though who know better than the AI, but the common case is that we eventually move away from looking at code directly. But this does rely on continued progress that we may not get.