Agent Skills

 (addyosmani.com)
1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Agent Skills est un scaffolding qui impose sous forme de workflow des procédures d’ingénierie senior afin que les agents d’IA pour le code ne puissent pas sauter des étapes comme la spécification, les tests, des PR réellement relisibles ou l’examen des frontières de confiance
  • Un skill est un fichier Markdown avec frontmatter ; il se rapproche davantage d’un workflow avec ordre des étapes, preuves aux checkpoints et critères de sortie que d’une simple documentation de référence
  • Les 20 skills du dépôt sont organisés en 6 étapes du cycle de vie — Define, Plan, Build, Verify, Review, Ship — et 7 commandes slash : /spec, /plan, /build, /test, /review, /ship, /code-simplify
  • Les principes clés sont le processus plutôt que la prose, des tableaux anti-rationalisation, la validation comme critère de sortie, la divulgation progressive et la discipline de périmètre ; using-agent-skills n’active que les skills adaptés à la tâche
  • L’outil peut être utilisé via l’installation marketplace de Claude Code, via des Markdown placés dans Cursor .cursor/rules/, Gemini CLI, Codex, Aider, Windsurf, OpenCode et d’autres outils, et il est publié sous licence MIT

Objectif et constat de départ

  • Agent Skills est un scaffolding conçu pour imposer sous forme de workflow des procédures d’ingénierie senior que les agents d’IA pour le code sautent par défaut
  • Lorsqu’on leur demande une fonctionnalité, les agents d’IA pour le code vont généralement au plus court et se contentent d’implémenter, sans produire par défaut de spécification, sans faire du test-first, sans examiner les frontières de confiance ni structurer une PR réellement relisible
  • Une grande partie du travail d’un ingénieur senior n’apparaît pas dans un diff
    • expliciter les hypothèses
    • rédiger une spécification
    • découper le travail en unités relisibles
    • choisir des conceptions ennuyeuses mais sûres
    • laisser des preuves que le résultat est correct
    • limiter les changements à une taille qu’un humain peut réellement relire
  • Si les agents sautent ces étapes, c’est pour une raison proche de celle d’un ingénieur junior : leur signal de récompense est aligné sur « tâche terminée », pas sur « tâche terminée avec la spécification qui va avec »
  • Le dépôt Agent Skills a dépassé les 26K stars et va au-delà du README : il couvre les raisons derrière les choix de conception, les correspondances avec le SDLC standard et les pratiques d’ingénierie publiques de Google, ainsi que des patterns réutilisables même sans installation

Ce que signifie réellement un skill

  • Un skill est un fichier Markdown avec frontmatter injecté dans le contexte de l’agent selon la situation ; il se situe entre un fragment de system prompt et un runbook
  • Un skill n’est pas un document de référence, ni une collection de connaissances du type « tout ce qu’il faut savoir sur les tests »
  • Un skill utile est un workflow que l’agent suit
    • il y a un ordre des étapes
    • il produit des preuves aux checkpoints
    • il se termine avec des critères de sortie clairs
  • Si l’on met dans le contexte un essai de 2 000 mots sur les bonnes pratiques de test, l’agent peut générer des phrases plausibles et quand même sauter les vrais tests
  • À l’inverse, si l’on fournit un workflow où il faut d’abord écrire un test qui échoue, l’exécuter pour vérifier l’échec, écrire l’implémentation minimale nécessaire, vérifier qu’il passe puis refactoriser, l’agent a des actions concrètes à exécuter et un humain peut vérifier le résultat
  • La distinction centrale est le processus plutôt que la prose, le workflow plutôt que la référence, des étapes avec critères de sortie plutôt qu’un essai sans fin définie
  • Si beaucoup de dépôts de type « AI rules » produisent peu d’effet, c’est parce que leurs règles restent au stade de l’essai et non du workflow

Structure SDLC et commandes slash

  • Les 20 skills du dépôt sont structurés en 6 étapes du cycle de vie, sur lesquelles viennent se superposer 7 commandes slash

  • Étapes et commandes

    • /spec : l’étape Define, pour décider quoi construire
    • /plan : l’étape Plan, pour décomposer le travail
    • /build : l’étape Build, pour implémenter en vertical slice
    • /test : l’étape Verify, pour prouver le fonctionnement
    • /review : l’étape Review, pour attraper ce qui a échappé
    • /ship : l’étape Ship, pour livrer en sécurité aux utilisateurs
    • /code-simplify : une commande de simplification applicable sur l’ensemble du flux
    • Cette structure suit le même mouvement que le SDLC d’une organisation d’ingénierie qui fonctionne ; seul le vocabulaire change selon les organisations
    • Chez Google, cela correspond à un flux design doc → review → implementation → readability review → launch checklist ; chez Amazon, on retrouve des approches comme le working-backwards memo et le bar raiser
    • Le nouveau problème avec les agents d’IA pour le code, c’est que la plupart sautent par défaut la majorité de ces étapes
    • On demande une fonctionnalité, et seule l’implémentation sort ; la spécification, le plan, les tests, la revue et la checklist de lancement ne sont pas exécutés
    • Les skills font aussi passer les agents par les étapes qu’un ingénieur senior s’impose à lui-même, car déployer du code sans ces procédures mène aux incidents
    • Une fonctionnalité complexe peut activer 11 skills à la suite, tandis qu’une petite correction de bug n’en utilisera que 3
    • Le routeur using-agent-skills décide quels skills s’appliquent à la tâche en cours, et le workflow s’étend selon la portée réelle, non selon une portée supposée

