Si vous ne pouvez pas lire votre code PHP, votre LLM ne le pourra pas non plus

L'IA fait l'objet d'un grand nombre d'idées fausses, d'opinions et de discours d'influenceurs. Tout le monde se demande "Êtes-vous prêt pour l'IA ?", une question tout à fait pertinente.

L'IA ne fera pas tout à votre place. Elle tentera de tout faire à votre place si vous la laissez faire, mais en fonction de la pile que vous utilisez, les résultats seront probablement mitigés. La façon la plus importante de traiter l'IA est de la considérer comme un ensemble d'outils supplémentaires dans votre arsenal. Il s'agit donc simplement d'une autre itération d'un ensemble décent d'outils tels que l'analyse statique, les linters de code et les tests bien écrits.

Pour préparer votre base de code à l'utilisation de l'IA, nous allons nous pencher sur l'utilisation de Readalizer de PHPparce que les outils d'IA sont aussi bons que le code qu'ils lisent.

Qu'est-ce que Readalizer ?

Readalizer est une bibliothèque PHP qui offre aux développeurs une API composée d'un ensemble de règles qu'elle appliquera à votre base de code. Au moment de l'exécution, elle ingère chaque fichier PHP défini dans sa configuration, et tokenise votre code à l'aide de l'arbre syntaxique abstrait Arbre Syntaxique Abstrait. Un exemple de règle serait NoTodoWithoutTicketRule. Au moment de l'exécution, votre code :

public function(stdObj $myExample) {
	// TODO add some logic
	return stdObject->valid === true; 
}

Cela échouera. La règle stipule qu'une sorte de référence au ticket doit doit être fournie dans le commentaire en ligne. Pour résoudre ce problème, nous devons donc modifier notre commentaire :

public function(stdObj $myExample) {
	// TODO add some logic (DEVEX-2541)
	return stdObject->valid === true; 
}

Il y a beaucoup Il y a beaucoup de règles, nous ne pouvons donc pas toutes les passer en revue. Ce que nous allons faire, cependant, c'est montrer une implémentation et pourquoi c'est important sur une base de code vivante.

Attendez, en quoi cela diffère-t-il de l'analyse statique ?

Ah, je suis heureux que vous ayez posé cette question. Parce que, essentiellement, un ensemble de règles et un outil de réussite ou d'échec ressemblent à des analyseurs statiques tels que PHPStan ou PsalmPHP (tous deux utilisent également l'AST pour analyser le code PHP en jetons). Il y a cependant une différence très nette entre les deux. L'analyse statique garantit que que votre code fonctionne. Readalizer ne se préoccupe pas de savoir si votre code fonctionne ou non, simplement qu'il respecte les règles que vous lui avez données. Nous pouvons donc conclure qu'un analyseur statique fait partie de votre chaîne d'outils de qualité du code, mais le principal cas d'utilisation de Readalizer est de s'assurer que les humains et les Grands Modèles de Langage peuvent lire votre code et prendre de meilleures décisions grâce aux ensembles de règles que vous avez mis en place.

Readalizer dans les propres mots de l'auteur

Dans les articles, j'aime bien demander aux créateurs d'un projet comment il est né et quel est son objectif. projet. Voici donc quelques mots sur ce qu'est Readalizer, en français et en anglais. Christopher Millerdans les mots de Christopher Miller :

"Readalizer a été conçu pour vous aider, vous et vos agents d'intelligence artificielle, à comprendre votre code PHP. L'inspiration pour commencer ce paquet a été une citation d'Ondrej Mirtes, qui a dit que PHPStan n'est pas concerné par l'apparence de votre code ; c'est le travail de quelqu'un d'autre. J'en ai donc fait mon affaire. Ayant passé la majeure partie de ma carrière à parler de code lisible, j'ai pensé qu'il était temps de faire quelque chose à ce sujet. C'est là que Readalizer entre en jeu. Il vous permet de personnaliser les règles avec des configurations, des règles personnalisées et des ensembles de règles personnalisées, tout en démarrant en 30 secondes environ."

Exécuter Readalizer sur le SDK PHP de Vonage

Pour voir comment cela fonctionne en pratique, exécutons Readalizer sur une base de code réelle : le code PHP de SDK PHP de Vonage.

