The term was coined by Margaret Storey, a computer science professor who’s been studying developer productivity for over two decades. There’s also a MIT paper that frames it more broadly – the accumulated cognitive cost of outsourcing your thinking to LLMs. Consistent underperformance at neural, linguistic, and behavioural levels in LLM-heavy groups compared to non-users. Polemically shortened: the cost of becoming more stupid through AI usage.

But in software, cognitive debt isn’t about individual intelligence. It’s about shared theory or the collective understanding your team has about how a system works, why decisions were made, and what the boundaries are. Technical debt in the same vein is not some magical, autonomous deterioration of code - it’s also the collective human factor, the accumulation of architectural decisions over time that make maintenance harder and harder. Cognitive debt is the same mechanic, but instead of the code degrading, your shared understanding of it does. Then production is down and your team is staring at the code like it’s some ancient Mesopotamian stonewall.

The dangerous thing is that you might recognise it as a problem when it’s already too late to cheaply reverse. Your velocity metrics look fantastic. You shipped (insert fantastic number of choice)% more features this quarter, all on AI-steroids. But when an incident hits an AI-written module and the resolution takes four times longer because nobody can trace the logic – that’s your interest payment on cognitive debt. And more API usage billed for your GitHub Copilot.

So what do you actually do about it?

The natural cure might simply be the end of subsidised token use – I swear, one of these days I will write that blog post about the real pricing of AI-compute, but today is not the day. Maybe it will just stay a meme to hide in every single blog post I write. But running out of a session limit with your Claude Max subscription has the same effect: slowing down. And slowing down is, annoyingly, the point.

The practices to prevent cognitive debt already exist. TDD, pair programming, refactoring, rigorous code review. Nothing new. Code review in particular was never really about catching bugs – it was the primary mechanism for knowledge transfer. Juniors learned architecture by reading senior PRs. Seniors maintained context by reviewing everything. AI bypasses that entire loop. The code shows up, it works, tests pass, it gets merged. Nobody learned anything. Nobody built context.

You could spin up agents to review and document for you – but they cannot retain the shared theory your team needs, the why your code works a certain way. They can generate decision records, sure, but those still need human eyes to become shared understanding. As long as agents can’t hold that memory for your team, the rule is straightforward: at least one team member must be able to explain any AI-generated code change before it ships. Not read it. Explain it. Can I walk a teammate through every line? Do I understand why this approach was chosen over alternatives? Could I debug this at 3 a.m. without reprompting? If the answer to any of those is no, it doesn’t merge.

I am a huge proponent of velocity over everything – it’s literally in the name of the blog. But speed without understanding is not velocity. You will be sprinting on borrowed time.

Further reading:

• Margaret Storey – Cognitive Debt
• Margaret Storey – Cognitive Debt Revisited
• Kosmyna et al. – “Your Brain on ChatGPT: Accumulation of Cognitive Debt When Using an AI Assistant for Essay Writing Task”

In a recent podcast appearance, Boris Cherny compared the craft of software engineering to that of the “medieval scribes.” That tiny, hyper-literate elite. Scribes were often more educated than the kings and lords they served, not just copying books in a painstakingly slow process, but being quite literally the interface to written knowledge for masters who weren’t literate themselves.

Then came the printing press

The printing press didn’t destroy scribes overnight. It just made their core skill – slow, perfected, manual reproduction of text – irrelevant. To go back to Boris’s podcast appearance: the notion that scribes became the first authors is not historically provable, and is probably more of a romantic thought than a documented fact. The truth is that literacy skills survived, expanded rapidly, and found new vessels – early printers, editors, translators, scholars. The craft of producing written text and knowledge did not disappear, but the bottleneck for its proliferation disappeared.

The parallels to software engineering today

It is the running in-joke at many a tech company that the nerds writing software are a small priesthood, gatekeeping access to the mystical ways of the machine. If you don’t speak it – or aren’t code-literate – you can’t join the club. I have lively memories of my first encounter, as a very green PM way too many years ago, with an extremely seasoned architect, who folded me like a camping chair for suggesting a technical solution in a sprint planning. Good times.

AI advancements and the current wave of agents are comparable to the printing press. The “tech-illiterates” – CEOs, some PMs, designers – the kings who could not read – are now starting to build things themselves, using code syntax they don’t even understand.

