Being a student myself, I really have no opinion on LLM-use in academia, for studying or creative authorship. I believe we're all still figuring it out and there isn't enough data yet. BUT I think the parallel with programming, and specifically the comparison between compiler-use and LLM-use is just that... parallel (two line that never meet).
It's been said repeatedly and at the risk of sounding like a broken record: the compiler is a deterministic tool and LLMs are not. And they most likely won't ever be deterministic for certain things sometimes so deeply subjective such as programming, where even different humans could come up with varying solutions to the same problem.
BECAUSE the compiler is so painfully deterministic, yu can be hands-off, knowing that some of the smartest people in the world continue to dedicate a dizzying amount of focus and brain-power to making sure that given x, the output is always z (it's obviously more complex but yu get the idea). I'd say that while determining the correctness of a compiler requires specialised knowledge, it is less mentally taxing to trust BECAUSE it is deterministic. And so, theoretically, yu can dig in directly and see that given these combinations of inputs, the compiler always produces that output... Again, whether the output is right or not is specialised knowledge and can usually be mathematically be verified.
This is very different from LLM-assisted programming which is a subjective endeavour that has now separated code-generation from intention where previously the act of actually writing the code embedded the author's intent by virtue of the author having to decide every single character that survives. This is why documentation feels boring because it feels like writing the code twice (depending on your disposition as a programmer anyway).
If I directed a team and they use LLMs, I'd want them to personally carry responsibility for their LLM-generated code to the extent that they've exhaustively verified that the code itself carries their intent, rather than just that the output matches what was expected. This would be an absurd thing to do with a compiler (i.e. verifying the generated assembly code), and I strongly believe that the difference is in the determinism of the generative process. If every generative run is unique, then every generated output must be very carefully verified EACH TIME to the extent which the human begins to naturally feel personally responsible for the code itself not just the final result.
And the idea that
> Software engineers who use LLMs should save a curated prose document describing the software, alongside the code that was generated from it.
is something I completely agree with, but c'mon, let's be honest... that's the same old documentation practice all over again. Amusingly, LLM-assisted coding is now making traditional programming practices even more important to adhere to. Anyway, it's always been easier to read the documentation than the code itself (for me atleast, I'd like to generally understand the general idea before I go eat granite).
I guess I'm disagree-ing with the article where it seems to say 'peeling of the sticker and calling it homemade' is the wrong thing to do with LLM-assisted programming because we don't do that with compilers (i.e. claiming authorship over the generated asm). I think that comparison shifts us dangerously into being purely result-focused, like we are with compilers.. where we only care about the results of the computation and our high-level input, and ignore the outputted ASM except in very special cases.
I posit that the indeterminism of LLM-generated code requires us to care very very deeply about the output of the model. A reliable signal of that care is when a human has painstakingly seen to it that the output aligns with their intention, to the point where they claim direct ownership of not just the results of computation, but the generated code itself. I think we should encourage that instinct especially if yu want to hold a programmer accountable for their failing code and expect them to feel personally responsible for it, rather than pointing back at the model. I believe this is what Indradhanush Gupta may be gesturing at.
Afterall, what is slop? Didn't read the code, only interested in the results of computation.
It's been said repeatedly and at the risk of sounding like a broken record: the compiler is a deterministic tool and LLMs are not. And they most likely won't ever be deterministic for certain things sometimes so deeply subjective such as programming, where even different humans could come up with varying solutions to the same problem.
BECAUSE the compiler is so painfully deterministic, yu can be hands-off, knowing that some of the smartest people in the world continue to dedicate a dizzying amount of focus and brain-power to making sure that given x, the output is always z (it's obviously more complex but yu get the idea). I'd say that while determining the correctness of a compiler requires specialised knowledge, it is less mentally taxing to trust BECAUSE it is deterministic. And so, theoretically, yu can dig in directly and see that given these combinations of inputs, the compiler always produces that output... Again, whether the output is right or not is specialised knowledge and can usually be mathematically be verified.
This is very different from LLM-assisted programming which is a subjective endeavour that has now separated code-generation from intention where previously the act of actually writing the code embedded the author's intent by virtue of the author having to decide every single character that survives. This is why documentation feels boring because it feels like writing the code twice (depending on your disposition as a programmer anyway).
If I directed a team and they use LLMs, I'd want them to personally carry responsibility for their LLM-generated code to the extent that they've exhaustively verified that the code itself carries their intent, rather than just that the output matches what was expected. This would be an absurd thing to do with a compiler (i.e. verifying the generated assembly code), and I strongly believe that the difference is in the determinism of the generative process. If every generative run is unique, then every generated output must be very carefully verified EACH TIME to the extent which the human begins to naturally feel personally responsible for the code itself not just the final result.
And the idea that
> Software engineers who use LLMs should save a curated prose document describing the software, alongside the code that was generated from it.
is something I completely agree with, but c'mon, let's be honest... that's the same old documentation practice all over again. Amusingly, LLM-assisted coding is now making traditional programming practices even more important to adhere to. Anyway, it's always been easier to read the documentation than the code itself (for me atleast, I'd like to generally understand the general idea before I go eat granite).
I guess I'm disagree-ing with the article where it seems to say 'peeling of the sticker and calling it homemade' is the wrong thing to do with LLM-assisted programming because we don't do that with compilers (i.e. claiming authorship over the generated asm). I think that comparison shifts us dangerously into being purely result-focused, like we are with compilers.. where we only care about the results of the computation and our high-level input, and ignore the outputted ASM except in very special cases.
I posit that the indeterminism of LLM-generated code requires us to care very very deeply about the output of the model. A reliable signal of that care is when a human has painstakingly seen to it that the output aligns with their intention, to the point where they claim direct ownership of not just the results of computation, but the generated code itself. I think we should encourage that instinct especially if yu want to hold a programmer accountable for their failing code and expect them to feel personally responsible for it, rather than pointing back at the model. I believe this is what Indradhanush Gupta may be gesturing at.
Afterall, what is slop? Didn't read the code, only interested in the results of computation.