There is a distinction that most organizations have never needed to make explicitly, because the cost of not making it was low enough to absorb. The distinction is between cognitive ability and intelligence — and while those words are often used interchangeably, they describe something meaningfully different. The arrival of AI is making the difference expensive to ignore for the first time.
This is particularly true in software engineering. And the people who built the most impressive careers on the wrong side of the distinction may be the last to see it coming.
- The difference between cognitive ability and fluid intelligence — a crossword vs. a word search
- How engineering culture systematically rewarded encyclopedic recall over reasoning under ambiguity
- Why the brute-force approach crowds out the habit of looking for leverage — a muscle analogy
- How AI's substitution curve is steep for recall and shallow for judgment — and what that means for careers
- The skills that were always most valuable but hardest to make legible — and why they're about to matter more
What Cognitive Ability Is, and What It Isn't
Consider two puzzles. A crossword and a word search.
A word search requires you to find something that is already there. The words exist in the grid. The task is scanning, pattern detection, visual search. It is cognitively demanding in the sense that it requires sustained attention and accurate perception. But it is not generative. Nothing needs to be constructed. The answer pre-exists the search.
A crossword requires you to construct an answer from partial constraints. You have a definition, a letter count, and whatever crosses you've already filled in. You have to retrieve candidates, test them against constraints, make connections between clues, hold multiple possibilities simultaneously. The answer doesn't exist anywhere until you produce it.
This is the distinction. Cognitive ability — in the sense I want to use it — is the capacity to detect, retrieve, and process accurately and quickly. It is pattern recognition at scale. It is memory depth and access speed. It is the ability to hold complexity without dropping it. Intelligence — in the sense I want to use it — is the capacity to reason through novel situations, to reframe problems, to operate under genuine ambiguity, to construct something that didn't exist before.
The two are correlated, which is why we conflate them. But they are not the same thing. And the difference matters enormously when the environment changes.
In cognitive science, the closest established terms are probably processing efficiency for the first cluster, and fluid intelligence for the second — reasoning on novel problems where accumulated knowledge is thin. (Fluid intelligence is not a perfect label for crosswords, which lean heavily on vocabulary and culture; the point is the boundary, not the psychometrics.)
The word search is solved by a computer in milliseconds. The crossword is harder to automate — it requires world knowledge, wordplay, inference, and the ability to reframe a clue that initially resists interpretation. That asymmetry is not a coincidence. It tracks which human abilities look most like fast search over a fixed field, versus construction under incomplete constraints — and that is roughly where today's tools are strongest versus weakest.
A different vocabulary for the same boundary — how much context a branch of work actually needs, and why delegation fails when you get it wrong — runs through the piece on local reasoning and agentic systems.
How Engineering Culture Rewarded the Wrong Things
Software engineering, for most of its history, has been a field where encyclopedic knowledge was visibly prestigious. The engineer who had memorized the Linux kernel flags, who knew every SQL quirk, who could compose arbitrarily complex queries from memory, who understood the internals of every framework they touched — that person had status. They were impressive in interviews. They were the person others deferred to in technical discussions. They were, in the vocabulary of engineering culture, senior.
This wasn't arbitrary. Encyclopedic knowledge was genuinely valuable. Systems were complex, documentation was poor, Google didn't exist and then existed but wasn't always useful, and having the answer in your head was faster than finding it anywhere else. Cognitive horsepower — the ability to hold an enormous amount of technical detail in working memory and retrieve it quickly — was a real competitive advantage.
But something else was happening alongside this. The engineers who couldn't rely on encyclopedic knowledge — who had to think more carefully about every problem because they couldn't brute-force it with recall — were quietly developing a different set of skills. They were learning to ask: what is the simplest version of this problem? They were learning to abstract, because they couldn't afford to work at the level of raw detail. They were learning to reason about systems rather than memorize them.
Brute-forcing complexity and managing complexity are opposite skills. The engineer who succeeds by knowing everything has been rewarded, in a sense, for tolerating accidental complexity rather than eliminating it. The engineer who succeeds by reasoning well has been forced to reduce problems to their essence — because they had no other choice.
The field systematically undervalued the second kind of engineer, because their skill was harder to see. That kind of judgment is notoriously hard to demonstrate in a short interview. You cannot demonstrate it by reciting API surface. You cannot point to it in a code review. It shows up in the decisions that don't get made, the complexity that never gets added, the reframing of a problem that makes three weeks of work unnecessary. It is legible only in retrospect, and often not even then.
What Happens When Strength Stops Being the Point
There is a useful analogy in physical labor. A person with exceptional raw muscle can lift things that others cannot. This is a genuine advantage — until the problem gets heavy enough that muscle alone fails, or until a tool appears that lifts more than any person could.
But there is a subtler problem. The person who can lift without tools never develops the instinct to look for leverage. Why would they? The brute force approach works. The weight gets lifted. The feedback loop reinforces the method. And so the habit of asking is there a lever here? never forms — not because the person is incapable of asking, but because they were never forced to.
The cognitive equivalent: if you can hold the entire API surface in your head, you never develop the discipline of abstraction. If you can memorize every SQL quirk, you never ask "what is the simplest query that answers this?" If you can brute-force the complexity, you never learn to dissolve it.
This is not a character flaw. It is a rational response to incentives. The cognitive athlete was rewarded for their strength, and they trained it. The problem is that the training crowded out something else — not deliberately, but by opportunity cost. Every hour spent accumulating technical detail is an hour not spent developing the habit of looking for the lever. Every problem solved by recall is a problem that didn't force the development of reasoning under uncertainty.
The result, for some engineers, is a career built on an enormous amount of knowledge and a somewhat underdeveloped instinct for what to do when the knowledge runs out. When the problem is genuinely novel. When the system doesn't behave as documented. When the question isn't how to implement something but whether to implement it, or what the right thing even is.
Those are the moments that reveal the difference between cognitive ability and intelligence. And in most engineering careers, those moments were rare enough that the difference rarely became visible.
There is a constructive sibling to brute-force success: get the answer any way you can, then go back for the picture that makes it inevitable — what I called the second pass.
The Substitution Curve Is Not Neutral
AI is, at its core, a very fast and very accurate pattern recognition and retrieval machine. It does not get tired. It does not forget. It can hold more API surface in context than any human, retrieve more syntax variants, compose more complex queries, and do so in milliseconds.
This means the substitution curve is not neutral across skill types. It is steep for straight recall and pattern completion, and shallower for reframing under ambiguity — though models already blur that line on some tasks, so the map is a snapshot, not a law of nature.
The engineer who was exceptional because they knew everything now has a colleague that knows more, never forgets, and never needs to look anything up. The productivity delta they could offer is gone. What remains is the question of whether they have anything underneath the knowledge — whether there is reasoning capacity that was always there but never needed to be the primary tool.
For some engineers, the answer is yes. The knowledge was always instrumentally held, in service of a deeper ability to think about systems. These people will adapt quickly. They will find that AI amplifies them — that the combination of their judgment and AI's recall is more powerful than either alone.
For others, the knowledge was the primary tool. And that is a harder position to be in, because the skill that needs to develop — reasoning under ambiguity, knowing which problem to solve, making judgment calls without a reference to consult — is one that takes years to build, and that the incentive structure of their career actively discouraged.
There is also a compounding effect. The people whose identity and status were built on knowing things may be the least likely to use AI well. Delegating recall to a tool is psychologically threatening when recall was your competitive advantage. The engineer who always knew their strength was judgment has less ego investment in doing the lookup themselves — and will adopt the tool more naturally, which accelerates the gap.
The Skills That Were Undervalued All Along
The abilities that survive the AI transition are not exotic. They are the ones that were always most valuable but hardest to make legible:
Knowing which problem is worth solving. Reframing a question when the question as stated is wrong. Understanding what a user or a trader or a stakeholder actually needs, as distinct from what they asked for. Knowing when an elegant solution exists and being willing to look for it rather than implement the obvious one. Having taste — about code, about systems, about what complexity is worth carrying.
These are the abilities that the best engineers always had, often quietly, sometimes despite a culture that rewarded the wrong things more visibly.
What AI does is not eliminate the need for engineers. It eliminates the need for encyclopedic engineers. It raises the floor — anyone with access to the tool can now produce competent implementations of well-defined problems. What it raises the value of is everything above the floor: the judgment about what to build, the taste about how to build it, the wisdom about when not to build it at all.
The person who was impressive because they knew everything now has competition that is superhuman at knowing things. The person who was impressive because they thought well has never had better tools to think with.
The muscle is being automated. The leverage was always the point — the same upstream move cheap execution already rehearsed once before.