Comment les outils de codage IA modifient un code inconnu

L'autocomplétion, les assistants et les agents peuvent tous produire une fonction plausible. Cette ressemblance superficielle a poussé les fournisseurs et les équipes d'ingénierie à employer un seul nom pour trois modes de fonctionnement différents. Ce nom masque l'essentiel : ce que l'outil peut observer, ce qu'il peut modifier et les preuves qu'il recueille avant de déclarer son travail terminé.

Sur une base de code que vous connaissez, ces différences jouent sur la vitesse. Sur un système dont les auteurs ne sont plus là, elles déterminent si vous préservez un comportement que personne n'a pensé à documenter. Une autocomplétion prédit le texte près du curseur. Un assistant répond à partir d'un contexte limité. Un agent choisit des actions, en observe les résultats et poursuit son travail. Confondre ces outils donne une fausse assurance bien avant de produire une erreur de compilation.

Comment l'autocomplétion prédit la prochaine modification locale

L'autocomplétion propose du texte à partir du code autour du curseur et du contexte supplémentaire fourni par son environnement. Son unité de travail naturelle est le prochain token, la prochaine ligne ou un petit bloc. Même lorsqu'une suggestion couvre une fonction entière, l'interaction reste prédictive : l'outil propose du texte et le développeur décide de l'accepter ou non.

Ce modèle est excellent quand l'intention se trouve déjà dans le fichier courant. Répéter un modèle de gestion d'erreur, compléter un switch sur une enum connue, construire une table de tests à partir des cas voisins ou écrire une autre méthode conforme à une interface visible sont de bons usages. Le développeur garde la conception en tête. L'outil évite de taper et rappelle la syntaxe.

Le Language Server Protocol fait ici une distinction utile. Sa requête de complétion contient une position dans le document et peut contenir un caractère ou un type de déclenchement. Le protocole ne définit pas de mission comme « remplacer cette couche de stockage », ni de boucle de preuve pour valider le remplacement. Un produit peut enrichir la complétion avec des extraits indexés du dépôt, mais l'interaction s'arrête toujours à une suggestion. Une recherche plus large peut améliorer l'hypothèse sans la transformer en enquête.

L'autocomplétion cesse d'être utile quand la justesse dépend de faits situés hors du voisinage fourni. Un paragraphe COBOL peut mettre à jour un champ dont la disposition vient d'un copybook, tandis que JCL choisit un autre jeu de données en fin de mois. Un gestionnaire d'événement VB6 peut sembler inutilisé jusqu'à ce qu'un fichier de formulaire le lie par son nom. Une procédure PL/SQL peut dépendre d'une variable de paquet initialisée lors d'un appel antérieur. Le fait manquant possède souvent une syntaxe valide et ne laisse aucun indice visible au point de modification.

Observez le geste d'acceptation. Appuyer sur Tab signifie « insérer ces caractères », pas « j'ai établi que ce comportement est sûr ». Les équipes se mettent en danger quand la facilité physique de l'acceptation remplace discrètement la revue. Une longue complétion mérite plus de méfiance, car sa surface soignée peut cacher davantage d'hypothèses.

Comment un assistant travaille dans la conversation fournie

Un assistant de codage répond à une demande avec les éléments placés dans son contexte : code sélectionné, fichiers ouverts, extraits récupérés, diagnostics, instructions et échanges précédents. Son unité naturelle est la conversation. Il peut expliquer une routine, comparer des conceptions, préparer un patch ou raisonner sur une erreur avec plus de latitude que l'autocomplétion.

Cette latitude change la qualité du travail. Vous pouvez lui demander de suivre une valeur dans quatre fonctions, de repérer un invariant implicite ou d'expliquer pourquoi une refonte proposée modifie les limites de transaction. Vous pouvez contester sa première réponse et ajouter le fichier qu'il n'avait pas vu. C'est utile pendant l'exploration, surtout quand un développeur reste responsable du choix des preuves.

