71–80 of 150 posts
More code is not better. more code, more quickly is worse. Don't delude yourself into thinking you are more productive, you are just digging a deeper hole.
"Technical" and "cognitive" debt aren't really distinct phenomena; the spirit of the original definition of "technical debt" was that it WAS the delta between the system-as-it-is, and the human understanding of how best to solve whatever problem the system was intended to solve [1].
If we accept collapsing them back down to one term, then "managing cognitive debt" is the same thing as "managing technical debt": work to match the system to the human understanding of the problem the system is meant to address. The article calls out "emerging" techniques to do just this:
- More rigorous review practices
- Writing tests that capture intent
- Updating design documents continuously
- Treating prototypes as disposable
To me these are not "emerging," but rather "well-known industry best practices." Though maybe they're not that well known in fact? [EDIT TO ADD] On the other hand, it would make sense that they ARE well known, and that teams therefore reach for these familiar techniques to try and solve this "new" problem.
Putting in my 2c for the closing questions/thoughts in the article:
> How will they shape socio-technical practices and tools to externalize intent and sustain shared understanding?
Honestly? We'll probably end up doing these things more or less the same ways we always have. AI has not actually changed anything fundamental about how an individual encounters the world; there always was, and always will be, and always will have been, WAY more going on that we can fully get our heads around, but it's also always been the case that we can partially get our heads around most any problem space
> How will they use Generative and Agentic AI not only to accelerate code production, but to maintain their collective theory?
I suspect the answer to this one might well be that high-performing teams will have to scrupulously AVOID "accelerating code production" using AI in order to make sure what they are creating actually composes into the system they think they're building. If human understanding is the bottleneck, then the humans will have to produce less crap they need to understand!
[1]: https://wiki.c2.com/?WardExplainsDebtMetaphor, particularly the "Burden" and "Agility" sections.
Cognitive Debt has existed much earlier before LLMs became mainstream. Technical people got good at their jobs and then was promoted to management. After time they lost their technical abilities but if they are a good manager they kept up to date with the technological landscape and used their engineering thinking to ensure that the people below them worked to their optimum efficiency to achieve the companies goals.…
Earlier quoted context omitted.
In fact, agile has been extremely successful. It's the people that claim to "do agile" that invariably don't do it. But software development used to fail most of the time, and it doesn't do that anymore.
What makes you say that it has been extremely successful? And when you say doesn't fail anymore, do you mean it doesn't go over budget and/or changes scope?
"the question becomes how teams will manage cognitive debt" the question is why it is allowed to occur when it is avoidable. Farcical nonsense. Write the code yourself or be silent.
> the question becomes how teams will manage cognitive debt That’s the neat trick kiddo, they won’t. Across the industry, the messaging is clear: use AI and be more productive. Management is salivating at the idea of getting rid of people and keeping a higher share of profits for themselves. Most ICs I talk to are increasingly expressing the feeling of burnout, fear of losing jobs and resentment that AI is being push…
You can use AI to manage cognitive debt, but it doesn't reflect on the sprint board. Across the board, I still see people loving to over design things that can be much simpler. This isn't much changed because of LLM, LLM just allowed them to create the complicated implementations much faster.
In terms of over engineering, I wouldn't be surprised if the human tendency for skeuomorphism (combined with an loss of technical skill) will create even weirder code.
Earlier quoted context omitted.
so it's called agile when it works, but not when it doesn't, got it!
You gotta understand how to use a tool for it to be effective, yes.
To be fair, the manifesto and methodology is quite good in theory. But I just have never heard of(or experienced) it working properly and the response is always that it wasn't implemented correctly.
There are many projects that should not be built agentically. For things that are appropriate to build with agents, I have come to hold the strong opinion that you need to go all-in. If you built it with an agent, then you fix it with an agent, you debug it with an agent, and you change it with an agent. In that case you should not consider yourself the steward of the source code and worry about “cognitive debt”- it’…
That said, it still frequently introduces subtle bugs, so I have to review every change carefully.
The real trick is learning when to use it. Some tasks are much faster to do myself, while others are faster with Claude Code.
Ever since LLMs started writing decent code, I started feeling like a part of that joy of code-writing has been taken away.
Using LLMs literally leaves a developer to do (what I find is) the worst part about software development: debugging someone else’s code.
Besides this, everything feels rushed. I am under the impression that I can’t “take my time” to think about a problem anymore. It almost feels wasteful now. I have to “just do it”.
It makes me nostalgic and I feel like I’ve lost something about coding that made me enjoy it.
But it is the reality we live in and I’m adapting to it. What I’m wondering is whether I should adapt or, rather, push back.
That being said: this feels a little like it was written using AI.