Personnellement, j’aimerais qu’on arrête de voir ici des textes sur le vibe coding. J’ai vraiment l’impression que, sans aucune exception, tous ces articles ne racontent rien d’autre que des histoires sans fondement et complètement absurdes du genre : « je n’ai pas fait d’études d’informatique, mais grâce au vibe coding j’ai généré en quelques semaines plusieurs milliards de chiffre d’affaires, j’ai même refusé un rachat par des VC, et ainsi de suite ». Est-ce qu’on est vraiment obligés de continuer à lire ce genre de texte sans intérêt ?
Pourquoi les entreprises coréennes ou le gouvernement se concentrent-ils sur des modèles de langage spécialisés en coréen ? Quand on pense à la tendance actuelle des LLM, qui améliorent leurs performances en s’entraînant sur des données massives à l’échelle d’Internet, j’ai plutôt l’impression qu’un modèle généraliste, indépendamment de la langue, serait plus naturel. Du coup, je ne vois pas vraiment quels avantages concrets peut avoir un LM spécialement optimisé pour le coréen.
En réfléchissant quelques minutes de plus et en tapant quelques fois de plus, on peut éviter de payer 1�a0000�a0$ et utiliser cet argent pour s'acheter à manger. On dirait moins de l'ultrathink que du hangover-think.
C’est une remarque à la fois évidente et importante, mais en pratique, c’est très difficile à mettre en œuvre et cela demande beaucoup d’attention. Les collègues brillants autour de moi semblaient particulièrement doués pour « décompresser » des informations condensées.
Il existe des termes plus appropriés comme experienced, verified ou skillful, donc le fait d’avoir utilisé boring à tout prix donne l’impression qu’il y avait une intention de faire du buzz.
>Ce qui est bien avec le caractère banal de ces choses (si contraignant), c’est que leurs capacités sont bien comprises. Mais surtout, leurs modes de défaillance sont bien connus.
Il y a dans le texte original un lien lié à boring, et à en juger par le contenu, boring semble ici signifier « trop familier ».
> Curiosité et questions complémentaires : la personne qui résout le problème doit poser des questions en continu et chercher à comprendre le contexte.
Je pense que c’est la partie la plus importante.
Parce que cette attitude consistant à se rapprocher de l’essentiel devient la motivation qui permet de faire émerger d’autres solutions, comme minimiser les passations, construire une culture d’organisation forte et réduire au maximum la distance entre le client et le code.
Jusqu’à récemment, je me concentrais uniquement sur l’implémentation des exigences données, mais une fois le développement terminé, j’avais souvent l’impression que l’impact réel restait minime. Ces jours-ci, avant même de discuter des exigences, je demande avec insistance « pourquoi c’est nécessaire », et j’ai l’impression que c’est dans ce processus que l’on trouve des solutions plus proches de la bonne réponse.
À l’étranger, cela semble être considéré comme une stack ennuyeuse.
En réalité, Go est tout simplement le choix le plus facile pour créer un serveur web...
J’ai l’impression qu’ils disent qu’il faut développer avec Rust, ou des langages du côté de la FP, pour que ce ne soit pas ennuyeux.
Je pense que GeekNews est appréciable de ce point de vue, parce que la densité d'information y est élevée.
Le fait que ça se termine en style télégraphique donne vraiment l'impression d'une optimisation maximale de la densité.
Personnellement, j’aimerais qu’on arrête de voir ici des textes sur le vibe coding. J’ai vraiment l’impression que, sans aucune exception, tous ces articles ne racontent rien d’autre que des histoires sans fondement et complètement absurdes du genre : « je n’ai pas fait d’études d’informatique, mais grâce au vibe coding j’ai généré en quelques semaines plusieurs milliards de chiffre d’affaires, j’ai même refusé un rachat par des VC, et ainsi de suite ». Est-ce qu’on est vraiment obligés de continuer à lire ce genre de texte sans intérêt ?
J’ai créé un template pour utiliser https://github.com/gracefullight/py-starter.
Merci.
Pourquoi les entreprises coréennes ou le gouvernement se concentrent-ils sur des modèles de langage spécialisés en coréen ? Quand on pense à la tendance actuelle des LLM, qui améliorent leurs performances en s’entraînant sur des données massives à l’échelle d’Internet, j’ai plutôt l’impression qu’un modèle généraliste, indépendamment de la langue, serait plus naturel. Du coup, je ne vois pas vraiment quels avantages concrets peut avoir un LM spécialement optimisé pour le coréen.
En réfléchissant quelques minutes de plus et en tapant quelques fois de plus, on peut éviter de payer 1�a0000�a0$ et utiliser cet argent pour s'acheter à manger. On dirait moins de l'ultrathink que du hangover-think.
C’est une remarque à la fois évidente et importante, mais en pratique, c’est très difficile à mettre en œuvre et cela demande beaucoup d’attention. Les collègues brillants autour de moi semblaient particulièrement doués pour « décompresser » des informations condensées.
Je pense que golang et React sont tous deux des langages de programmation d’entreprise « boring » de la nouvelle ère.
Comme
boringne se traduit pas à 100 % correctement par « ennuyeux », on dirait que la nuance n’est pas vraiment transmise aux lecteurs coréens.À voir avant de négocier votre salaire
Il existe des termes plus appropriés comme experienced, verified ou skillful, donc le fait d’avoir utilisé boring à tout prix donne l’impression qu’il y avait une intention de faire du buzz.
>Ce qui est bien avec le caractère banal de ces choses (si contraignant), c’est que leurs capacités sont bien comprises. Mais surtout, leurs modes de défaillance sont bien connus.
Il y a dans le texte original un lien lié à
boring, et à en juger par le contenu,boringsemble ici signifier « trop familier ».Le nom du modèle d’IA a quelque chose d’assez inquiétant, on dirait un nom tout droit sorti d’un univers post-apocalyptique ou dystopique lol
Ce n’est pas ennuyeux à écrire, mais plutôt une pile « gukbap » devenue ennuyeuse à force d’avoir été trop utilisée, non ?
> Curiosité et questions complémentaires : la personne qui résout le problème doit poser des questions en continu et chercher à comprendre le contexte.
Je pense que c’est la partie la plus importante.
Parce que cette attitude consistant à se rapprocher de l’essentiel devient la motivation qui permet de faire émerger d’autres solutions, comme minimiser les passations, construire une culture d’organisation forte et réduire au maximum la distance entre le client et le code.
Jusqu’à récemment, je me concentrais uniquement sur l’implémentation des exigences données, mais une fois le développement terminé, j’avais souvent l’impression que l’impact réel restait minime. Ces jours-ci, avant même de discuter des exigences, je demande avec insistance « pourquoi c’est nécessaire », et j’ai l’impression que c’est dans ce processus que l’on trouve des solutions plus proches de la bonne réponse.
À l’étranger, cela semble être considéré comme une stack ennuyeuse.
En réalité, Go est tout simplement le choix le plus facile pour créer un serveur web...
J’ai l’impression qu’ils disent qu’il faut développer avec Rust, ou des langages du côté de la FP, pour que ce ne soit pas ennuyeux.
J’aimerais vivre dans le monde ennuyeux de Postgres, golang et React.
Jusqu’au noyau Linux 2.6.29 environ...
Des évidences tellement banales... des points importants qu’on néglige justement parce qu’ils paraissent trop évidents...
Le simple fait qu’ils aient utilisé gRPC… haha
Moi aussi, ma première réaction a été de me dire : quoi, Go serait ennuyeux ?
À la limite, on pourrait peut-être dire ça de classic asp.
Je pense que GeekNews est appréciable de ce point de vue, parce que la densité d'information y est élevée.
Le fait que ça se termine en style télégraphique donne vraiment l'impression d'une optimisation maximale de la densité.