De mes expérimentations, j'ai le même constat, générateur de code ne vois pas de problème a refaire 2, 3, 4, 5, 6 fois la même chose, ni ne fait de recherche préliminaire pour savoir si ce qu'il fait à déjà été mis dans ta base de code.
On arrive (très) rapidement à quelque chose de fonctionnel, et à première vue, (mes premières relectures), on ne voit pas le problème, le code est propre, clair lisible, jusqu'au moment ou faut faire évoluer, ou que le truc a raté un cas à la marge (pourtant y'a tous les tests)
Et là c'est le drame on ne lit plus sa sortie, on la comprends, on voit qu'il fait plusieurs passes sur un tableau alors qu'une seule suffit, on voit qu'il a ajouté des présupposé de nulle part...
Alors quand on s'en rends compte tôt c'est pas grave, le plus gênant c'est si on laisse ces duplication perdurer, qu'on en corrige certaines et pas les autres, et à la fin le refactoring deviens un tel sac de nœuds que le llm lâchera l'affaire; ou plutôt va consommer les tokens jusqu'à plus soif, sans arriver à une solution.
Alors oui le problème de performance, plusieurs fois la même tâche avec juste un booléen qui change, j'ai déjà eu des collègues qui le font, la duplication de code / fonctionnalité, aussi, mais là je parle d'une seule évolution réclamée.
Cette semaine je ferai un autre essai plus orienté fonctionnel en demandant à Claude d'implémenter un algo que j'ai moi-même précédemment implémenté. La démarche sera la même, il partira du commit précédant mes modifs, et je lui décrirai le besoin. Il n'aura plus qu'à l'implémenter. Moi il m'a fallu 4 heures de travail effectif (7 à l'horloge murale) pour aller de zéro à la la validation complète de la suite de test. J'aimerais bien le voir faire mieux, genre plus rapide pour la même qualité de code. Ça m'aiderait à comprendre mes confrères.
ça c'est plus dans ses cordes ;) Tu peux aussi t'en servir pour relire ton code et faire des propositions, lui faire faire de petites évolution que tu relieras intégralement, ou simplement t'en servir comme google y'a 10-15 ans :)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pendant ce temps
Posté par fearan . En réponse au journal De développeur à orchestrateur, comment l'IA a changé ma vie. Évalué à 10.
De mes expérimentations, j'ai le même constat, générateur de code ne vois pas de problème a refaire 2, 3, 4, 5, 6 fois la même chose, ni ne fait de recherche préliminaire pour savoir si ce qu'il fait à déjà été mis dans ta base de code.
On arrive (très) rapidement à quelque chose de fonctionnel, et à première vue, (mes premières relectures), on ne voit pas le problème, le code est propre, clair lisible, jusqu'au moment ou faut faire évoluer, ou que le truc a raté un cas à la marge (pourtant y'a tous les tests)
Et là c'est le drame on ne lit plus sa sortie, on la comprends, on voit qu'il fait plusieurs passes sur un tableau alors qu'une seule suffit, on voit qu'il a ajouté des présupposé de nulle part...
Alors quand on s'en rends compte tôt c'est pas grave, le plus gênant c'est si on laisse ces duplication perdurer, qu'on en corrige certaines et pas les autres, et à la fin le refactoring deviens un tel sac de nœuds que le llm lâchera l'affaire; ou plutôt va consommer les tokens jusqu'à plus soif, sans arriver à une solution.
Alors oui le problème de performance, plusieurs fois la même tâche avec juste un booléen qui change, j'ai déjà eu des collègues qui le font, la duplication de code / fonctionnalité, aussi, mais là je parle d'une seule évolution réclamée.
ça c'est plus dans ses cordes ;) Tu peux aussi t'en servir pour relire ton code et faire des propositions, lui faire faire de petites évolution que tu relieras intégralement, ou simplement t'en servir comme google y'a 10-15 ans :)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent