J’aimerais qu’on construise ce genre de chose une fois les hallucinations des modèles de base maîtrisées à un niveau Six Sigma. Est-ce que cela signifie qu’on peut les contrôler suffisamment grâce à un agent jouant un rôle de gestion ou à d’autres compléments au niveau du code ?

Lisez la documentation officielle, bon sang.

Merci beaucoup pour ces informations très précieuses sur le développement et l’exploitation réels du site, je les lis avec grand intérêt.

On parle d’une entreprise plus grande que Toss~

Bien sûr, impossible qu’un benchmark échappe à une petite manipulation.

S’il y a d’un côté un manager direct qui ne tient pas compte des émotions et de l’autre un manager bienveillant qui sait entretenir le rapport humain, lequel de ces deux types de managers peut faire progresser les membres de son équipe grâce au feedback ? C’est la question que je me suis posée en lisant l’article.

Je pense que c’est un jeu de probabilités. Des personnes qui réussissent à grandir malgré des chances extrêmement faibles, il y en a partout. Je pense qu’un manager doit laisser ces cas de côté et s’efforcer d’augmenter la probabilité globale. Je pense qu’un manager mérite le respect s’il agit en croyant sincèrement, à sa manière, augmenter ces probabilités. Tant qu’il ne se contente pas de maintenir les méthodes qu’il a toujours utilisées simplement parce qu’il peut se le permettre.

Les réactions sur Hacker News font peur... « Dix millions ? Une blague ? »

On dit que ce n’est pas une checklist, mais je vais quand même en faire ma propre checklist.

Une expérience vraiment intéressante.

Je me disais bien ces derniers temps que Gemini était écrasant en vitesse de time to first token… voilà donc pourquoi.

Je suis tout à fait d’accord sur le fait qu’il faut absolument consulter la documentation officielle.

Quand on commence à enseigner le code, j’ai l’impression que l’aptitude à devenir programmeur se révèle d’abord dans la capacité — ou non — à lire attentivement les messages d’erreur.

Ce ne sont pas tous les points, mais la plupart parlent probablement à beaucoup de monde.

Je n’avais jamais pensé au fait que cela ressemble à de l’artisanat, mais je m’y retrouve beaucoup.
En y réfléchissant sous cet angle, j’ai l’impression que cela explique beaucoup de phénomènes.

Hyperlight - gestionnaire de machine virtuelle légère (VMM) | GeekNews

Hyperlight WASM : rapide, sécurisé et sans OS | GeekNews

Lire des commentaires critiques m’a beaucoup fait réfléchir. Il y a des points avec lesquels je suis d’accord, et d’autres sur lesquels je pense différemment.

• Il peut y avoir aujourd’hui une certaine bulle autour du statut des développeurs, mais je pense que c’est aussi le cas dans d’autres métiers. On passe d’une minorité à une majorité. Autrement dit, à mesure que le nombre de professionnels augmente et que la diversité s’élargit, c’est un phénomène naturel. Je ne dis pas que cette direction est forcément la bonne, mais je ne pense pas que ce soit un trait particulièrement propre aux développeurs.
• C’est facile à apprendre. Je l’admets, mais une faible barrière à l’entrée ne signifie pas une faible expertise. Si c’est plus facile à apprendre que d’autres métiers techniques dans d’autres secteurs, en particulier dans l’industrie manufacturière, ce n’est pas tant parce que le développement est simple, mais plutôt à cause de la culture open source ou du faible niveau de risque. Comme je l’ai dit plus haut à propos de la diversité des développeurs, il y a des tâches qu’on peut apprendre rapidement et faire, et d’autres qui doivent reposer sur une véritable expertise.
• L’environnement a changé. Je ne pense pas que la hausse des attentes du marché envers les développeurs et de leur rémunération, par rapport au passé, s’explique seulement par leurs compétences, leur niveau de maîtrise ou leur expertise. À mesure que l’IT s’insère profondément dans la vie humaine, le logiciel devient plus important et soutient une grande partie des infrastructures. Ce n’est pas que les capacités de chaque développeur aient tellement augmenté que leur rémunération grimpe ; je pense simplement que le travail lui-même est devenu plus cher. Parce qu’il est devenu plus important qu’avant.
• Est-il vraiment pertinent de comparer directement avec l’industrie manufacturière ? Si l’on considère que le secteur ne s’est pas encore suffisamment sophistiqué, la référence de comparaison semble être l’industrie manufacturière. Si l’on essaie de comprendre le logiciel à travers le paradigme de l’industrie manufacturière, cela peut donner l’impression d’un artisanat ou d’un développement amateur. Mais à l’inverse, je pense que c’est justement ce genre d’aspects qui a façonné une culture du développement logiciel plus souple et plus créative, et qui lui permet de croître.
• Une implication excessive est dangereuse. Je suis tout à fait d’accord. Le développement n’est pas la seule chose au monde qu’il faut étudier, et, au fond, nous écrivons toujours « employé de bureau » dans la case profession. Il faut se garder de penser que, sous prétexte qu’il y a une bulle dans l’ambiance sociale, ce métier serait fondamentalement très différent des autres. Mais cela vaut pour n’importe quelle profession.

Pour Toss, l’UX est directement liée à sa survie.
Mais sous un autre angle que celui de cet article, je ne sais pas si cette entreprise sait vraiment bien poursuivre la rentabilité.

Joyeux anniversaire. Écoute bien les anciens et reste en bonne santé pendant très longtemps.

Je pense que ce genre de feedback peut être mal vécu, voire susciter de la colère, selon la personnalité, le contexte culturel ou les différences individuelles. Mais, au fond, partir du principe que « cette personne ne cherche pas délibérément à me faire souffrir » me semble être une meilleure approche, à la fois pour son équilibre mental et dans une perspective de progression. Si l’on se retrouve dans ce genre de situation, on pourra peut-être se rappeler de ce texte et se demander : « Et si ce manager aussi ? » C’est un bon texte.