"Sources d'erreur" ça c'est très vrai, comme les humains d'ailleurs (les LLM n'ont pas >inventé les bugs). C'est pour ça qu'on relit et qu'on teste. Les anecdotes "ChatGPT a dit >une connerie" il y en a autant que de gens qui disent que ça les a aidés.
C'est d'autant plus difficile de voir le bug potentiel quand on a pas écrit le code, et que probablement on ne comprend pas non plus le code.
Et pour l'exemple en question, ce n'est pas un bug c'est une erreur. Le client veut augmenter la taille d'un message dans rabbitmq et gpt lui dis de changer la valeur de frame_max. Aucun rapport. Ouvrir la doc de rabbitmq, / max_, trouver le paramètre, lire la définition. Environ 1minute....
Pour moi il y a plusieurs problèmes structurels avec ces outils :
on ne fait plus ses gammes, son footing et donc on perd en fluidité, en agilité et au final en compétence
utiliser un llm est un anti pattern du dev. Développer c'est faire du spécifique pour répondre à un cas bien particulier. Si ce n'est pas du spécifique c'est dans une lib, et les lib sont dans un framework. Par essence un llm donne des réponses génériques. Si c'est générique c'est dans la lib et dans le framework avec tous les avantages connus.
Perso je trouve les llm verbeux, ils écrivent trop de code et ne respectent pas les pratiques du projet et on se retrouve avec du code incohérent avec la base de code. Tout ça pour dire que relire le code généré par un llm est fastidieux et j'ai souvent bien plus vite fait de l'écrire moi, que de demander à un llm, une fois deux fois trois fois dix fois pour avoir ce que je veux, puis de relire, de comprendre et de remettre au carré.
écrire le code n'est plus vraiment un sujet depuis très longtemps je pense. Être un dev aujourd'hui c'est comprendre le besoin, comprendre l'architecture de la base de code et écrire juste le strict nécessaire pour ajouter le code qui répond au besoin. J'ai de plus en plus à intervenir sur du code que j'ai écrit pour des clients il y a plusieurs années et qui a été repris par la suite par d'autres gens et le plus souvent je trouve côte à côte du code similaire empilé par divers dev. Au bout d'un moment tout s'effondre sous son propre poids. Et moi je nettoie derrière.
Pour terminer sur le sujet, les gens qui utilisent un llm lisent un livre en portugais sans parler la langue et de dire qu'ils comprennent.
Bref comme me l'a dit un presta chez un client : "moi je suis très content que les gens dev avec un llm. Comme ça je répare leurs bêtises à 5k€ la journée".
[^] # Re: Le choix de ~Sophie~ Claude
Posté par oau . En réponse au lien Extorsion automatisée, chantage ciblé... quand Claude Code pilote une opération de « vibe hacking » . Évalué à 5.
C'est d'autant plus difficile de voir le bug potentiel quand on a pas écrit le code, et que probablement on ne comprend pas non plus le code.
Et pour l'exemple en question, ce n'est pas un bug c'est une erreur. Le client veut augmenter la taille d'un message dans rabbitmq et gpt lui dis de changer la valeur de frame_max. Aucun rapport. Ouvrir la doc de rabbitmq, / max_, trouver le paramètre, lire la définition. Environ 1minute....
Pour moi il y a plusieurs problèmes structurels avec ces outils :
Pour terminer sur le sujet, les gens qui utilisent un llm lisent un livre en portugais sans parler la langue et de dire qu'ils comprennent.
Bref comme me l'a dit un presta chez un client : "moi je suis très content que les gens dev avec un llm. Comme ça je répare leurs bêtises à 5k€ la journée".