J'avoue que pour de petits projets les assistants font très bien le boulot et on arrive à avoir un résultat très vite.
Mais pour de gros projets genre un très gros mono-répo, c'est plus compliqué. On en utilise pas mal dans $JOB mais il nous sort souvent du code pas très adapté et l'effort pour le corriger et loin d'être faible. Et souvent il se perd dans ce qu'on lui a demandé ou exigé comme contrainte au début, donc le soucis de la fenêtre d'attention est réel.
La solution de ne pas polluer sa mémoire en ne gardant que les résultats des analyses est intéressant, mais pas forcément facile à intégrer dans les outils actuels, mais à creuser.
Après à prendre avec des pincettes car c'est un peu le business des auteurs si je comprends bien (pas trop cherché non plus).
Je ne comprends pas trop le principe de tout faire faire par l’IA.
Personnellement mon approche est de voir où les outils me sont utiles et où j’ai envi de les utiliser et pour moi :
je ne sais pas quel contexte donner, je suis exploratif. J’utilise les outils en cli, ils vont eux même se créer des contexte, ils sont en lecture seule. C’est pour découvrir ou base de code (« comment on fait ça ? », « où est-ce qu’on fait ça »,…) ou de l’idéation pour des bugs (« j’ai tel comportement, je comprends pas pourquoi »)
je sais quoi leur faire faire donc je leur donne un contexte. Leurs contexte est limité, ce qu’ils produisent aussi. Par exemple pour bootstraper des tests, ils arrivent pas trop mal à lister les cas à tester et ils font une partie du boilerplate ou pour des refacto simple (ils arrivent à le faire plus rapidement que moi) mais là on parle de quelques lignes voir caractères de modifications
Justement comment faire pour que ce soit elle qui analyse le tout dans une grosse base de code, sans qu'elle s'embourbe car elle a lu trop de fichiers qui étaient inutiles dans son contexte au final (mais comme pour nous elle peux pas trop le savoir au début).
Perso je vois bien l'intérêt si elle est capable de jumper dans une nouvelle base de code et d'aller déjà faire une bonne analyse de ce qu'il faut changer par rapport à un besoin global. C'est des heures de recherches et de cartes mentales évitées.
Pour le moment je n’ai pas rencontré de problème de ce genre avec le plus gros projets que j’ai et ses 900k ligne de code. Ce que font tous les outils que j’ai vu c’est commencer par faire des grep (avec grep, avec rg ou une implémentation à eux).
C’est probablement très loin de ce qu’on doit pouvoir trouver ailleurs mais ça me parait pas dégueux comme taille de projet.
J’ai oublié un troisième usage : hors-sol, sans aucun accès aux fichiers, juste ajouter des snippets de code, pour des petits trucs évidement.
# A tester
Posté par Jean Gabes (site web personnel) . Évalué à 2 (+1/-1).
J'avoue que pour de petits projets les assistants font très bien le boulot et on arrive à avoir un résultat très vite.
Mais pour de gros projets genre un très gros mono-répo, c'est plus compliqué. On en utilise pas mal dans $JOB mais il nous sort souvent du code pas très adapté et l'effort pour le corriger et loin d'être faible. Et souvent il se perd dans ce qu'on lui a demandé ou exigé comme contrainte au début, donc le soucis de la fenêtre d'attention est réel.
La solution de ne pas polluer sa mémoire en ne gardant que les résultats des analyses est intéressant, mais pas forcément facile à intégrer dans les outils actuels, mais à creuser.
Après à prendre avec des pincettes car c'est un peu le business des auteurs si je comprends bien (pas trop cherché non plus).
[^] # Re: A tester
Posté par barmic 🦦 . Évalué à 6 (+4/-0).
Je ne comprends pas trop le principe de tout faire faire par l’IA.
Personnellement mon approche est de voir où les outils me sont utiles et où j’ai envi de les utiliser et pour moi :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: A tester
Posté par Jean Gabes (site web personnel) . Évalué à 1 (+1/-2).
Justement comment faire pour que ce soit elle qui analyse le tout dans une grosse base de code, sans qu'elle s'embourbe car elle a lu trop de fichiers qui étaient inutiles dans son contexte au final (mais comme pour nous elle peux pas trop le savoir au début).
Perso je vois bien l'intérêt si elle est capable de jumper dans une nouvelle base de code et d'aller déjà faire une bonne analyse de ce qu'il faut changer par rapport à un besoin global. C'est des heures de recherches et de cartes mentales évitées.
[^] # Re: A tester
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Pour le moment je n’ai pas rencontré de problème de ce genre avec le plus gros projets que j’ai et ses 900k ligne de code. Ce que font tous les outils que j’ai vu c’est commencer par faire des grep (avec grep, avec rg ou une implémentation à eux).
C’est probablement très loin de ce qu’on doit pouvoir trouver ailleurs mais ça me parait pas dégueux comme taille de projet.
J’ai oublié un troisième usage : hors-sol, sans aucun accès aux fichiers, juste ajouter des snippets de code, pour des petits trucs évidement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
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.