Your repository is your memory

The first thing I recommend to anyone starting to build anything with AI — a product, an automation, even a personal agent — isn’t an AI tool. It’s creating a repository.

It sounds like advice from one programmer to another. It isn’t. If chapter 8 said the model only knows what’s in the window, this one answers the next question: where do you keep everything that needs to go back into the window tomorrow?

What is a repository, anyway?

Git is a system that keeps every version of a folder of files. It came out of the Linux community, led by Linus Torvalds — the story is short and good. You know the version history of an online document? It’s that, for an entire project and with a lot more control.

GitHub is a website that hosts those versioned folders — the repositories — and adds what’s missing for working in a group: permissions, review, discussion.

The minimum vocabulary:

• Commit: a saved version, with a description of what changed. One small project of mine has more than a hundred; each one is a point I can go back to.
• Branch: an offshoot, like a branch on a tree. A parallel timeline where you experiment without touching what’s working. It’s the image of timelines branching off, common in time-travel stories.
• Pull request (PR): the request to join your branch back into the main line. “Look what I did. Can it go in?”
• Review: someone looks at the PR before approving it. On my team, I review what a teammate does and they review what I do — and an AI reviews us both.
• Merge: the approved branch joins the main line.
• Rollback: it went wrong, so you go back to the previous version. Nothing is lost.

Why does this matter so much with AI?

Because you can make mistakes without fear. An agent is going to touch your files. Sometimes it will do it badly. With Git, the worst consequence is “go back one version.” Without Git, it’s “I hope I have a copy.”

Because the agent handles the paperwork. I don’t create branches by hand. One of the projects I work on has more than a thousand, all created and managed by agents. My role is to say what I want and review what shows up in the pull request.

Because it works for teams. Humans and agents working on the same project need a place where nobody steps on anybody else’s work and every change goes through someone before it takes effect.

Because it’s your memory. This is the least obvious point and the most valuable.

Where does a project’s memory live?

Code is only part of what I keep. The other part is everything I don’t want to explain twice — to an AI or to a person.

# Rules for this project
- Never commit directly to the main branch; open a PR.
- Real client data doesn't go into tests. Use /fake-data.
- Before saying you're done, run the tests and show the result.
- Decisions already made are in docs/decisions. Read them before proposing anything.

Who writes these documents? Most of the time, the AI itself, at my request: “generate the documentation for what we learned in this session.” I read it, fix it, and commit.

What if the trendy tool changes tomorrow?

Because the knowledge lives in plain text files, in a repository that’s mine, I can switch AIs whenever I want. I use three different vendors on purpose. It was painful at first, but today any of them opens the project, reads the same files, and carries on with the work.

For me, models have become a commodity — I was already saying so a while back, comparing it with what happened to the cloud: the difference between the best ones is more a matter of taste than of capability. What isn’t a commodity is your project’s context — and that shouldn’t live inside a vendor’s account, or inside a specific agent framework. If the trendy tool changes tomorrow, you plug the next one into the same repository.

The same goes for people. Someone new joined the team? Give them access to the repository. The decisions, the rules, and the history are already there.