À l’université, j’ai participé au programme bêta de l’une des premières versions de la complétion de code inline par AI dans VS Code. J’avais le sentiment que cela allait changer la donne. Depuis, GenAI a fondamentalement transformé le développement logiciel : des équipes hybrides ont émergé, où les agents et les humains travaillent ensemble, et où le développeur reste au centre en tant que visionnaire et orchestrateur. Nous vivons actuellement cette transformation.
Conséquence naturelle de la vitesse à laquelle progresse l’innovation dans le domaine de GenAI, nous disposons désormais d’outils capables de nous aider à planifier, développer, examiner et déployer notre code. Pourtant, dans la situation actuelle, de nombreux workflows donnent encore l’impression d’être fragmentés. Le contexte se perd entre les conversations et les interfaces, et l’examen du travail produit par les agents prend plus de temps que nécessaire. Les agents peuvent produire des modifications plus rapidement qu’une personne ne pourrait les examiner, et la plupart des outils pour développeurs n’ont pas été conçus à l’origine pour l’orchestration de plusieurs agents.
Il devient facile de ne plus savoir ce qui a été exécuté, ce qui a changé, ce qui a été vérifié et quels points nécessitent encore un jugement humain.
L’application GitHub Copilot constitue une étape importante pour répondre à ce problème. Il y a notamment une fonctionnalité que j’apprécie particulièrement et que j’ai appris à utiliser presque tous les jours : les canvas. Les canvas permettent aux développeurs et aux agents d’interagir dans un espace partagé et persistant. Plutôt que de considérer Chat comme le seul endroit où le travail s’accomplit, les canvas rendent le travail visible, orientable et validable au fur et à mesure de sa progression.
Chat est idéal pour exprimer une intention, mais moins adapté à l’exécution durable du travail
Je continue de penser que Chat est l’une des meilleures interfaces dont nous disposons pour exprimer des intentions. C’est l’endroit où vous pouvez réfléchir, développer et orienter. Il est particulièrement rapide et flexible lorsque le problème reste encore flou.
Cependant, lorsqu’un agent commence à effectuer le véritable travail, Chat se transforme en un flux interminable d’instructions, de logs, de changements d’orientation et de corrections. Les éléments importants s’y trouvent techniquement, mais ils sont enfouis : le plan, les points de décision, les validations et les moments d’approbation. Si vous devez reconstituer tout cela à partir de l’historique, vous avez déjà commencé à payer le coût de la coordination.
Les canvas résolvent ce problème en offrant un cadre aux flux de travail. Ils rendent l’état clair et persistant. Les humains peuvent les examiner et les orienter. Les agents peuvent les mettre à jour et progresser. Les uns comme les autres peuvent rester alignés sans devoir constamment réactiver le contexte.
Premier projet : Java Modernization Studio
L’un des premiers canvas que j’ai développés était Java Modernization Studio. La modernisation Java est précisément un exemple de flux de travail où la visibilité et la gouvernance sont essentielles : évaluation, planification, tâches de migration, étapes de validation et préparation à la publication.
Dans une expérience reposant uniquement sur Chat, ces étapes se mélangent.
Vous pouvez continuer à avancer, mais il devient difficile de superviser le processus et de lui faire confiance à grande échelle, en particulier lorsque plusieurs contributeurs sont impliqués. Les équipes continuent de poser les mêmes questions coûteuses : À quelle étape en sommes-nous ? Quelles décisions ont été prises ? Qu’est-ce qui nous bloque ? Que reste-t-il à faire et qui nécessite une approbation humaine ?
Studio a rendu chaque étape claire et vérifiable. Les équipes pouvaient voir directement l’état opérationnel au lieu de disséquer l’historique narratif. Elles pouvaient vérifier ce qui s’était passé au lieu de le deviner. Les agents poursuivaient l’exécution entre les points de contrôle, tandis que les évaluateurs humains se concentraient sur les évaluations importantes.
Découvrez le canvas Java Modernization Studio >
Deuxième étude : Site Studio
Ensuite, j’ai développé Site Studio pour un flux de travail très différent : créer et gérer le contenu d’un site personnel. Bien que cette étude soit davantage axée sur le contenu que sur la migration, le problème d’orchestration est similaire : progression des sections, modifications itératives, cycles de révision et transitions d’état.
Dans un flux reposant uniquement sur Chat, le contenu peut rapidement dériver. Une section est révisée, puis révisée à nouveau, et la confiance diminue quant à celle qui est à jour. Les retours se dispersent, les brouillons se répètent et la progression ralentit, car chaque itération recommence par reconstituer le contexte.
Site Studio rend cet état persistant. L’état de chaque section est visible. Les valeurs des brouillons sont enregistrées au fur et à mesure du travail. Les points de révision humaine sont clairement définis.