Blog #0189: The Unreasonable Effectiveness of the Highlander Rule

Source: https://www.bbc.co.uk/programmes/m000qr0t

[ED: On naming coding rules after 80s sci-fi films, and why it works better than it should. 3/5 hats.]

The Rule

I have a coding rule I call The Highlander Rule. It says: there can be only one.

One code path for a given responsibility. One source of truth for a given piece of state. One function that does a given job. If you find two things doing the same work, one of them has to go. No exceptions, no "just in case" duplicates, no parallel implementations kept around for comfort.

The name comes from the 1986 film Highlander, in which immortals fight each other one-on-one across centuries until only one remains. The premise was simple. The execution was good. The sequel was terrible — which is itself a kind of Highlander Violation: if your core thesis is "there can be only one", perhaps don't make a second one.

Why It Matters for Agentic Coding

I've been using Claude Code as my primary coding agent for a while now. It's good. It's fast. It generates a lot of code. And therein lies the problem.

Left to its own devices, an agentic coder will solve a problem in the moment. If it needs a helper function, it writes one. If it needs to format a date, it formats a date. It doesn't always check whether that helper already exists three modules over, or whether there's a formatting function in the utils that does the same thing slightly differently. The agent optimises for solving the immediate task, not for the structural integrity of the codebase.

This is how you end up with two implementations of the same concern, then three, then a codebase where nobody — human or agent — can tell which version is canonical. I wrote about this dynamic in a previous post on agentic coding: the hard problem has shifted from writing code to knowing what to throw away. The Highlander Rule is the operational form of that insight. It gives the agent a concrete, testable constraint: if there are two, find the better one and kill the other.

What Makes It Work

Here's what surprised me. Within a short time of adding The Highlander Rule to my coding guidelines, Claude Code started finding violations on its own. Unprompted. It would refactor a module and report back: "Found a Highlander Violation — two functions were handling error normalisation. Consolidated into one."

The rule worked not because it was technically sophisticated. It worked because the name was memorable and the concept was unambiguous. "There can be only one" requires no further explanation. There's no grey area. You don't need a three-paragraph rubric to decide whether a situation qualifies. Either there are two things doing the same job or there aren't.

I think this points at something worth paying attention to. When you're writing rules for an AI agent, the rules need to be the kind of thing that survives compression. The agent doesn't have your full context. It doesn't remember last Tuesday's architectural discussion. What it has is the rule as written, and whatever cultural scaffolding the name carries with it.

Pithy Names as Load-Bearing Structures

This is where it gets interesting — or at least, where I started noticing a pattern.

A rule like "avoid duplicating code paths across modules" is precise but forgettable. It's the kind of thing you write in a style guide that nobody reads twice. "The Highlander Rule" does the same work but it sticks. It sticks because the metaphor has cultural weight. You don't need to re-derive the reasoning every time you encounter it. The name carries the intent.

I've started to wonder whether there's something structurally useful here — not just as a mnemonic trick but as a genuine communication strategy for working with AI agents. A metaphor that maps cleanly from one domain (80s cinema) to another (software architecture) may compress more meaning into fewer tokens than a precise but dry specification. The agent "gets it" faster because the metaphor is already in the training data, complete with connotations.

This is the third post I've written on agentic coding that draws on an 80s sci-fi film. The first argued that LLM-powered programming is more mech suit than artificial human. The second was about knowing what code to throw away, which leaned on Michelangelo rather than sci-fi but shared the same instinct: reach for a metaphor that does structural work, not decorative work. It may be time to accept that my mental model for agentic coding is built entirely from films I watched as a teenager.

The Unreasonable Effectiveness of a Good Name

There's a tradition in computer science and adjacent fields of writing papers and posts about "the unreasonable effectiveness" of some surprisingly powerful idea. Halevy, Norvig, and Pereira wrote about the unreasonable effectiveness of data. Wigner wrote the original on the unreasonable effectiveness of mathematics in the natural sciences. Someone maintains a whole list of these on GitHub.

The pattern is always the same: something that looks too simple to matter turns out to punch well above its weight. The Highlander Rule fits. It's a three-word coding rule named after a film with a one-sentence premise. It has no theoretical depth. And yet it's one of the most reliable tools I've found for keeping an AI coding agent from slowly degrading a codebase through well-intentioned duplication.

There can be only one. It turns out that's enough.

Regards,
M@

Originally posted on matthewsinclair.com and cross-posted on Medium.

_[ED: If you'd like to sign up for this content as an email, _click here_ to join the mailing list.]_