La limite passe facilement inaperçue, car les interfaces de chat parlent avec aisance de fichiers qu'elles n'ont jamais ouverts. Si l'assistant affirme : « Cette fonction n'est appelée que par l'importateur par lots », cette affirmation peut être une déduction tirée de l'extrait collé plutôt que le résultat d'une recherche dans le dépôt. Demandez ce qu'il a inspecté. Une réponse solide doit nommer les sites d'appel, la configuration, les liaisons générées ou les observations d'exécution qui soutiennent sa conclusion. Sinon, traitez cette affirmation comme une hypothèse.

Les fenêtres de contexte ne règlent pas la sélection du contexte. Un million de lignes peuvent être mal exploitées même si un modèle accepte une entrée énorme. Les arborescences contiennent du code généré, des versions dupliquées, des définitions de base de données, des scripts de déploiement, des formats binaires et des tests dont l'autorité varie. Ajouter des tokens au prompt n'indique pas à l'assistant quel copybook est actif en production ni laquelle de deux formules presque identiques répond à la règle réglementaire.

Servez-vous d'un assistant pour transformer l'incertitude en questions explicites. Demandez-lui d'énumérer les hypothèses derrière un patch, de nommer les fichiers qui pourraient les réfuter et de décrire le test de comportement qu'il s'attend à réussir. Un relecteur obtient alors des éléments concrets à inspecter. Ne demandez pas de score de confiance. Un pourcentage précis en apparence n'a aucune calibration commune et n'ajoute rien aux preuves.

Comment un agent modifie le dépôt par une boucle d'actions

Un agent de codage peut choisir et exécuter des actions, puis utiliser leurs résultats pour choisir l'action suivante. Il peut parcourir l'arborescence, ouvrir des fichiers, modifier plusieurs modules, lancer un compilateur, exécuter des tests, examiner les échecs et revoir le patch. Son unité naturelle est une tâche assortie d'une condition d'arrêt, pas une réponse unique.

La boucle compte plus que la fenêtre de chat. Un agent utile procède à peu près ainsi :

1. Il détermine l'état du dépôt et les instructions applicables.
2. Il recherche définitions, appelants, configuration, tests et liens générés.
3. Il effectue une modification limitée sur une branche ou dans un worktree isolé.
4. Il lance les contrôles capables de réfuter la modification.
5. Il examine le diff et signale les incertitudes restantes.

Chaque observation peut réorienter le travail. Un test en échec peut révéler une règle d'arrondi non documentée. Une erreur du compilateur peut faire apparaître un tag de build qui sélectionne une autre implémentation. Une recherche peut trouver un second langage qui appelle la même routine de base de données. L'agent peut suivre ces branches sans attendre qu'une personne colle le fichier suivant.

Pouvoir agir ne signifie pas disposer d'une autonomie illimitée. L'écriture de fichiers, les commandes shell, l'accès réseau, les identifiants, les droits de déploiement et les règles d'approbation sont des capacités distinctes. Un outil qui modifie l'arborescence sans pouvoir lancer les tests possède une boucle de preuve plus courte. Un outil autorisé à exécuter n'importe quelle commande en production possède un modèle de permissions dangereux. Appeler les deux « agents » n'apprend presque rien à un responsable de l'ingénierie.

La condition d'arrêt mérite aussi d'être examinée. « Les tests passent » ne suffit que si ces tests couvrent le comportement exposé. « Le build réussit » prouve des contraintes de type et d'édition de liens, pas l'équivalence fonctionnelle. L'agent doit s'arrêter parce qu'il a satisfait un critère d'acceptation explicite et épuisé les contrôles convenus, pas parce qu'il ne trouve plus d'action évidente ou que le diff est propre.

Dans un système inconnu, le contexte manquant est le risque principal