And it’s not just non-techies shipping entire features without touching code. Even seasoned developers with a deep portfolio of programming languages under their belt are, by adopting AI into their workflow, writing less and less code themselves. Boris notes in the podcast that 100% of his code has been written by AI since November 2025. Andrej Karpathy stated in a recent podcast that by December he had already flipped to writing just 20% of his own code – and hasn’t typed a line since.

Now, those two are extreme examples – and Boris, for one, presumably has unlimited access to tokens.

There is a version of this essay where I spend three paragraphs on token economics, the true cost of compute, and whether we are all just characters in a fever dream fuelled by absurd amounts of investment capital. That essay exists. You are not reading it.

What remains

The engineering part is not going away – and it was never the same thing as coding anyway. The job being replaced is “human-as-syntax-translator.” The job that remains – and was always the aspirational one, by the way – is “human-as-system-thinker.”

This is an important distinction for juniors hitting the job market right now. I recently had a conversation about this with a CTO and founder in the European fintech space, and his framing nailed it: the entry-level job of the future will essentially be something like a “junior architect” or “systems orchestrator.”

All the underlying engineering muscles become more valuable, not less. System design, trade-off analysis, understanding failure modes, knowing why something should be built a certain way. Especially when you are orchestrating five agents simultaneously to go and build separate but ultimately interconnected things.

Ironically, this is what senior engineers were always best at. AI has just removed the prerequisite of absolute syntax fluency – and the scribe bottleneck along with it.

An uncomfortable way forward

I am really not trying to play the prophet here. This is just an attempt at a zoomed-out observation at a very specific point in time, which happens to be early 2026.

But as of right now, it’s clear that the transition – for new engineers and experienced ones alike – won’t be clean or comfortable. If your entire professional identity was built on coding at some insane craft level, that identity is under pressure. Speed was always everything, and the scribing bottleneck is gone.

And with the flood – where everyone, including those with little to no systems thinking, can spin up anything – judgement of quality becomes the scarcest resource. Just like an editor is the last line of defence against a bad author’s output. The difference is that this author (agent) never sleeps, never gets offended by your (the editor’s) feedback, and will cheerfully rewrite the entire chapter in thirty seconds.

Boris mentions in the podcast a 15th-century scribe who was asked how he felt about the printing press. The surprising answer was that he wasn’t lamenting the printing press, he was excited. He had never enjoyed copying books over and over and over again – the parts he loved were illustration and bookbinding.

That is perhaps the mental framework to adopt going forward: code syntax becomes a common language, a generalist view on the products we create becomes key, and we get to focus on the bits that actually matter.

That is, until you hit your usage limit.

Just 2 years ago, the answer might be something like “the programming language used is not relevant, you have to understand the underlying concepts of software engineering” (you are probably talking to a software engineer) or “You working with data? Go with Python!” (you are probably talking to a data scientist).

The answer today is: English. Learn English. (or any language you already speak).

“Coding” is rapidly becoming a commodity. When operating in an AI-powered VS code or directly in Claude Code, the limiting factor is just your ability to express as precisely as possible what you want in the natural language you speak. By “speak” I also mean dictate into your microphone. And then iterate on your steps. Your AI agents (plural) do the rest. December 2025 is the moment we can mark in our calendars when this shift truly happened.

This paradigm shift even justifies a paragraph on the Natural Language Programming Wikipedia page .

It’s very similar to the way translation software works. We have reached an amazing level of precision in text-to-text translations – and we are completely used to it.

Take DeepL as an example. Being tri-lingual, I often try to test the output based on an input I know the meaning of, and time and time again I am amazed that the software even captures some subtle meaning that is far removed from simple line by line, word by word translations.

But still – it has become a commodity. We are so used to it and its quality output that we use it casually, hidden within a browser extension, just one click away from understanding any foreign language.

LLMs have become so precise in translating your natural language input into the appropriate code syntax that learning a new (programming) language is a valiant effort, but not a necessary one. It has the same benefits as learning a new (natural) language – it makes you smarter, believe it or not – but beyond that you will be able to navigate the complicated world of coding pretty easily. Just as you would be able to navigate with Google Translate through your next holiday in Thailand.

The question today is not really about code. It’s about whether you can think precisely enough to tell a machine what you want.

AI didn’t just lower that bar – it blew open the door and removed the secondary skill of learning a programming language completely. And we are getting used to it faster than we realise.

And a small PS: note that I write explicitly about coding. I am not talking about the engineering side of software. That’s for another time.