The Horizon Effect
Early chess programs had a recurring, almost human flaw. Facing a loss they couldn’t prevent — a piece about to fall, say — they would throw out a string of pointless checks and threats that pushed the loss past the number of moves they were allowed to look ahead. Beyond that depth the program couldn’t see the disaster, so it scored the position as fine. It hadn’t avoided losing the piece. It had only shoved the moment out of view, usually wrecking its position further to do it.
Hans Berliner, working on computer chess at Carnegie Mellon, described this around 1973 and the name stuck: the horizon effect. A problem shoved just past where you’re looking reads as solved.
The structure is general, and it shows up everywhere a decision-maker evaluates only out to some fixed distance. Refinancing to lower this month’s payment. Patching a symptom so the dashboard goes green. Taking on debt — financial, technical, relational — whose bill arrives after the quarter you’ll be judged on. Each move is locally rational and globally a disaster, and it looks good because your evaluation stops just before the consequence.
It rhymes with the availability heuristic: we weight what’s vivid and near. The horizon effect is what happens when “near” hardens into a cutoff. What lies past the edge of attention gets scored as zero, not as unknown — absence of visible cost quietly becomes absence of cost.
It also names a kind of self-deception. People rarely choose disaster outright. They choose the move that makes the next few steps look fine and trust that “later” will sort itself out. The reflex to kick the can down the road isn’t stupidity. It’s an evaluation that, like those early engines, can’t see far enough, and so rewards the move that hides the loss over the move that takes it.
The fix the programmers found is the fix here too. They called it quiescence search: don’t stop at an arbitrary depth, keep looking down the volatile lines — the captures, the checks, the forcing moves — until the position goes quiet, and only then judge it. Claude Shannon had sketched the seed of this back in his 1950 paper on computer chess, distinguishing brute-force search from the selective kind that knows which positions are stable enough to trust. The lesson survived into every serious engine since.
In practice it means one habit. Before you accept a move that makes the near term look better, ask where the cost went. If you can’t find it, the likeliest explanation isn’t that there’s no cost — it’s that you stopped searching before the position settled. Keep going down the line that’s still churning.
A problem you can no longer see is not the same as a problem you’ve solved. The engines learned that the expensive way, one delayed catastrophe at a time.