Hacker News Reader

Comment by vivzkestrel | Hacker News Reader

- 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

View on HN

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'd like to see them try to increase prices as long as open source models that are roughly in the same league are available

> 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.

“FORTRAN should virtually eliminate coding and debugging.” — FORTRAN Preliminary Report, 1954.

Relative to punch cards and writing in machine code, I imagine the statement was entirely correct. And still is.

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.

compiler is not putting words together randomly with a mathematical probability but the LLM is

Yes, the difference between a compiler and an LLM is that a compiler's output correctness is binary, whereas an LLM's output correctness is probabilistic.

That may be an interesting distinction in a vacuum, but given that the input to both is words put together randomly with a mathematical probability a compiler's binary correctness isn't actually the useful property that it may first seem. In the real world, to overcome the probabilistic input, you have to validate the input with respect to the output. And it turns out once you have systems in place for that, you gain the same assurances with a probabilistic output as you do with binary output.

So, while there are some technical differences, there is no practical difference.

On your second point... that's the problem... IMO, humans need to read/understand and approve code changes generated by AI. If either through a lack of understanding or skill, they approve changes anyways, that's largely on them an they largely deserve what they get.

Like TFA, I'm a proponent of human gatekeepers in the loop. IMO, the result isn't much better at a team level when you compare dev + ai to a typical team and that level of output... but you get a lot more testing and documentation along the way just through the process refinement and iterations.

I think the harder issue is finding and growing Senior level developers that actually have a material understanding of what is happening and how things are working at a high and low level. The more junior, imo, the more likely someone is to just accept the AI result(s) that introduce more bugs in the process.

Reply on news.ycombinator.com