L'objectif est simple : identifier les domaines dans lesquels l'amélioration de la cohérence du code peut rendre le projet plus facile à comprendre pour les humains et les LLM.

Pour commencer, il suffit de suivre deux étapes :

composer require readalizer/readalizer

vendor/bin/readalizer --init

Cela vous donnera une readalizer.php à la racine de votre projet. Excellent. J'ai modifié le modèle de base pour lui demander de regarder dans le répertoire src par défaut, et j'ai temporairement désactivé toutes les règles pour pouvoir les activer une par une et voir leur impact.

<?php

declare(strict_types=1);

use Readalizer\Readalizer\Rules\ClassNamePascalCaseRule;

use Readalizer\Readalizer\Rules\NoStaticPropertyRule;

use Readalizer\Readalizer\Rules\RequireNamespaceRule;

use Readalizer\Readalizer\Rules\StrictTypesDeclarationRule;

use Readalizer\Readalizer\Rules\PropertyNameCamelCaseRule;

use Readalizer\Readalizer\Rules\ConstantUpperCaseRule;

use Readalizer\Readalizer\Rules\ExceptionSuffixRule;

/**

* Copy this to readalizer.php in your project root and configure your rules.

*

* Each rule is a class implementing RuleInterface (node-level) or

* FileRuleInterface (file-level). Rules can live anywhere.

*

* ── Suppressing violations ───────────────────────────────────────────────────

*

* PHP attribute on a class, method, property, or parameter:

*

*   use Readalizer\Readalizer\Attributes\Suppress;

*

*   #[Suppress]                                   // suppress ALL rules

*   #[Suppress(NoLongMethodsRule::class)]          // suppress one rule

*   #[Suppress(RuleA::class, RuleB::class)]        // suppress multiple

*

* Scope: a class-level attribute suppresses everything within the class;

* a method-level attribute suppresses everything within that method.

*

* Inline comment for line-level suppression (trailing or preceding line):

*

*   $x = something(); // @readalizer-suppress NoLongMethodsRule

*   // @readalizer-suppress                   (preceding line, suppress all)

*   // @readalizer-suppress RuleA, RuleB      (preceding line, suppress named)

*/

return [

   // Paths to scan when no paths are passed on the CLI.

   'paths' => [

       'src',

   ],

   // Memory limit for analysis (default: 2G).

   'memory_limit' => '2G',

   // Cache results between runs.

   'cache' => [

       'enabled' => true,

       'path' => '.readalizer-cache.json',

   ],

   // Optional baseline file to suppress known violations.

   // 'baseline' => '.readalizer-baseline.json',

   // Paths, directory prefixes, or glob patterns to exclude from scanning.

   'ignore' => [

       // 'rector.php',

       // 'src/',

       // '*.generated.php',

   ],

   // Choose one or more rulesets (packs).

   'ruleset' => [

       // new FileStructureRuleset(),

       // new TypeSafetyRuleset(),

       // new ClassDesignRuleset(),

       // new MethodDesignRuleset(),

       // new NamingRuleset(),

       // new ExpressionRuleset(),

   ],

   // Add or override rules on top of rulesets.

   'rules' => [

       // File structure

       // new LineLengthRule(maxLeng)th: 120),

       // new CustomFileRule(),

       // Type safety

       // new CustomTypeRule(),

       // Class design

       // new CustomClassRule(),

       // Method design

       // new CustomMethodRule(),

       // Naming conventions

       // new CustomNamingRule(),

       // Expressions & control flow

       // new CustomExpressionRule(),
   ],
];

. Ensuite, j'ai ajouté des règles, une par une. Tout d'abord, j'ai ajouté la règle ClassNamePascalCaseRule()qui s'assure que toutes les classes de votre code source sont en PascalCase (les développeurs de WordPress devraient donc regarder ailleurs). J'ai lancé Readalizer et j'ai obtenu les résultats :

