Je crois que l'IA est plutôt douée pour les tâches de niveau moyen
En fait, par la nature du fonctionnement des modèles, les LLMs sont efficaces pour les problèmes déjà résolus plusieurs fois ailleurs.
J'ai un programme en rust qui me file un ics pour ce que j'appelle la "meeting chaos period", ce moment de l'année où les réunions bougent dans mon calendrier à cause de la date de changement d'heure qui différe entre l'Europe (ou je suis) et les USA (ou mes collègues sont). Quand je fait un meeting, il bouge quand je bouge, quand c'est mon chef en Californie, ça bouge quand il bouge. Du coup, y a des conflits de partout. Par curiosité, j'ai choisi utilisé Crush en branchant le logiciel sur Gemini de Google il y a ~8 mois, et j'ai demandé via l'interface de faire une revue de code.
Le modèle a correctement noté que j'ai mal écrit une balise, que je devais mettre des tests parce que j'ai laissé ça en "TODO". J'ai laissé le modèle écrire des tests, mais j'ai du les refaire de 0 car relativement non idiomatique. Puis j'ai eu comme remarque que je pouvais utiliser une constante, mais le code généré a mis un clone() gratuit que j'ai du retirer. Le modèle a aussi correctement remonté que mes tests n'étaient pas suffisant, vu que j'avais mis un commentaire sur le fait que ça ne soit pas forcément 1h de décalage (et en effet, il y a parfois 2h et parfois 30 minutes). Du coup, j'ai continué à chercher tout les edges cases possibles, et c'est pour ça que j'ai 2 fois plus de tests que de code sur le fichier principal.
J'ai aussi eu comme suggestion d'ajouter ce patch:
--- a/src/timezone_pair.rs
+++ b/src/timezone_pair.rs
@@ -19,34 +19,25 @@
pub fn parse_tz(paths: Vec<&str>) -> Option<TimezonePair> {
- let mut prefix = String::from("");
- let mut res = Vec::new();
-
// make sure we do not do a loop if the result is obviously
// wrong (small protection against DoS)
// 6 is the maximum for 2 TZs
- if paths.len() > 6 {
+ if paths.len() > 6 || paths.is_empty() {
return None;
}
- for item in paths {
- prefix.push_str(item);
- match prefix.parse() {
- Ok(tz) => {
- res.push(tz);
- prefix.clear();
- }
- Err(_) => prefix.push('/'),
+ // Iterate through all possible split points from 1 to paths.len() - 1
+ for i in 1..paths.len() {
+ let s1 = paths[0..i].join(\"/\");
+ let s2 = paths[i..].join(\"/\");
+
+ // If both parts parse as valid timezones, we've found our pair.
+ if let (Ok(tz1), Ok(tz2)) = (s1.parse(), s2.parse()) {
+ return Some(TimezonePair::new(tz1, tz2));
}
}
- if res.len() == 2 || prefix.is_empty() {
- Some(TimezonePair::new(res[0], res[1]))
- } else {
- None
- }
+ None
}
impl TimezonePair {
Le code marche (de ce que je sache), mais je l'ai refusé parce que ça m'a semblé moins idiomatique que le mien, que le code avait l'air plus subtile et avec une complexité plus dure à évaluer (mon algo fait un nombre linéaire d'appel à Tz::parse() dépendant de la taille de la chaîne sauf erreur de ma part, la ou le code proposé fait du 2n). Et je pense consomme un peu plus de mémoire (vu qu'il y a plus d'allocations de chaîne via s1 et s2).
En pratique, on s'en fout car la fonction est appelé 1 fois par jour (y a un cache), que n vaut au plus 6, mais j'aime bien ne pas avoir du code rust qui ressemble trop à du code C quand je peux éviter.
Le LLM a aussi réussi à se planter dans un diff (eg, un diff syntaxiquement incorrect), et a ne pas noter qu'une constante est utilisé en dehors du code rust (BUILDTIME dans les templates askama).
Ce que je retient avec mon échantillon de 1 revue, c'est que le LLM, outil de matching avant tout, a correctement noté des trucs subtils, mais classiques. Remplacer un "// TODO add test" avec une réponse "faut faire des tests", c'est une revue courante. Mettre header au lieu de head, je suis sans doute pas le premier à faire l'erreur. Remplacer une chaine par une constante en Rust, c'est aussi une optim de base qu'on doit voir dans plein de revue.
Et hélas, refaire un algo qui marche sans raison, c'est aussi une réponse courante dans des revues de code.
Je ne dit pas que ça sert à rien, j'ai améliorer mon code grâce à ça mais si la seule raison de ma productivité est d'avoir face à moi une machine reloue, je sais pas si c'est si bien que ça.
Toujours dans un cas qui va dans mon sens, j'ai aussi fait une seconde tentative, toujours via Gemini, toujours sur les calendriers, mais avec de la génération de code. J'ai voulu automatisé le fait de copier les jours fériés qui concernent mon équipe (8 pays) sur le calendrier d'équipe pour aider notre administratrice. Google Calendar est scriptable via une API, on peut lancer du javascript chez Google avec la gestion des clés et tout coté serveur, donc ç'est pas mal. Mais ayant déjà du faire ça par le passé, la documentation de Google est franchement pas terrible (et traduite automatiquement, avec un coté bizarre à la lecture).
Donc je me suis dit que le LLM de Google doit sans doute bien connaître l'API Google et peut me sortir un script d'exemple que je peux adapter, quelque chose qui prends un ics d'un coté pour le mettre vers le calendrier sans trop de souci. L'idée était de comparer et copier les nouveaux événements pour ceux qui peuvent changer dans l'année (le cas typique, c'est le ramadan, mais je doute pas que Trump invente aussi un nouveau jour férié à un moment), ou quand quelqu'un arrive dans l'équipe depuis un pays non couvert dans l'année. Pour le moment, c'est une copie manuelle en décembre, mais un truc dynamique serait mieux.
Il n'y a rien d'innovant, c'est juste lire 2 ics via http, faire une boucle pour comparer et envoyer la différence via une API. Et en effet, j'ai eu mon script en 30 secondes, ce qui me va parce que j'ai pas envie de faire du js si je peux l'éviter.
Le seul probléme, le modèle a généré du code utilisant une fonction sans dire d’où elle vient, mais après recherche pas des apis Google (et qui ne marche pas). Alors bien sur, les hallucinations, ç'est documenté, mais la ou c'est intéressant, que je pense que celle ci est causé par le fait qu'il y a assez peu de code JS sur le web qui concerne le scripting de Google Workspace, et peu de code sur les calendriers en javascript en général, mais juste assez pour avoir une réponse en utilisant une lib non spécifié. Malheureusement, j'ai pas gardé le résultat.
Donc oui, la ou les modèles font du bon boulot, c'est quand ce que tu dois faire a déjà été fait 100 fois et que le code est publique. Quand tu tapes dans les trucs un peu "nouveau" et un peu cracra que ça soit du point de vue des libs à utiliser, ou du domaine, ça semble commencer à partir un peu en vrille plus facilement.
Pour moi, ça montre surtout que le métier de dev, c'est assez souvent refaire la roue, et c'est pour ça qu'une technologie qui est une forme de recherche statistique de code marche tellement bien dans les cas ou ç'est finalement un peu toujours la même chose.
[^] # Re: Pendant ce temps
Posté par Misc (site web personnel) . En réponse au journal De développeur à orchestrateur, comment l'IA a changé ma vie. Évalué à 5.
En fait, par la nature du fonctionnement des modèles, les LLMs sont efficaces pour les problèmes déjà résolus plusieurs fois ailleurs.
J'ai un programme en rust qui me file un ics pour ce que j'appelle la "meeting chaos period", ce moment de l'année où les réunions bougent dans mon calendrier à cause de la date de changement d'heure qui différe entre l'Europe (ou je suis) et les USA (ou mes collègues sont). Quand je fait un meeting, il bouge quand je bouge, quand c'est mon chef en Californie, ça bouge quand il bouge. Du coup, y a des conflits de partout. Par curiosité, j'ai choisi utilisé Crush en branchant le logiciel sur Gemini de Google il y a ~8 mois, et j'ai demandé via l'interface de faire une revue de code.
Le modèle a correctement noté que j'ai mal écrit une balise, que je devais mettre des tests parce que j'ai laissé ça en "TODO". J'ai laissé le modèle écrire des tests, mais j'ai du les refaire de 0 car relativement non idiomatique. Puis j'ai eu comme remarque que je pouvais utiliser une constante, mais le code généré a mis un clone() gratuit que j'ai du retirer. Le modèle a aussi correctement remonté que mes tests n'étaient pas suffisant, vu que j'avais mis un commentaire sur le fait que ça ne soit pas forcément 1h de décalage (et en effet, il y a parfois 2h et parfois 30 minutes). Du coup, j'ai continué à chercher tout les edges cases possibles, et c'est pour ça que j'ai 2 fois plus de tests que de code sur le fichier principal.
J'ai aussi eu comme suggestion d'ajouter ce patch:
Le code marche (de ce que je sache), mais je l'ai refusé parce que ça m'a semblé moins idiomatique que le mien, que le code avait l'air plus subtile et avec une complexité plus dure à évaluer (mon algo fait un nombre linéaire d'appel à Tz::parse() dépendant de la taille de la chaîne sauf erreur de ma part, la ou le code proposé fait du 2n). Et je pense consomme un peu plus de mémoire (vu qu'il y a plus d'allocations de chaîne via s1 et s2).
En pratique, on s'en fout car la fonction est appelé 1 fois par jour (y a un cache), que n vaut au plus 6, mais j'aime bien ne pas avoir du code rust qui ressemble trop à du code C quand je peux éviter.
Le LLM a aussi réussi à se planter dans un diff (eg, un diff syntaxiquement incorrect), et a ne pas noter qu'une constante est utilisé en dehors du code rust (BUILDTIME dans les templates askama).
Ce que je retient avec mon échantillon de 1 revue, c'est que le LLM, outil de matching avant tout, a correctement noté des trucs subtils, mais classiques. Remplacer un "// TODO add test" avec une réponse "faut faire des tests", c'est une revue courante. Mettre header au lieu de head, je suis sans doute pas le premier à faire l'erreur. Remplacer une chaine par une constante en Rust, c'est aussi une optim de base qu'on doit voir dans plein de revue.
Et hélas, refaire un algo qui marche sans raison, c'est aussi une réponse courante dans des revues de code.
Je ne dit pas que ça sert à rien, j'ai améliorer mon code grâce à ça mais si la seule raison de ma productivité est d'avoir face à moi une machine reloue, je sais pas si c'est si bien que ça.
Toujours dans un cas qui va dans mon sens, j'ai aussi fait une seconde tentative, toujours via Gemini, toujours sur les calendriers, mais avec de la génération de code. J'ai voulu automatisé le fait de copier les jours fériés qui concernent mon équipe (8 pays) sur le calendrier d'équipe pour aider notre administratrice. Google Calendar est scriptable via une API, on peut lancer du javascript chez Google avec la gestion des clés et tout coté serveur, donc ç'est pas mal. Mais ayant déjà du faire ça par le passé, la documentation de Google est franchement pas terrible (et traduite automatiquement, avec un coté bizarre à la lecture).
Donc je me suis dit que le LLM de Google doit sans doute bien connaître l'API Google et peut me sortir un script d'exemple que je peux adapter, quelque chose qui prends un ics d'un coté pour le mettre vers le calendrier sans trop de souci. L'idée était de comparer et copier les nouveaux événements pour ceux qui peuvent changer dans l'année (le cas typique, c'est le ramadan, mais je doute pas que Trump invente aussi un nouveau jour férié à un moment), ou quand quelqu'un arrive dans l'équipe depuis un pays non couvert dans l'année. Pour le moment, c'est une copie manuelle en décembre, mais un truc dynamique serait mieux.
Il n'y a rien d'innovant, c'est juste lire 2 ics via http, faire une boucle pour comparer et envoyer la différence via une API. Et en effet, j'ai eu mon script en 30 secondes, ce qui me va parce que j'ai pas envie de faire du js si je peux l'éviter.
Le seul probléme, le modèle a généré du code utilisant une fonction sans dire d’où elle vient, mais après recherche pas des apis Google (et qui ne marche pas). Alors bien sur, les hallucinations, ç'est documenté, mais la ou c'est intéressant, que je pense que celle ci est causé par le fait qu'il y a assez peu de code JS sur le web qui concerne le scripting de Google Workspace, et peu de code sur les calendriers en javascript en général, mais juste assez pour avoir une réponse en utilisant une lib non spécifié. Malheureusement, j'ai pas gardé le résultat.
Donc oui, la ou les modèles font du bon boulot, c'est quand ce que tu dois faire a déjà été fait 100 fois et que le code est publique. Quand tu tapes dans les trucs un peu "nouveau" et un peu cracra que ça soit du point de vue des libs à utiliser, ou du domaine, ça semble commencer à partir un peu en vrille plus facilement.
Pour moi, ça montre surtout que le métier de dev, c'est assez souvent refaire la roue, et c'est pour ça qu'une technologie qui est une forme de recherche statistique de code marche tellement bien dans les cas ou ç'est finalement un peu toujours la même chose.