The file that lists what not to build
AI is relentlessly helpful. Without a written fence, that help walks your project somewhere you already decided not to go.
Early in my game project I cut an ability. A heavy melee move, call it the plasma punch. It didn’t fit the design, the reasons were good, and I moved on.
It came back three times.
Not because I changed my mind. Because every few sessions, working through some unrelated combat problem, the AI would reason its way to a clean, sensible suggestion: “the player needs a heavy option here. What about a plasma punch?” And it was right, locally. In the little box of that one problem, the punch was a good answer. It just happened to be the exact thing I’d already rejected for reasons that lived outside that box.
This is the failure mode nobody warns you about. AI isn’t reckless. It’s the opposite. It’s relentlessly, tirelessly helpful, and it has no memory of what you decided not to do. Every session it wakes up ready to solve the problem in front of it as well as possible, and “as well as possible” keeps rediscovering the same rejected ideas because they were never bad ideas. They were just wrong for this.
A decision log, the thing I’ve written about before, records what you chose. It’s good at defending a settled yes. But it turns out a settled no needs its own file, because the two get consulted at different moments. You look up a decision when you’re deciding. You reach for a drift check the moment before you build, when you’re not deciding anything. You’re just executing, and a plausible wrong turn slips in exactly because it looks like execution, not a decision.
The fence
So I keep a second file. Not “what we decided,” but “what an AI session must not propose or implement without me explicitly overriding it.” A fence of nos.
Mine has entries like: no difficulty selector. No health regeneration. No third combat button. No zip-to-anchor on the base grapple. No reintroducing the plasma punch. Each one is a place the project has already drifted toward, or obviously could, with a one-line reason attached so future-me and the AI both remember why the fence is there.
The rule around it is the important part: if a new idea conflicts with the fence, the AI stops and flags it instead of quietly building a workaround. Surfacing the conflict is the whole job. A good drift check doesn’t prevent good ideas. It makes sure a direction I already closed can’t get reopened by accident, only on purpose.
Where the name came from
I had the instinct before I had a word for it. I was just tired of arguing the plasma punch back out of existence every third session, so I built the file to make the decision stick.
Claude gave me the name while we were writing this note. Software design docs have long had a “Non-Goals” section: the part that says what a system deliberately won’t do, so nobody wastes a week building it. I hadn’t known that. Learning the practice was already standard didn’t make me feel behind. It made me trust the file more. A non-goals list in a design doc gets written once and read rarely. Mine gets checked before every build, because my collaborator has no memory and infinite enthusiasm. Same idea, load-bearing in a way it never had to be when the collaborators were all human and remembered last month’s decisions.
The honest limit
A fence only stops the drift you’ve already seen. The first time the plasma punch came back, there was no entry for it. I had to notice the pattern, feel the specific fatigue of re-rejecting something, and only then write it down. The file is a record of drifts I’ve already caught, not a shield against ones I haven’t. New projects drift in new directions, and I don’t find out where until I’ve been walked there once.
That’s fine. That’s what the file is: a place to put each wrong turn the first time, so it costs a sentence to prevent instead of a session to re-argue. The fence doesn’t need to predict every direction. It just needs to remember the ones I’ve already ruled out, because I will forget, and the AI never knew.