By the end of this post you will understand why an AI coding tool that seemed to know your project inside out on Monday has no idea what it did when you come back on Tuesday. The reason is mechanical, not a fault in your tool, and once you see it the rest of the vibe coding problem makes sense.
The AI does not have a memory in the way you do
When you work with a person, they remember. You had a conversation last week about how the boss fight should work, and they carry that forward. You do not have to repeat it.
An AI model does not work that way. It does not store your conversation anywhere inside itself. Every time you send a message, the tool hands the model a bundle of text: your current message, the earlier messages in this conversation, and often some of your project files. The model reads that bundle from the top, produces a reply, and then it is done. Nothing is kept. The next message starts the process again with a fresh bundle.
The bundle has a size limit
That bundle of text has a maximum size. The technical name for it is the context window. Think of it as the model's desk. Everything the model can see has to fit on the desk at once. Anything not on the desk does not exist, as far as the model is concerned.
The desk is large. It can hold a long conversation and a good number of project files. But it is not infinite, and a game project that has been going for weeks produces far more text than it can hold: every prompt, every reply, every version of every file.
When the conversation gets too long for the desk, the tool has to make room. Different tools handle this differently. Some quietly drop the oldest messages. Some write a summary of the earlier conversation and keep only that. Some ask you to start a new session. Whatever the method, the detail from earlier is no longer in front of the model. It may still be in a log somewhere, but the model is not reading it.
What happens when you close the window
Closing the session and coming back tomorrow is the sharpest version of this. The desk is cleared. The new session starts with your project files as they now exist on disk and nothing else.
The files are the only thing that carried over. The reasons behind the files did not. The model can see that a function exists. It cannot see that you and it spent two hours on Monday getting the jump timing right, that you tried four values before settling on the fifth, or that the odd-looking line near the top is there because removing it broke the sound. None of that is in the files. It was in the conversation, and the conversation is gone.
Why the model cannot tell you what it changed
This is the part that surprises people most. You ask "what did you change yesterday?" and the answer is vague, wrong, or a confident guess.
The model is not being evasive. It has no record to consult. Asking it what it did yesterday is like asking a stranger what you did yesterday. They can look at the evidence and make a reasonable guess. They cannot know.
Some tools now offer a memory feature, where the tool saves notes between sessions and puts them back on the desk next time. That helps. It is worth knowing that those notes are written by the model, so they inherit the same limits: the model summarises what it believes it did, which is not always what it did. A note that says "fixed the jump" does not tell you that the sound file was also touched.
What this means for your project
The practical consequences follow directly.
Within a session, the model knows your project only as well as what is on the desk, and late in a long session that may no longer include the reasoning from two hours earlier. Across sessions, the model knows only what is in the files. Any reason, any decision, any "do not touch this" that lived only in conversation is gone.
The record of why the project works has to live somewhere other than the model's memory, because the model does not have one. In traditional programming that record lives partly in the code itself, written by a person who understood it, and partly in notes and version history kept by that person. In vibe coding the person did not write the code, so that record does not get made unless someone makes it deliberately.
The honest version of the fix
The fix is not a better AI. A model with a larger desk delays the problem but does not remove it. Sessions still end. Summaries are still lossy. The model still cannot verify its own past.
The fix is a record kept outside the model, in plain words, at the moment things work: what the game does right now, what you decided and why, what the AI said it changed, and what actually changed in the files. Then when the next session starts cold, the reasons are on the desk again because you put them there.
You can keep that record by hand in a text file. The discipline is doing it before asking for the next change rather than after something breaks.
Fate Tracker Build Memory is a Windows tool built for this specific gap. It keeps a per-project record alongside the game: the reasons a build worked, the decisions the owner made, what the AI claimed to change against what actually changed, and a verified recovery copy of the working version. It does not give the model a memory. It gives you one that the model can be shown.
More guides
This is one of a series of plain-language guides to building with AI coding tools. See all guides.
Ask Aquila