Nine chapters on the memory layer that changes what AI can build with you.
There is a particular rhythm to working with a good AI assistant on a real software project. You start with a rough sketch — the shape of the product, a few user flows, the piece of infrastructure you have been avoiding — and over the next few hours something quietly compounds. The model learns that your API returns snake_case, that your team decided against a message queue for the third time this quarter, that your billing logic depends on a subtle rule nobody has written down. Suggestions get sharper. Trade-offs get named. By the end of the afternoon you are not really giving instructions anymore. You are thinking out loud, and something intelligent is thinking with you.
Then you close the tab.
The next morning the same assistant greets you like a stranger. You ask it to review the endpoint you spent yesterday designing, and it asks you what the endpoint does. You mention the queue decision, and it enthusiastically proposes the queue again. You explain the billing rule, again, in the same careful sentences you used the day before. Somewhere between the third and fourth re-explanation you realise you are not building software anymore — you are onboarding a new hire, every single day, for the rest of the project.
Every developer who has spent serious time with AI tools knows this feeling. It is not a bug in any particular model, and it is not limited to a particular provider. As soon as the conversation ends, the understanding evaporates. The next session begins from zero. The intelligence resets.
That question is the reason CreateLixir exists, and the reason this series is being written. The system that answers it — the persistent, structured memory layer that keeps every AI teammate in sync with the project it is helping to build — is called the Project Brain.
This is a nine-chapter series. Each chapter stands on its own. Together they form one complete argument: what is missing from today's AI, what software projects actually require, what a memory layer looks like when you take those requirements seriously, and what changes about engineering once persistent understanding is in place.
You do not have to read them in order — but if you do, you will finish with a full picture of how AI-native software engineering is meant to work.
Modern AI does not fail to remember because it is careless. It fails to remember because remembering, in the way humans do it, is not part of how these systems are built.
Software is a body of accumulated knowledge, not just code. This chapter looks at what a project actually is — the architecture, decisions, constraints, and invariants that make it more than the sum of its files.
Every new AI session begins from zero. This chapter looks at the practical, engineering-wide cost of that reset — for founders, for teams, and for the codebase itself.
The core chapter of the series — what Project Brain is, why it is the right shape for the problem, and how it differs from context injection, RAG, and long conversation history.
A tour of the layers of memory Project Brain holds — identity, product, target users, architecture, design system, decisions, constraints, risks, and knowledge — and why each of them matters.
The mechanics chapter — how Project Brain is queried, how it composes context for every AI teammate, and how it stays consistent as the project evolves.
How Project Brain participates in every phase of a project — from the first planning conversation with the AI Architect through code, review, deployment, and postmortem.
The synthesis chapter — what changes about AI-assisted engineering once persistent memory is in place, and why it is the missing primitive for autonomous AI teams.
The closing chapter — where persistent memory in AI is heading over the next decade, and what a mature memory layer will make possible that today's software cannot.
The team building CreateLixir — the Operating System for Software Creation.
One email a week. No spam. Unsubscribe any time.