Kodacode 1.3 réunit quatre modes de travail de l’agent dans un seul client Desktop

L’agent a écrit le code et modifié une dizaine de fichiers — puis commence le travail habituel : ouvrir les changements, vérifier chaque modification, lancer les tests, avant de chercher pourquoi l’automatisation dans la CI s’est terminée avec un texte étrange au lieu d’un statut normal. Kodacode 1.3 tente de réunir ce processus fragmenté en un seul endroit. L’agent peut désormais interagir avec des applications par leur interface, ouvrir des pages dans le navigateur intégré, afficher ses propres modifications et s’exécuter dans un pipeline avec un résultat lisible par une machine.

L’intérêt pratique ne réside pas dans une énième fenêtre de chat. Le développeur bénéficie d’un cycle de travail plus cohérent : confier une tâche, observer les actions de l’agent, examiner le diff et transmettre le résultat à l’outil suivant. L’équipe produit peut rapidement assembler un prototype interactif à partir des composants du projet. L’équipe chargée de l’automatisation dispose de workflows visuels combinant requêtes HTTP, outils MCP, conditions et validation humaine obligatoire.

L’agent sort du cadre de l’éditeur

Le mode Computer Use permet à Kodacode de voir l’écran, de repérer la fenêtre nécessaire, de cliquer sur des éléments de l’interface, de faire défiler les pages et de saisir du texte. Il est disponible dans l’application de bureau et dans les extensions IDE en mode Agent.

Exemple simple : il faut transférer les données d’un tableau de bord interne vers une feuille de calcul, mais le tableau de bord ne propose pas d’API pratique. L’agent peut ouvrir l’application, retrouver l’enregistrement, copier les valeurs et remplir le formulaire. Auparavant, une telle tâche aurait nécessité une automatisation de navigateur distincte ou un traitement entièrement manuel.

Un navigateur intégré fait également son apparition. Les liens s’ouvrent dans le client Desktop, le fragment sélectionné d’une page peut être immédiatement transmis à l’agent, tandis que la recherche, la sélection d’éléments et les captures d’écran facilitent la vérification. Cela réduit les allers-retours entre le chat, le navigateur et l’éditeur, sans rendre pour autant les actions de l’agent intrinsèquement fiables.

C’est précisément ici que le contrôle est essentiel. Un agent visuel peut cliquer sur le mauvais bouton, mal interpréter l’état de l’interface ou poursuivre son travail après l’apparition d’une fenêtre inattendue. Les opérations de publication, de paiement, de suppression de données et de modification des paramètres ne doivent donc jamais lui être confiées sans confirmation humaine.

Modifications et prototypes visibles à côté du dialogue

Le client Desktop permet désormais de consulter les changements à deux niveaux : pour l’ensemble du dialogue et pour un message particulier. Cela aide à distinguer le résultat d’une instruction précise des modifications accumulées. Le diff fonctionne même dans les dossiers sans Git : l’application suit elle-même les changements apportés par l’agent.

L’espace de travail peut être divisé entre le chat et l’affichage du fichier. On y trouve l’arborescence du projet, la coloration syntaxique et la possibilité d’associer un passage précis à la requête suivante. Pour une longue session, cela s’avère plus utile qu’une question générale comme « qu’as-tu modifié ? » : le développeur montre directement la ligne problématique et demande de corriger celle-ci en particulier.

Autre scénario : les prototypes interactifs. L’agent peut assembler plusieurs écrans à partir des composants et des styles existants du projet, puis l’équipe peut comparer les versions mobile et Desktop. Cela ne remplace pas une revue de conception, mais accélère la validation d’une hypothèse avant que les développeurs ne commencent à peaufiner l’implémentation.

Flows et la CLI intègrent l’agent au système

Flows est un constructeur visuel d’automatisations comparable à n8n ou Zapier, à ceci près que certaines étapes peuvent être exécutées par un agent. Un workflow peut être lancé manuellement, selon un calendrier, par un webhook ou par un autre workflow. Il prend en charge les branchements, les boucles, les fichiers, HTTP, MCP et les interruptions pour validation.

Par exemple, un scénario matinal récupère les actualités, les filtre, prépare un brouillon et attend l’approbation de l’éditeur. Le mot essentiel est ici « attend » : la vérification manuelle est intégrée au processus lui-même, au lieu de reposer sur une simple promesse de l’équipe de ne pas publier automatiquement le résultat. Flows étant encore en version bêta, il est raisonnable de doubler les processus critiques par une journalisation et des contrôles dans un système externe.

Le mode headless a été étendu pour la CI. La CLI peut recevoir un flux de requêtes via stdin, renvoyer les événements sous forme de JSON ligne par ligne, indiquer la consommation de jetons et se terminer avec un code explicite. Le code 0 signifie que l’exécution a réussi ; un code différent de zéro indique que la tâche n’a pas été accomplie. Une limite d’étapes permet d’interrompre une exécution bloquée dans une boucle ; lorsque cette limite est atteinte, la raison de l’arrêt et le code 2 sont renvoyés.

Conclusion pratique : il vaut mieux commencer par tester la CLI sur une vérification sans risque — par exemple une analyse des changements en lecture seule. Il faut ensuite raccorder le flux JSON aux journaux de la CI, définir une limite d’étapes et vérifier le traitement de tous les codes de sortie. Computer Use et Flows devraient être introduits par la suite, en commençant par des opérations réversibles et en imposant une confirmation avant toute action externe.