Marrant. En tous cas en équipe on commence à expérimenter de bosser sur un même projet en partageant les AGENTS.md et autres règles, et clairement, y compris en utilisant des LLMs différent, ça harmonise énormément le code pondu, ça maintient le process etc.
Je vais suggérer cet ajout.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Mais est ce que c'est efficace ? J'utilise pas de LLMs pour coder en dehors d'essais infructueux 1 fois tout les 6 mois en moyenne, mais j'ai cru comprendre que le respect des instructions était parfois optionnel. (et y a au moins un article qui dit que les agents.md n'ont pas d'effet visible, dans mon souvenir, donc ça pointe en faveur d'un "ça risque de ne pas marcher tout le temps")
Posté par gUI (Mastodon) .
Évalué à 5 (+2/-0).
Dernière modification le 23 septembre 2026 à 09:26.
mais j'ai cru comprendre que le respect des instructions était parfois optionnel
Il l'est de moins en moins. Un truc comme ça, ça marche sans trop de pb (mais c'est évidemment jamais garanti 100% juré-craché). Là où il faut se méfier ce sont les instructions où l'IA a des difficultés à arriver à ses fins (par exemple : un code qui fait passer 100% des tests). Là ça peut tricher (modifier les tests par exemple) parce que "arriver à ses fins" apparaît plus prioritaire que respecter les consignes à la lettre.
D'où la nécessité de ne pas lui laisser faire n'importe quoi via les outils autour (rappelons qu'un LLM pisse seulement du texte et n'exécute rien).
Une façon aussi de limiter cet effet c'est de séparer les agents. Si t'as un agent qui passe derrière où ses fins sont "refuser toute contribution où les instructions n'ont pas été respectées" ça ajoutera une couche de confiance dans le bouzing…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Pour le coup vérifier si la sortie a viré le canari, tu peux utiliser un script avant soumission des commits, c'est plus efficace que de lancer un agent de relecture.
yep. Je constate un espèce de délire en ce moment sur les LLM ou le LLM est censé résoudre tous les problèmes. Par exemple, dans notre outil de ticketing, les chefs veulent absolument ajouter une couche LLM pour trouver les tickets qui sont sans réponse depuis plus de 3 semaines (côté dev ou côté client).
J'ai montré la requête SQL qui te sort ça nickel (bah on a des champs date, ça sert à ça hein). Non, il faut coder un truc via LLM qui va aller lire les dates, faire un calcul et écrire une relance type genre "le ticket n'a pas avancé depuis 3 semaines, tu te met à bosser ou on s'énerve un peu"?
L'usage des LLM sert à rien, le premier test s'est montré calamiteux (un LLM a du mal à compter et à calculer des écarts de date), mais c'est pas grave, il faut mettre plus d'IA (donc une 2e IA qui relit les messages sortis par la première).
Je comprends pas. Idem le coup de git, on a des hooks post- pre- commit, ça sert précisément à ça.
Posté par gUI (Mastodon) .
Évalué à 7 (+4/-0).
Dernière modification le 23 septembre 2026 à 10:37.
Par exemple, dans notre outil de ticketing, les chefs veulent absolument ajouter une couche LLM pour trouver les tickets qui sont sans réponse depuis plus de 3 semaines (côté dev ou côté client).
Évidemment aucun intérêt, d'ailleurs ton outils de ticket doit même pouvoir les colorier en rouge tout seul ! Non l'IA dans ce cas ce serait pas exemple pour évaluer automatiquement (et au doigt mouillé) :
- la charge estimé
- l'urgence
- le rapport avec les modifications récentes
- que sais-je…
Mais pas un calcul en effet. Le seul moyen de faire faire des bons calculs à une IA c'est… de lui filer un outil de calcul (MCP). Donc un script python quoi.
on a des hooks post- pre- commit, ça sert précisément à ça.
oui mais non, là on veut que seules les IA ajoutent ce texte, et qu'ensuite un humain l'enlève.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Posté par octane .
Évalué à 2 (+1/-1).
Dernière modification le 23 septembre 2026 à 11:56.
Évidemment aucun intérêt, d'ailleurs ton outils de ticket doit même pouvoir les colorier en rouge tout seul !
Merci de ton soutien. L'ennui, c'est que mon chef veut que ce soit l'IA qui le fasse.
oui mais non, là on veut que seules les IA ajoutent ce texte, et qu'ensuite un humain l'enlève.
#!/bin/shfor f in $(git diff --cached --name-only -- '*.c''*.h');do
sed -i.bak 's/^/\/\* ceci est ajouté par le LLM \*\/ /'"$f"
rm -f "$f.bak"
git add "$f"done
dans un hook pre-commit, ça doit faire le taff. Et hop.
L'ennui, c'est que mon chef veut que ce soit l'IA qui le fasse.
Laisse moi juste le temps de monter une boite de consulting, et on peut ensuite s'arranger pour lui donner un script qui fait un appel à un LLM et qui ensuite exécute ton code. Avec assez d'esbrouffe, ça passe (65/35 pour moi sur les bénefs, je peux pas faire mieux).
Ça n'est pas l'intérêt à mon avis. Pour un projet libre publique à forte visibilité, ça doit permettre de filtrer les PR faites le plus à l'arrache. Pas servir de preuve de travail humaine
Merci de ton soutien. L'ennui, c'est que mon chef veut que ce soit l'IA qui le fasse.
Sûrement parce qu'il n'a pas encore reçu la facture des tokens consommés ? J'ai récemment donné une petite conférence pour expliquer exactement ça à des professionnels. Les cas où l'IA ne sert à rien et fera moins bien qu'un simple algo pour beaucoup plus cher. Sinon tu gardes ta requêtes SQL pour le résultat et tu concatènes avec une phrase générée par pipotron/IA pour donner l'impression que ça varie donc ça vient du LLM
# Lien vers le patch
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 22 septembre 2026 à 18:13.
https://github.com/systemd/systemd/commit/73aa952
Marrant. En tous cas en équipe on commence à expérimenter de bosser sur un même projet en partageant les AGENTS.md et autres règles, et clairement, y compris en utilisant des LLMs différent, ça harmonise énormément le code pondu, ça maintient le process etc.
Je vais suggérer cet ajout.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Lien vers le patch
Posté par barmic 🦦 . Évalué à 3 (+1/-0). Dernière modification le 23 septembre 2026 à 06:17.
Ça n'est utile qu, avec les contributions extérieures. Tu as vite fait de voir quelqu'un créer un hook pour virer le canary.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Lien vers le patch
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Je pars du principe que les collègues ne sont pas malveillants :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Lien vers le patch
Posté par Misc (site web personnel) . Évalué à 6 (+3/-0).
Mais est ce que c'est efficace ? J'utilise pas de LLMs pour coder en dehors d'essais infructueux 1 fois tout les 6 mois en moyenne, mais j'ai cru comprendre que le respect des instructions était parfois optionnel. (et y a au moins un article qui dit que les agents.md n'ont pas d'effet visible, dans mon souvenir, donc ça pointe en faveur d'un "ça risque de ne pas marcher tout le temps")
[^] # Re: Lien vers le patch
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 23 septembre 2026 à 09:26.
Il l'est de moins en moins. Un truc comme ça, ça marche sans trop de pb (mais c'est évidemment jamais garanti 100% juré-craché). Là où il faut se méfier ce sont les instructions où l'IA a des difficultés à arriver à ses fins (par exemple : un code qui fait passer 100% des tests). Là ça peut tricher (modifier les tests par exemple) parce que "arriver à ses fins" apparaît plus prioritaire que respecter les consignes à la lettre.
D'où la nécessité de ne pas lui laisser faire n'importe quoi via les outils autour (rappelons qu'un LLM pisse seulement du texte et n'exécute rien).
Une façon aussi de limiter cet effet c'est de séparer les agents. Si t'as un agent qui passe derrière où ses fins sont "refuser toute contribution où les instructions n'ont pas été respectées" ça ajoutera une couche de confiance dans le bouzing…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Lien vers le patch
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
Pour le coup vérifier si la sortie a viré le canari, tu peux utiliser un script avant soumission des commits, c'est plus efficace que de lancer un agent de relecture.
[^] # Re: Lien vers le patch
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 23 septembre 2026 à 09:58.
Oui bien sûr je parlais généralement de la façon de bosser avec un LLM pour le faire obéir le plus possible aux instructions.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Lien vers le patch
Posté par octane . Évalué à 8 (+6/-0).
yep. Je constate un espèce de délire en ce moment sur les LLM ou le LLM est censé résoudre tous les problèmes. Par exemple, dans notre outil de ticketing, les chefs veulent absolument ajouter une couche LLM pour trouver les tickets qui sont sans réponse depuis plus de 3 semaines (côté dev ou côté client).
J'ai montré la requête SQL qui te sort ça nickel (bah on a des champs date, ça sert à ça hein). Non, il faut coder un truc via LLM qui va aller lire les dates, faire un calcul et écrire une relance type genre "le ticket n'a pas avancé depuis 3 semaines, tu te met à bosser ou on s'énerve un peu"?
L'usage des LLM sert à rien, le premier test s'est montré calamiteux (un LLM a du mal à compter et à calculer des écarts de date), mais c'est pas grave, il faut mettre plus d'IA (donc une 2e IA qui relit les messages sortis par la première).
Je comprends pas. Idem le coup de git, on a des hooks post- pre- commit, ça sert précisément à ça.
[^] # Re: Lien vers le patch
Posté par gUI (Mastodon) . Évalué à 7 (+4/-0). Dernière modification le 23 septembre 2026 à 10:37.
Évidemment aucun intérêt, d'ailleurs ton outils de ticket doit même pouvoir les colorier en rouge tout seul ! Non l'IA dans ce cas ce serait pas exemple pour évaluer automatiquement (et au doigt mouillé) :
- la charge estimé
- l'urgence
- le rapport avec les modifications récentes
- que sais-je…
Mais pas un calcul en effet. Le seul moyen de faire faire des bons calculs à une IA c'est… de lui filer un outil de calcul (MCP). Donc un script python quoi.
oui mais non, là on veut que seules les IA ajoutent ce texte, et qu'ensuite un humain l'enlève.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Lien vers le patch
Posté par octane . Évalué à 2 (+1/-1). Dernière modification le 23 septembre 2026 à 11:56.
Merci de ton soutien. L'ennui, c'est que mon chef veut que ce soit l'IA qui le fasse.
dans un hook pre-commit, ça doit faire le taff. Et hop.
[^] # Re: Lien vers le patch
Posté par Misc (site web personnel) . Évalué à 9 (+6/-0).
Laisse moi juste le temps de monter une boite de consulting, et on peut ensuite s'arranger pour lui donner un script qui fait un appel à un LLM et qui ensuite exécute ton code. Avec assez d'esbrouffe, ça passe (65/35 pour moi sur les bénefs, je peux pas faire mieux).
[^] # Re: Lien vers le patch
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0).
t'as pas lu, ça marchera pas ton truc, c'est le README qui est modifié ;)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Lien vers le patch
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Ça n'est pas l'intérêt à mon avis. Pour un projet libre publique à forte visibilité, ça doit permettre de filtrer les PR faites le plus à l'arrache. Pas servir de preuve de travail humaine
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Lien vers le patch
Posté par Faya . Évalué à 4 (+2/-0).
Sûrement parce qu'il n'a pas encore reçu la facture des tokens consommés ? J'ai récemment donné une petite conférence pour expliquer exactement ça à des professionnels. Les cas où l'IA ne sert à rien et fera moins bien qu'un simple algo pour beaucoup plus cher. Sinon tu gardes ta requêtes SQL pour le résultat et tu concatènes avec une phrase générée par pipotron/IA pour donner l'impression que ça varie donc ça vient du LLM
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.