Écrire des règles de curseur qui font que l'IA se comporte dans une ancienne base de code

Ma première semaine de développement piloté par des agents dans notre base de code vieille de quatre ans a produit un code magnifique qui violait trois conventions d'équipe et une décision architecturale pour laquelle nous nous battions depuis des mois. Le correctif n'était pas plus invitant ; il s'agissait de rédiger la constitution.

Un bon fichier de règles est court et négatif. Le mien répertorie ce que la base de code ne doit jamais faire : pas de nouvelles bibliothèques de gestion d'état, les dates sont dayjs et non Date, chaque route API est validée avec les schémas zod existants et ne touche jamais aux fichiers sous Legacy/ sans demander. Ce sont les contraintes, et non les aspirations, qui changent le comportement du modèle.

La victoire inattendue consistait à documenter le pourquoi de chaque règle dans une seule clause. Le modèle qui sait que les migrations ont échoué au dernier trimestre écrit un code de migration plus prudent que celui qui dit simplement d'être prudent. Le contexte convertit les règles respectées en règles comprises, et les règles comprises se généralisent aux cas que vous n'avez pas répertoriés.

Conservez un deuxième fichier de règles par répertoire pour les conventions locales, mon dossier de composants a le sien et résistez à l'envie de gonfler le dossier global. J'ai réduit mon premier brouillon de quarante lignes à douze et les différences se sont améliorées, car chaque ligne que vous ajoutez dilue celles qui comptent.

Six semaines plus tard, le résultat mesurable : les différences violant les conventions sont passées d'environ un sur trois à rarement, et les commentaires de révision de code sont passés du style à la logique. Le fichier de règles est l'ingénieur senior le moins cher que j'ai jamais embauché.