One Level Down
Some problems resist every solution you throw at them because you're solving them at the wrong level.
The chess-via-regex-VM case is the cleanest illustration I know. You want an engine that can recognize patterns: forks, pins. Direct approach, write the recognition logic for each one. You're immediately in a mess of board-coordinate arithmetic, special cases per piece type, edge conditions at the boundary. The code for "knight fork" is forty lines and fragile. Add "bishop battery" and you're back to square one structurally.
The indirect approach: build a small VM that runs regex-like patterns over board states. Represent the board as a string with a grammar. "Knight fork" becomes a five-token pattern in that language. The VM parses it and handles the search. "Bishop battery" is another five tokens. The VM's internals are hard, but you write them once.
The problem moved up a level. At the original level it was intractable, each case its own bespoke thing. At the abstraction level, all cases share a structure and you solve the structural problem once.
SQL is the historical example at scale. Writing an optimizer by hand for every query is impossible. The query planner is hard once. SQL as a language gives you a clean interface: state the what, delegate the how. The relational algebra layer made a whole class of previously intractable problems tractable by moving them up and solving them there.
The pattern: when you find yourself writing the same shape of solution for each new case, and the solutions don't compose, and there's no obvious stopping point, you're fighting the representation. The problem isn't the individual cases. The problem is that you don't have a language for talking about the cases.
The psychological resistance is real. Building the abstraction layer doesn't feel like progress. You have a chess problem; now you're writing a VM. The deliverable recedes while you do infrastructure work.
That feeling is usually wrong, but not always. If the cases are few, genuinely distinct, and you're not adding more, just write them. But if they keep accumulating and each one is its own slog, you're already paying the abstraction tax without getting the abstraction. You're maintaining an implicit VM in the pattern of your repetitions. Making it explicit is just admitting what you're doing.
The signal I look for: am I writing a new version of something I've already written, or am I solving a new problem? If I'm writing a new version, the abstraction already exists implicitly. Naming it is the only work left.
Getting the abstraction right isn't guaranteed. A bad one constrains the problem without making it tractable, and then you have two layers to fight. The test: does solving the problem at the new level actually feel easier? Not ceremonially easier. Concretely easier, in the way that counting on your fingers beats arithmetic in your head. The VM approach to chess patterns passes that test. If it didn't, you'd know: patterns would be as painful to write in the pattern language as in raw code.
The wins are real when it lands. The chess engine with the VM is extensible and testable at two levels independently. The problem has clean seams. The direct approach never had those seams; it was accretion all the way down.
Sometimes the right move is to step back and build the tool that makes the problem soluble.