Comment utiliser le Codex et ses limites dans des projets réels

Une situation courante consiste à demander « comment utiliser le Codex ». Par défaut, il pose des questions sur les touches de raccourci, les modèles de mots d’invite et comment lui faire écrire plus de code.

J’ai découvert plus tard que cette question était posée dans la mauvaise direction.

La plus grande valeur du Codex est de permettre aux équipes de lancer des changements plus fréquemment et à moindre coût. Le vrai risque est également là : après avoir augmenté la fréquence des changements, le mécanisme d’enregistrement initial de l’équipe peut ne pas suffire.

Je ne parlerai donc pas des « Dix techniques de mots rapides » dans cet article. Je ne parlerai que d’un seul axe principal : Connectez le Codex à un pipeline de modifications qui peut être accepté, annulé et tracé.

1. Sélectionnez d’abord « l’unité de travail adaptée au Codex »

L’usage le plus facilement renversé consiste à adresser une vague exigence directement au Codex :

• “Refactoriser ce module”
• “Optimiser les performances”
• “Rendre cet endroit plus élégant”

Cela donne certainement un tas de changements, et ils semblent tous corrects. Le problème est qu’il n’y a aucun moyen de l’accepter ou de l’examiner.

J’ai condensé les tâches adaptées au Codex en trois catégories, chacune avec des « conditions d’achèvement » claires.

A. Changements de comportement qui peuvent être écrits sous forme d’assertions

La caractéristique est la suivante : l’entrée et la sortie peuvent-elles être décrites en une seule phrase.

• Ajouter un traitement de limite à une fonction
• Correction d’un bug définitif
• Migrer un élément de logique vers une nouvelle interface mais garder la sémantique inchangée

La meilleure façon de procéder à l’acceptation est d’écrire des tests directement, ou au moins d’écrire un script d’assertion exécutable.

B. Modifications mécaniques énumérables

Les caractéristiques sont les suivantes : des règles claires et une couverture contrôlable.

• Renommer des lots
• Mettre à niveau les appels API
• Nullabilité complète / gestion des erreurs

Le Codex est puissant pour ce type de travail, mais il doit être autorisé à produire une « liste de modifications » et une « étendue des modifications consultable », sinon il a tendance à manquer des coins.

C. Optimisation locale avec des indicateurs concrets

La caractéristique est : la capacité à définir des méthodes de mesure.

• Réduire les E/S une fois pendant la phase de démarrage
• Réduire la sérialisation une fois pour un certain lien
• Réduire la réorganisation inutile d’une certaine page

N’optimisez pas sans métriques. Le Codex confondra « ça a l’air plus rapide » avec « c’est vraiment plus rapide ».

2. Écrivez les exigences sous forme de « critères d’acceptation », puis écrivez les mots d’invite

Une situation courante consiste à écrire des mots rapides comme écrire des souhaits :

• “S’il vous plaît, écrivez avec élégance”
• “Veuillez suivre les meilleures pratiques”

C’est inacceptable.

J’exige qu’à chaque fois, avant de laisser le Codex agir, j’écrive d’abord un critère d’acceptation et que je l’écrive dans la même description de tâche :

• Quel comportement ce changement va-t-il changer ?
• Quels comportements ne sont pas autorisés à changer ?
• Comment se comporter en cas d’échec
• Comment revenir en arrière

Vous constaterez qu’une fois les critères d’acceptation clairement rédigés, les mots d’invite deviennent plus courts.

Une structure que j’utilise souvent est :

1. Contexte (deux ou trois phrases, ne parlez pas d’histoire)
2. Objectif (écrire uniquement le comportement, pas la mise en œuvre)
3. Contraintes (ce qui ne peut pas être déplacé)
4. Acceptation (points de test ou scripts)
5. Format de sortie (donner d’abord le plan, puis le patch)

3. Demandez au Codex de donner d’abord un « plan de changement », plutôt que de donner directement le code final.

La chose la plus coûteuse dans les projets réels est de « découvrir que la sémantique a changé après la fusion ».

J’ai donc fait de la sortie par défaut du Codex un processus en deux étapes :

• Étape 1 : Répertoriez quels fichiers seront modifiés, pourquoi ils seront modifiés et les risques de chaque modification
• Étape 2 : appliquez à nouveau le patch

S’il génère tout un morceau de code dès qu’il apparaît, je le rappellerai simplement et le laisserai établir le plan.

La raison est simple :

• La phase de planification peut révéler si elle comprend les limites
• Si les changements excessifs peuvent être interrompus à temps pendant la phase de planification