Les principes qui soutiennent le fonctionnement

  • 1. Le processus plutôt que la prose

    • Un workflow peut être mis en action par l’agent, un essai non
    • Le même principe s’applique aux équipes humaines
    • Si le handbook d’une équipe fait 200 pages, personne ne le lit sous pression ; un petit workflow avec checkpoints a bien plus de chances d’être réellement exécuté

  • 2. Les tableaux anti-rationalisation

    • Le choix de conception le plus distinctif d’Agent Skills — et que d’autres équipes devraient reprendre — est celui des tableaux anti-rationalisation
    • Chaque skill inclut des excuses fréquentes qu’un agent ou un ingénieur fatigué pourrait utiliser pour contourner le workflow, avec une réfutation préparée à l’avance
    • Exemples
      • « Cette tâche est trop simple pour nécessiter une spécification » → les critères d’acceptation s’appliquent quand même. 5 lignes, c’est acceptable ; 0 ligne, non
      • « J’écrirai les tests plus tard » → le problème clé, c’est justement « plus tard ». Il n’y a pas de plus tard. Il faut d’abord écrire un test qui échoue
      • « Les tests passent, on peut déployer » → des tests qui passent sont une preuve, pas une démonstration totale. Il faut vérifier le runtime, le comportement visible pour l’utilisateur et s’assurer qu’un humain a lu le diff
    • Les LLM excellent dans la rationalisation et peuvent produire des paragraphes plausibles expliquant qu’une tâche donnée n’a pas besoin de spécification ou qu’un changement peut être mergé sans review
    • Les tableaux anti-rationalisation sont des réfutations écrites à l’avance contre des mensonges que l’agent n’a pas encore prononcés
    • Ce pattern fonctionne aussi pour les équipes humaines
    • La dégradation de la qualité en ingénierie vient rarement d’une décision explicite de mal faire ; elle vient plutôt de l’acceptation de justifications plausibles pour sauter des procédures pénibles

  • 3. La validation n’est pas négociable

    • Tous les skills se terminent par des preuves concrètes
    • Tests passants, sortie de build propre, trace runtime montrant le comportement attendu, approbation d’un reviewer : voilà les critères de sortie
    • « Ça a l’air plausible » ne suffit pas
    • C’est le même principe que celui par lequel le harness d’Anthropic récupère après échec, la séparation planner/worker/judge de Cursor attrape réellement des bugs, et les long-running agents deviennent récupérables
    • Un agent étant un générateur, il lui faut un signal distinct pour juger qu’un travail est terminé ; les skills intègrent ce signal dans chaque workflow

  • 4. La divulgation progressive

    • On ne charge pas les 20 skills dans le contexte au début de la session
    • Seuls les skills nécessaires à l’étape courante sont activés
    • Un petit meta-skill, using-agent-skills, joue le rôle de routeur pour choisir les skills adaptés à la tâche en cours
    • C’est l’application, au niveau du skill, des leçons de la harness engineering
    • Chaque token chargé dans le contexte coûte quelque part en performance ; il faut donc ne charger que ce qui est pertinent et laisser le reste sur disque
    • La divulgation progressive est la manière de faire tenir une bibliothèque de 20 skills dans un slot de 5K tokens sans polluer tout le contexte

  • 5. La discipline de périmètre

    • Le meta-skill encode comme principe non négociable : « ne touche qu’à ce qui est demandé »
    • Il ne faut pas refactorer les systèmes adjacents, ni supprimer du code qu’on ne comprend pas entièrement, ni voir un TODO et décider de réécrire tout le fichier
    • Un agent peut vouloir corriger un bug puis « moderniser » trois fichiers sans rapport
    • La discipline de périmètre est le plus grand facteur qui détermine si la PR de l’agent est mergeable ou doit être revertée
    • Cela s’aligne aussi très bien avec les normes de code review de Google, où un reviewer peut bloquer une PR qui fait plus d’une chose

