Les agents de programmation ont beaucoup progressé, et les bonnes pratiques évoluent vite. Avec des modèles plus performants, ce qui exigeait auparavant un accompagnement étroit et un cadre détaillé n’en a plus besoin.
Si vous avez utilisé des agents comme Codex pour vos projets au cours de l’année écoulée, vous avez probablement accumulé de nombreuses instructions pour orienter les modèles vers de bons résultats. Chaque nouvelle version était déjà l’occasion de réexaminer ces choix, mais avec GPT-6 Astra, c’est plus important que jamais.
Ces instructions peuvent prendre de nombreuses formes : les skills, AGENTS.md et les prompts de vos tâches influencent tous la manière dont le modèle travaille.
De meilleurs skills
Ces instructions peuvent prendre la forme de skills : il s’agit essentiellement de prompts enregistrés dans des fichiers Markdown, auxquels peuvent s’ajouter des ressources et des scripts. En général, ils sont surtout utiles pour guider un workflow précis ou l’utilisation de certaines applications.
Il est désormais courant d’intégrer de nombreux skills aux projets. Chaque skill possède un nom et une description qui sont chargés dans le contexte du modèle pour lui indiquer quand l’utiliser. Mais beaucoup de descriptions sont bien trop longues et, lorsque vous ajoutez trop de skills, Codex commence à raccourcir leurs descriptions pour qu’elles tiennent dans le contexte. Le modèle voit alors une plus petite partie de chaque description, ce qui complique le choix du bon skill.
Pire encore, les descriptions peuvent souvent se contredire ou trop insister sur les situations où les skills doivent être utilisés. Le modèle charge alors des instructions qui ne l’aident pas vraiment à accomplir la tâche.
Une méthode courante pour créer des skills consiste à utiliser le skill $skill-creator. Nous avons récemment mis à jour ses instructions pour limiter bon nombre des problèmes observés en pratique.
Premièrement, les descriptions des skills doivent être aussi courtes que possible, tout en précisant clairement quand le modèle doit les utiliser :
Créez et validez des migrations de schéma Postgres. Utilisez ce skill lorsque vous travaillez sur des bases de données, des requêtes, des modèles ou la persistance des données.
Créez et validez des migrations de schéma Postgres. Utilisez ce skill lorsque vous ajoutez ou modifiez une migration, ou que vous examinez son déploiement.
Ici, la mauvaise description du skill peut inciter le modèle à l’utiliser dès qu’il touche à quoi que ce soit en lien avec une base de données, au lieu de le réserver aux migrations.
Deuxièmement, un skill utile se reconnaît notamment à la façon dont il présente les informations au fur et à mesure des besoins. Lire un skill occupe de la place dans le contexte, rapproche le moment du compactage et introduit des instructions qui ne s’appliquent pas forcément à la tâche. Pour les skills qui couvrent plusieurs workflows, faites du document principal un point d’orientation minimal vers les documents et scripts complémentaires. Donnez au modèle suffisamment d’indications pour savoir où chercher, sans l’obliger à lire des éléments inutiles sur le moment.
Troisièmement, beaucoup de skills ont été rédigés comme des parcours détaillés ou des recettes à suivre. Les modèles comprennent bien mieux les nuances et les ambiguïtés. Des instructions trop précises peuvent donc désormais nuire aux résultats alors qu’elles étaient auparavant utiles.
Les skills du dépôt guident aussi les agents des autres contributeurs, qui peuvent utiliser des modèles différents. Des instructions utiles à Sol ou Luna peuvent trop contraindre GPT-6 Astra. Tenez donc compte des modèles qui utiliseront les instructions que vous laissez dans le dépôt.
Un fichier AGENTS.md à jour
Comme AGENTS.md s’applique chaque fois que le modèle travaille dans votre dépôt, réexaminez régulièrement chaque instruction et demandez-vous si elle est toujours nécessaire.
Exiger la lecture d’une pile de documents ou d’un plan complet du dépôt avant chaque modification est excessif pour corriger une faute de frappe. GPT-6 Astra sait déterminer ce qu’il doit lire sans qu’on l’incite à passer tout le projet en revue avant chaque changement.
Avant chaque modification, lisez architecture.md, database.md et deployment.md.
Consultez architecture.md pour les frontières entre services, database.md pour les modifications de schéma et deployment.md lorsque vous préparez un déploiement.
Demander au modèle de lire des fichiers avant chaque modification est un excellent moyen de gaspiller du contexte et de ralentir le travail. Renvoyer à certains documents peut néanmoins rester utile, à condition de préciser dans quel cas les consulter. Pensez aussi à tenir votre documentation à jour !
Il fallait encourager les modèles précédents à exécuter des tests et à vérifier leur travail. GPT-6 Astra le fait de lui-même : les mêmes instructions peuvent donc conduire à des tests inutiles.
GPT-6 Astra est minutieux, mais peut hésiter davantage sur la portée à donner à une tâche. Il a parfois besoin d’un petit coup de pouce pour continuer. Vous pouvez utiliser AGENTS.md pour lui donner l’autorisation de suivre un workflow précis que vous savez sûr, comme l’exécution d’une suite de tests locale :
Les tests locaux utilisent des fixtures jetables et n’ont aucun accès à la production. Exécutez-les, corrigez les échecs causés par la modification demandée et relancez les tests concernés sans demander d’approbation à chaque étape.
Limites de décision
Soignez la façon dont vous formulez les limites. Si un modèle précédent a agi en votre nom sans autorisation, vous avez peut-être ajouté des consignes fermes pour qu’il vous consulte d’abord. Cela peut être utile, mais GPT-6 Astra, notre modèle le plus aligné, fait preuve d’un bien meilleur discernement et n’exécute une tâche que s’il sait qu’elle est sans danger. Tenez-en compte dans vos instructions.
Si vous aviez fixé des limites pour empêcher d’autres modèles d’aller trop loin et que vous passez maintenant à GPT-6 Astra, envisagez de revoir leur formulation : Astra pourrait les prendre trop au sérieux et s’arrêter alors que vous seriez tout à fait d’accord pour qu’il continue.
Persévérance
Si vous avez l’habitude de voir GPT-5.6 Sol prendre en charge une demande et travailler longuement dessus, GPT-6 Astra peut vous sembler plus hésitant quant au moment de s’arrêter. Il peut produire une première implémentation et revenir vous la soumettre pour révision alors qu’il reste encore du travail.
C’est là qu’il est utile de définir, avant de commencer, ce qui constituera une tâche terminée. Vous devrez peut-être encourager Astra à poursuivre jusqu’à ce que tout soit fait. Si la tâche comprend l’exécution de l’implémentation, l’inspection du résultat et la correction de ce qui ne fonctionne pas, précisez-le dans votre demande. Exiger un arrêt pour révision après la première implémentation incitera le modèle à s’arrêter plus tôt. Vérifiez donc si vous avez vraiment besoin d’intervenir à ce stade.
Si vous souhaitez qu’il continue à explorer au-delà d’un premier passage, précisez ce qu’il doit approfondir et où il doit s’arrêter.
L’arrivée d’un nouveau modèle est une bonne occasion de faire le ménage, mais vous n’avez pas besoin de tout passer en revue manuellement : demandez à GPT-6 Astra de réaliser un audit à partir des points abordés dans cet article, puis lancez-vous dans un projet que vous n’auriez pas osé entreprendre auparavant !