Nowadays I run four coding agents, while the vast majority of my colleagues is still on a single Claude instance. In my daily routine I have Hermes orchestrating the others: it holds the memory, the skills, the plan, and it decides who does what (check out how I got there). Oh-My-Pi (omp) is my daily driver, with the IDE wired in, so it renames semantically instead of guessing (omp from Hermes), and it is not tied to a single model: MiniMax 3.1 Flash and DeepSeek v4.1 Flash 1017 for the bulk of the day, the free MiniMax route on OpenRouter included, which on its own is one of the best value options I have found, Opus 5.5 when a task deserves a frontier model, local engines when I want zero cost and zero data leaving the machine. agy is Google’s Antigravity CLI, and it only runs Gemini 3.8 Flash (piloting Antigravity from Hermes): excellent with images, a mess for code. It earns its place because Hermes drives it end to end. Claude is the one everybody has an opinion about, and I keep it around as a second pair of eyes on the diffs I do not trust.
Four runtimes. Four sets of tools. Four completely different ways of failing. This post is focused on the file to rule them all: the AGENTS.md file, which is de facto standard, and that can be easily linked from CLAUDE.md and RULES.md.
TL;DR
- Karpathy’s January 2026 thread was a complaint, not a spec. Forrest Chang turned it into four rules, and those four are what the community now carries in a 220,000-star template.
- Mnimiy tested that template on 30 codebases for six weeks in May 2026 and added eight more, plus the 41% to 3% measurement that came with them.
- One file, many runtimes.
AGENTS.mdis read by omp, Codex, Cursor, Cline, Gemini CLI and most open-source harnesses, so the rules travel when the runtime does not. - Keep it under 200 lines. Past that, compliance falls off and the rules quietly stop applying.
How I Got Here
I did not plan a multi-agent setup. It accumulated, one frustrating session at a time.
The first version was me using just ChatGPT, then Claude and finally Claude Code. Then the context got too big and drained my credits too quickly, so I gave the agent a memory layer. Then one agent was not enough for a job that needed a plan, an implementation, and a review, so I started piloting one from another. That is Hermes: an orchestrator that drives other coding agents as execution backends, instead of always swapping my own runtime when I wanted a different model, using profiles with specific SOUL.md and so on.
I wrote about the mechanics in piloting Antigravity from Hermes and the runtime in omp from Hermes. What I did not write about is the part that annoyed me most: the rules.
The part that surprised me: the failure profile moves with the model, not only with the runtime. The same rule, worded the same way, lands differently on a flash model than on a frontier one.
The Lineage: Who Wrote Which Rule
Getting the attribution right matters, because the file people paste around has several authors and they all get merged into one.
Andrej Karpathy published a thread in January 2026 after weeks of working this way. It was not a framework, it was a complaint: agents assume instead of asking, they overbuild instead of solving the minimum, and they touch code nobody asked them to touch. He was blunt about the setup too. The “no IDE needed” claim is overdone; if the code matters to you, keep a close eye on the run in a proper editor next to it. Personally, I use Warp terminal to pilot my agents running 24/7 remotely, and I can simply have a tab alongside the terminal to watch my files and an integrated diff and much much more.
Forrest Chang read the thread and wrote it down as rules. That four-rule file is the one the community now carries in a repository with more than 220,000 stars, and half the ecosystem pasted it into their repos.
Mnimiy (@Mnilax, May 2026) took that four-rule file, ran it against 30 codebases for six weeks, and added eight more. His headline is the measurement: the four rules cut the mistake rate from 41% to 11%, and the twelve cut it to 3%, with compliance barely moving (78% to 76%). The eight are the ones I use, and the numbers below are his.
The Core: 4 simple rules
These are the original four, the ones the 220,000-star file is built on. They came out of Karpathy’s thread, they have not changed since, and they still cover the majority of what goes wrong.
Rule 1 - Think Before Coding
“The models make wrong assumptions on your behalf and just run along with them without checking. They don’t manage their confusion, don’t seek clarifications, don’t surface inconsistencies, don’t present tradeoffs, don’t push back when they should.”
Say what you believe the code does before you write a line. Ask instead of guessing when the answer would change the design. Speak up when a simpler approach exists. Never build on an assumption you did not state.
Rule 2 - Simplicity First
“They really like to overcomplicate code and APIs, bloat abstractions, don’t clean up dead code… implement a bloated construction over 1000 lines when 100 would do.”
Write the least code that solves the problem. No speculative features, no abstraction used once, no helper for a case that never happens. If a senior engineer would call it over-engineered, cut it back.
In this case I would also suggest to use this rule in combination with the Ponytail skill, it’s great to simplify code that in the 99% of the cases should be written like a ultra-lazy senior engineer.
Rule 3 - Surgical Changes
“They still sometimes change/remove comments and code they don’t sufficiently understand as side effects, even if orthogonal to the task.”
Change only what the task requires. Leave the neighbouring function, the comments and the formatting alone. Do not refactor what is not broken. Follow the style that is already there.
Rule 4 - Goal-Driven Execution
Decide what done looks like, then loop until it is met and checked. Do not write the procedure for the agent: give it the target and let it find the path.
In this gist you will find the same four, in the wording I actually ship.
The Eight Mnimiy Added
The following rules are Mnimiy’s, and each one closes a gap the original four never covered. The four gaps he names are long-running agent tasks, multi-codebase consistency, test quality, and the difference between prototype code and production code. Below is my own phrasing of each rule and the failure it closes.
Rule 5 - Use the Model Only for Judgment Calls
- Use the model for judgment calls: classification, drafting, summarisation, extraction.- Do not use it for routing, retries, status-code handling, or deterministic transforms.- If code can answer the question, then it's the code that answers it.Rule 6 - Token Budgets on top of max_turns and guardrails
For instance, using Hermes agent you can enforce max_turns to avoid infinite spinning. Believe me, it tends to be ridicolous in terms of token consumption and in credits spent per single session. Also, the same endurance shows up in my stack, where a supervisor agent will happily keep a subagent running past the point where the answer stopped changing.
- Token budgets are not advisory. - Per task: 4,000 tokens. - Per session: 30,000 tokens.- When a task approaches its budget, summarise the state and start fresh instead of pushing through.- Surface the breach rather than silently overrunning.Rule 7 - Surface Conflicts, Do Not Average Them
- When two patterns in the codebase contradict, do not blend them.- Pick the more recent or the more tested one, explain why, and flag the other for cleanup.- Code that satisfies both patterns is the worst code.Rule 8 - Read Before You Write
In my stack this rule is what stops a subagent from “fixing” a file it has only skimmed.
- Before adding code to a file, read that file's exports, its immediate caller, and any shared utilities it would use.- If you do not understand why the existing code is structured that way, ask before adding to it.Rule 9 - Tests Verify Intent, Not Just Behaviour
- Every test must encode why the behaviour matters, not only what it does.- A test that cannot fail when the business logic changes is the wrong test, and the function behind it is probably wrong too.Rule 10 - Checkpoint After Every Significant Step
This is the one that matters most in my stack, where an orchestrator hands work to a subagent and has to be able to resume from a summary.
- After completing each step of a multi-step task, summarise what was done, what is verified, and what is left.- Do not continue from a state you cannot describe back.- If you lose track, stop and restate.Rule 11 - Match the Codebase’s Conventions, Even If You Disagree
- Match the conventions of the codebase you are working in, even when you would have chosen differently.- Conformance over taste inside the codebase. If a convention is genuinely harmful, surface it instead of forking it silently.Rule 12 - Fail Loud
This is the one my own stack taught me, and it is not theoretical. Headless agy (what that cost me) auto-denies a file write and exits 0 with empty output. An orchestrator reading that exit code concludes the job is done, because nothing threw.
- If you cannot be sure something worked, say so explicitly.- "Migration completed" is wrong if any records were skipped silently.- "Tests pass" is wrong if any were skipped.- Default to surfacing uncertainty rather than hiding it.Averting the Slopocalypse?
What happens to the gap between the average engineer and the best one when both have agents? Are we going to see a real flood of machine-generated slop everywhere in terms of code produced?
As Linus Torvalds said few days ago, there is no point in avoiding genAI. It’s just another tool and the important thing is to understand what you’re doing. Tools are just… tools.
You have to understand how the whole systems work from the ground up, otherwise you won’t be able to control anything very soon and it will be a disaster. Having the right ideas will still be relevant and also maintaining the control of the full picture. I’ve designed new systems in 2026 and believe me, having a clear direction of what you actually want to achieve while knowing how things works behind the scenes makes the difference. I’ve seen juniors that believe they can do great things, but unfortunately it was just a sloppy and faded shadow of a real application that the LLM was just replicating or re-assemblying like a Frankenstein’s sloppy monster.
Hard boundaries
In my case, to keep the control over the machines as John Connor taught me back in the days, I also add guardrails and boundaries in my AGENTS.md files to enforce what the agent will be actually forbidden. For instance:
- **The human runs every command.** Do not execute terminal/shell commands in this repository unless the user explicitly asks for that specific command in that specific request.- **Never commit or push.** No `git commit`, `git push`, `git checkout`, rebasing, branch or tag creation, or history rewrites. The user handles all git operations and commits personally.- **No package-manager operations.** No installs, no lockfile edits, no dependency changes without human specific consent.