Lien avec les pratiques d’ingénierie de Google

  • Agent Skills reprend de nombreuses pratiques issues de Software Engineering at Google et de la culture d’ingénierie publique de Google
  • Une grande partie de ce qui permet au logiciel de fonctionner à l’échelle de Google est documentée publiquement, et c’est précisément cette partie que les agents sautent le plus souvent

  • Correspondance entre skills et pratiques

    • api-and-interface-design reflète Hyrum’s Law. Tout comportement observable d’une API finit par être utilisé par quelqu’un, il faut donc le prendre en compte dans la conception
    • test-driven-development reflète la pyramide de test ~80/15/5 et la Beyoncé Rule : « si tu l’aimais vraiment, il fallait lui mettre un test ». Ce ne sont pas les changements d’infrastructure qui attrapent les bugs, ce sont les tests
    • Le principe DAMP over DRY pour les tests : selon la philosophie de Google, le code de test doit se lire comme une spécification, même au prix d’un peu de duplication. Les tests sur-abstraits sont un anti-pattern connu
    • code-review-and-quality reflète des PR d’environ ~100 lines et les labels de sévérité Critical / Nit / Optional / FYI. Les grosses PR ne sont en pratique pas vraiment relues et finissent souvent approuvées machinalement
    • code-simplification reflète Chesterton’s Fence. Il ne faut pas supprimer quelque chose avant d’avoir compris pourquoi c’était là
    • git-workflow-and-versioning reflète le trunk-based development et les atomic commits
    • ci-cd-and-automation reflète le Shift Left et les feature flags. Il faut attraper les problèmes aussi tôt que possible et découpler déploiement et release
    • deprecation-and-migration reflète l’idée de code-as-liability. Chaque ligne maintenue devra l’être pour toujours ; mieux vaut donc une surface plus petite
    • Ces concepts ne sont pas nouveaux, mais ils ne sont pas embarqués par défaut dans les agents
    • Même si un frontier model a lu l’expression « Hyrum’s Law » dans ses données d’entraînement, il ne va pas l’appliquer automatiquement à 3 h du matin pendant la conception d’une API
    • Les skills font appliquer ces pratiques à l’agent pendant le travail réel

Comment l’utiliser en pratique

  • Méthode 1 : installation via marketplace

    • Si vous utilisez Claude Code, l’installation se fait avec les commandes suivantes
    /plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
    • Une fois installé, on peut utiliser les commandes slash /spec, /plan, /build, /test, /review, /ship, /code-simplify
    • L’agent active automatiquement les skills pertinents selon le contexte
    • Pour la plupart des utilisateurs, c’est la manière recommandée de commencer

  • Méthode 2 : mettre les fichiers Markdown dans l’outil de son choix

    • Les skills sont de simples fichiers Markdown avec frontmatter
    • Les utilisateurs de Cursor peuvent les placer dans .cursor/rules/
    • Gemini CLI a son propre chemin d’installation
    • Codex, Aider, Windsurf, OpenCode et d’autres outils capables de recevoir du contenu de system prompt peuvent aussi les lire
    • Plus que l’outil lui-même, ce qui compte est le workflow sous-jacent

  • Méthode 3 : les lire comme une spécification

    • Même sans rien installer, les skills documentent une manière de faire de la bonne ingénierie avec des agents d’IA
    • On peut lire code-review-and-quality.md et appliquer son framework à 5 axes au processus de review de l’équipe
    • On peut lire test-driven-development.md pour nourrir des débats du type « faut-il écrire les tests d’abord ? »
    • On peut lire les meta-skills et reprendre les 5 principes non négociables dans son propre AGENTS.md
    • Un bon point de départ consiste à choisir 4 ou 5 skills au plus près du problème le plus douloureux du moment, définir les workflows qu’on veut imposer, puis installer ou construire un runtime qui les applique

