Je vous ai bien lu. Ainsi que ce que vous avez écrit sur votre blog. Je ne sais pas si l’analogie est vraiment appropriée, mais cela me fait penser à la raison pour laquelle le tout premier tutoriel de nombreux langages est Hello World!, et au fait que, par le passé, lorsqu’on apprenait le développement web en construisant des forums ou des boutiques en ligne, le processus relevait au fond de la même logique que celle que vous évoquez. À l’époque, je pensais ceci : si l’on maîtrise suffisamment les techniques pour créer un forum et une boutique en ligne, alors on peut implémenter la plupart des sites web. Et au fond, la programmation, en fin de compte, ce n’est jamais qu’une affaire d’input et d’output.
Je trouve que la conclusion est un peu excessive. La commercialisation ou la formalisation peuvent poser problème, mais cela ne veut pas dire que des outils comme les sprints ou le backlog sont devenus inutiles. Ils ont aussi contribué à ancrer une culture de réunion plus horizontale et centrée sur les objectifs. Il est vrai que le SDD a gagné en importance, mais comme on peut désormais rédiger rapidement cette spécification de manière collaborative avec l’IA, cela reste malgré tout agile. Les sprints de deux semaines se sont simplement raccourcis à quelques heures ; l’essence même, celle d’itérer en affinant progressivement, me semble inchangée.
C’est un article assez idiot. Le point essentiel, c’est qu’il faut rédiger la spec. elle-même de manière agile... L’agilité, c’est s’adapter rapidement à l’évolution des exigences du client.
C’est à cause de ce genre de malentendus sur l’agilité et des idées vagues que les choses partent dans la mauvaise direction, que ce soit pour l’agilité ou pour la culture de développement.
À certains égards, tout le monde est agile. Je me demande même s’il y a déjà eu une époque où l’on déployait aussi vite qu’aujourd’hui et où l’on recevait autant de retours.
Comme on n’est pas sans avoir à lire du code, l’idée que le code prime sur la documentation me semble valable sous cet angle. Et puisque, en tant qu’instructions, la documentation doit être lue par la LLM qui en assure l’implémentation, je suis aussi d’accord de ce point de vue. Donc, au final, j’ai l’impression que les deux sont importants en même temps.
Le problème des produits fondés sur la productivité des LLM aujourd’hui, c’est la dette qui s’accumule en phase d’exploitation. Pour assurer une exploitation continue, les développeurs doivent intervenir sur le code, et pour cela je pense qu’à ce stade le code doit encore pouvoir tenir lieu de documentation.
Ce n’était pas tant que libhwp était la raison décisive, c’est surtout le groupe de déchets qui posait davantage problème. Il n’y a pas de sujet dans cette phrase ; si ça t’énerve en la lisant, c’est ton problème.
Ah, vous avez raison de le souligner, professeur. La machine à états elle-même est bien déterministe. Ce que j’ai introduit dans le manifesto repose sur une base non Turing-complète, et il n’existe pas de boucle à l’intérieur du DSL. Grâce à cela, il est possible de calculer à l’avance comment le programme va fonctionner avant même de l’exécuter, et d’expliquer pourquoi un tel résultat a été obtenu.
Je vous ai bien lu. Ainsi que ce que vous avez écrit sur votre blog. Je ne sais pas si l’analogie est vraiment appropriée, mais cela me fait penser à la raison pour laquelle le tout premier tutoriel de nombreux langages est
Hello World!, et au fait que, par le passé, lorsqu’on apprenait le développement web en construisant des forums ou des boutiques en ligne, le processus relevait au fond de la même logique que celle que vous évoquez. À l’époque, je pensais ceci : si l’on maîtrise suffisamment les techniques pour créer un forum et une boutique en ligne, alors on peut implémenter la plupart des sites web. Et au fond, la programmation, en fin de compte, ce n’est jamais qu’une affaire d’input et d’output.Je trouve que la conclusion est un peu excessive. La commercialisation ou la formalisation peuvent poser problème, mais cela ne veut pas dire que des outils comme les sprints ou le backlog sont devenus inutiles. Ils ont aussi contribué à ancrer une culture de réunion plus horizontale et centrée sur les objectifs. Il est vrai que le SDD a gagné en importance, mais comme on peut désormais rédiger rapidement cette spécification de manière collaborative avec l’IA, cela reste malgré tout agile. Les sprints de deux semaines se sont simplement raccourcis à quelques heures ; l’essence même, celle d’itérer en affinant progressivement, me semble inchangée.
C’est un article assez idiot. Le point essentiel, c’est qu’il faut rédiger la spec. elle-même de manière agile... L’agilité, c’est s’adapter rapidement à l’évolution des exigences du client.
C’est à cause de ce genre de malentendus sur l’agilité et des idées vagues que les choses partent dans la mauvaise direction, que ce soit pour l’agilité ou pour la culture de développement.
C'est quoi encore ce délire ?
On croit que les DB sont utilisées pour les performances ou quoi ?
Le lien pointe visiblement par erreur vers un domaine en
com.Voici le lien vers l’annonce correspondante.
[Info] 16/04 (jeu.) Problème d’accès au service ▶ Correction effectuée
On peut vivre sans réfrigérateur, mais ce serait moins pratique.
S’il est possible d’en utiliser un, il n’y a aucune raison de s’en priver.
En effet, ce n’est pas sous Apache 2.0.
Merci beaucoup !!
Celui-ci a une licence différente de celle du modèle original Gemma 4.
Terriblement, c’est probablement ce que je vois le plus souvent...
Waouh, quand j’avais regardé en 2020, il n’y avait pas beaucoup de bibliothèques capables de gérer le HWP, mais récemment leur nombre a explosé.
C’est encore réservé à macOS... c’est un peu dommage T_T J’ai plein de serveurs inutilisés, mais ils sont tous basés sur Linux...
À certains égards, tout le monde est agile. Je me demande même s’il y a déjà eu une époque où l’on déployait aussi vite qu’aujourd’hui et où l’on recevait autant de retours.
Incroyable de ouf
Comme on n’est pas sans avoir à lire du code, l’idée que le code prime sur la documentation me semble valable sous cet angle. Et puisque, en tant qu’instructions, la documentation doit être lue par la LLM qui en assure l’implémentation, je suis aussi d’accord de ce point de vue. Donc, au final, j’ai l’impression que les deux sont importants en même temps.
Le problème des produits fondés sur la productivité des LLM aujourd’hui, c’est la dette qui s’accumule en phase d’exploitation. Pour assurer une exploitation continue, les développeurs doivent intervenir sur le code, et pour cela je pense qu’à ce stade le code doit encore pouvoir tenir lieu de documentation.
Ce n’était pas tant que
libhwpétait la raison décisive, c’est surtout le groupe de déchets qui posait davantage problème. Il n’y a pas de sujet dans cette phrase ; si ça t’énerve en la lisant, c’est ton problème.Et si le cycle en cascade ne prenait qu’une journée ?
Disponible aussi sur Ollama
https://ollama.com/0xIbra/supergemma4-26b-uncensored-gguf-v2
Un modèle 31b plus grand également
https://huggingface.co/Jiunsong/SuperGemma4-31b-abliterated-mlx-4bit
https://huggingface.co/Jiunsong/SuperGemma4-31b-abliterated-GGUF
Haha, c’est surprenant de voir qu’il s’agit d’un modèle créé par une communauté coréenne.
Ah, vous avez raison de le souligner, professeur. La machine à états elle-même est bien déterministe. Ce que j’ai introduit dans le manifesto repose sur une base non Turing-complète, et il n’existe pas de boucle à l’intérieur du DSL. Grâce à cela, il est possible de calculer à l’avance comment le programme va fonctionner avant même de l’exécuter, et d’expliquer pourquoi un tel résultat a été obtenu.
Merci pour cette remarque !