C'est quoi un ingénieur câblage & pourquoi est-ce important ?

AAI Jason
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00Merci à HubSpot de sponsoriser cette vidéo.
00:00:03Quelque chose de vraiment important s'est produit en décembre 2025.
00:00:07Et la plupart des gens ne s'en sont même pas rendu compte.
00:00:09Andrew Cupsey a tweeté à ce sujet la semaine dernière.
00:00:10"Il est très difficile de communiquer à quel point la programmation a changé grâce à l'IA ces deux derniers mois,
00:00:15plus précisément depuis décembre dernier."
00:00:17Et Greg d'OpenAI en a également parlé.
00:00:20Depuis décembre, il y a eu des améliorations majeures dans les capacités des modèles et des outils.
00:00:24Et quelques ingénieurs lui ont confié que leur métier a fondamentalement changé depuis décembre
00:00:282025.
00:00:29Alors, que s'est-il réellement passé en décembre 2025 ?
00:00:32Pour faire court, le dernier modèle introduit est enfin prêt pour des tâches
00:00:37autonomes de longue durée.
00:00:38Avec l'IA, le rêve ultime est que pendant que nous dormons, l'IA puisse travailler sur
00:00:43des tâches en toute autonomie, 24h/24 et 7j/7.
00:00:46En 2023, le projet le plus populaire, si vous vous souvenez, s'appelait AutoGPT.
00:00:50C'était la première fois que ces systèmes d'agents entièrement autonomes étaient introduits.
00:00:54Leur architecture était assez basique et simple : utiliser GPT-4 comme modèle pour décomposer
00:00:59autononemant une liste de tâches selon l'objectif de l'utilisateur, avec une mémoire simple pour stocker
00:01:03les résultats.
00:01:04Certains tentaient des choses folles, comme fixer l'objectif de gagner 100 000 $ et
00:01:08laisser l'IA boucler sur les tâches indéfiniment jusqu'à réussite.
00:01:11À l'époque, le système finissait par planter lamentablement car le modèle n'était tout simplement pas prêt.
00:01:15Mais depuis décembre dernier, la donne a vraiment changé.
00:01:18Les modèles ont une qualité et une cohérence à long terme nettement supérieures, et ils peuvent gérer
00:01:22des tâches beaucoup plus vastes et longues.
00:01:24Nous avons vu apparaître toutes sortes d'expérimentations dans l'industrie.
00:01:28D'abord, dès janvier, on a vu ce concept très en vogue de "rough loop", la boucle d'itération
00:01:33d'agent la plus basique pour forcer le modèle à travailler plus longtemps sur des tâches
00:01:37plus complexes.
00:01:38On faisait simplement boucler le modèle avec quelques vérifications de conditions, mais on voyait
00:01:42déjà la différence.
00:01:43Une semaine plus tard, Cursor a publié son expérimentation utilisant GPT-5.2 pour construire
00:01:49autonomement un navigateur de zéro avec 3 millions de lignes de code.
00:01:52Anthropic a aussi dévoilé une expérience où une équipe de "Cloud Codes" a travaillé en autonomie
00:01:57sur un compilateur C à partir de zéro pendant deux semaines.
00:02:01Au final, ils ont livré une version fonctionnelle sans aucun codage manuel.
00:02:05On peut même faire tourner Doom à l'intérieur de ce compilateur.
00:02:08Au même moment, OpenClaw a commencé à attirer l'attention avec une croissance explosive
00:02:13jamais vue auparavant.
00:02:14Il était difficile de comprendre l'engouement pour OpenClaw car de l'extérieur,
00:02:18on pouvait le voir comme une simple menace de plus, mais qui vit dans votre ordinateur
00:02:23et accessible via Telegram.
00:02:27Pourquoi un tel succès ?
00:02:29Ce n'est qu'après une utilisation approfondie que j'ai compris : OpenClaw représente
00:02:35ce type d'agents toujours actifs, autonomes et de longue durée, très différents des
00:02:40autres systèmes d'agents où l'humain est le moteur principal qui déclenche
00:02:45chaque action.
00:02:46OpenClaw est permanent et proactif.
00:02:49Ce sentiment d'autonomie est créé par une architecture assez simple : une couche de
00:02:53contexte mémoire avec des déclencheurs et des tâches cron pour agir automatiquement, avec un
00:02:58accès total à l'ordinateur, un environnement de travail surpuissant.
00:03:02Je pense qu'OpenClaw est le premier projet à avoir amorcé le grand changement de paradigme
00:03:06de 2026 : passer de systèmes de co-pilotes basés sur des tâches simples à des agents
00:03:13totalement autonomes et de longue durée.
00:03:15Quelque chose de toujours actif, prêt à livrer des travaux complexes et coordonnés.
00:03:20C'est un changement crucial à comprendre.
00:03:22Le modèle actuel est bien plus puissant que vous ne le pensez, à condition de concevoir
00:03:27le bon système pour le libérer.
00:03:28C'est le cœur de mon propos aujourd'hui.
00:03:30Le "Harness Engineer" (Ingénieur de structure) pour permettre ces systèmes autonomes.
00:03:34Si c'est la première fois que vous en entendez parler, c'est l'évolution de ce dont nous
00:03:38parlions auparavant : le "Context Engineer" ou le "Prompt Engineer".
00:03:41Avant, nous nous concentrions sur l'optimisation des prompts dans la fenêtre de contexte
00:03:46pour qu'un agent soit performant sur une seule session de travail.
00:03:49Mais le Harness Engineer se concentre sur les tâches de longue durée : comment
00:03:53concevoir un système capable de fonctionner sur plusieurs sessions et avec plusieurs agents.
00:03:57Comment concevoir le flux de travail pour garantir que le contexte pertinent soit récupéré
00:04:01à chaque session, avec les bons outils pour tirer le meilleur des modèles.
00:04:05C'est un concept assez nouveau, mais l'industrie converge déjà vers
00:04:09certaines meilleures pratiques, notamment chez Anthropic, Vercel, LangChain et d'autres.
00:04:14Nous allons les examiner un par un pour en voir les modèles récurrents.
00:04:16Mais avant d'approfondir, sachez que ce virage vers les agents autonomes offre une
00:04:21opportunité immense pour les 6 à 12 mois à venir : créer un OpenClaw vertical.
00:04:25Cela signifie étudier et comprendre en profondeur le flux de travail d'un secteur spécifique.
00:04:29Et construire un agent autonome avec l'environnement et les outils adaptés à ce processus.
00:04:34C'est pourquoi je veux vous présenter cette excellente étude de HubSpot sur l'adoption de l'IA
00:04:39dans l'email marketing.
00:04:40C'est un rapport passionnant pour comprendre comment, dans un domaine comme l'email marketing, les gens
00:04:44utilisent réellement l'IA aujourd'hui et quelles sont les lacunes.
00:04:47Ce rapport met en évidence des flux de travail clairs et des opportunités en email marketing que vous
00:04:51pourriez potentiellement automatiser.
00:04:52Ils ont interrogé des centaines d'experts en marketing des plus grandes entreprises pour comprendre
00:04:57comment l'IA transforme leurs méthodes de travail.
00:04:58Ils expliquent pourquoi les marketeurs font encore beaucoup d'édition manuelle,
00:05:03les causes de cela, ainsi que les plus grands défis qu'ils rencontrent lors de
00:05:06la mise en œuvre de l'IA dans l'email marketing.
00:05:07Chacun de ces points est une opportunité de créer un agent entièrement autonome.
00:05:11Ils analysent même les indicateurs clés (KPI) les plus importants pour eux et là où
00:05:15l'IA a prouvé son efficacité.
00:05:16Ainsi que ce que les spécialistes du marketing attendent précisément de l'IA.
00:05:20Si vous êtes un développeur cherchant le prochain grand produit d'agent à construire, je vous
00:05:24recommande vivement de consulter cette ressource.
00:05:27J'ai mis le lien dans la description ci-dessous pour la télécharger gratuitement.
00:05:30Et merci à HubSpot d'avoir sponsorisé cette vidéo.
00:05:32Revenons maintenant au Harness Engineer pour les systèmes d'agents de longue durée.
00:05:36De manière générale, j'en ai tiré trois enseignements majeurs.
00:05:39Premièrement, pour ces agents, la partie critique de la conception du système consiste à créer
00:05:44cet environnement lisible où chaque sous-agent ou session peut comprendre
00:05:49où en sont les choses.
00:05:50Il existe probablement des flux de travail à mettre en place pour imposer cette lisibilité de l'environnement.
00:05:54J'y reviendrai plus en détail.
00:05:56Deuxièmement, la vérification est cruciale.
00:05:58Vous pouvez améliorer considérablement les résultats du système en lui permettant de vérifier son travail
00:06:03efficacement avec une boucle de rétroaction plus rapide.
00:06:04Et troisièmement, nous devons davantage faire confiance au modèle au lieu de construire des outils spécialisés
00:06:08qui encapsulent prématurément trop de raisonnement et de logique.
00:06:11Nous devrions donner au modèle un maximum de contexte avec des outils génériques qu'il comprend nativement,
00:06:16et le laisser explorer comme un humain.
00:06:17Je vais détailler ces trois points en examinant chaque section ici.
00:06:20Commençons par les blocs de structure efficace d'Anthropic pour les agents de longue durée.
00:06:24Ils ont expérimenté l'utilisation du SDK Cloud Code pour construire un agent spécialisé dans
00:06:29des tâches très longues, comme créer un clone du site cloud.ai.
00:06:32Les premiers échecs constatés sont, tout d'abord, que les agents ont tendance à en faire trop d'un coup.
00:06:37Essentiellement, il essaiera toujours de générer l'application entière d'une seule traite.
00:06:40Cela conduit le modèle à manquer de contexte en plein milieu de son exécution, laissant
00:06:45la session suivante démarrer avec une fonctionnalité à moitié implémentée ou documentée.
00:06:49L'agent devait alors deviner ce qui s'était passé et passait un temps fou à essayer
00:06:52de refaire fonctionner l'application de base.
00:06:55Le deuxième échec observé est que les agents ont tendance à déclarer le travail terminé prématurément.
00:07:00Vous l'avez probablement déjà vécu vous-même.
00:07:02Cloud Code ou Cursor affirment que le projet ou la fonctionnalité est terminé.
00:07:05Mais quand vous testez, ça ne fonctionne pas.
00:07:07Leur approche pour résoudre ces comportements par défaut a été, premièrement, de configurer un
00:07:12environnement initial qui pose les bases de toutes les fonctionnalités requises, ce qui
00:07:16oblige l'agent à travailler étape par étape, fonctionnalité après fonctionnalité.
00:07:20C'est assez similaire à l'approche par plan ou PRD (document de spécifications produit) habituelle.
00:07:23Deuxièmement, ils ont commencé à inciter chaque agent à progresser par étapes vers son but,
00:07:27tout en laissant l'environnement dans un état propre à la fin de chaque session.
00:07:32Ils ont donc conçu cette solution en deux parties.
00:07:35Ils ont un agent initialiseur qui utilise un prompt spécialisé pour demander au modèle
00:07:40de configurer l'environnement avec un script init.sh, pour lancer le serveur de dev par exemple,
00:07:45afin que le modèle suivant n'ait pas à s'en soucier.
00:07:48Il y a aussi un fichier cloud-progress.txt qui consigne ce que l'agent a fait, ainsi qu'un
00:07:53commit git initial montrant les fichiers ajoutés.
00:07:55Ensuite, un agent de codage intervient pour chaque session suivante pour demander au modèle de progresser,
00:08:01puis de laisser des comptes-rendus structurés.
00:08:02Tous ces efforts visent un seul but : définir un environnement
00:08:07permettant aux agents de comprendre rapidement l'état du travail en commençant avec une
00:08:11fenêtre de contexte vierge.
00:08:13Le flux est le suivant : l'agent initialiseur tente d'abord de configurer un environnement ou
00:08:17un système de documentation pour suivre et maintenir le plan global.
00:08:21L'environnement qu'ils ont conçu comporte d'abord un document de liste de fonctionnalités pour
00:08:25empêcher l'agent de vouloir tout faire d'un coup ou de croire que le projet est fini trop tôt.
00:08:30Ils demandent à l'agent initialiseur de décomposer le projet en plus de 200 fonctionnalités
00:08:34et de les consigner dans un fichier JSON local, où chaque tâche a des spécifications détaillées
00:08:39ainsi qu'un état de réussite ou d'échec.
00:08:41Par défaut, toutes les tâches sont marquées comme échouées.
00:08:43Cela force le modèle à toujours regarder l'objectif global, à voir la progression et à choisir
00:08:49la tâche la plus prioritaire à accomplir.
00:08:50Mais pour que cela fonctionne, ils doivent aussi forcer le modèle à laisser l'environnement
00:08:55propre après avoir modifié le code. Dans leurs tests, ils ont trouvé que le meilleur moyen
00:08:59est de demander au modèle de committer ses progrès sur git avec un message descriptif et d'écrire
00:09:05un résumé de son avancement dans le fichier de progression. Mais la documentation et l'environnement
00:09:08ne suffisent pas, car le modèle a naturellement tendance à marquer quelque chose
00:09:13comme terminé sans test approprié. Au début, ils incitaient simplement Cloud Code
00:09:17à toujours faire des tests après chaque modification, via des tests unitaires ou des tests d'API
00:09:22sur le serveur de dev.
00:09:23Mais cela ne permettait souvent pas de voir qu'une fonctionnalité ne marchait pas de bout en bout.
00:09:27Les choses ont vraiment changé lorsqu'ils ont donné au modèle les bons outils pour effectuer
00:09:30des tests de bout en bout lui-même, comme Puppeteer MCP ou Chrome DevTools. L'agent a pu
00:09:35identifier et corriger des bugs qui n'étaient pas évidents à la seule lecture du code.
00:09:39En gros, ils ont structuré le tout avec l'agent initialiseur qui décompose
00:09:43l'objectif en une liste de fonctionnalités, avec init.sh pour lancer le serveur
00:09:47de dev et les fichiers de progression.
00:09:49Ainsi, l'agent de codage suivant peut lire la liste des fonctionnalités pour comprendre
00:09:53le plan global, choisir les tâches prioritaires et consulter le fichier de progression pour savoir
00:09:57exactement où en sont les choses.
00:09:59Puis il lance init.sh pour démarrer le serveur de dev et fait des tests de bout en bout pour vérifier
00:10:04que l'environnement est sain. Il obtient ainsi une vision complète et une boucle de rétroaction rapide,
00:10:09même lors des changements de sessions et de fenêtres de contexte.
00:10:10Dans le blog d'OpenAI, ils mentionnent des choses très similaires.
00:10:13Vous devez vous assurer que l'environnement de votre application est lisible.
00:10:16Ils font de l'ensemble du dépôt la source unique de connaissance ou le système d'enregistrement.
00:10:19Au début, ils utilisaient un énorme fichier agents.md, mais cela échouait de façon prévisible car
00:10:23c'était trop de contexte à gérer pour n'importe quel agent.
00:10:27Ils ont donc conçu une structure de documentation propre et traité agents.md comme une table
00:10:32des matières.
00:10:33Ils ont mis en place ce système documentaire allant de l'architecture aux documents de conception, au plan
00:10:37d'exécution, au schéma de base de données, aux spécifications produit, au plan front-end, à la sécurité, etc.,
00:10:42et ont placé cette table des matières dans agents.md pour que l'agent puisse retrouver
00:10:47les informations précises au besoin.
00:10:49Cela permet une divulgation progressive de l'information, et OpenAI va même plus loin.
00:10:53Ils essaient d'intégrer non seulement la connaissance du code, mais aussi des Google Docs, des messages Slack, toutes ces
00:10:58autres informations fragmentées, et les injectent dans le dépôt sous forme de
00:11:03versions locales d'artéfacts.
00:11:04Ainsi, l'agent peut les récupérer car, de son point de vue, si une information n'est pas accessible
00:11:09dans son environnement, alors elle n'existe tout simplement pas.
00:11:11Mais encore une fois, la documentation seule ne suffit pas à garder cohérent un code généré par un agent.
00:11:16Ils ont aussi introduit certains flux de travail programmatiques pour imposer des invariants.
00:11:20Par exemple, ils structurent l'architecture du domaine avec des frontières transversales explicites,
00:11:25ce qui leur permet d'imposer des règles avec des vérifications personnalisées, des linters et des tests structurels,
00:11:29déclenchés et injectés automatiquement à chaque pre-commit git.
00:11:33On attend généralement d'avoir des centaines d'ingénieurs dans une entreprise classique pour ce genre d'architecture,
00:11:37mais avec un agent de codage, c'est un prérequis indispensable dès le départ.
00:11:41À l'intérieur de ces limites, on laisse aux équipes et aux agents une grande liberté dans l'expression
00:11:46des solutions, sans micro-management et sans craindre que l'architecture ne dérive.
00:11:49En parallèle, ils ont aussi beaucoup amélioré la base de code.
00:11:52Par exemple, ils ont rendu l'app lançable via des "git work trees", permettant aux agents de
00:11:55lancer et piloter plusieurs instances simultanément.
00:11:57Ils ont aussi intégré le protocole Chrome DevTools dans l'exécution de l'agent pour qu'il puisse
00:12:01reproduire des bugs et valider des correctifs via des instantanés DOM, des captures d'écran et la navigation.
00:12:05Avec cet environnement et ce flux de travail, le dépôt a enfin franchi le seuil
00:12:09permettant aux agents de piloter de bout en bout une nouvelle fonctionnalité.
00:12:13Désormais, dès qu'il reçoit un prompt, l'agent valide l'état
00:12:17actuel du code, reproduit le bug signalé, enregistre une vidéo pour démontrer
00:12:21l'échec, implémente le correctif, le valide en pilotant l'application, enregistre une seconde
00:12:25vidéo montrant la résolution, et finit par merger les modifications.
00:12:29Ces deux exemples montrent bien les apprentissages et les structures de contrôle nécessaires
00:12:32pour un système entièrement autonome.
00:12:34Il y a aussi d'autres leçons à en tirer.
00:12:36Souvent, quand on construit des agents, surtout verticaux, on a tendance à
00:12:40créer des outils spécialisés pour des tâches spécifiques au domaine.
00:12:43Mais on apprend que les grands modèles de langage fonctionnent presque toujours mieux avec des outils génériques
00:12:47qu'ils comprennent nativement.
00:12:49Vercel a publié un super article sur la refonte de leurs agents "Texte vers SQL".
00:12:53Ils avaient passé des mois à construire un agent interne sophistiqué avec du prompt engineering
00:12:58poussé et une gestion du contexte minutieuse.
00:13:02Mais comme beaucoup d'entre nous, ils ont trouvé que ces systèmes fonctionnaient un peu, mais étaient fragiles,
00:13:06lents et demandaient une maintenance constante.
00:13:09Car à chaque nouveau cas particulier, il fallait injecter un nouveau prompt à l'agent.
00:13:12Plus tard, ils ont tenté une approche qui a tout changé.
00:13:15Ils ont supprimé la plupart des outils spécialisés pour ne laisser qu'un seul outil de commande par lot.
00:13:20Avec cette architecture simplifiée, l'agent est devenu 3,5 fois plus rapide avec
00:13:2537 % de jetons en moins, et le taux de réussite est passé de 80 % à 100 %.
00:13:30L'équipe d'Anthropic a partagé un constat similaire : au lieu d'outils d'exécution
00:13:34de recherche spécialisés, ils n'ont qu'un seul outil de batch
00:13:38permettant de lancer grep, tail, npm ou npm run lint.
00:13:41Fondamentalement, je pense que c'est parce que les modèles sont bien plus familiers
00:13:45avec ces outils natifs du code entraînés sur des milliards de jetons, plutôt qu'avec des fichiers
00:13:49JSON d'appels d'outils sur mesure qu'ils doivent générer.
00:13:51J'en ai parlé dans ma vidéo sur l'appel d'outils programmatique la semaine dernière.
00:13:55Les principes sont les mêmes, mais la base de ces architectures simples
00:13:59reste un bon environnement de contexte et de documentation où le modèle peut utiliser des outils génériques
00:14:05pour récupérer le contexte au fur et à mesure.
00:14:06C'est aussi le cas pour OpenClaw.
00:14:09Si OpenClaw est si intéressant, c'est qu'ils ont un environnement de contexte
00:14:13étonnamment simple mais efficace.
00:14:15Ils ont une liste de documents pour stocker les informations clés. Avec cette base,
00:14:18ils n'ont que les outils les plus basiques : lire, écrire, éditer des fichiers, lancer des commandes
00:14:23et envoyer des messages.
00:14:24Tout le reste vient de la capacité de l'agent à récupérer le contexte pertinent et d'une vaste
00:14:29bibliothèque de compétences pour étendre ses capacités.
00:14:31Voilà donc trois leçons pratiques sur l'ingénierie de structure pour des agents
00:14:35complexes de longue durée.
00:14:36Mettre en place un environnement lisible pour que chaque session capte le contexte efficacement,
00:14:41créer des flux et outils pour que le modèle vérifie son travail et accélère la boucle de
00:14:46rétroaction, et faire confiance à l'agent avec des outils génériques qu'il comprend nativement.
00:14:50Si cela vous intéresse, je vais approfondir la manière dont je transforme ces leçons
00:14:54en un véritable cycle de vie de développement.
00:14:58Dans le AI Builder Club, nous avons des cours sur le "vibe coding" et la création d'agents
00:15:02pour la production.
00:15:03Chaque semaine, moi-même et des experts du secteur partageons nos dernières découvertes pratiques.
00:15:08Si vous voulez apprendre ce que j'apprends chaque jour, cliquez sur le lien
00:15:12ci-dessous pour rejoindre la communauté.
00:15:13J'espère que cette vidéo vous a plu.
00:15:14Merci et à la prochaine.

