Ces temps-ci, les agents de codage peuvent compenser nos lacunes, donc je pense que si l’on connaît clairement ses points forts et qu’on sait les exploiter, la barrière à l’entrée peut s’abaisser.
Moi aussi, la documentation a toujours été mon point faible, mais en en déléguant une partie à un agent de codage, la charge a diminué, et le fait de relire ces documents rédigés m’a aussi permis de développer un meilleur regard sur la documentation.
Merci de m’avoir lu ! Avant, il y avait beaucoup de choses dont il fallait s’occuper soi-même, comme la documentation, les cas de test, la validation, etc. Maintenant qu’on peut faire pas mal de choses avec des agents de coding IA, j’ai l’impression que la gestion d’un projet open source est devenue bien moins difficile qu’avant !
Oui, si on ne considère que l’historique du presse-papiers, il y a pas mal de recoupements. Mais Raycast ne fait pas que le presse-papiers, il a aussi beaucoup d’autres fonctions, donc je le trouvais un peu trop chargé.
Voici les points auxquels j’ai fait attention.
D’abord, que ce soit léger et que cela ne gère que l’historique du presse-papiers ; pour l’instant, ça fait environ 2 Mo.
Ensuite, on peut modifier le contenu enregistré dans la vue détaillée avant de le réutiliser. Je trouvais ça pratique pour relire plusieurs prompts et les retoucher un peu à l’avance.
J’ai aussi porté une attention particulière à la recherche et au rangement par dossiers. En travaillant, j’ai essayé de faciliter la gestion des informations utiles, qu’elles soient ponctuelles ou pénibles à retrouver plus tard.
La recherche fonctionne par contenu, tags, titre, etc.
Plus tard, j’aimerais permettre d’ajouter directement des fonctions ou des agencements via des plugins, mais ce n’est pas encore vraiment défini.
Je pense aussi que Raycast est une bonne application, et j’aimerais faire en sorte que le choix puisse simplement relever des préférences de chacun.
Dans ce genre d’outil, le plus difficile n’est pas tant d’accumuler que de jeter, et le fait que le garden soit séparé dans un cycle de vie distinct saute aux yeux.
Le contexte donné à l’agent, quand il vieillit, n’est pas seulement inutile, il devient nuisible. Un humain peut lire un document et se dire « ça ressemble à une vieille histoire », mais un modèle n’a pas cette intuition, donc il prend tel quel une contrainte supposée immuable, vraie il y a trois mois, comme si elle l’était encore aujourd’hui. Le code, au moins, finit par casser à la compilation, mais un wiki se trompe en silence.
Du coup, je me demande si chaque page indique à quelle date elle fait référence et sur quoi elle s’appuie. Le choix de les stocker en Markdown dans le dépôt et de les faire relire via Git me semble juste sur ce point, mais ce qui reste dans le diff, c’est le moment où le document a changé, pas celui où son contenu reste encore valable.
Avec 1 700 entrées, parler de performance n’a pratiquement pas de sens à cette échelle : que vous traitiez directement côté front ou que vous mettiez un backend, les deux s’afficheront instantanément. Le bon critère de décision n’est donc pas la vitesse, mais plutôt le fait de devoir, ou non, réécrire la logique Python existante.
Sur ce critère, Streamlit est le meilleur choix. Vous pouvez importer telle quelle la logique de matching, et l’interface se limite à 5 selectbox plus un tableau de résultats, donc pas besoin d’écrire de code front. En le déployant sur Streamlit Community Cloud, vous obtenez gratuitement un lien partageable, et si vous faites lire le JSON à l’exécution, il suffit de remplacer le fichier pour refléter les données à jour.
Le HTML statique est plus simple à déployer, mais il faut porter la logique Python en JS ; si le calcul de score est un tant soit peu complexe, ce portage peut facilement prendre plusieurs jours. Si l’objectif est de montrer quelque chose qui fonctionne cette semaine, il vaut mieux éviter ce risque.
Un point toutefois : Streamlit ressemble malgré tout davantage à un outil qu’à un produit. Si c’est une démo destinée à des décideurs internes et que le but est de vérifier que « quand on saisit, ça s’affiche vraiment », ce n’est pas un problème ; pour une démo à des clients externes, il faut en tenir compte.
Oh… Dans les posts Show GN, j’ai toujours eu envie de voir ce genre d’insights en plus du simple « j’ai créé un truc », donc lire un article comme ça, ça m’enthousiasme haha
C’est dans la psychologie humaine de préférer confier le tout à une seule personne qui se débrouillera pour tout bien gérer, plutôt que de chercher un expert pour chaque cas et de ne lui confier que son périmètre de travail.
Pour les LLM aussi, la fonction de récompense ne finit-elle pas forcément par être conçue de façon à accepter tout ce qu’on leur lance, quel que soit le sujet ?
Même s’il s’agit d’un benchmark public, c’est la première fois que je vois des chiffres aussi précis. Merci.
Le ratio 159 / 76 / 3 197 m’a particulièrement marqué. Le fait qu’il y ait une écrasante majorité de cas impossibles à évaluer (pas d’ID) signifie qu’au final, la plupart des doublons se situent dans une zone où le suivi lui-même est impossible, et cela m’a rappelé qu’il ne faut pas se rassurer en se disant simplement : « il suffit d’avoir des logs d’audit ».
L’orientation consistant à prioriser la création (POST) correspond exactement à notre conception. C’est précisément pour cela que nous voulions attacher d’abord une clé d’idempotence à l’événement de création dans notre hash chain.
Je vais appliquer immédiatement la proposition d’un message ID pour l’e-mail. Rien qu’en ajoutant « ID d’entité obligatoire dans la réponse » à la spécification de nos outils internes, la vérifiabilité des logs d’audit change déjà. Et si on utilise l’ID comme ancre dans la hash chain, on peut vérifier les doublons par simple calcul.
Avez-vous pu identifier sur quels types d’outils se concentraient les 3 197 cas « sans ID » ? En dehors de l’e-mail, je me demande combien d’outils se contentent de renvoyer « succès/échec ».
Nous sommes actuellement en phase d’optimisation ; si tout est finalisé d’ici la fin de la semaine, vous devriez pouvoir consulter le site de manière plus propre :)
Je suis moi aussi assez content de tomber sur quelqu’un qui construit quelque chose de similaire !
Même avant la grande époque de Claude, j’avais déjà investi pas mal de temps dans Rust, en créant des API et des CLI en Rust.
J’ai commencé assez récemment à me dire qu’il fallait remplacer tmux ; je ne l’ai donc remplacé lui-même que depuis peu, mais j’avais déjà créé un multiplexeur et, dès le deuxième jour, j’avais fortement réduit mon usage de tmux !
Ici, au-delà du niveau de finition, je pense aussi que le fait d’avoir une solution de repli vers d’autres outils que le mien devenait au contraire une échappatoire, ce qui faisait que je ne m’investissais pas assez dans le développement.
Si cela a pris quatre mois, c’est sans doute aussi parce que, comme vous l’avez dit, il m’a fallu longtemps pour rendre extensibles à d’autres des fonctionnalités très liées à mes préférences, et qu’il m’a aussi fallu pas mal de courage pour décider de rendre cela public.
Et alors que des programmes comme orca bénéficient d’un soutien d’entreprise, je suis au contraire plutôt positif concernant la motivation d’un projet mené à titre personnel.
Bien sûr, il n’y a guère de motivation plus forte qu’une contrainte financière, mais de mon côté, comme j’ai aligné tout mon workflow sur les outils que j’utilise, si je veux travailler tout de suite, je dois améliorer cet outil ; c’est pourquoi je découpe autant que possible mon temps personnel pour l’investir dans l’amélioration de ces outils.
Évidemment, le problème est que tout s’arrête au moment où ma motivation baisse, mais pour éviter cette situation, j’ai délibérément optimisé mon workflow autour de mes propres outils afin de m’en prémunir !
Personnellement, j’ai même le sentiment qu’à l’heure actuelle, par rapport aux outils concurrents, ce qui nous manque n’est pas technique mais relève surtout du marketing ; le fait de l’avoir rendu public pour recueillir des retours a donc aussi beaucoup compté.
Le rendu GPU n’a pas été fait tant pour le support de Windows que pour le défi technique et l’optimisation des programmes qui occupent tout l’écran du terminal.
Personnellement, cela fait longtemps que je n’utilise plus Windows pour le développement, donc je n’avais pas vraiment réfléchi en profondeur au support de cet OS ; mais maintenant que les bases sont assez solides, je me dis que cela vaut peut-être le coup d’essayer.
Mon objectif, c’est simplement qu’un seul copad suffise pour tout mon développement, et c’est pour cela que j’ai aussi mis en place un système de plugins !
Donc, pour les fonctionnalités qui nécessitent une interface graphique, j’essaie autant que possible de les implémenter directement dans copad.
Il y a une différence assez importante dans le mode de rendu, mais en réalité ce n’est pas quelque chose que l’utilisateur final ressent fortement, donc je suis un peu gêné d’entrer dans les détails. Comme vous le dites, avec la baisse des coûts de production, j’ai l’impression qu’on est dans un monde où le meilleur outil est simplement celui qui vous convient le mieux..!
Je n’ai pas encore pu le tester en production. Tous ces chiffres proviennent de traces de benchmarks publics ; il me semble donc préférable de commencer par préciser cette limite.
Cela dit, il y a une observation qui peut servir de référence pour la conception d’une clé d’idempotence.
Pour essayer de distinguer « deux appels » de « deux exécutions », j’ai comparé les ID d’entités présents dans les réponses. Quand le même appel est effectué deux fois avec les mêmes arguments, si l’ID de réponse est différent, cela signifie que deux objets ont réellement été créés ; s’il est identique, c’est que l’API a fait la déduplication elle-même.
D’après le benchmark Toolathlon, parmi les appels dupliqués à des outils modifiant l’état :
ID différents (création réelle en doublon) : 159 cas
ID identiques (déduplication par l’API) : 76 cas
Absence d’ID, donc impossible à déterminer : 3 197 cas
Une structure s’en dégage. Les 159 cas avec des ID différents concernaient tous des outils de type création (création de document, création de feuille de calcul, upload de fichier, création de quiz). À l’inverse, dans les outils de type mise à jour (patch, update, enroll), il n’y avait aucun cas avec des ID différents : ils pointaient vers la même cible et ne créaient donc rien de nouveau.
Autrement dit, si vous ajoutez une clé d’idempotence, la priorité devrait probablement être du côté des créations (POST). Pour les mises à jour, beaucoup de cas semblaient déjà naturellement idempotents.
Et c’est là que le problème des e-mails évoqué tout à l’heure revient. L’envoi d’e-mail ne renvoyait qu’une chaîne « succès », ce qui rendait la comparaison d’ID impossible. Même avec une clé d’idempotence, il n’y a aucun moyen de vérifier, à partir des seules traces, qu’elle a effectivement fonctionné. Si vous concevez un outil interne, le simple fait de renvoyer un message ID dans le résultat d’envoi permettrait une vérification dans les journaux d’audit. Cela devrait aussi bien s’accorder avec l’approche par hash chain que vous mentionnez.
Pour rappeler encore une fois la limite : tous les chiffres ci-dessus proviennent de traces de benchmark, donc on ne sait pas si les proportions seraient les mêmes dans un environnement de production réel. Si jamais vous avez l’occasion de faire tourner des traces, je serais curieux de voir en quoi les résultats diffèrent.
Il existe numba, qui repose sur une approche de compilation JIT avec une idée similaire, mais celui-ci donne l’impression d’avoir une couverture plus large.
Donc, le mieux serait de proposer des LLM fermés sur le marché au prix le plus bas possible. Si l’accès à une intelligence très performante est élevé, l’incitation à développer des modèles open weight diminuera naturellement, et le leadership technologique pourra aussi rester entre les mains d’institutions classiques. Mais au final, Anthropic est justement le fournisseur le plus exclusif du marché, non ?
Ces temps-ci, les agents de codage peuvent compenser nos lacunes, donc je pense que si l’on connaît clairement ses points forts et qu’on sait les exploiter, la barrière à l’entrée peut s’abaisser.
Moi aussi, la documentation a toujours été mon point faible, mais en en déléguant une partie à un agent de codage, la charge a diminué, et le fait de relire ces documents rédigés m’a aussi permis de développer un meilleur regard sur la documentation.
Merci de m’avoir lu ! Avant, il y avait beaucoup de choses dont il fallait s’occuper soi-même, comme la documentation, les cas de test, la validation, etc. Maintenant qu’on peut faire pas mal de choses avec des agents de coding IA, j’ai l’impression que la gestion d’un projet open source est devenue bien moins difficile qu’avant !
@xguru Il me semble que le lien est incorrect~
Oui, si on ne considère que l’historique du presse-papiers, il y a pas mal de recoupements. Mais Raycast ne fait pas que le presse-papiers, il a aussi beaucoup d’autres fonctions, donc je le trouvais un peu trop chargé.
Voici les points auxquels j’ai fait attention.
D’abord, que ce soit léger et que cela ne gère que l’historique du presse-papiers ; pour l’instant, ça fait environ 2 Mo.
Ensuite, on peut modifier le contenu enregistré dans la vue détaillée avant de le réutiliser. Je trouvais ça pratique pour relire plusieurs prompts et les retoucher un peu à l’avance.
J’ai aussi porté une attention particulière à la recherche et au rangement par dossiers. En travaillant, j’ai essayé de faciliter la gestion des informations utiles, qu’elles soient ponctuelles ou pénibles à retrouver plus tard.
La recherche fonctionne par contenu, tags, titre, etc.
Plus tard, j’aimerais permettre d’ajouter directement des fonctions ou des agencements via des plugins, mais ce n’est pas encore vraiment défini.
Je pense aussi que Raycast est une bonne application, et j’aimerais faire en sorte que le choix puisse simplement relever des préférences de chacun.
Merci pour votre avis.
Dans ce genre d’outil, le plus difficile n’est pas tant d’accumuler que de jeter, et le fait que le
gardensoit séparé dans un cycle de vie distinct saute aux yeux.Le contexte donné à l’agent, quand il vieillit, n’est pas seulement inutile, il devient nuisible. Un humain peut lire un document et se dire « ça ressemble à une vieille histoire », mais un modèle n’a pas cette intuition, donc il prend tel quel une contrainte supposée immuable, vraie il y a trois mois, comme si elle l’était encore aujourd’hui. Le code, au moins, finit par casser à la compilation, mais un wiki se trompe en silence.
Du coup, je me demande si chaque page indique à quelle date elle fait référence et sur quoi elle s’appuie. Le choix de les stocker en Markdown dans le dépôt et de les faire relire via Git me semble juste sur ce point, mais ce qui reste dans le diff, c’est le moment où le document a changé, pas celui où son contenu reste encore valable.
Avec 1 700 entrées, parler de performance n’a pratiquement pas de sens à cette échelle : que vous traitiez directement côté front ou que vous mettiez un backend, les deux s’afficheront instantanément. Le bon critère de décision n’est donc pas la vitesse, mais plutôt le fait de devoir, ou non, réécrire la logique Python existante.
Sur ce critère, Streamlit est le meilleur choix. Vous pouvez importer telle quelle la logique de matching, et l’interface se limite à 5
selectboxplus un tableau de résultats, donc pas besoin d’écrire de code front. En le déployant sur Streamlit Community Cloud, vous obtenez gratuitement un lien partageable, et si vous faites lire le JSON à l’exécution, il suffit de remplacer le fichier pour refléter les données à jour.Le HTML statique est plus simple à déployer, mais il faut porter la logique Python en JS ; si le calcul de score est un tant soit peu complexe, ce portage peut facilement prendre plusieurs jours. Si l’objectif est de montrer quelque chose qui fonctionne cette semaine, il vaut mieux éviter ce risque.
Un point toutefois : Streamlit ressemble malgré tout davantage à un outil qu’à un produit. Si c’est une démo destinée à des décideurs internes et que le but est de vérifier que « quand on saisit, ça s’affiche vraiment », ce n’est pas un problème ; pour une démo à des clients externes, il faut en tenir compte.
Il semble prendre en charge presque toutes les fonctionnalités présentes dans Raycast ; quelles sont les différences, le cas échéant ?
Oh… Dans les posts Show GN, j’ai toujours eu envie de voir ce genre d’insights en plus du simple « j’ai créé un truc », donc lire un article comme ça, ça m’enthousiasme haha
C’est dans la psychologie humaine de préférer confier le tout à une seule personne qui se débrouillera pour tout bien gérer, plutôt que de chercher un expert pour chaque cas et de ne lui confier que son périmètre de travail.
Pour les LLM aussi, la fonction de récompense ne finit-elle pas forcément par être conçue de façon à accepter tout ce qu’on leur lance, quel que soit le sujet ?
Même s’il s’agit d’un benchmark public, c’est la première fois que je vois des chiffres aussi précis. Merci.
Le ratio 159 / 76 / 3 197 m’a particulièrement marqué. Le fait qu’il y ait une écrasante majorité de cas impossibles à évaluer (pas d’ID) signifie qu’au final, la plupart des doublons se situent dans une zone où le suivi lui-même est impossible, et cela m’a rappelé qu’il ne faut pas se rassurer en se disant simplement : « il suffit d’avoir des logs d’audit ».
L’orientation consistant à prioriser la création (POST) correspond exactement à notre conception. C’est précisément pour cela que nous voulions attacher d’abord une clé d’idempotence à l’événement de création dans notre hash chain.
Je vais appliquer immédiatement la proposition d’un message ID pour l’e-mail. Rien qu’en ajoutant « ID d’entité obligatoire dans la réponse » à la spécification de nos outils internes, la vérifiabilité des logs d’audit change déjà. Et si on utilise l’ID comme ancre dans la hash chain, on peut vérifier les doublons par simple calcul.
Avez-vous pu identifier sur quels types d’outils se concentraient les 3 197 cas « sans ID » ? En dehors de l’e-mail, je me demande combien d’outils se contentent de renvoyer « succès/échec ».
Nous sommes actuellement en phase d’optimisation ; si tout est finalisé d’ici la fin de la semaine, vous devriez pouvoir consulter le site de manière plus propre :)
Vous avez déjà ajouté la fonctionnalité de passage au coréen :)
Merci beaucoup
Je suis moi aussi assez content de tomber sur quelqu’un qui construit quelque chose de similaire !
Même avant la grande époque de Claude, j’avais déjà investi pas mal de temps dans Rust, en créant des API et des CLI en Rust.
J’ai commencé assez récemment à me dire qu’il fallait remplacer
tmux; je ne l’ai donc remplacé lui-même que depuis peu, mais j’avais déjà créé un multiplexeur et, dès le deuxième jour, j’avais fortement réduit mon usage detmux!Ici, au-delà du niveau de finition, je pense aussi que le fait d’avoir une solution de repli vers d’autres outils que le mien devenait au contraire une échappatoire, ce qui faisait que je ne m’investissais pas assez dans le développement.
Si cela a pris quatre mois, c’est sans doute aussi parce que, comme vous l’avez dit, il m’a fallu longtemps pour rendre extensibles à d’autres des fonctionnalités très liées à mes préférences, et qu’il m’a aussi fallu pas mal de courage pour décider de rendre cela public.
Et alors que des programmes comme orca bénéficient d’un soutien d’entreprise, je suis au contraire plutôt positif concernant la motivation d’un projet mené à titre personnel.
Bien sûr, il n’y a guère de motivation plus forte qu’une contrainte financière, mais de mon côté, comme j’ai aligné tout mon workflow sur les outils que j’utilise, si je veux travailler tout de suite, je dois améliorer cet outil ; c’est pourquoi je découpe autant que possible mon temps personnel pour l’investir dans l’amélioration de ces outils.
Évidemment, le problème est que tout s’arrête au moment où ma motivation baisse, mais pour éviter cette situation, j’ai délibérément optimisé mon workflow autour de mes propres outils afin de m’en prémunir !
Personnellement, j’ai même le sentiment qu’à l’heure actuelle, par rapport aux outils concurrents, ce qui nous manque n’est pas technique mais relève surtout du marketing ; le fait de l’avoir rendu public pour recueillir des retours a donc aussi beaucoup compté.
Le rendu GPU n’a pas été fait tant pour le support de Windows que pour le défi technique et l’optimisation des programmes qui occupent tout l’écran du terminal.
Personnellement, cela fait longtemps que je n’utilise plus Windows pour le développement, donc je n’avais pas vraiment réfléchi en profondeur au support de cet OS ; mais maintenant que les bases sont assez solides, je me dis que cela vaut peut-être le coup d’essayer.
Mon objectif, c’est simplement qu’un seul copad suffise pour tout mon développement, et c’est pour cela que j’ai aussi mis en place un système de plugins !
Donc, pour les fonctionnalités qui nécessitent une interface graphique, j’essaie autant que possible de les implémenter directement dans copad.
Il y a une différence assez importante dans le mode de rendu, mais en réalité ce n’est pas quelque chose que l’utilisateur final ressent fortement, donc je suis un peu gêné d’entrer dans les détails. Comme vous le dites, avec la baisse des coûts de production, j’ai l’impression qu’on est dans un monde où le meilleur outil est simplement celui qui vous convient le mieux..!
Samsung, qui collectait les dossiers de consultation internes dans des dossiers disciplinaires RH, reste décidément une entreprise leader mondiale.
Je n’ai pas encore pu le tester en production. Tous ces chiffres proviennent de traces de benchmarks publics ; il me semble donc préférable de commencer par préciser cette limite.
Cela dit, il y a une observation qui peut servir de référence pour la conception d’une clé d’idempotence.
Pour essayer de distinguer « deux appels » de « deux exécutions », j’ai comparé les ID d’entités présents dans les réponses. Quand le même appel est effectué deux fois avec les mêmes arguments, si l’ID de réponse est différent, cela signifie que deux objets ont réellement été créés ; s’il est identique, c’est que l’API a fait la déduplication elle-même.
D’après le benchmark Toolathlon, parmi les appels dupliqués à des outils modifiant l’état :
ID différents (création réelle en doublon) : 159 cas
ID identiques (déduplication par l’API) : 76 cas
Absence d’ID, donc impossible à déterminer : 3 197 cas
Une structure s’en dégage. Les 159 cas avec des ID différents concernaient tous des outils de type création (création de document, création de feuille de calcul, upload de fichier, création de quiz). À l’inverse, dans les outils de type mise à jour (
patch,update,enroll), il n’y avait aucun cas avec des ID différents : ils pointaient vers la même cible et ne créaient donc rien de nouveau.Autrement dit, si vous ajoutez une clé d’idempotence, la priorité devrait probablement être du côté des créations (
POST). Pour les mises à jour, beaucoup de cas semblaient déjà naturellement idempotents.Et c’est là que le problème des e-mails évoqué tout à l’heure revient. L’envoi d’e-mail ne renvoyait qu’une chaîne « succès », ce qui rendait la comparaison d’ID impossible. Même avec une clé d’idempotence, il n’y a aucun moyen de vérifier, à partir des seules traces, qu’elle a effectivement fonctionné. Si vous concevez un outil interne, le simple fait de renvoyer un message ID dans le résultat d’envoi permettrait une vérification dans les journaux d’audit. Cela devrait aussi bien s’accorder avec l’approche par hash chain que vous mentionnez.
Pour rappeler encore une fois la limite : tous les chiffres ci-dessus proviennent de traces de benchmark, donc on ne sait pas si les proportions seraient les mêmes dans un environnement de production réel. Si jamais vous avez l’occasion de faire tourner des traces, je serais curieux de voir en quoi les résultats diffèrent.
On dirait un panier pour stocker des captures d’écran.
Il existe numba, qui repose sur une approche de compilation JIT avec une idée similaire, mais celui-ci donne l’impression d’avoir une couverture plus large.
S’ils sortaient ne serait-ce qu’un modèle du genre GPT OSS 120B, ça paraîtrait déjà un peu plus convaincant, mais bon.
Donc, le mieux serait de proposer des LLM fermés sur le marché au prix le plus bas possible. Si l’accès à une intelligence très performante est élevé, l’incitation à développer des modèles open weight diminuera naturellement, et le leadership technologique pourra aussi rester entre les mains d’institutions classiques. Mais au final, Anthropic est justement le fournisseur le plus exclusif du marché, non ?