Le 30 juillet 2026, le blog officiel de GitHub a présenté la méthode de fonctionnement « stacked session » dans Copilot : les développeurs peuvent créer plusieurs sessions dépendantes dans le même dépôt, permettant à la tâche suivante d’hériter du contexte et du code de la tâche précédente, puis de fusionner les pull requests dans l’ordre. Le problème n’est pas de savoir si le modèle peut écrire du code, mais si l’équipe peut encore le réviser en profondeur après que l’IA ait apporté trop de modifications en même temps.
Pourquoi un ancien projet a-t-il besoin d’une pile de session ?
Le cas de GitHub montre une application personnelle qui se poursuit depuis 2014, utilisant toujours React 15, Less et l’ancien React-Bootstrap. Les développeurs font d’abord planifier la modernisation du front-end par Copilot, puis la mettent progressivement en œuvre ; Lorsque la suppression de React-Bootstrap a commencé à dépasser la portée de la tâche actuelle, elle n’a pas continué à étendre la session initiale. Au lieu de cela, elle a d’abord créé des pull requests pour des travaux existants, puis de nouvelles sessions pour poursuivre le contexte précédent.
Copilot a ensuite accompli trois objectifs : sauvegarder la modification actuelle en tant que pull request ; Créer une nouvelle session de pile pour le remplacement des composants et générer un calendrier de confirmation en attente ; Créez la prochaine pull request basée sur la branche précédente. Ainsi, chaque modification a ses propres limites de révision tout en maintenant un ordre clair des dépendances.
Il vise un nouveau type de disparition de portée dans la programmation IA
La programmation IA réduit le coût de génération de code, mais rend aussi les « refontes majeures » bien trop faciles. Une seule invite peut rapidement s’étendre en des dizaines de milliers de lignes de modifications, mélangeant fonctionnalités, refactorisation, mises à jour de dépendances et ajustements de style. Même si le code fonctionne, les évaluateurs ont du mal à déterminer quels changements provoquent la régression.
L’empilement des sessions divise les longues tâches en parties incrémentales pouvant être testées et examinées indépendamment : d’abord fusionner la préparation sous-jacente, puis fusionner les fonctionnalités qui en dépendent ; Lorsqu’un problème survient à un certain étage, il est également plus facile de le localiser et de le retirer. Cela fait passer l’unité de travail de l’agent IA d’une longue conversation unique à un ensemble de petites tâches avec des relations de livraison.
Ne négligez pas ces quatre points de contrôle lors de l’utilisation
- Chaque session ne conserve qu’un objectif clair, évitant de simples refactorisations aléatoires.
- Après le changement des pull requests de niveau inférieur, la branche de la couche supérieure doit être resynchronisée et les conflits traités.
- Les tests doivent suivre chaque couche de modification, plutôt que de s’exécuter uniformément une fois la pile complète terminée.
- L’ordre des fusions doit être clair ; Lorsque les dépendances de code de la couche supérieure ne sont pas encore entrées dans la branche principale, elles ne doivent pas être confondues avec des redistributions indépendantes.
Les sessions de stacking n’aident pas les développeurs à décider quelles frontières diviser, ni ne prouvent automatiquement que le code est correct. Sa véritable valeur réside dans le fait que les agents de codage de longue durée restent soumis aux contraintes traditionnelles de l’ingénierie logicielle : modifications à petite échelle, vérification indépendante, dépendances claires et revues de rétroaction. Pour les mises à jour des systèmes hérités et les migrations en plusieurs étapes, cela est plus fiable que de viser une génération unique et une achèvement complet.