Dans un code inconnu, le plus grand risque n'est généralement pas de produire la syntaxe de remplacement. Il faut découvrir le contrat de comportement qui traverse les sources, le contrôle des jobs, les données, l'exploitation et les habitudes des utilisateurs. Les auteurs d'origine ont souvent placé ce contrat dans des endroits qu'une recherche moderne dans le dépôt classe mal.

Prenons un job de facturation nocturne. Une routine de calcul est claire quand on la lit seule, donc un assistant la réécrit dans un langage moderne et ses tests unitaires passent. Le comportement en production dépend aussi d'un code de condition JCL qui saute une étape après une entrée partielle, d'un enregistrement à largeur fixe où un montant vide diffère de zéro et d'une procédure opérateur qui conserve un fichier intermédiaire lors d'une relance. Aucun de ces faits ne doit nécessairement apparaître dans la routine. Une réécriture fidèle localement peut tout de même facturer deux fois lors d'une relance.

Le secteur confond ici deux formes de contexte. Le contexte source correspond aux éléments lisibles par l'outil : code, schémas, fichiers de build, tickets et tests. Le contexte d'exploitation montre ce que le système fait réellement : requêtes de production, entrées par lots, sorties, horaires, effets secondaires, reprise après erreur et décisions des opérateurs. Ajouter du contexte source ne peut pas reconstituer automatiquement le contexte d'exploitation. La conséquence est nette : comprendre le dépôt aide une migration, mais ne prouve pas à lui seul la parité de comportement.

Les systèmes anciens ajoutent des liens entre langages. COBOL appelle de l'assembleur ou des procédures de base de données. Les programmes RPG dépendent de commandes CL et de fichiers décrits à l'extérieur. Une page Classic ASP invoque des composants COM écrits en VB6. Un classeur Excel appelle une requête Access qui appelle une procédure stockée. Un outil qui n'indexe que le langage nommé dans le ticket dessine une carte propre où des routes manquent.

Avant de modifier un tel système, écrivez la frontière des preuves. Quels dépôts sont inclus ? Quels ordonnanceurs, schémas, formats de données et traces d'exécution sont disponibles ? Quels appels externes seront simulés ? Quelles actions des opérateurs resteront hors observation ? Ce n'est pas de la paperasse de projet. Cette frontière indique les affirmations que l'outil peut soutenir et celles qui exigent encore une personne connaissant la production.

La parité de comportement exige un oracle extérieur au nouveau code

Une réécriture doit être jugée d'après le comportement observé, pas d'après l'apparente logique de la nouvelle implémentation. L'oracle le plus sûr est indépendant du code généré : les mêmes entrées enregistrées sont envoyées aux deux versions, puis les sorties et effets secondaires sont comparés selon des règles de normalisation explicites.

Un petit banc de parité peut commencer par un manifeste qui précise ce qui doit être égal :

{
  "case": "month_end_partial_input",
  "input": "fixtures/partial.dat",
  "compare": ["stdout", "records", "exit_code"],
  "ignore": ["run_id", "processed_at"]
}

Exécutez ensuite les anciennes et nouvelles implémentations depuis un état propre et conservez des résultats lisibles par une machine :

case                         old  new  records  result
month_end_partial_input      04   04   1827     PASS
blank_amount_field           00   00   19       PASS
operator_rerun_after_step_3  00   08   641      FAIL

La ligne en échec est plus utile qu'une revue de code pleine d'assurance. Elle donne à l'équipe une entrée reproductible, le premier effet divergent et un point de départ pour enquêter. La comparaison doit porter sur les données retournées, les écritures en base, les messages émis, les fichiers, les codes de sortie et l'ordre chaque fois qu'un consommateur l'observe. Ne normalisez que les valeurs que le contrat autorise réellement à varier, comme les identifiants d'exécution générés. Une liste d'exclusions trop large peut donner raison à toutes les implémentations.