Key Takeaway

Le passage des co-pilotes de tâches simples à des agents autonomes de longue durée nécessite une nouvelle discipline, le Harness Engineering, centrée sur la conception d'environnements structurés et l'utilisation d'outils natifs.

Highlights

L'émergence du modèle GPT-5.2 et des capacités d'IA autonome de longue durée depuis décembre 2025.

La transition du "Prompt Engineering" vers le "Harness Engineering" (ingénierie de structure) pour gérer des sessions multiples.

L'importance de créer un environnement de développement lisible et structuré (fichiers de progression, listes de tâches JSON) pour les agents.

La supériorité des outils génériques natifs (grep, npm, git) sur les outils spécialisés sur mesure pour les performances des LLM.

L'utilisation de boucles de rétroaction rapides via des tests de bout en bout (Puppeteer, Chrome DevTools) pour valider le travail de l'IA.

L'opportunité commerciale actuelle de créer des "OpenClaw verticaux" dédiés à des secteurs spécifiques comme le marketing par courriel.

Timeline

Le grand changement de paradigme de décembre 2025

Cette section explore une rupture technologique majeure survenue fin 2025 concernant l'autonomie des modèles d'IA. Le locuteur mentionne des figures de l'industrie comme Greg d'OpenAI pour souligner que les métiers de la programmation ont fondamentalement changé. Contrairement aux tentatives limitées d'AutoGPT en 2023, les nouveaux modèles permettent désormais des tâches autonomes de plusieurs semaines sans interruption humaine. Des exemples concrets sont cités, notamment la création d'un navigateur de 3 millions de lignes de code par Cursor et un compilateur C fonctionnel par Anthropic. Le projet OpenClaw est présenté comme le catalyseur de ce passage vers des systèmes proactifs et toujours actifs.

