Cognitive Debt: When Velocity Exceeds Comprehension

Just to make sure it's somewhere in these comments: the fundamental issue is people trying to measure something they don't understand. That is not new. The article gives an interesting exploration of how things break down in a new way when people focus too much on metrics instead of (IMO) the more robust approach of getting people who care to try to make something that feels quality. We're building crap, yes, but I blame the people who spend their time measuring "velocity" like it's a well defined term, not the coding tools being used to play the game.

I have this at the bottom of my AGENTS.md:

You will also add a markdown file to the changelog directory named with the current date and time `date -u +"%Y-%m-%dT%H-%M-%SZ"`, record the prompt, and a brief summary of what changes you made, this should be the same summary you gave the developer in the chat.

From that I get the prompt and the summary for each change. It's not perfect but it at least adds some context around the commit.

The other guy's post was also very obviously written at least in part by an LLM. It's slop all the way down.

I'm seriously considering taking a break from this site if this is the direction that everyone wants to go in.

Oh yes, this is blatantly AI-written. Whether this is ironic and discredits the claims is up to you.

But the opening at least makes a good point: AI-written code is right now something of an embezzlement or theft or fraud. Like junk food, it presents all the appearance of coming with correlates like "an engineer now understands the problem-space and has built tacit knowledge and a theory of how the domain/code work"... But it doesn't. The human engineer takes all the credit (and promotions), having put in a tenth or less the usual work, but evades the blame or tech debt.

This is why vibecoding is the inevitable endpoint. The current code market is a lemon market, and we see the exact same kind of dynamics of 'buyers' withdrawing from 'purchases' as they see all these shiny code bases which are secretly lemons, and sellers increasingly get frustrated they can't get a 'fair price' (like anyone to look at their 'Show HN' posts).

We must understand that the source code is no more valuable than a compiled binary, and that the responsible human doesn't understand it and has to trust it, in the same way that we now understand source code but don't understand and have to trust the compiled binary. Today, I understand my Haskell code, but I have no idea what is going on in the compiled binary (nor do I claim to); tomorrow, I will understand my prompt/spec, but I will have no idea what is going on in the 'source code' (nor will anyone expect me to or admire me for 'writing all that code' or be surprised if some seriously mistaken assumption is hardwired into the generated code). Just as no one cares about a binary you compiled today, no one will care about your source code. (Unless there is something special about it, of course. 'I compiled Firefox for my Linux' - OK, congrats? 'I compiled Firefox for my toaster' - OK now I'm interested.)

So, no one will care about the codebase for your 'Show HN' project; you have to instead get them to care about your proposal or your testsuite. If it's any good, they can simply pass it to their own LLMs to 'compile'; no need to trust your crummy dubious already-obsolete 'source code'...

> One other thing that surprised me was that my eng manager was seemingly oblivious to my ongoing complains about growing cognitive load and confusion rate.

Engineering managers in my experience (even in ones with deep technical backgrounds) often miss the trees for the forest. The best ones go to bat for you, especially once verifying that they can do something to unblock or support you. But that’s still different than being in the terminal or IDE all day.

Offloading cognitive load is pretty much their entire role.