Live data from Hacker News

Comprehension debt: A ticking time bomb of LLM-generated code

codemanship.wordpress.com

261–270 of 352 posts

Re: Comprehension debt: A ticking time bomb of LLM-generated code

#261

Was listening to the Dwarkesh Patel podcast recently and the guest (Agustin Lebron) [0] mentioned the book "A Deepness In The Sky" by Vernor Vinge [1]. I started reading it and a key plot point is that there is a computer system that is thousands of years old. One of the main characters has "cold sleeped" for so long that he's the only one who knows some of the hidden backdoors. That legacy knowledge is then used to…

His description of learning to be a programmer in that far future era was fun too, iirc there was just so much ‘legacy code’, like practically infinite libraries and packages to perform practically any function - that ‘coding’ was mostly a matter of finding the right pieces and wiring them together. Knowing the nuances of these existing pieces and the subtlety of their interpretation was the skill.

100%

Another great example:

In Fire Upon the Deep, due to the delay in communications between star systems, everyone use a descendant of Usenet.

Re: Comprehension debt: A ticking time bomb of LLM-generated code

#262

So many of these concepts only make sense under the assumption that AI will not get better and humans will continue to pour over code by hand. They won't. In a year or two these will be articles that get linked back to similar to "Is the internet just a fad?" articles of the late 90s.

This requires an assumption that LLM capability growth will continue on an exponential curve, when there are already signs that in reality the curve is logistic

Re: Comprehension debt: A ticking time bomb of LLM-generated code

#263
> An effect that’s being more and more widely reported is the increase in time it’s taking developers to modify or fix code that was generated by Large Language Models.

And this is where I stop reading. You cannot make such a descriptive statement without some sort of corroborating evidence other than your intuition/anecdotes.

Re: Comprehension debt: A ticking time bomb of LLM-generated code

#265

Earlier quoted context omitted.

Okay how about this situation that one of my junior devs hit recently: Coding in an obj oriented language in an enormous code base (big tech). Junior dev is making a new class and they start it off with LLM generation. LLM adds in three separate abstract classes to the inheritance structure, for a total of seven inherited classes. Each of these inherited classes ultimately comes with several required classes that are…

> Tell me how you, without knowing the code base, get the LLM to not add these classes? Stop talking to it like a chatbot. Draft, in your editor, the best contract-of-work you can as if you were writing one on behalf of NASA to ensure the lowest bidder makes the minimum viable product without cutting corners. --- Goal: Do X. Sub-goal 1: Do Y. Sub-goal 2: Do Z. Requirements: 1. Solve the problem at hand in a direct ma…

Every time I see something like this, I wonder what kind of programmers actually do this. For the kinds of code that I write (specific to my domain and generates real value), describing "X", "Y", and "Z" is a very non-trivial task.

If doing those is easy, then I would assume that the software isn't that novel in the first place. Maybe get something COTS

I've been coding for 25 years. It is easier for me to describe what I need in code than it is to do so in English. May as well just write it.

Re: Comprehension debt: A ticking time bomb of LLM-generated code

#266

> An effect that’s being more and more widely reported is the increase in time it’s taking developers to modify or fix code that was generated by Large Language Models. And this is where I stop reading. You cannot make such a descriptive statement without some sort of corroborating evidence other than your intuition/anecdotes.

Sounds like a great way to shift our problems from categories that are easy to measure to ones that are hard to measure.

Re: Comprehension debt: A ticking time bomb of LLM-generated code

#267

Earlier quoted context omitted.

Thats why you throw away the prototype.

That's also when you tell your manager: "this is just the happy flow, it isn't production ready". Manager will then ask how long that will take and the answer is that the estimate hasn't changed.

I'm not sure I understand the problem. Just don't publish the prototype.

Re: Comprehension debt: A ticking time bomb of LLM-generated code

#268

Earlier quoted context omitted.

Okay how about this situation that one of my junior devs hit recently: Coding in an obj oriented language in an enormous code base (big tech). Junior dev is making a new class and they start it off with LLM generation. LLM adds in three separate abstract classes to the inheritance structure, for a total of seven inherited classes. Each of these inherited classes ultimately comes with several required classes that are…

> Tell me how you, without knowing the code base, get the LLM to not add these classes? Stop talking to it like a chatbot. Draft, in your editor, the best contract-of-work you can as if you were writing one on behalf of NASA to ensure the lowest bidder makes the minimum viable product without cutting corners. --- Goal: Do X. Sub-goal 1: Do Y. Sub-goal 2: Do Z. Requirements: 1. Solve the problem at hand in a direct ma…

I mean, unless you just don't know how to program, I struggle to see what value the LLM is providing. By the time you've broken it down enough for the LLM, you might as well just write the code yourself.

Re: Comprehension debt: A ticking time bomb of LLM-generated code

#269
post #59

LLMs absolutely produce reams of hard-to-debug code. It's a real problem. But "Teams that care about quality will take the time to review and understand LLM-generated code" is already failing. Sounds nice to say, but you can't review code being generated faster than you can read it. You either become a bottleneck (defeats the point) or you rubber-stamp it (creates the debt). Pick your poison. Everyone's trying to bol…

> You … become a bottleneck (defeats the point) It's better if the bottleneck is just reviewing, instead of both coding and reviewing, right? We've developed plenty of tools for this (linting, fuzzing, testing, etc). I think what's going on is people who are bad at architecting entire projects and quickly reading/analyzing code are having to get much better at that and they're complaining. I personally enjoy that kin…

> It's better if the bottleneck is just reviewing, instead of both coding and reviewing, right?

Not really. There's something very "generic" about LLM generated code that makes you just want gloss over it, no matter how hard you try not to.

Re: Comprehension debt: A ticking time bomb of LLM-generated code

#270
post #20

Earlier quoted context omitted.

> I suspect that there is a strong correlation between programmers who don't think that there needs to be a model/theory, and those who are reporting that LLMs are speeding them up. I have some anecdotal evidence that suggests that we can accomplish far more value-add on software projects when completely away from the computer and any related technology. It's amazing how fast the code goes when you know exactly what…

> It's amazing how fast the code goes when you know exactly what you want. To quote Russ Ackoff[1]: > Improving a system requires knowing what you could do if you could do whatever you wanted to. Because if you don't know what you would do if you could do whatever you wanted to, how on earth are you going to know what you can do under constraints? [1] https://www.youtube.com/watch?v=OqEeIG8aPPk

If you were playing chess and could do whatever you wanted, you could take several goes in a row, take the opponents pieces off the board and move yours into a winning position. How does that help you play better under the constraints of the rules?
Post reply on HN