L'émergence du Harness Engineer et l'opportunité verticale

Le concept de "Harness Engineer" ou ingénieur de structure est introduit comme l'évolution logique du prompt engineering. Cette nouvelle discipline se concentre sur la conception de systèmes capables de maintenir un contexte sur de longues durées et plusieurs sessions. Le locuteur insiste sur l'opportunité de créer des agents autonomes spécialisés pour des secteurs verticaux précis. Une étude de HubSpot sur l'IA dans l'email marketing sert d'illustration pour identifier des flux de travail automatisables. L'objectif est de transformer les défis rencontrés par les professionnels en opportunités pour des agents totalement autonomes.

Principes de conception pour les agents de longue durée

Trois enseignements majeurs sont tirés pour réussir la mise en œuvre de systèmes d'agents complexes. Premièrement, il est impératif de créer un environnement lisible où chaque session peut comprendre l'état d'avancement du projet. Deuxièmement, la vérification est cruciale pour éviter que l'IA ne déclare une tâche terminée alors qu'elle comporte des erreurs. Enfin, le locuteur suggère de faire davantage confiance aux capacités natives du modèle plutôt que de restreindre son raisonnement. Ces principes visent à résoudre les échecs courants où les agents tentent de trop en faire d'un coup sans contexte suffisant.

