- in about 5 yrs of time, this is not going to age well
- massive studies ll come out on how 50% of the software engineers dont know or understand what they "generated" at all and how their critical thinking skills have taken a nosedive
- every major software company out there that is busy firing juniors now is going to run into the opposite problem: finding talented juniors and they ll command a hefty pay
- the whole LLM premise runs on one little assumption that they ll improve indefinitely. you are forgetting the law of diminishing returns
- i ll come back here in 5 yrs, this whole thing wont end well
I wonder if people said the same when compilers first appeared in the software development scene.
> the whole LLM premise runs on one little assumption that they ll improve indefinitely. you are forgetting the law of diminishing returns
To be honest, I think I'd remain happy if they just stayed at the level they are now, maybe bit faster and cheaper (and ideally more energy efficient), best would be to run it locally too, but I don't really need them to get "better" to make good use of them at this point.
The difference is you can trust the compiler without knowing what System.out.println("Hello, World!") is going to ultimately look like, and the vast majority of what compilers output will never need human intervention to fix something or human oversight to ensure correctness and fitness for purpose.
>” To be honest, I think I'd remain happy if they just stayed at the level they are now, maybe bit faster and cheaper (and ideally more energy efficient), best would be to run it locally too, but I don't really need them to get "better" to make good use of them at this point.”
I have bad news … you’re gonna be mad… they’re gonna make it expensive otherwise they can’t get the hockey stick ROI.
> I think I'd remain happy if they just stayed at the level they are now, maybe bit faster and cheaper
Definitely ! It's so useful as is, even without spitting a single line of code, as an analysis and documentation tool, it's already great. Now a faster and/or cheaper version: perfect. Make it runnable on commodity hardware: icing on the cake.
Not since the advent of the compiler have most developers understood what is being generated. Their efforts have instead gone into validation (often manual, but sometimes automated) to see that what was generated works as expected as that is all that really matters to the business goals.
Which is still where the effort is going, although there does seem to be more interest in automated validation now, which is welcome progress.
This is certainly overstating the difference between compiled code and the source code. If I write an if/else statement, I understand what the computer is going to do when it's evaluated even if I don't know or see the literal machine code.
Only if the compiler is perfectly naive. With the state of today's optimizing compilers, the output might be very different from what you'd expect. But it also doesn't matter because the business goal is the results from executing the program, not the static code. Hence why, as the earlier commenter pointed out, efforts go into validation rather than understanding the generated code. 99% of the time the code a compiler spits out simply doesn't matter. The same is now proving true as we move up a level of abstraction. The code spit out from an LLM doesn't matter any more than the code spit out from a compiler, only validation that it functions as expected matters.
- massive studies ll come out on how 50% of the software engineers dont know or understand what they "generated" at all and how their critical thinking skills have taken a nosedive
- every major software company out there that is busy firing juniors now is going to run into the opposite problem: finding talented juniors and they ll command a hefty pay
- the whole LLM premise runs on one little assumption that they ll improve indefinitely. you are forgetting the law of diminishing returns
- i ll come back here in 5 yrs, this whole thing wont end well