Deux remarques (il y en aurait d'autres...) concernant la partie « Reset, on remet une pièce ».
Pourquoi avoir enlevé ce qui donne un élément de contexte ?
En ce qui me concerne, je suis assez fan des concepts de programmation fonctionnelle.
Ensuite, au § suivant, pourquoi avoir reformulé en ce "truc" incompréhensible qui indique ce qui est fait sans donner de raison claire :
C'est un fold de tous les événements signés du groupe, ordonés de manière déterministe, qui fait évoluer l'état.
et non pas gardé ce qui est plus fluide (pour moi en tout cas) et indique l'évolution de la réflexion (le pourquoi du comment) :
Ensuite je modélise le domaine et le flux des données de manière adaptée, et tout coule de source. Pour les plus techniques d’entre vous, j’ai utilisé le langage Elm, et le cœur de l’appli, se résume à cette fonction, qui est un "fold" de tous les événements du groupe (signés), triés de manière déterministe, pour faire évoluer l’état du groupe.
Forcément, ya une 3ème remarque :D Ah et sinon, plus haut dans la partie « Un mois de vibe coding »
Je pars sur du SolidJS et TypeScript pour le client, Loro pour les CRDT, PocketBase pour le serveur.
mais pourquoi ?!
notamment pourquoi introduire les CRDT sans l'expliquer, est-ce un concept que tu avais identifié dans le travail amont ? En quoi est-il structurant (même si c'est évident pour une appli répartie) ?
et quitte à faire appel à un LLM, autant avoir un schéma explicatif (archi fonctionnelle, logicielle voire technique) ou indiquer qu'il est disponible dans le DESIGN.md (divulgâchage : ah bah non plus :/ de toute façon, mieux vaut abstraire le DESIGN de la pile logicielle retenue et avoir un ARCHITECTURE.md qui permet de séparer le fonctionnel / besoins utilisateurs des choix d'implémentation).
Ces points m'ont fait tiquer sur l'écriture du journal par LLM, qui zappe généralement la réflexion / le changement de point de vue (et rend le texte insipide) pour privilégier quoi est fait au détriment du « dans quel but » et état des hypothèses du moment contribuant à un choix intermédiaire.
[^] # Re: Journal LLM ?
Posté par BAud (site web personnel) . En réponse au journal J'ai vibe-codé une appli pendant un mois, puis j'ai tout jeté. Évalué à 3 (+1/-0). Dernière modification le 11 septembre 2026 à 14:52.
Deux remarques (il y en aurait d'autres...) concernant la partie « Reset, on remet une pièce ».
Pourquoi avoir enlevé ce qui donne un élément de contexte ?
Ensuite, au § suivant, pourquoi avoir reformulé en ce "truc" incompréhensible qui indique ce qui est fait sans donner de raison claire :
et non pas gardé ce qui est plus fluide (pour moi en tout cas) et indique l'évolution de la réflexion (le pourquoi du comment) :
Forcément, ya une 3ème remarque :D Ah et sinon, plus haut dans la partie « Un mois de vibe coding »
mais pourquoi ?!
notamment pourquoi introduire les CRDT sans l'expliquer, est-ce un concept que tu avais identifié dans le travail amont ? En quoi est-il structurant (même si c'est évident pour une appli répartie) ?
et quitte à faire appel à un LLM, autant avoir un schéma explicatif (archi fonctionnelle, logicielle voire technique) ou indiquer qu'il est disponible dans le DESIGN.md (divulgâchage : ah bah non plus :/ de toute façon, mieux vaut abstraire le DESIGN de la pile logicielle retenue et avoir un ARCHITECTURE.md qui permet de séparer le fonctionnel / besoins utilisateurs des choix d'implémentation).
Ces points m'ont fait tiquer sur l'écriture du journal par LLM, qui zappe généralement la réflexion / le changement de point de vue (et rend le texte insipide) pour privilégier quoi est fait au détriment du « dans quel but » et état des hypothèses du moment contribuant à un choix intermédiaire.