00:00:00(musique entraînante)
00:00:02- Salut tout le monde, comment ça va ?
00:00:23C'est un plaisir d'être là, je m'appelle Dex.
00:00:25Comme on l'a dit dans cette super intro,
00:00:27je travaille sur les agents depuis un moment.
00:00:29Notre conférence, "12-Factor Agents", lors de l'AI Engineer en juin,
00:00:32a été l'une des plus suivies de tous les temps.
00:00:34Elle est dans le top 8, je crois,
00:00:35l'une des meilleures de l'édition de juin.
00:00:38J'y ai peut-être glissé un mot sur l'ingénierie de contexte.
00:00:41Alors, pourquoi suis-je ici aujourd'hui ? De quoi allons-nous parler ?
00:00:44Je veux revenir sur l'une de mes présentations préférées
00:00:46de l'AI Engineer de juin,
00:00:47et je sais qu'on a eu les dernières nouvelles d'Igor hier,
00:00:49mais on ne m'a pas laissé modifier mes diapositives,
00:00:50donc on va se baser sur ce qu'Igor a expliqué en juin.
00:00:54En gros, ils ont sondé 100 000 développeurs
00:00:56dans des entreprises de toutes tailles,
00:00:58et ils ont découvert que la plupart du temps,
00:01:00quand on utilise l'IA pour le génie logiciel,
00:01:01on se retrouve avec beaucoup de retouches et de remue-ménage dans le code.
00:01:04Et ça ne fonctionne pas très bien pour les tâches complexes
00:01:07ou sur des bases de code existantes, dites "brownfield".
00:01:08Comme vous pouvez le voir sur le graphique,
00:01:10on déploie beaucoup plus de choses,
00:01:11mais une grande partie consiste à corriger le travail bâclé
00:01:14que l'on a livré la semaine précédente.
00:01:15Et d'un autre côté,
00:01:18si vous partez de zéro sur un petit tableau de bord Vercel,
00:01:21ou quelque chose du genre, ça marche à merveille.
00:01:25Mais si vous attaquez une base de code Java vieille de 10 ans,
00:01:28c'est une autre paire de manches.
00:01:29Et c'est exactement ce que j'ai ressenti.
00:01:30Personnellement, et en discutant avec beaucoup de fondateurs
00:01:32et d'excellents ingénieurs : trop de déchets,
00:01:35des usines à dette technique... ça ne marchera pas sur notre code.
00:01:37Peut-être un jour, quand les modèles s'amélioreront.
00:01:40Mais c'est là que l'ingénierie de contexte entre en jeu.
00:01:42Comment tirer le maximum des modèles actuels ?
00:01:44Comment gérer notre fenêtre de contexte ?
00:01:46Nous en avons discuté en août.
00:01:48Je dois vous avouer quelque chose.
00:01:49La première fois que j'ai utilisé Claude Code, je n'ai pas été emballé.
00:01:53Je me suis dit : "Ok, c'est un peu mieux,
00:01:54je comprends le principe, j'aime bien l'interface."
00:01:56Mais depuis, notre équipe a trouvé un truc,
00:01:59et on a réussi à obtenir
00:02:01deux à trois fois plus de rendement.
00:02:02On produisait tellement qu'on n'a pas eu d'autre choix
00:02:06que de changer notre manière de collaborer.
00:02:07On a revu de fond en comble notre façon de créer des logiciels.
00:02:11On était une équipe de trois, ça a pris huit semaines, c'était très dur.
00:02:12C'était vraiment une épreuve.
00:02:14Mais maintenant que c'est réglé, on ne reviendra jamais en arrière.
00:02:16C'est toute cette histoire de "zéro déchet".
00:02:18Je pense qu'on tient quelque chose.
00:02:20C'est devenu viral sur Hacker News en septembre.
00:02:23Des milliers de personnes sont allées sur GitHub
00:02:25pour récupérer notre système de prompt "recherche, plan, exécution".
00:02:28Les objectifs qu'on a définis petit à petit sont les suivants :
00:02:31il nous faut une IA efficace sur les bases de code existantes.
00:02:35Capable de résoudre des problèmes complexes.
00:02:38Sans produire de code poubelle.
00:02:40Et on devait maintenir une certaine cohérence mentale.
00:02:42Je reviendrai sur ce que ça signifie
00:02:43dans un instant.
00:02:44Et bien sûr, comme pour tout,
00:02:46on veut utiliser le plus de tokens possible.
00:02:47Ce qu'on peut déléguer intelligemment à l'IA
00:02:50est crucial.
00:02:52C'est un levier énorme.
00:02:53Voici donc l'ingénierie de contexte avancée pour les agents de codage.
00:02:56Je vais commencer par poser le cadre.
00:02:58La manière la plus naïve d'utiliser un agent
00:03:01est de lui demander un truc, de lui dire pourquoi c'est faux,
00:03:03de le corriger, et de recommencer encore et encore
00:03:05jusqu'à épuiser le contexte, abandonner ou finir en pleurs.
00:03:09On peut être un peu plus malin.
00:03:11La plupart des gens découvrent assez vite
00:03:13dans leur exploration de l'IA qu'il vaut mieux,
00:03:17si une conversation s'égare,
00:03:21ouvrir une nouvelle fenêtre de contexte.
00:03:24On se dit : "Ok, on a pris la mauvaise route."
00:03:25On repart de zéro.
00:03:26Même prompt, même tâche.
00:03:27Mais cette fois, on va par là.
00:03:29Et n'allez pas là-bas, ça ne marche pas.
00:03:31Comment savoir quand il est temps de recommencer ?
00:03:34Si vous voyez ceci,
00:03:37(rires de l'assistance)
00:03:39c'est probablement le moment de faire table rase, non ?
00:03:41C'est ce que répond Claude quand on lui dit qu'il déconne.
00:03:45Mais on peut aller encore plus loin.
00:03:47On peut pratiquer ce que j'appelle la "compaction intentionnelle".
00:03:50Que vous soyez sur la bonne voie ou non,
00:03:53vous pouvez prendre votre fenêtre de contexte actuelle
00:03:56et demander à l'agent de la résumer dans un fichier Markdown.
00:03:59Vous pouvez le relire et l'annoter.
00:04:00Ensuite, quand le nouvel agent démarre,
00:04:02il se met direct au travail au lieu de devoir
00:04:04refaire toutes les recherches et l'analyse du code
00:04:05pour se remettre à niveau.
00:04:07Qu'est-ce qu'on met dans cette compaction ?
00:04:09La question est : qu'est-ce qui prend de la place
00:04:11dans votre fenêtre de contexte ?
00:04:13La recherche de fichiers, la compréhension du flux,
00:04:17l'édition, les rapports de tests et de build.
00:04:20Et si vous utilisez un MCP qui balance du JSON
00:04:22et des tonnes d'UUID dans votre contexte,
00:04:25que Dieu vous vienne en aide.
00:04:26Alors, que faut-il compacter ?
00:04:28Je détaillerai les spécificités plus tard,
00:04:30mais voici un exemple de bonne compaction.
00:04:31C'est exactement ce sur quoi nous travaillons,
00:04:33les fichiers précis et les numéros de lignes
00:04:34qui sont pertinents pour le problème à résoudre.
00:04:37Pourquoi sommes-nous si obsédés par le contexte ?
00:04:39Parce que les LLM se sont fait descendre sur YouTube pour ça.
00:04:42Ce ne sont pas des fonctions pures car ils sont non déterministes,
00:04:45mais ils sont sans état (stateless).
00:04:46La seule façon d'améliorer les performances d'un LLM
00:04:49est d'y injecter de meilleurs tokens
00:04:51pour en obtenir de meilleurs en sortie.
00:04:52À chaque étape de la boucle,
00:04:53Claude, ou n'importe quel agent de codage,
00:04:55doit choisir le prochain outil.
00:04:56Il peut y avoir des centaines de bonnes options
00:04:58et des centaines de mauvaises.
00:05:00Mais la seule chose qui influence la suite,
00:05:03c'est ce qui se trouve déjà dans la conversation.
00:05:05Nous allons donc optimiser cette fenêtre
00:05:07pour la justesse, l'exhaustivité, la taille
00:05:10et aussi pour la trajectoire.
00:05:11Cette histoire de trajectoire est intéressante
00:05:12car beaucoup de gens disent :
00:05:13"J'ai demandé un truc à l'agent,
00:05:16il s'est trompé."
00:05:17"Je l'ai corrigé, je l'ai engueulé,
00:05:18et il a encore fait une erreur."
00:05:20"Et je l'ai encore engueulé."
00:05:21Le LLM regarde alors la conversation et se dit :
00:05:23"D'accord, j'ai fait une erreur,
00:05:24l'humain m'a crié dessus,
00:05:25j'ai encore fait une erreur et il m'a encore crié dessus."
00:05:26"Le prochain token le plus probable ici
00:05:29est donc que je refasse une erreur
00:05:31pour que l'humain puisse m'engueuler à nouveau."
00:05:33Faites donc attention à votre trajectoire.
00:05:35À l'inverse,
00:05:36le pire, c'est d'avoir des infos erronées,
00:05:39puis des infos manquantes, et enfin trop de bruit.
00:05:42Si vous aimez les équations, en voici une un peu bête
00:05:44pour illustrer ma pensée.
00:05:47Jeff Huntley a fait beaucoup de recherches sur les agents de codage.
00:05:51Il l'a très bien formulé.
00:05:51Plus vous saturez la fenêtre de contexte,
00:05:53plus les résultats seront médiocres.
00:05:55Cela m'amène à un concept.
00:05:56Un concept très académique appelé la "zone d'idiotie".
00:05:59Vous avez votre fenêtre de contexte.
00:06:01Environ 168 000 tokens.
00:06:03Certains sont réservés à la sortie et à la compaction.
00:06:05Ça varie selon les modèles,
00:06:07mais prenons Claude Code en exemple.
00:06:09À partir de 40 %, vous allez commencer
00:06:10à voir des rendements décroissants selon la tâche.
00:06:14Si vous avez trop de MCP dans vos agents,
00:06:17vous travaillez en plein dans la zone d'idiotie
00:06:18et vous n'aurez jamais de bons résultats.
00:06:21Les gens en ont parlé.
00:06:21Je ne m'étendrai pas là-dessus.
00:06:22Les résultats peuvent varier.
00:06:23Les 40 % dépendent de la complexité de la tâche,
00:06:26mais c'est une bonne règle de base.
00:06:28Revenons à la compaction, ou comme je l'appellerai désormais :
00:06:31comment éviter habilement la zone d'idiotie.
00:06:33On peut utiliser des sous-agents.
00:06:37Si vous avez un sous-agent front-end, un back-end,
00:06:39un QA et un data scientist, arrêtez tout de suite.
00:06:44Les sous-agents ne servent pas à imiter des rôles humains.
00:06:47Ils servent à contrôler le contexte.
00:06:49Par exemple, si vous voulez comprendre
00:06:51comment fonctionne un élément dans une grosse base de code,
00:06:53vous pouvez diriger l'agent principal vers cette tâche,
00:06:55s'il gère les sous-agents,
00:06:56ou créer votre propre système.
00:06:58En gros, vous dites : "Va voir comment ça marche."
00:07:00Il peut alors créer une nouvelle fenêtre de contexte
00:07:03qui va se charger de lire, chercher,
00:07:05analyser des fichiers entiers
00:07:07et comprendre l'architecture,
00:07:09pour ensuite renvoyer un message ultra succinct
00:07:13à l'agent parent, du genre :
00:07:14"Hé, le fichier que tu cherches est ici."
00:07:17L'agent parent n'a plus qu'à lire ce fichier et bosser.
00:07:20C'est extrêmement puissant.
00:07:22Si vous les utilisez correctement,
00:07:23vous obtenez de bonnes réponses,
00:07:25et vous gérez parfaitement votre contexte.
00:07:29Ce qui marche encore mieux que les sous-agents,
00:07:30ou une couche au-dessus des sous-agents,
00:07:32est un flux de travail que j'appelle la compaction intentionnelle fréquente.
00:07:35Nous parlerons du cycle recherche-plan-implémentation dans une minute,
00:07:37mais l'idée est que vous réduisez
00:07:39constamment votre fenêtre de contexte.
00:07:41Vous bâtissez tout votre flux de travail autour de la gestion du contexte,
00:07:45cela se décline en trois phases : recherche, plan, implémentation,
00:07:48et nous allons essayer de rester dans la "zone intelligente" tout du long.
00:07:51La recherche consiste à comprendre
00:07:53comment le système fonctionne, trouver le bon fichier,
00:07:55en restant objectif.
00:07:56Voici un prompt que vous pouvez utiliser pour faire de la recherche.
00:07:58Voici le résultat d'un prompt de recherche.
00:08:00Tout ceci est en open source.
00:08:01Vous pouvez aller les récupérer et les tester vous-mêmes.
00:08:04Pour la planification, vous allez définir les étapes exactes.
00:08:06Vous inclurez les noms de fichiers et des extraits de lignes.
00:08:08Vous serez très explicite sur la manière de tester les choses
00:08:10après chaque modification.
00:08:11Voici un bon prompt de planification.
00:08:12Voici l'un de nos plans.
00:08:13Il contient de réels extraits de code.
00:08:16Et ensuite, nous allons implémenter.
00:08:17Et si vous avez lu l'un de ces plans,
00:08:17vous voyez très facilement comment le modèle le plus bête au monde
00:08:20ne risque probablement pas de se rater.
00:08:23On se contente donc de dérouler le plan
00:08:24en gardant un contexte réduit.
00:08:26Comme prompt de planification, comme je l'ai dit,
00:08:27c'est la partie la moins excitante du processus.
00:08:30Je voulais mettre cela en pratique.
00:08:31Pour nous, je fais un podcast avec mon ami Vaibhav,
00:08:34qui est le PDG d'une entreprise appelée Boundary ML.
00:08:37Et j'ai dit : "Hé, je vais essayer de corriger d'un coup
00:08:39ton codebase Rust de 300 000 lignes
00:08:41pour un langage de programmation."
00:08:42Et tout l'épisode y passe.
00:08:45Ça dure environ une heure et demie.
00:08:46Je ne vais pas tout détailler maintenant,
00:08:47mais nous avons généré beaucoup de recherches
00:08:48puis nous les avons jetées parce qu'elles étaient mauvaises.
00:08:49Ensuite, nous avons fait un plan sans recherche,
00:08:51puis avec recherche, et comparé tous les résultats.
00:08:53C'était un moment sympa.
00:08:54C'était lundi soir.
00:08:55Dès mardi matin, nous étions dans l'émission
00:08:57et le CTO avait vu la Pull Request,
00:08:59sans réaliser que je faisais ça pour un sketch de podcast.
00:09:03Et en gros, il a dit : "Ouais, ça a l'air bien.
00:09:04On l'intégrera dans la prochaine version."
00:09:05Il était un peu confus.
00:09:08Voici le plan.
00:09:09Mais bref, oui, c'est confirmé.
00:09:12Ça fonctionne sur des codebases existants sans produire de déchets.
00:09:14Mais je voulais voir si on pouvait résoudre des problèmes complexes.
00:09:17Vaibhav était encore un peu sceptique.
00:09:19On s'est posés pendant environ sept heures un samedi
00:09:21et on a livré 35 000 lignes de code pour BAML.
00:09:24L'une des PR a été fusionnée une semaine plus tard.
00:09:26Je précise qu'une partie est de la génération de code.
00:09:28Vous mettez à jour votre comportement,
00:09:29tous les fichiers de référence se mettent à jour, etc.,
00:09:31mais on a expédié énormément de code ce jour-là.
00:09:33Il estime qu'on a fait une à deux semaines de travail en sept heures.
00:09:36Donc cool, on peut résoudre des problèmes complexes.
00:09:40Il y a des limites à cela.
00:09:41Je me suis posé avec mon ami Blake.
00:09:42On a tenté de supprimer les dépendances Hadoop de Parquet Java.
00:09:46Si vous savez ce qu'est Parquet Java,
00:09:47je suis désolé pour ce qui a pu vous arriver
00:09:50pour en arriver à ce stade de votre carrière.
00:09:53Ça ne s'est pas bien passé.
00:09:55Voici les plans, voici la recherche.
00:09:57À un certain point, on a tout jeté
00:09:58et on est retournés devant le tableau blanc.
00:10:00On a dû, une fois qu'on avait appris
00:10:01où se trouvaient tous les pièges,
00:10:03revenir à la question :
00:10:05comment tout cela va-t-il vraiment s'assembler ?
00:10:06Et cela m'amène à un point très intéressant
00:10:09dont Jake parlera plus tard.
00:10:11Ne déléguez pas la réflexion.
00:10:13L'IA ne peut pas remplacer la pensée.
00:10:14Elle ne peut qu'amplifier la réflexion que vous avez menée,
00:10:17ou votre absence de réflexion.
00:10:19Alors les gens demandent : "Donc Dex,
00:10:21c'est du développement piloté par les spécifications (SDD), non ?"
00:10:23Non, le concept de SDD est cassé.
00:10:27Pas l'idée en soi, mais l'expression.
00:10:30Elle n'est pas bien définie.
00:10:33C'est Brigetta de chez ThoughtWorks.
00:10:35Et beaucoup de gens disent "spécification"
00:10:37alors qu'ils veulent dire un prompt plus détaillé.
00:10:39Est-ce que quelqu'un se souvient de cette image ?
00:10:41Est-ce que quelqu'un sait d'où ça vient ?
00:10:43D'accord, c'est une référence pointue.
00:10:44Il n'y aura jamais d'"année des agents"
00:10:46à cause de la diffusion sémantique.
00:10:47Martin Fowler a dit cela en 2006.
00:10:49On invente un bon terme avec une bonne définition,
00:10:52puis tout le monde s'emballe
00:10:53et chacun commence à lui donner 100 sens différents
00:10:56pour 100 personnes différentes, et cela devient inutile.
00:10:59On a eu l'agent comme personne, l'agent comme microservice,
00:11:02l'agent comme chatbot, l'agent comme flux de travail.
00:11:05Et merci Simon.
00:11:06Nous revoilà au point de départ.
00:11:07Un agent, c'est juste des outils dans une boucle.
00:11:09C'est ce qui arrive au développement piloté par les spécifications.
00:11:11J'avais l'habitude de mettre la diapositive de Sean au début,
00:11:15mais cela poussait beaucoup de gens
00:11:15à se concentrer sur les mauvaises choses.
00:11:17Son idée de "oubliez le code, c'est comme de l'assembleur maintenant"
00:11:19et de se concentrer uniquement sur le Markdown.
00:11:21C'est une idée très cool, mais les gens disent SDD
00:11:24pour désigner un meilleur prompt ou un document d'exigences produit.
00:11:26Parfois, c'est utiliser des boucles de rétroaction vérifiables
00:11:28et de la contre-pression.
00:11:30Peut-être est-ce traiter le code comme de l'assembleur,
00:11:32comme Sean nous l'a enseigné.
00:11:34Mais pour beaucoup, c'est juste utiliser des fichiers Markdown
00:11:36pendant que vous codez.
00:11:37Ou mon préféré, je suis tombé dessus la semaine dernière :
00:11:39une spécification est la documentation d'une bibliothèque open source.
00:11:43C'est donc fini.
00:11:44Le SDD est surévalué, c'est devenu inutile.
00:11:48C'est sémantiquement diffus.
00:11:49Je voulais donc parler de quatre choses
00:11:52qui fonctionnent réellement aujourd'hui, les étapes tactiques et pratiques
00:11:55que nous avons trouvées efficaces en interne et avec nos utilisateurs.
00:11:59On fait la recherche, on comprend comment le système fonctionne.
00:12:02Vous vous souvenez de "Memento" ?
00:12:03C'est le meilleur film sur l'ingénierie du contexte,
00:12:05comme le dit Peter.
00:12:07Ce gars se réveille, il n'a plus de mémoire,
00:12:09il doit lire ses propres tatouages pour savoir qui il est
00:12:11et ce qu'il est en train de faire.
00:12:12Si vous n'intégrez pas vos agents, ils vont inventer n'importe quoi.
00:12:17Et voici votre équipe, c'est très simplifié
00:12:19pour la plupart d'entre vous.
00:12:19La plupart d'entre vous ont des organisations bien plus grandes.
00:12:21Mais disons que vous voulez travailler sur cette partie.
00:12:23Une chose possible est de mettre un document d'accueil
00:12:26dans chaque dépôt.
00:12:27Vous y mettez beaucoup de contexte.
00:12:28Voici le dépôt, voici comment il fonctionne.
00:12:29C'est une compression de tout le contexte du codebase
00:12:32que l'agent peut voir à l'avance
00:12:34avant de se mettre réellement au travail.
00:12:36C'est difficile car parfois cela devient trop long.
00:12:39À mesure que votre codebase grandit,
00:12:41soit vous devez rallonger ce document,
00:12:43soit vous devez omettre des informations.
00:12:45Et donc, pendant que vous lisez ceci,
00:12:48vous allez lire le contexte
00:12:49de ce gros mono-repo de cinq millions de lignes
00:12:52et vous allez épuiser toute votre "zone intelligente"
00:12:53juste pour apprendre comment ça marche, et vous ne pourrez plus
00:12:55faire de bons appels d'outils dans la "zone bête".
00:12:57Donc, vous pouvez fragmenter cela dans la pile.
00:13:02On parle simplement de divulgation progressive.
00:13:04Vous pourriez diviser cela, n'est-ce pas ?
00:13:05Vous pourriez mettre un fichier à la racine de chaque dépôt
00:13:08et ensuite, à chaque niveau, avoir du contexte additionnel
00:13:11selon l'endroit où vous travaillez :
00:13:13si vous êtes ici, voici ce que vous devez savoir.
00:13:15On ne documente pas les fichiers eux-mêmes
00:13:17car ils sont la source de vérité.
00:13:18Mais à mesure que votre agent travaille,
00:13:19vous récupérez le contexte racine
00:13:21puis vous récupérez le sous-contexte.
00:13:22On ne citera pas d'outil spécifique,
00:13:23vous pourriez utiliser CloudMD pour ça,
00:13:24ou Hoax, peu importe.
00:13:26Mais ainsi, il vous reste plein de place dans la "zone intelligente"
00:13:28car vous n'importez que ce dont vous avez besoin.
00:13:31Le problème, c'est que ça finit par être obsolète.
00:13:33Chaque fois que vous livrez une nouvelle fonctionnalité,
00:13:35vous devez en quelque sorte invalider le cache
00:13:38et reconstruire de larges pans de cette documentation interne.
00:13:42Et vous pourriez utiliser massivement l'IA
00:13:43et intégrer cette mise à jour à votre processus.
00:13:46Laissez-moi poser une question.
00:13:48Entre le code réel, les noms de fonctions,
00:13:50les commentaires et la documentation,
00:13:51quelqu'un veut deviner ce qu'il y a sur l'axe Y de ce graphique ?
00:13:57- Les déchets. - Les déchets.
00:13:58C'est en fait la quantité de mensonges que vous pouvez trouver
00:14:01dans n'importe quelle partie de votre codebase.
00:14:03Vous pourriez intégrer sa mise à jour à votre processus,
00:14:06mais vous ne devriez probablement pas, car vous ne le ferez sans doute pas.
00:14:08Ce que nous préférons, c'est le contexte compressé à la demande.
00:14:11Si je bâtis une fonction liée aux fournisseurs SCM,
00:14:14à JIRA et à Linear,
00:14:15je donnerais juste une petite orientation.
00:14:17Je dirais : "Hé, on va travailler
00:14:18dans cette partie du codebase juste ici",
00:14:21et un bon prompt de recherche ou une commande
00:14:24pourrait utiliser votre compétence,
00:14:27lancer des sous-agents pour analyser ces tranches verticales
00:14:30à travers la base de code, puis de construire un document de recherche
00:14:33qui n'est qu'un instantané de la vérité brute,
00:14:35basé sur le code lui-même, des parties qui comptent vraiment.
00:14:39Nous compressons la vérité.
00:14:41La planification est un levier.
00:14:43Planifier, c'est compresser l'intention.
00:14:45Et dans le plan, nous allons définir les étapes exactes.
00:14:48Prenons nos recherches et notre PRD, ou notre ticket de bug,
00:14:50ou quoi que ce soit d'autre.
00:14:52Nous créons un plan et un fichier de planification.
00:14:54Nous compactons donc à nouveau.
00:14:55Et je veux m'arrêter un instant sur l'alignement mental.
00:14:58Est-ce que quelqu'un sait à quoi sert la revue de code ?
00:15:00L'alignement mental, l'alignement mental.
00:15:05Il s'agit de s'assurer que les choses sont correctes et tout ça.
00:15:08Mais le plus important, c'est comment garder tout le monde
00:15:10sur la même longueur d'onde au sein de l'équipe
00:15:11sur l'évolution de la base de code et pourquoi ?
00:15:14Je peux lire mille lignes de Golang par semaine.
00:15:17Pardon, je ne peux pas en lire mille.
00:15:18C'est dur, mais j'y arrive.
00:15:19Je n'en ai pas envie.
00:15:20Et à mesure que l'équipe grandit, tout le code est révisé.
00:15:23On ne néglige pas la lecture du code.
00:15:24Mais moi, en tant que leader technique de l'équipe,
00:15:27je peux lire les plans et rester à jour.
00:15:29Et ça me suffit.
00:15:30Je peux détecter certains problèmes tôt
00:15:32et je garde une compréhension de l'évolution du système.
00:15:35Mitchell a écrit ce super article
00:15:36sur la façon dont il intègre ses fils de discussion AMP
00:15:38dans ses pull requests pour qu'on ne voie pas juste
00:15:41un mur de texte vert dans GitHub,
00:15:43mais les étapes exactes, les prompts utilisés,
00:15:44et le fait que le build final soit passé.
00:15:46Cela emmène le réviseur dans un voyage
00:15:49qu'une simple PR GitHub ne permet pas.
00:15:51Et comme vous livrez de plus en plus,
00:15:52parfois deux à trois fois plus de code,
00:15:54c'est à vous de trouver des moyens de garder votre équipe
00:15:57sur la même page et de montrer les étapes effectuées
00:16:00ainsi que les tests manuels réalisés.
00:16:01Votre objectif est le levier, vous voulez donc être sûr
00:16:04que le modèle fera réellement la bonne chose.
00:16:06Je ne peux pas lire ce plan et savoir exactement
00:16:08ce qui va se passer et quels changements de code auront lieu.
00:16:11Donc, au fil du temps, nous avons évolué pour que nos plans incluent
00:16:14des extraits de code réels de ce qui va changer.
00:16:17Votre but est le levier.
00:16:18Vous voulez la compression de l'intention
00:16:19et une exécution fiable.
00:16:22Bon, j'ai une formation en physique.
00:16:23On aime tracer des lignes au milieu des pics et des courbes.
00:16:28Plus vos plans sont longs, plus la fiabilité augmente,
00:16:30mais la lisibilité diminue.
00:16:31Il y a un juste milieu pour vous, votre équipe
00:16:33et votre base de code ; vous devriez essayer de le trouver.
00:16:35Car quand nous révisons les recherches et les plans,
00:16:37s'ils sont bons, nous obtenons cet alignement mental.
00:16:40Ne sous-traitez pas la réflexion.
00:16:42Je l'ai déjà dit, ce n'est pas magique.
00:16:44Le prompt parfait n'existe pas.
00:16:46Ça ne marchera pas si vous ne lisez pas le plan.
00:16:50Nous avons conçu tout notre processus autour du fait que vous,
00:16:53le créateur, interagissez avec l'agent
00:16:55en lisant les plans au fur et à mesure de leur création.
00:16:56Et si vous avez besoin d'une revue par les pairs,
00:16:58vous pouvez l'envoyer à quelqu'hui et demander :
00:16:58« Est-ce que ce plan semble correct ? »
00:17:00« Est-ce la bonne approche ? »
00:17:00« Est-ce le bon ordre pour aborder ces points ? »
00:17:03Jake a écrit un excellent article de blog expliquant que
00:17:05la valeur du cycle recherche-plan-implémentation
00:17:07vient de vous, l'humain dans la boucle, qui garantit la justesse.
00:17:11Si vous ne devez retenir qu'une chose de cette conférence,
00:17:14c'est qu'une mauvaise ligne de code reste une mauvaise ligne de code.
00:17:17Et une mauvaise partie de plan peut générer 100 mauvaises lignes.
00:17:22Une mauvaise recherche, comme une incompréhension
00:17:25du fonctionnement du système ou de l'emplacement des choses,
00:17:27et tout votre projet est fichu.
00:17:29Vous allez envoyer le modèle dans la mauvaise direction.
00:17:31En interne et avec nos utilisateurs,
00:17:34nous essayons constamment de déplacer l'effort humain
00:17:36vers les parties à plus fort levier de ce pipeline.
00:17:39Ne sous-traitez pas la réflexion.
00:17:41Méfiez-vous des outils qui crachent juste
00:17:43des tas de fichiers Markdown juste pour vous rassurer.
00:17:45Je ne citerai pas de noms ici.
00:17:47Parfois, c'est excessif.
00:17:49Ma façon de voir les choses est la suivante :
00:17:51on n'a pas toujours besoin d'un cycle complet RPI.
00:17:54Parfois il en faut plus, parfois moins.
00:17:56Si vous changez juste la couleur d'un bouton,
00:17:57parlez simplement à l'agent et dites-lui quoi faire.
00:18:00Pour un plan simple sur une petite fonctionnalité,
00:18:04ou des fonctionnalités moyennes sur plusieurs dépôts,
00:18:07faites une recherche, puis construisez un plan.
00:18:09En gros, la difficulté des problèmes que vous pouvez résoudre
00:18:10augmente avec l'ingénierie du contexte
00:18:13et la compaction que vous acceptez de faire.
00:18:15Si vous visez le niveau supérieur,
00:18:18vous devrez probablement en faire plus.
00:18:19On me demande souvent comment savoir
00:18:21quelle dose d'ingénierie de contexte utiliser ?
00:18:23C'est une question d'entraînement.
00:18:24Vous vous tromperez, et vous devez vous tromper
00:18:26encore et encore.
00:18:27Parfois vous ferez trop grand, parfois trop petit.
00:18:29Choisissez un outil et pratiquez.
00:18:32Je déconseille de papillonner entre Claude, Codex
00:18:35et tous ces différents outils.
00:18:36Je ne suis pas un grand fan des acronymes.
00:18:40On disait que le développement piloté par les specs était mort.
00:18:42Je ne pense pas que « recherche, plan, implémentation » seront les seules étapes.
00:18:44L'important, c'est la compaction, l'ingénierie de contexte
00:18:47et le fait de rester dans la « zone intelligente ».
00:18:48Mais les gens appellent ça le RPI,
00:18:50et je ne peux rien y faire.
00:18:52Soyez juste prudents : il n'y a pas de prompt parfait,
00:18:55pas de solution miracle.
00:18:56Si vous voulez vraiment un mot à la mode,
00:18:58vous pouvez appeler ça l'ingénierie de harnais,
00:19:00qui fait partie de l'ingénierie de contexte,
00:19:01et c'est la façon dont vous vous intégrez aux points de contact
00:19:03sur Codex, Claude, Cursor ou autre,
00:19:05comment vous personnalisez votre base de code.
00:19:07Et la suite ?
00:19:11Je pense que les agents de codage vont en fait
00:19:12devenir un produit de base.
00:19:13Les gens vont apprendre à s'en servir et s'améliorer.
00:19:15Le plus dur sera d'adapter votre équipe
00:19:17et votre flux de travail dans le SDLC pour fonctionner
00:19:21dans un monde où 99 % de votre code est produit par l'IA.
00:19:24Si vous n'y arrivez pas, vous êtes perdus.
00:19:26Car il y a une sorte de fossé qui se creuse :
00:19:27les ingénieurs confirmés n'adoptent pas l'IA
00:19:29parce qu'elle ne les rend pas beaucoup plus rapides,
00:19:31alors que les juniors et les profils intermédiaires l'utilisent beaucoup
00:19:33car elle comble leurs lacunes,
00:19:35mais elle produit aussi parfois du code médiocre,
00:19:36et les ingénieurs seniors détestent ça de plus en plus
00:19:38chaque semaine parce qu'ils doivent nettoyer ce code
00:19:40généré par Cursor la semaine précédente.
00:19:42Ce n'est pas la faute de l'IA,
00:19:44ni celle de l'ingénieur intermédiaire.
00:19:46Le changement culturel est très difficile
00:19:48et il doit venir d'en haut pour fonctionner.
00:19:50Si vous êtes un leader technique dans votre entreprise,
00:19:52choisissez un outil et commencez à pratiquer.
00:19:54Si vous voulez nous aider, nous recrutons,
00:19:56nous construisons un IDE agentique pour aider les équipes
00:19:59à atteindre rapidement les 99 % de code généré par IA.
00:20:03Nous serions ravis de discuter si vous voulez travailler avec nous.
00:20:06Allez sur notre site, envoyez-nous un email,
00:20:08ou venez me voir dans le couloir.
00:20:09Merci infiniment pour votre énergie.
00:20:11(Applaudissements du public)
00:20:13(Musique électronique entraînante)