Le changement de contexte est le travail

Pendant la majeure partie de ma carrière de développeur, le changement de contexte était l'ennemi.

L'état productif, c'était la concentration profonde. On chargeait une fonctionnalité dans sa tête : la forme de la base de code, les fichiers concernés, les cas limites, la suite de tests, les compromis derrière l'implémentation existante. Une fois cette carte mentale réchauffée, la meilleure chose que les autres pouvaient faire était de vous laisser tranquille. Une réunion, un fil Slack, une question support ou une deuxième fonctionnalité en expulsait une partie. La reconstruire coûtait cher.

Cela avait du sens parce que l'implémentation était l'activité rare. Si vous étiez la personne qui écrivait le code, garder toute la pile de détails en mémoire à court terme était le travail. Il fallait savoir où intervenir, quelle abstraction réutiliser, quels tests lancer et ce qui avait déjà été tenté. Plus vous saviez rester dans cet état, plus vous livriez vite.

Le codage agentique change cette équation.

Quand je travaille avec un agent de code, je dois toujours comprendre la fonctionnalité. Je dois toujours savoir à quoi ressemble un bon résultat. Mais une fois le problème cadré, l'étape suivante n'est souvent plus de taper l'implémentation moi-même. Elle consiste à confier la tâche à l'agent, le laisser explorer la base de code, modifier les fichiers, lancer les tests, rencontrer des erreurs, les corriger, puis revenir avec un compte rendu.

Cette boucle prend du temps. Parfois cinq minutes. Parfois trente. Sur une grande base de code, le simple fait de lancer les tests pertinents peut déjà prendre un moment. Pendant ce temps, le développeur humain n'est pas exactement inactif, mais il n'utilise plus le même type d'attention ininterrompue qu'exigeait l'implémentation manuelle. Il attend qu'un travailleur revienne avec un résultat.

La réaction évidente est de commencer une autre tâche.

Puis une autre.

Puis le premier agent termine, et il faut revenir au contexte initial. Vous relisez le diff, parcourez la transcription, vérifiez si l'implémentation correspond à l'intention, lancez ou inspectez les tests, décidez si l'agent était bloqué pour une vraie raison ou s'il a simplement perdu le fil, puis vous acceptez le travail ou vous le renvoyez dans une nouvelle itération. Quelques minutes plus tard, une autre tâche est prête à être revue. Puis une autre.

C'est là que le développement logiciel donne l'impression de s'inverser. L'ancien idéal consistait à réduire le changement de contexte pour qu'une personne puisse implémenter rapidement une chose. La compétence émergente consiste à changer de contexte assez bien pour superviser plusieurs implémentations en parallèle.

C'est un métier différent.

Il n'est pas moins technique. À certains égards, il pardonne moins. L'agent peut écrire le code, mais il ne peut pas porter la responsabilité du jugement produit, du périmètre du changement, de la qualité de l'abstraction ou de la décision que les tests prouvent bien ce qu'il fallait prouver. Tout cela appartient encore à l'ingénieur. Ce qui change, c'est l'endroit où l'ingénieur passe le plus de temps. Moins à pousser des caractères dans des fichiers. Plus à décomposer le travail, préserver l'intention, relire les résultats et décider ce qui mérite une nouvelle itération.

Dans ce monde, le changement de contexte n'est plus seulement une taxe. Il devient une partie du modèle de production.

On voit déjà les outils évoluer dans cette direction. Des applications comme Conductor, Superset et Herdr sont construites autour du travail agentique parallèle. Elles partent du principe qu'un développeur peut avoir plusieurs espaces de travail actifs à la fois, chacun avec sa branche, sa session d'agent, ses logs, ses tests et son état de revue. Elles n'optimisent pas pour l'ancienne image du développeur qui fixe un buffer d'éditeur jusqu'à ce que la fonctionnalité soit terminée. Elles optimisent pour un développeur qui distribue le travail, surveille l'avancement et revient dans le bon contexte au bon moment.

