The first written rule I ever gave a coding agent inside a client's repository was one sentence: never touch the migrations folder without a human in the pull request. It was there because the agent had done it twice.
Steve Yegge, a veteran engineer and long time writer on software, took that idea to a scale I have not seen elsewhere. In an essay published August 24, 2026 he describes running 50 to 60 agents on one codebase, averaging 270 commits a day, with at least one bad decision every night. The agents accumulated 450 written rules, over 100 of them fences, any mechanism that turns you away if you are not supposed to be there. His lifecycle for a rule: a custom, then a warning, then written law, then a program that refuses by policy. His point: containment does not scale, written rules that escalate do.
In the client team the sentence about migrations became a check in the pipeline the third time it mattered. By the end of the quarter the context file had forty lines like it and the review queue had come down, because less arrived that needed a senior.
Harvard Business Review on X: adoption improves when organizations are explicit about an agent's capabilities and limitations. The explicit part is the work.
Questions and answers
What is a fence for an AI coding agent?
In Steve Yegge's definition, a fence is any mechanism that turns an agent away when it is not supposed to be there: a polite refusal, not a wall. A rule that only one kind of agent may talk to humans, enforced at the chat and email boundary, is a fence. A pipeline check that rejects a change to a protected folder is a fence.
How is a fence different from a sandbox?
A sandbox tries to contain what an agent can do. A fence tells the agent what it may not do and refuses when it tries. Yegge's argument is that containment does not scale as agents become capable and numerous, while written rules that the agent reads, and that escalate to mechanical enforcement, do.
How many rules did it take?
Yegge reports that his 50 to 60 agents, averaging 270 commits a day on one codebase, accumulated 450 written rules over ten weeks, more than 100 of them fences. Each one exists because an agent made a decision that defied common sense, at least one every night.
How does a rule tighten over time?
Yegge describes a lifecycle: first a custom, then a warning when it is broken, then written law that every agent must obey, then mechanical enforcement, a program that refuses by policy or alerts loudly. A rule moves up a step each time it is violated again.
What does this look like in a normal engineering team?
Smaller, but the same lifecycle. A reviewer catches something twice; it becomes a line in the context file the agent reads. When it is caught a third time, it becomes a check that runs before the pull request opens. In one client team the first rule was one sentence about the migrations folder, and by the end of the quarter the context file had forty lines like it.
Why does writing the rule down matter?
Because the agent can only follow what it can read, and the team can only enforce what it has stated. Harvard Business Review noted on X in September 2026 that adoption improves when organizations are explicit about an agent's capabilities and limitations. The explicit part is the work.
Sources
- Steve Yegge, Fences, not Sandboxes, August 24, 2026. https://yegge.ai/essays/fences-not-sandboxes/
- Harvard Business Review on X, September 10, 2026. https://x.com/HarvardBiz/status/2097884015944442217