A few months ago most of my day was writing prompts. A prompt for the agent that fixes a bug, another for the one that writes the tests, a long rules file so they would not forget how my servers work, hooks to stop them from doing something stupid. Today I don't write prompts for agents anymore. I talk to one chat, and the agents write their own prompts.
This is not about a product. It is about a habit I think we should drop: treating every new model like the old one and wrapping it in more rules.
How it works now
I have one conversation, with Claude. I tell it what I want in normal words: "the SEO on this site is weak", "release the new version of the API", "find out why the backups were slow last night". I don't say how.
Claude turns that into tasks and sends each one to an orchestrator. An orchestrator is an agent that owns one area: one project, or one part of a project. I can have several per project, each with a narrower job. One looks after features, one only after SEO, one only runs and fixes the tests.
When an orchestrator gets a task, it builds its own team. It decides how many agents it needs, writes the brief for each one, starts them, checks their work and sends them back if something is wrong. When the task is really done, it reports back up, and I see the result in the same chat.
The agents prompt themselves
This is the part that changed the most for me. The orchestrator knows the task, the code and what already went wrong, so it writes a better brief than I would. It is also faster, and it does it again every time something changes.
The loop each orchestrator runs is simple:
Why I stopped adding rules
Every rule, memory file, skill and hook I wrote was a fix for something a model got wrong at some point. The problem is that the model changes every few months and the rules stay. They were written for last year's model, so they slowly turn from help into a ceiling.
I am not the only one who thinks so:
- Anthropic's guide to context engineering says that smarter models need less prescriptive engineering and can work with more autonomy, and warns against brittle, hardcoded prompts.
- Their older Building effective agents post says the same thing from the other side: start with the simplest thing that works and only add complexity when you need it.
- Chroma's Context Rot study found that models get less reliable as the input grows. Every rule you load is input the model has to carry on every task.
- Rich Sutton's The Bitter Lesson is the long version: general methods that use more compute keep beating the knowledge we try to hand-code into them.
None of this says "remove all structure". It says: keep only what the current model actually needs, and test that again when a new model comes out.
Stop asking for permission on every command
The same goes for permissions. Approving every ls and every git status does not make anything safer. People just click yes. Anthropic measured this when they built auto mode for Claude Code: users accepted 93% of permission prompts. With sandboxing they cut prompts by 84% and the agent got more autonomous, not less safe.
My rule now is short: block the few commands that can really hurt (deleting data, touching production secrets, force-pushing), and let the agents do the rest without asking. A newer model doesn't need a hand on its shoulder for every step, and asking makes it slower, not smarter.
Fresh eyes beat old rules
Felix Rieseberg wrote Hunger beats tenure, advice for junior engineers. His point: execution is cheap now, so years of accumulated knowledge matter less, and the person with fresh eyes who asks "why do we do it this way?" can move faster than the senior who stopped asking. He prefers a working prototype over a long spec.
I think the same is true for models. Every new model is the hungry newcomer. If we hand it a thick binder of rules written for the old one, we turn it into the tired senior who does things a certain way because that is how they were always done. Give it the goal, the access it needs and a few hard limits, and let it build something you can look at.
What I would do
- Keep one conversation where you say what you want, not how.
- Let orchestrators write the agents' prompts. They have the context. You don't.
- Give each orchestrator one area: a project, or a part of it like SEO or tests.
- Block only the dangerous commands. Let everything else run.
- With every new model, delete rules and see what still breaks. Usually less than you expect.
I run all of this in my own tool, Tree Next, which will be on GitHub soon. But the tool is not the point. The point is to stop holding the models back with instructions they have already outgrown.