Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

codemanship.wordpress.com

Post reply on HN
Print view View original

251–260 of 352 posts

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

#251

Post by sorcercode »

jayd16 wrote: post #201
sorcercode wrote: post #183

There's truth to a lot of what's said in this post and I see many people complain but these opinions feel short sighted (not meant derogatorily - just that these are shorter term problems). > Teams that care about quality will take the time to review and understand (and more often than not, rework) LLM-generated code before it makes it into the repo. This slows things down, to the extent that any time saved using the…

> i intentionally tried to use a language I'm not as proficient in (but obv have a lot of bg in programming) to see if I could keep steering the LLM effectively I think this might be the wrong assumption. In the same way the news happens to be wrong about topics you know, I think it's probably better to judge code you know over code you don't. It's easy to accept whatever the output was if you don't know what you're…

fair point.

but i'm not proficient != i don't know (i.e. i have worked on javascript many moons ago, but i wouldn't consider myself an expert at it today).

i like to think i can still spot unmaintainable vs maintainable code but i understand your point that maybe the thinking is to have an expert state that opinion.

the code is [oss](https://github.com/kaushikgopal/ff-container-traffic-control) btw so would love to get other takes.

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

#252

Post by danans »

The guiding principle for most of the tech industry is to produce the cheapest thing you can get away with. There is little intrinsic motivation toward quality left in the culture.

When velocity and quantity are massively incentivized over understanding, strategy, and quality, this is the result. Enshittification of not only the product, but our own professional minds.

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

#253

Post by romaniv »

No, this is not a pre-existing problem.

In the past the problem was about transferring a mental model from one developer to the other. This applied even when people copy-pasted poorly understood chunks of example code from StackOverflow. There was specific intent and some sort of idea of why this particular chunk of code should work.

With LLM-generated software there can be no underlying mental model of the code at all. None. There is nothing to transfer or infer.

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

#254

Post by recursive »

bluefirebrand wrote: post #111
jacobr1 wrote: post #94

Earlier quoted context omitted.

I think this is part of the reason why I've had a bit more success with AI Coding than some of my colleagues. My pre-llm workflow was to rapidly build a crappy version of something so that I could better understand it, then rework it (even throw away to the prototype) to build something I now know how I want to handle. I've found even as plenty of thought leaders talk about this general approach (rapid prototyping, c…

> My pre-llm workflow was to rapidly build a crappy version of something so that I could better understand it, then rework it (even throw away to the prototype) to build something I now know how I want to handle. In my experience this is a bad workflow. "Build it crappy and fast" is how you wind up with crappy code in production because your manager sees you have something working fast and thinks it is good enough

Nothing lasts longer than a temporary fix.

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

#255

Post by blackhaj7 »

alexpotato wrote: post #232
blackhaj7 wrote: post #222

Earlier quoted context omitted.

Sounds great - thanks for the recommendation. Looks like it is the second in a trilogy. Can you just dive in or did you read the first book before?

I read Fire Upon the Deep first and liked both books. General recommendation is to read them in order (Fire first, Deepness second) but I don't really think it matters.

Awesome - thanks!

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

#256

Post by solatic »

trjordan wrote: post #43

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…

> We need different primitives

The correct primitives are the tests. Ensure your model is writing tests as you go, and make sure you review the tests, which should be pretty readable. Don't merge until both old and new tests pass. Invest in your test infrastructure so that your test suite doesn't get too slow, as it will be in the hot path of your model checking future work.

Legacy code is that which lacks tests. Still true in the LLM age.

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

#257

Post by bluefirebrand »

book_mike wrote: post #66

LLMs are powerful tools but they are not going to save the world. I have seen this before. The experienced crowd gets chuffed because it is a new pattern that radically changes their current workflow. The new crowd haven't optimised yet so they over use the new way of doing things until they moderate it. The only difference I can detect is that rate of change increased to an almost uncomprehensable pace. The wave’s s…

> The only difference I can detect is that rate of change increased to an almost uncomprehensable pace

This is a pretty seriously bad difference imo

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

#258

Post by wiradikusuma »

From my experience, you should either treat LLM-generated code as the usual code (before LLM age) that you need to review every time it changes, or you should not review it at all and treat it as black box with clearly defined boundaries. You test it by putting on your QA hat, not your Developer hat.

You can't change your stance later, it will just give you a headache.

When the former breaks, you fix it like conventional bug hunting. When the latter breaks, you fix it by either asking LLM to fix it or scrap it and ask LLM to regenerate it.

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

#259

Post by sfn42 »

medstrom wrote: post #247
sfn42 wrote: post #103

Earlier quoted context omitted.

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.

Yeah sure but that's not what dude above is suggesting. Dude above is suggesting "hello ai please document this entire project for me".

I mean even if that did work you still gotta read the docs to roughly the same degree as you would have had to read the code and you have to read the code to work with it anyway.

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

#260

Post by captainkrtek »

romaniv wrote: post #253

No, this is not a pre-existing problem. In the past the problem was about transferring a mental model from one developer to the other. This applied even when people copy-pasted poorly understood chunks of example code from StackOverflow. There was specific intent and some sort of idea of why this particular chunk of code should work. With LLM-generated software there can be no underlying mental model of the code at a…

It’s even worse because the solution an LLM produces is not obvious as to whether it was inherently chosen by the user and favored over a different approach for any reason, or it was just what happened to be output and “works”.

I’ve had to give feedback to some junior devs who used quite a bit of LLM created code in a PR, but didn’t stop to question if we really wanted that code to be “ours” versus using a library. It was apparent they didn’t consider alternatives and just went with what it made.

Post reply on HN