It doesn't matter which AI model you use

Every few weeks there's a new best model. A new benchmark, a new coding tool, a new thread explaining why everything you set up last month is out of date. It's easy to spend your time there.

It's also mostly the wrong thing to pay attention to. Models do differ, and sometimes one is clearly better at a task. But give a strong model a vague request and you get a plausible answer to a question you didn't quite ask. Give any decent model your goals, your constraints and what good looks like, and you get something you can work with. The gap between those two results is bigger than the gap between the models.

So the first question I ask isn't which model to use. It's what the model needs to know, in what order, and who checks the result.

Tools change, what you know doesn't

A model is a rented part. It will be replaced within months, by the vendor or by you. The tool around it changes almost as fast. If your way of working lives in one tool's settings, or in the chat history of last Tuesday, you start over every time.

What lasts is what you know about your product. Who it's for. What you decided and why. How you want things built. What good looks like. That's worth writing down somewhere you own.

Markdown is the interface

Markdown is plain text. Every model reads it well, and so does everyone on your team. It sits in your repository next to the code, so it has a history, it can be reviewed and anyone can change it. There's nothing to export and no account to lose.

A long prompt is gone when you close the window. A file gets better every time something goes wrong. That's the habit that matters most: when the model gets something wrong, don't only correct it in the chat. Ask what the file should have said, and change the file.

This is the shape I'd start with:

AGENTS.md                    always true: the product, the stack, the rules
docs/
  discovery/                 interviews, opportunities, open questions
  decisions/                 what we chose and why, one file each
  specs/                     what we're building now
skills/
  synthesize-interviews/
    SKILL.md
  write-spec/
    SKILL.md
agents/
  reviewer.md

There are three layers in there.

• Context is what's always true: what the product is, who it's for, the conventions and what to avoid. It's read at the start of every session, so every line has a cost. Keep it short and let it point to the rest.
• Memory is what has been decided and learned: specs, decisions, discovery notes. The model reads these when they're relevant.
• Procedures are how recurring work gets done. Those are the skills and agents, and I'll come back to them.

You don't have to write any of this from scratch. As I wrote in How AI changed how I work, have a conversation first, let the model draft the file, then correct every line that's wrong.

In software development

The order of the work matters more than the model doing it.

1. Write the spec first. The problem, the outcome, what's out of scope and how you'll know it works.
2. Ask for a plan before any code. Let the model read the codebase and write the plan down, then read it yourself. Correcting a plan costs a sentence. Correcting a build costs an afternoon.
3. Build in small steps. Give the model a way to check its own work, like tests or a command it can run.
4. Review in a fresh context. A model that just wrote something tends to agree with itself.
5. Write down what you learned. A decision goes in docs/decisions. A mistake that could happen again goes in the root file.

The decisions folder helps most in older codebases, where business logic sits in places no one remembers the reason for. The model can't guess that history. It can read it if someone wrote it down.

In product discovery

Discovery needs structure even more than code does. Code runs or it doesn't. A summary of ten interviews always reads well, whether it's true or not. There's no test suite that tells you the model made up a pattern, so the structure has to do that job.

• Keep raw material raw. One file per interview, with who and when. The synthesis goes in a separate file that links back.
• Require evidence. Every insight cites an interview and a quote. Without a quote, it's labelled a hypothesis.
• Ask for what contradicts it. Models tend to follow where you're already heading. Ask separately what in the material argues against your conclusion.
• Keep problems and solutions apart. The opportunities file doesn't contain features yet.
• Write assumptions so they can be tested. What we believe, what would prove us wrong, and the cheapest way to find out.

The other advantage is that discovery and development now share one place. When the model builds the feature, it can read why the feature exists. So can the next person who touches it.

Skills and agents are not the same thing

These two words get used loosely, but the difference is simple.

A skill is a written procedure. An agent is a worker.

A skill is a folder with a markdown file in it, sometimes with templates or scripts next to it. It says what the task is, when it applies, which steps to follow and what a good result looks like. It doesn't do anything on its own. The model sees only the short description until a task calls for the skill, and then reads the rest. That's why you can have dozens without filling up the conversation. A skill runs inside your current session, and it sees everything that session sees.

---
name: synthesize-interviews
description: Turn interview transcripts into insights backed by evidence. Use when asked to analyse or summarise user interviews.
---

1. Read every transcript in docs/discovery/interviews.
2. List what people did, separately from what they said they want.
3. Group the findings into themes. A theme needs at least two interviews.
4. Quote and cite the source file for every claim.
5. End with what contradicts these themes and what we still don't know.

An agent is a model in a loop with tools. It gets a goal, decides the next step, acts, looks at the result and carries on until it's done. Your coding tool is already one. Most of these tools also let you define sub-agents in a markdown file: a role with its own instructions and often its own limits. The important part is that a sub-agent works in a separate context. It sees only what you hand it, does the work and returns a result.

---
name: reviewer
description: Reviews a change against its spec. Use after a feature is built.
---

You review work you did not write. You only read, you never edit files.
Read the spec and the change. Report what doesn't match the spec,
what could break and what is missing a test. Most serious first.
If you find nothing, say so.

A skill answers how do we do this? An agent answers who does this, and what can they see?

• Use a skill when you keep explaining the same task and want it done the same way every time. My Promo Film project is a skill.
• Use an agent when the work benefits from being separate: reading a lot of material that would clutter your session, running several tasks in parallel, or giving a judgement that shouldn't be coloured by how the work was done. A review is the clearest case.

Think of a recipe and a cook. A recipe doesn't cook anything, and a cook without one improvises. They also combine: a reviewer agent can follow your review skill.

Start with skills. They're cheap to write and easy to fix. A team of agents working from vague instructions only produces vague work faster.

How to keep it agnostic

• Write for a reader. Plain markdown, plain sentences. If a new colleague could follow it, a model can too.
• Keep one source. Many tools read AGENTS.md, but some want their own filename, like CLAUDE.md. Make that file a link to the same document instead of a copy, because copies drift.
• Describe the action, not the tool. Write "search the codebase for existing components", not the name of one tool's command.
• Keep vendor settings at the edge. Which model, which permissions and which folder a tool looks in are adapters, not the method. Skills are an open format that many tools now read, though the folder they expect can differ. Sub-agent files are less portable, so keep the role description in plain text and treat the wrapper around it as disposable.
• Test by swapping. Run the same task on a different model. If the result falls apart, the knowledge is in your head or in your tool, and not yet in your files.

What this doesn't fix

Files don't make decisions. They get you to the decision with better material, and the call is still yours.

Structure can also become a way of not doing the work. Don't build the whole tree on day one. Start with one root file. Write a skill the third time you explain the same thing. Add an agent when you notice work that should be done apart from the rest.

And files go stale. A wrong file is worse than no file, because the model believes it. Delete what's no longer true.

The models will keep changing. I'd rather spend my time on the part that stays.