3 ms·

I bet some people felt the same way when we collectively moved from assembly to compilers.

gyosko 1y ago
Yeah, if not only for the small fact that you are leaving a well defined set of rules for pure chaos and randomness this time around.
- foolserrandboy 1y ago
  Yeah, I don't understand this comparison. I've programmed for years in higher level languages professionally and never learned assembly and never got stuck because the higher level language was limited or doing something wrong. Whenever I use an LLM I always need to review its output because usually there is something not quite right. For context I'm using VS copilot, mostly ask and agent mode, in a large brownfield project.
- utyop22 1y ago
  Exactly that's the trade-off. People keep comparing higher-level programming languages to lower-level abstractions - these comparisons are absolutely false. The whole point of higher-level programming languages is for people to get away from working with the lower level stuff. But with the way software engineers are interacting with LLMs, they are not getting away from writing code because they have to use what comes out of it to achieve their goal (writing and piecing together code to complete a project).
- david-gpu 1y ago
  My career sat at the interface of hardware and software. We would often run into situations where the code produced by the compiler was not what we desired. This issue was particularly pronounced when we were transitioning some components from being written in assembly by hand vs using a compiler. I think the parallels are clear for those of us who have been through this scenario.
- PretzelPirate 1y ago
  In reality, the outcome doesn't appear to be the result of "pure chaos and randomness" if you ground your tools. Test cases and instructions do a fantastic job of keeping them focused and moving down the right path. If I see an LLM consistently producing something I don't like, I'll either add the correct behavior to the prompt, or create a tool that will tell it if it messed up or not, and prompt it to call the tool after each major change.
ModernMech 1y ago
To some degree you're correct -- LLMs can be viewed as the kind of "sufficiently advanced" compiler we've always dreamed of. Our dreams didn't include the compiler lying to us though, so we have not achieved utopia. LLMs are more like DNA transcription, where some percentage of the time it just injects a random mutation into the transcript, either causing am evolutionary advantage, or a terminal disease. This whole AI industry right now is trying to figure out how to always get the good mutation, and I don't think it's something that can be controlled that way. It will probably turn out that on a long enough timescale, left unattended, LLMs are guaranteed to give your codebase cancer.
jplusequalt 1y ago
In the previous scenario, programmers were still writing the code themselves. The compilers, if they were any good, generated deterministic code. In our current scenario, programmers are merely describing what they think the code should do, and another program takes their description and then stochastically generates code based on it.
- david-gpu 1y ago
  Compilers are (a) typically non-deterministic and, (b) produce different code from one version to the next, from one brand to the next, and from one set of flags to the next.

Yeah, if not only for the small fact that you are leaving a well defined set of rules for pure chaos and randomness this time around.

foolserrandboy 1y ago
Yeah, I don't understand this comparison. I've programmed for years in higher level languages professionally and never learned assembly and never got stuck because the higher level language was limited or doing something wrong. Whenever I use an LLM I always need to review its output because usually there is something not quite right. For context I'm using VS copilot, mostly ask and agent mode, in a large brownfield project.
utyop22 1y ago
Exactly that's the trade-off. People keep comparing higher-level programming languages to lower-level abstractions - these comparisons are absolutely false. The whole point of higher-level programming languages is for people to get away from working with the lower level stuff. But with the way software engineers are interacting with LLMs, they are not getting away from writing code because they have to use what comes out of it to achieve their goal (writing and piecing together code to complete a project).
david-gpu 1y ago
My career sat at the interface of hardware and software. We would often run into situations where the code produced by the compiler was not what we desired. This issue was particularly pronounced when we were transitioning some components from being written in assembly by hand vs using a compiler. I think the parallels are clear for those of us who have been through this scenario.
PretzelPirate 1y ago
In reality, the outcome doesn't appear to be the result of "pure chaos and randomness" if you ground your tools. Test cases and instructions do a fantastic job of keeping them focused and moving down the right path. If I see an LLM consistently producing something I don't like, I'll either add the correct behavior to the prompt, or create a tool that will tell it if it messed up or not, and prompt it to call the tool after each major change.

ModernMech 1y ago

To some degree you're correct -- LLMs can be viewed as the kind of "sufficiently advanced" compiler we've always dreamed of. Our dreams didn't include the compiler lying to us though, so we have not achieved utopia. LLMs are more like DNA transcription, where some percentage of the time it just injects a random mutation into the transcript, either causing am evolutionary advantage, or a terminal disease. This whole AI industry right now is trying to figure out how to always get the good mutation, and I don't think it's something that can be controlled that way. It will probably turn out that on a long enough timescale, left unattended, LLMs are guaranteed to give your codebase cancer.

jplusequalt 1y ago

In the previous scenario, programmers were still writing the code themselves. The compilers, if they were any good, generated deterministic code. In our current scenario, programmers are merely describing what they think the code should do, and another program takes their description and then stochastically generates code based on it.

david-gpu 1y ago
Compilers are (a) typically non-deterministic and, (b) produce different code from one version to the next, from one brand to the next, and from one set of flags to the next.