Agentic Coding for PHP Teams: Laravel, Symfony and WordPress

One language, very different codebases

"PHP" covers a modern Laravel API with full test coverage, a Symfony application with Doctrine and strict typing, and a WordPress plugin that must run on many hosting setups. An agent needs different instructions for each, because the conventions and the ways to verify a change differ.

Laravel also offers Laravel Boost, an MCP server with framework-specific guidance for agents, which is worth evaluating for Laravel teams.

What belongs in the instruction file

• Minimum supported PHP version and framework version, so the agent does not use syntax or APIs that are too new or too old.
• Code style tool and whether files use declare(strict_types=1).
• Where business logic lives: services, actions or controllers – agents otherwise put it wherever is closest.
• Composer rule: no new packages without approval, and composer.lock stays committed.
• The exact commands for a filtered test run, for example php artisan test --filter=InvoiceTest or vendor/bin/phpunit --filter InvoiceTest.

Static analysis is your compiler

PHP has no compiler that catches type errors before runtime, so PHPStan or Psalm take that role in an agent workflow. Run them at the level the project already uses and include them in the commands the agent runs after every change. One rule is essential for legacy projects with a baseline file: the agent must fix new errors, never add them to the baseline or suppress them with ignore comments. State that explicitly – otherwise suppression is often the shortest path to a green check.

Be careful with tests that run against SQLite in memory while production uses MySQL or PostgreSQL. Queries generated by an agent can pass locally and fail on the real database.

Database migrations need a human gate

1. The agent writes the migration; a developer reviews it before it runs anywhere shared.
2. Laravel migrations get a working down() method. In Symfony, review the SQL that doctrine:migrations:diff generates rather than trusting it blindly.
3. Split destructive changes such as dropping or renaming columns into several deployments, so old and new code can run side by side.
4. Think about locks on large tables before adding indexes or columns.
5. The agent's environment uses a local database with fake data – no credentials for staging or production.

Legacy PHP and WordPress security

For upgrades between PHP versions or framework majors, let Rector apply the mechanical changes and use the agent for the remainder. Before touching untested legacy code, have the agent write characterization tests that pin today's behavior. In WordPress code, review agent output with a security checklist: $wpdb->prepare() for queries, escaping functions like esc_html() on output, nonce checks with wp_verify_nonce() and capability checks with current_user_can(). Generated plugin code forgets these surprisingly often. Our guide on testing AI-generated code goes deeper.

How jocapps helps

neooutput runs hands-on workshops, team trainings and 1:1 consulting on agentic coding, in English and German, on-site or remote. PHP teams set up instruction files, static analysis gates and migration rules for their own stack and leave with working results. See the formats on our agentic coding workshops page, or book a free 30-minute intro call via the meeting planner.