- La génération de code basée sur les LLM est récemment de plus en plus utilisée parmi les développeurs
- Le code généré automatiquement alimente des inquiétudes croissantes concernant la qualité du code et sa fiabilité
- Les développeurs constatent une hausse de la difficulté de maintenance des projets en raison d’une compréhension insuffisante du code et d’une validation incomplète
- La diffusion de l’usage de code non fiable a un impact sur l’ensemble de l’écosystème logiciel
- Avec les avancées technologiques, la nécessité de mettre en place des moyens de garantir la fiabilité est soulignée
Aperçu
Dans son blog, Jay aborde l’impact des récentes technologies de génération de code basées sur les LLM (grands modèles de langage) sur le développement logiciel. Si l’évolution de ces outils améliore l’efficacité du développement, elle fait aussi émerger des questions de fiabilité et de qualité du code.
L’essor des technologies de génération de code par LLM
- Dans le développement logiciel, les outils de génération automatique de code utilisant des LLM se diffusent rapidement
- Ils offrent une forte productivité pour l’implémentation de fonctionnalités complexes ou les tâches de codage répétitives
- Ils présentent l’avantage de permettre un prototypage rapide et d’alléger la charge liée à l’apprentissage de nouveaux langages
Les problèmes de fiabilité
- Le code généré par les LLM ne fonctionne pas toujours comme prévu
- L’intention et la logique de conception internes du code sont parfois floues, ce qui complique les processus de compréhension et de vérification
- Si les phases de revue et de test sont insuffisantes, des bugs ou vulnérabilités inattendus peuvent apparaître
Maintenance des projets et impact sur l’écosystème
- Le code généré automatiquement souffre souvent d’un manque de documentation et d’explications insuffisantes
- Les développeurs ont du mal à comprendre le principe de fonctionnement du code, ce qui accroît la complexité de maintenance
- Il existe un risque de dégradation de la culture de développement de logiciels fiables
Conclusion et recommandations
- Les technologies de génération de code basées sur les LLM sont innovantes, mais garantir leur fiabilité est un enjeu essentiel
- Lors de l’adoption de code généré automatiquement, la nécessité de renforcer la validation et de mener des revues de code systématiques est soulignée
- À long terme, il est important d’établir des standards pour préserver la confiance dans l’écosystème informatique
1 commentaires
Avis sur Hacker News
https://archive.is/5I9sB
Fonctionne même avec de vieux navigateurs et ne nécessite JavaScript que lors du passage par CloudSnare
Un ami répète toujours que « l’innovation avance à la vitesse de la confiance », et depuis GPT-3 cette phrase me revient sans cesse
La vérification coûte cher, et le principal moyen de réduire ce coût, c’est la confiance. Je ne vois pas comment on pourrait en venir à faire confiance aux LLM. Ils sont très fluides, aussi bien en code qu’en langage naturel, mais ils s’engouffrent volontiers dans des terriers de lapin fractals sans fin, et adoptent aussi des comportements qu’on jugerait malveillants chez un humain
Ce nouveau monde où il faut toujours tout vérifier est assez épuisant et, franchement, très lent
C’est trop utile pour être ignoré, et la confiance se construit toujours brique par brique. Il ne faut pas oublier que les humains ne sont pas très fiables à la base non plus. Comme pour la conduite automobile, leur capacité à produire du code avec moins de bugs sur des routes prédéfinies dépassera bientôt celle des humains, puis il ne restera qu’une bataille de fondamentaux pour améliorer la complexité
En science, on construit la confiance au fur et à mesure
Au travail, j’ai vécu ça d’une manière inattendue. Un collègue et moi étions sous pression pour montrer des progrès, et nous avons décidé de merger à la hâte un assez gros refactoring sur lequel je travaillais. C’était une PR en brouillon, mais on l’a mergée pour maintenir l’élan, et la semaine suivante quelques bugs sont apparus dans des zones de code non testées
Pendant le débogage, mon collègue a laissé entendre qu’il supposait que je l’avais écrit avec l’IA, et qu’il trouvait frustrant d’essayer de comprendre a posteriori du code généré par IA. Mais ce code n’avait pas été écrit avec l’IA. Bien sûr, j’utilise l’IA pour écrire du code, mais celui-ci avait été écrit à la main, en réfléchissant soigneusement à toute la conception. Les bugs n’étaient pas des défauts fondamentaux du refactoring, mais de petits oublis survenus en adaptant l’ancien code à l’API modifiée
Au final, comme nous avons pu parler explicitement de la tension avec mon collègue, cela s’est transformé en une expérience de construction de confiance. C’était une façon assez douce de se confronter à la force de ce qui se passe en ce moment. Avec le recul, je suis content que ça se soit résolu ainsi, et j’imagine que dans un autre environnement de travail, cela aurait pu devenir bien plus sale. Il faut être prudent
Il y a environ quatre ans, j’ai fait une grosse bêtise. Un journal local avait publié un article contenant une affirmation absurde sur une personne, en s’appuyant principalement sur une photo comme preuve, et j’ai envoyé directement un e-mail au rédacteur en chef pour expliquer pourquoi j’étais convaincu que l’image avait été manipulée. Mon raisonnement reposait sur une incompréhension : j’avais mal interprété le fait que la personne en question avait posé avec plusieurs personnes lors d’un meet-and-greet, en gardant presque la même position et la même posture. Le rédacteur en chef l’a mal pris et m’a répondu sur un ton moqueur ; quand je n’ai pas lâché, il a compris que je n’étais pas un agitateur mais simplement idiot, et m’a partagé la vidéo complète non publiée d’où provenait la photo. Je me suis alors profondément excusé et j’ai aussi fait un don, et pendant l’année qui a suivi, mon ego est resté dûment raboté
Avant d’envoyer l’e-mail, comme je ne voulais pas porter une fausse accusation, j’avais partagé la photo avec des amis posés pour leur demander leur avis, et comme eux aussi avaient conclu qu’il y avait de fortes chances que l’image ait été manipulée, j’étais assez sûr de moi. Aujourd’hui, je fais implicitement confiance à ce journal et aux personnes concernées, mais il a fallu un travail énorme pour convaincre ne serait-ce qu’une seule personne
La prémisse est difficile à comprendre. Si l’on fait confiance à quelqu’un parce qu’il écrit du bon code, cette confiance a été acquise parce que son code fonctionnait bien, et non parce qu’il existerait dans son esprit un quelconque modèle mental a priori « produisant du bon code »
Si quelqu’un utilise un LLM pour produire du code sans bugs, on lui fera confiance. Si quelqu’un utilise un LLM pour produire du code plein de bugs, on ne lui fera pas confiance. En quoi est-ce différent de l’époque où cette personne écrivait du code uniquement avec sa propre tête ?
À cause des LLM, il devient très difficile de juger immédiatement de la qualité du développeur qui a soumis un patch en ne regardant que le code proposé. Si l’on ne peut pas évaluer quel type de personne on a en face, on revient à une situation de « confiance zéro » où il faut tout examiner de très près. Autrement dit, il n’existe plus de « raccourci de revue » sûr, et cela peut être douloureux dans les endroits qui faisaient fonctionner leur travail en s’appuyant sur ce genre de signaux. Si l’équipe est déjà compétente et bénéficie d’un haut niveau de confiance, ce problème ne s’applique pas, et le concept lui-même risque de sembler étrange
On fait davantage confiance à un contributeur s’il explique bien ses changements. On lui fait davantage confiance s’il a déjà fait un excellent travail par le passé. On lui fait davantage confiance s’il gère bien la granularité des changements, avec des commits raisonnables. On lui fait davantage confiance s’il choisit les bons problèmes, par exemple en corrigeant des bugs avant d’ajouter de nouvelles fonctionnalités. On lui fait davantage confiance s’il montre qu’il peut maintenir le code existant, plutôt que simplement empiler des choses par-dessus. On lui fait davantage confiance s’il contribue régulièrement
Le problème est souvent une erreur de communication. La tâche peut être claire pour l’opérateur, mais à cause des fréquentes réinitialisations de contexte, il est difficile de garantir que le LLM connaît lui aussi la vue d’ensemble ; et en cas d’ambiguïté, il tend à faire des suppositions stupides. La manière dont le deep research de 4o demande des informations supplémentaires avant de faire quelque chose devrait, à mon avis, devenir la norme aussi pour la génération de code. Cela permettrait d’éviter une montagne de problèmes
Certains cas sont simples : il s’agit de savoir si cette routine renvoie ou non la valeur attendue. Mais d’autres situations sont bien plus complexes, car il faut anticiper la façon dont le code interagira avec d’autres parties du système et quels cas limites peu visibles peuvent exister. Dans ces situations, pour écrire du code « sans bugs », l’auteur doit comprendre les implications du code ; et si le développeur ne comprend pas exactement ce que fait le code écrit par le LLM, il ne peut pas non plus en comprendre les implications. Cette charge est alors transférée au reviewer, dont le travail augmente. C’était cela, la prémisse
Une bonne règle empirique consiste à simplement rejeter le travail impliquant un LLM et à ignorer aussi les communications écrites par un LLM. Même pour quelqu’un dont l’anglais est une langue étrangère, je pense que son anglais « maladroit » vaut largement mieux que des propos formulés à sa place par ChatGPT. À mesure que les problèmes graves des LLM deviendront plus évidents, ce type de politique deviendra probablement la norme générale, et j’espère que ce sera le cas
Les LLM donnent à n’importe quel type de mauvais travail l’apparence d’un travail plausiblement bon. Il est donc raisonnable de déprécier automatiquement le résultat d’une personne qui a utilisé l’IA.
Il y a longtemps, un membre de ma famille s’est révélé être un escroc. Après qu’il a été démasqué, j’ai coupé les ponts en disant que je ne le connaissais pas, et il m’a répondu : « Je suis la même personne que celle que tu connais depuis 10 ans ». J’ai répondu : « Peut-être. Mais je viens seulement de comprendre que je ne savais absolument pas qui tu étais, et que je ne pourrai jamais le savoir. »
Nous partons tous du principe que les gens dans notre vie ne cherchent pas activement à nous nuire. Quand cette confiance se brise, elle se brise très violemment. Quelqu’un qui utilise l’IA ne peut pas dire : « c’est mon travail ». Parce qu’on ne peut pas savoir si c’est vraiment son travail. Quelqu’un qui a utilisé l’IA ne peut pas non plus prétendre que c’est du bon travail, sauf s’il le comprend en profondeur, et il est probable qu’il ne le comprenne pas en profondeur. J’ai constaté que beaucoup de mes étudiants affirmaient avoir lu et compris des textes que j’avais écrits, alors qu’en réalité ce n’était pas le cas. Et si j’étais une IA, et qu’ils reprenaient mon travail en mettant leur nom comme auteur ? Ils seraient incapables d’expliquer quoi que ce soit, de le défendre ou d’en assurer la suite. Ce problème existait déjà avant l’IA, mais il est désormais dix fois pire.
Je suis quelqu’un qui a consacré « plus de 10 000 heures » à la programmation d’applications complexes avant l’arrivée de LLM utiles. Pendant des années, j’ai passé toutes mes soirées à fouiller la documentation et le code source des autres, totalement absorbé par l’apprentissage du full-stack. À la fin, cette immersion a mené à un burnout sévère, ma santé s’est dégradée et mon mariage a vacillé. Juste après avoir lancé mon application, j’ai dû tout arrêter complètement pendant trois ans pour récupérer, et j’étais convaincu que je ne pourrais plus jamais m’y remettre.
Après avoir beaucoup entendu dire que les LLM étaient devenus assez bons en code, je suis revenu prudemment devant mon ordinateur, et c’est là que mon expérience diverge fortement de ces inquiétudes. Je ne peux pas accepter l’idée que « quelqu’un qui utilise l’IA ne peut pas dire : “c’est mon travail” ». Quand j’utilise un LLM, je suis l’architecte et le validateur final. Je définis la vision, je conçois le système, et je relis chaque ligne générée par le LLM avec un outil de diff. Récemment, j’ai construit avec un LLM un modèle d’optimisation complexe pour le moteur de devis de mon entreprise. Utiliser un vrai modèle d’optimisation a toujours été la « bonne » approche, mais auparavant cela aurait demandé des mois de travail pénible à apprendre chaque détail de la bibliothèque et à lire le code des autres. Cette fois, je l’ai fait en une semaine. Est-ce que cela me donne l’impression que c’est mon travail ? Absolument. J’avais simplement un assistant infatigable, brillant, mais parfois défaillant.
Mon expérience contredit aussi l’idée que l’utilisateur « ne le comprendra pas en profondeur ». Pour utiliser efficacement un LLM sur quelque chose de non trivial, il faut une compréhension plus profonde des fondamentaux afin de le guider et de repérer les erreurs subtiles qui reviennent souvent. Sans mes années d’expérience, je n’aurais pas pu piloter un développement complexe multi-modules, déboguer les sorties, ni savoir qu’un travail plausiblement bon en apparence était en réalité faux, par exemple à cause d’un problème de type N+1.
Je comprends l’expérience côté enseignant. Le problème des étudiants qui font semblant de comprendre grâce à ces outils est réel et difficile. Dans le monde académique, l’objectif est le processus d’apprentissage, c’est-à-dire acquérir une part substantielle de ces 10 000 heures. Mais dans le monde professionnel, l’objectif est le résultat, et c’est un nouvel outil puissant pour obtenir de meilleurs résultats. Je ne sais pas comment les enseignants devraient former les étudiants dans cette nouvelle réalité, mais diaboliser l’usage des LLM n’est probablement pas la meilleure solution.
Pour moi, cela n’a pas rendu un mauvais travail plus séduisant. Cela a rendu à nouveau possible un excellent travail, tout en me permettant de reprendre ma vie en main. Cela m’a rendu le plaisir du craft qu’est le développement logiciel, sans me détruire moi ni ma famille, et je suis reconnaissant d’avoir aujourd’hui une vie bien plus équilibrée.
Pour moi, on en est déjà là. J’ai lu « désolé d’avoir négligé cela, vous avez tout à fait raison » un nombre incalculable de fois. Environ 8 ou 9 fois sur 10.
En parallèle, je continue de voir des gens copier sans réfléchir du code généré par des LLM payants, puis s’énerver quand il ne fonctionne pas comme prévu. À noter que c’est encore la meilleure option. Parce qu’il vaut mieux que ce soit manifestement cassé plutôt que d’avoir l’air de fonctionner en surface.
Cela dit, les moteurs prédictifs ne sont pas encore capables de faire de la vraie ingénierie. Si on ne leur demande pas explicitement d’utiliser quelque chose comme un generator Python, il y a de fortes chances qu’ils produisent du code qui consomme une quantité énorme de mémoire. Malheureusement, ce n’est pas très différent de beaucoup de programmeurs Python que je connais, mais c’est aussi un exemple de cas où un LLM est exactement aussi mauvais qu’on le dit. Le point positif, c’est que cela pousse les gens à réellement rédiger des spécifications plus détaillées qu’une ligne du type « ajouter une fonctionnalité ».
Là où les agents IA nous sont le plus utiles, c’est sur le code legacy que personne ne met en priorité. Nous avons un extracteur de données écrit au millénaire précédent, qui utilise environ 200 coordonnées codées en dur pour extraire des données d’un certain type de document reçu par fax. Le document n’avait pas changé depuis une trentaine d’années, donc cela fonctionnait bien, mais il a récemment changé, et Copilot a mis environ 30 secondes à corriger les coordonnées. Pour un humain, cela aurait probablement été une journée entière de travail extrêmement fastidieux. En revanche, je n’ai aucune idée de la façon dont notre industrie compte former des experts à l’ère du vibe coding.
Lutter contre les LLM, c’est pisser face au vent
Les LLM tels qu’ils existent aujourd’hui semblent rendre les développeurs plus productifs. Ils pourraient même apporter un gain plus important aux développeurs moins expérimentés qu’aux développeurs chevronnés. Une hausse de productivité, peut-être même un multiplicateur très élevé, ne sera pas abandonnée à cause d’obstacles dressés par des gens opposés à la technologie pour une raison ou une autre.
Même si un nouvel outil de productivité causait des dégâts énormes — par exemple un bug mettant un grand service hors ligne pendant un bon moment —, il ne serait pas arrêté s’il apporte une productivité significative. La seule voie raisonnable est de travailler avec la technologie et d’en atténuer les faiblesses. Et ces mesures d’atténuation ne doivent pas être un ensemble de règles qui annulent complètement les gains de productivité de la nouvelle technologie. Elles doivent fonctionner avec la technologie dans le sens d’une adoption accrue ; sinon, elles seront contournées.
D’après mon expérience, les personnes qui affirment avec force que les LLM les ont rendues 10 fois plus productives sont le plus souvent des développeurs frontend relativement juniors, ou des développeurs de startups en série qui créent sans cesse de nouvelles apps à partir de zéro. Ce sont bien sûr des cas d’usage tout à fait valables, mais c’est aussi pourquoi un développeur frontend junior et un développeur C embarqué senior risquent facilement de parler à côté l’un de l’autre lorsqu’ils discutent des gains de productivité liés à l’IA.
Plutôt que de dire que la seule approche raisonnable est de travailler avec la technologie et d’en atténuer les faiblesses, il suffit de l’utiliser avec davantage de discernement. Par exemple, l’idée même d’un « agent » IA est-elle bonne ? Le récent incident Copilot[0] a donné à MS et à l’IA une image ridicule. Il est possible que tenter de laisser l’IA travailler de manière autonome ne soit tout simplement pas très avisé.
Une analogie récente serait la blockchain et les cryptomonnaies. Qu’on les aime ou non, le succès de Coinbase et d’autres montre clairement que la blockchain a trouvé un cas d’usage réel, mais étroit. Mais pendant la surchauffe crypto, il y avait des gens qui disaient vouloir « suivre la chaîne d’approvisionnement des grains de café avec la blockchain ». En 2025, cela ressemble à une blague exagérée sur Twitter, mais en 2020 IBM essayait réellement de vendre ce genre de chose[1]. Peut-être qu’un jour, avec le recul, nous verrons que les agents IA ou certaines applications actuelles de l’IA générative étaient la blockchain du café de cette bulle.
[0] https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my...
[1] https://www.forbes.com/sites/robertanzalone/2020/07/15/big-c...
Mais cela ne veut pas dire que la combinaison modèle/humain répond plus efficacement aux besoins de l’utilisateur. Cela veut dire qu’elle produit « plus de code ». Aucun LLM ne va sortir un ensemble de changements qui supprime 2 000 lignes de code. C’est ainsi qu’on comprend que dire « cela rend les ingénieurs plus productifs » parle de la quantité de code générée.
Vous semblez présenter cela comme un choix binaire entre utiliser ou non les LLM, alors que l’auteur parle surtout de réduction des risques. Pour prendre une analogie, c’est comme si l’auteur soulignait que quelques voitures ont explosé et disait que, puisque les anciens chevaux n’explosaient pas, il faudrait rendre les voitures moins explosives avant de faire tourner l’usine de colle ; mais vous semblez considérer que l’auteur est fondamentalement opposé au développement des voitures lui-même.
Aujourd’hui encore, j’ai une réticence à utiliser GPT, alors que récemment mes collègues disent « ChatGPT dit que » ou « ce code a été produit par ChatGPT ». Je tire une certaine fierté à écrire moi-même le code et à ne pas utiliser GPT, mais en même temps j’utilise Google et Stack Overflow. On pourrait dire que c’est aussi une version plus lente de GPT.
Il me semble que l’auteur passe à côté du fait que des acteurs imparfaits et probabilistes peuvent eux aussi construire des systèmes déterministes fiables
On ne ferait pas confiance à un outil de garbage collection sur la base de la fiabilité de son auteur ; on lui ferait confiance après de nombreux tests montrant qu’il fait bien ce qui était prévu. On peut tout à fait imaginer une érosion de la confiance à l’avenir, et j’ai l’impression que cela donnera davantage d’élan au développement piloté par les tests. Ne pas faire confiance : vérifier.
La question la plus importante est : qui teste les tests eux-mêmes ? Dans le développement traditionnel, toute la logique est implémentée deux fois : une fois dans le code, une fois dans les tests. Les tests vérifient le code et, inversement, le code vérifie implicitement les tests. Il est assez courant que le bug soit dans les tests et non dans le code applicatif. On ne peut pas faire aveuglément confiance aux tests et attendre qu’un agent trouve un moyen de répliquer un bug de test dans le code.
Pour reprendre l’exemple du garbage collection, bien sûr, un jour, un système agentique pourra peut-être lancer quelque chose et le faire converger à coups de harnais de tests et de corrections de bugs. Mais imaginez utiliser le modèle comme garbage collector/outil lui-même. Par exemple, à chaque sweep, on lui enverrait la mémoire du programme en lui demandant de libérer les blocs inutiles. On ne pourrait jamais lui faire confiance pour identifier exactement les bons blocs mémoire, et aucun « patch » ni « fine-tuning » ne permettra d’y parvenir.
Dans les abstractions passées comme la JVM, lorsqu’une sortie déterministe — en l’occurrence l’assembleur émis par le JIT — est incorrecte, le bug est corrigé et cette abstraction ne présente plus jamais le même défaut. Ce n’est pas le cas des LLM. Quand on parle des outils de développement passés qui ont changé toute la nature de l’industrie, cette différence est, à mes yeux, cruciale. Je ne dis pas que les LLM n’auront pas une influence profonde sur les façons de travailler à l’avenir. Je pense simplement que nous sommes entrés dans un territoire totalement inconnu, avec très peu de précédents historiques.
Quant à l’idée que le développement piloté par les tests va prendre plus d’ampleur, je ne comprends pas pourquoi le TDD est toujours présenté comme une solution miracle à tous les problèmes de construction logicielle. Le nombre de fois où j’ai vu du TDD partir de mauvais tests et produire un mauvais logiciel est franchement embarrassant.
Il faut spécifier le résultat attendu, pas le processus. Attendre des contributeurs qu’ils comprennent un patch est une bonne idée
Mais recommander, ou exiger, qu’un junior évite pendant un temps les outils d’assistance par LLM durant son onboarding est une très mauvaise idée. L’onboarding comporte beaucoup de problèmes de configuration d’environnement assez aléatoires, et les LLM sont souvent plutôt bons dans ce domaine. Il s’agit aussi de se mettre à niveau sur le code et la documentation, et il existe d’excellents outils de recherche et de synthèse de texte que l’on peut vouloir partager.
Si l’on supprime de sa vie toutes les difficultés et toute la complexité de façon fluide, il paraît assez évident qu’on finira bientôt par ne plus avoir la moindre idée de quoi faire lorsqu’on rencontrera une difficulté ou de la complexité. Je suis le seul à penser ça ?
Je n’avais jamais entendu parler de ce phénomène où les LLM « approximent quelque chose de proche de la bonne réponse pendant un certain temps, puis voient leur précision chuter brutalement avec le temps », que l’auteur appelle la falaise de l’IA. D’autres l’ont-ils vécu ?
Les générateurs actuels ont tendance, avec le temps, à rendre les choses plus complexes plutôt que plus simples. C’est toujours moi qui demande au LLM de refactorer pour simplifier, ou qui refactore moi-même quand c’est devenu trop complexe pour lui. Donc, au moins avec la génération actuelle de LLM, si on se contente de « lâcher la bride au LLM » et de le laisser faire, il semble assez inévitable qu’il finisse par produire un gigantesque bazar à la Rube Goldberg, que vous devrez ensuite nettoyer.
Pour relier cela au propos de l’article : une personne expérimentée remarquera tôt que le LLM commence à l’entraîner au large et saura retrouver le chemin des eaux peu profondes même si elle s’est un peu éloignée. Un débutant se retrouvera hors de sa profondeur et perdu en mer avant même de comprendre ce qui s’est passé.
Imaginez qu’il y ait, dans l’entrée de contexte, 10 000 tokens corrects à 99 %. Chaque fois que le LLM répond, il ajoute 1 000 tokens corrects à 90 %. Après quelques échanges à corriger le LLM, la fenêtre de contexte est remplie en grande partie par ses propres sorties résiduelles. Pire encore, les erreurs s’accumulent. Même les 90 % corrects ne sont qu’une extrapolation correcte d’une discussion portant sur du code erroné, et le LLM accorde plus d’importance aux tokens les plus récents. Le même problème apparaît aussi en prose.
Avec les modèles de raisonnement, ce problème peut empirer. Tout le processus de raisonnement est dans le contexte, et si la réflexion part vraiment sur une tangente, elle sème des graines toxiques qui alimentent la dégradation. J’aimerais qu’une forme d’élagage du contexte soit implémentée, afin de couper le contexte non pertinent lorsqu’il apparaît. Pour l’instant, quand je sens que la dégradation s’installe, je fais un résumé et je passe à une nouvelle instance.
C’est beaucoup moins problématique avec des outils agentiques comme claude code, codex ou gemini cli. Ils gèrent leur propre fenêtre de contexte et peuvent exécuter des outils de développement pour effectuer eux-mêmes des sanity checks.
Ce processus entraîne à prendre l’habitude de documenter l’état actuel du travail pour que le nouvel agent puisse se mettre à niveau.