Le trafic de production enregistré comporte des lacunes. Les chemins d'erreur rares peuvent manquer, les champs sensibles nécessitent un traitement contrôlé et les jobs par lots peuvent dépendre de l'horloge ou de l'environnement. Ajoutez des cas conçus pour les limites, les entrées incorrectes, les nouvelles tentatives et la reprise. Conservez l'ancien exécutable dans un banc isolé si les licences et l'accès à la plateforme le permettent. S'il n'existe aucun oracle indépendant, dites-le clairement et réduisez l'étendue des modifications automatiques.

Je déconseille d'utiliser les tests écrits par le modèle comme seule suite d'acceptation. Cette recommandation est populaire parce que le modèle peut produire code et tests d'un seul coup, et que le build vert donne une impression d'achèvement. Les deux artefacts peuvent partager la même erreur d'interprétation. Les tests générés expriment des règles connues; ils ne découvrent pas indépendamment les règles que la génération a oubliées.

Le travail de parité échoue quand les équipes comparent uniquement la valeur retournée dans le cas nominal. Les changements d'état s'échappent souvent par des canaux que la nouvelle conception souhaite supprimer : fichier temporaire consommé par un autre job, code d'état contrôlé par JCL, ligne de base écrite avant une erreur ou rapport trié dans l'ordre attendu par les opérateurs. Inventoriez les effets observables depuis l'extérieur. Si un consommateur peut distinguer deux exécutions, le banc doit comparer cette différence ou expliquer pourquoi le nouveau contrat peut la modifier.

Le temps mérite sa propre fixture. Les anciens programmes lisent souvent l'heure plusieurs fois, dérivent leurs dates métier de variables de l'ordonnanceur ou prennent minuit local comme limite de traitement. Figez l'heure quand la plateforme le permet et enregistrez les valeurs fournies par l'ordonnanceur. Faites de même pour les valeurs aléatoires, générateurs de séquences, paramètres régionaux, encodages et variables d'environnement. Sans entrées contrôlées, le rapport de différences se remplit de bruit et les relecteurs finissent par ignorer des échecs, dont peut-être celui qu'ils cherchent.

Comparer la base exige plus qu'un export des tables finales. Capturez les limites de transaction et les points de panne quand les appelants peuvent les observer. Deux implémentations peuvent finir avec les mêmes lignes après une réussite et réagir différemment après l'échec de la troisième écriture. Lancez des cas de panne qui interrompent le job à des points contrôlés, puis comparez les lignes validées, marqueurs de nouvelle tentative, verrous, messages émis et résultat de la procédure de relance documentée. Ce travail est fastidieux, mais il transforme l'instruction vague « préserver le comportement » en preuve contestable par un ingénieur.

Les règles de normalisation doivent être revues avec le banc. Une règle comme « ignorer tous les horodatages » est généralement trop large; elle peut cacher une date de règlement déplacée dans la mauvaise période. Préférez des règles au niveau des champs avec une justification, par exemple ignorer un identifiant de trace généré tout en comparant exactement l'horodatage métier. Quand une règle change, rejouez les cas antérieurs et notez les différences qui disparaissent. La configuration des exclusions appartient à la spécification de migration, ce n'est pas du rangement.

L'ancien système peut aussi se contredire. Les enregistrements de production peuvent contenir un défaut accepté, une correction manuelle non documentée ou un comportement qui varie selon le déploiement. Ne laissez pas l'agent choisir en silence la version la plus commode. Classez chaque écart : comportement à préserver, défaut à corriger sur décision séparée, différence autorisée ou observation non résolue. Le responsable du processus métier doit approuver les deuxième et troisième catégories. Sinon, une réécriture fait passer des changements de règle dans une revue technique.

Un résultat de parité doit pouvoir être reproduit par quelqu'un qui n'a pas exécuté la tâche initiale. Conservez la révision source, les entrées du build, l'identité des fixtures, la description de l'environnement, la version de normalisation, la ligne de commande et les artefacts de sortie. Calculez l'empreinte des fixtures volumineuses ou sensibles quand leur copie est inadaptée, mais gardez un chemin contrôlé vers les originaux. Masquez les données selon un processus défini plutôt que de modifier les fixtures au hasard, car le masquage peut changer longueurs de champ, jeux de caractères, sommes de contrôle et branches d'exécution.

