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

21–30 of 234 posts

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#21

Post by ford »

Good engineering has always been about minimizing the amount of effort it takes for someone to understand and modify your code. This is the motivation for good abstractions & interfaces, consistent design principles, single-responsibility methods without side-effects, and all of the things we consider "clean code".

These are more important than ever, because we don't have the crutch of "Teammate x wrote this and they are intimately familiar with it" which previously let us paper over bad abstractions and messy code.

This is felt more viscerally today because some people (especially at smaller/newer companies) have never had to work this way, and because AI gives us more opportunity to ignore it

Like it or not, the most important part of our jobs is now reviewing code, not writing it. And "shelfed" ideas will now look like unmerged PRs instead of unwritten code

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#22

Post by monkeydust »

lolive wrote: post #6

I have been in a big company for 4 years, and following the zillions of projets going on here and there, how they interact [nicely or not] has become a job in itself. Very disturbing as I thought my technical skills would help me clarify the global picture. And that is exactly the contrary that is happening.

The way that people interact inside of knowledge companies to get things done is itself the fabric of how it operates. A recent SaaS CEO piece here calls is the 'language games'.

https://ionanalytics.com/wp-content/uploads/2026/02/The_Wron...

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#24

Post by somebehemoth »

esafak wrote: post #19

Just read every line of the generated code and make sure it is as clear and good as possible. If you can't understand it when it's new you won't tomorrow, either. This verification process places a natural limit on the rate at which you can safely generate code. I suppose you could reduce that to spot checks and achieve probabilistic correctness but I would not venture there for things that matter.

Because lines of code interact with each other. Understanding what one line does in isolation does not always show the rough edges that are found when code interacts. The challenge is seeing the forest instead of individual trees.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#25

Post by softwaredoug »

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

If I’m learning for the first time, I think it matters to hand code something. The struggle internalizes critical thinking. How else am I supposed to have “taste”? :)

I don’t know if this becomes prod code, but I often feel the need to create like a Jupyter notebook to create a solution step by step to ensure I understand.

Of course I don’t need to understand most silly things in my codebase. But some things I need to reason about carefully.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#26

Post by samrus »

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.

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

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#27

Post by [deleted] »

somebehemoth wrote: post #24
esafak wrote: post #19

Just read every line of the generated code and make sure it is as clear and good as possible. If you can't understand it when it's new you won't tomorrow, either. This verification process places a natural limit on the rate at which you can safely generate code. I suppose you could reduce that to spot checks and achieve probabilistic correctness but I would not venture there for things that matter.

Because lines of code interact with each other. Understanding what one line does in isolation does not always show the rough edges that are found when code interacts. The challenge is seeing the forest instead of individual trees.

[deleted]

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#28

Post by avaer »

> The engineer who pauses to deeply understand what they built falls behind in velocity metrics.

This is the most insidious part. It's not even that bad code gets deployed. That can be fixed and hopefully (by definition) the market weeds that out.

The problem is that the market doesn't seem to operate like that, and instead the engineer who cares loses their job because they're not hitting the metrics.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#29

Post by bob1029 »

I think stronger determinism could dramatically improve the situation here. Right now, I don't know if the same model within the same hour will produce consistent output given identical prompts and low temperature.

I have no clue what my compiler is emitting every time I hit F5. I don't need to comprehend IL or ASM because I have a ~deterministic way to produce this output from a stable representation.

Writing a codebase as natural language is definitely feasible, but how we're going about it right now is not going to support this. A vast majority of LLM coding is coming out of ad-hoc human in the loop or stochastic agent swarms. If we want to avoid the comprehension gap we need something closer to a compiler & linker that operates over a bucket of version-controlled natural language documents.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#30

Post by add-sub-mul-div »

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.

With the free time gained from the advent of fast food people "should" have started exercising more, but they didn't. As disciplined as you yourself may be, the typical person is going to use AI to expend minimal effort and go home at 4:55 pm.
Post reply on HN