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’s literally not your job anymore. Your job is the keeper of the specification and care and feeding of the agents.
If you adopt the mindset that “I’m not going to build the documentation for me, I’m going to build it for the agent”, and “I’m not going to try to use my development skills to debug something I didn’t write, I’m going to make specific interfaces for the agent to understand the state and activity of the running code”, etc.- you’ll be a lot happier and more successful.
If you are using agents for autocomplete in your editor, or you open a separate chat window to ask a question about your code- that’s a very low level of agent usage and all your existing dev skills and responsibilities still apply.
If you’re using a planning framework like superpowers (the skill) and just laying out the spec for the program, then keep your fingers out of the source code, and don’t waste your time reading it. Have the agent explain it, showing you in the IDE, and make the agent make any changes you want.
This is correct, but it misses out an important dimension.
You can inject philosophy into the agent and ensure that it sticks to it. The LLM will, with sufficient drilling, begrudgingly implement it, most important of which is SIMPLE>COMPLEX on all levels and you have to either manually or agentically continuously monitor this.
Alternatively, LLM will use its tiny context window to build a true spaghetti that even itself cannot fix any more. This is the default path, and the path that way too many has taken.
> Alternatively, LLM will use its tiny context window to build a true spaghetti that even itself cannot fix any more.
And this is (probably) what is happening to the Claude Code product itself. The harness itself has regressed and is increasingly unstable. I get lots of weird glitches:
- I scroll back in the conversation and keep seeing the the same sections repeated, I am not actually able to see the earlier parts of the conversation because of this.
- The whole CLI UI glitches out such that you can't even make sense of what you are seeing. This is usually fixed by resizing the terminal window
- The previous edit in the conversation history gets lost when I escape it to provide direction
- The CLI sometimes consumes huge amounts of memory (more than 10GB per window, multiplied by the number of windows I'm working in)
Not my experience at all. I’ve been using Claude Code on a large "hand written" project and it’s genuinely excellent at finding bugs and generating new methods or classes.
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.
Same experience here. It produces code that I would not accept if it was written by a human, but it also produces a lot of completely fine code. It made me clear tasks that I had been procrastinating for a long time.
Unfortunately I think Cognitive Debt is the cry of the software craftsperson who thought they were an Engineer. Upon working with the agent subcontractor, the agent factory, the agent part vendor, they approached it as a craft; they found themselves wanting to walk through the offices of the subcontractor reviewing screens, inspect pieces at the factory, and get the internal design for the parts they ordered. It's natural to get overwhelmed: this is why Engineers have contracts, specifications, design drawings, datasheets, and characterization data, handed over at clearly defined boundaries of abstraction, accepting the other side may be a black box.
Of course, we have had compilers and tooling, but those are the pencil and drafting board of the draftsperson. An ecosystem of packages, dependencies and APIs has evolved, but those are often just spells the software magician invokes after reading the spellbook^H^H^H^H^H^H^H^H^H stackoverflow^H^H^H^H^H^H^H^H^H^H^H^H^H API documentation.
We are going to need to build a new set of boundaries and abstractions with new handover protocols to manage this mess.
> this is why Engineers have contracts, specifications, design drawings, datasheets, and characterization data, handed over at clearly defined boundaries of abstraction
AND inspecting the actual production line. Even Apple audits Foxconn (the most successful and reliable assembly line humans ever built) onsite annually.
Lots of very successful software was built using a waterfall approach. It's a methodology that works well if you know precisely what the end result needs to be. That doesn't make it appropriate for everything - if you don't know what the customer needs, or if you want to get an MVP out, then Agile works better, but you shouldn't dismiss an approach because it doesn't work everywhere.
Plus, 'agile' in quite a lot companies is really waterfall that's been broken into sprints without the planning of proper waterfall or the discovery and learning of real Agile. The software still gets built though. Maybe software is actually quite easy to plan.
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?
Agile cannot go over budget or scope because those are failures of planning. Agile is the methodology that was developed specifically to counteract those problems with planning. Projects that use Agile can go over budget and scope but they never do that because they are using Agile, rather they use Agile because they might do that.
It always felt like Agile is the lazy attempt of people unwilling to learn what it takes to build software, to make it more predictable. Unfortunately project planning methods that work for buildings are not really great for software. It's just corpo stuff project managers do to feel meaningful.
If the idea does not compute with human nature, the idea is flawed, its basis the knowledge of human nature is non-existent and thus it had no place in reality after all..
No, “it’s” adaptive and if you’re not adaptive then you’re quite literally not doing “it”.
Adaptive methods aren’t something unique to Agile, it’s an aspect found in basic business methodologies and processes. Very basic, textbook stuff. So when software types start grumping about their dysfunctional organizations and blaming methods they aren’t actually applying, it isn’t an indictment of the method and never can be.
If “Adaptive Heat Cycle 3.5” is a process where we turn down the thermostat when we’re too hot, and up when we’re too cold, based on a vote every 20 min: a bunch of sweaty people who are not voting and not changing the temp and lying about their needs because their boss sucks are not using the process. The fact they claim they are is only further proof of dysfunction and incompetence.
Agile has a built in solution to all agile complaints: the agile process where you fix the problem. No fix? Not agile. Blame the cargo cult players, not the rules.
And if a tool is that difficult to use, how can you tell if the problem is in the tool or the user? There's a large industry built around doing training and certifications in agile methodologies now. If a tool is that difficult to get right, maybe it's just not a good tool to begin with.
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.
So the widespread existence of business programs, certification and training heavy, obviously proves every project and business methodology is “bad” and the problem is the tool of “business methodologies”?
PRINCE2, for example, is constantly fumbled and misunderstood by immature juniors. They don’t get it, and screw it up. So… what? Haphazard planning and last minute project detonations must replace any effort to avoid such outcomes?
It’s chicken and egg. You have screwups who can’t manage and think wrong, so you formalize rules so dummies can’t hurt leadership, and then you have to train people. A stunning number fail to ‘get it’, suck at management, and do what they feel with justifications instead of following the book. That’s standard distribution at play.
Blaming methods for basic management failures is a management and culture failure. “I’ve never seen [agile] implemented correctly” is saying you didn’t fix communication issues. That’s fine, that’s hard. But that’s a meatspace issue, not process.
I am not sure how you jumped from what I said to this. I don't believe I claimed that every project and business methodology is bad. I can only speak from my experience and am not confident enough to say how every project and business methodology should or shouldn't work.
I do believe you are helping to make my point though. I am saying that the process may very well be perfection but if entities within "meatspace" cannot use it well and may never be able to use it well then how useful really is it.
Yes, this is the thing - an agent is not a counter party. But it role plays one really well.
You would need the agent to be a processing step owned by someone responsible. But the intelligent part of an agent is what makes it viable as something more than a processing step. What to do with an intelligence that can't take responsibility? Not answering this question leads to cognitive debt.
> 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 pushed the way it is being pushed. I have more than a few conversations where people have clearly expressed that they are mostly focused on keeping their jobs. They don’t care about cognitive debt and some are looking forward to the time when the debt comes due.
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.
If the default mode is that LLMs generate crap code that you have to fix with even more LLMs, then something is fundamentally wrong.
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.
The default mode of the whole startup world is humans generate crap code that you have to fix with even more humans. And it has been like that for at least two decades.
Exactly what I’m hearing and feeling too. Devs I know are just going with it so they still have a job. No one cares about quality anymore it’s just a race to output as much code as possible. And when there’s docs, it’s just whatever slop they can have an llm output so it appears to their managers that won’t read it that they did work.
I think the antidote is ownership. Every part of a company or product needs some person or small group that owns it, understands it, and feels ownership over its long-term health. They review or decide what level of review changes to it can take.
So much of what makes high-functioning teams work is a sense of ownership and stewardship, and what makes low-functioning teams break is a lack thereof. Someone with pride, drive, and a high standard feeling responsible for a particular area or thing.
In the past, that ownership could be individual or collective, but with AI and a lot more lane-crossing, ownership should tend toward smaller groups (or individuals).
A developer can design, but a designer needs to review it. A designer can code, but the owner of the code must review it.
This might feel like gatekeeping, but it's the only way.
Fortunately, the widespread use of LLMs results in companies reducing the number of things each team owns, and/or leaving lots of engineers on payroll who suddenly have abundant free time with which to start self-learning and developing a sense of ownership of parts of the product.
I agree but don't see it working out. Ownership implies that a person or a team becomes irreplaceable or at least more difficult to replace. People stop being resources and go back to being people. Management is not going to like that.
At one business I was a part of where that experiment was tried, it failed badly. In reality, people were being switched around on projects and the "owner" was changing every few months. The end result was quite messy, both in terms of technical debt and politics(about who's the final decision maker).
What you need is ownership of not just the code but ownership of the company if your work is your own then you care a lot more about then if it belongs to someone else.
I've said this before, but people gloss over this fact.
>Someone with pride, drive, and a high standard feeling responsible for a particular area or thing.
I've also said this before, but AI-glazers just respond with "I think we may just have to let go of pride & kudos and their connection to our identity."
Most people who vibecode don't give a shit about their work. Any solution is a solution as long as it works.
>This might feel like gatekeeping, but it's the only way.
Gatekeeping is not inherently bad. We want gatekeeping.
If I'm getting surgery, I want an actual doctor with proven credentials to do it.
And to anyone claiming that software doesn't kill, please look up "Therac-25" or the 65 people that died due to Tesla's "Full Self-Driving".
Of course there are examples of software killing or being capable of killing (operating machinery or medical devices), but that doesn't apply to probably 90+% of software
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.
Now we all know horrible mangers who didn't keep up to date nor used their thinking. This will happen with AI useage too. What is more we are expecting people who are engineers to have a manager's mindset (by managing AI agents, products requirements, etc). Many engineers are horrible at this and have no desires or ability to become a manager. This is why they went to engineering in the first place.
While this isn't a unique perspective, I think it's wild more people don't understand this. What happened is everyone is being "promoted" to staff+ level engineer and they're realizing the realities of that situation.
The funny part is that these are the same people who are upset that these folks up the food chain "do nothing".
This is true; as smarter people than me have said, software engineering is programming over time, and that time aspect involves individuals knowing less and less of a codebase. But that's what these smart people are advocating, in order to keep code maintainable, you need to stick to some rules, processes, patterns, etc.
Whether you apply those things to other developers or LLMs is a bit moot I think, ultimately neither (or you yourself) can be fully trusted to know and understand the full system.
This, and I would even say we are promoting people to be kings and queens. I'm afraid AI will amplify our worst parts because they are ultimately sycophants. I've heard so many things about AI enabling a single person to run a billion dollar business. But I believe without the right mindset/discipline, a person cannot go too far with any technology.
I'm consistently surprised by how many "software engineers" I've worked with have never read Naur's paper (https://pages.cs.wisc.edu/~remzi/Naur.pdf) or not even familiar with this notion before agentic coding. This was always a reality in our discipline whether folks realized it or now.
Struck a cord, and I think I managed this prior to LLM in a certain degree.
My primary editor is vim, and for a significant amount of time I was using it almost in puritan fashion, this was before LLM was mainstream.
However, I could not use vim to edit java, even with language server - I tried, but each time I went back to intellij - the rest of the code base in python, ruby and typescript was typically fine.
The reason was two fold, because everyone was using all of the features that intellij had to offer, the code was structured similar to intellij and obviously the java design patterns that was popular at the time. Everything went through factories and managers and interfaces and tracking them through a pure editor was almost impossible. The IDE handled it for you.
But everything else? Things I or others had to build from ground up was built with this cognitive limitation in mind, which means I can fit everything nicely and edit with vim, even without a language server with high efficiency.
Those cognitive limitation is good for the software. It's easy to explain, easy to debug, easy to add and subtract. And I've come to disregard the intellij way, or the current vibe coding till it works that is common everywhere now. The principle is KISS - keep it simple stupid. If AI will not do that, then you have to. It is a simple philosophical question that is more important than ever. And sadly most people still don't realize it - they will happily tack on the next "feature" in with the scaling they didn't need at that time with the design pattern that they don't need at the time and prematurely optimize themselves into cognitive and technical bankruptcy.
I had the same reaction, but the article is not AI-generated according to pangram, which I've generally found reliable. I wonder if LLM turns of phrase and even thought patterns are creeping into normal human thought.
There are typical LLM voices and styles, just like human writers have differentiated voices and styles. And some common elements of the typical LLM style are distinct from humans I've previously read.
I recognize this. It's also the case that I suspect that I've read more about how annoying suspected LLM output is to read than I have read LLM output. The slop is, to me, an incredibly unwelcome contribution of humans that don't enjoy the craft but complaining about it is equally stuck in and further exacerbating the froth rather than distilling down to the substance. That is it keeps the focus on the surface rather than on what the core content is and whether it has value.
As someone from outside the Anglophone cultural sphere, when I first learned to write in English, the kind of writing that AI now often produces was taught to me as “formal" writing.
But these days, when I write in that formal style, people sometimes say it sounds like AI. That has been a difficult and frustrating point for me.
I still find the subtle difference hard to understand.
I was raised and educated well inside the Anglosphere (USA) and was also taught to write formally in that way.
Do the people who say you sound like AI give you any specifics?
Also, if you don't mind, what was your English education like? I understand that quite a few Americans work in South Korea as teachers but I have no details about how that manifests.
That used to happen to me more often. When I first came to HN, and even now if I am not careful, my comments can get flagged. Also, when I translate from Korean using DeepL and paste the result, people often say it sounds flagged, awkward, or unnatural.
I studied English more seriously in graduate school, although I dropped out. In Korea, there are quite a few Americans who teach English. Public schools often have native English-speaking instructors, but in my case I learned English more seriously at graduate school, and universities also make students study English almost semi-compulsorily.
In Seoul, there are probably many teachers who mainly teach middle and high school students, but a lot of that is through private education rather than the public school system.
It's worth mentioning pangram is more confident in it's positive detections than it's negative ones, as stated by the founder in an interview on the most recent ThursdAI episode
These sorts of articles just seem silly to me. Use AI where it helps you and avoid where it doesn't. That dividing line may change week to week.
I think it's great for writing tests and sanity checking changes but wouldn't let it write core driver code(I'm a systems programmer so YMMV). Maybe in a month I'll think differently.
It worked for bread. Why wouldn't it work for AI? I've been baking allen wrenches and screws into my sliced bread for ages, and no single living person has complained about it.
I worry about these remediation measures. The problem described is that the increased reliance on AI has increased cognitive debt, and the solution is to write tests that better capture intent and to update design documents continuously. But the people with cognitive debt problems that got there by using AI are also going to be using AI to write tests that "capture intent better" and using AI to update design documents. And while, sure, those are good things for your agents to be doing just for the sake of the effectiveness of those same agents, it's also not going to help you get out of the cognitive debt spiral.
Just reading the first paragraph and I've already started to experience it when attempting to apply AI to Acceptance Criteria that testers have to test against.
The software is necessarily complex due to legislative requirements, and the corpus of documentation the AI has access to just doesn't seem to capture the complexities and subtleties of the system and its related platforms.
I can churn out ACs quicker, but if I just move on to the next thing as if they're 'done' then quality is going to decline sharply. I'm currently entirely re-writing the first set of ACs it generated because the base premise was off.
This is both a prompt engineering and an availability-of-enough-context documentation problem, but both of those have fairly long learning curve work. Not many places do knowledge management very well, and so the requisite base information just may not be complete enough, and one missing 'patch' can very much change a lot of contexts.
I work with Australian tax - lots of regulatory complexity, add the documentation often assumes the reader is a CPA. I've got decent results by telling the chat bot to ask questions instead of making assumptions, and then grilling it to find edge cases.
I did a live demo in front of the CPAs, using their documentation, and Claude asked clarification questions they hadn't thought of and exposed gaps in the old manual processes.
To me, the cognitive debt incurred by Agentic AI described here is not so different from the cognitive debt incurred by code written by someone else. Even when you are the reviewer of your colleague’s code, you can’t just grok everything as if the code were written by you. What more to say if you are not even the reviewer.
And that’s okay! Much like it’s okay to let other people write the code.
What is important is that the code written by Agentic AI is covered by automated tests adequately, and that you verify that the architectural plan is solid. But then this is also what you do with your colleagues’/juniors’ code.
yes, from the point of view of an individual programmer, there is no difference between code created by AI or by some other programmer.
but from the point of view of the company as a whole there is a difference: code created by some programmer is understood by that programmer, while code created by AI is understood by nobody
> code created by some programmer is understood by that programmer
was at some point understood by that programmer, at least for a few months, before they moved on to something else and forgot important context and detail, or left the company
> High-performing teams have always managed technical debt intentionally.
The ability to generate code has seemingly transposed what people think of as a "high-performing team" from one that produces quality to one that produces quantity. With the short term gains obviously increasing long term technical debt.
Sometimes people make an assumption that every codebase has a team (or at least a single person) devoted to maintaining it. Companies with large codebases may not be able to afford that, or don't think it's worthwhile. You could have dozens or hundreds of libraries and only a few maintainers. The libraries are effectively "done" until something comes up. Work on them is interrupt-driven.
In that situation, coming in cold to a library that you haven't worked on before to make a change is the normal case, not "cognitive debt."
If you have common coding standards that all your libraries abide by, then it's much easier to dive into a new one.
Also, being able to ask an AI questions about an unfamiliar library might actually help?
Its more and more clear to me that AI is a force multiplier for small teams and hobby workflows, but seems to have diminishing returns for larger teams.
Smaller teams have more agency to move and usually team members with broader responsibility and understanding of the systems. Also possibly closer to stakeholders, so are already involved in specification creation and know where automation can add value. Add an AI agent and they can pick and choose where they can be most effective at a system level.
Bigger teams have clear boundaries that stop agency - blockers due to cross team dependencies, potentially no idea what stakeholders want, just piecemeal incremental change of a bigger system specified by someone else. If all they can do is automate that limited scope it's really just like faster typing.
That's the success case.
In the failure case you have emboldened, pressured teams jumping in to make a "quick fix" or "that feature we needed" in a codebase for a team they've never heard of, and leaders cheering it on in the name of progress.
Not every company is going to see those boundaries and stakeholders as features, and they'll be under pressure to "mitigate those blockers to execution". That's where the cognitive debt skyrockets.
But... as team size grows, LLMs can be more valuable in other ways. Larger teams typically have larger codebases to comprehend, more users, more bug reports to triage, etc. It's SO much easier to get up to speed on a big existing codebase now.
I'm currently working on a large project that was started by a 3rd-party vendor, then dumped onto the in-house team's lap due to an unforeseen financial pinch.
The vendor was basically right at the end of the "fun" part of cranking out features, and just about to hit the "rubber meets the road" part where you start fixing bugs, finding new edge cases, discovering new hidden requirements, and realizing X% of your design assumptions were completely wrong. Oh yeah, and minor little mop-up tasks that don't wow the client, like integrating with a payment processor, integrating with our internal scheduling system, exporting invitee lists from our CRM into our app, etc.
It's possible we're in a similar cognitive debt situation to having to maintain a large, swiftly-AI-coded app. After about 6 months of stressful development, which started with what I call throwing dye in the water and eventually progressed to understanding one small feature or flow at a time, we have maybe 50% of the mental model we'd have if we'd built the app ourselves. Whole chunks of the app are still a black box to us.
It doesn't help that requirements have evolved so much since the original documentation that it's worse than useless because we can't trust it. So the code, which we don't understand, is the only documentation of the current requirements.
Of course, our internal clients are pissed because the final product is taking so much longer than expected, when they could see all these awesome shiny, happy-path, 80%-done features 6 months ago. We're in a constant fire drill. Everyone on the project is miserable. It's the least fun kind of development.
The post makes some good points. As a programmer I love writing code. I know coding is just a tool but I enjoy the act of thinking about a problem, finding a solution and implementing it. It gives me a little dopamine boost.
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.
> 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”.
This exactly, has been the problem in cultures that have produced broken, lower quality things in general. Don't think deeply about the problem and don't think about the long term consequences. Just grab whatever solution gives some immediate solution the fastest. "Jugaar."
Many people are slipping into this culture now with the new pressure for immediate production pushed by the AI crowd. It's "jugaar." It's trading short term gain for long term breakage, chaos, and pain. It's also social and economic pressure to not do things properly.
Those who want to take the time time to really understand things, or to build things correctly are mocked or punished for being slow and simple minded. "Just do it this way, look everyone is doing it and making more money faster!" This is also part of that culture that drags everyone into jugaar.
I empathize with all of the above, but ive honestly felt that way more or less the moment I went from “programmer” to “founder” (I run a small startup since 2021, so a couple years before “agentic programming”). At some point I accepted this as the cost of working at a higher level of abstraction (and getting more done as a result, whether via a human employee or an LLM doing the work I used to do).
I know older devs that reminisce for the days of programming straight to the metal in assembly (e.g. on DOS or Amiga) and “knowing exactly what the computer is doing” which feels somehow familiar!
Even more familiar are senior devs moving to management (I know this isnt an original metaphor).
>Ever since LLMs started writing decent code, I started feeling like a part of that joy of code-writing has been taken away.
The SWEs that go all-in on AI will never understand this, because they have never enjoyed the joy of code-writing. I would even go as far as saying that many of them even hate it.
Of this group, I think the majority are the same people that have joined the industry not because of an innate love for engineering, but because they saw an opportunity to make big bucks in big tech.
Trying to curb and mitigate 'bad' practice through rigor and diligence is a sound reflex, but history has taught us time and time again it is not the restrained that come out on top, but the single digit percentage of those that threw caution to the wind, got lucky, and survived long enough to be a be to afford dealing with the 'debt' (still don't like that metaphor) in the future.
It’s a general principle. Complexity breeds complexity via a multitude of mechanisms thus growing exponentially. As complexity is also related to cost, this means, that there are two limits approached exponentially: financial (we can no longer afford complexity) and cognitive (ee can no longer understand). In an ideal world, financial barrier arrives first, as it is necessary to understand something to make it constructively simple. If it doesn’t, the only solution is destructive simplification by simply breaking the system into pieces forcefully. This is what Musk did to X and tried to do to the US Government.
AI is a force multiplier for whoever is using it. In the hands of a skilled practitioner, AI can be used effectively. In the hands of an idiot… watch out.
> the accumulated gap between a system’s evolving structure and a team’s shared understanding of how and why that system works and can be changed over time
That just sounds like everyone is going to be management. Blindly setting goals and demanding features of a black box, formerly the development team, soon to be 'AI' agents.
fwiw, understanding was never really the goal. calling it "debt" assumes all of it needs to be repaid, but most of the time this just feels like brain OOM. imo the skill is knowing what actually needs to stay in your head.
Edit: yep, I really do type this much. I'm a bit of a "thinking out loud" person.
> Cognitive Debt, Like Technical Debt, Must Be Repaid
In quite a few circumstances, cognitive debt doesn't entirely need to be repaid. I personally found with multiple projects that certain directions aren't the one I want to go in. But I only found it out after fully fleshing it out with Claude Code and then by using my own app realizing that certain things that I thought would work, they don't.
For example, I created library.aliceindataland.com (a narrative driven SQL course). After a while, I noticed that the grading scheme was off and it needed to be rewritten. The same goes for how I wanted to implement the cheatsheet, or lessons not following the standard format. Of course, I need to understand the new code but I don't need to understand the old code.
With other small forms of code, I just don't really need to know how things work because it's that simple. For example, every 5 minutes I track to which wifi network I'm connected with. It's mostly useful to simply know whether I went to the office that day or not. A python script retrieves the data and when I look at it, I can recognize that it's correct. But doing it this way is sure a lot faster than active recall.
At work, I've had similar things. At my previous job I created SEO and SEA tools for marketing experts. So I remember creating this whole app that gave experts insights into SEO things that Ahrefs and similar sites don't, as it was tailored to the data of the company I worked at. The feedback I basically got was: the data is great, the insights are necessary, but the way the app works is unusuable for us. I was a bit perplexed as I personally didn't find it that complicated. But I also know that I'm not the one using it. Then I created a second version and that was way more usable. The second version assumed a completely different front-end app and front-end app architecture though. All the cognitive debt of V1? No payback needed.
The reason that this is the case, as it seems to me, fall under a few categories:
1. Experimenting with technologies. If you have certain assumptions about how a technology works but it turns out you're wrong, or you learn through the process that an adjacent technology works way better, then you need to redo it. Back when coding by hand was such a thing, I had this with a collaborative drawing project called Doodledocs (2019). I didn't know if browsers supported pressure sensitivity and to what extent it was easy to implement. It required a few programming experiments.
2. It's a small and simple script, not much more to it.
3. Experimenting with usability. A lot of the time, we don't know how usable our app is. In my experience, this seems to be either because (1) it's a hobby project or (2) the UX people have been fired years ago. In these cases, more often than not, UX becomes an afterthought. But with LLMs, delivering a 95% fully working version is usually done within a week for a greenfield project. This 95% fully working version is an amazing high fidelity interaction prototype (95% no less). Once you do that for a few iterations, you then understand what you really need. Once you understand what you really need, then you can start repaying the cognitive debt.
I've found it's usually category 3, sometimes 2 and rarely 1.
> High-performing teams have always managed technical debt intentionally. As AI is adopted by startups and large companies, the question becomes how teams will manage cognitive debt.
"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!
Good article but it misses, for me, the core aspect of cognitive debt, by not doing the work you don’t learn anything.
There is no mitigation for writing code, no amount of reviewing or documentation will fix it, it’s just not how our brains work and how we learn things. We learn by doing, and by repetition, failure makes us repeat it, which is why it’s good to fail sometimes.
Carmack once wrote something I’ve been holding dear ever since, and I’m paraphrasing, ”even if you copy paste code, make sure you write it”. And it actually works, the outcome of just having your brain make your fingers type the code is easily differentiated from just pasting it.
As you said it's distributed across - People, conversations, AI agents , tooling, etc... , can't the LLM Knowledgebase/ wiki ( a.k.a. org's second brain) solve this ? I think if , second brain exists, no one needs to pay cognitive debt.
Why must so much gumflapping involve the spew of any words but those which encourage not using the clear problem tool more.
"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.
For my entire career, most of the people working on the systems I've worked on have not known how the systems work. Sometimes a few people learn a great deal about the system. They are spoken of in hushed tones, as one would a powerful mage, or witch. However, never in my entire career did anyone complain about the fact that nobody knew how the system worked. Most people never noticed it, much less cared once they found out. "This is just how things are. Business as usual."
AI is making people afraid as they run into these things. It's a little sad that they don't have the historical context or perspective to realize these are old problems. I imagine this is what Samurai felt like as flintlock guns came in and completely upended hundreds of years of martial tradition. How will they be able to defend themselves if they don't learn Kenjutsu? What will happen to our Bushido?
And I do think the fear is warranted. But I don't think people are going to act differently once they realize this unfortunate status quo hasn't yet led to the collapse of civilization, or their paychecks. Once the fear has passed, we will move on into the new normal, willfully ignorant and mildly disappointed.
>I always believe software wages shouldn't be more than a plumber or mechanic.
Wages in the trades have gone up a lot recently, at least where I'm from. Decades of parents telling their kids the trades are for losers lowering the supply of capable craftsmen...
And not all software will work as specialized tooling.
Calorie tracker apps? Sure.
Operating system kernels? Each with their own schedulers and allocators and ABIs and syscalls? Definitely not.
Am I the only one that is finding quite the opposite? I feel like a kid again, back when I had no responsibilities and infinite time to play around and build things. Being able to look at my existing tooling and say "there's a rough edge here" and then whip out the equivalent of a Milwaukee Bandfile [1] and smooth it out is making it fun to go to work again.
It's all fun and games, but I've yet to see anything of value come out of agentic coding. As in, all the code it produces is such total garbage, I'm not worries about the cognitive debt, I'm worried about the technical debt.
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.
bidirectional inverted commas, negative parallelism, short punchy prose, dot point listing ... these language techniques are consistently present throughout. whether this article was written by AI or not, its structure and style utterly screams of AI.
It is a bit surprising sometimes when you vibe code an AI tool and it ends up doing a bunch of regular expressions to "detect the user's intention". Instead of the code using an LLM to see which tool to run, or if they want to see the SQL or the code you end up seeing .*SQL or \i^build (or some crazy regex). It really likes to use a lot of regex when it's building AI tools.
Personally, my observation is that 'cognitive debt" feels closer to a tool for selling essays than a precise engineering concept.
Lack of documentation, failed onboarding, poor architectural understanding, missing tests, review fatigue.
if all of these are simply grouped together as “cognitive debt,” isn’t that just a failure to build a proper workflow?
The scope is too broad. It reminds me of Stepanov, the creator of the STL, saying that if everything is an object, then nothing is.
When an abstraction tries to cover too many things, that abstraction inevitably fails.
The way AI specifically amplifies this problem is through the difference between direct work and indirect work. The core issue is that “it works” can easily create the illusion that “I understand it.”
Another thing I felt while reading this essay is that it almost seems to go against the direction of modern software engineering. Once software grows beyond a certain size, it is already impossible for anyone except perhaps the original designer to understand the entire system. The goal is not for everyone to understand everything.
The real goal is to make local changes safely, and to ensure that the system keeps running without major disruption when one replaceable part — including a person — leaves.
At this point, many things being described in the industry as “cognitive debt' look to me like rhetorical tools for selling essays.
Reading this, I even wondered: if I write about trendy terms like cognitive debt or spec-driven development on my own blog, will people pay more attention?
To be honest, spec driven development has a similar issue. When you go from a specification down into implementation, information loss is inevitable. LLMs cannot fully solve that. In the end, a human supervisor still has to iterate several times and tune the result precisely. The real question should be: how far down should the specification go? In other words, at what local scope does it become faster for a human programmer to modify the code directly than to keep steering the AI-generated code?
But that discussion is often missing.
As people sometimes say, “when you start talking about Agile, it stops being agile.” In the same way, I think the “cognitive debt” frame may be a flawed abstraction of the current phenomenon.
The moment a living practice is nominalized, packaged, and turned into a consulting product, it loses its original dynamism and context-dependence, becoming a dead template.
It puts various discomforts that emerged after AI adoption — review burden, lack of understanding, fatigue — into a single box.
Then it attaches the economic metaphor of “debt” to emphasize the seriousness of the problem, and subtly injects the normative idea that “this must eventually be repaid.”
Thinking back to Parnas’s 1972 work on information hiding, software engineering was built on the principle that local understanding should be sufficient, and global understanding is not the goal.
The cognitive debt framing seems to implicitly reverse that principle by treating “shared understanding” as something that must be preserved as a global unit. I do not understand why the discussion keeps moving toward the idea that everything must be understood.
It reminds me of Bjarne’s onion metaphor for abstraction: if an abstraction works, you do not necessarily need to peel it apart without reason.
My main issue with the current cognitive debt framing is that the layer it tries to cover is too broad.
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’s literally not your job anymore. Your job is the keeper of the specification and care and feeding of the agents.
If you adopt the mindset that “I’m not going to build the documentation for me, I’m going to build it for the agent”, and “I’m not going to try to use my development skills to debug something I didn’t write, I’m going to make specific interfaces for the agent to understand the state and activity of the running code”, etc.- you’ll be a lot happier and more successful.
If you are using agents for autocomplete in your editor, or you open a separate chat window to ask a question about your code- that’s a very low level of agent usage and all your existing dev skills and responsibilities still apply.
If you’re using a planning framework like superpowers (the skill) and just laying out the spec for the program, then keep your fingers out of the source code, and don’t waste your time reading it. Have the agent explain it, showing you in the IDE, and make the agent make any changes you want.
This is correct, but it misses out an important dimension.
You can inject philosophy into the agent and ensure that it sticks to it. The LLM will, with sufficient drilling, begrudgingly implement it, most important of which is SIMPLE>COMPLEX on all levels and you have to either manually or agentically continuously monitor this.
Alternatively, LLM will use its tiny context window to build a true spaghetti that even itself cannot fix any more. This is the default path, and the path that way too many has taken.
> Alternatively, LLM will use its tiny context window to build a true spaghetti that even itself cannot fix any more.
And this is (probably) what is happening to the Claude Code product itself. The harness itself has regressed and is increasingly unstable. I get lots of weird glitches:
- I scroll back in the conversation and keep seeing the the same sections repeated, I am not actually able to see the earlier parts of the conversation because of this.
- The whole CLI UI glitches out such that you can't even make sense of what you are seeing. This is usually fixed by resizing the terminal window
- The previous edit in the conversation history gets lost when I escape it to provide direction
- The CLI sometimes consumes huge amounts of memory (more than 10GB per window, multiplied by the number of windows I'm working in)
- Etc
Not my experience at all. I’ve been using Claude Code on a large "hand written" project and it’s genuinely excellent at finding bugs and generating new methods or classes.
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.
Same experience here. It produces code that I would not accept if it was written by a human, but it also produces a lot of completely fine code. It made me clear tasks that I had been procrastinating for a long time.
tldr; agentic coding just works, you just have to put puny humans on a leash
Unfortunately I think Cognitive Debt is the cry of the software craftsperson who thought they were an Engineer. Upon working with the agent subcontractor, the agent factory, the agent part vendor, they approached it as a craft; they found themselves wanting to walk through the offices of the subcontractor reviewing screens, inspect pieces at the factory, and get the internal design for the parts they ordered. It's natural to get overwhelmed: this is why Engineers have contracts, specifications, design drawings, datasheets, and characterization data, handed over at clearly defined boundaries of abstraction, accepting the other side may be a black box.
Of course, we have had compilers and tooling, but those are the pencil and drafting board of the draftsperson. An ecosystem of packages, dependencies and APIs has evolved, but those are often just spells the software magician invokes after reading the spellbook^H^H^H^H^H^H^H^H^H stackoverflow^H^H^H^H^H^H^H^H^H^H^H^H^H API documentation.
We are going to need to build a new set of boundaries and abstractions with new handover protocols to manage this mess.
> this is why Engineers have contracts, specifications, design drawings, datasheets, and characterization data, handed over at clearly defined boundaries of abstraction
AND inspecting the actual production line. Even Apple audits Foxconn (the most successful and reliable assembly line humans ever built) onsite annually.
Because waterfall software engineering has been so successful, right? ;-)
Lots of very successful software was built using a waterfall approach. It's a methodology that works well if you know precisely what the end result needs to be. That doesn't make it appropriate for everything - if you don't know what the customer needs, or if you want to get an MVP out, then Agile works better, but you shouldn't dismiss an approach because it doesn't work everywhere.
Plus, 'agile' in quite a lot companies is really waterfall that's been broken into sprints without the planning of proper waterfall or the discovery and learning of real Agile. The software still gets built though. Maybe software is actually quite easy to plan.
Agilefall, the worst of both worlds.
Because agile has been so successful, right? ;)
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?
Agile cannot go over budget or scope because those are failures of planning. Agile is the methodology that was developed specifically to counteract those problems with planning. Projects that use Agile can go over budget and scope but they never do that because they are using Agile, rather they use Agile because they might do that.
It always felt like Agile is the lazy attempt of people unwilling to learn what it takes to build software, to make it more predictable. Unfortunately project planning methods that work for buildings are not really great for software. It's just corpo stuff project managers do to feel meaningful.
It used to fail once after a long time, now software fails a lot every 2 weeks.
They cloned one true scottsmann in the end..
If the idea does not compute with human nature, the idea is flawed, its basis the knowledge of human nature is non-existent and thus it had no place in reality after all..
Hmm that reminds me of what some people say about communism :)
Waterfall was also extremely successful.
People who failed just did it wrong. /s
Agile fails when folks don't adjust and tailor the process to the specific needs of their team or organization but instead try to cargo cult it.
so it's called agile when it works, but not when it doesn't, got it!
No, “it’s” adaptive and if you’re not adaptive then you’re quite literally not doing “it”.
Adaptive methods aren’t something unique to Agile, it’s an aspect found in basic business methodologies and processes. Very basic, textbook stuff. So when software types start grumping about their dysfunctional organizations and blaming methods they aren’t actually applying, it isn’t an indictment of the method and never can be.
If “Adaptive Heat Cycle 3.5” is a process where we turn down the thermostat when we’re too hot, and up when we’re too cold, based on a vote every 20 min: a bunch of sweaty people who are not voting and not changing the temp and lying about their needs because their boss sucks are not using the process. The fact they claim they are is only further proof of dysfunction and incompetence.
Agile has a built in solution to all agile complaints: the agile process where you fix the problem. No fix? Not agile. Blame the cargo cult players, not the rules.
You gotta understand how to use a tool for it to be effective, yes.
And if a tool is that difficult to use, how can you tell if the problem is in the tool or the user? There's a large industry built around doing training and certifications in agile methodologies now. If a tool is that difficult to get right, maybe it's just not a good tool to begin with.
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.
So the widespread existence of business programs, certification and training heavy, obviously proves every project and business methodology is “bad” and the problem is the tool of “business methodologies”?
PRINCE2, for example, is constantly fumbled and misunderstood by immature juniors. They don’t get it, and screw it up. So… what? Haphazard planning and last minute project detonations must replace any effort to avoid such outcomes?
It’s chicken and egg. You have screwups who can’t manage and think wrong, so you formalize rules so dummies can’t hurt leadership, and then you have to train people. A stunning number fail to ‘get it’, suck at management, and do what they feel with justifications instead of following the book. That’s standard distribution at play.
Blaming methods for basic management failures is a management and culture failure. “I’ve never seen [agile] implemented correctly” is saying you didn’t fix communication issues. That’s fine, that’s hard. But that’s a meatspace issue, not process.
I am not sure how you jumped from what I said to this. I don't believe I claimed that every project and business methodology is bad. I can only speak from my experience and am not confident enough to say how every project and business methodology should or shouldn't work.
I do believe you are helping to make my point though. I am saying that the process may very well be perfection but if entities within "meatspace" cannot use it well and may never be able to use it well then how useful really is it.
As if anything in the world is ever pure. Waterfall can have small scrums run on side-shows, while staying waterfally on the center project.
There is no party capable to take responsibility on the other side of the handover protocol.
Yes, this is the thing - an agent is not a counter party. But it role plays one really well.
You would need the agent to be a processing step owned by someone responsible. But the intelligent part of an agent is what makes it viable as something more than a processing step. What to do with an intelligence that can't take responsibility? Not answering this question leads to cognitive debt.
> 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 pushed the way it is being pushed. I have more than a few conversations where people have clearly expressed that they are mostly focused on keeping their jobs. They don’t care about cognitive debt and some are looking forward to the time when the debt comes due.
It is depressing, but it is the reality.
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.
If the default mode is that LLMs generate crap code that you have to fix with even more LLMs, then something is fundamentally wrong.
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.
The default mode of the whole startup world is humans generate crap code that you have to fix with even more humans. And it has been like that for at least two decades.
And we learned nothing of previous hype cycles.
Enshitification in this area will be shift. And there will be grand articles here on HN “nobody could possibly have seen this coming.” Yes we did.
Meh, enshitification is the same, it just happen faster.
Which means the stuff that replace it will also happen faster.
Overall, the quality of the software is likely similar, since AI do not have purpose, and software still largely reflect human will and thinking.
Exactly what I’m hearing and feeling too. Devs I know are just going with it so they still have a job. No one cares about quality anymore it’s just a race to output as much code as possible. And when there’s docs, it’s just whatever slop they can have an llm output so it appears to their managers that won’t read it that they did work.
I think the antidote is ownership. Every part of a company or product needs some person or small group that owns it, understands it, and feels ownership over its long-term health. They review or decide what level of review changes to it can take.
So much of what makes high-functioning teams work is a sense of ownership and stewardship, and what makes low-functioning teams break is a lack thereof. Someone with pride, drive, and a high standard feeling responsible for a particular area or thing.
In the past, that ownership could be individual or collective, but with AI and a lot more lane-crossing, ownership should tend toward smaller groups (or individuals).
A developer can design, but a designer needs to review it. A designer can code, but the owner of the code must review it.
This might feel like gatekeeping, but it's the only way.
Fortunately, the widespread use of LLMs results in companies reducing the number of things each team owns, and/or leaving lots of engineers on payroll who suddenly have abundant free time with which to start self-learning and developing a sense of ownership of parts of the product.
Wait...
I agree but don't see it working out. Ownership implies that a person or a team becomes irreplaceable or at least more difficult to replace. People stop being resources and go back to being people. Management is not going to like that.
At one business I was a part of where that experiment was tried, it failed badly. In reality, people were being switched around on projects and the "owner" was changing every few months. The end result was quite messy, both in terms of technical debt and politics(about who's the final decision maker).
What you need is ownership of not just the code but ownership of the company if your work is your own then you care a lot more about then if it belongs to someone else.
>I think the antidote is ownership.
I've said this before, but people gloss over this fact.
>Someone with pride, drive, and a high standard feeling responsible for a particular area or thing.
I've also said this before, but AI-glazers just respond with "I think we may just have to let go of pride & kudos and their connection to our identity."
Most people who vibecode don't give a shit about their work. Any solution is a solution as long as it works.
>This might feel like gatekeeping, but it's the only way.
Gatekeeping is not inherently bad. We want gatekeeping.
If I'm getting surgery, I want an actual doctor with proven credentials to do it.
And to anyone claiming that software doesn't kill, please look up "Therac-25" or the 65 people that died due to Tesla's "Full Self-Driving".
Of course there are examples of software killing or being capable of killing (operating machinery or medical devices), but that doesn't apply to probably 90+% of software
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.
Now we all know horrible mangers who didn't keep up to date nor used their thinking. This will happen with AI useage too. What is more we are expecting people who are engineers to have a manager's mindset (by managing AI agents, products requirements, etc). Many engineers are horrible at this and have no desires or ability to become a manager. This is why they went to engineering in the first place.
>Many engineers are horrible at this and have no desires or ability to become a manager. This is why they went to engineering in the first place.
Bingo. If I wanted to spend my life managing incompetent sycophants, I would've studied for an MBA to try to rise the ranks at McKinsey.
While this isn't a unique perspective, I think it's wild more people don't understand this. What happened is everyone is being "promoted" to staff+ level engineer and they're realizing the realities of that situation.
The funny part is that these are the same people who are upset that these folks up the food chain "do nothing".
If you’re a manager you have people under you that care about the code they write and the direction of the company, not typewriter monkeys.
They're being "promoted" without any kind of extra income, only elevated expectations and responsibilities
So no wonder people aren't happy
This is true; as smarter people than me have said, software engineering is programming over time, and that time aspect involves individuals knowing less and less of a codebase. But that's what these smart people are advocating, in order to keep code maintainable, you need to stick to some rules, processes, patterns, etc.
Whether you apply those things to other developers or LLMs is a bit moot I think, ultimately neither (or you yourself) can be fully trusted to know and understand the full system.
This, and I would even say we are promoting people to be kings and queens. I'm afraid AI will amplify our worst parts because they are ultimately sycophants. I've heard so many things about AI enabling a single person to run a billion dollar business. But I believe without the right mindset/discipline, a person cannot go too far with any technology.
I'm consistently surprised by how many "software engineers" I've worked with have never read Naur's paper (https://pages.cs.wisc.edu/~remzi/Naur.pdf) or not even familiar with this notion before agentic coding. This was always a reality in our discipline whether folks realized it or now.
Struck a cord, and I think I managed this prior to LLM in a certain degree.
My primary editor is vim, and for a significant amount of time I was using it almost in puritan fashion, this was before LLM was mainstream.
However, I could not use vim to edit java, even with language server - I tried, but each time I went back to intellij - the rest of the code base in python, ruby and typescript was typically fine.
The reason was two fold, because everyone was using all of the features that intellij had to offer, the code was structured similar to intellij and obviously the java design patterns that was popular at the time. Everything went through factories and managers and interfaces and tracking them through a pure editor was almost impossible. The IDE handled it for you.
But everything else? Things I or others had to build from ground up was built with this cognitive limitation in mind, which means I can fit everything nicely and edit with vim, even without a language server with high efficiency.
Those cognitive limitation is good for the software. It's easy to explain, easy to debug, easy to add and subtract. And I've come to disregard the intellij way, or the current vibe coding till it works that is common everywhere now. The principle is KISS - keep it simple stupid. If AI will not do that, then you have to. It is a simple philosophical question that is more important than ever. And sadly most people still don't realize it - they will happily tack on the next "feature" in with the scaling they didn't need at that time with the design pattern that they don't need at the time and prematurely optimize themselves into cognitive and technical bankruptcy.
I find it disconcerting that an article about cognitive debt contains many "tells" of being written by AI.
Independent of that, the article is just a summary of a HN thread...
I had the same reaction, but the article is not AI-generated according to pangram, which I've generally found reliable. I wonder if LLM turns of phrase and even thought patterns are creeping into normal human thought.
Or, stay with me here, the LLMs were trained on how we, statistically, write.
There are typical LLM voices and styles, just like human writers have differentiated voices and styles. And some common elements of the typical LLM style are distinct from humans I've previously read.
I recognize this. It's also the case that I suspect that I've read more about how annoying suspected LLM output is to read than I have read LLM output. The slop is, to me, an incredibly unwelcome contribution of humans that don't enjoy the craft but complaining about it is equally stuck in and further exacerbating the froth rather than distilling down to the substance. That is it keeps the focus on the surface rather than on what the core content is and whether it has value.
LLM writing doesn’t have substance, it’s statistically likely text generated from some bullet points, without intention or style.
When you say "we" you're talking about Twitter, right?
Anytime I see “this is not just x, it’s y” i can almost guarantee with high degree of confidence that slop was used.
As someone from outside the Anglophone cultural sphere, when I first learned to write in English, the kind of writing that AI now often produces was taught to me as “formal" writing.
But these days, when I write in that formal style, people sometimes say it sounds like AI. That has been a difficult and frustrating point for me.
I still find the subtle difference hard to understand.
I was raised and educated well inside the Anglosphere (USA) and was also taught to write formally in that way.
Do the people who say you sound like AI give you any specifics?
Also, if you don't mind, what was your English education like? I understand that quite a few Americans work in South Korea as teachers but I have no details about how that manifests.
That used to happen to me more often. When I first came to HN, and even now if I am not careful, my comments can get flagged. Also, when I translate from Korean using DeepL and paste the result, people often say it sounds flagged, awkward, or unnatural. I studied English more seriously in graduate school, although I dropped out. In Korea, there are quite a few Americans who teach English. Public schools often have native English-speaking instructors, but in my case I learned English more seriously at graduate school, and universities also make students study English almost semi-compulsorily.
In Seoul, there are probably many teachers who mainly teach middle and high school students, but a lot of that is through private education rather than the public school system.
I'm still pissed that I had to practice removing that from my writing habits. I liked that device, dammit!
It's not just AI-generated, it's also slop!
It's worth mentioning pangram is more confident in it's positive detections than it's negative ones, as stated by the founder in an interview on the most recent ThursdAI episode
I think its bidirectional. We change our writing based on what we see (AI generated content on the internet) and AI will learn based on what we write.
These sorts of articles just seem silly to me. Use AI where it helps you and avoid where it doesn't. That dividing line may change week to week.
I think it's great for writing tests and sanity checking changes but wouldn't let it write core driver code(I'm a systems programmer so YMMV). Maybe in a month I'll think differently.
Using a tool as a tool is hard when the market is telling you to use it in everything as if it’s the new sliced bread.
It worked for bread. Why wouldn't it work for AI? I've been baking allen wrenches and screws into my sliced bread for ages, and no single living person has complained about it.
>Use AI where it helps you and avoid where it doesn't
When all you've got is a hammer...
...you'll eventually stop knowing how to use other tools.
I worry about these remediation measures. The problem described is that the increased reliance on AI has increased cognitive debt, and the solution is to write tests that better capture intent and to update design documents continuously. But the people with cognitive debt problems that got there by using AI are also going to be using AI to write tests that "capture intent better" and using AI to update design documents. And while, sure, those are good things for your agents to be doing just for the sake of the effectiveness of those same agents, it's also not going to help you get out of the cognitive debt spiral.
Just reading the first paragraph and I've already started to experience it when attempting to apply AI to Acceptance Criteria that testers have to test against.
The software is necessarily complex due to legislative requirements, and the corpus of documentation the AI has access to just doesn't seem to capture the complexities and subtleties of the system and its related platforms.
I can churn out ACs quicker, but if I just move on to the next thing as if they're 'done' then quality is going to decline sharply. I'm currently entirely re-writing the first set of ACs it generated because the base premise was off.
This is both a prompt engineering and an availability-of-enough-context documentation problem, but both of those have fairly long learning curve work. Not many places do knowledge management very well, and so the requisite base information just may not be complete enough, and one missing 'patch' can very much change a lot of contexts.
I work with Australian tax - lots of regulatory complexity, add the documentation often assumes the reader is a CPA. I've got decent results by telling the chat bot to ask questions instead of making assumptions, and then grilling it to find edge cases.
I did a live demo in front of the CPAs, using their documentation, and Claude asked clarification questions they hadn't thought of and exposed gaps in the old manual processes.
To me, the cognitive debt incurred by Agentic AI described here is not so different from the cognitive debt incurred by code written by someone else. Even when you are the reviewer of your colleague’s code, you can’t just grok everything as if the code were written by you. What more to say if you are not even the reviewer.
And that’s okay! Much like it’s okay to let other people write the code.
What is important is that the code written by Agentic AI is covered by automated tests adequately, and that you verify that the architectural plan is solid. But then this is also what you do with your colleagues’/juniors’ code.
yes, from the point of view of an individual programmer, there is no difference between code created by AI or by some other programmer.
but from the point of view of the company as a whole there is a difference: code created by some programmer is understood by that programmer, while code created by AI is understood by nobody
> code created by some programmer is understood by that programmer
was at some point understood by that programmer, at least for a few months, before they moved on to something else and forgot important context and detail, or left the company
> High-performing teams have always managed technical debt intentionally.
The ability to generate code has seemingly transposed what people think of as a "high-performing team" from one that produces quality to one that produces quantity. With the short term gains obviously increasing long term technical debt.
Sometimes people make an assumption that every codebase has a team (or at least a single person) devoted to maintaining it. Companies with large codebases may not be able to afford that, or don't think it's worthwhile. You could have dozens or hundreds of libraries and only a few maintainers. The libraries are effectively "done" until something comes up. Work on them is interrupt-driven.
In that situation, coming in cold to a library that you haven't worked on before to make a change is the normal case, not "cognitive debt."
If you have common coding standards that all your libraries abide by, then it's much easier to dive into a new one.
Also, being able to ask an AI questions about an unfamiliar library might actually help?
Its more and more clear to me that AI is a force multiplier for small teams and hobby workflows, but seems to have diminishing returns for larger teams.
How so? Could you give some specific examples?
My experience moving between startup/SME/corp:
Smaller teams have more agency to move and usually team members with broader responsibility and understanding of the systems. Also possibly closer to stakeholders, so are already involved in specification creation and know where automation can add value. Add an AI agent and they can pick and choose where they can be most effective at a system level.
Bigger teams have clear boundaries that stop agency - blockers due to cross team dependencies, potentially no idea what stakeholders want, just piecemeal incremental change of a bigger system specified by someone else. If all they can do is automate that limited scope it's really just like faster typing.
That's the success case. In the failure case you have emboldened, pressured teams jumping in to make a "quick fix" or "that feature we needed" in a codebase for a team they've never heard of, and leaders cheering it on in the name of progress.
Not every company is going to see those boundaries and stakeholders as features, and they'll be under pressure to "mitigate those blockers to execution". That's where the cognitive debt skyrockets.
I agree with the agency aspect.
But... as team size grows, LLMs can be more valuable in other ways. Larger teams typically have larger codebases to comprehend, more users, more bug reports to triage, etc. It's SO much easier to get up to speed on a big existing codebase now.
Ah, I feel what you're saying. Yea that makes total sense.
Small teams prioritize expertise and agency.
Large teams prioritize service resilience and depth of coverage.
I'm currently working on a large project that was started by a 3rd-party vendor, then dumped onto the in-house team's lap due to an unforeseen financial pinch.
The vendor was basically right at the end of the "fun" part of cranking out features, and just about to hit the "rubber meets the road" part where you start fixing bugs, finding new edge cases, discovering new hidden requirements, and realizing X% of your design assumptions were completely wrong. Oh yeah, and minor little mop-up tasks that don't wow the client, like integrating with a payment processor, integrating with our internal scheduling system, exporting invitee lists from our CRM into our app, etc.
It's possible we're in a similar cognitive debt situation to having to maintain a large, swiftly-AI-coded app. After about 6 months of stressful development, which started with what I call throwing dye in the water and eventually progressed to understanding one small feature or flow at a time, we have maybe 50% of the mental model we'd have if we'd built the app ourselves. Whole chunks of the app are still a black box to us.
It doesn't help that requirements have evolved so much since the original documentation that it's worse than useless because we can't trust it. So the code, which we don't understand, is the only documentation of the current requirements.
Of course, our internal clients are pissed because the final product is taking so much longer than expected, when they could see all these awesome shiny, happy-path, 80%-done features 6 months ago. We're in a constant fire drill. Everyone on the project is miserable. It's the least fun kind of development.
The post makes some good points. As a programmer I love writing code. I know coding is just a tool but I enjoy the act of thinking about a problem, finding a solution and implementing it. It gives me a little dopamine boost.
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.
> 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”.
This exactly, has been the problem in cultures that have produced broken, lower quality things in general. Don't think deeply about the problem and don't think about the long term consequences. Just grab whatever solution gives some immediate solution the fastest. "Jugaar."
Many people are slipping into this culture now with the new pressure for immediate production pushed by the AI crowd. It's "jugaar." It's trading short term gain for long term breakage, chaos, and pain. It's also social and economic pressure to not do things properly.
Those who want to take the time time to really understand things, or to build things correctly are mocked or punished for being slow and simple minded. "Just do it this way, look everyone is doing it and making more money faster!" This is also part of that culture that drags everyone into jugaar.
I empathize with all of the above, but ive honestly felt that way more or less the moment I went from “programmer” to “founder” (I run a small startup since 2021, so a couple years before “agentic programming”). At some point I accepted this as the cost of working at a higher level of abstraction (and getting more done as a result, whether via a human employee or an LLM doing the work I used to do).
I know older devs that reminisce for the days of programming straight to the metal in assembly (e.g. on DOS or Amiga) and “knowing exactly what the computer is doing” which feels somehow familiar!
Even more familiar are senior devs moving to management (I know this isnt an original metaphor).
>Ever since LLMs started writing decent code, I started feeling like a part of that joy of code-writing has been taken away.
The SWEs that go all-in on AI will never understand this, because they have never enjoyed the joy of code-writing. I would even go as far as saying that many of them even hate it.
Of this group, I think the majority are the same people that have joined the industry not because of an innate love for engineering, but because they saw an opportunity to make big bucks in big tech.
I see it the other way, I can do whatever creative and fun stuff I like, and the agent does the boring debugging or finishing up my loose ends.
Trying to curb and mitigate 'bad' practice through rigor and diligence is a sound reflex, but history has taught us time and time again it is not the restrained that come out on top, but the single digit percentage of those that threw caution to the wind, got lucky, and survived long enough to be a be to afford dealing with the 'debt' (still don't like that metaphor) in the future.
It’s a general principle. Complexity breeds complexity via a multitude of mechanisms thus growing exponentially. As complexity is also related to cost, this means, that there are two limits approached exponentially: financial (we can no longer afford complexity) and cognitive (ee can no longer understand). In an ideal world, financial barrier arrives first, as it is necessary to understand something to make it constructively simple. If it doesn’t, the only solution is destructive simplification by simply breaking the system into pieces forcefully. This is what Musk did to X and tried to do to the US Government.
AI is a force multiplier for whoever is using it. In the hands of a skilled practitioner, AI can be used effectively. In the hands of an idiot… watch out.
Most people are idiots.
> the accumulated gap between a system’s evolving structure and a team’s shared understanding of how and why that system works and can be changed over time
That just sounds like everyone is going to be management. Blindly setting goals and demanding features of a black box, formerly the development team, soon to be 'AI' agents.
I mean that's already happened. Everyone is expected to be a manager of agents. Anyone not doing this is programming for hobby.
fwiw, understanding was never really the goal. calling it "debt" assumes all of it needs to be repaid, but most of the time this just feels like brain OOM. imo the skill is knowing what actually needs to stay in your head.
As the [newly popular] saying goes: > you can outsource your thinking, but you cannot outsource your understanding
Edit: yep, I really do type this much. I'm a bit of a "thinking out loud" person.
> Cognitive Debt, Like Technical Debt, Must Be Repaid
In quite a few circumstances, cognitive debt doesn't entirely need to be repaid. I personally found with multiple projects that certain directions aren't the one I want to go in. But I only found it out after fully fleshing it out with Claude Code and then by using my own app realizing that certain things that I thought would work, they don't.
For example, I created library.aliceindataland.com (a narrative driven SQL course). After a while, I noticed that the grading scheme was off and it needed to be rewritten. The same goes for how I wanted to implement the cheatsheet, or lessons not following the standard format. Of course, I need to understand the new code but I don't need to understand the old code.
With other small forms of code, I just don't really need to know how things work because it's that simple. For example, every 5 minutes I track to which wifi network I'm connected with. It's mostly useful to simply know whether I went to the office that day or not. A python script retrieves the data and when I look at it, I can recognize that it's correct. But doing it this way is sure a lot faster than active recall.
At work, I've had similar things. At my previous job I created SEO and SEA tools for marketing experts. So I remember creating this whole app that gave experts insights into SEO things that Ahrefs and similar sites don't, as it was tailored to the data of the company I worked at. The feedback I basically got was: the data is great, the insights are necessary, but the way the app works is unusuable for us. I was a bit perplexed as I personally didn't find it that complicated. But I also know that I'm not the one using it. Then I created a second version and that was way more usable. The second version assumed a completely different front-end app and front-end app architecture though. All the cognitive debt of V1? No payback needed.
The reason that this is the case, as it seems to me, fall under a few categories:
1. Experimenting with technologies. If you have certain assumptions about how a technology works but it turns out you're wrong, or you learn through the process that an adjacent technology works way better, then you need to redo it. Back when coding by hand was such a thing, I had this with a collaborative drawing project called Doodledocs (2019). I didn't know if browsers supported pressure sensitivity and to what extent it was easy to implement. It required a few programming experiments.
2. It's a small and simple script, not much more to it.
3. Experimenting with usability. A lot of the time, we don't know how usable our app is. In my experience, this seems to be either because (1) it's a hobby project or (2) the UX people have been fired years ago. In these cases, more often than not, UX becomes an afterthought. But with LLMs, delivering a 95% fully working version is usually done within a week for a greenfield project. This 95% fully working version is an amazing high fidelity interaction prototype (95% no less). Once you do that for a few iterations, you then understand what you really need. Once you understand what you really need, then you can start repaying the cognitive debt.
I've found it's usually category 3, sometimes 2 and rarely 1.
> High-performing teams have always managed technical debt intentionally. As AI is adopted by startups and large companies, the question becomes how teams will manage cognitive debt.
"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.
Good article but it misses, for me, the core aspect of cognitive debt, by not doing the work you don’t learn anything. There is no mitigation for writing code, no amount of reviewing or documentation will fix it, it’s just not how our brains work and how we learn things. We learn by doing, and by repetition, failure makes us repeat it, which is why it’s good to fail sometimes.
Carmack once wrote something I’ve been holding dear ever since, and I’m paraphrasing, ”even if you copy paste code, make sure you write it”. And it actually works, the outcome of just having your brain make your fingers type the code is easily differentiated from just pasting it.
As you said it's distributed across - People, conversations, AI agents , tooling, etc... , can't the LLM Knowledgebase/ wiki ( a.k.a. org's second brain) solve this ? I think if , second brain exists, no one needs to pay cognitive debt.
Why must so much gumflapping involve the spew of any words but those which encourage not using the clear problem tool more.
"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.
For my entire career, most of the people working on the systems I've worked on have not known how the systems work. Sometimes a few people learn a great deal about the system. They are spoken of in hushed tones, as one would a powerful mage, or witch. However, never in my entire career did anyone complain about the fact that nobody knew how the system worked. Most people never noticed it, much less cared once they found out. "This is just how things are. Business as usual."
AI is making people afraid as they run into these things. It's a little sad that they don't have the historical context or perspective to realize these are old problems. I imagine this is what Samurai felt like as flintlock guns came in and completely upended hundreds of years of martial tradition. How will they be able to defend themselves if they don't learn Kenjutsu? What will happen to our Bushido?
And I do think the fear is warranted. But I don't think people are going to act differently once they realize this unfortunate status quo hasn't yet led to the collapse of civilization, or their paychecks. Once the fear has passed, we will move on into the new normal, willfully ignorant and mildly disappointed.
I may get downvoted for this but
I don't agree that demand for software guys will drop.
What I think is, demand for software people will go up while wages will be suppressed. And more software will be in the market as a whole.
There are so many craftsmen in market who hardly make liveable wage, select few make a bank! Same pattern will repeat in software.
Mass market software with large-scale adoption will drop. And specialised tools and services will take its place.
Which means 1000s of calorie trackers, 1000s of image editors, etc... but as scale will drop, income and revenue of companies will also drop.
Software wages are an anomaly in select countries; I always believe software wages shouldn't be more than a plumber or mechanic.
>I always believe software wages shouldn't be more than a plumber or mechanic.
Wages in the trades have gone up a lot recently, at least where I'm from. Decades of parents telling their kids the trades are for losers lowering the supply of capable craftsmen...
And not all software will work as specialized tooling.
Calorie tracker apps? Sure.
Operating system kernels? Each with their own schedulers and allocators and ABIs and syscalls? Definitely not.
We keep talking about AI fatigue and burnout.
Am I the only one that is finding quite the opposite? I feel like a kid again, back when I had no responsibilities and infinite time to play around and build things. Being able to look at my existing tooling and say "there's a rough edge here" and then whip out the equivalent of a Milwaukee Bandfile [1] and smooth it out is making it fun to go to work again.
[1] https://www.milwaukeetool.com/products/details/m12-fuel-1-2-...
It's all fun and games, but I've yet to see anything of value come out of agentic coding. As in, all the code it produces is such total garbage, I'm not worries about the cognitive debt, I'm worried about the technical debt.
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.
Was this article written by AI?
I'd bet a lot of money on AI at least having a substantial influence on the phrasing.
bidirectional inverted commas, negative parallelism, short punchy prose, dot point listing ... these language techniques are consistently present throughout. whether this article was written by AI or not, its structure and style utterly screams of AI.
But which was the first, the chicken or the egg?
The LLMs have been trained on soulless corporate speak.
It is a bit surprising sometimes when you vibe code an AI tool and it ends up doing a bunch of regular expressions to "detect the user's intention". Instead of the code using an LLM to see which tool to run, or if they want to see the SQL or the code you end up seeing .*SQL or \i^build (or some crazy regex). It really likes to use a lot of regex when it's building AI tools.
mythical man month covered this
The most important lesson from Gen AI is that it does not matter how much money you have, make, lose, or spend because in the long run everyone is…
So the logical next step is to focus on Biological Immortality and short of that Digital Immortality. God speed everyone.
Personally, my observation is that 'cognitive debt" feels closer to a tool for selling essays than a precise engineering concept.
Lack of documentation, failed onboarding, poor architectural understanding, missing tests, review fatigue. if all of these are simply grouped together as “cognitive debt,” isn’t that just a failure to build a proper workflow?
The scope is too broad. It reminds me of Stepanov, the creator of the STL, saying that if everything is an object, then nothing is.
When an abstraction tries to cover too many things, that abstraction inevitably fails.
The way AI specifically amplifies this problem is through the difference between direct work and indirect work. The core issue is that “it works” can easily create the illusion that “I understand it.”
Another thing I felt while reading this essay is that it almost seems to go against the direction of modern software engineering. Once software grows beyond a certain size, it is already impossible for anyone except perhaps the original designer to understand the entire system. The goal is not for everyone to understand everything.
The real goal is to make local changes safely, and to ensure that the system keeps running without major disruption when one replaceable part — including a person — leaves.
At this point, many things being described in the industry as “cognitive debt' look to me like rhetorical tools for selling essays.
Reading this, I even wondered: if I write about trendy terms like cognitive debt or spec-driven development on my own blog, will people pay more attention?
To be honest, spec driven development has a similar issue. When you go from a specification down into implementation, information loss is inevitable. LLMs cannot fully solve that. In the end, a human supervisor still has to iterate several times and tune the result precisely. The real question should be: how far down should the specification go? In other words, at what local scope does it become faster for a human programmer to modify the code directly than to keep steering the AI-generated code?
But that discussion is often missing.
As people sometimes say, “when you start talking about Agile, it stops being agile.” In the same way, I think the “cognitive debt” frame may be a flawed abstraction of the current phenomenon.
The moment a living practice is nominalized, packaged, and turned into a consulting product, it loses its original dynamism and context-dependence, becoming a dead template.
It puts various discomforts that emerged after AI adoption — review burden, lack of understanding, fatigue — into a single box.
Then it attaches the economic metaphor of “debt” to emphasize the seriousness of the problem, and subtly injects the normative idea that “this must eventually be repaid.”
Thinking back to Parnas’s 1972 work on information hiding, software engineering was built on the principle that local understanding should be sufficient, and global understanding is not the goal.
The cognitive debt framing seems to implicitly reverse that principle by treating “shared understanding” as something that must be preserved as a global unit. I do not understand why the discussion keeps moving toward the idea that everything must be understood.
It reminds me of Bjarne’s onion metaphor for abstraction: if an abstraction works, you do not necessarily need to peel it apart without reason.
My main issue with the current cognitive debt framing is that the layer it tries to cover is too broad.