| Jubijub |
stylé la page... Plam a écrit :
Tout à fait d'accord : 1. J'ai jamais prompté le résultat final voulu direct, j'ai d'ailleurs demandé un truc en CLI pur et basique pour commencer. Y aller par étape est aussi important pour comprendre les mécaniques haut niveau de ton soft. 2. J'ai demandé d'ajouter plein de tests, et c'est génial. Tous les downside du TDD d'avant s'estompent. Il n'y a uniquement que des victoires ! Tu peux te focus sur la partie métier et même demander à ton LLM de t'expliquer la logique quand t'es pas sûr, c'est un énorme gain. edit : d'ailleurs le test devient la mémoire de la logique métier, et donc une super base pour un LLM.
|
le @ dans Claude c'est top, c'est la réponse dont j'avais besoin à mon problème de garder les specs : j'ai un repertoire reqs/ avec mes stories en .md dedans. Et je peux simplement dire à Claude "implement @reqs/<la story> (et ça me propose en auto-complete les docs dedans)". Et après les allez-retour, je peux lui demander de mettre à jour la story, ainsi que des docs genre architecture.md (qui contient mon data model, etc...) Pour les tests : faut surveiller quand meme, c'est très fort pour générer des tests parfaitement cons en abusant du mocking
Kenshineuh a écrit :
C'est exactement ça. On avait du eslint (sans jamais avoir fix) et du prettier (sans jamais l'avoir passé partout également). Je migre tout sur OXC et j'en profite pour fix le projet. L'équipe grandit, ça commençait à devenir chiant. Prochaine étape, virer les 50% de code inutile. :o
|
et ça vaut le coup de péter tout ton historique ? mandatory https://xkcd.com/927/ (ça aurait pu etre pertinent de s'aligner sur un des deux existants, ça te faisait déjà x% du code qui bougeait pas) Je lis aussi "sans jamais l'avoir passé partout également", et ça me fait soucis un peu, vous avez pas de pre-commit hook ? |