Cognitive Debt: When Velocity Exceeds Comprehension • Hacker News Board

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#131

Post by aurareturn » Sat, Feb 28, 2026, 6:53 PM UTC

hintymad wrote: post #114

Richard Gabriel wrote a famous essay Worse Is Better ( https://www.dreamsongs.com/WorseIsBetter.html ). The MIT approach vs the New Jersey approach does not necessarily apply to the discussion of the merits of coding agent, but the essay's philosophy seems relevant. AI coding sometimes sacrifices correctness or cleanness for simplicity, but it will win and win big as long as the produced code works per its users' sta…

  Once the software has users and VC funding, developers can go back and incrementally improve or refactor the AI's mess, to a satisfying degree.

Or in my case, the AI is going back to refactor some poor human written code.

I will fully admit that AI writes better code than me and does it faster.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#132

Post by gopher_space » Sat, Feb 28, 2026, 6:53 PM UTC

Klaster_1 wrote: post #101

nsvd2 wrote: post #97

Earlier quoted context omitted.

I think that recording dialog with the agent (prompt, the agent's plan, and agent's report after implementation) will become increasingly important in the future.

Agree, but current agents don't help with that. I use Copilot, and you can't even dump it preserving complete context, including images, tool call results and subagent outputs. And even if you could, you'd immediately blow up the context trying to ingest that. This needs some supporting tooling, like in today's submission where agent accesses terabytes of CI logs via ClickHouse.

I've had some luck creating tiny skills that produce summaries. E.g. a current TASK.md is generated from a milestone in PLAN.md, and when work is checked in STATUS.md and README.md are regenerated as needed. AGENTS.md is minimal and shrinking as I spread instructions out to the tools.

Part of my CI process when creating skills involves setting token caps and comparing usage rates with and without the skill.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#133

Post by skydhash » Sat, Feb 28, 2026, 6:56 PM UTC

bojan wrote: post #92

xeromal wrote: post #49

Earlier quoted context omitted.

Of course, there are counter examples but there's a disconnect between the production of something and the selling of it with almost opposing goals. Given unlimited money and time, many engineers, arts, etc will write and rewrite something to perfection. Constraints are needed because the world doesn't operate in a vacuum and unless we all live in a utopia, we have to compete for customers and resources. Constraints…

> Given unlimited money and time, many engineers, arts, etc will write and rewrite something to perfection This is a common trope, but in my experience many engineers I met know that's not how a business runs. Dealing with the constraints and weighing them out is one of the essential skills of any engineer. Knowing when a product is just good enough is one of the things that make you senior.

The usual person that believe in the trope is the one that wants something with short-term budget, but with long-term quality. Lot of engineers know the triangle of budget-scope-time. But a lot of managers want to have the cake and eat it too. When they ask to reduce time and the budget and the engineer ask what to reduce in the scope, they get all vague and shifty.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#134

Post by Gliding7682 » Sat, Feb 28, 2026, 6:56 PM UTC

juanpabloaj wrote: post #121

> The second is absorption: mental models form, edge cases become intuitive, architectural relationships solidify into understanding. ... . The friction of implementation creates space for reasoning. > This gap between output velocity and comprehension velocity is cognitive debt. I have felt that lack of absorption during the last months, adding doomscroolling to the equation, I have felt how my thinking is disappear…

I like this phrase from the post you shared:

> A species that cannot follow the reasoning of its own systems does not supervise them; it simply inhabits them until they stop working.

I feel this idea is closely related to additive bias. People are scared of breaking things, so the safest way is to just add another tiny part to an already complex system. As cognitive debt accumulates faster, this additive bias just becomes stronger imo.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#135

Post by 0wis » Sat, Feb 28, 2026, 7:01 PM UTC

matsemann wrote: post #123

Klaster_1 wrote: post #84

The article very much resonates with my experience past several months. The project I work on has been steadily growing for years, but the amount of engineers taking care of it stayed same or even declined a bit. Most of features are isolated and left untouched for months unless something comes up. So far, I managed growing scope by relying on tests more and more. Then I switched to exclusively developing against a s…

Learning has always been to write things down. Just reading it seldom sticks.

Not sure humanity learned nothing before the last 8000 years. It was just very slow. Maybe we will need new ways to learn

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#136

Post by juanre » Sat, Feb 28, 2026, 7:02 PM UTC

"The system they built feels slightly foreign even as it functions correctly." This is exactly the same issue that engineers who become managers have. You are further away from the code; your understanding is less grounded, it feels disconnected.

When software engineers become agent herders their day-to-day starts to resemble more that of a manager than that of an engineer.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#137

Post by kazinator » Sat, Feb 28, 2026, 7:02 PM UTC

> When an engineer writes code manually, two parallel processes occur. The first is production: characters appear in files, tests get written, systems change. The second is absorption: mental models form, edge cases become intuitive, architectural relationships solidify into understanding.

That absorption only takes place in the mind of that individual, unfortunately. That doesn't help when they no longer work there or are on vacation.

The ideal situation is the solo open source project. You wrote all 200K lines of code yourself, and will maintain them until death. :)

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#138

Post by hintymad » Sat, Feb 28, 2026, 7:05 PM UTC

jamamp wrote: post #125

hintymad wrote: post #114

Richard Gabriel wrote a famous essay Worse Is Better ( https://www.dreamsongs.com/WorseIsBetter.html ). The MIT approach vs the New Jersey approach does not necessarily apply to the discussion of the merits of coding agent, but the essay's philosophy seems relevant. AI coding sometimes sacrifices correctness or cleanness for simplicity, but it will win and win big as long as the produced code works per its users' sta…

I hope people can ask themselves why the goal is "winning" and "winning big", and not making a product that you are proud of. It shouldn't be about VC funding and making money, shouldn't we all be making software to make the world a little bit better? I realize we live in an unfortunate reality surrounded by capitalism, but giving in to that seems shortsighted and dismissive of actual problems.

“Winning” is just the the subjective word I quickly picked. It certainly can be another one, such as the success due to a great product as you mentioned

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#139

Post by cs702 » Sat, Feb 28, 2026, 7:06 PM UTC

It used to take years, decades, or centuries before a system could grow and evolve to be so complex and unwieldy, and so full of internal contradictions, that the whole thing becomes an incomprehensible tangle of hairballs. An example is the patchwork system of international, national, regional, and local laws we have at present, which has grown and evolved over centuries.

Now, it can take only a few days or weeks.

Re: Cognitive Debt: When Velocity Exceeds Comprehension

#140

Post by skydhash » Sat, Feb 28, 2026, 7:07 PM UTC

wrs wrote: post #70

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…

The code for the machine to execute is opcodes realized by electric signals. But it's not a good tool to solve problems even when directly translated to assembly. All the other languages were invented for better human affordance and can map to assembly (and opcodes) with logical rules.

The last part is what matters. There's no such clear rules in LLMs behavior. Yes you can get to behave roughly like a rule, but there's no clear cut demarcation between what's in and what's not.