Le comportement dynamique exige une autre méthode de découverte que les graphes d'appels statiques. La recherche trouvera un nom de fonction direct, mais peut manquer la réflexion, les appels par chaîne, les callbacks de base de données, l'enregistrement de plugins, les invocations de l'ordonnanceur et les noms assemblés depuis la configuration. Combinez recherche dans les sources, métadonnées du build et observation à l'exécution. Sur un système qui permet le traçage, enregistrez modules chargés, jobs exécutés, endpoints appelés, fichiers ouverts et routines de base pour des cas représentatifs. La trace ne remplace pas la lecture des sources; elle montre les parties d'une large carte qui participent au comportement observé.

Toute affirmation de couverture doit préciser son dénominateur. Dire qu'un agent « a lu le dépôt » peut signifier qu'il a listé chaque fichier, intégré certains textes, analysé les langages pris en charge ou construit un graphe de dépendances interlangage. Ce sont des opérations différentes. Demandez les décomptes par type de fichier, les exclusions explicites, les erreurs d'analyse, les symboles non résolus et les liens déduits de la configuration. Un court rapport d'exclusion inspire plus confiance qu'une déclaration générale de compréhension totale.

Enfin, testez le banc lui-même avec des mutations volontaires. Modifiez un champ comparé, inversez une sortie ordonnée, changez un code de sortie et supprimez un effet secondaire. Chaque mutation doit déclencher un échec clair. Si le banc reste vert, il n'est pas un oracle pour ce comportement. Les équipes relisent volontiers le code applicatif mais considèrent l'infrastructure de test comme neutre; dans une réécriture générée, le mécanisme de comparaison mérite au moins la même méfiance que le code qu'il juge.

L'autocomplétion gagne quand le développeur maîtrise déjà l'intention

L'autocomplétion est souvent le meilleur outil pour une modification étroite et comprise, car elle ajoute peu de délai et de procédure. Si vous connaissez le contrat, voyez les types concernés et relisez chaque insertion, une boucle d'actions ajoute du travail sans découvrir beaucoup de nouvelles preuves.

Une bonne tâche de complétion possède un rayon de revue réduit. On peut convertir des assertions répétitives en table, ajouter une branche d'analyseur conforme aux cas voisins, écrire un appel d'API familier ou compléter la sérialisation depuis un schéma visible. Le développeur peut rejeter une mauvaise suggestion en quelques secondes parce qu'il sait déjà à quoi ressemble le bon résultat.

Fixez une limite pratique. Dès que vous devez vous demander si un autre fichier contrôle le comportement, cessez d'accepter de longues complétions et cherchez. Quand la modification franchit une limite de persistance, de permission, de langage ou de job asynchrone, passez à un assistant pour l'analyse ou à un agent pour l'enquête. Le changement dépend de l'incertitude et du rayon d'impact, pas du nombre de lignes. Une modification d'une ligne dans un format d'enregistrement peut être plus risquée qu'une fixture de test de cent lignes.

Relisez la complétion comme le code d'un collègue rapide qui n'a pas assisté à la réunion de conception. Vérifiez chemins d'erreur, propriété des ressources, conversions numériques, encodage et hypothèses de concurrence. Ne récompensez pas l'outil parce qu'il reproduit le style local si ce style contient un défaut. C'est justement dans la répétition que la complétion reproduit efficacement un mauvais modèle.

Désactivez ou limitez la complétion là où une divulgation ou une insertion accidentelle serait inacceptable. Les sources réglementées, secrets dans une configuration voisine, textes juridiques générés et consoles de production demandent des règles explicites. La question n'est pas de savoir si le fournisseur du modèle est globalement digne de confiance. Il faut savoir quelles données l'environnement envoie, où l'inférence se déroule, ce qui est conservé et quels contrôles votre environnement impose.

