I was looking at your screen yesterday, Herman, and for a second I thought you were back to writing C plus plus, but then I realized it was just a massive list of instructions in plain English. It is a strange sight to see a senior developer spend three hours on a text file that has no actual code in it. No semicolons, no curly braces, just... bullet points and very sternly worded sentences.
It is the new reality of the stack, Corn. I am Herman Poppleberry, by the way, for anyone joining us for the first time. That file you saw was a Claude dot M D file, which is essentially the rulebook for how the AI agent behaves within that specific project. Today's prompt from Daniel is about exactly this phenomenon—the rise of these AI rulebooks. Daniel is seeing this shift where we are using structured natural language to program agent behavior, and he is wondering if we are witnessing the birth of a brand new programming paradigm. It is not quite coding, and it is definitely not just "chatting." It is something in the middle.
It certainly feels different from the early days of just chatting with a bot. Back then, you would just ask it to write a function, hope for the best, and maybe do a bit of prompt engineering if it failed. Now, we are seeing these persistent, stateful configuration files that act as a permanent set of guardrails. It is like we have moved from giving a one-time order to writing a constitution for the machine. We are defining the laws of the land before the agent even takes its first step.
That is a great way to frame it. We have reached a point where single-shot prompting is simply not enough for complex, agentic workflows. When you are using something like Claude Code, which had that significant update back in January twenty twenty-six, the model needs to know more than just the task at hand. It needs to know the architectural style of the project, the specific testing frameworks to use, and very importantly, the logic for when to use certain tools. This is not just a "fancy system prompt." It is a distinct architectural layer. In our episode twelve ten, "The Invisible Chaperone," we talked about how system prompts act as the hidden floor under the AI's feet. These rulebooks are more like the walls and the ceiling. They are the structural constraints that keep the agent from wandering off into a hallucination or, worse, deleting your source code because it thought it was "cleaning up."
I noticed in Daniel's notes that he has been specifically working on rules for when an agent should install a Model Context Protocol server locally versus on a managed server. That sounds incredibly specific. It is not just "be helpful," it is "if the latency is over fifty milliseconds on the managed instance, then pivot to a local installation." That is logic. That is a program. But it is written in English. It makes me wonder if we are actually making things easier or if we are just creating a new way to be confused.
And that is the friction point. We are in what I would call the assembly language phase of natural language instruction. In the early days of computing, you had to manage memory addresses manually. You were talking directly to the hardware in a way that was incredibly tedious but necessary. Now, we are manually managing the attention mechanisms of these large language models using bullet points and capitalized directives. We are trying to force a deterministic outcome out of a probabilistic engine. We are essentially trying to hack the transformer architecture to act like a logic gate.
Is it actually working, though? Because natural language is famously ambiguous. If I tell you to "be concise," your definition of concise might be three sentences, and mine might be three words. In a programming language, "concise" does not exist; there is only "valid" or "invalid." How do you solve that ambiguity when you are trying to build a reliable system out of words that mean different things to different people—and different things to different models?
You solve it through structure and what people are starting to call pseudocode for agents. If you look at a well-crafted rulebook today, it does not look like a letter to a friend. It uses nested hierarchies. It uses if-then-else structures. Developers are finding that if they use headers like CRITICAL or MANDATORY in all caps, it actually changes how the model weights those instructions in its context window. It is a form of manual weighting. We are learning that the model responds to the "visual" structure of the text—the indentation, the bolding, the numbering—almost as much as the semantic meaning of the words.
We talked about decision trees back in episode twelve ten when we were looking at system prompts, but this feels like it has evolved. It is not just a tree anymore; it is a full-on specification. But there is no compiler. There is no one telling you that you have a syntax error in your English until the agent goes off the rails and deletes a production database. That seems like a massive step backward in safety.
That is the big danger. We are seeing a phenomenon called instruction drift or context window attention decay. Research from late twenty twenty-five showed that as these rulebooks get longer, the models tend to prioritize the instructions at the very beginning and the very end, while the middle gets fuzzy. It is the "lost in the middle" problem but applied to logic. If you put your most important security guardrail in the middle of a five thousand word rulebook, there is a statistical probability the model will just ignore it when it gets busy processing a complex task. It is not that the model "forgot," it is that the attention weights were spread too thin across too many tokens.
So we are essentially fighting against the architecture of the transformer itself. We are trying to impose a linear, logical flow on a system that processes everything as a high-dimensional vector space. It feels like we are trying to build a skyscraper out of clouds. You can shape the cloud for a while, but eventually, the wind blows and the shape changes.
It is more like we are learning the physics of the cloud so we can shape it. For example, one of the emerging best practices is to use explicit priority stacks. You literally tell the model, "If rule A conflicts with rule B, rule A always takes precedence." You are building a manual resolution logic because the model cannot inherently rank the importance of two different sentences unless you tell it to. This is where the "pseudocode" mental model becomes really useful. You are not writing prose; you are writing a set of constraints that the model must satisfy simultaneously.
I wonder if this is why we are seeing people use almost mathematical notation in their prompts now. I have seen rulebooks that use brackets and arrows to show the flow of data. It makes me wonder if we are going to see a formal Prompt Specification Language emerge. Something that sits right in the middle between natural language and Python. A language that is human-readable but machine-verifiable.
I think that is inevitable. We are already seeing the early stages of it with things like the Model Context Protocol, or M C P. But beyond the protocol, we need a way to validate these instructions. Think about a linter for code. It checks for unused variables or syntax errors. We need an AI-driven linter that reads your rulebook and says, "Hey, your instruction on line fifty-two contradicts your security policy on line ten." We are moving from the "what" to the "how"—how do we actually ensure these rules are followed?
That would be a fascinating use of a smaller, faster model. You have a high-reasoning model like a Claude three point five or a four doing the work, but a smaller, highly-specialized model acting as the "logic police" for the rulebook itself. It would basically be an automated auditor for the agent's constitution. It would run simulations: "If I give the agent this input, will it violate rule seventeen?"
We are seeing the first versions of that in some of the more advanced development environments as of early March twenty twenty-six. They will actually run a simulation of the instructions before they go live. But the failure modes are still so unique to natural language. One of the biggest issues is what I call the "politeness trap." If you write your rules too softly, using words like "please" or "try to," the model treats them as suggestions. If you write them too harshly, the model can become overly cautious and refuse to do basic tasks because it is terrified of breaking a rule. It is the "alignment problem" on a micro-scale.
It is like managing a very literal-minded intern who also happens to have access to your entire file system. You have to be incredibly careful with your phrasing. This reminds me of the transition from punch cards to command lines. With punch cards, you had total rigidity but very little flexibility. You had to get every hole exactly right. With command lines, you got more flexibility, but you had to learn a specific syntax. Now, we have total flexibility with natural language, but we are desperately trying to re-introduce some of the rigidity of the command line so we can actually predict what the machine will do.
The historical parallel is spot on. Every time we move to a higher level of abstraction, we lose a bit of control, and then we spend the next decade building tools to get that control back. We moved from Assembly to C, then to Java, then to Python. Each step made us more productive but further away from the hardware. Now, the "hardware" is a neural network, and the "language" is English. But as we discussed in episode eleven twenty-two, "Beyond Words," we are hitting a biological bottleneck. Human language was never designed to be a high-precision instrument for machine control.
But English is a terrible programming language! It is full of idioms, cultural context, and double meanings. If I say "get rid of the bugs," an AI agent might delete my code, or it might just ignore the line because it thinks I am talking about actual insects. How do we bridge that gap without just inventing a new, more annoying version of Java?
That is why the "rulebook" approach is so important. It moves away from prose and toward structured data. If you look at the way Daniel is structuring his rules for local versus managed servers, he is likely using very specific triggers. He is not saying "use a local server if it feels slow." He is likely saying "monitor the response time of the managed server; if the p ninety-nine latency exceeds two hundred milliseconds over a five-minute window, initiate the local server deployment protocol." He is using the linguistic capabilities of the model to understand the context, but he is using the structure of the rulebook to define the thresholds.
That is the key difference. You are using the model's "judgment" to fill in the gaps that traditional code cannot handle. A regular program might crash if it encounters an unexpected network state. An AI agent with a good rulebook might see that the managed server is down, realize it cannot meet the latency requirement, and proactively switch to local without being explicitly told what to do in every possible "server down" scenario. It is the "spirit of the law" versus the "letter of the law." Traditional code is all "letter," and AI rulebooks allow for the "spirit."
But as any lawyer will tell you, arguing about the spirit of the law is a lot more complicated and expensive than following the letter. We are seeing that complexity play out in the context window. One of the most interesting technical challenges right now is how to keep these rulebooks "atomic." If you have one giant file with a thousand rules, the model gets overwhelmed. The trend is moving toward modular rulebooks. You have a core set of global rules, and then you have smaller, task-specific rulebooks that get "injected" into the context only when they are needed.
That sounds like a dynamic import in Javascript. You are only loading the "Local Server Installation" module when the agent is actually performing a server task. That would solve the attention decay problem because the model only has to focus on five rules at a time instead of five hundred. It keeps the "signal-to-noise" ratio high.
And that requires an orchestration layer. Something has to be smart enough to know which rules are relevant right now. This is where we see the interplay between the system prompt, the project-level rulebook, and the real-time instructions. It is a three-tier architecture for agent behavior. And it is not just about the rules themselves, but how they are stored. We are seeing developers treat these rulebooks just like code. They are in version control. They have pull requests. They have commit histories. If an agent starts acting weird on a Tuesday, the first thing the developer does is check the git log for the CLAUDE dot M D file to see what rule was changed.
So, "Prompt Engineering" was a bit of a misnomer. It was more like "Prompt Whispering" in the beginning—just trying things until they worked. Now, we are moving into "Prompt Architecture." You are building a structural framework that the agent lives inside. But I still worry about the "black box" nature of it. You can write the most perfect rulebook in the world, and the model might still have a random fluctuation in its weights that causes it to ignore a rule. In traditional code, if you write "if x equals five," it will always execute that branch when x is five. In an AI rulebook, there are three points of potential failure: the model has to "understand" the rule, "decide" to follow it, and then "execute" it correctly.
You are touching on the core limitation of this paradigm. We are trading determinism for capability. We want the rules to handle the ninety percent of standard cases, but we want the natural language capability to handle the ten percent of edge cases that we forgot to write a rule for. It is a hybrid. It is a machine-human interface where the human has to learn to think like a machine in order to tell the machine how to act like a human.
So, if I am a developer listening to this and I want to start building better rulebooks for my agents, where do I start? Because right now it feels like everyone is just making it up as they go along. Is there a "best practice" guide, or are we still in the Wild West?
The first step is to stop writing paragraphs. Use bullet points and clear hierarchies. If you have a set of instructions, use numbers to indicate priority. The model will naturally see "one" as more important than "five." And use those capitalized markers we talked about. "CRITICAL: Never share the A P I key" is much more effective than "Please ensure the A P I key remains private."
And what about the "pseudocode" aspect? Should we be using "if-then" statements in our English?
Yes, but keep them simple. Avoid deeply nested logic. If you have a rule that requires four different conditions to be met, the model is likely to miss one. It is better to break that into four separate, atomic rules. Instead of "If A and B and C then D," try "Rule one: Always check A. Rule two: If A is true, check B. Rule three: If B is true, execute D." It feels redundant to a human, but it is much easier for a model to follow without skipping a step. It is like writing a manual for a very smart person who is also incredibly distracted.
That is a great analogy. You have to be explicit, you have to be repetitive, and you have to be structured. And you have to watch out for "prompt bloat." I have seen rulebooks that are so long they take up half the context window before the agent even sees the user's request. You are paying for those tokens every time!
Prompt bloat is a real productivity killer. Every token you spend on a rule is a token you cannot spend on the actual task or the project's code. That is why modularity is so key. You should also have a "test suite" for your rulebook. Run the agent through ten different scenarios and see if it follows the rules. If it fails on scenario seven, you know you need to clarify that specific rule. We are moving toward a world of "behavior-driven development" for AI agents.
It is a bit ironic, isn't it? We spent decades trying to make computers understand us, and now that they finally do, we are spending all our time trying to learn how to speak their specific version of our language so they do not mess up our projects. We are meeting them halfway, but the "halfway" point keeps moving.
It is a new kind of literacy. We are learning to speak "Machine-Fluent English." It is a subset of our language that is optimized for logical consistency and attention weighting. And honestly, it might make us better thinkers in the long run. It forces you to be incredibly clear about what you actually want. You cannot be vague with an agent that has the power to refactor your entire codebase.
I don't know about that. I think it might just make us all talk like technical manuals. But I can see the value in it. Especially when you are dealing with something as complex as Daniel's example of managing local versus remote infrastructure. You cannot leave that to chance. If an agent is authorized to spend money or delete files, that rulebook is the only thing standing between a successful deployment and a total disaster.
We are going to see a lot more focus on "formal verification" of these natural language rules. Could we see a world where the rulebook is actually more valuable than the code it is managing? If the agent can write the code itself, then the human's primary job is just to maintain the rulebook. The "developer" becomes a "policy writer" or a "behavioral architect."
That is a massive shift for the industry. It changes what we need to teach in computer science. It is less about syntax and more about logic, ethics, and clear communication. We are moving from being the "builders" to being the "governors."
It is a return to philosophy in a way. If you look at the history of logic, from Aristotle to Boolean algebra, it was always about how to structure thought. Now, we are using those same principles to structure the "thoughts" of our machines. It is a very exciting time to be a nerd, Corn. We are defining the foundational laws of a new kind of intelligence.
You say that about every episode, Herman. But I have to admit, seeing the way these rulebooks are evolving is pretty wild. It feels like we are watching the foundation of a new civilization being poured, one bullet point at a time. And we are doing it in public! These files are sitting in open-source repositories on GitHub for everyone to see. You can go and read the rulebooks for some of the most advanced AI projects in the world right now. It is the most transparent "programming" has ever been.
Until someone figures out how to "prompt inject" a rulebook and trick the agent into ignoring its own constitution. That is going to be the next big security frontier. There is already a whole field of research into "robustness" for these rulebooks. How do you write a rule that cannot be overridden by a clever user input? It is an arms race between the people writing the guardrails and the people trying to jump over them.
Well, I think we have covered a lot of ground here. From the "assembly phase" of natural language to the need for AI-driven linters. It is clear that these rulebooks are not just a fad. They are a fundamental new layer of the technology stack. They are the interface. And as they become more standardized, we will look back on this era of "capitalized directives" and "bulleted decision trees" as the wild west of AI development.
Before we wrap up, let's give the listeners some concrete things to take away. If you are building an agentic system right now, how should you handle your rulebooks? First, keep it modular. Do not let your rulebook become a dumping ground for every random thought you have. Keep global rules in one place and task-specific rules in another.
Second, use explicit hierarchy. Don't just list things. Use numbers, headers, and priority markers. Tell the model what to do if two rules conflict. The more you leave to the model's "judgment," the more likely it is to surprise you in a bad way.
Third, treat it like code. Put your rulebook in version control. Write tests for it. If you change a rule, verify that it actually did what you intended without breaking something else. Use a smaller model to "audit" your changes if you can.
And finally, be aware of the "attention decay." Keep your most important rules at the very beginning or the very end of the file. The middle is the danger zone where instructions go to be forgotten. It is basically "Software Engineering One Oh One" but applied to the English language.
It is funny how the more things change, the more they stay the same. We are still just trying to tell a box of sand how to do what we want without it blowing up in our faces. But the box of sand is getting a lot better at understanding us. We just have to meet it halfway.
Well, I think that is a good place to leave it for today. This has been a fascinating look into the world of AI rulebooks. It is definitely something we will be keeping an eye on as the technology continues to evolve throughout twenty twenty-six.
Definitely. There is a lot more to explore here, especially as we see more formal frameworks start to emerge.
Thanks as always to our producer, Hilbert Flumingtop, for keeping the show running smoothly.
And a big thanks to Modal for providing the GPU credits that power this show. They make it possible for us to dive deep into these technical topics every week.
This has been My Weird Prompts. If you are enjoying the show, a quick review on your podcast app really helps us reach new listeners and keeps the project growing.
You can find us at myweirdprompts dot com for the RSS feed and all the ways to subscribe. We are also on Spotify and Apple Podcasts.
And if you have a prompt of your own, send it over to show at myweirdprompts dot com. We love hearing what you are curious about.
Until next time, keep experimenting with those rulebooks.
Just don't let the agents rewrite them while you're sleeping. Goodbye, everyone.
Goodbye.