Structures de contrôle et documentation chez Anthropic

Cette partie détaille les méthodes spécifiques utilisées par Anthropic pour structurer le travail de leurs agents. Ils utilisent un agent initialiseur qui décompose un projet en plus de 200 fonctionnalités détaillées dans un fichier JSON. L'environnement inclut des scripts d'initialisation et des fichiers de progression pour assurer une continuité parfaite entre les sessions de codage. L'intégration d'outils de test comme Puppeteer permet à l'agent d'identifier visuellement les bugs et de les corriger de manière autonome. Cette approche force le modèle à travailler étape par étape tout en maintenant une vision globale de l'objectif final.

Optimisation de l'environnement et outils natifs chez OpenAI et Vercel

Le locuteur analyse les stratégies d'OpenAI et Vercel pour améliorer la fiabilité de la génération de code. OpenAI utilise le dépôt git comme source unique de vérité, intégrant même des documents Slack et Google Docs sous forme d'artéfacts locaux. Vercel a découvert qu'en supprimant les outils spécialisés au profit de commandes par lot simples, la rapidité a été multipliée par trois avec un taux de réussite de 100 %. Les modèles de langage sont plus performants avec des outils qu'ils ont rencontrés massivement lors de leur entraînement, comme grep ou npm. La vidéo se conclut sur l'importance du "vibe coding" et invite à rejoindre la communauté AI Builder Club pour approfondir ces techniques.

Community Posts

View all posts