Les assistants excellent quand la question peut être bornée

Un assistant est efficace quand un développeur peut définir l'ensemble des preuves et évaluer la réponse sans accorder de droit d'écriture. Il convient à l'archéologie du code, à la comparaison de conceptions, à la revue de patch, à l'explication de requêtes et à la transformation d'une observation d'incident en cas de test.

Posez une question bornée avec des preuves nommées. Au lieu de « explique ce sous-système », demandez : « À partir de la définition du job, de ces deux copybooks et des trois appelants, explique quand CUSTOMER-STATUS passe de H à A. Cite le fichier et le symbole de chaque transition, puis liste tout chemin que tu ne peux pas résoudre. » La réponse peut rester fausse, mais la forme demandée rend visibles les sauts sans preuve.

L'assistant doit séparer observation, déduction et proposition. Une observation indique qu'un appelant transmet un champ vide. Une déduction estime que le vide correspond probablement à un montant absent parce que deux tests attendent ce résultat. Une proposition recommande de convertir les champs vides en valeur optionnelle explicite dans le nouvel analyseur. Mélanger ces affirmations transforme un choix de conception plausible en prétendu fait sur l'ancien système.

Utilisez la conversation pour une revue contradictoire. Demandez ce qui casse si les enregistrements arrivent dans le désordre, si le job redémarre après une écriture, si une chaîne contient un caractère non ASCII ou si l'appel à la base valide de façon indépendante. Vérifiez ensuite les réponses dans les sources ou les observations d'exécution. L'assistant aide parce qu'il peut énumérer des chemins qu'un humain fatigué saute, mais une question inventée ne prouve pas que le chemin existe.

Évitez les conversations interminables qui accumulent des hypothèses périmées. Dès que l'ensemble des preuves change nettement, recommencez l'analyse avec les faits corrigés et un bref relevé des décisions. Sinon, une mauvaise lecture initiale peut rester dans la conversation et influencer les réponses suivantes après que l'équipe la croit corrigée. Stockez les conclusions durables dans des tests, notes d'architecture ou tickets, pas uniquement dans l'historique du chat.

Les agents ont besoin d'une autorité bornée et de preuves visibles

Un agent mérite un périmètre plus large quand ses actions sont inspectables et réversibles. Accordez-lui les permissions minimales nécessaires, une branche ou un worktree isolé, des instructions de préparation déterministes et des contrôles d'acceptation qui échouent clairement. Gardez les identifiants de production et les droits de déploiement hors de la boucle, sauf si la tâche les exige explicitement et qu'une validation humaine existe.

Un rapport d'exécution utile doit répondre à des questions concrètes :

• Dans quel état du dépôt et avec quelles instructions l'agent a-t-il commencé ?
• Quels fichiers a-t-il lus et modifiés ?
• Quelles commandes ont été exécutées, et avec quels résultats de sortie ?
• Quels critères d'acceptation ont réussi ou échoué ?
• Quelle incertitude demeure, et quelle preuve la lèverait ?

Le diff reste nécessaire, mais il ne suffit pas. Les relecteurs doivent aussi connaître le chemin qui l'a produit. Un agent peut supprimer un test pour faire réussir une suite, mettre à jour un snapshot qui capturait une régression ou choisir une configuration de secours qui ne tourne jamais en production. Les journaux de commandes et les nombres de tests avant et après exposent certains de ces raccourcis. Les règles du dépôt doivent interdire les autres.

Contenez les échecs par des moyens mécaniques. Limitez les chemins accessibles en écriture quand c'est possible. Exigez une validation avant les commandes destructrices, les changements de dépendances, l'accès réseau ou la modification de la configuration de déploiement. Utilisez une durée maximale et un nombre maximal de fichiers modifiés comme alarmes, pas comme définition de la justesse. Si une alarme se déclenche, conservez le travail et les preuves pour la revue au lieu de laisser l'agent élargir lui-même ses droits.

