Why I keep my rules in plain files
Async Digital Ltd Cardiff, UK
Working with an AI assistant on a long-running project builds up a body of rules, observations, and small decisions that shape how the assistant behaves for the developer who taught it. That teaching is professional capital. In most setups it lives inside one product, in vendor-specific directories and formats, and would not travel if the developer switched assistants. Keeping the same rules in plain markdown files in a folder I own makes the assistant the runtime, not the storage. The assistant becomes interchangeable; the teaching stays mine.
The most valuable thing I'm building alongside the assistant is the body of teaching I've given it. I keep that teaching in plain files. This note is about why.
The capital builds up whether you name it or not
Every time I correct the assistant on a phrasing, a file layout, or a naming convention, I’m teaching it something it didn’t know yesterday. Every time I capture a lesson from a bug into a rules file, I’m widening that body of teaching. The teaching compounds. After a few months, the assistant behaves differently for me than it would for someone who started yesterday.
This is the part most people miss. The assistant feels like a tool. The teaching feels like a workflow tax. But the teaching is the asset.
The asset is trapped
In most setups, the teaching lives inside the product. Settings in a vendor-specific directory. Memory entries in a vendor-specific format. Skill definitions only one tool knows how to load. Even plain-prose rules end up phrased in that vendor’s terms.
If I switched assistants tomorrow, I’d start from zero. Months of teaching, gone. Or rather, still on disk, but not legible to anything else.
This is the bit that ought to feel uncomfortable. The most valuable thing I’m building is sitting in someone else’s filing cabinet.
Why this matters for a one-developer studio
Async Digital is one developer. The rules and reflexes I’ve taught the assistant are what make a one-person studio capable of more than one person’s work. They function the way an agreed working style functions inside a small team. I’ve built them up alone, over months, file by file.
If those rules are stuck inside one vendor’s product, what makes me effective is rented. If they travel with me, it’s mine.
The assistant as runtime, not storage
The setup is straightforward. The rules live in plain markdown files. The state lives in plain markdown files. The configuration lives in a plain git repo. If a different assistant could read those files, it could pick up where this one left off. The assistant becomes the runtime, not the storage.
I’m not all the way there. The current setup still leaks vendor-specific shape in places. But the direction is settled, and most of the body is already in a portable shape.
The IDE analogy
The reason this matters isn’t fear of any one vendor. It’s the same reason a developer learns the language and not the IDE. The IDE comes and goes; the language stays. I want the teaching to be like the language. The assistant can be like the IDE.