is no one using LLMs to help them read/understand code? reading code is definitely a skill that needs to be acquired, but LLMs can definitely help. we should be pushing that instead of “vibe coding”
Comprehension debt: A ticking time bomb of LLM-generated code
241–250 of 352 posts
Re: Comprehension debt: A ticking time bomb of LLM-generated code
#242This was a pre-existing problem, even if reliance on LLMs is making it worse. Naur ( https://gwern.net/doc/cs/algorithm/1985-naur.pdf ) called it "theory building": > The death of a program happens when the programmer team possessing its theory is dissolved. A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modi…
LLMs can be used to vibe-code with limited or superficial understanding, but they can also be extremely helpful parsing and explaining code for a programmer who wants to understand what the program is doing. Well-managed forward thinking organizations will take advantage of the latter approach. The overwhelming majority of organizations will slide into the former without realizing it.
In the medium to longer term, we might be in a situation where only the most powerful next-generation AI models are able to make sense of giant vibe-coded balls of spaghetti and mud we're about to saddle ourselves with.
Re: Comprehension debt: A ticking time bomb of LLM-generated code
#243Shouldn't you be getting the LLM to also generate test cases to drive the code and also enforce coding standards on the LLM to generate small easily comprehensible software modułes with high quality inline documentation. Is this something people are doing?
The people who are doing that aren't writing these blog posts. They're writing much better code & faster, while quietly internally panicking a bit about the future.
You're probably talking about infamous Dark Matter Developers [1]. When the term was coined, I thought there were many of them, now seeing how many developers are here at HN (including myself) I doubt there are many left /s.
The quote that is interesting in the context of the fast-pacing LLM development is this
> The Dark Matter Developer will never read this blog post because they are getting work done using tech from ten years ago and that's totally OK
[1] https://www.hanselman.com/blog/dark-matter-developers-the-un...
Re: Comprehension debt: A ticking time bomb of LLM-generated code
#244This was a pre-existing problem, even if reliance on LLMs is making it worse. Naur ( https://gwern.net/doc/cs/algorithm/1985-naur.pdf ) called it "theory building": > The death of a program happens when the programmer team possessing its theory is dissolved. A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modi…
Funny enough I find LLMs useful for fixing the "death of a program" issue. I was consulting on a project built offshore where all the knowledge / context was gone, and it basically allowed me to have an AI version of the previous team that I could ask questions of.
I could ask questions about how things were done, have it theorize about why, etc.
Obviously it's not perfect, but that's fine, humans aren't perfect either.
Re: Comprehension debt: A ticking time bomb of LLM-generated code
#245Was 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.
Re: Comprehension debt: A ticking time bomb of LLM-generated code
#246Re: Comprehension debt: A ticking time bomb of LLM-generated code
#247Earlier quoted context omitted.
> The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered. Yeah but we can ask an LLM to read the code and write documentation, if that happens.
It's insane to me how you people are so confident in the LLMs abilities. Have you not tried them? They fuck things up all the time. Basic things. You can't trust them to do anything right. But sure let's just have it generate docs, that's gonna work great.
There's a skill to phrasing the prompt so the code comes out more reliable.
Was some thread on here the other day, where someone said they routinely give Claude many paragraphs specifying what the code should and shouldn't do. Take 20 minutes just to type it up.
Re: Comprehension debt: A ticking time bomb of LLM-generated code
#248One side of the equation is definitely that we'll get more 'bad' code.
But nearly every engineer I've ever spoken to has over-indexed on 'tech debt bad'. Tech debt is a lot like normal debt - you can have a lot of it and still be a healthy business.
The other side of the equation is that it's easier to understand and make changes to code with LLMs. I've been able to create "Business Value" (tm) in other people's legacy code bases in languages I don't know by making CRUD apps do things differently from how they currently do things.
Before, I'd needed to have hired a developer who specialises in that language and paid them to get up to speed on the code base.
So I agree with the article that the concerns are valid, but overall I'm optimistic that it's going to balance out in the long run - we'll have more code, throw away more code, and edit code faster, and a lot of that will cancel.
Re: Comprehension debt: A ticking time bomb of LLM-generated code
#249When speed and quantity are incentivized over understanding and quality, this is what we get. Enshittification of not only the product, but our own professional minds.
Re: Comprehension debt: A ticking time bomb of LLM-generated code
#250Most programmers don't understand the low level assembly or machine code. High level language becomes the layer where human comprehension and collaboration happens. LLM is pushing that layer towards natural language and spec-driven development. The only *big* difference is that high level programming languages are still deterministic but natural language is not. I'm guessing we've reached an irreducible point where t…
There is another big difference: natural languages have ambiguity baked in. If a programming language has any ambiguity in how it can be parsed, that is rightly considered a major bug. But it's almost a feature of natural languages, allowing poetry, innuendo, and other nuanced forms of communication.
C has a lot of ambiguity in how it is parsed ("undefined behavior") but people usually view that as a benefit because it allows compilers more freedom to dictate an implementation.