Des patterns à reprendre même sans installation

  • Faire de l’anti-rationalisation une pratique d’équipe

    • Une équipe doit écrire les mensonges qu’elle se raconte à elle-même
    • Exemples : « on corrigera les tests après la release », « ce changement est trop petit pour nécessiter un document de conception », « il y a du monitoring, donc ça va »
    • Ajouter une réfutation à chaque phrase et les mettre dans AGENTS.md ou dans le wiki d’ingénierie permet de réduire les débats et d’éviter les raccourcis fatigués du vendredi après-midi

  • Écrire la documentation interne comme un processus, pas comme de la prose

    • Si l’on écrit un document de 2 000 mots intitulé « comment abordons-nous X », on produit un support de référence
    • Si on le transforme en workflow avec checkpoints, le document peut tomber à 400 mots et aura bien plus de chances d’être exécuté
    • Ce principe s’applique aux guides d’onboarding, aux runbooks et aux skills d’agent

  • Faire de la validation un critère de sortie solide

    • La dernière étape de tout travail devrait être « produire une preuve »
    • Cela vaut pour les agents, les ingénieurs et le travail individuel
    • Une preuve peut être un run de tests au vert, une capture d’écran, des logs, une approbation de review — tout élément démontrant que le travail est terminé
    • Sans preuve, le travail n’est pas terminé, et « ça a l’air plausible » ne ferme pas la boucle

  • Appliquer la divulgation progressive à tout corpus de règles

    • Au lieu d’écrire un handbook de 50 pages, mieux vaut écrire un petit routeur qui envoie vers de petits chapitres selon la situation
    • Cela vaut pour AGENTS.md, les runbooks, les playbooks de gestion d’incident et tout document destiné à être lu sous pression

  • Les 5 principes non négociables à mettre dans AGENTS.md

    • Il faut expliciter les hypothèses avant de construire. Des hypothèses erronées gardées silencieuses sont l’un des modes de défaillance les plus fréquents
    • Si les exigences entrent en conflit, il faut s’arrêter et demander. Il ne faut pas deviner
    • Il faut s’opposer quand c’est nécessaire. Un agent ou un ingénieur n’est pas là pour dire oui à tout
    • Il faut préférer les solutions ennuyeuses et claires. L’ingéniosité coûte cher
    • Il ne faut toucher qu’à ce qui est demandé

La place des skills dans le harness

  • Les skills sont, dans une perspective plus large, une couche de agent harness engineering
  • Le harness comprend le modèle et tout ce qui est construit autour ; les skills sont des fragments de workflow réutilisables, révélés progressivement dans le system prompt
  • Les skills se placent à côté de AGENTS.md, des hooks, des tools et du session log
    • AGENTS.md : joue le rôle de corpus de règles continuellement mis à jour
    • hooks : couche d’application déterministe
    • tools : actions que l’agent peut exécuter
    • session log : mémoire persistante
    • skills : prennent en charge les processus d’ingénierie senior
  • Les skills sont encore plus importants pour les long-running agents que pour les agents conversationnels
  • Les exécutions longues amplifient tous les raccourcis
    • Dans une session de 10 minutes, un agent qui saute les tests peut créer un bug
    • Dans une session de 30 heures, un agent qui saute les tests peut produire, à la fin de l’exécution, une opération d’archéologie de debug dont personne ne se souvient plus de l’intention d’origine
  • Plus la durée d’exécution s’allonge, plus le scaffolding d’ingénierie senior doit être imposé et non simplement suggéré
  • La portabilité du format des skills est aussi importante
  • Le même fichier SKILL.md peut être utilisé avec Claude Code, Cursor via ses rules, Gemini CLI, Codex et d’autres harness capables de recevoir du contenu de system prompt
  • On écrit le workflow une fois, puis le runtime peut l’imposer ; c’est l’avantage du format Markdown avec frontmatter par rapport au prompt engineering sur mesure