Les worktrees Git sont un bon symbole de ce basculement. Je les connaissais depuis des années, mais je ne les utilisais presque jamais. Pourquoi l'aurais-je fait ? J'implémentais rarement plusieurs fonctionnalités en même temps. Avec les agents de code, les worktrees sont passés du statut de curiosité à celui d'infrastructure quotidienne. Ils permettent à chaque agent d'avoir son propre checkout propre, sa propre branche et ses propres tests sans piétiner le travail des autres.

Mon propre workflow a suivi le même chemin, même si j'ai été têtu sur l'endroit où je voulais qu'il vive. J'ai passé des années à façonner Emacs comme environnement de travail : buffers, splits, Magit, LSP, recherche, navigation, revue. Quand le codage agentique est arrivé, je n'avais pas particulièrement envie de remplacer tout cela par une nouvelle application desktop. Je voulais le workflow d'agents parallèles dans l'éditeur que je connaissais déjà.

J'ai donc utilisé un agent pour construire une version Emacs de cette idée :

emacs-superset sur GitHub

C'est essentiellement un gestionnaire de worktrees conscient de ce que font mes agents : quelles tâches tournent, lesquelles m'attendent et lesquelles sont prêtes à être relues. Il n'est pas aussi poli que les versions financées par du capital-risque du même concept, mais il me convient mieux parce qu'il est intégré aux outils que j'utilise déjà. Je relis toujours dans Magit. Je navigue toujours entre les buffers comme avant. La différence est que l'unité de travail n'est plus seulement « le fichier que je suis en train d'éditer » ; c'est « l'ensemble des tâches d'agents que je supervise ».

Cette distinction compte parce que la partie difficile devient de réhydrater rapidement le contexte.

Quand un agent revient après vingt minutes, je dois retrouver l'intention initiale de la tâche, comprendre le chemin qu'il a pris et juger le résultat sans repartir de zéro. Cela exige de meilleures notes, de meilleures descriptions de tâches, des périmètres plus petits, des critères d'acceptation plus clairs et une isolation plus propre entre les efforts parallèles. Cela récompense les développeurs capables de rendre un problème lisible avant de le déléguer, puis de relire la réponse avec esprit critique quand elle revient.

Autrement dit, la compétence n'est pas « laisser l'agent coder et arrêter de penser ». Elle ressemble plutôt à de l'édition technique, du debugging et du pilotage de projet compressés dans un workflow individuel.

Cet argument a des limites. Je parle surtout de développement applicatif, en particulier de la grande quantité de travail logiciel professionnel qui consiste à livrer des fonctionnalités produit compréhensibles sur des systèmes existants : CRUD, intégrations, changements d'interface, migrations, outils internes, endpoints d'API, tests, refactors et toute la plomberie peu glamour qui fait avancer les produits.

Si vous travaillez sur un algorithme subtil, un nouveau moteur de base de données, une optimisation de compilateur, un problème difficile de systèmes distribués ou tout sujet dont le travail central consiste à maintenir un modèle mathématique ou conceptuel profond dans votre tête, les anciennes règles s'appliquent peut-être encore plus fortement. La concentration profonde ne disparaît pas partout.

Mais la plupart des développeurs ne passent pas l'essentiel de leurs journées à inventer de nouveaux algorithmes. La plupart d'entre nous font avancer du logiciel produit à travers une longue séquence de changements bornés. Pour ce type de travail, le codage agentique rend le parallélisme praticable d'une manière qui ne l'était pas auparavant.

Le développeur productif de demain ne sera peut-être pas celui qui peut disparaître six heures dans une implémentation unique et ininterrompue. Ce sera peut-être celui qui sait garder cinq morceaux de travail en mouvement, revenir dans chacun au bon moment, comprendre ce qui a changé et prendre rapidement une bonne décision.

Avant, je détestais le changement de contexte parce qu'il cassait le travail.

Désormais, il est de plus en plus le travail.