La sécurité et la conformité demandent des termes précis. Exécuter un modèle dans le périmètre du client peut répondre à des contraintes de localisation des données et de réseau, mais ne donne aucune certification à l'outil ou au système produit. Une installation isolée du réseau exige encore des contrôles d'accès, des traces d'audit, la provenance du modèle et des dépendances, ainsi qu'un processus d'approbation de ce qui quitte l'environnement.

Choisissez l'outil selon les preuves et le rayon d'impact

Le choix doit suivre l'affirmation que vous devez soutenir. Pour « cette ligne suit le modèle que je comprends déjà », l'autocomplétion peut suffire. Pour « ces fichiers impliquent ce comportement », utilisez un assistant et vérifiez les preuves qu'il cite. Pour « le dépôt satisfait maintenant ce critère d'acceptation », un agent peut recueillir les preuves, à condition que ses outils et permissions couvrent ce critère.

N'achetez pas le nom de la catégorie. Demandez aux fournisseurs de démontrer la véritable frontière d'observation et d'action. L'outil lit-il tous les langages de l'arborescence ? Suit-il les liens générés et configurés ? Peut-il exécuter le build et les contrôles de parité dans votre environnement ? Affiche-t-il commandes et échecs ? Pouvez-vous limiter les écritures, le réseau et les identifiants ? Qu'est-ce qui provoque exactement son arrêt ? Un patch bien présenté ne répond à aucune de ces questions.

Pour un système hérité, commencez le choix de l'outil par une matrice de risques, pas par une liste de fonctions. Placez l'ambiguïté du comportement sur un axe et le rayon d'impact sur l'autre. Une faible ambiguïté et un faible impact favorisent la complétion. Une ambiguïté bornée avec une décision humaine favorise l'assistant. Une forte ambiguïté ou un changement entre systèmes appelle un agent et un oracle indépendant, et parfois un report jusqu'à ce que l'équipe puisse capturer cet oracle.

CodeHero applique ce dernier modèle aux réécritures de systèmes anciens : sa plateforme lit toute la base multilingue, modernise l'architecture et compare le comportement au trafic de production enregistré grâce à un banc de parité. Chaque projet est livré en moins de 30 jours, mais le calendrier ne réduit pas l'exigence de preuve; la boucle d'actions et l'oracle permettent justement de discuter ce délai sur des bases techniques.

Un achat doit s'appuyer sur une tâche qui comporte au moins un modèle local trompeur, une dépendance entre langages et un comportement visible seulement à l'exécution. Donnez à chaque candidat le même état du dépôt et les mêmes preuves d'acceptation. Comparez les affirmations non soutenues, fichiers exclus, commandes, tentatives échouées et effort de revue aussi soigneusement que le patch final. Un outil qui reconnaît un lien non résolu est plus sûr qu'un outil qui remplit le vide par une hypothèse convaincante.

La responsabilité après l'exécution compte aussi. L'équipe doit pouvoir reproduire les contrôles, maintenir le remplacement et comprendre les exceptions restantes sans accéder à une conversation disparue. Exigez des sources ordinaires, des tests, des instructions d'exécution et des relevés de décision. Si un fournisseur ne peut pas remettre la chaîne de preuves sous une forme que vos ingénieurs peuvent inspecter, le système reste inconnu après la réécriture, simplement dans un langage plus récent.

Un outil ne doit jamais recevoir plus d'autorité que ses preuves ne le justifient. Face à un code inconnu, inspectez ce que l'outil a vu, ce qu'il a fait et comment il a tenté de prouver le résultat. Les trois noms comptent parce qu'ils imposent cette discussion avant qu'une suggestion éloquente ne devienne une modification de production non examinée.