Conclusion

  • Les agents d’IA pour le code se comportent comme des ingénieurs juniors extrêmement compétents, mais sans instinct pour le travail qui n’apparaît pas dans un diff
  • Des tâches d’ingénierie senior comme expliciter les hypothèses, calibrer la taille des changements, rédiger des spécifications, laisser des preuves ou refuser de merger des changements impossibles à relire ont de fortes chances d’être sautées si l’on n’empêche pas l’agent de les contourner
  • Ce qui devient de plus en plus important, c’est d’encoder cette discipline dans une forme dont l’agent ne peut pas s’extraire par un simple argumentaire
  • Les skills en sont une forme ; leurs éléments clés sont les tableaux anti-rationalisation, la divulgation progressive, le processus plutôt que la prose, la validation comme critère de sortie, et une structure qui rend portables des pratiques Google déjà éprouvées
  • Le dépôt Agent Skills est publié sous licence MIT, et la perspective de scaffolding plus large se prolonge dans Agent Harness Engineering et Long-running Agents

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Avis Hacker News

  • C’est presque de l’huile de serpent. Ça vaut la peine d’être lu et ça a l’air plausible, mais ça reste de l’huile de serpent
    Parce que des modèles façon machine à sous peuvent oublier à tout moment des exigences obligatoires écrites dans AGENTS.md, memory.md ou des dizaines de fichiers Markdown de skills, et c’est en pratique presque garanti
    Ce type d’approche par harnais fait comme si les LLM suivaient les règles de façon stricte et parfaite, et que le seul problème était qu’on n’avait pas écrit assez de règles, ou pas assez clairement. C’est une erreur fondamentale de compréhension de la façon dont fonctionnent les LLM
    Au final, la seule alternative digne de confiance, ou relativement plus digne de confiance, reste la relecture et la supervision humaines, idéalement faites deux fois de suite
    Tout le reste, c’est de l’huile de serpent, et à ce stade on se rend compte que les gains de productivité promis le sont aussi. Parce que lire du code et se construire un modèle mental est bien plus difficile que traduire en code quelque chose dont on a déjà un modèle mental

    • Le terme huile de serpent est un peu excessif. Ces remèdes ne marchent jamais, alors que les choses avec des LLM fonctionnent quand même assez souvent, même si c’est probabiliste
      La lecture de code dépend du code en question, mais comme pour toute autre compétence, ça devient plus facile avec la pratique. C’est très courant dans les situations où l’on lit bien plus de code qu’on n’en écrit, comme lorsqu’on doit travailler sur de grosses bases de code complexes qui existent depuis longtemps
      C’est encore plus facile quand on a déjà un modèle mental du code grâce à la documentation, à l’expérience passée ou à des échanges avec des collègues
      C’est pareil avec les agents. En général, avant même d’écrire le prompt, on connaît déjà bien la structure du code, et si on découpe soigneusement le travail, la revue du code généré devient très facile. C’est comme relire un livre qu’on a déjà lu, et quand quelque chose cloche, ça saute tout de suite aux yeux, donc on attrape la plupart des erreurs très tôt. Dans les deux cas, le gain de vitesse est important
    • Les humains aussi oublient souvent des exigences obligatoires qu’on leur a données, et ils ont eux aussi besoin de revue. Malgré ça, on a réussi à améliorer la fiabilité du travail humain via les processus et la revue, et la plupart des méthodes utilisées dans les harnais viennent justement de l’expérience acquise pour réduire les problèmes humains liés à une transmission peu fiable
    • Tout ce que tu dis est possible, et en théorie je suis d’accord
      Mais ces derniers mois, j’ai utilisé spec-kit, donc ce type d’usage de l’IA, et en pratique c’était incroyablement bon. Je construis de très bonnes choses, et je n’ai pas encore rencontré les problèmes que tu présentes comme des hypothèses. Ils apparaîtront peut-être un jour, donc je reste prudent
      Mais après l’avoir réellement utilisé soi-même pendant un certain temps, on ne peut pas juste balayer ça comme de l’huile de serpent. Je programme depuis plus de 30 ans, et j’ai le sentiment de plutôt bien savoir ce qui marche et ce qui ne marche pas
    • Ça revient à dire qu’une épée +5 est inutile parce qu’elle rate quand on fait un 1. Il faut raisonner en valeur attendue. Si quelqu’un fusionne cinq PR correctes et en jette trois, se focaliser bruyamment sur le fait que l’une d’elles était mauvaise n’a pas grand intérêt pour comparer
    • J’espère que si les gens appellent ces propositions en Markdown des workflows, c’est parce qu’ils ont peur qu’un terme plus structuré devienne obsolète pendant qu’on affine l’approche. Le rythme d’innovation des modèles de base ne restera probablement pas éternellement à ce niveau
      À l’avenir, j’aimerais voir des harnais qui imposent au lieu de demander. Si on dit à un agent de rester en mode planification mais qu’il ne suit pas la procédure prévue, on le tue. Même imparfait, ça devrait valoir mieux que l’approche actuelle avec humain dans la boucle

  • On dit que « les skills sont des fichiers Markdown avec frontmatter injectés dans le contexte de l’agent quand la situation s’y prête », mais c’est le LLM qui décide si c’est bien cette situation
    On dit aussi que c’est « une suite d’étapes que l’agent suit, se terminant par des points de contrôle qui produisent des preuves et des critères d’arrêt clairs », mais c’est encore le LLM qui peut décider s’il va suivre ces étapes ou non

    • Les skills sont souvent appelées de façon impérative par l’utilisateur. Quand ils sont conçus pour être utilisés directement par le LLM, il suffit de l’indiquer quelque part dans le contexte. Par exemple : 
      After implementing the feature, read the testing skill for instructions on how to test.
    • Pour être juste, dans des environnements comme Codex, on peut invoquer directement une skill avec $my-skill, et dans ce cas elle est effectivement injectée dans le contexte. Ensuite, le LLM suit cette skill au même titre qu’il suit le prompt, les instructions ou les autres parties du contexte

  • J’attends avec impatience le jour où tout le monde réalisera qu’il a passé plus d’un an à bricoler avec des agents pour n’obtenir qu’un sentiment de fausse productivité

    • Je comprends un certain scepticisme, et on peut croire pour diverses raisons qu’au fond l’IA est mauvaise. Mais ce ton catégorique m’échappe de plus en plus. Je me demande d’où vient une telle certitude que le développement avec l’IA est un échec
      Ça ne correspond pas du tout à mon expérience réelle. J’aimerais savoir quelle expérience t’a conduit à être aussi sûr d’un effondrement inévitable du coding avec l’IA. Est-ce une conviction philosophique selon laquelle l’IA est moralement mauvaise, ou as-tu vraiment construit des choses avec l’IA, exploré sérieusement le sujet, puis tiré une conclusion forte ?
      J’écris du code tous les jours depuis plus de 30 ans, et c’est mon métier depuis plus de 20 ans. J’ai vu des modes aller et venir, et aussi plusieurs vraies avancées qui ont changé notre façon de travailler. Plus je construis de projets avec l’IA, plus je suis convaincu qu’il s’agit d’un changement durable et fondamental dans la façon de créer des logiciels et d’utiliser les ordinateurs
      J’ai vu l’IA s’améliorer, et j’ai vu ma propre capacité à m’en servir pour finir du vrai travail progresser. Ce travail a déjà été testé sous de vraies charges en production. On peut ne pas aimer ce qui se passe ni la sensation de travailler avec l’IA, mais ça ne signifie pas qu’elle n’apporte pas de valeur réelle aux gens ni qu’elle ne fait pas de vrai travail
    • Ce point de vue m’intrigue. En toute bonne foi, cela repose-t-il sur l’idée que les gens qui utilisent IA/agents/harnais ne livrent pas de fonctionnalités ?
      Chez nous, on est passés à fond sur Claude Code vers septembre, et on a pu suivre les améliorations avec succès. On livre des fonctionnalités utilisées en vraie production. Que ce soit côté infrastructure, logique métier, frontend ou backend
      Je n’ai pas l’impression que les gens perdent autant leur temps. En revanche, je suis d’accord pour dire que la plupart de ces articles racontent n’importe quoi, y compris celui-ci. Mais le développement avec IA se fait déjà dans beaucoup d’entreprises dans le monde
    • C’est comme dire que les gens ont perdu en productivité parce qu’ils ont arrêté les grands livres papier pour bricoler avec ce qu’on appelle une base de données
    • Je travaille sur des projets où l’on mesure les résultats, et il n’y a absolument rien de « faux »
    • Je le traite comme l’automatisation de Minecraft. C’est juste pour le fun et pour passer le temps
      Je ne pense pas que les workflows de type agent en soient encore là, mais les implémentations de skills utilisées manuellement pour travailler côte à côte avec l’IA sont clairement correctes. Dans notre entreprise, on se concentre beaucoup en ce moment sur le sandboxing et les skills sûres
      Je ne pense pas qu’on maîtrise encore vraiment le développement de fonctionnalités, mais les skills de revue et les skills Grafana qu’on a écrites étaient plutôt solides

  • J’ai déjà utilisé des ensembles plus larges de skills d’agent, et j’ai eu l’impression que c’était une perte de temps parce qu’ils essayaient d’en faire trop. Comme avec Vim, il vaut souvent mieux sélectionner des skills dans la communauté que d’installer un pack complet comme si c’était un IDE
    Les skills varient tellement selon les développeurs et les équipes qu’elles sont trop personnelles. Mieux vaut les considérer comme des références pour construire sa propre configuration, plutôt que d’installer en masse celle des autres

    • C’est pareil pour MCP et les system prompts. Beaucoup de gens installent tout sans même comprendre, encombrent le contexte avec des outils dont ils n’ont pas besoin, gaspillent plus de 50 000 tokens, puis se plaignent d’atteindre les limites trop vite et de devoir payer plus de 100 dollars par mois

  • Du point de vue du SEO ou de l’optimisation pour les LLM, j’ai l’impression que la découvrabilité de ces skills risque d’être compliquée si le nom ne change pas : https://agentskills.io/
    Si Addy voit ça, j’aimerais savoir comment il comparerait ça à Superpowers : https://github.com/obra/superpowers

    • J’aimerais bien savoir combien de gens utilisent vraiment superpowers
      J’étais déjà dans le développement d’agents avant superpowers, et j’ai l’impression que plus de 50 % de mon propre processus est désormais couvert par superpowers, ce qui m’inquiète
      Je ne fais plus confiance aux étoiles GitHub. J’aimerais que quelqu’un m’éclaire. Est-ce que superpowers est vraiment adopté maintenant ? Et si ça a vraiment de la valeur, pourquoi Boris n’a-t-il pas encore intégré ce concept ?
    • On dirait qu’ils ont appelé un framework React ReactJS pour concurrencer NextJS
    • Ça ressemble à un pack de skills préfabriquées fourni comme plugin
    • Est-ce que superpowers marche vraiment ? Le fichier principal des skills n’inspire pas spécialement confiance :
      « si tu penses qu’il y a ne serait-ce qu’1 % de chances qu’une skill s’applique à ce que tu es en train de faire, alors tu dois absolument invoquer cette skill »

  • Je ne comprends pas pourquoi tout le monde a l’air si enthousiaste à l’idée de supprimer son propre emploi
    Ce genre de choses, ou n’importe quelles “skills”, ne le feront probablement pas vraiment, mais sur le principe. On dirait une aliénation du travail à grande échelle

    • Ça fait des décennies qu’on automatise de grandes parties d’anciens métiers. Sinon, tout le monde chercherait à faire les choses de la manière la plus inefficace possible pour qu’elles prennent le plus de temps possible, et ce n’est pas une bonne idée
      L’humanité a toujours cherché, aussi loin qu’on puisse remonter, à réduire le travail nécessaire pour produire un certain résultat, et c’est ça la civilisation. Faut-il retourner à l’agriculture manuelle à la houe juste pour maximiser le travail dépensé ? Revenir à l’époque où on allumait les réverbères un par un ?
      Les sociétés qui prennent du retard dans l’automatisation s’appauvrissent puis finissent par mourir, car même les gens qui y naissent partent là où la productivité est plus élevée. On l’a vu en Europe de l’Est, chez les Amish, et dans toutes les sociétés pauvres d’où les gens émigrent. Faire plus avec moins a toujours été quelque chose de passionnant
    • En tant que programmeur informatique, j’ai du mal à comprendre cette idée. Toute ma vie, j’ai fait en sorte que les ordinateurs fassent le travail pour que les humains n’aient plus à le faire. Tout logiciel écrit sert à supprimer le travail de quelqu’un
      Je me demande si tu ressens ça pour toute forme d’automatisation. Il y avait autrefois des administrateurs système à l’ancienne qui voyaient les progrès de l’automatisation de l’infrastructure de cette façon, et qui détestaient voir des scripts et des systèmes remplacer des tâches autrefois faites à la main
      Dans un de mes emplois, notre équipe a construit un système de patching automatique qui exécutait les correctifs sur 30 000 serveurs, retirait et remettait automatiquement les machines en production, et a rendu tout le processus entièrement sans intervention. Avant, il y avait une équipe dédiée qui faisait tourner ce processus manuellement. L’automatisation leur a-t-elle pris leur travail ?
      D’une certaine manière oui, mais il y avait d’autres choses à faire, et maintenant ils peuvent les faire
      C’est justement pour ça que j’aime la programmation, les ordinateurs et la technologie : ils font le travail à notre place. Mon utopie, c’est un monde où les robots font tout le travail pénible pour que les humains puissent faire ce qu’ils veulent. L’IA nous fait avancer d’un pas dans cette direction. Plutôt que d’essayer de préserver artificiellement assez de travail pour que les humains restent occupés à faire des choses qu’ils ne veulent pas faire, j’aimerais qu’on se concentre sur la manière de faire en sorte que les bénéfices des robots qui prennent les emplois profitent au monde entier, et pas seulement aux propriétaires riches
    • En général, les gens qui perdent leur emploi sont ceux qui n’arrivent pas à s’adapter au marché
      En ce moment, on ne voit pas encore clairement dans quelle direction tout cela évolue, donc les gens testent des agents au hasard avec leurs données, cherchent comment stocker et retrouver le contexte, réutilisent des prompts et multiplient les tentatives pour apprivoiser cette technologie
      La plupart de ces choses seront peut-être devenues inutiles dans un an, intégrées en profondeur dans la génération suivante de modèles. Mais suivre cette évolution a toujours fait partie du plaisir de travailler dans ce domaine
    • C’est un instinct de survie. Quand tout le monde autour de toi, y compris ton employeur, répète « utilisez l’IA », il est difficile d’adopter une position contraire ou même de simplement appeler à la prudence. Ce n’est pas tant de l’enthousiasme que la peur de rater le train et de prendre du retard
      Je pense que ça surprendrait un peu les deux camps si des données à long terme montraient qu’en moyenne, les gains de productivité restent limités, et que même avec l’aide des meilleurs modèles actuels, produire un logiciel de qualité exige toujours de l’attention humaine et du soin
      C’est le même travail, sauf qu’on a désormais une perceuse électrique au lieu d’un tournevis. Certaines personnes construiront des maisons qui tiennent des siècles, d’autres non
    • Ceux qui semblent les plus enthousiastes sont souvent ceux qui n’étaient pas de bons développeurs et qui ont soudain eu l’impression d’être propulsés jusqu’à un niveau “normal”. Tous les bons développeurs que je connais ont été plus prudents dans leur adoption

  • J’entends souvent ce discours en ce moment. Les choses qui sont bonnes pour gérer une équipe de développeurs sont aussi bonnes pour gérer des LLM
    De bons cas de test, une documentation claire et concise, du CI/CD, de bonnes pratiques et des documents d’onboarding
    Gérer des LLM ressemble de plus en plus à la gestion d’une équipe humaine

    • Oui. C’est ce que je dis depuis environ un an, et j’ai même utilisé exactement cette anecdote dans des présentations internes
    • De la même façon, les récits de réussite du coding par agents viennent dès le départ d’organisations qui avaient déjà toutes ces choses en place

  • Je me demande en quoi c’est meilleur ou différent de spec-kit. La philosophie a l’air très similaire, et je me demande aussi si les deux peuvent être utilisés ensemble. Ou bien est-ce simplement redondant ?
    https://github.com/github/spec-kit

    • En rien. C’est la même ordure destinée aux développeurs qui veulent se plaindre des licenciements massifs tout en n’ayant aucune intention d’utiliser l’IA avec prudence quand ils écrivent du code

  • J’ai été surpris de voir que certaines skills sont aussi longues, sur plusieurs pages, avec des tableaux, des listes à cocher, des exemples de code, etc.
    Je me demande à quel point c’est courant. Rien qu’avec quelques-unes, on a l’impression que ça remplirait déjà une bonne partie du contexte

    • Si elles sont longues, c’est parce que la plupart de ces skills ont été générées avec Claude Code et Opus, et qu’aucune personne saine d’esprit ne lirait ces fichiers ni ne construirait un modèle mental à partir d’eux. Il y a plusieurs couches d’hypothèses selon lesquelles cela devrait marcher, mais dans la réalité, ça ne marche pas et c’est du gaspillage
      Il y a une expérience amusante à faire. Demandez à un LLM d’écrire quelque chose de vaguement familier. Par exemple, si vous demandez « write a fib », presque tous les LLM répondront avec l’algorithme de la suite de Fibonacci, car ils ont été finement entraînés sur du code, alors que pour un non-programmeur cela pourrait vouloir dire « écris un petit mensonge »
      Autrement dit, il y a compression. Pas besoin d’expliquer en détail ce qu’est la suite de Fibonacci : trois tokens ambigus suffisent à exprimer le résultat
      On voit donc que la longueur du prompt n’est pas le vrai sujet. Ce qui compte, ce sont les bons mots, leur fréquence et leur ordre. Un prompt de deux pages peut produire le même résultat qu’un prompt de deux phrases
    • En parcourant rapidement, au moins quelques-unes m’ont semblé plus proches de system prompts pour des sous-agents à périmètre étroit que de véritables skills. Je suis d’accord pour dire que je n’aurais pas envie d’en utiliser beaucoup dans une session de travail longue
      Jusqu’ici, j’ai surtout eu du succès avec des skills courtes et ciblées. Je les traite comme des morceaux de contexte réutilisables, tout en les gardant petits. Par exemple, quelques paragraphes expliquant comment on utilise Python dans mon projet et comment on exécute les tests unitaires
      J’ai aussi plusieurs petites skills « info » qui ne donnent pas d’instructions à l’agent, mais contiennent juste des éléments de contexte utiles qu’il peut aller chercher si nécessaire
      Trop de skills peut aussi devenir un problème. La liste des noms et descriptions des skills finit de toute façon par entrer dans le contexte à un moment ou un autre
    • Je n’ai encore jamais écrit de skill, donc je ne sais pas à quel point c’est courant. J’ai compté le nombre de mots de quelques exemples, et on était à peu près autour de 2 000 mots. Cinq skills, ça fait environ 10 000 mots
      Même dans un petit contexte LLM de 128k, ça représente environ 10 %, et dans une grande fenêtre de contexte de 1M, c’est à peine visible
    • Par défaut, seul le frontmatter des skills, donc le nom, la description, les déclencheurs, etc., est chargé dans le contexte, donc à moins d’avoir des milliers de skills, ce n’est normalement pas un vrai problème
    • J’ai regardé le nombre de lignes des fichiers de skills dans mon projet : le top 3 était à 805 lignes, 660 lignes et 511 lignes
      Il est possible que je sois trop conservateur là-dessus. Il y a encore beaucoup à explorer

  • « Le travail d’un ingénieur senior est en grande partie invisible dans un diff »
    Agent Skills est la tentative d’Addy d’automatiser aussi cette partie. Santé, Addy :P