Two engineers stare at the same problem. One of them sees it in thirty seconds: “that’s a state machine, those booleans can’t all be true at once.” The other grinds at it for an afternoon. The easy story is that the first one is just smarter. I don’t think that’s usually what’s happening. The first one had seen that shape before and the second one hadn’t. The recognition did the work, not the raw horsepower.
I used to think problem-solving was a set of techniques. Ask questions about the problem. Make it smaller. Work backwards. Build examples. Draw it on paper. I still use all of those, every week. But somewhere along the way I noticed they were never the thing that actually unlocked a hard problem. They’re amplifiers. They help me pin down a shape I already half-recognize. What they cannot do is hand me a shape I’ve never seen.
You Can’t Look for Patterns You Don’t Have
“Look for patterns” is good advice that quietly assumes a library to look in.
The clearest example I have is from my own work. A checkout flow with a dozen states, and for a long time I tracked it the way most of us do at first, with a pile of boolean flags: isSubmitting, hasError, isComplete, needsRetry. The bugs all came from the combinations that were never supposed to happen but did. If I’d never run into the idea of a state machine, no amount of “work backwards” or “draw it on paper” would have gotten me to the actual fix, which was to stop tracking flags and start modeling states. The techniques operate on a vocabulary of shapes. Without the shape, they have nothing to grab onto. You can shrink a problem, flip it around, and cover the wall in examples, and still not see it, because the thing you’re missing isn’t effort or cleverness. It’s that you don’t have the word for what you’re looking at.
This reframes the most boring item on every problem-solving list, the one that says practice matters, experience helps. True, but stated like that it’s useless. The reason practice matters is specific: every real problem you solve, and every solution you read closely, deposits a shape into the library. A debounce that keeps a handler from firing on every keystroke. Memoization. Optimistic updates with a rollback path. Idempotency on a payment you might retry. A cache, and the invalidation problem that comes free with it. None of those are techniques you apply by willpower. They’re shapes you recognize, or you don’t. Experience isn’t a vague virtue here. It’s the literal mechanism by which the library gets stocked.
How the Library Actually Gets Built
Not by memorizing a catalogue of patterns. I’ve tried that and it doesn’t stick, because a pattern you can recite but have never needed isn’t really in your hands yet.
It gets built by solving real problems and then naming what you just did. By reading someone else’s solution and noticing not just that it worked but what shape it was. And, importantly, by being wrong a lot. The old advice that your ideas will be wrong more often than right is correct, but the value isn’t some lesson in humility. A failed attempt is how you map the territory. “That didn’t work, and the reason it didn’t work is that this is actually a scheduling problem, not a sorting one” is a shape filed away for next time. The wrong turns are where the vocabulary comes from.
So the generic techniques aren’t useless. They’re the tools you use to excavate which shape you’re standing on. They just aren’t the shapes themselves, and confusing the two is why “I know all the problem-solving tips and I’m still stuck” is such a common and frustrating place to be.
What Changes When a Model Will Name It for You
This is where it gets genuinely interesting in 2026, and a little dangerous.
A model will name the shape for you, instantly. Paste in the problem and it’ll tell you it’s a race between two async updates, or a caching problem, before you’ve drawn a single box. That’s real, and I use it. It’s a faster path to recognition than grinding for an afternoon ever was. I’ve written more generally about working this way in Coding in the Age of AI.
But notice what it does to the mechanism above. If you let the model do the recognition every single time, you stop depositing shapes into your own library. You’re renting vocabulary instead of owning it. The reps that would have taught you to spot it yourself next time never happen, so next time you reach for the model again, and the dependency deepens instead of fading. It’s the old “don’t jump straight into the code” instinct moved up a level: don’t jump straight to the answer before you’ve tried to recognize the problem, because the trying is the part that builds you. The same trap with prompts, where the tool quietly does your thinking, is something I got into in Thinking Clearly with LLMs.
The move I try to make: form my own guess at the shape first, even a bad one, then let the model confirm or correct it. When I’m wrong, the correction lands on something, because I had a hypothesis for it to hit. When I skip the guess, the answer slides right off.
Where This Breaks
A few honest caveats, because “build your pattern vocabulary” can be taken too far.
Vocabulary without judgment is its own failure. Once you’ve got a library of shapes, everything starts looking like one of them, and you’ll reach for a state machine where a single boolean would have done, or force a problem into a pattern it doesn’t actually fit. Recognizing a shape is not the same as it being the right shape, and reaching for structure you don’t need is a real cost, which is the whole argument in A Case Against Abstraction. A bigger vocabulary makes this more tempting, not less.
The techniques still matter too. For a genuinely novel problem, one where no shape in anyone’s library fits, the generic moves are all you have, and they’re exactly how new shapes get discovered in the first place. Library and technique aren’t rivals. The library handles the problems that resemble something; the techniques handle the ones that don’t, and slowly turn them into new entries in the library.
And you can over-collect. Grinding pattern catalogues without ever shipping anything is its own way of avoiding hard problems. Vocabulary is a means. The point is to solve the thing in front of you, not to own an impressive set of shapes.
The Takeaway
Problem-solving advice usually sells you the techniques and stays quiet about the part that makes them work. The techniques are real, but they’re downstream of a library of shapes you can only build by solving things, reading closely, and being wrong on purpose.
So next time you’re stuck, before you reach for technique or for the model, try to tell which one you’re missing. If you have the shape and can’t apply it, grind on the technique. But if you’re stuck because nothing about the problem looks like anything you know, more grinding won’t help. The fix is to go learn the shape, because every technique on every list only pays off when there’s something in your head for it to grab. What’s the last new shape you actually added to yours, versus the last one you let a model hand you?