Les projets Laravel et Symfony sont d'excellents endroits pour utiliser les agents IA. Non pas parce que PHP est "facile" (ce n'est pas le cas), mais parce que les backends PHP comportent beaucoup de véritable logique métier. Contrôleurs, services, commandes de console, tâches de file d'attente, référentiels Doctrine, modèles Eloquent, écouteurs d'événements, validateurs, politiques, migrations et tests coexistent tous dans un seul dépôt, et les relations entre eux sont exactement le type de contexte qui est coûteux à charger pour un humain et peu coûteux à cartographier pour un agent prudent.
La meilleure utilisation d'un agent dans une base de code PHP n'est pas de "me générer du code aléatoire". C'est plus proche de :
Aidez-moi à comprendre ce flux backend. Aide-moi à protéger mon comportement. Aide-moi à trouver les tests manquants. Aidez-moi à examiner les requêtes risquées. Aidez-moi à documenter ce que fait réellement ce code.C'est là que l'IA devient un partenaire de base de code au lieu d'un dactylographe. Un bon agent Laravel/Symfony devrait travailler comme un assistant senior attentif. Il inspecte les fichiers, cartographie les flux, explique les effets secondaires, suggère des tests, examine les requêtes ORM et ne modifie le code que lorsque vous l'autorisez explicitement. Cet article présente les flux de travail pratiques pour ce type d'agent, de manière à ne pas transformer votre base de code en un jeu de devinettes.
Un bon agent doit d'abord répondre « à quoi sert ce code ? » avant de demander « quel code dois-je écrire ? » Cet ordre est plus important en PHP que dans la plupart des langages, car Laravel et Symfony cachent de nombreux comportements derrière les façades, les conteneurs de services et les écouteurs d'événements. La lecture d'un contrôleur isolé ne vous dit presque rien sur ce qui se passe réellement lorsque la route se déclenche.
Prenez ce contrôleur Laravel :
final class SubscriptionController { public function Cancel(Request $request, int $subscriptionId): JsonResponse { $subscription = Subscription::query() ->where('user_id', $request->user()->id) ->findOrFail($subscriptionId); $this->subscriptionService->cancel($subscription, $request->boolean('immédiatement')); return réponse()->json([ 'status' => $subscription->status, 'ends_at' => $subscription->ends_at?->toISOString(), ]); } }Une invite faible est « refactoriser ce contrôleur ». Cela met l'agent en mode édition avant qu'il n'ait la moindre idée de ce dont le code est responsable. Un bien meilleur coup de départ serait quelque chose comme :
Analysez ce contrôleur Laravel et expliquez le flux backend. Veuillez identifier : - le point d'entrée HTTP, - les entrées de requête, - les hypothèses d'autorisation, - les appels de service, - les lectures/écritures de la base de données, - les événements/tâches/e-mails qui peuvent survenir en aval, - la forme de la réponse, - le comportement qui doit être protégé par des tests. Ne modifiez pas encore le code.C'est beaucoup plus sûr, et c'est le genre de message auquel l'agent peut réellement répondre correctement. Cela pourrait revenir avec quelque chose comme :
Le contrôleur étend l'abonnement à l'utilisateur actuel. Le paramètre de requête « immédiatement » modifie le comportement d'annulation. La forme de réponse inclut « statut » et « ends_at ». Le service peut contenir des effets secondaires importants. Les tests doivent protéger la portée de l'utilisateur et la forme de la réponse.Vous comprenez désormais la surface des risques avant de refactoriser : ce qu'est le contrat public, ce qui est caché et où les tests doivent être effectués en premier.