Contexte technique
J'aime ce genre d'idées, non pas pour l'effet « wow », mais parce qu'elles éliminent immédiatement un vrai problème. Le principe est simple : j'ajoute un done skill qui, à la fin de la tâche, écrit automatiquement un bref historique des décisions dans devlog.md. Ce n'est plus un jouet, mais une base solide pour l'AI automation dans le développement.
L'architecture repose sur deux éléments. D'abord, le skill lui-même : il rassemble ce que j'ai décidé lors de cette session, pourquoi j'ai choisi cette voie, quelles alternatives j'ai rejetées et ce qui reste à faire. Ensuite, AGENTS.md ou agent.md à la racine du dépôt, où je dis explicitement à l'agent : une fois la tâche terminée, appelle le done skill.
J'apprécie le fait qu'il n'y ait presque pas de magie. Je peux stocker le skill sous forme de fichier markdown séparé, définir un modèle d'enregistrement fixe et exiger la création de devlog.md s'il n'existe pas encore. Moins il y a de liberté dans le format, moins il y a de bruit dans le journal.
Je structurerais l'entrée ainsi : tâche, décision prise, raison, options rejetées, fichiers modifiés, suivi (follow-up). C'est suffisant pour qu'un autre agent ou développeur n'ait pas à deviner le lendemain pourquoi le code a pris cette direction. Les messages de commit ne suffisent pas à ce niveau.
Pour plus de fiabilité, je suggère de déléguer l'écriture à un script tel que log_done.sh. De cette façon, l'agent ne génère pas de markdown manuellement, mais appelle un mécanisme prévisible. Pour l'AI integration dans le flux de travail d'une équipe, c'est beaucoup plus robuste que de compter sur la discipline du modèle.
Impact sur les affaires et l'automatisation
Je constate l'effet pratique immédiatement à trois niveaux. Premièrement, des transferts (handoffs) moins coûteux : un nouvel agent ou développeur s'intègre beaucoup plus rapidement. Deuxièmement, moins de décisions répétées et de refactorisations inutiles. Troisièmement, il est plus facile d'analyser l'origine d'un choix d'architecture controversé.
Les équipes avec plusieurs agents, des changements de contexte fréquents et de longues branches de tâches sont gagnantes. Celles qui continuent d'espérer que « tout est visible dans le code » perdent. Non, ce n'est pas le cas.
Je teste directement ces solutions sur des flux de tâches réels, car sur le papier, les modèles sont attrayants, mais dans un dépôt actif, les doublons, les entrées vides et le bruit apparaissent vite. C'est précisément ce type de workflow que nous optimisons pour nos clients chez Nahornyi AI Lab, lorsqu'il s'agit de bâtir une AI architecture opérationnelle autour de l'équipe, plutôt que de simplement connecter un modèle.
Si votre agent écrit déjà du code, mais que la mémoire des décisions s'évapore dans l'historique du chat à chaque fois, analysons votre processus. Chez Nahornyi AI Lab, je peux vous aider à structurer cette AI automation afin de préserver le contexte et de permettre à votre équipe de progresser plus rapidement, sans tâches manuelles superflues.