{"slug": "ai-agents-for-laravel-symfony-projects", "title": "AI Agents For Laravel/Symfony Projects", "summary": "A developer outlines practical workflows for using AI agents in Laravel and Symfony projects, emphasizing analysis over code generation. The agent should first map backend flows, identify entry points, and explain side effects before suggesting edits. This approach helps developers understand risk surfaces and protect behavior through tests.", "body_md": "Laravel and Symfony projects are great places to use AI agents. Not because PHP is \"easy\" (it isn't), but because PHP backends carry a lot of real business logic. Controllers, services, console commands, queue jobs, Doctrine repositories, Eloquent models, event listeners, validators, policies, migrations, and tests all coexist in one repo, and the relationships between them are exactly the kind of context that's expensive for a human to load and cheap for a careful agent to map.\n\nThe best use of an agent in a PHP codebase is not \"generate me random code.\" It's closer to:\n\n```\nHelp me understand this backend flow.\nHelp me protect behavior.\nHelp me find missing tests.\nHelp me review risky queries.\nHelp me document what this code actually does.\n```\n\nThat's where AI becomes a codebase partner instead of a code typist. A good Laravel/Symfony agent should work like a careful senior assistant. It inspects files, maps flows, explains side effects, suggests tests, reviews ORM queries, and only edits code when you explicitly allow it. This article walks through practical workflows for that kind of agent, in a way that doesn't turn your codebase into a guessing game.\n\nA good agent should first answer \"what does this code do?\" before it ever asks \"what code should I write?\" That ordering matters more in PHP than in most languages, because Laravel and Symfony hide a lot of behavior behind facades, service containers, and event listeners. Reading a controller in isolation tells you almost nothing about what actually happens when the route fires.\n\nTake this Laravel controller:\n\n```\nfinal class SubscriptionController\n{\n    public function cancel(Request $request, int $subscriptionId): JsonResponse\n    {\n        $subscription = Subscription::query()\n            ->where('user_id', $request->user()->id)\n            ->findOrFail($subscriptionId);\n\n        $this->subscriptionService->cancel($subscription, $request->boolean('immediately'));\n\n        return response()->json([\n            'status' => $subscription->status,\n            'ends_at' => $subscription->ends_at?->toISOString(),\n        ]);\n    }\n}\n```\n\nA weak prompt is \"refactor this controller.\" It puts the agent in editing mode before it has any idea what the code is responsible for. A much better starting move is something like:\n\n```\nAnalyze this Laravel controller and explain the backend flow.\n\nPlease identify:\n- the HTTP entry point,\n- request inputs,\n- authorization assumptions,\n- service calls,\n- database reads/writes,\n- events/jobs/emails that may happen downstream,\n- response shape,\n- behavior that should be protected by tests.\n\nDo not edit code yet.\n```\n\nThis is much safer, and it's the kind of prompt the agent can actually answer well. It might come back with something like:\n\n```\nThe controller scopes the subscription by current user.\nThe `immediately` request parameter changes cancellation behavior.\nThe response shape includes `status` and `ends_at`.\nThe service may contain important side effects.\nTests should protect user scoping and response shape.\n```\n\nNow you understand the risk surface before refactoring: what the public contract is, what's hidden, and where tests need to land first.\n\nLaravel projects usually have several types of entry points to the same feature: `routes/api.php`\n\n, an HTTP controller, an Artisan command, a scheduled command, a queue job, an event listener, a webhook controller, a notification class. The same business operation often runs through more than one of these paths, and the surprising bugs live exactly where those paths diverge.\n\nThat makes \"find every entry point\" a high-value question for an agent:\n\n```\nFind every entry point related to subscription cancellation.\n\nSearch for:\n- routes,\n- controllers,\n- services,\n- jobs,\n- commands,\n- event listeners,\n- notifications,\n- tests.\n\nGroup the results by execution path.\nFor each path, explain what triggers it and what side effects it may cause.\n```\n\nThis matters because changing only the controller may not change the real production path. For example:\n\n```\nfinal class CancelExpiredTrialsCommand extends Command\n{\n    protected $signature = 'subscriptions:cancel-expired-trials';\n\n    public function handle(): int\n    {\n        Subscription::query()\n            ->where('status', 'trialing')\n            ->where('trial_ends_at', '<', now())\n            ->each(fn (Subscription $subscription) =>\n                $this->subscriptionService->cancel($subscription, immediately: true)\n            );\n\n        return self::SUCCESS;\n    }\n}\n```\n\nThe same `SubscriptionService::cancel()`\n\nis called from both the API controller and a scheduled command, which means your tests need to cover both paths. An agent that maps the call graph for you will catch that even when grep wouldn't.\n\nSymfony projects make dependencies more explicit through services and constructor injection, which is good news for an agent. There's less magic to chase. A typical controller looks like this:\n\n```\nfinal class CancelSubscriptionController\n{\n    public function __construct(\n        private readonly SubscriptionCanceller $subscriptionCanceller,\n        private readonly SubscriptionRepository $subscriptionRepository,\n    ) {}\n\n    public function __invoke(Request $request, string $id): JsonResponse\n    {\n        $subscription = $this->subscriptionRepository->findOwnedByUser(\n            $id,\n            $this->getUser()->getId(),\n        );\n\n        if (!$subscription) {\n            throw $this->createNotFoundException();\n        }\n\n        $this->subscriptionCanceller->cancel(\n            subscription: $subscription,\n            immediately: $request->query->getBoolean('immediately'),\n        );\n\n        return $this->json([\n            'status' => $subscription->status()->value,\n            'endsAt' => $subscription->endsAt()?->format(DATE_ATOM),\n        ]);\n    }\n}\n```\n\nA useful prompt for that kind of file:\n\n```\nAnalyze this Symfony controller and related services.\n\nExplain:\n- which services are injected,\n- which repository methods are used,\n- how authorization is enforced,\n- where Doctrine flush likely happens,\n- which domain events or messages may be dispatched,\n- which response fields are public API contracts,\n- what tests should exist before refactoring.\n```\n\nThe agent can help you trace from controller to service to repository, but it should always inspect the files, never assume behavior from the class names alone. Domain layers are full of services that look generic and do something very specific.\n\nAI can generate tests quickly, but quick isn't the goal. Random tests aren't enough. You want behavior-protecting tests, the kind that fail loudly when a refactor accidentally changes a side effect or a response contract.\n\nFor Laravel, that looks something like:\n\n```\npublic function test_user_can_cancel_own_subscription(): void\n{\n    Queue::fake();\n    Mail::fake();\n\n    $user = User::factory()->create();\n\n    $subscription = Subscription::factory()->create([\n        'user_id' => $user->id,\n        'status' => 'active',\n    ]);\n\n    $response = $this\n        ->actingAs($user)\n        ->postJson(\"/api/subscriptions/{$subscription->id}/cancel\", [\n            'immediately' => true,\n        ]);\n\n    $response\n        ->assertOk()\n        ->assertJsonStructure([\n            'status',\n            'ends_at',\n        ]);\n\n    $this->assertDatabaseHas('subscriptions', [\n        'id' => $subscription->id,\n        'status' => 'canceled',\n    ]);\n}\n```\n\nFor Symfony, the same idea translated to its WebTestCase:\n\n``` php\npublic function testUserCanCancelOwnSubscription(): void\n{\n    $client = static::createClient();\n\n    $user = UserFactory::createOne();\n    $subscription = SubscriptionFactory::createOne([\n        'user' => $user,\n        'status' => SubscriptionStatus::Active,\n    ]);\n\n    $client->loginUser($user->_real());\n\n    $client->request(\n        'POST',\n        sprintf('/api/subscriptions/%s/cancel', $subscription->getId()),\n        ['immediately' => true],\n    );\n\n    self::assertResponseIsSuccessful();\n\n    $payload = json_decode($client->getResponse()->getContent(), true);\n\n    self::assertArrayHasKey('status', $payload);\n    self::assertArrayHasKey('endsAt', $payload);\n}\n```\n\nWhen you ask an agent to produce tests like this, give it the rules up front:\n\n```\nGenerate PHPUnit tests for this backend flow.\n\nRules:\n- Protect current behavior before refactoring.\n- Include authorization tests.\n- Include failure cases.\n- Include response shape checks.\n- Include database assertions.\n- Mock external services, but do not mock the domain logic.\n- Explain why each test exists.\n```\n\nThat last line is the important one. A test without a stated reason is often just noise. It pins behavior nobody intentionally chose, and the next refactor has to fight it.\n\nAI agents are useful for reviewing Eloquent queries because ORM code can hide SQL problems that look fine at the call site. Take this example:\n\n``` php\n$orders = Order::query()\n    ->where('status', 'paid')\n    ->whereDate('created_at', now()->toDateString())\n    ->get();\n\nforeach ($orders as $order) {\n    echo $order->customer->email;\n}\n```\n\nThis looks simple, but it has two common issues. First, `whereDate()`\n\nmay prevent efficient index usage because it applies a date expression to the column, so a normal `created_at`\n\nindex can't be used. Second, `$order->customer`\n\ninside the loop triggers one extra query per order. Textbook N+1.\n\nA safer rewrite:\n\n``` php\n$start = now()->startOfDay();\n$end = now()->endOfDay();\n\n$orders = Order::query()\n    ->with('customer')\n    ->where('status', 'paid')\n    ->whereBetween('created_at', [$start, $end])\n    ->get();\n\nforeach ($orders as $order) {\n    echo $order->customer->email;\n}\n```\n\nThe prompt that gets you there:\n\n```\nReview this Eloquent query for performance.\n\nCheck:\n- possible N+1 queries,\n- missing eager loading,\n- functions applied to indexed columns,\n- filtering order,\n- pagination issues,\n- whether an index may help,\n- whether the query loads too many rows.\n\nSuggest the safest change first.\nDo not change behavior silently.\n```\n\nThe agent should explain the trade-off, not just rewrite the code. A \"safer\" query that quietly drops a row or changes ordering is not actually safer.\n\nDoctrine can hide performance problems too, in slightly different shapes. A typical repository call:\n\n``` php\n$orders = $orderRepository->findBy([\n    'status' => OrderStatus::Paid,\n]);\n\nforeach ($orders as $order) {\n    echo $order->getCustomer()->getEmail();\n}\n```\n\nIf `customer`\n\nis lazy-loaded (the Doctrine default), this triggers one query for orders and then one query per customer. The query-builder version that fetches both in one shot:\n\n``` php\n$orders = $entityManager->createQueryBuilder()\n    ->select('o', 'c')\n    ->from(Order::class, 'o')\n    ->join('o.customer', 'c')\n    ->where('o.status = :status')\n    ->setParameter('status', OrderStatus::Paid)\n    ->getQuery()\n    ->getResult();\n```\n\nUseful agent prompt for Doctrine:\n\n```\nReview this Doctrine query and related entity mappings.\n\nCheck:\n- lazy loading that may cause N+1 queries,\n- missing joins,\n- hydration cost,\n- pagination behavior,\n- indexes needed by WHERE/JOIN columns,\n- whether the query loads unnecessary associations.\n\nReturn:\n- current behavior,\n- likely SQL shape,\n- performance risks,\n- safest improvement,\n- tests or profiling checks.\n```\n\nN+1 queries are one of the easiest performance bugs to introduce, and one of the easiest for an agent to catch, if you ask the right question. A Laravel example:\n\n``` php\n$users = User::query()->where('active', true)->get();\n\nreturn $users->map(fn (User $user) => [\n    'id' => $user->id,\n    'team' => $user->team->name,\n]);\n```\n\nBetter, with eager loading:\n\n``` php\n$users = User::query()\n    ->with('team')\n    ->where('active', true)\n    ->get();\n```\n\nA Symfony/Doctrine equivalent:\n\n``` php\n$users = $userRepository->findActiveUsers();\n\nforeach ($users as $user) {\n    $teamName = $user->getTeam()->getName();\n}\n```\n\nBetter, with a join:\n\n``` php\n$queryBuilder\n    ->select('u', 't')\n    ->from(User::class, 'u')\n    ->join('u.team', 't')\n    ->where('u.active = true');\n```\n\nThe prompt that catches these consistently:\n\n```\nAnalyze this code for possible N+1 queries.\n\nLook for:\n- relationship access inside loops,\n- lazy-loaded Doctrine associations,\n- Eloquent relationship properties,\n- serializers that access relations,\n- API resources that access nested data,\n- notifications or exports that loop over models.\n\nFor each possible N+1:\n- show the line,\n- explain why it may trigger extra queries,\n- suggest eager loading or query change,\n- mention possible memory trade-offs.\n```\n\nThe memory trade-off is worth flagging out loud. Eager loading everything isn't always correct. A list endpoint that pulls 10,000 rows shouldn't also hydrate every related entity. The right fix depends on the call site.\n\nLegacy PHP often has large service methods that do five things at once. Something like:\n\n``` php\npublic function processRefund(int $orderId, int $amount): void\n{\n    $order = Order::findOrFail($orderId);\n\n    if ($order->status !== 'paid') {\n        throw new RuntimeException('Order is not refundable.');\n    }\n\n    if ($amount > $order->paid_amount) {\n        throw new RuntimeException('Refund amount is too high.');\n    }\n\n    $response = $this->gateway->refund($order->transaction_id, $amount);\n\n    if (!$response->successful()) {\n        Log::warning('Refund failed', ['order_id' => $order->id]);\n        throw new RuntimeException('Refund failed.');\n    }\n\n    $order->refunds()->create([\n        'amount' => $amount,\n        'gateway_reference' => $response->reference(),\n    ]);\n\n    $order->update([\n        'refunded_amount' => $order->refunded_amount + $amount,\n    ]);\n\n    event(new OrderRefunded($order));\n\n    Mail::to($order->user)->queue(new RefundProcessedMail($order));\n}\n```\n\nDon't ask the agent to \"rewrite this cleanly.\" That phrasing invites it to invent abstractions that don't match your domain. Ask it for an analysis first:\n\n```\nAnalyze this legacy PHP method for safe refactoring.\n\nFirst:\n- summarize current behavior,\n- list validation rules,\n- list side effects,\n- identify external services,\n- identify events/emails/jobs,\n- suggest characterization tests,\n- propose a small-step refactor plan.\n\nDo not change code yet.\n```\n\nA good plan back from the agent might look like this:\n\n```\n1. Add tests for non-paid order, amount too high, gateway failure, successful refund.\n2. Extract refund eligibility checks into a private method.\n3. Extract gateway refund call into a small method.\n4. Keep event and email behavior unchanged.\n5. Only then consider a dedicated RefundService.\n```\n\nThat's how AI helps without creating chaos: small, testable steps in an order that keeps behavior intact between every commit.\n\nAI agents are excellent for documentation because they can read code paths and summarize them, which is exactly the work humans tend to skip. A solid prompt:\n\n```\nCreate developer documentation for this backend flow.\n\nInclude:\n- entry points,\n- request parameters,\n- main services,\n- database tables changed,\n- events/jobs/emails triggered,\n- external APIs called,\n- failure modes,\n- tests that cover the flow.\n\nUse plain English.\nDo not invent behavior.\nIf something is uncertain, mark it as uncertain.\n```\n\nThe output looks something like:\n\n```\n# Subscription Cancellation Flow\n\n## Entry Points\n\n- `POST /api/subscriptions/{id}/cancel`\n- `subscriptions:cancel-expired-trials` scheduled command\n\n## Main Service\n\n`SubscriptionService::cancel()` handles cancellation rules.\n\n## Side Effects\n\n- Updates `subscriptions.status`\n- May set `subscriptions.ends_at`\n- Dispatches `SubscriptionCanceled`\n- Queues cancellation email\n\n## External APIs\n\nThe payment gateway may be called for immediate cancellation.\n\n## Tests\n\n- `CancelSubscriptionTest`\n- `CancelExpiredTrialsCommandTest`\n```\n\nThis kind of doc is gold for onboarding and maintenance. It surfaces the behavior the code already has without anyone needing to re-read the whole module.\n\nA useful PHP agent doesn't need unlimited access. The pattern that works well is a tiered set of tools. Read-only by default, safe execution where it pays off, and write access only behind a confirmation:\n\n```\nRead-only tools:\n- search codebase,\n- read file,\n- list routes,\n- inspect composer.json,\n- inspect migrations,\n- inspect tests.\n\nSafe execution tools:\n- run PHPUnit,\n- run PHPStan/Psalm,\n- run PHP CS Fixer in dry-run mode,\n- run Doctrine schema validation,\n- run Laravel route:list.\n\nWrite tools with approval:\n- edit files,\n- create tests,\n- update docs,\n- create PR summary.\n\nBlocked by default:\n- deploy,\n- run arbitrary shell,\n- access production secrets,\n- modify .env,\n- change CI secrets,\n- merge PRs.\n```\n\nThis gives the agent enough power to help, but not enough to damage the system. The agent that can grep your code and run your tests is already a senior collaborator; the one with deploy keys is just a liability.\n\nThe best Laravel/Symfony workflow with AI is not \"AI writes code, developer hopes it works.\" It's closer to:\n\n```\nAI maps the flow.\nAI finds risks.\nAI suggests tests.\nAI reviews queries.\nAI documents behavior.\nDeveloper decides and approves changes.\n```\n\nThat's where AI fits naturally into senior backend development. Use agents to understand services, controllers, jobs, commands, Doctrine, Eloquent, tests, and documentation. Let them shorten the time it takes to load context. Don't let them replace judgment.\n\nIn PHP projects, the most valuable agent is not the one that writes the most code. It's the one that helps you change less code, more safely.\n\n*Originally published at nazarboyko.com.*", "url": "https://wpnews.pro/news/ai-agents-for-laravel-symfony-projects", "canonical_source": "https://dev.to/nazar_boyko/ai-agents-for-laravelsymfony-projects-2mn7", "published_at": "2026-06-26 20:48:02+00:00", "updated_at": "2026-06-26 21:03:55.697791+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "large-language-models"], "entities": ["Laravel", "Symfony", "PHP", "Doctrine", "Eloquent", "Artisan"], "alternates": {"html": "https://wpnews.pro/news/ai-agents-for-laravel-symfony-projects", "markdown": "https://wpnews.pro/news/ai-agents-for-laravel-symfony-projects.md", "text": "https://wpnews.pro/news/ai-agents-for-laravel-symfony-projects.txt", "jsonld": "https://wpnews.pro/news/ai-agents-for-laravel-symfony-projects.jsonld"}}