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.
The first article in this series is “Your Brain Is a Cognitive Resource Too.”
The Stack Overflow Assumption
Many years ago, I was just about to go on vacation when I decided to redo a little animated effect on an input form. It was one of those simple effects where the label floats up when you start typing. We already had an implementation, but I didn't like how it worked, so I wrote a better one. Then I forgot to remove the old implementation before I left.
When I came back, I discovered that a more junior developer I'd been working with had added a third implementation of the exact same thing. I asked why she'd redone it. She hadn't realized I'd already finished it, which was my fault, as I'd apparently added and then forgotten to remove it from whatever to-do list we were working from.
But in the course of the conversation she said something to the effect of: “Everybody just copies that kind of thing off Stack Overflow anyhow.”
That genuinely surprised me because it absolutely would not have occurred to me to go searching for an implementation of something that was that simple. She was a good engineer, and I suspect it just didn't occur to her that many otherwise fancy looking UI effects can be accomplished with just a few lines of code and take far less time than hunting down someone else's implementation.
I've seen variations on that attitude many times since then.
Delegation vs. Abdication
Now, to be clear there is absolutely nothing wrong with using somebody else's solution. Sometimes using a library instead of building your own component is exactly what you should be doing. There are tradeoffs to doing it yourself vs. using a library. And there is no reason to reinvent the wheel when a good utility library does it for you, unless of course that library is bloated and you only need a function or two—you get the idea.
But there is a difference between deciding not to build something because an existing solution is the better choice, and never really making that decision at all.
That doesn't mean you need to understand every corner of every system you touch. There isn't enough time, and one of the reasons abstractions exist is so that we don't all have to carry the entire computing stack around in our heads.
Sometimes the right decision is: I do not need to know how every bit of this works. Sometimes it's: I need to understand this well enough to recognize when it breaks. And sometimes it's: This is fundamental to the work I'm doing, and outsourcing my understanding of it is going to make me worse at my job.
The important part is that the people doing the work are making that decision deliberately.
You're deciding where your attention, understanding, memory, tools, documentation, and now AI are most useful. The goal isn't maximum human cognition. It is effective use of all the cognitive resources available to solve the problem. Just as teammates might divide a problem between them, you can decide which parts deserve your attention, which can be delegated, where AI should assist, and where it should provide an independent analysis.
Using AI to Fix What AI Broke
Now that we have AI in everyday use as a software engineering tool, the temptation to lean on it and sometimes even outsource thinking entirely is incredibly powerful. AI can do nearly all the things. It can write the function, find the API, read the documentation, produce the query, explain the error, remember the syntax you forgot, and dig through a codebase that would take you hours to explore manually.
All of that is really cool.
So why on earth would your response to gaining another cognitive resource be to stop using the one you already have?
I've heard engineers talk about no longer reading much of the code because AI writes it now. I've heard people say their fluency in specific languages is getting worse because they don't really write code anymore. Well, yes. Stop practicing something and there's a decent chance you'll get rusty.
I noticed it happening to me. I'd been using AI autocomplete heavily for a couple of years when I realized some of my JavaScript recall was getting a little soft. Things I used to type without thinking, I was occasionally drawing a blank on.
So I started using AI to drill me on JavaScript. AI contributed to a cognitive tradeoff I didn't like, so I used AI to help correct it.
That is Cognitive Resource Management. The point isn't to minimize your use of AI. And it certainly isn't to prove you're a Real Programmer™ by refusing autocomplete and carving code into stone tablets with a chisel. The goal is to understand what the different resources available to you are capable of, and use them deliberately. AI has strengths you don't have. Excellent. Use them. But don't confuse AI can do things I can't with there is no longer any reason for me to think.
Maintaining the Mental Model
Have it investigate a problem and explain what it found. Have it trace a code path through some miserable corner of the application. Ask it for three implementations and the tradeoffs between them. Let it sketch the plan, then read the plan until you understand it and write the code yourself. Or you could write the code first and ask the AI to review and critique your approach. Ask questions about the parts of the codebase you've never understood. Make it quiz you on something you've gotten rusty on. And one of my personal favorites: ask it what assumptions it's making or that you might be making.
There are plenty of ways to use AI without turning yourself into a passenger.
Lately, I've been doing more of that myself. I like having AI help me investigate a problem or develop an approach, then writing more of the implementation myself. Not because manually typing the code makes me morally superior, but because writing it helps maintain my mental model of the system.
And that mental model matters a hell of a lot more than whether I remember the exact arguments to some method.
The mental model is what lets me look at a bug and have a pretty good hunch about where it lives. It's what lets me recognize that a proposed implementation was written in the wrong layer. It's what lets me notice that something technically works but doesn't fit the way the rest of the application operates. And it is what lets me look at an AI-generated solution and say: “No. That's not how that model works.”
That's professional engineering judgment. And it doesn't come from typing faster nor from generating code faster, it comes from understanding enough of the system to make good decisions about the work you're doing.
Speed Is a Metric, Not The Metric
This is also why I don't buy the idea that AI means all our old software engineering disciplines suddenly become optional because your management chain wants things faster now (like that's new).
Okay, so push back. Speed is a metric. It isn't the metric.
Writing code faster just because you can is kind of like mining more coal because your tools can dig faster even if there is no one to buy it. Producing code faster doesn't mean you are building the right thing faster, or that the users want all those new features and upgrades faster. They might prefer you get to that bug that's been sitting around for two years a little quicker.
Meanwhile, all the very real parts of software engineering that are NOT code writing still matter. Tests, QA, architecture, code reviews, reliability, security maintenance, and whether anybody understands what the hell you just shipped, definitely still matters.
One of the more interesting things I've noticed working with AI is that the places where AI struggles most are often the exact same places where engineers struggle. I don't think that's a coincidence.
If the naming is confusing to humans, it tends to confuse the AI also. If the architecture contains weird hidden coupling that developers routinely misunderstand, the AI is going to have trouble reasoning about it too. If critical business logic exists only in somebody's head, the AI will not magically know about it. And if you don't have good tests, you are lacking one of the best tools available for checking whether the thing the AI confidently produced broke half of your application in the process.
AI doesn't make comprehensible software less important. I believe that it makes comprehensible software more valuable.
Which brings me back to Cognitive Resource Management: your brain is part of the system. AI is another part.
If AI saves you from spending two hours digging through legacy code, use some of that time to understand the architecture. If it can explain something faster than you can hunt down the documentation, learn something you didn't understand yesterday. If autocomplete makes you rusty, practice. Sometimes let the AI write the code, other times write it yourself. Sometimes let it produce the first draft and then tear the thing apart.
Use the machine, but keep your hands on the wheel.
Because the great opportunity AI gives software engineers isn't permission to stop learning. It's the chance to learn more, understand more, and bring more cognitive power to the problem than we have ever had before.
If your response to that is to stop thinking, then you are not taking advantage of AI. You're undercutting the whole system.