Vibe Engineering Effect Apps — Michael Arnaldi, Effectful

Alors, bienvenue à tous. Euh, juste pour poser le contexte de cet atelier. J'avais beaucoup d'idées à préparer potentiellement, mais à la fin, j'ai pensé que nous étions en train de "vibe engineering" pour que ce soit authentique, il faut que ce soit à partir de zéro, donc je n'ai absolument rien préparé. Cela signifie que nous pouvons prendre n'importe quel chemin que nous voulons et espérons que ce soit assez réel. Tout d'abord, j'aimerais savoir de la foule, est-ce que vous avez déjà un effet, vous savez, zéro, comme quel est votre niveau de familiarité avec les outils d'IA et des questions de ce genre. Heureusement, nous ne sommes pas trop nombreux, donc j'espère que cela pourra être aussi interactif que possible. Peut-être commençons-nous juste. Je sais que Chris >> bonjour, salut >> familiarité avec l'IA et avec l'effet >> soleil D'accord, bien. >> Exécution de V4 en production. >> Exécution de V4 en production. Contre toute attente, d'ailleurs. >> Bien. >> Bien. Ma main de cette année fait tout et la raison pour laquelle je suis particulièrement intéressé par l'effet, c'est qu'il encourage tellement la sécurité que mes agents ne peuvent pas devenir petits et la raison pour laquelle je voulais l'effet, c'est que nous avions un client API que j'ai transféré et maintenant je suis plus intéressé par la façon dont vous rendez l'effet plus découvert par les agents >> d'accord >> J'ai vu l'idée d'avoir le loy, pas convaincu par ça, donc je suis curieux. Bien. >> Bien. Et vous ? >> Oui, mais j'ai beaucoup entendu parler de l'effet. >> Ça a l'air bien. Ça a l'air bien. >> Bien. Donc, une foule assez hétérogène, tous intéressés par une sorte de façon d'utiliser efficacement les agents avec l'effet, jeu de mots intentionnel. Vous avez souligné une très bonne chose, c'est le clonage, donner l'accès au dépôt, donner à l'agent l'accès au dépôt. Et en réalité, cette session devrait juste s'appeler "clonez juste le [ __ ] repo et c'est réglé". Et vraiment, je n'ai pas codé à la main depuis la fin de l'été. Donc, ça fait un bon moment. J'ai commencé à programmer quand j'avais 12 ans. C'est donc un sentiment assez étrange d'arriver au point où vous savez que vous n'écrivez plus de code à la main. Et la plupart de ce que je fais est du codage au niveau de la bibliothèque. C'est donc assez bas niveau, généralement des trucs de machinerie de type assez complexes qui nécessitaient auparavant une très bonne compréhension du langage, de la manière dont l'utilisateur interagit avec votre logiciel, etc. sans diminuer en aucune façon le développement de haut niveau, juste que la façon dont vous traitez un langage si vous devez construire une bibliothèque par rapport à la façon dont vous traitez le langage si vous construisez une application par-dessus, est généralement très différente. Parfois, dans le domaine des applications, vous avez les mêmes exigences que dans le domaine des bibliothèques, surtout lorsque vous devez généraliser, abstraire des modèles, les rendre répétables, supprimer la verbosité des répétitions, etc. Il y a donc un croisement, mais j'ai définitivement pensé que l'IA serait plus utile dans le domaine des applications. Et je n'ai pas vu beaucoup d'utilisation au niveau des bibliothèques. Et j'avais complètement tort, car je n'écris pas de code à la main. Je n'ai pas écrit une seule ligne de code à la main depuis un moment. Et je l'ai fait en Typescript. Je l'ai fait en Rust. Et l'élément amusant est que, étant donné que j'écris principalement des bibliothèques, j'interagis généralement avec des bases de code qui n'ont aucune documentation, qui n'ont aucune bonne pratique disponible en ligne. Et donc, je ne pouvais pas vraiment utiliser le truc habituel "ajoutons juste un serveur MCP pour accéder à la documentation" ou espérer que les modèles aient été suffisamment entraînés sur la documentation pour être directement utiles. Et la réalité est qu'avec les LLM, les gens les traitent comme un cerveau humain, mais ils sont très différents. Nous apprenons continuellement. C'est une expérience d'apprentissage. Une fois que nous sortons de cette pièce, j'espère que vous en saurez un peu plus par rapport au point de départ lorsque vous entrez, et votre cerveau continuera à internaliser de plus en plus de modèles au fil du temps. Ensuite, vous allez dormir. Votre cerveau nettoie un peu le désordre des informations non pertinentes que vous avez reçues pendant la journée. Et il y a tout ce processus de transformation de l'expérience. Le mot que nous expérimentons chaque jour en mémoire à long terme avec les LLM. Cela n'arrive pas avec les LLM. Il y a une phase de pré-entraînement où les LLM sont entraînés sur tout le savoir existant dans le monde. Généralement, ils sont entraînés sur tout Internet. Ensuite, ils sont spécialisés dans certaines tâches, puis il y a toute la phase de post-entraînement où les modèles sont affinés pour agir sur des choses spécifiques. Par exemple, les agents de codage sont des modèles génériques qui ont été renforcés, qui ont eu des passes d'apprentissage par renforcement pour opérer sur des bases de code. Toute la phase de post-entraînement d'un grand modèle linguistique dédié au codage consiste à laisser le modèle parcourir des bases de code et à avoir des évaluations qui indiquent à la phase d'entraînement comment le modèle se comporte. Fait-il bien ? Fait-il mal ? Le code compile-t-il après ce changement ? Le code ne compile-t-il pas après ce changement ? Et ainsi de suite. Mais une fois que c'est fait, c'est fait. Il n'y a plus de connaissances qui entrent dans le modèle chaque jour. Donc, si vous interagissez avec un modèle aujourd'hui et que vous lui dites quelque chose et que vous dites : "Hé, je veux que tu fasses ça d'une manière très spécifique. Demain, il ne s'en souviendra pas." Alors, comment le faire se souvenir, c'est la grande question. Et les modèles, vous devez penser que vous leur parlez, mais la réalité est que vous ajoutez essentiellement des messages à un tableau de taille fixe appelé fenêtre de contexte, et la fenêtre de contexte est limitée. Maintenant, il existe des modèles avec une fenêtre de contexte d'un million de tokens, et ce n'est pas nécessairement une bonne idée, car la fenêtre de contexte du modèle est ce qui est envoyé au réseau neuronal, et le réseau neuronal va essayer de prédire ce qui vient ensuite. Donc, si vous envoyez plus d'informations, il y a une très forte chance que vous confondiez le modèle, c'est pourquoi une fenêtre de contexte d'un million de tokens n'est pas nécessairement utile, surtout si vous faites plusieurs choses dans le même contexte. Cela signifie vraiment que nous devons architecturer autour d'un processus de vidage. Nous devons architecturer autour d'une machine qui avait une connaissance d'il y a six mois au mieux, qui ne se souviendra pas de tout, car même si vous avez un trillion de paramètres dans le modèle, ou même si vous avez 10 billions de paramètres dans le modèle, ce n'est pas suffisant pour stocker toute la connaissance humaine. Vous obtiendrez donc toujours une connaissance compressée et, dans le meilleur des cas, vous aurez une certaine capacité de généralisation dans le modèle, de sorte que le modèle puisse dire "hé, je connais AB, peut-être que je peux faire C parce que c'est similaire à A et B", et vous avez une forme de ce comportement émergent et de cette capacité de raisonnement sur de nouveaux problèmes. Mais les modèles sont devenus très bons. Je l'ai dit moi-même, je n'écris plus de code à la main depuis au moins six ou huit mois. Cela signifie que même si la machine est stupide, elle est déjà au point où nous pouvons l'utiliser pour faire du bon travail. Mais comment le faire ? Maintenant, si l'hypothèse est que le modèle a des connaissances obsolètes, nous avons besoin d'un moyen pour que le modèle acquière de nouvelles connaissances. Et nous avons dit que ces modèles que nous utilisons pour le codage ont été renforcés, ont suivi un apprentissage par renforcement pour pouvoir comprendre votre propre base de code, apporter des modifications à votre propre base de code et reproduire les modèles qui existent dans votre propre base de code. Ils n'ont pas vraiment été entraînés à lire la documentation humaine. Ils n'ont pas été entraînés à utiliser un serveur MCP qu'ils n'ont jamais vu. Ils ont été principalement entraînés à consommer et à produire du code. Donc, il y a huit mois, je pensais : et si je donnais simplement au modèle l'accès au code ? Cela signifie que si je veux utiliser l'effet, je vais ajouter le dépôt de l'effet dans mon répertoire, en masquant simplement la base de code de l'effet comme ma propre base de code, et peut-être que je peux tromper le modèle en lui faisant croire que c'est une seule grande base de code et qu'il l'explorerait et l'utiliserait progressivement pour construire les connaissances requises et pour en quelque sorte cloner les modèles. Et il existe diverses façons de le faire. On pourrait soutenir que le modèle a déjà accès au code de la bibliothèque en l'ayant dans npm dans node_modules, mais les agents de codage ont été entraînés à se concentrer sur votre propre code, pas sur le code qui se trouve dans node_modules. Donc, si vous l'avez dans node_modules, le modèle est optimisé. Il ne le regardera pas avec la même fréquence qu'il regarde votre propre code. Si vous l'avez dans un répertoire .gitignore, les modèles ont été entraînés à ne pas regarder les fichiers qui sont ignorés par git. Par exemple, Cursor n'indexe pas les trucs qui sont ignorés par git. Il y a donc toutes ces sortes de restrictions aléatoires que nous découvrons au fur et à mesure du développement. Et la seule façon dont j'ai trouvé que les modèles étaient bons, quelle que soit la langue, quel que soit ce que vous utilisez, c'est si vous clonez simplement le [ __ ] repo, ce qui est le but de ce travail. C'est donc un projet complètement vide. J'ai quelques idées sur la façon dont nous pourrions l'aborder. Mon idée serait de mettre en place un dépôt bun, d'utiliser vest pour les tests, de construire une sorte de serveur HTTP, idéalement en fournissant une documentation OpenAPI pour la consommation, de construire une sorte de client type-safe pour interagir avec le backend. J'espère que si nous avons assez de temps, je ne suis pas sûr, exploiter le monde des workflows et du clustering pour les opérations persistantes dans le backend, et vraiment, je n'ai rien mis en place. Alors, comment je commence habituellement ? Eh bien, j'aimerais que vous commenciez gentiment avec le modèle, mais dès qu'il déraille, vous verrez, je vais commencer à insulter le modèle. C'est amusant parce qu'il ne peut pas vraiment vous répondre. Si vous n'aimez pas la réponse, vous pouvez simplement l'arrêter. Ce n'est pas comme un humain qui se vexe. Peut-être que j'aimerais mettre en place un projet en utilisant le projet devrait également inclure la configuration de Vest et de Typescript check script. J'utilise GPT 5.4. Quand j'ai commencé ce voyage, j'utilisais set 4. Il y a beaucoup de différences entre set 4 et GPT 5.4, à savoir que set 4 donnait l'impression d'un enfant avec un couteau courant dans la maison. C'est un exemple qui vient de Joffrey Huntley, l'auteur de Ralph Loops. Mais même en tant qu'enfant courant dans la maison avec un couteau, c'était suffisant pour coder. Et GP. Maintenant, nous avons des modèles comme Opus 4.5, GPT 5.4 qui sont beaucoup, beaucoup mieux. Mais un élément très intéressant à considérer est que les modèles à poids ouverts prennent du retard de trois à six mois par rapport aux modèles de pointe. Ce qui signifie que nous avons déjà des modèles ouverts qui sont plus intelligents que set 4, que j'utilisais déjà dans le développement de bibliothèques. Combien de temps faudra-t-il pour que ces modèles à poids ouverts deviennent suffisamment bons pour être utilisés dans nos opérations quotidiennes ? Je ne sais pas. C'est juste une pensée que dernièrement j'ai de plus en plus, surtout parce que, eh bien, Anthropic impose des restrictions arbitraires sur la façon dont nous utilisons leurs modèles. Donc, je ne veux pas vraiment utiliser les modèles Anthropic. OpenAI est bon pour l'instant. Qui sait ce qu'ils vont faire dans un an ou deux. Et j'aime l'open source, bien sûr. D'accord. Je n'ai pas de dépôt git créé. Créez un dépôt git vide. Et au fait, si vous avez des questions, si vous voulez m'interrompre, ceci est censé être interactif. Je suis là pour vous divertir pendant encore une heure et demie. Initialisez le dépôt. D'accord, c'est fait. C'est incroyable qu'en utilisant GPT 5.4 avec du code ouvert, il crée par défaut un code MD, je pense, comme ceci, c'est de bun, oui, jetons ça. >> Absolument, n'a rien à voir avec ça. Stratégie marketing parfaite, en plus ils ont dit que ce n'était pas un vrai fool et deux jours après ils ont annoncé MAS comme nouveau modèle. D'accord. Je crée un répertoire source et test. Voyons ce qu'il a créé. D'accord. Types, mode bundler bun, pas d'émission. C'est bien. Strict, skip lib check. C'est bien. Override implicite. C'est bien. Oui. Déplacez également les fichiers dans le répertoire approprié. Déplacement du fichier d'entrée. Bien. Semble assez intelligent. Exécute un test de fumée basique. D'accord. D'accord. Donc, c'est un bon point de départ. Nous avons vérifié avec bun run test, bun run type check. Bien. Euh, nous voulons ajouter effect beta. Nous allons utiliser effect v4. Il n'est pas encore sorti pour une utilisation en production, sauf qu'il l'utilise déjà en production. Donc, si j'ai un problème, je vais vous demander. C'est bon. >> Oui, c'est effect small. >> Petit parce qu'il était petit et a évolué pour devenir plus grand. Toujours très euh, très léger en taille de bundle. D'accord, 1% 14k. Il reste beaucoup de contexte. Euh, nous voulons ajouter effect beta et nous voulons utiliser effect test pour écrire les tests. Je le ferai. Je le ferai. C'est la suite. C'est la suite. Et à ce propos, je veux essayer d'utiliser la version TSGO. Maintenant, je n'ai jamais utilisé ça. Alors, qu'est-ce que je n'ai pas utilisé, je ne sais pas comment l'utiliser. Configurons le compilateur comme vérificateur de type, lisons le README et configurons-le. Je ne suis pas sûr que cela fonctionne ou non. >> Oh, le compilateur de base réel. Oui. Je ne sais pas si Matia l'a autorisé. >> Oui, ça le fait. Le fait est qu'il ne l'utilise pas et nous pourrions simplement faire une installation alias. Donc, installer typescript comme autre chose, mais je ne suis pas sûr s'il l'a fait. Peut-être suivons la pratique normale. Installons TypeScript Go au lieu de TypeScript. Sera-t-il capable de faire ça ? Qui sait. Nous le découvrirons. >> Nous le découvrirons. Est-ce le paquet ? Non, je ne pense pas que ce soit le paquet. Je pense qu'ils m'ont juste volé mon portefeuille crypto. Sauf que je n'en ai pas. Alors, vérifiez d'ici. Oh, le nom du paquet npm TypeScript Go n'est qu'un espace réservé pour un paquet de sécurité. Donc, j'utilise le vrai compilateur preview qui fournit le binaire TSGO. Eh bien, c'était probablement une bonne idée. Euh, script ts go no emit. Voyons bun exact go. D'accord. D'accord. Vérification de type. Vérification de type. D'accord. Configurer VS Code pour utiliser TSGO. VS GO LSP fonctionnera peut-être. Oui, j'en ai besoin. Voilà. Aperçu natif. C'est ça. D'accord, je l'ai installé. Je vais probablement devoir recharger la fenêtre. Allons-y. D'accord, peut-être que ça a marché. Alors, allons ici. Et oui, je devrais être capable de faire ça. Mais il y a aussi un joli message qui ne sera pas chargé si des fichiers sont spécifiés. Configuration de la ligne de commande pour ignorer cette erreur. Ce que je vais lui donner à l'agent dans une minute. C'est bun qui pose problème, probablement. Peut-être pas. Oui, c'est bun. Alors, laissez-moi arrêter ça. euh, sélectionnez la configuration TS pour configurer celle-ci. L'autre est un package.json installant les dépendances de développement. Sélectionnez tout. Qu'est-ce que c'est ? C'est VS Code. C'est bon. Cela nécessite beaucoup de travail. Avons-nous le motif d'effet installé ? Oh, mon Dieu. D'où vient ceci ? Qui sait. D'accord. D'accord. D'accord. Un. Installer. D'accord. C'est installé. Voyons s'il attrape quelque chose. Importer. de effect 100. Non, c'est un effet pendant. Je pense que je l'ai fait. Vous voulez dire celui de préparation ? >> Oui, je l'ai fait. Euh, peut-être que je dois recharger. Recharger après ça. Oui, c'était facile. La solution Windows vient de redémarrer. D'accord, nous l'avons. Euh, et maintenant maintenant nous voulons, nous avons une certaine gravité de diagnostic à suggestion, avertissement, etc. Pour l'IA, nous aimerions tout transformer en erreur afin que le LLM ne puisse pas passer, ne puisse pas accepter de code qui ait la moindre ressemblance avec une erreur. C'est donc un projet où nous utiliserons beaucoup l'IA. Nous voulons que tous les diagnostics disponibles soient définis sur erreur. Je devrais passer de Qu'est-ce que le modèle fait ? A-t-il mis à jour la configuration TS ? Il ne l'a pas fait. Oh, je mets à jour la configuration TS. D'accord. Non, non, non. Euh, et c'est un autre point intéressant. Euh, les solutions d'effet. Euh, il y a un site web appelé effect.solutions. C'est un très beau site web. Euh, Kit Langton l'a fait et c'est une sorte de démarrage rapide pour utiliser l'effet dans un projet d'IA et il installe le service de langage et les politiques strictes par défaut, etc. Mais ensuite, il utilise une CLI pour donner au modèle l'accès au dépôt d'effet et le modèle doit savoir comment utiliser la CLI. C'est donc une sorte de chien qui se mord la queue. >> Oui. Oui, mais >> il y a des fichiers markdown, >> mais ça ne marche pas aussi bien. Et si vous lisez en fait à un moment donné, il dit que vous devriez en fait simplement cloner le dépôt. D'accord, cela ressemble exactement à ce que j'avais en tête. Donc, nous avons tous les diagnostics définis sur erreur. Ce qui est bien. C'est exactement ce que nous voulons. Charger la fenêtre. D'accord. Je veux aussi formater à la sauvegarde sur vrai juste parce que c'est ennuyeux autrement. D'accord. Très bon point. Euh, commiter le commit actuel. Maintenant, je veux ajouter effect comme sous-arbre. D'accord, c'est commité. Bien. Maintenant, créez un dossier .repos et ajoutez-le comme sous-arbre git sans historique, écrasé, dans repos/effect. Qui sait si ça va marcher. Au moins, ça l'a fait. D'accord, ici. Pourquoi essaie-t-il de ? D'accord. D'accord, nous l'avons. Vérifions juste git log. Yep, il a audité. D'accord. Et maintenant, nous sommes au point où nous pouvons commencer notre recherche. Par exemple, nous avons dit que nous voulons créer une API HTTP. Je vais nettoyer ceci. Ouvrir une nouvelle session pour éviter la pollution du contexte. Vous avez accès au dépôt d'effet dans repos. En fait, faisons autre chose avant. Nous voulons configurer un agents.md. Configurer un agents.md listant les commandes disponibles comme one run type check et spécifier que vous avez accès au dépôt d'effet dans repos/effect et que vous devriez l'utiliser pour extraire les meilleures pratiques. Regardez comment les choses fonctionnent, etc. Maintenant, le agents.md. Maintenant, nous allons obtenir un prototype initial. Au fur et à mesure que vous travaillez sur le projet, vous allez l'améliorer, vous allez ajouter plus de commandes, vous allez ajouter des règles lorsque vous constatez que des mauvais modèles sont créés dans le code. Une chose que nous n'avons pas encore configurée, c'est un linter. Un linter sera un élément essentiel de la boucle de contre-pression qui aide le modèle à aller dans la bonne direction. Si vous voulez une configuration entièrement fonctionnelle, j'ai un dépôt qui m'appartient et que j'utilise pour le plaisir, qui s'appelle accountability. Dans ce dépôt, vous pouvez trouver beaucoup de choses, mais par exemple, j'ai une configuration ESLint avec beaucoup de règles personnalisées, et celles-ci sont arbitraires. Par exemple, je ne veux pas que le modèle fasse une assertion de type explicite sur les choses. Je veux que le modèle utilise des schémas pour vérifier la forme. J'ai des règles interdisant l'utilisation de x as z. J'ai des règles interdisant l'utilisation de any ou unknown. Essentiellement, j'essaie d'éviter que le modèle fasse des trucs stupides que j'ai réalisé qu'il faisait dans mon code. >> Non. >> Oui. Pareil pour unknown. >> Et le truc amusant est qu'au début, j'ai interdit unknown parce que je voulais que le modèle ne fasse pas as unknown as x. Il a découvert que never est un type bottom. Donc, vous pouvez faire as never as x. J'ai dit, d'accord, alors je vais interdire as et maintenant ça va mieux. Euh, d'accord, voyons ce qu'il a créé. D'accord, c'est court. Utiliser bun. D'accord. Commandes de projet disponibles. C'est bon. Test watch, cela va créer des problèmes. Je le sais déjà parce que le modèle va essayer de l'exécuter et de se bloquer. Idem pour les serveurs de développement. Dépôts de référence d'effet. Bien. Regardez pour des conseils spécifiques. D'accord, c'est suffisant pour commencer. Mentionnez dans le agents.md que vous ne devriez jamais essayer d'exécuter des commandes en mode watch. Par exemple, vous n'êtes pas autorisé à exécuter ou un serveur de développement. Sinon, il va essayer d'exécuter le serveur de développement comme première chose et se bloquer. D'accord. Ce que j'aime dans les modèles OpenAI, c'est qu'ils sont beaucoup plus concis par rapport aux modèles Anthropic. La même tâche avec Opus aurait probablement écrit 200 lignes de agents.md, mais c'est bien. C'est suffisant pour commencer. Donc, nous sommes de retour à la case départ. Nous avons dit que nous voulions créer une API HTTP. Je ne connais rien à l'effet. Donc, j'aimerais créer une API HTTP qui devrait avoir une documentation OpenAPI et un client type-safe généré par défaut. Explorez le dépôt d'effet pour trouver des modèles pour faire cela. Enregistrez votre recherche dans patterns/http-api.md. Posez-moi toutes les questions dont vous avez besoin. Encore une fois, je pars du principe que je n'ai aucune idée de comment faire cela dans l'effet. >> Non, je trouve le mode plan comme ça. Le problème avec le mode plan est que le modèle a un accès limité aux outils. Donc, il ne peut pas facilement faire les mêmes choses qu'il fait en dehors du mode plan. Donc, je ne l'utilise pas beaucoup. Je fais généralement ce qu'on appelle le développement piloté par spécifications, dans le sens où la première tâche que je fais avec le modèle est de discuter avec le modèle de la façon de créer une spécification pour quelque chose, puis la spécification est conservée sous forme de fichier markdown, qui est effectivement mon plan, et je dis ensuite au modèle de l'implémenter. Généralement, la deuxième étape que je fais dans une boucle Ralph, car vous avez vu, j'ai déjà redémarré Open Code plusieurs fois pour nettoyer la fenêtre de contexte. Faire cela manuellement est ennuyeux et vous finissez généralement par réutiliser la même fenêtre de contexte pour plusieurs choses et cela va simplement dégrader les performances du modèle à un moment donné, car la fenêtre de contexte est limitée. Vous allez y mettre beaucoup d'informations et les informations antérieures vont confondre le modèle pour les informations ultérieures. Donc, j'utilise un script bash très simple qui dit au modèle : prenez une petite tâche, implémentez la petite tâche, puis quittez, et je l'exécute en boucle. Il est amusant de constater qu'avec l'IA, souvent moins c'est plus. Vous pouvez avoir des architectures très complexes autour de la gestion du contexte, etc. Au final, la chose la plus stupide fonctionne mieux. Et nous faisons des recherches par nous-mêmes, et il semble qu'il y ait en fait de très bonnes marges d'amélioration en réduisant le nombre d'outils auxquels le modèle a accès. Par exemple, nous avons expérimenté avec un agent de codage qui a un seul appel d'outil appelé "execute" et il peut exécuter du code TypeScript arbitraire, y compris appeler bash via TypeScript. Et dans ce scénario, le modèle n'a même pas accès à bash. Il ne peut pas modifier les fichiers directement. Il doit écrire un fichier TypeScript qui modifie le code, puis il finit par faire des transformations basées sur des transformateurs TypeScript. C'est fantastique de voir comment vous réduisez les choses que le modèle peut faire et il fait mieux. Alors, voyons, enregistrez la recherche dans http-api.md. Bien. Conclusion principale pour ce dépôt : le modèle d'effet par défaut le plus solide est de définir l'API HTTP partagée. Vous avez absolument raison. Dériver OpenAPI à partir de celle-ci. Monter la documentation. D'accord. Générateur OpenAPI uniquement lorsque vous avez besoin d'un artefact client généré. Nous n'en avons pas besoin. Une question avant d'implémenter quoi que ce soit d'autre. Voulez-vous que le modèle principal ici soit une API HTTP partagée avec un client API HTTP fabriqué ? Non, je suis satisfait d'une API HTTP partagée. Je n'ai pas besoin d'un client commité dans le dépôt lui-même. Voyons ce qu'il a fait ici pour ce dépôt d'atelier. La meilleure partie. D'accord, cela vous donne des fichiers en amont pertinents. Bien. Il regarde les tests. Bien. D'accord, cela ressemble à un résultat décent. Nous devrions probablement lui dire ce que nous voulons faire. Mais ce ne sont que des modèles génériques que nous utiliserons comme référence. Donc, listez les fichiers dans patterns dans le agents.md. Ainsi, l'agent a connaissance de leur existence. Le modèle ne se soucie pas de la grammaire. Et j'ai l'impression que beaucoup de gens soulignent qu'un modèle n'est pas bon à quelque chose s'il ne fait pas bien par défaut. Je ne pense pas qu'il y ait quoi que ce soit de plus faux dans cette déclaration. Le modèle est bon lorsqu'il peut opérer sur une base de code à grande échelle en utilisant des modèles et qu'il ne échoue pas à l'échelle. Le problème du zéro à un n'est pas vraiment un problème pour les 10 premiers jours ou les 10 heures, selon ce que vous construisez. Et en tant que programmeurs, si notre travail n'est pas d'écrire du code, notre travail devrait être de configurer les dépôts de manière à ce que les modèles puissent agir correctement. Donc, ce que je fais maintenant, c'est que la plupart de ce que je fais lorsque j'opère un agent de codage à grande échelle dans une base de code, même si la base de code n'a aucun concept d'IA, comme si je commence dans un projet qui est une base de code existante de cinq à dix ans, sans contexte, la première chose que je fais est de laisser le modèle explorer le code, cloner les principales bibliothèques utilisées. Si vous utilisez un framework comme tanstack ou similaire, clonez le code de tanstack router. Si vous utilisez svelte, clonez la base de code svelte. Demandez au modèle de générer des fichiers de bonnes pratiques, etc. Une fois que vous avez tout cela, le modèle sera beaucoup plus efficace. Donc, maintenant que nous avons un peu de contexte sur les API HTTP, nous pouvons commencer à en implémenter une. Je veux vérifier quelque chose rapidement parce que j'utilise bun et j'utilise vest. Il y a un vest run. Est-ce que vest run utilise bun comme runtime ou utilise-t-il node ? Parce que si je me souviens bien, il y avait une balise que je devais passer à vitest pour lui faire utiliser bun, et je ne veux pas que notre configuration de test diffère de notre euh, qu'est-ce qu'il fait ? Euh, non, ajoutez à vitest qu'il doit ignorer tout ce qui se trouve dans repos. Il exécutait les tests d'effet qu'il trouvait. Oui, il n'y avait aucune configuration vitest. Bien. Ajoutez aux tests quelque chose qui utilise une API bun. J'ai l'impression de l'avoir fait ici. Donc, je devrais avoir ceci. D'accord. Utilisais-je node ? Probablement, vous devriez vous attendre à ce qu'il soit défini parce que maintenant nous avons fait une des erreurs SQL. Il a fallu faire passer le test. Il a modifié le test pour le faire passer. Wow. D'accord. D'accord, il l'a fait. Commençons maintenant notre implémentation d'API HTTP. Donc, nous voulons implémenter une API HTTP en suivant les modèles à patterns/http-api.md. Nous voulons que l'API euh, expose une fonctionnalité de todo où vous pouvez un, créer des todos (description, titre, description), deux, mettre à jour des todos (changer le titre, etc.), trois, marquer un todo comme fait ou non, quatre, lister les todos. Euh, j'aurais dû faire autre chose. Discutez du plan avec moi et créez un plan dans api.md. Ici, je dis à l'LLM de lire le fichier de modèles que nous avons créé auparavant, où il rassemblera des connaissances générales sur les façons de faire les choses dans l'effet. Il a toujours accès à la base de code originale de l'effet s'il le souhaite. Mais maintenant, je crée un plan spécifique pour implémenter l'API que je voudrais euh, que je voudrais implémenter. Rédaction du plan. D'accord. Pour enregistrer. C'est bon. Stratégie de stockage initiale. Faisons quelque chose de différent pour le stockage. Utiliser effect-sql et euh, un magasin SQLite. Explorez le dépôt d'effet pour savoir comment faire cela. Et créez des modèles dans patterns/sql.md. Je réalise que j'ai besoin d'une stratégie de persistance et je n'ai pas de stratégie de persistance. Je sais que l'effet a quelque chose de SQL et encore une fois, j'utilise le même processus où je génère d'abord des modèles pour cela. Et c'est aussi utile parce que vous pourriez vouloir utiliser quelque chose de l'effet, mais vous pourriez ne pas vouloir tout utiliser de l'effet. Donc, si nous devions pousser tous les modèles dans votre dépôt par défaut, vous finiriez par utiliser tout de l'effet, même si vous ne le voulez pas. C'est une sorte de sélection personnelle. Donc, vous pouvez choisir ce que vous voulez utiliser. Surtout dans les projets brownfield. C'est très important parce que vous ne voulez pas refactoriser tout ce que vous avez déjà. Par exemple, ici, j'aurais pu choisir diesel pour faire la persistance tout aussi bien. Le plus probable est que nous allons développer une sorte de CLI où vous pouvez pré-télécharger certains modèles qui sont déjà disponibles et vous laisser toujours choisir. Et nous voulons également automatiser ce type de processus d'exploration de quelque chose, de création de modèles à partir de cela, car les modèles que nous avons comme bonnes pratiques pourraient ne pas correspondre exactement à vos besoins. Donc, vous les mettriez toujours à jour comme une deuxième étape. Le modèle que j'utilise n'est peut-être pas aussi bon que celui que, par exemple, comme les PR que vous lisez et certains d'entre eux sont juste comme ça, et les auteurs de bibliothèques génèrent tout, pas comme des compétences comme le logiciel, mais ce genre de modèle est comme effect.solutions mais officiellement distribué par le paquet colocalisé. >> Je pense que c'est généralement une bonne idée, mais il y a quelques mises en garde. Par exemple, même la norme agents.md n'est pas vraiment une norme parce que la façon dont vous invitez Cloud et la façon dont vous invitez GPT est différente. Par exemple, vous avez remarqué que je n'ai jamais écrit en majuscules. Si j'utilisais du code, j'écrirais beaucoup de choses en majuscules. La raison est que GPT a peur si vous lui criez dessus. Je ne sais même pas comment appeler le modèle. Et si vous lui criez dessus, il va se dégrader et devenir passif et tout accepter. Ce n'est pas ce que vous voulez. Avec le code, si vous lui criez dessus, il va prêter attention à cette phrase spécifique. Donc, cela s'applique également à ces modèles partagés. J'ai l'impression que les modèles devraient être presque générés avec le modèle que vous utilisez plutôt que d'être prêts à l'emploi. Maintenant, nous pouvons le faire pour les trois principaux modèles de pointe. Toute la famille GPT est très similaire. 5.3, 5.4, 4 5.2, il n'y a pas tant de différences. Opus, set et Haiku sont également très similaires. Idéalement, nous pouvons avoir la CLI où elle dit quel modèle utilisez-vous ? D'accord, je vais optimiser le contexte pour ceci par rapport au contexte pour cela, et c'est ennuyeux parce que vous aimeriez évidemment avoir une norme. >> J'aimerais bien maintenir ça. >> Oui. Oui, c'est très pénible de maintenir ces choses. Notre approche est de rendre le code aussi bon et auto-explicatif que possible avec des exemples et tout, de sorte que n'importe quel modèle que vous utilisez puisse les générer, puis la CLI les générera sur place. >> Pour le modèle que vous utilisez. C'est une approche. Cela peut échouer et dans six mois, nous fournissons des modèles pour tout et vous disons simplement, veuillez en utiliser un ou deux. Un autre argument très intéressant est de fine-tuner un modèle open source pour utiliser les modèles d'effet par défaut. Nous y avons pensé. >> Genre, d'accord, voyons, mettons à jour v htt. Non, si vous voulez la prochaine étape pour que je mette à jour, oui, faites-le. C'est la partie ennuyeuse des modèles GPT. Ils demanderont constamment votre avis pour continuer. Opus l'aurait simplement fait. >> Mais parfois mal, et vous devez le faire trois fois votre session. >> C'est pourquoi j'utilise GPT 5.4. Eh bien, j'aimerais une sorte de fusion, vous savez, une fusion consanguine de modèles Anthropic et OpenAI, de sorte qu'il ne me demande pas tout le temps, car GPT prend généralement, surtout dans les tâches complexes, son temps, mais à la fin, le résultat est bon. Avec Opus, c'est juste. Parfois, il aime prendre des raccourcis. Et le truc amusant est que si vous laissez l'un dormir, il va se répéter, comme si vous laissiez n'importe quoi dormir dans votre base de code, et si vous avez Opus, il fera comme n'importe quoi tout le temps. C'est comme, oh, je ne peux pas faire ça. Laissez-moi faire ça pour tout. J'ai besoin que cela compile. Supprimons le code. >> Oui. C'est pourquoi dans ce projet et dans accountability, j'utilisais ous et j'ai un fichier de lint de milliers de lignes de code pour interdire tout raccourci. Je peux commencer à implémenter ça ensuite. Oui, s'il vous plaît, nous avons passé assez de temps et voyons ce qu'il fait. Regardez, il recherche correctement dans le dépôt d'effet, dans la documentation IA, des idées. Il est très probable que cela prenne un peu de temps, ce qui est positif. >> Genre, dans certains projets, il utilisait le schéma par défaut et je n'avais pas besoin de beaucoup de contre-pression. Parfois oui, un exemple est la règle dans accountability, j'ai cette règle de lint SQL personnalisée pour interdire le type SQL parce qu'il écrivait une requête SQL. Il écrivait une interface et il faisait juste, c'est exactement la même chose que le casting, et j'ai dû interdire complètement ce modèle et utiliser des paramètres de type avec des littéraux de modèle SQL ne fournit aucune validation d'exécution. Utilisez le schéma SQL. Trouvez-en un. Et vous voyez que la règle suggère finalement d'utiliser le schéma SQL. Donc, je regarde plus ou moins ce que le modèle produit, et s'il y a quelque chose que je n'aime pas, j'écris des règles de lint pour interdire ce modèle spécifique. Par exemple, dans le schéma, il arriverait souvent, par exemple, qu'il y ait un ID utilisateur comme chaîne, puis qu'il y ait un autre ID comme chaîne, et vous n'auriez bien sûr aucune sécurité de type et le code essaierait de passer l'un dans l'autre. J'ai donc forcé tous les identifiants à être des types marqués et j'ai interdit l'utilisation de type casting, sinon il ferait comme "cela nécessite un ID utilisateur, laissez-moi faire en tant qu'ID utilisateur" et c'est comme oui, c'est inutile, vous devez valider les données. J'ai donc interdit l'utilisation de "as" et je les ai forcés à utiliser des constructeurs. Donc, au lieu de faire "100 as user ID", "user ID.make" ou interdire l'utilisation de constructeurs dans des endroits où vous devriez faire une validation, par exemple, un cas où cela s'est produit, c'est qu'il faisait la couche API comme des chaînes de caractères simples, puis utilisait des constructeurs dans le gestionnaire pour créer les objets, ce qui annulait le but. Ensuite, j'écrirais des règles pour que le modèle écrive la validation directement dans les schémas. Donc, je disais essentiellement que si vous utilisez un constructeur dans le gestionnaire, il est très probable que vous ayez tort. Vous devriez améliorer le schéma de départ pour fournir la validation à la périphérie. C'est un peu comme surveiller un développeur junior avec un couteau courant dans la cuisine au lieu d'un enfant courant dans la cuisine avec un couteau. Et cela continue. Les deux modèles sont exceptionnels. Parfois, un modèle vous rend fou et vous essayez l'autre. Il n'y a pas beaucoup de règles. Dernièrement, j'ai tendance à utiliser davantage les modèles OpenAI parce que je n'aime pas vraiment être limité sur le matériel que je peux utiliser. La CLI elle-même. Je veux utiliser Open Code. Je veux utiliser mes propres fichiers TypeScript qui interagissent nativement avec le SDK d'IA, et Anthropic me l'interdit. Donc, jusqu'à il y a quelques mois, lorsque cela était autorisé, j'utilisais principalement Opus. Lorsqu'ils ont appliqué leurs politiques contre le code ouvert, je suis passé aux modèles OpenAI et maintenant j'utilise la plupart du temps des modèles OpenAI. Il y a quelques petits cas limites, par exemple, lorsque vous faites de l'interface utilisateur, Opus est bien meilleur que Codex. Donc, pour certaines choses spécifiques, l'un est clairement meilleur que l'autre, mais pour la plupart des tâches, ils sont les mêmes. J'ai eu une expérience, par exemple, où GPT a réfléchi pendant une demi-journée à un bug que j'avais et n'est allé nulle part, et Opus a trouvé la solution en une seule fois, mais j'ai eu l'expérience inverse aussi. Il est donc très difficile de savoir lequel est lequel. D'accord, voyons ce qu'il crée. Euh, d'accord, il a créé un client SQL. La couche semble correcte. Euh, elle a des migrations. Il a décidé d'intégrer les migrations. D'accord, c'est un choix valide. D'accord, il a correctement fourni la couche SQL live aux couches de migration. Cela semble dupliqué. Il y a une duplication claire entre j'ai utilisé pour cela, en le créant. Il est également disponible, parfois refactorisé, et il laisse du code en place et il n'est jamais exporté dans les mêmes blocs. >> D'accord, bon à savoir. Euh, nous sommes dans notre expérimentation. Une autre chose que nous faisons, c'est que nous utilisons la recherche sémantique de code >> parce que nous avons remarqué que très souvent le modèle réimplémente les mêmes fonctionnalités parce qu'il ne les trouve pas. >> Et avec la recherche sémantique de code, il les trouve. Eh bien, d'accord, il y a une duplication ici. Je vais probablement lui dire qu'il y a une duplication à un moment donné. Je veux vérifier l'API. Exactement. Vous voyez, il utilise des chaînes de caractères simples pour les identifiants. Donc, une des choses futures que nous pourrions vouloir faire est de lui dire d'utiliser des types marqués. D'accord. D'accord. Pour ne pas trouver, il a ajouté une notation de schéma pour marquer que "todo not found" devrait être un 404. Cela semble décent. Euh, je ne comprends pas pourquoi il crée parfois des strrus au lieu de classes. Je préfère personnellement utiliser des classes. Donc, à l'avenir, je créerais soit une bonne pratique pour préférer les classes, soit, selon la rigueur que je veux, je créerais une règle de lint pour interdire l'utilisation de schema.struct dans des fichiers spécifiques et ce genre de choses. Pour l'instant, c'est évidemment bien. Il n'en a pas besoin. Je ne suis pas sûr. Il pourrait y en avoir, mais il ne signale rien ici. Donc, et le LSP est activé. Linter tous les fichiers, linter avec quoi ? Nous n'avons pas de linter en place. Bon point. Nous n'avons pas non plus de formateur en place. Ignorons pour l'instant. Voyons. D'accord. Client avec une URL de base. C'est bien. Nous avons le gestionnaire live. L'index du serveur exporte juste tout. L'index.ts devrait probablement exécuter le serveur au lieu d'exporter tout. Faites cette vérification conditionnelle que le fichier est principal. Donc, il ne s'exécute pas lorsque vous importez le fichier. J'ai également créé quelques tests. Quoi ? Qu'est-ce qu'il fait ici ? Il a créé un arbitraire avec HTTP pour exécuter un test HTTP live d'effet. D'accord, c'est une façon. Les tests passent-ils réellement ? Allez. Exécutez les tests. Je serais surpris. Wow. Euh, y a-t-il une commande de démarrage ? Ajoutez une commande de démarrage pour démarrer le serveur API et dites-moi où trouver la documentation OpenAPI. D'accord, il aime vraiment ce modèle. Comme chose future, je lui dirais probablement d'utiliser la couche de couche au lieu d'utiliser le dépôt et la chose de couche. Mais voyons si au moins ça marche. One run start. Bien. Lister les todos. Vérifions l'OpenAPI. Bien. Il y a une OpenAPI. Créée. Cela semble décent pour un début. Choisissez correctement les schémas. Bien. D'accord, alors laissez-moi. Il a créé une base de données ici. Laissez-moi peut-être ignorer la base de données complète pour les todos. Vous avez raison. Oui, je ne suis plus capable d'écrire quoi que ce soit à la main. Oui. D'accord, nettoyons un peu les tests. Donc, nettoyer. Vous voyez, je me mens à moi-même en voulant utiliser la même session encore et encore. C'est là que les boucles Ralph sont vraiment utiles. Nous avons créé beaucoup de désordre. Vous avez créé beaucoup de désordre dans les tests. Nettoyez tout. Ce devrait être le code le plus propre que vous ayez jamais vu. Pas comme le code Python merdique sur lequel vous avez été entraîné. N'utilisez pas de modèles comme utilisez simplement la couche de couche et mettez les utilitaires dans leur propre dossier. Aucune offense aux développeurs Python, bien sûr. >> Probablement. Maintenant, maintenant, je me débrouille. Je vais voir s'il est capable de le faire. Euh, s'il le fait, une fois que ce sera fait, je créerai un modèle à partir de cela. Mais oui, cela aurait été une bonne idée. C'est pourquoi l'automatisation du processus est très importante parce que nous sommes paresseux. Comme maintenant, j'étais tellement paresseux que je ne voulais pas créer de modèle pour cela. Peut-être que j'utiliserai des couches de test. Peut-être. Peut-être. Oh, le mauvais modèle. >> Il a essentiellement créé une fonction pour fournir une couche à un effet. Il a construit la couche manuellement. Il a tout enveloppé dans effect.scoped, ce qui va fermer la couche une fois que ce sera fait. Et ma supposition est qu'il a fait cela parce que ce modèle est en fait utilisé pour tester certains internes de couche dans la base de code. Mais c'est complètement inutile ici. Mais si vous regardez le fichier, même sans connaître les détails de l'effet, ça sent mauvais. Quelque chose ne va pas. Maintenant, il l'a nettoyé. Donc, quand vous voyez quelque chose qui ne va pas, demandez simplement au modèle pourquoi vous avez fait ça, y a-t-il une alternative ? Et dans ce cas, je savais que pour fournir une couche dans un test, il fallait juste utiliser la couche de couche. Donc, j'ai un peu sauté ça, mais en réalité, j'aurais, si je ne l'avais pas remarqué, discuté avec le modèle que je n'aimais pas voir cette chose répétée partout. Et parfois, c'est nécessaire. Parfois, vous avez tort et le modèle a raison. C'est comme ça qu'il faut faire. Dans ce cas, c'était complètement inutile. >> Non, je pense que nous l'avons. Faites-le. Vous feriez la couche de couche comme chose principale, passez la couche comme couche, puis dans la fermeture, faites-le. Décrivez. Décrivez pourrait probablement aussi ajouter un describe comme raccourci. Les modèles ne se soucient pas du code verbeux. Pourquoi devrions-nous le rendre moins verbeux ? >> Fait-il des nettoyages ? >> Oui. >> Oui. Oui, mais vous pouvez le faire par test. Maintenant, cela empoisonne les autres tests. >> L'autre alternative est de fournir la couche à chaque test. La réalité est que chaque fois que vous utilisez une base de données, dans ce cas, c'est SQLite. Donc, l'argument est discutable. Mais si j'utilisais un PostgreSQL dans un projet où vous avez des centaines de fichiers, des centaines de tests, lancer une instance PostgreSQL par test prendrait peut-être deux jours. Donc, généralement, ce que je finis par faire, c'est de faire des tests qui peuvent s'exécuter, qui font un auto-nettoyage. Comme par exemple, j'exécute un test dans une transaction et j'annule la transaction dès que le test est terminé, de sorte qu'ils soient en quelque sorte atomiques par le fait qu'ils ne fuient pas. Ce serait un autre modèle que nous pourrions dire au modèle de faire. Ce serait une question de créer la transaction et l'annulation. Mais il y a des alternatives et >> bibliothèque. >> Non, nous avons ajouté la base de code d'effet dans un dossier de dépôt. Nous avons créé un agents.md qui fait référence au dépôt d'effet, puis pour les fonctionnalités que nous voulions utiliser, nous avons demandé au modèle de créer des modèles en regardant le dépôt, en enquêtant sur la façon dont les choses sont faites dans le dépôt comme connaissances générales. Dans ce cas, nous en avons fait un pour SQL, nous en avons fait un pour l'API. Maintenant, le bon point est que dans cette session, nous avons des bonnes pratiques pour les tests. Créons donc patterns/testing.md. Il devrait inclure toutes les bonnes pratiques pour tester le code basé sur l'effet, y compris l'utilisation de la couche de couche, etc. Je vais également mettre à jour, je vais mettre en file d'attente le agents.md pour faire référence à tous les modèles dans do patterns, et la prochaine chose que vous feriez pour automatiser le flux est, par exemple, Open Code vous permet de créer des commandes slash. Code permet de faire la même chose. Vous optimisez pour /new pattern, peu importe ce que vous voulez, et euh >> vous pouvez créer des compétences et taguer les compétences. Les compétences sont très utiles pour ce genre de choses. Je suis un peu contre les compétences en général, pas pour ces choses, elles sont idéales, mais beaucoup de gens pensent qu'en ajoutant simplement une compétence, vous allez rendre le modèle bon en React, vous allez rendre le modèle bon en Next.js. La réalité est que si vous mettez une compétence pour chaque interne de Next.js, vous allez polluer le contexte et n'arriver nulle part. Donc, les compétences ont un très bon cas d'utilisation, qui est ce genre de cas d'utilisation, et je suppose qu'elles sont plus générales que les commandes slash. Donc, j'ai tendance à faire des commandes slash parce que j'ai tendance à utiliser un seul agent de codage. Mais certainement si vous êtes, par exemple, dans une équipe où tout le monde est libre d'utiliser son propre agent, peut-être que certaines personnes utilisent Cursor, certaines personnes utilisent Open Code, certaines personnes utilisent Code, les compétences sont une bonne base. Voyons, patterns/testing. Utilisez effect test pour tous les tests basés sur l'effet. Utilisez la couche de couche d'effet. Évitez les wrappers personnalisés qui appellent layer.build. C'est une règle très spécifique. Maintenant, un ami m'a dit, chaque fois que vous lisez un livre de règles, un livre de règles juridiques ou que vous trouvez ces règles spécifiques qui sont comme lorsque vous entrez dans un pub et qu'il est dit "ne faites pas de skateboard dessus" et que vous vous demandez, pourquoi cette règle existe-t-elle ? Parce que quelqu'un l'a fait. Pourquoi cette règle existe-t-elle ? Parce que le modèle l'a fait. Pourquoi ce modèle ? D'accord, vous voyez les fichiers pertinents. Ils sont tous liés. >> Oui. Et il y a un ami qui écrit un plugin linter qui vérifie les références existantes. Donc, lorsque vous ajoutez, lorsque vous modifiez du code, il s'exécute dans le CI et dit "hé, cette référence est cassée". >> Oui. >> Oui. >> Le fullome / whatever. Oui. Oui. Comment écririez-vous un test pour un modèle ? >> Vous voulez dire écrire un fichier ? J'ai l'impression que cela pourrait être une façon. Parfois, le code qui se trouve dans les modèles n'est pas vraiment exécutable. Je suppose que cela a des avantages et des inconvénients. C'est certainement une idée intéressante. Par exemple, peut-être avec

