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

61–70 of 234 posts

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#61

Post by seba_dos1 »

copperx wrote: post #56
senko wrote: post #35

Earlier quoted context omitted.

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)

Lucky you. I always go "huh, so I wrote this?". And this was in the pre-AI era.

These feelings aren't mutually exclusive. I'm often like "I have no memory of this place" while my name stares at me from git blame, but that doesn't mean my intuition of how it's structured isn't highly likely to be right in such cases.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#62

Post by AndrewKemendo »

Code has become cheaper to produce than to perceive.

Which means fixes can go in faster than it would require to first grok it

What’s missing in literally every single one of these conversations is testing

Literally all you have to do is implement test driven development and you solve like 99.9% of these issues

Even if you don’t go fully TDD which I’m not a fan of necessarily having an extensive testing suite the covers edge cases is necessary no matter what you do but it’s a need to have in a case where your code velocity is high

This is true for a company full of juniors pumping out code like early days of Facebook let’s say which allowed for their mono repot to grow insanely but it took major factors every few years but it didn’t really matter because they had their resources to do it

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#63

Post by red_admiral »

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

In the past, it was also an optimistic assumption that your engineers would still be working for you in a year's time? You need some kind of documentation / instructive testing anyway. And maybe more than one person who understands each bit of the system (bus factor).

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#64

Post by immortalcodes »

I have a view that we are shifting from the traditional form of Engineering into a more AI guided form, where may be we are not learning as much about the code but about how we can produce that code with correct instructions and high level design.

It's like how we might not know how sewing is done but we know how to put instructions in a loom to produce it. I also agree it is still important to read that code and understand how it works, may be take a moment to see what is happening but we are learning something entirely different here.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#65

Post by bootsmann »

jasode wrote: post #48

Not to disagree with anything the article talks about but to add some perspective... The complaint about "code nobody understands" because of accumulating cognitive debt also happened with hand-written code. E.g. some stories: - from https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=58... : >Two of us tried to debug the program to figure out what was going on, but given that this was code written several year…

This underlines the argument of the OP no? The argument presented is that the situation where nobody knows how and why a piece of code is written will happen more often and appear faster with AI.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#66

Post by senko »

SoftTalker wrote: post #60
senko wrote: post #35

Earlier quoted context omitted.

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)

I find this to be the case if it was something I was deeply involved with. Other times, I can make a small change to something that doesn't require much time, and once it's tested and committed, I quickly lose any memory of even having done it.

Yeah I did pour a lot of sweat and thinking into that codebase all those years ago.

When I do a drive-by edit, I probably don't remember it in a week.

Which is why the "cognitive debt" from the article is relevant, IMHO. If I just thoroughly review the plan and quickly scan the resulting code, will that have a strong enough imprint on my mind over time?

I would like to think "yes", my gut is telling me "no". IMHO the LLMs are now "good enough" for coding. These are hard questions we'll have to grapple with this in the next year or two (in context of AI-assisted software development).

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#67

Post by osigurdson »

I think we might as well just go all in at this point: "LGTM, LLM". The industry always overshoots and then self-corrects later. Therefore, maybe the right thing to do is help it get to a more sane equilibrium is to forget about the code altogether and focus on other ways to constrain it / ensure correctness and/or determine better ways to know when comprehension is needed vs optional.

What I don't like is the impossible middle ground where people are asked to 20X their output while taking full responsibility for 100% of the code at the same time. That is the kind of magical thinking that I am certain the market will eventually delete. You have to either give up on comprehension or accept a modest, 20% productivity boost at best.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#68

Post by bikelang »

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

It’s hard to keep the minutiae in your memory over a long period of time - but I certainly remember the high level details. Patterns, types, interfaces, APIs, architectural decisions. This is why I write comments and have thorough tests - the documentation of the minutiae is critical and gives guardrails when refactoring.

I absolutely feel the cognitive debt with our codebase at work now. It’s not so much that we are churning out features faster with ai (although that is certainly happening) - but we are tackling much more complex work that previously we would have said No to.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#69

Post by mikewittie »

More code written probably does means less understanding per line (or per a more germane metric), statistically speaking. More dilute understanding probably does lead to more failures and longer recovery times. This feels like something better addressed as an end-to-end actuarial problem though, rather than trying to design metrics for something elusive like understanding.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#70

Post by wrs »

samrus wrote: post #33

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…

“Programs must be written for people to read, and only incidentally for machines to execute." — Harold Abelson

The purpose of high level languages is to make the structure of the code and data structures more explicit so it better captures the “actual” program model, which is in the mind of the programmer. Structured programming, type systems, modules, etc. are there to provide solid abstractions in which to express that model.

None of that applies to giving an LLM a feature idea in English and letting it run. (Though all of it is helpful for keeping an LLM from going completely off the rails.)

Post reply on HN