[##############################] 100% (319/319) 1s

[OK] No readability violations found.

Time: 1.06s

Pas d'infraction ici. Bon travail, auteurs du SDK! Je pense que je devrais en choisir un autre. J'ai donc choisi l'option ExceptionSuffixRule(). Cette règle stipule que toutes vos /Exception's doivent doivent être identifiables par la présence d'une Exception dans le nom de la classe. Pour un LLM, c'est important parce que la structure du fichier et les conventions de nommage lui confèrent une prévisibilité. Que se passe-t-il alors lorsque nous exécutons ce programme ?

[##############################] 100% (319/319) 1s

src/Client/Exception/Conflict.php

  line 7  [ExceptionSuffixRule]  Exception class "Conflict" should end with "Exception".

src/Client/Exception/Credentials.php

  line 7  [ExceptionSuffixRule]  Exception class "Credentials" should end with "Exception".

src/Client/Exception/NotFound.php

  line 7  [ExceptionSuffixRule]  Exception class "NotFound" should end with "Exception".

src/Client/Exception/Request.php

  line 10  [ExceptionSuffixRule]  Exception class "Request" should end with "Exception".

src/Client/Exception/Server.php

  line 10  [ExceptionSuffixRule]  Exception class "Server" should end with "Exception".

src/Client/Exception/Transport.php

  line 7  [ExceptionSuffixRule]  Exception class "Transport" should end with "Exception".

[FAIL] Found 6 violations.

Time: 1.10s

Nous arrivons maintenant à quelque chose. Ce n'est pas une mauvaise décision d'écrire les exceptions de cette manière - elles sont, après tout, définies dans la structure de l'espace de noms en tant qu'exceptions. Mais répétons-le : vous voulez que votre LLM ait le moins de travail possible à faire pour prendre la décision suivante. Encore une fois, prévisibilité dans votre base de code est la clé ici.

Avec seulement six violations, et la correction consistant à renommer six classes, cela semble être un travail assez trivial pour Claude à réparer. J'ouvre donc mon invite dans curseurje colle les violations et je lui demande de les remanier. Je pousse le code vers le haut, je crée un PR, et hop, le tour est joué :

https://github.com/Vonage/vonage-php-sdk-core/pull/553

Il semble semble un petit exemple, mais juste pour vérifier le bien-fondé de la démarche, j'ai même demandé à Glean de me dire en ses propres termes quelles améliorations je peux apporter à un SDK pour améliorer l'expérience de l'agent. Ses résultats ont confirmé ce que je supposais être le cas :

• Ajouter des champs de raisonnement structurés à vos réponses API

• Utiliser des conventions de dénomination cohérentes - Les LLM ont besoin de prévisibilité pour prendre des décisions

• Inclure des actions de résolution dans les réponses aux erreurs afin que les agents sachent comment résoudre les problèmes

// Example: Exception naming for predictability

// BAD - LLM can't predict this is an exception

class Invalid {}

// GOOD - Clear suffix helps LLM identify exceptions

class InvalidRequestException {}

Voilà, c'est l'agent lui-même qui vous le dit en une phrase.

Conclusion

Bien qu'un simple exemple serve à donner un aperçu de la manière dont il faut se préparer à l'IA, il convient également de mentionner que l'expérience de l'agent est une approche à multiples facettes. Pour réussir avec l'IA, je n'écouterais pas, par exemple, les très nombreux influenceurs sur les fils LinkedIn qui disent "X est mauvais, utilisez Y". C'est trop simpliste. L'approche de Vonage ressemble beaucoup à celle d'autres leaders de l'industrie en ce sens qu'il s'agit d'un effort multiplateforme :

• Cet article présentait des outils permettant d'améliorer vos SDK pour les agents fonctionnant uniquement en tant que LLM, tels que OpenClaw

• En outre, un agent devrait avoir la possibilité d'utiliser un serveur MCP comme option alternative (Vonage, par exemple, a publié son propre serveur MCP). publié le sien), qui devrait à son tour être connecté :

• Une interface de ligne de commande (CLI) remaniée et renforcée, et oui, Vonage en a une depuis longtemps) et une structure de commande publique afin que les agents aient la possibilité d'utiliser l'interface de ligne de commande seule.

Trois approches, permettant à l'outil d'IA de décider ce qui accomplit le mieux la tâche qui lui a été confiée. C'est ainsi que l'on se prépare à l'IA.