4. Laissez le Codex produire un “correctif révisable” au lieu d’un simple tas de texte

Copier et coller des centaines de lignes de code dans l’EDI transforme la révision en un travail manuel.

L’approche correcte est la suivante : laissez le Codex produire sous forme de diff/patch, ou laissez-le apporter uniquement les plus petites modifications fusionnables.

Je respecterai deux contraintes dans l’équipe :

• Un seul PR ne couvre pas deux intentions indépendantes
• La différence fondamentale d’un seul PR se situe dans les 200 lignes (sinon il doit être divisé)

Il est facile d’écrire de plus en plus de codex, et il doit être « enfermé dans une petite boîte » avec des contraintes de relations publiques.

5. Que le test soit le “premier résultat”, pas le “dernier ajout”

Le piège le plus courant du Codex est que l’implémentation est entièrement écrite et que les tests semblent être là, mais le test ne fait que valider l’implémentation qu’il a écrite.

Je lui ai donc demandé d’afficher dans l’ordre :

1. Liste des cas de test (dont les limites sont couvertes)
2. Code de test clé
3. Implémenter le correctif

S’il ne peut pas fournir de points de test, cela signifie soit que les exigences ne sont pas clairement écrites, soit que ce changement ne lui convient pas.

6. Écrivez le “chemin de restauration” dans la modification

Les personnes qui apportent des modifications manuellement laissent souvent inconsciemment une solution de repli.

Il est facile pour la personne qui a effectué le changement d’oublier.

J’exigerais que chaque modification de build satisfasse à au moins une politique de restauration :

-indicateur de fonctionnalité

• Commutateurs de configuration
• Conserver l’ancien chemin pendant un moment (double passage)

Les changements majeurs sans chemin de restauration, peu importe qui les a écrits, ne devraient pas être mis en ligne. Le Codex facilite simplement la réalisation de « grands changements ».

7. Traitez la traçabilité comme un « élément de coût » lié à l’utilisation du Codex

Si vous ne comptez que « le temps de développement économisé », vous serez souvent encouragé à écrire de plus en plus de Codex.

Ce qui m’importe le plus, c’est de savoir si le problème peut être reproduit.

Donc, dans le processus, j’enregistrerai avec force trois choses :

• Description des tâches pour le Codex cette fois (y compris les critères d’acceptation)
• Plan de changement donné par le Codex
• Patch final et résultats des tests

Ces trois éléments constituent la chaîne de preuves lors de l’examen des accidents.

Sans journalisation, plus vous utilisez Codex, plus vous aurez l’impression d’utiliser un système non reproductible.

8. Un ensemble de squelettes de mots d’invite qui peuvent être utilisés directement

Le paragraphe suivant est le changement minimum pour que sa sortie soit mise en ligne.

Vous pouvez le copier directement et remplacer les crochets :

Des changements doivent être apportés dans un projet réel.

Contexte : [Deux ou trois phrases décrivant la situation et les problèmes actuels] Objectifs (niveau comportemental) :

• Doit faire : [Liste 2 à 4 éléments]
• Ne jamais changer : [Liste 2-4] Contraintes : - Interdit d’introduire de nouvelles dépendances/interdit de modifier l’API publique/doit être compatible avec les anciennes données (sélectionnez si nécessaire) Acceptation :
• donne une liste de points de test
• Donner au moins [N] codes de scénario de test clés Format de sortie :

1. Donnez d’abord un plan de changement (liste de documents + points à risque)
2. Donnez le plus petit patch (diff), n’incluez pas de long texte explicatif

Limites applicables

Les scénarios dans lesquels le Codex ne convient pas sont également clairs :

• Je ne peux même pas dire quel comportement je veux, donc je peux seulement « l’essayer d’abord »
• Il s’agit d’un changement à haut risque impliquant la migration des données, les autorisations et le financement, mais il n’existe pas d’environnement d’acceptation complet.
• Recours à des connaissances tacites (commutateurs en ligne, stratégies en niveaux de gris, incidents historiques) sans documentation

Dans ces scénarios, le Codex solidifiera l’incertitude directement dans le code.

Résumé

La réponse à la question « comment utiliser le Codex » est un ensemble de contraintes techniques.

Considérer cela comme une rédaction plus rapide met la responsabilité sur la révision et en ligne.

Traitez-le comme une section du pipeline, utilisez des critères d’acceptation, des tests, une restauration et une traçabilité pour contenir les modifications, et il deviendra un véritable outil d’efficacité.