Great article. I def experienced this new form of burnout. I’ve gotten use to working with AI systems to produce code, mainly the velocity of code production. It took me four months to develop an intuition of how to maintain a healthy pace and when to rest. I still feel that the pace is very fast, but my ability to consume code and update my mental model has improved. I try my best not to push past a certain point. I feel once the cognitive load is at capacity, you’re going to reduce quality in your outputs. So I’ve given myself a set threshold that I won’t cross. If things are slower, so be it. It’s not worth the added stress to have completed functioning code, with outsize cognitive debt.
Cognitive Debt: When Velocity Exceeds Comprehension
221–230 of 234 posts
Re: Cognitive Debt: When Velocity Exceeds Comprehension
#222The 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."
My experience with Perl. "Write-only" language.
Beat me to it! I did in fact have experiences like that with Perl in years past.
Re: Cognitive Debt: When Velocity Exceeds Comprehension
#223Management where I work is currently touting a youtube video from some influencer about the levels of AI development, one of the later ones being "you'll care that it works, not how". We are all supposed to be advancing through these levels. Moving at a pace where you actually understand the system you're responsible for is now considered a performance issue. But also, we're "still held responsible for quality". Need…
Sounds like "Nate B Jones" from the "AI News & Strategy Daily | Nate B Jones". He's very enthusiastic about the notion that there are "dark software houses" or something like that where no human writes code, reviews code, or writes unit / integration tests. The human's job is to write specs so complete that the AI can't help but write the correctly behaving software, and that the software developer role combines somehow with the product manager role, and that the skills required for this are fundamentally different from traditional software, and that most people are at tier zero, one, or two of the AI-aided software paradigm, whereas they need to be at level five to not be left behind. His videos are thought-provoking at least.
EDIT: fixed a few mistakes
Re: Cognitive Debt: When Velocity Exceeds Comprehension
#224Earlier quoted context omitted.
"free time gained" lol in what world is that ever a thing?
I guess we work in very different places!
I'm more inclined to believe your response is an AI-generated one liner if my choices are that or accepting an employer is baking in slack time in response to productivity gains by employees.
Re: Cognitive Debt: When Velocity Exceeds Comprehension
#225The 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…
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.
Why doesn't this apply to human collaborators as well? If you need all this extra metadata to comprehend the changes, isn't that kind of going backwards? You spend time (setting up the agents, building extensive prompts that explain soooo much of how to do things, adding to whatever markdown file you think controls the parrot) and money (so many token$), to get code that you don't comprehend, and just decide to fill your repo with all of the above to... what exactly does all this accomplish? So you can later ask another parrot to "fix" something?
Re: Cognitive Debt: When Velocity Exceeds Comprehension
#226Earlier quoted context omitted.
I doubt you can give more context to an LLM from a README file than 500 properly written commits. Or to a human for that matter.
The problem isn't giving MORE context to an agent, it's giving the right context These things are built for pattern matching, and if you keep their context focused on one pattern, they'll perform much better You want to avoid dumping in a bunch of data (like a year's worth of git logs) and telling it to sort out what's relevant itself Better to have pre-processing steps, that find (and maybe summarize) what's relevan…
"You want to avoid dumping in a bunch of data (like a year's worth of git logs) and telling it to sort out what's relevant itself"
So instead you give it a years worth of changelog.md?
"Better to have pre-processing steps, that find (and maybe summarize) what's relevant, then only bring that into context"
So, not a list of commits that touched the relevant files or are associated with relevant issues? That kind of "preprocessing" doesn't count?
"You can do that by running your git history through a cheap model, and asking it to extract the relevant bits for the current change. But, that can be overkill and error prone, compared to just maintaining markdown files as you make changes"
And somehow extracting the same data out of a [relatively] unstructured and context-free (the changelog only has dates and description, that will need to be correlated to actual changes with git anyway...) markdown file is magically less error-prone?
Re: Cognitive Debt: When Velocity Exceeds Comprehension
#227The 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."
But at least the coder has potential to have learned something. The future agent needs to be given all the context the past agent had, or else it's basically starting from scratch and is likely to make all the same mistakes.
Re: Cognitive Debt: When Velocity Exceeds Comprehension
#228Earlier quoted context omitted.
Users flagged it and there were several reports that it seems likely to be LLM-generated. Please email us (hn@ycombinator.com) to communicate with the mods. We don't get alerted to mentions of usernames and we don't get even close to seeing every comment, especially after a thread has gone from the front page.
It feels like this article was flagged by users who sell AI stuff, because they dont like its content - so they tried to censorship it with some excuse. This article shows flaws with AI driven development.
I didn't flag it, but I am certain it is fully or almost-fully LLM composed. I haven't engaged with it carefully enough to know if I agree with it, because just from a skim it seems so fully LLM-synthesized I am not going to bother.
Re: Cognitive Debt: When Velocity Exceeds Comprehension
#229Richard 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.
I hope people can see that "winning big" using that process is very unlikely NOT to be "winning long term".
(From GP) "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' standards."
Those user's standards are an ephemeral target for any software beyond a one-shot script or a hobby project with minimal user:dev ratio. That incorrect and unclean code simply isn't conducive to the many iterations needed when those "users' standards" change. And as we all know, that change is _inevitable_, and oftentimes happens before the software in question has even had a single release! Get ready to throw ever more tokens at trying to correct and clean if you ever really "win big" and need to actually support the product.
It's very much gross short-sighted thinking that goes right along with the gross short-sighted thinking providing all the [fake] value around this crap.
Re: Cognitive Debt: When Velocity Exceeds Comprehension
#230Great 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…
I think it won't be too different once we see a few upgrades that are going to be required for reliability (and scaling up the AI assisted engineering process): - deterministic agents, where the model guarantees the same output with a seed - much faster coding agents, which will allow us to "compile" or "execute" natural language without noticing the llm - maybe just running the whole thing locally so privacy and rel…
Then those "upgrades" will come down to just using an LLM as a lexer/parser for natural language and then calling a compiler on the generated AST. Except natural language is often very very ambiguous and removing that ambiguity by limiting the possible inputs just brings you closer and closer to a high level programming language. So why not just start there and use something way more efficient than an LLM for lexing/parsing? I'm not saying current high level languages are the endgame, they can certainly be improved and specialized and made faster. Just that the current architecture does not need to be replaced by statistical modeling, especially when you talk of making them deterministic with starting seeds... why bother forcing an LLM to follow the same deterministic path when we already know how to make tools to do that?