Your AI Coding Assistant Doesn't Remember Last Week's Decisions

There's a project I looked at recently where the same "soft delete" pattern had been implemented three different ways across three parts of the app. One table used a deleted_at timestamp. Another used a boolean flag. A third just left rows in place and filtered them out with a status column that meant something slightly different depending on which screen you looked at. Nobody had decided this. It had happened, one AI-assisted coding session at a time, over a few months.

That's the bit people miss when they hear that AI can write code fast. The code itself might be fine, line by line. What breaks down is consistency, because most AI coding tools don't actually remember what happened last week.

Why the memory gap exists

Tools like Cursor, Copilot, or Claude Code work within a context window. Give them the right files and the right prompt, and they'll produce something sensible in the moment. But once that session ends, the reasoning behind a decision doesn't automatically carry forward to the next one. Open a new chat, or come back the next day, and the assistant is working from whatever it can infer by reading the code again, not from a memory of the conversation where you decided that "cancelled" orders get archived, not deleted.

There's active work in the AI tooling world trying to fix exactly this, building git-native memory systems so an agent can look back at commit history and prior notes rather than starting cold each time. That's a sign the problem is real and widely felt, not something I'm making up to sell development work. It's a genuine gap in how these tools operate today.

What it actually costs you

The damage isn't dramatic. It's not a crash or an outage. It's slower, and it accumulates:

• Duplicated logic. The same validation rule gets written twice, slightly differently, because the second session didn't know the first one existed.
• Security patterns applied inconsistently. One API route checks permissions properly. Another, built in a later session with no memory of the first one's approach, doesn't.
• Naming drift. Is it customer or client in this table? Depends which session named it.
• Decisions get silently reversed. Someone decided three months ago that discounts shouldn't stack. A later session, with no record of that call, quietly lets them stack again because nothing in the code explicitly forbids it.

None of this shows up in a demo. It shows up eighteen months in, when someone tries to add a feature and can't work out which of the three patterns is the "real" one, or when a bug appears because two parts of the system disagree about what a status field means.

What actually solves it (hint: it's not a bigger context window)

A bigger context window helps a bit. It doesn't fix the underlying issue, which is that decisions need to live somewhere more durable than a chat transcript. The practical fixes are unglamorous:

• A decision log. A short, dated file in the repo that says "we chose X over Y because Z". Not exhaustive, just enough that the next session, human or AI, doesn't reinvent the argument.
• Consistent naming conventions written down, not assumed. If it's not documented, it will drift.
• A human who's been on the project the whole time. This is the part that's easy to underrate. An AI agent has no continuity unless you build it in. A person who's worked on your codebase since the first commit does, without you having to engineer it.

This last point is why I think solo, direct-relationship development actually has an advantage right now, not a disadvantage. When I build something for a client, I'm not handing work between people who each only see their slice of it. I remember why a table is shaped the way it is, because I shaped it. If a client comes back eight months later wanting a new feature, I'm not reverse-engineering my own decisions from scratch, and I'm not trusting an AI agent to have correctly inferred them either.

What to check if you're relying on AI-heavy development

If you're working with a developer, agency, or in-house team that leans heavily on AI coding tools (which, at this point, most do), it's worth asking a few direct questions:

• Is there a written record of key decisions, or does it all live in someone's chat history?
• Who actually reads and understands the generated code before it ships, and do they know the project's history well enough to spot a contradiction?
• If the person who's been running the AI sessions left tomorrow, would anyone be able to make sense of the codebase?

If the honest answer is "not really", that's not a reason to panic, but it is a reason to get a decision log started now rather than in two years' time when the inconsistencies have multiplied. It's also worth reading about who actually checks AI-generated code if you want a fuller picture of where the risk sits.

None of this is an argument against using AI tools to write code. I use them myself, daily. It's an argument for treating memory and continuity as something you have to deliberately provide, whether that's through documentation, through process, or through keeping one person on a project long enough that they simply remember why things are the way they are. The tools are fast. They're just not the ones holding the history.