We need to talk about cognitive resource management.
This is not some newfangled buzzword term… yet. 😉
Cognitive resource management is a term I’ve started using, inspired by crew resource management.
But what is it? Definition time…
Cognitive resource management is the deliberate coordination and maintenance of the human and artificial cognitive resources involved in solving a problem, by the people actually solving that problem.
It is not a top-down kind of management.
And the reason I think we need a term for this is that a lot of people are trying to figure out what to do with AI, how we should use it, and how humans should interact with it, but I think we’re missing some big points about how humans should interact with these systems.
Writing, coding, and cognitive work
The problems are especially obvious if you try to write with AI.
That’s part of why I find it interesting how differently people respond to AI writing than they do to AI-written code. People are deeply suspicious of AI-written prose, while in software engineering we are increasingly being encouraged, and sometimes outright expected, to generate all or most of our code with AI.
I don’t believe writing and coding are as different here as you might imagine.
I’ve used AI to clean up my writing for a few years now, mostly for grammar and minor editing. Occasionally I’ve asked it to rewrite something to make it more punchy. And sometimes that works. Other times I end up arguing with my AI friend on my iPad over the nuances of voice, rhetoric, and style that it has a talent for utterly demolishing.
You have to be very careful anytime you let AI redo any part of your writing.
But that is not the only problem. You might try a small experiment if you’re interested.
Write a 500-word short story from a prompt. Then give the same prompt to an AI and have it write one.
If you don’t already have writing skills, the AI isn’t going to give them to you.
It may give you a perfectly competent story. It may even give you ideas you wouldn’t have thought of yourself. But generating stories with AI does not, by itself, teach you how to construct a story. This becomes deeply apparent the longer and more complex the story is.
And if you rely on it too heavily, you may avoid doing exactly the cognitive work that develops those skills.
I think a similar phenomenon happens with code.
Understanding the larger system
Code is a little different because there are certain functions everyone has to write sooner or later. Null checks. Input validation. Try/catch statements. Is this field filled out? Is this a valid date? How to log out a precise bit of data.
There are algorithms and patterns that get used over and over again. A lot of programming, especially at that level, feels more like discovering or applying known solutions than inventing something completely new.
So we don’t expect originality from every line of code, but originality isn’t really the issue.
The issue is whether you understand what the code is doing.
That doesn’t mean you have to personally write every line of code in order to understand it. Engineers spend enormous amounts of time reading and working with code other people wrote.
But there is a difference between seeing code and actively building an understanding of it.
If an AI generates a change, simply reading through the diff often does not give me the understanding I need.
So, depending on what I am working on, I may ask the AI to explain why the change works. I may ask it to trace the flow through the codebase.
I may ask what calls this function, what this function calls, what assumptions are being made, and what could break if certain things are changed. And every now and then I have gone so far as to ask my AI to quiz me on the part of the code that I am learning.
If I really need to understand something deeply, I might even explain it back to the AI and ask it to tell me where my understanding is incomplete.
Because the important question isn’t simply whether I can write that particular piece of code myself, the more relevant question is whether I understand how that piece fits into the larger system.
When I write fiction, individual sentences are only part of the work. I also need to understand how scenes connect, what information has already been established, what later events depend on earlier ones, and what happens to the rest of the story if I change something.
Software has the same kind of interconnected structure.
A function calls another function. Data changes. Something else depends on that data. An event gets emitted. Another service responds. A small change can travel surprisingly far.
So if AI is going to write more of the individual pieces, we have to be very deliberate about making sure we still understand how those pieces fit together.
Explain it to me
One of the things we’ve had to do frequently as a team is something like this:
“Hey, AI, here’s the bug I’m having. Here’s the part of the codebase where we think it is. Let me describe the symptoms.”
The AI comes back and says, “Yes, I think this is the bug. Do you want me to fix it?”
What’s my next step?
My next step is: Explain it to me.
Explain why that happened. Explain how this code works and explain how your changes resolve it.
I might ask it to explain what allowed this failure and how we can better prevent it in the future.
Because it isn’t enough to know, “This is the bug.” I need to understand why.
If you simply rely on AI to fix the problem, you’re not really keeping a human cognitively engaged with the system in any meaningful sense and that distinction matters.
There’s an assumption floating around that if AI handles more of the low-level coding, humans will naturally move upward into architecture, systems thinking, and higher-level reasoning.
Okay… maybe.
I don’t believe that happens automatically. I think your understanding and skill on a codebase can actually decay.
You could easily end up with a person who is producing more code while understanding less about how the system actually works.
The skill was never typing speed
That’s where I think people have been a bit too quick to dismiss the idea that we should continue to actively and continuously learn and verify our own understanding of our code and codebases.
There’s an assumption that coding skills won’t matter as much because AI will be writing it and fixing it in the future anyhow.
I think engineering skills matter enormously but the important skill was never simply how quickly you could type out a for loop or reproduce an algorithm from memory.
The important questions are things like:
- Do you understand how this part of the codebase works?
- Do you know what questions to ask?
- Can you recognize when something looks wrong?
- Can you trace a problem through a system?
- Can you tell when the AI is confidently spinning a yarn?
- Do you know what you don’t know?
Crew resource management
That’s why I keep coming back to crew resource management.
If you’ve ever watched an aviation disaster documentary, you’ve probably seen some version of this. In an emergency, a trained flight crew doesn’t simply become three frightened people all trying to solve the same problem.
They divide the cognitive work.
One person has control of the aircraft. Someone else is working the checklist and handling the radio. Someone might be monitoring instruments, gathering information, or troubleshooting.
Because of their training, they can rapidly function as a coordinated cognitive unit.
They aren’t tripping over each other.
It is very easy for a group of people to become less than the sum of its parts. Crew resource management is designed to help prevent that. It gives people trained roles and communication patterns that can make the group more capable than any one person operating alone.
It also recognizes something else that matters enormously: human cognition has failure modes.
Ego can cause problems. Authority and perception of authority can cause problems.
People may hesitate to challenge someone with a title. Someone may notice that something is wrong but remain quiet because they’ve been dismissed before.
Someone may become fixated on one explanation and stop seeing evidence that contradicts it, which is when that extra set of eyes can stop a disaster.
Those problems are central to crew resource management in a cockpit.
Your brain is a resource too
So I want to start thinking about cognitive resource management.
It is related to crew resource management, but now we have AI in the mix. You are working with something that isn’t quite a team member, but it absolutely is a cognitive resource, and it doesn’t think exactly like you. It has a much bigger working memory but significant failure modes of its own.
It is crucial to remember: your brain is a cognitive resource too.
The cognitive resource behind your eyeballs needs maintenance.
It needs to remain current. It needs to remain capable of reasoning at a high level.
It needs to understand where the thorny parts of a system are, where logging could be better, where cumbersome processes are hiding complexity, and which areas of the codebase you still don’t understand.
AI can be extremely useful in all of that, but it can also be wrong.
It can confidently tell you something that is simply not true.
Sometimes you need to double-check it. Sometimes you need a second opinion. Sometimes you need to go look at the source code yourself.
Knowing when to do those things is going to become an increasingly important engineering skill. And that means that managing cognitive resources includes managing your own.
You have to make deliberate choices that keep your knowledge of your codebase current.
You absolutely should keep developing engineering judgment.
You should continue developing architecture and systems skills.
And yes, I think you should continue developing your coding skills.
Because you are the one who ultimately has to verify that the AI is doing its job and not simply producing something that looks plausible.
So don’t stop practicing. Don’t stop reading and writing code. Continue to develop your code review and problem solving skills.
You are also a cognitive resource. You just have another one now.
Our challenge now is learning how to work with that new resource in a way that enhances our capabilities instead of quietly diminishing them.