The going advice for coding agents seems to be to point Cursor at your repository and hope. That is not a workflow, it is a way to generate technical debt at speed. Manage your AI coding agent context deliberately or you are paying a subscription for confident wrong answers that eventually reach production.
I have been building on WordPress since the 4.x days and I have seen a checkout break in most of the available ways. The newer variety is AI spaghetti: code that runs, looks plausible, and ignores everything specific about the project. It happens when Claude Code or Cursor gets treated as a black box instead of a tool that needs to be told where it is.
Why the context gets messy
The context you hand over is the only map the agent has. Outdated, or padded out with fifty files that have nothing to do with the task, and it fills the gaps itself. In WordPress that shows up as a deprecated hook, or a race condition because nothing in the context mentioned your object cache. The padding costs you twice as well, since every irrelevant file is tokens and latency on each turn.
Three habits fix most of it. They cut my debugging time roughly in half on complex WooCommerce builds.
1. AGENTS.md as the project’s memory
Agents forget your preferences the moment the tab closes. An AGENTS.md at the project root, or .cursorrules if that is your tool, is where those preferences live instead. Tech stack, naming conventions, which hooks you expect it to use. Treat it as the README the agent reads first.
# Project Context: Custom WooCommerce Plugin
- Use PHP 8.2+ syntax (strictly typed).
- Prefix all custom functions with bbioon_.
- Always use the Options API instead of Transients for persistent settings.
- Never use direct SQL queries; use WP_Query or the CRUD classes.
- Documentation: https://developer.wordpress.org/reference/When the agent gets something wrong, say an old version of the Stripe API, I correct it and tell it to write the correction into AGENTS.md. The file grows into a list of mistakes the project has already made, and that particular one stops coming back.
2. Documentation links and your actual schema
The knowledge cutoff is a real constraint. Ask about a new library or a WordPress 6.7 feature and the model is working from whatever it saw a year ago. Paste the documentation link and it reads the current syntax rather than reconstructing something that looks like it.
Your infrastructure files and database schema belong in the AI coding agent context for the same reason. I once lost two hours watching an agent query a table I had renamed in a migration, because nothing told it otherwise. Now there is a SCHEMA.md listing table names and primary keys, and it no longer has to guess what my database looks like.
3. Start a new thread when the task changes
The habit I have to keep breaking is leaving one chat thread open for days. It fills up with stale logs and superseded versions of the same function, and the model is still reading all of it. Finish the REST API endpoint, then open a fresh thread for the CSS bug. I made the same argument in my post on stopping vibe coding.
If wiring agents into an existing codebase is eating your week, I take this on as contract work. I have been building on WordPress since the 4.x days and I know where these tools tend to do damage.
Where to start
Write the AGENTS.md today, even a short one, and add to it every time you correct the agent. Keep the documentation links and the schema file close by, and close threads more often than feels necessary. My guide on robust custom AI assistants goes further into the setup. The agent will guess whatever you leave out, so leave less out.
