For most of my career, organizational rules lived in people’s heads. The longest-tenured engineer knew why we never deployed on Fridays. The VP who had been around since the founding remembered why the approval chain bent a certain way. That knowledge moved through conversations, onboarding lunches, and the occasional “trust me on this one.” It worked — imperfectly, slowly — because humans could ask each other questions.
That era is ending — and it is worth sitting with what that actually means.
The rules we inherited
Every company carries commandments nobody voted on. They arrived as sensible adaptations to real constraints: engineering time was expensive, context took weeks to transfer, mistakes cost months to undo. So we built rules around those frictions. We held long approval meetings because asynchronous coordination was unreliable. We wrote detailed specs because rework was brutally costly. We built roadmaps because nobody could hold the plan in their head otherwise.
AI is dissolving many of those original constraints. The interesting question is not whether the rules change — they will — but whether we are doing that deliberately or by accident.
The key insight is this: AI removes the scarcity that created a rule, but it does not remove the judgment the rule was encoding. When you dissolve the constraint, you are left holding the reasoning — and you have to decide consciously whether that reasoning still applies.
The legibility problem
There is a second shift that gets less attention. Rules that only live in someone’s head do not exist to an AI agent (a software system that takes actions on your behalf). An agent pointed at your calendar, your repository, and your documentation will surface the rules that are actually written down. Everything else — the tribal knowledge, the cultural instincts, the unspoken norms — is invisible to it.
This creates an uncomfortable audit. The things your organization says it values and the things it actually enforces become suddenly distinguishable. If your “no unnecessary meetings” value is only enforced by the occasional eye-roll, an agent running your schedule will not see it. If it is implemented as a calendar check with a Slack challenge and a deadline, the agent can act on it.
It forces a kind of precision that culture documents usually avoid.
Four things companies blur together
One pattern worth naming: organizations treat four genuinely different objects as if they were one: a value, a rule, a runtime check, and a human appeal. These do different work. A value is directional — it tells you what you are optimizing for. A rule is behavioral — it specifies what you will and will not do. A runtime check is mechanical — it asks whether the rule was followed in a specific case. A human appeal is the ceiling — the place where judgment that cannot be automated lives.
Confusing these produces culture documents that enforce nothing. A values statement cannot do a rule’s job. A rule without a runtime check is aspirational at best. And removing the human appeal entirely is how you build a system that applies rules confidently in situations they were never meant to cover.
The five-rung enforcement ladder moves from value, to instruction, to reminder, to hard block, to human-owned decision — and the key is that each rung requires specific evidence before escalating to the next. The machine handles the early rungs; a person keeps the judgment at the top.
The replacement problem
A lesson that tends to arrive the hard way: you cannot ban a behavior without absorbing the function it was performing. If your team uses weekly roadmaps and you eliminate them, the coordination job that roadmaps were doing does not disappear. It has to go somewhere. If you have not written down what absorbs it, you have not really made a decision — you have just created a gap.
This seems obvious in retrospect. But organizations routinely copy someone else’s operating principles without copying the surrounding mechanisms that made those principles functional. The prohibition lands; the replacement never arrives; confusion follows.
What the audit actually looks like
The practical step worth taking is a five-question worksheet, applied to any rule under evaluation. Name the behavior the rule governs. Find the scarcity condition that originally created it. Decide whether that scarcity still exists. If it does not, decide what judgment remains worth keeping. Then write a testable breakage condition — something a person can tell you broke, in specific terms.
That last step is harder than it sounds. “We want to move fast” is not a breakage condition. “A decision with more than three stakeholders and no documented owner has broken the rule” is.
An agent pointed at your actual systems — calendar, git history, documentation — can surface a lot of this. Not to replace the judgment, but to make the gap between stated and actual behavior visible. That visibility is the starting point.
Where this goes
The organizations that navigate this well will be the ones that treat rule legibility as a first-class concern — not a documentation task, not a culture initiative, but a precondition for effective AI deployment. The agent stack is only as good as the context it can read. And the context it can read is only as good as what you have been willing to write down.
The work of making implicit rules explicit is, at bottom, the work of deciding what you actually believe. AI just makes it harder to avoid.
Text summarized and optimized using Anthropic’s models and reviewed by a human.