Organizational Cognitive Debt Was the Warning. Personal Cognitive Debt Is the Multiplier

Two debts, not one

The first is organizational: the accumulated cost of decisions nobody wrote down. Architecture choices, tradeoffs, the reason a team picked one pattern over another three years ago: all of it evaporates the moment the person who made the call moves to a different project, and the next engineer inherits the outcome without the reasoning. This isn't new, and AI didn't cause it - it's been building in every engineering org for as long as engineering orgs have existed.

The second is personal, and it's newer: the erosion of an individual's own judgment when decision-making gets handed to AI tools by default rather than by choice. A 2026 peer-reviewed study from Carnegie Mellon and Stanford researchers, presented at CHI - one of the field's top venues - found that LLM access measurably reduced critical thinking performance on realistic reasoning tasks. It echoes an earlier, larger pattern: a 666-participant study out of SBS Swiss Business School found a strong negative correlation between AI reliance and critical thinking scores, with cognitive offloading identified as the driving mechanism. The most vivid evidence of how comes from a widely-discussed (if still preprint) MIT Media Lab study: participants who wrote essays with an LLM's help showed measurably weaker neural connectivity than those who wrote unaided or used a search engine, and recalled less of what they'd supposedly just written. The tradeoff is straightforward, and very human: the easier it is to let a model draft the decision, the less practice a person gets making one… and the less equipped they are to catch it when the model gets it wrong.

Many of the articles I’ve seen treat these as two individual categories - one for engineering leads, one for HR and/or a general commentary on the impacts on today’s workforce. When considered together, they describe something far worse: a team that already can't explain its own architecture is now also losing the individual capacity to interrogate the decisions AI is increasingly making that modify that architecture on their behalf. The debt that was accumulating slowly for a decade is now compounding against a second, much faster-accruing debt that didn't exist five years ago. I haven’t found anyone writing about this that is naming the interaction between these forces directly. Most of the content out there is still focused on awareness - people describing the erosion from one or the other, but not the compounding effects.

Why the obvious fix doesn't work

The instinct is to respond with culture: better documentation habits, more thorough code review, a Slack reminder to "write it down." Cognitive Debt isn't a culture problem. It's a documentation architecture problem. Culture fixes rely on someone remembering to do the right thing under deadline pressure, every time, forever. Architecture fixes don't ask anyone to remember anything - the capture happens right inside the workflow, or it doesn't happen at all.

This isn't new - it's an old idea that just got more urgent

Decision Records aren't something recently invented. Michael Nygard wrote the original case for Architecture Decision Records way back in 2011; Martin Fowler and the wider engineering community have carried the practice forward since. The extended field set, including pros and cons weighed per option, not just the winner - follows MADR, the community's own name for this type of record. The practice has existed, quietly, for fifteen years, mostly as a discipline that well-run teams adopted and everyone else meant to get around to.

The value of the practice hasn’t changed, but the cost of skipping it is now collecting interest at a much higher rate. When a human wrote every line, an undocumented decision was recoverable… slow to reconstruct, but recoverable - because a person could still explain their own reasoning if you asked them to. When an AI agent is generating a meaningful share of the code, that recovery path disappears. Nobody can explain a rationale that was never articulated in the first place, including the tool that wrote it, even if that tool hasn’t undergone massive cognitive engine upgrades since it made the decision in the first place.

That's the actual argument for calling this something more specific than "keep better docs." I've spent more than a decade advising engineering organizations across a global agency network and watching teams mature - or fail to - on exactly this axis: all had good engineers, but the reasoning behind their engineering decisions may not have survived past the person who made them. This is especially acute in marketing agencies, who I spent two decades of my career advising. Code and finished products are frequently handed off to clients, and team membership is regularly broken and recreated in order to meet the exact and diverse needs of the next project for clients across many unrelated industries. 

One team I advised had passed through three team reconfigurations before the client approved the scope for a second phase, and no one could explain why a core integration was built the way it was without tracking down the original project’s Tech Lead.

The fix has to live inside the workflow, or it won't survive contact with your next deadline

Here's where most of the articles I’ve seen stop short: if capturing a decision's rationale requires a separate step - a second tool, a different tab, a task someone has to remember to do  it will lose the battle with pressure to ship the product - every time, the same way documentation always has. The only solution I’ve seen consistently work is one where the decision capture happens as a byproduct of the work itself - inside a team’s CI/CD pipeline, not alongside it.

Most CTOs would pause here, anticipating the suggestion of yet another AI-enhancement or automated documentation script - and their objections to that approach are almost as clear as if they were looking over my shoulder and objecting to it as I type:
“Isn't using AI to fix a problem that AI caused in the first place a little circular?”
My answer: It sure would be, if the AI were making the decision by itself. That isn't what I am suggesting - I’m suggesting adding a gate to the process to make the rationale impossible to skip. There's a real distinction here, going back to Douglas Engelbart's 1962 research report Augmenting Human Intellect: A Conceptual Framework — the foundational document behind much of modern computing, including the mouse and hypertext. Engelbart's central argument was that tools should expand a person's own capacity to reason through a problem, not think for them. An agent that prompts an engineer to state why before a decision gets logged is doing the former: forcing the explicit-reasoning step, not replacing it. Letting a model make the call and move on without anyone articulating the reasoning at all is the latter, and it's the offloading that is causing the massively increasing Cognitive Debt problem in the first place. The difference is that a human's judgment is required to close the loop.

What this looks like, concretely

A decision worth logging doesn't need a new destination. It needs to be captured where the work already happens: a pull request, a design doc, a pipeline step; with enough friction to force the "why," and little enough friction that it survives your next deadline. That's exactly what I'm helping teams achieve via OLS Consulting engagements: The decision gets captured inside the pull request approval itself -no context switching to a wiki page that was already falling behind before AI ever entered the picture.

The starting point

I built a small working version of a decision-record-toolkit - not just a PR template and a merge-time check, but a paired capture point at chat-time too: an agent skill that logs the reasoning the moment a decision gets made, and checks prior decisions before a new one gets made on top of them. That second layer exists because of Craig Castle-Mead, a former colleague from the Uhub team, who reviewed the first version and sent back structured feedback in exactly the format the toolkit itself uses: a set of decision records, reasoning included, arguing for a chat-time capture point I hadn't built. It's the kind of proof a piece like this can't manufacture on its own: someone using the practice to argue for improving the practice. I merged his suggestions in.

The toolkit repo is free to fork - although it may not necessarily run against your specific CI/CD stack without some adaptation. Neither layer is a finished product, and both are intentionally the smallest version that actually works - so you can see the mechanism instead of taking my word for it.

What’s next

This is the first of a short series I plan on writing on where Cognitive Debt actually gets created inside the engineering lifecycle: the onboarding gap new hires spend weeks closing, the specific way AI-assisted code generation strips rationale out by default, and why most incident postmortems are really just symptom logs wearing a decision log's name. 

Unsure about where to start yourself? Identify your organization's Cognitive Debt with the Enterprise Platform Blueprint.