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

Cognitive Debt: When Velocity Exceeds Comprehension

rockoder.com

Post reply on HN
Print view View original

31–40 of 234 posts

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#31

Post by forgetfreeman »

Retric wrote: post #14
pajtai wrote: post #9

The whole premise of the post, that coders remember what and why they wrote things from 6 months ago, is flawed. We've always had the problem that understanding while writing code is easier than understanding code you've written. This is why, in the pre-AI era, Joel Spolsky wrote: "It's harder to read code than to write it."

Harder here doesn’t mean slower. Reading and understanding your own code is way faster than writing and testing it, but it’s not easy. AI tools don’t prevent people from understanding the code they are producing as it wouldn’t actually take that much time, but there’s a natural tendency to avoid hard work. Of course AI code is generally terrible making the process even more painful, but you where just looking at the…

Certainly AI tools don't prevent anything per se, that's management's job. Deadlines and other forms of time pressure being what they are it's trivial to construct a narrative where developers are producing (and shipping) code significantly faster than the resulting codebase can be fully comprehended.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#32

Post by forgetfreeman »

gusmally wrote: post #15
soared wrote: post #4

The organizational memory and on-call debugging sections allude to this, but there are significant effects on other parts of the organization. For example, if I work in product support and a customers asks about a products behavior - it becomes much more challenging to find answers if documentation is sparse (or ai written), engineers don’t immediately know the basics of the code they wrote, etc. Even if documentatio…

With the free time gained from not manually writing code, documentation should be part of the workflow. I should start doing this.

"free time gained" lol in what world is that ever a thing?

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#33

Post by samrus »

Great article. I agree with the argument.

But to offer a counter argument, would the same thing not have happened with the rise of high level languages? The machine code was abstracted away from engineers and they lost understanding of it, only knowing what the high level code is supposed to do. But that turned out fine. Would llms abstracting the code away so engineers only understand the functionality (specs, tests) also be fine for the same reason? Why didnt cognitive debt rise in with high level languages?

A counter counter argument is that compilers are deterministic so understanding the procedure of the high level language meant you understood the procedure that mattered of the machine code, and the stuff abstracted away wasnt necessary to the codes operation. But llms are probabilistic so understanding the functionality does not mean understanding the procedure of the code in the ways that matters. But id love to hear other peoples thoughts on that

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#35

Post by senko »

pajtai wrote: post #9

The whole premise of the post, that coders remember what and why they wrote things from 6 months ago, is flawed. We've always had the problem that understanding while writing code is easier than understanding code you've written. This is why, in the pre-AI era, Joel Spolsky wrote: "It's harder to read code than to write it."

I recently did some work on a codebase I last touched 4 years ago.

I didn't remember every line but I still had a very good grasp of how and why it's put together.

(edit: and no, I don't have some extra good memory)

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#36

Post by supriyo-biswas »

samrus wrote: post #26
gusmally wrote: post #15

Earlier quoted context omitted.

With the free time gained from not manually writing code, documentation should be part of the workflow. I should start doing this.

Management will demand that free time goes to more features. Thats the problem. Time spent understand the feature (either while writing it or documenting it) is not valued, only time spent making it. So when making and understanding are decoupled, management will demand you spend all your time making, rather than understanding. They'll just tell you to have the llm make the docs

If that is what management wants I’m more than happy to give it to them.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#37

Post by iainctduncan »

pajtai wrote: post #9

The whole premise of the post, that coders remember what and why they wrote things from 6 months ago, is flawed. We've always had the problem that understanding while writing code is easier than understanding code you've written. This is why, in the pre-AI era, Joel Spolsky wrote: "It's harder to read code than to write it."

Oh come on, that is complete nonsense. I can reunderstand complicated code I wrote a year ago far, far faster than complicated code someone else wrote. Especially if I also wrote tests, accompanying notes, and docs. If you can't understand your old code when you come back to it... including looking through your comments and docs and tests... I'm going to say you're doing it wrong. Maybe it takes a while, but it shouldn't be that hard.

Anyone pretending gen-ai code is understood as well as pre-gen-ai, handwritten code is totally kidding themselves.

Now, whether the trade off is still worth it is debatable, but that's a different question.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#39

Post by youknownothing »

gusmally wrote: post #17

> When circumstances eventually require that understanding, when something breaks in an unexpected way or requirements change in a way that demands architectural reasoning, the organization discovers the deficit. Maybe it's because I work in such a small team on a still-starting project, but even with the chaos of LLM-generated code, I can't imagine such a case as above that the LLMs couldn't also address. Great read…

have you worked in a 10-15 year old codebase? because I honestly doubt that LLMs can cope with that.
Post reply on HN