This text defines and explores "Hyrum's Law," an observation in software engineering which states that with a sufficient number of users, all observable behaviors of an API will be depended on by someone, regardless of what is officially promised in the contract. This phenomenon creates an "implicit interface" based on implementation details like performance, bug-for-bug compatibility, or data ordering. As a system grows, this implicit interface constrains developers' ability to change or fix the implementation without breaking a user's workflow. The accompanying discussion from Hacker News elaborates on this, providing real-world examples (like Windows 95's compatibility with SimCity), mitigation strategies (such as intentional randomization in Go), and the modern relevance of the law in the context of LLMs.
Hyrum's Law: The Unspoken Contract of Software Interfaces
The Core Principle: The law is formally stated as: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."
The "Implicit Interface": Over time, users will begin to rely on undocumented implementation details, not just the official API. These expectations (e.g., performance speed, data order, or even bugs) form an "implicit interface" that is as binding as the documented one.
Constraining Evolution: This implicit interface makes it difficult for developers to change the system. Any modification, including bug fixes or optimizations, risks breaking the code of users who unintentionally depended on the previous behavior. This is often referred to as needing "bug-for-bug compatibility."
Unintentional Reliance: The discussion highlights that users often don't intentionally exploit quirks. A developer might write code that simply works, without realizing its functionality is tied to a specific, un-guaranteed behavior of the API they are using.
A Real-World Example (Windows 95): A famous case involved the game SimCity, which relied on an obscure memory allocator bug. To ensure the popular game still worked, Windows 95 developers had to detect SimCity and intentionally re-enable the old, buggy behavior for that specific application.
Mitigation Strategy: Intentional Randomization: To combat this, some systems actively prevent reliance on implementation details. The Go programming language, for instance, purposely randomizes the iteration order of maps to ensure developers cannot write code that depends on a consistent order.
Mitigation Strategy: Versioning and Flags: Other strategies discussed include API versioning (e.g., /api/v1/, /api/v2/) to manage breaking changes, and shipping bug fixes with optional "bug flags" that allow users to temporarily retain the old, buggy behavior.
Relevance to AI/LLMs: The concept is highly relevant today with LLMs. Since the output of an LLM is an "observable behavior" with no firm contract, any downstream system built upon it is vulnerable to breaking when the model is updated.