Every new chat starts from zero. You spend ten minutes re-explaining that this WordPress site runs a custom boilerplate, that you hate Tailwind, and that every helper function needs your own prefix. Then you close the tab and do it again tomorrow. Until you close the AI coding assistant memory gap, you are the state manager for a tool that was supposed to be doing the heavy lifting.
Why the chat forgets you
Large language models (LLMs) are stateless by design. They do not remember who you are or what you built yesterday. Every session starts empty, inside a context window with a hard token limit, and when the chat closes, the architectural decisions you talked through go with it. That leaves you as the “human-in-the-loop,” the one assembling context and re-explaining the same conventions every morning.
Short-term memory lives in the current session: the open files and the recent chat history. Long-term memory is the part that survives a restart, and that is what context engineering is for. It is the deliberate assembly of what the AI needs to finish a job without you supervising every step of it. If hallucinations are the problem you are hitting, I wrote about stopping AI coding agent hallucinations through better context.
Level 1: a project rules file
The most practical fix for the AI coding assistant memory problem is a project rules file: a markdown file at the root of the repo that tools like Cursor and Claude Code read on their own. For WordPress work, this is where you pin your standards so the assistant stops reaching for vanilla PHP when a core WP function already does the job.
# .cursor/rules (or CLAUDE.md)
# WordPress Stack
- PHP 8.2 with WooCommerce 8.x
- Use bbioon_ prefix for all functions
- Prefer WP_Query over global $wpdb
# Interactivity
- Use Vanilla JS for simple DOM manipulation
- No jQuery unless it's a legacy plugin fix
# Commands
- Lint: ./vendor/bin/phpcs --standard=WordPress .
- Fix: ./vendor/bin/phpcbf .That memory travels with the codebase. When a new developer clones the repo, their assistant already knows how things are done here, so onboarding costs less and the output does not drift from one session to the next.
Level 2: global rules and implicit memory
Project rules cover the technical specifics. Global rules cover your preferences: brief answers, readable code instead of clever one-liners, that sort of thing. The more interesting move is implicit memory. Anthropic’s memory tool and Claude Code’s auto-memory watch how you work and keep notes, so the way you usually chase down a race condition is already there the next time something breaks.
If you want to push this further, I wrote about how to use OpenClaw to make a personal AI assistant. It runs context engineering hard, keeping writable memory files that change as the agent picks up your habits.
MCP and custom infrastructure
On a big team, a rules file runs out of room. That is where the Model Context Protocol (MCP) comes in: it lets the assistant reach external data such as Jira tickets, Slack history, or a vector database (RAG). Martin Fowler makes the point in his piece on context engineering that context is the current bottleneck for coding agents. A bigger token window does not help a model that is drowning in irrelevant data.
If this is eating your dev hours, hand it over. I have been working with WordPress since the 4.x days, and I have watched a context window collapse in about every way it can.
What I would actually do
The stateless chat window is an artifact of early tooling, and the assistants that come after it will carry a persistent memory layer that knows what your team already decided. Until then, stop paying the repetition tax. Write the Level 1 rules file, commit it, and let the assistant build on what is already in the repo. Context is a resource you manage, the same as any other.
