Choosing an Agent for PHP and WordPress Work

Every comparison you will read asks which agent writes better code. That is the question you cannot answer from the outside, because the answer depends on your repository, your task and the version of the model that shipped last Tuesday. The questions you can answer before spending anything are narrower and more useful.

There are two of them. Can the agent execute commands on the machine where WordPress lives, and can you tell it what it needs to know in a file you commit? An agent with both is usable for WordPress work today regardless of which model it drives. An agent with neither produces plausible PHP that you will be debugging by hand, and the model quality will not save you from that.

Command execution decides whether the loop can close

The previous lesson established the loop: read, edit, run, observe. Everything in this course assumes the agent can run things, because the alternative is that you become the execution layer. You run the code, copy the error, paste it back, and wait. That works, and it is slower than it sounds, because each round trip costs you the context switch and the agent loses the ability to run the twenty small checks that would have narrowed the problem.

Ask three questions about execution before anything else. Does the agent run commands by default, or only after you approve each one? Does it have a sandbox, and if so what can the sandbox reach? Can it be configured to run without prompting inside a directory you choose? The answers change your working day: a sandbox that blocks network access cannot install a Composer dependency, and an approval prompt per command turns an agent into a very fast terminal you still have to drive.

For WordPress specifically, the commands that matter are wp, php, composer, npm and the database client. An agent that cannot reach a running WordPress can still write a plugin. It cannot tell you whether the plugin activates.

An instruction file beats a better model on the first attempt

The second question is whether the agent reads a committed file of project instructions. Every current agent does this in some form, and the details differ enough to matter.

The convention to standardise on is AGENTS.md, a plain Markdown file with no required fields, stewarded by the Agentic AI Foundation under the Linux Foundation and read by Codex, OpenCode, Cursor, GitHub Copilot, Claude Code under conditions covered in the next lesson, and dozens of other tools. It sits at the root of a repository and does the job a README does for a new colleague: what this project is, how to run it, which commands are safe, and what not to touch.

Cursor adds a trap that catches people migrating guides. Its rules live in .cursor/rules/*.mdc with frontmatter for description, globs and alwaysApply, and a plain .md file in that directory is ignored. If you copy a rules file from an article and it does nothing, the extension is why. Cursor also supports AGENTS.md as a simpler alternative, which is the option to prefer if you want one file that other tools can read too.

Antigravity, the replacement for Gemini CLI, documents behavior rule sets and SKILL.md files, but whether it honours AGENTS.md was not confirmed against its own documentation. Treat that as open and check it on your install rather than trusting a table.

The line-up, and what each one is for

Prices below were taken from each vendor's own pages on 16 October 2026 and will move. The column that will not move as fast is the one about instruction files, because it is a product decision rather than a pricing experiment.

Two more products belong in a footnote rather than a table row, and both are traps for anyone following older guides. Windsurf is gone. Its domain redirects to Devin's desktop page, its documentation redirects with it, and no live Windsurf pricing page could be found. Anything that prices it is stale. Devin is what remains: Pro at $20/month, Max at $200/month, with a SWE-2 model and cloud agents.

Aider deserves an honest paragraph because it is still recommended everywhere. It is installable and its repo-map approach is genuinely good, but its last release was 9 August 2025 and its README still leads with a model list that includes Claude 3.7 Sonnet. More relevant for WordPress: its polyglot benchmark covers 225 exercises in C++, Go, Java, JavaScript, Python and Rust. PHP appears in its list of supported languages with tree-sitter tags and repo-map support, and that is a weaker claim than being in the benchmark. Use it if you already have it working, pinned. Do not adopt it in 2026 expecting an active maintainer.

DeepSeek is a token supplier, not an agent

One distinction worth getting right, because it appears in half the guides as a tool comparison. DeepSeek ships models and an API. It does not ship an agent. Its own documentation lists integrations with other people's agents, including an explicit OpenCode integration, and that is the honest framing: cheap tokens behind a harness you chose.

Cheap matters here. An agent working on WordPress reads a lot of files and runs a lot of commands, and the cost of a session is dominated by input tokens. A model at a fraction of frontier pricing with a large context window makes an agent you can leave running through a test suite without watching the meter. The trade-off is real and visible in the failure modes: cheaper models miss semantic errors more often, which is exactly why the environment in module 2 matters more than the model you point at it.

What no vendor documentation says about your language

Remember the absence from the last lesson when you read a comparison table. None of the vendor documentation reviewed for this course mentions WordPress, WooCommerce, WP-CLI or PHP. That has two consequences for choosing.

First, every WordPress-specific capability you get is something WordPress published or something you wrote. The practical effect is that the agent's WordPress knowledge is frozen at whatever its training data contained, which is why the vendor with the most recent model is not automatically the best choice for a site running a version-specific API.

Second, there is no vendor benchmark to choose from. Aider's leaderboard is the most cited and its newest entries are from August 2025, with no PHP in the benchmark at all. If you see a percentage claiming one agent is better at WordPress, its source is either a marketing page or an invented number. Nobody has published a defensible one.

Choose on observables, and keep the receipts

Here is the method that survives the next pricing change. Pick on the two properties you can test, verify cost against the vendor's own page on the day you decide, and write down what you observed so that the next person — including you in six months — has evidence rather than a recommendation.

Choice: OpenCode 1.18.30 with deepseek-flash, decided 2026-10-16.
Cost: model billed per token; vendor pricing page, 2026-10-16.
Execution evidence: `opencode run "run php -v and then wp core version
in this directory and show me both outputs"` returned PHP 8.5.6 and
7.1.3 from the local install.
Instruction evidence: AGENTS.md says "every PHP file must guard with an
ABSPATH check"; asked the agent to quote the rule for adding a new PHP
file, and it quoted that sentence.
Least sure: I believe it will run composer phpcs unprompted. Test: add a
known WPCS violation and ask it to fix the file without naming the tool.