Zéro « vibes », que du code : Résoudre des problèmes ardus dans des bases de code complexes – Dex Horthy, HumanLayer

AAI Engineer
Computing/SoftwareManagementInternet Technology

Transcript

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)

Key Takeaway

Pour résoudre des problèmes complexes dans des bases de code existantes sans générer de déchets, les développeurs doivent passer d'un simple usage de prompts à une ingénierie de contexte rigoureuse basée sur la compaction de l'information et la planification explicite.

Highlights

Le défi du code "brownfield" : l'IA excelle sur les nouveaux projets mais génère souvent de la dette technique sur les bases de code existantes et complexes.

L'ingénierie de contexte avancée : l'utilisation de la "compaction intentionnelle" pour résumer les sessions de travail et éviter de saturer la fenêtre de contexte du modèle.

Le concept de la "Zone d'Idiotie" : au-delà de 40 % de remplissage de la fenêtre de contexte, les performances des agents LLM chutent drastiquement.

Le cycle Recherche-Plan-Implémentation (RPI) : un flux de travail structuré pour forcer l'agent à comprendre et planifier avant de modifier une seule ligne de code.

L'importance de l'alignement mental : utiliser des plans en Markdown avec extraits de code pour permettre aux leaders techniques de superviser efficacement le travail de l'IA.

Ne pas déléguer la réflexion : l'IA ne remplace pas la pensée humaine ; elle amplifie la rigueur ou, au contraire, l'absence de réflexion de l'utilisateur.

Timeline

Introduction et le problème du code complexe

Dex Horthy introduit la session en s'appuyant sur des données montrant que l'IA génère souvent du travail bâclé dans les environnements logiciels matures. Bien que l'IA fonctionne parfaitement pour de petits tableaux de bord créés de zéro, elle peine face à des bases de code Java vieilles de dix ans. L'auteur souligne que l'utilisation naïve de l'IA crée des "usines à dette technique" où l'on passe son temps à corriger les erreurs de la semaine précédente. Ce constat pose le décor pour la nécessité d'une nouvelle approche appelée l'ingénierie de contexte. Il affirme que pour tirer le meilleur des modèles actuels, il faut changer radicalement notre manière de collaborer avec eux.

La genèse du système de compaction intentionnelle

L'orateur raconte comment son équipe a multiplié son rendement par trois en modifiant sa méthode de travail après une expérience initialement décevante avec Claude Code. Ce succès repose sur un système viral de prompts nommé "recherche, plan, exécution" qui vise à éliminer le code inutile. L'objectif est de maintenir une cohérence mentale tout en déléguant intelligemment des tâches aux agents sans perdre le contrôle. Cette phase de transition a duré huit semaines et a nécessité une refonte complète de leur processus de création logicielle. L'enjeu est de pouvoir s'attaquer à des problèmes complexes sans produire de "code poubelle".

Stratégies de gestion de la fenêtre de contexte

Cette section détaille les méthodes pour éviter l'épuisement du contexte, notamment la technique de repartir de zéro dans une nouvelle fenêtre dès qu'une conversation s'égare. Dex présente la "compaction intentionnelle", qui consiste à demander à l'agent de résumer l'état actuel de son travail dans un fichier Markdown avant de changer de contexte. Il explique que les LLM sont sans état (stateless) et que leur performance dépend uniquement de la qualité des tokens injectés en entrée. Un point crucial est fait sur la "trajectoire" : si l'on passe son temps à réprimander l'IA, elle finit par prédire de futures erreurs pour satisfaire ce schéma d'interaction. Il faut donc nettoyer le contexte pour ne garder que la vérité technique et les informations pertinentes.

La Zone d'Idiotie et l'usage des sous-agents

L'orateur introduit le concept académique de la "zone d'idiotie", située au-delà de 40 % de remplissage de la fenêtre de contexte de Claude. Plus le contexte est saturé de données inutiles comme du JSON ou des UUID, plus les capacités de raisonnement du modèle diminuent. Pour contrer cela, il préconise l'usage de sous-agents dont le rôle n'est pas d'imiter des humains, mais de contrôler strictement le contexte. Un sous-agent peut explorer une base de code massive et renvoyer uniquement un message succinct à l'agent parent pour lui indiquer le fichier exact à modifier. Cette architecture permet de maintenir l'agent principal dans une "zone intelligente" de haute performance.

Le cycle RPI (Recherche, Plan, Implémentation)

Dex détaille le flux de travail RPI qui permet de structurer l'intervention de l'IA de manière rigoureuse. La recherche identifie objectivement le fonctionnement du système, tandis que la planification définit des étapes explicites incluant des extraits de code et des méthodes de test. L'implémentation devient alors une étape triviale car le plan est si précis qu'un modèle moins puissant pourrait l'exécuter sans erreur. Il illustre l'efficacité de cette méthode par une anecdote où il a livré 35 000 lignes de code en une journée sur un projet complexe en Rust. Enfin, il critique le terme de "développement piloté par les spécifications" (SDD), le jugeant trop flou à cause de la diffusion sémantique.

Tactiques pratiques pour les organisations

L'orateur propose quatre étapes tactiques, incluant la création de documents d'accueil et la divulgation progressive du contexte par niveaux de répertoires. Il compare la gestion du contexte au film "Memento", où le protagoniste doit lire ses propres notes pour savoir ce qu'il fait. L'idée est d'éviter d'importer tout le contexte d'un coup pour ne pas saturer la mémoire de travail de l'agent. Dex souligne que les plans Markdown servent aussi d'outil d'alignement pour les équipes humaines, permettant aux leaders techniques de réviser l'intention sans lire chaque ligne de code. Cette approche transforme la revue de code en une revue de stratégie et de conception.

L'importance du levier humain et conclusion

La présentation se termine sur un avertissement : il ne faut jamais sous-traiter la réflexion à l'IA, car un mauvais plan générera inévitablement du mauvais code. Dex explique qu'il existe un juste milieu entre la longueur d'un plan et sa lisibilité, et qu'il faut s'entraîner pour trouver le bon dosage d'ingénierie de contexte. Il prédit que les agents de codage deviendront un produit de base et que le vrai défi sera culturel pour les entreprises. Les ingénieurs seniors doivent guider l'adoption pour éviter que les juniors ne produisent du code médiocre que les seniors devront nettoyer. Il conclut en invitant les développeurs à pratiquer ces méthodes pour atteindre l'objectif de 99 % de code généré par IA de haute qualité.

Community Posts

View all posts