avec une balise supplémentaire comme TS exécutez ceux-ci pour marquer quels modèles vous souhaitez réellement exécuter ou comme références quels fichiers vous souhaitez référencer car parfois il mentionne des fichiers comme exemples. Par exemple, si vous écrivez cette fonctionnalité utilise un fichier appelé ABC et ce n'est pas une référence concrète. Donc vous ne voulez pas que votre programme échoue parce qu'il a lu cela. C'est plus dans la direction des évaluations. Donc ça évolue. >> Oui, c'est à grande échelle. C'est très bien. J'ai trouvé que le faire sur une base par projet se termine >> plus. Ce que nous pensons faire dans le dépôt d'effet est par exemple d'avoir des évolutions qui s'exécutent une fois par jour et génèrent des rapports. Ainsi, chaque fois que nous apportons des modifications à la bibliothèque ou que nous ajoutons plus de documentation, nous ajoutons plus d'exemples, nous voyons exactement si les résultats sont meilleurs ou moins bons. Parfois, dans les évolutions, c'est très difficile, même Anthropic il y a quelque temps a écrit un article de blog où le résumé de l'article de blog est que nous ne savons pas vraiment quand le code est bon ou mauvais car le code est-il meilleur ? Cela dépend. Le code plus verbeux est-il meilleur ? Cela dépend. Il y a certaines propriétés où vous pouvez dire que c'est définitivement mieux que pas. Comme le code qui vérifie les types est meilleur que le code qui ne le fait pas. Probablement vrai. Mais quand il s'agit de style, quand il s'agit de savoir si cette structure de fichier est meilleure qu'une autre structure de fichier et qu'elles transmettent toutes deux un sens, vous avez besoin d'un humain à la fin pour dire : "Ouais, je préfère ça." Et si vous prenez 100 humains, vous aurez une répartition 80-20. Nous avons donc le même problème maintenant avec la définition des modèles d'effet car nous exécutons des évolutions et les évolutions sont en quelque sorte notre opinion sur ce qui est bon et ce n'est pas vraiment une vérité absolue. Mettons-le ainsi. Nous avons du code de meilleures pratiques écrit par des humains. Nous avons du code généré et ensuite nous avons un LLM qui correspond et dit si ces deux-là sont différents ou non. Donnez-nous un score. Et c'est à peu près comme ça que vous exécutez l'évolution. Pas une façon très agréable de fonctionner, mais nous essayons de résoudre ce problème car nous pensons à affiner le modèle sur l'effet et pour la partie apprentissage par renforcement, nous aurons besoin de bonnes évolutions. C'est donc une partie de ce que nous recherchons en ce moment. Il n'y a pas de bonne ou de mauvaise réponse. S'il y en avait, tous les modèles performeraient de la même manière car tout le monde aurait les mêmes évolutions, tout le monde aurait la même chose. Mais maintenant, nous avons tous les modèles pour ce que nous voulons. J'ai donc l'impression que nous sommes au point de dire "validez ceci". Je vais créer un dépôt et le pousser afin qu'au moins vous y ayez accès. Gosh, je suis trop grand. Nouveau dépôt. Est-il public ? Veuillez choisir un propriétaire. Bien sûr. Ajoutez plus d'orange et poussez. Poussez le dépôt final. Donc, espérons-le, nous n'en sommes pas encore au point de faire du clustering et des workflows. Partageons juste quelques mots sur pourquoi vous voudriez ces aspects dans votre code. C'est une API de to-do très basique. Une chose que je voulais ajouter serait l'authentification et l'enregistrement. Par exemple, lorsque vous avez un enregistrement, votre processus consiste généralement à écrire quelque chose dans la base de données, puis à envoyer un e-mail ou un code par e-mail et à attendre la confirmation. Chaque fois que vous effectuez deux opérations non liées, il n'y a pas de transaction entre elles, pas de transaction de base de données entre elles et votre serveur peut échouer à n'importe quel moment aléatoire de votre code. Il est donc très difficile de garantir que l'e-mail a bien été envoyé, c'est pourquoi de nombreuses fois dans une procédure d'enregistrement, vous voyez la phrase "si l'e-mail n'est pas arrivé dans 30 minutes, veuillez réessayer". Pourquoi devrais-je réessayer si je n'ai pas reçu l'e-mail ? C'est le symptôme d'un système mal conçu qui ne peut pas garantir que deux opérations ont eu lieu. Pour ce faire, vous avez différentes méthodes. Une méthode consiste à implémenter des files d'attente, etc. L'autre méthode consiste à utiliser quelque chose comme des workflows. Vous avez des solutions comme Temporal ingest. Il existe de nombreuses solutions de workflow. L'effet en a une implémentée sur ce qui est appelé l'effet cluster où vous exécutez un cluster de nœuds ban, peu importe les instances, et le système lui-même garantit qu'une fois qu'une procédure commence, elle se terminera, même si le serveur plante, il se déplacera vers un emplacement différent. Comment j'aborderais cela, de la même manière que je l'ai fait maintenant, demander au modèle d'explorer le dépôt, d'extraire les meilleures pratiques autour de l'utilisation de l'effet cluster, de l'utilisation des workflows d'effet et vous partez de là. C'est très intéressant. C'est toujours dans la partie instable de l'effet, mais cela deviendra stable très bientôt. Et nous pensons que surtout si vous intégrez l'IA dans votre application, ce sera encore plus important car avec l'IA, chaque processus devient plus long, comme les LLM prennent des minutes pour répondre. Il y a beaucoup de choses qui peuvent mal tourner en une minute. Si le temps de réponse moyen est de 10 millisecondes, le serveur ne tombera pratiquement jamais en panne pendant ces 10 millisecondes. Si ces 10 millisecondes deviennent une minute, oui, vous êtes à peu près sûr que le serveur tombera en panne pendant cette minute à un moment donné. Et généralement, avant, les entreprises qui utilisaient des workflows étaient des entreprises à plus grande échelle car à grande échelle, chaque cas limite se produit deux fois par jour. Avec des temps de réponse plus longs, même si vous avez 10 utilisateurs, vous aurez pratiquement des perturbations. Si votre processus moyen prend une minute et que vous aurez des pannes partout, c'est pourquoi, par exemple, Temporal est devenu beaucoup plus intéressant au cours des 12 derniers mois, car tout le monde intègre maintenant l'IA dans ses propres produits. Ils ont donc des chatbots, ils ont tout type de processus piloté par l'IA et avec l'effet, vous obtenez des workflows, vous obtenez du clustering, vous avez des intégrations IA, vous avez des intégrations Discord, Slack, etc. Le système est donc vraiment composable et les modèles sont assez décents là-dessus. Nous avons une API fonctionnelle. Je parle depuis environ une heure et demie et j'ai commencé avec zéro connaissance de l'effet. C'était un dépôt vide et c'est pourquoi je voulais appeler cet atelier "clonez simplement le dépôt [ __ ]". C'est à peu près tout. Si vous avez des questions ou quoi que ce soit d'autre, je serai heureux d'en discuter avec vous plus tard, et mettons en place le prochain intervenant. Merci beaucoup.