Un agent IA peut-il travailler sans tout le contexte du code ?

Un agent IA qui ne voit qu'un fichier peut produire une modification convaincante à cet endroit et pourtant endommager le système. L'échec vient rarement d'une mauvaise syntaxe ou d'une branche manifestement erronée. Il vient d'un appelant absent, d'une règle encodée dans les données, d'un traitement nocturne qui utilise un autre point d'entrée ou d'une dépendance d'exploitation qui n'apparaît jamais dans le fichier examiné.

Voilà pourquoi les limites du contexte déterminent si le développement assisté par des agents fonctionne sur un logiciel ancien. La bonne unité de travail est le comportement qui traverse programmes, scripts, objets de base de données, planifications, fichiers et procédures d'exploitation. Un fichier n'est qu'un des endroits où une partie de ce comportement a été écrite.

J'ai vu des correctifs propres passer en revue parce que chaque ligne visible semblait logique. La panne est arrivée plus tard, lorsqu'un fichier de contrôle a choisi un ancien mode, qu'un programme nommé dynamiquement a reçu un paramètre à une position que personne n'avait documentée ou qu'une reprise de batch a rencontré des enregistrements que le parcours en ligne ne produit jamais. Modifier les lignes avec plus de soin ne résout pas cette catégorie de panne. L'agent doit d'abord découvrir le système autour de la ligne.

Un fichier n'est pas une unité de comportement

Le comportement d'un système ancien tient rarement dans le fichier qui semble en être responsable. Un programme COBOL peut calculer un montant, mais le JCL choisit son jeu de données d'entrée, une étape SORT change l'ordre des enregistrements, un copybook fixe la position des champs et un programme ultérieur interprète l'octet d'état produit. Lire uniquement le calcul donne à l'agent une histoire cohérente mais incomplète.

Le même schéma existe hors des mainframes. Un formulaire VB6 appelle un composant COM dont l'enregistrement choisit une version. Un contrôleur PHP inclut un fichier de configuration assemblé par des scripts de déploiement. Un programme RPG lit une zone de données et appelle un autre programme dont le nom se trouve dans un champ. Un package PL/SQL dépend d'un déclencheur qui modifie la ligne après son écriture. Aucune de ces dépendances ne doit forcément ressembler à un import classique.

Cette distinction compte : la proximité dans le code source ne donne pas la responsabilité du comportement. Deux fonctions du même fichier peuvent n'avoir aucun lien à l'exécution, alors qu'un membre JCL et un paragraphe COBOL placés dans des bibliothèques différentes forment une seule opération de production indivisible. Si un agent classe surtout le contexte selon la proximité des répertoires, les instructions d'import ou les identifiants identiques, il manquera des dépendances que l'exploitation juge évidentes.

Avant de modifier un fichier, il faut demander ce qui lance ce comportement, quelles entrées sélectionnent ses branches, quel état persistant il lit ou écrit et qui consomme son résultat. Ces questions définissent une limite du système. Elle peut inclure douze fichiers ou douze mille. Sa taille dépend du comportement, pas de l'onglet ouvert dans l'éditeur.

La conséquence pratique est directe. Un outil incapable de chercher et de raisonner dans tout le dépôt, les définitions de build, le contrôle des jobs, les schémas et les tests ne doit pas modifier seul un système ancien. Il peut expliquer un paragraphe ou préparer un test unitaire. Il ne peut pas établir les effets d'une modification en production.

Les sites d'appel échappent au graphe des imports

Un graphe d'appels construit à partir des appels de fonction explicites est utile, mais ce n'est pas le graphe d'appels du système. Les systèmes anciens choisissent le travail à exécuter au moyen de chaînes, tables, planificateurs, code généré, étapes de liaison, fichiers de commandes et conventions. L'arête manquante est souvent celle qui compte.

La documentation ILE d'IBM fournit un exemple clair. Une application IBM i peut employer des appels de procédures statiques, résolus lors de la liaison du programme, ou des appels de programmes dynamiques dont le nom cible est résolu à l'exécution. Une analyse limitée au code source trouve souvent la référence statique. Un appel dynamique par identifiant peut dépendre d'une valeur chargée depuis un fichier, un message, une zone de données ou un paramètre. Chercher le nom du programme appelé ne trouvera pas une valeur que la production construit plus tard.

Le même angle mort prend des formes ordinaires :

• Un planificateur appelle un script shell qui lance un programme sous un alias.
• Une table de base de données associe des codes de transaction à des noms de gestionnaire.
• La réflexion charge une classe nommée dans la configuration.
• Une macro de tableur appelle une méthode COM par l'intermédiaire d'un objet lié tardivement.
• Du JCL généré insère un nom de procédure seulement après une substitution symbolique.

Le métier confond souvent accessibilité statique et dépendance à l'exécution. L'accessibilité statique demande si le texte source ou les métadonnées compilées exposent un chemin. La dépendance à l'exécution demande si la production peut faire passer des données ou le contrôle par ce chemin dans un état donné. Prendre la première pour une preuve de la seconde produit un diagramme séduisant et incomplet.

Un agent a besoin de preuves pour les deux. Il doit extraire les références explicites, puis examiner les chaînes littérales, clés de configuration, étapes de jobs, métadonnées de liaison, tables d'aiguillage en base et traces de production. S'il ne peut pas résoudre une cible dynamique, il doit conserver une arête non résolue avec l'expression et ses sources possibles. L'absence de réponse n'est pas une résolution valable.

Une recherche élémentaire dans le dépôt montre déjà à quelle vitesse un symbole supposé isolé quitte son module :

rg -n -uu 'CALC-TAX|CALCTAX|calc_tax' .
rg -n -uu 'EXEC PGM=|CALL +[A-Z0-9-]+|CALLP|PROCEDURE DIVISION' .
rg -n -uu 'handler|program_name|transaction_code' config db jobs src

Une vraie sortie contient des chemins et des numéros de ligne, par exemple jobs/NIGHTTAX.jcl:18://STEP20 EXEC PGM=CALCTAX. L'artefact est simple, mais il oblige la personne qui relit à inspecter les appelants au-delà du fichier ouvert. Un agent sérieux doit construire automatiquement une carte plus riche et conserver les preuves qui justifient chaque arête.

Les règles métier circulent dans les données

Beaucoup de règles anciennes sont des valeurs, des formats et des séquences plutôt que des fonctions nommées. Un agent peut conserver chaque condition visible tout en changeant le résultat s'il comprend mal un champ décimal compacté, une date sentinelle, un type d'enregistrement, un ordre de tri ou le sens d'un espace.

Prenons un programme nocturne de calcul de frais. Le code dit que la classe de compte P bénéficie d'une exemption. Cette classe ne vient pas directement de la ligne du compte. Une extraction antérieure passe les codes produit dans une table de contrôle, écrit une classe sur un octet à la position 47 et trie les exceptions avant les enregistrements ordinaires. L'exploitation remplace cette table avant la clôture mensuelle. La règle que la revue situe dans une seule instruction IF s'étend en réalité sur une table, un format de fichier, un contrat de tri et une procédure d'exploitation.

C'est ici que les agents limités à un fichier produisent des translittérations plausibles. Ils convertissent correctement le IF, définissent une jolie énumération et lisent un CSV dans un service moderne. Puis ils suppriment les espaces ou interprètent un champ vide comme null. Le programme d'origine comparait un blanc de largeur fixe, donc une partie des comptes prend une autre branche. Tous les tests unitaires dérivés de la fonction réécrite réussissent puisqu'ils répètent la nouvelle interprétation.

L'inventaire du système doit donc inclure la sémantique des données, pas seulement les noms de schémas. Pour chaque enregistrement ou table à la frontière, il faut relever les positions de champs, encodages, valeurs par défaut, comportement des valeurs nulles, formats de signe, arrondis, ordre, traitement des doublons et politique face aux enregistrements invalides. Si une valeur de contrôle change hors du gestionnaire de versions, notez comment elle est promue et quel job la lit.

Ne supposez pas qu'un type moderne est plus juste que l'ancienne représentation. Convertir 9(7)V99 COMP-3 en type décimal peut être raisonnable, mais seulement après avoir préservé échelle, signe, arrondi, dépassement et comportement des entrées mal formées. Remplacer une date de six caractères par un horodatage peut clarifier la conception cible tout en inventant discrètement une règle de siècle absente de la source.

L'agent doit aussi relier les producteurs aux lecteurs. Un champ qui semble inutilisé côté production peut être un remplissage positionnel requis trois étapes plus loin. Sa suppression décale tous les champs suivants sans provoquer d'erreur de compilation. La représentation la plus sûre de cette relation est un contrat explicite avec des octets d'exemple et les valeurs analysées, pas une note en prose affirmant que les fichiers sont compatibles.

Le batch nocturne est une autre application

Un parcours en ligne et un parcours batch qui partagent du code restent deux applications différentes lorsqu'ils utilisent d'autres entrées, identités, horaires et règles de reprise. La réussite d'un test interactif dit peu de chose sur un job qui traite après minuit un état accumulé.

La documentation z/OS d'IBM décrit le JCL comme l'endroit où le système apprend où trouver les entrées, comment les traiter et que faire des sorties. Les instructions DD relient les noms employés par un programme aux véritables jeux de données et précisent des éléments comme leur disposition et le format des enregistrements. Ce n'est pas un emballage autour de l'application. C'est du contexte exécutable.

Imaginons une modification qui ajoute un état à une fonction de commande en ligne. Le parcours de la requête écrit H pour les commandes retenues, affiche le bon message et passe la revue. Le job nocturne de règlement lit le même fichier. Sa première étape trie uniquement les anciens états vers l'entrée du règlement, tandis qu'une étape d'erreur copie tous les autres vers un jeu de données temporaire avec DISP=(NEW,PASS). Une étape ultérieure ne s'exécute que si une condition sur le code retour correspond. Le nouvel état évite le règlement, arrive dans le fichier temporaire et disparaît lorsque le job se termine normalement. Aucun fichier source du service examiné ne montre ce résultat.

La panne peut attendre un certain volume ou un état du calendrier. Un test en journée utilise un enregistrement et une base propre. Le batch rencontre des doublons accumulés au fil des reprises, clôt une date comptable avant le traitement et valide tous les quelques milliers d'enregistrements. Une reprise repart du dernier point de contrôle, pas de la transaction attendue par le test. La correction inclut le comportement de reprise, car l'exploitation relancera tôt ou tard un job partiellement terminé.

Pour chaque flux planifié, l'agent doit modéliser cinq faits :

1. Le déclencheur, le calendrier, l'identité et l'environnement.
2. Les étapes ordonnées et les conditions qui les sautent ou les répètent.
3. Les entrées et sorties concrètes, y compris les jeux de données temporaires.
4. Le comportement de validation, point de contrôle, nouvelle tentative et relance.
5. La preuve utilisée par l'exploitation pour déclarer la réussite.

Un code de sortie vert n'est pas toujours le critère de succès. Certaines équipes acceptent des codes d'avertissement définis, inspectent le nombre d'enregistrements ou rapprochent un total de contrôle dans un rapport ultérieur. Un agent qui ne voit que le code source et les tests unitaires optimise le mauvais signal.

La configuration exécute des règles

La configuration mérite le même examen que le code source, car elle choisit le comportement, fournit des valeurs métier et relie les composants à l'exécution. La qualifier de "simple configuration" permet facilement d'approuver une modification sans relire la règle qui sera réellement exécutée.

La configuration ancienne se trouve rarement dans un répertoire bien rangé. Il peut s'agir d'un paramètre symbolique JCL, d'une zone de données IBM i, d'un fichier INI à côté d'un exécutable de bureau, d'une ligne gérée depuis un formulaire Access, d'une valeur du registre, d'un membre d'environnement ou d'un tableur copié dans un dossier surveillé. Certaines valeurs sont versionnées. D'autres arrivent par les outils de déploiement ou une procédure d'exploitation. L'agent doit trouver et distinguer les deux catégories.

Supposons qu'un programme de sinistres choisisse une routine tarifaire dans une table. Le code source contient une valeur par défaut inoffensive, donc l'agent réécrit et teste cette branche. En production, des lignes régionales nomment quatre anciennes routines, dont une accepte un argument supplémentaire dans un tampon partagé. Le nouveau service démarre proprement et traite les cas par défaut. Le premier sinistre de cette région n'appelle aucun gestionnaire ou appelle le nouveau avec un contrat incomplet. Le site d'appel manquant était une ligne de table, pas une ligne de code.

Traitez les valeurs de configuration selon leur effet. Une valeur qui modifie le niveau des journaux présente peu de risque fonctionnel. Une valeur qui choisit un programme, change un seuil, contrôle l'arrondi, accorde un accès, fixe une version de format de fichier ou modifie la fréquence de validation appartient à la carte d'impact. La distinction dépend de la conséquence, pas de l'extension du fichier.

Pour chaque valeur qui sélectionne un comportement, l'agent doit répondre à quatre questions :

• Où la valeur est-elle définie et qui peut la changer ?
• Quel code la lit, et quand cette lecture a-t-elle lieu ?
• Quelles valeurs ont été observées dans de vrais environnements ?
• Que se passe-t-il si elle est vide, ancienne, inconnue ou indisponible ?

Les valeurs par défaut appellent une méfiance particulière. Une solution de repli pratique dans un test unitaire peut masquer un échec de chargement en production. Le système source peut s'arrêter quand un membre de contrôle manque, alors que la réécriture choisit silencieusement une valeur par défaut. Les deux produisent un résultat valide pour les cas configurés, mais leurs contrats d'échec diffèrent. Les tests de parité doivent inclure une configuration absente ou mal formée, pas seulement les valeurs attendues.

Conservez un instantané du déploiement avec la révision source analysée. Attribuez si possible un hachage ou une version à l'export du planificateur, aux tables de contrôle, au schéma et aux fichiers d'environnement. Si la personne qui relit ne peut pas savoir quelle configuration l'agent a supposée, l'affirmation d'impact n'est pas reproductible. Même un index complet du code associé à une configuration de production inconnue reste un contexte partiel, et l'agent doit le dire clairement.

Construire la carte avant de demander un correctif

L'agent doit construire une carte d'impact fondée sur des preuves avant de proposer du code. Ce n'est pas une affiche d'architecture. C'est un ensemble de travail composé de nœuds et d'arêtes reliés à des fichiers, définitions, observations d'exécution et questions non résolues.

Commencez par les points d'entrée : routes en ligne, consommateurs de messages, jobs planifiés, programmes de commande, procédures stockées, événements d'application de bureau et commandes opérateur. Reliez ensuite les appels de programmes, lectures et écritures de fichiers, accès aux tables, artefacts générés, sélections de configuration et liaisons de déploiement. Marquez les arêtes comme statiques, configurées, observées ou déduites. Ces étiquettes empêchent une supposition de prendre l'autorité d'un fait.

J'utilise un relevé compact pour chaque modification proposée :

{
  "change": "add held order status H",
  "entry_points": ["POST /orders/{id}/hold", "NIGHTSET STEP20"],
  "writers": ["OrderStatus.bas", "HOLDORDR.cbl"],
  "readers": ["SETTLE.cbl", "RECON.sql"],
  "contracts": ["ORDER-REC copybook", "status_control table"],
  "unresolved": ["Does restart input retain H records?"],
  "required_evidence": ["online trace", "nightly replay", "reconciliation totals"]
}

Cet objet est volontairement inconfortable. Il rend visibles le second point d'entrée et la question non résolue de la reprise avant toute approbation. Le nom précis des champs importe peu. Ce qui compte, c'est d'obliger l'agent à citer les points d'entrée, lecteurs, contrats et preuves manquantes.

L'autre méthode populaire est la divulgation progressive : donnez à l'agent le fichier cible, laissez-le réclamer les fichiers associés et arrêtez lorsqu'il estime en avoir assez. Cela économise des jetons et semble efficace dans une démonstration. Pour découvrir l'impact, la méthode est mauvaise, car le premier fichier conditionne toutes les demandes suivantes. S'il ne contient aucun indice sur un planificateur, une table de contrôle ou une procédure générée, l'agent ne les demandera jamais.

La divulgation progressive est utile après la découverte, lorsque l'agent a besoin du texte détaillé d'une partie connue de la carte. La découverte elle-même exige une indexation de tout le dépôt et une analyse entre les langages. L'agent peut concentrer son raisonnement, mais l'espace de recherche ne doit pas commencer à la limite d'un fichier.

La carte donne aussi aux humains une meilleure surface de revue. Une personne peut contester une arête absente, demander la preuve d'une déduction ou ajouter une procédure d'exploitation qui ne se trouve pas dans le dépôt. Examiner seulement le diff final impose à l'humain de reconstruire mentalement cette carte, soit précisément le travail que l'agent devait faciliter.

Le contexte demande des couches, pas un prompt géant

Le contexte de tout le système ne consiste pas à coller un million de lignes dans un seul prompt. L'agent doit pouvoir interroger et raisonner sur le système complet au moyen de représentations adaptées à chaque question, tout en gardant un chemin vers les preuves sources.

Une couche contient l'inventaire : langages, unités de build, schémas, jobs, points d'entrée, fichiers, procédures et sources de configuration. Une autre contient les relations telles que les appels, lectures, écritures, planifications, inclusions, liaisons et générations. Une couche sémantique consigne les contrats et responsabilités probables. Les preuves d'exécution ajoutent des traces, exemples proches de la production, journaux de jobs et cibles d'aiguillage observées.

Ces couches servent des requêtes différentes. Pour renommer un champ, l'agent a besoin des définitions de format et de chaque lecteur. Pour changer un calcul, il lui faut les appelants, la provenance des données, les règles d'arrondi et les sorties de comparaison. Pour découper un batch, il lui faut les conditions des étapes, la durée de vie des ressources temporaires, les points de contrôle et la reprise par l'exploitation. Aucune stratégie fixe de découpage ne répond aux trois.

Les résumés aident, mais restent des caches avec pertes. Un résumé peut dire qu'un programme calcule des frais et omettre la branche réservée aux transactions annulées pendant la clôture. Chaque affirmation résumée doit conserver des références vers des portions précises du code ou des enregistrements d'exécution. Quand une modification touche l'affirmation, l'agent doit rouvrir ces sources au lieu de raisonner seulement à partir du résumé.

La fraîcheur du contexte compte aussi. Copybooks générés, définitions de base, exports du planificateur et configuration déployée peuvent diverger du dépôt principal. L'agent doit montrer l'instantané analysé. Mélanger un fichier COBOL actuel et l'export JCL du trimestre précédent crée un système artificiel qui n'a jamais fonctionné nulle part.

L'analyse du dépôt a également une limite. Un opérateur peut modifier un membre de contrôle pendant un incident. Un partenaire peut envoyer des variantes d'enregistrements non documentées. Une application de bureau peut dépendre de l'enregistrement de la machine. Il faut alors nommer la lacune et exiger des preuves d'exécution, sans la combler par une supposition assurée.

Cette approche en couches maîtrise le coût sans sacrifier le périmètre. De larges index trouvent les candidats à peu de frais. Une récupération ciblée fournit le code exact lorsque l'agent raisonne sur une arête. La relecture d'exécution teste le comportement obtenu. Le système reste à la portée de l'agent même si tous les jetons ne sont pas actifs en même temps.

La parité se prouve à la frontière du comportement

Des tests écrits uniquement contre la nouvelle implémentation prouvent sa cohérence interne, pas la conservation du comportement. Une réécriture peut réussir une suite unitaire neuve et complète tout en divergeant de la production sur les cas qu'elle a mal compris.

Le meilleur oracle pratique reste l'ancien système. Capturez des entrées représentatives à ses véritables frontières, exécutez-les dans les deux implémentations, normalisez seulement les valeurs volontairement non déterministes et comparez les sorties observables. Elles peuvent inclure les corps de réponse, modifications de base de données, fichiers émis, messages, codes retour, totaux de contrôle et journaux que l'exploitation traite comme contractuels.

Un cas de parité doit conserver assez de détails pour reproduire une divergence :

{
  "case_id": "nightly-held-order-restart",
  "entry_point": "NIGHTSET",
  "input_refs": ["orders.dat#sha256:...", "status_control#2026-08-01"],
  "source": {"rc": 4, "settled": 812, "held": 17, "control_total": "194033.22"},
  "target": {"rc": 0, "settled": 829, "held": 0, "control_total": "196801.04"},
  "comparison": "mismatch"
}

L'exemple montre pourquoi comparer les codes de sortie ne suffit pas. La source accepte le code retour 4 et conserve les enregistrements retenus. La cible renvoie zéro après les avoir réglés. Un contrôle d'état classique préfère le mauvais résultat.

Le trafic enregistré demande de la rigueur. Retirez ou protégez les valeurs sensibles, conservez l'ordre lorsqu'il influe sur le comportement et incluez échecs et nouvelles tentatives au lieu d'échantillonner seulement les requêtes réussies. Les fixtures batch doivent couvrir des catégories de volume proches de la production, dates limites, doublons, enregistrements mal formés et points de reprise. Tous les enregistrements de production ne sont pas nécessaires, mais chaque classe de comportement connue l'est.

La parité n'interdit pas le changement d'architecture. Elle sépare les changements voulus des changements accidentels. Vous pouvez remplacer le traitement séquentiel de fichiers par des transactions en base, diviser un monolithe en services ou déplacer un noyau numérique vers Rust. La comparaison montre où le comportement visible a bougé. Un humain peut alors approuver une différence intentionnelle et motivée au lieu de la découvrir lors du rapprochement.

CodeHero utilise volontairement cette frontière : sa plateforme lit tout le code dans tous les langages, puis vérifie le système réécrit grâce à un banc de parité alimenté par du trafic de production enregistré. Ce mécanisme compte davantage que l'apparence idiomatique du code généré dans une demande de fusion.

Relire l'affirmation d'impact, pas seulement le diff

Une revue assistée par agent doit évaluer ce que l'agent affirme au sujet de l'impact sur le système. Le diff reste nécessaire, mais il est le dernier artefact d'une chaîne qui commence par la découverte et finit par des preuves de comportement.

Un dossier de revue utile contient le comportement demandé, les points d'entrée touchés, les contrats modifiés, les consommateurs découverts, les arêtes non résolues, les preuves de test et les différences acceptées. Chaque affirmation doit rester traçable. Si l'agent dit qu'un champ n'a qu'un lecteur, la personne qui relit doit pouvoir ouvrir la recherche ou la trace qui justifie ce nombre.

La conversation d'approbation change. Au lieu de demander si la nouvelle fonction semble raisonnable, la personne demande pourquoi RECON.sql n'est pas touché, si la reprise nocturne a été rejouée et quelle preuve couvre les états vides. Un agent peut moins facilement simuler une réponse à ces questions, et un ingénieur expérimenté peut y répondre avec précision.

Surveillez trois signaux. Premièrement, l'agent décrit des dépendances sans séparer les faits observés des déductions. Deuxièmement, ses tests viennent entièrement du nouveau modèle et non du comportement ancien capturé. Troisièmement, il emploie des expressions comme "tous les appelants" sans exposer la limite de recherche. Chaque signal indique que l'affirmation de contexte dépasse les preuves.

La revue a aussi besoin d'une règle d'arrêt. Bloquez la modification lorsqu'une arête non résolue peut toucher l'argent, les autorisations, des données réglementées, une sortie irréversible ou le comportement de reprise. Pour un défaut d'affichage peu risqué, une déduction limitée peut suffire. La complétude du contexte n'est pas binaire : le niveau de preuve requis augmente avec les conséquences d'une erreur.

Ne mesurez pas un agent au nombre de lignes acceptées ou à la vitesse des demandes de fusion. Ces mesures récompensent la plausibilité locale. Mesurez la concordance entre les impacts prévus et les effets observés, les divergences de parité qui s'échappent et le fonctionnement des relances et contrôles d'exploitation. Même sans score formel, ces questions séparent l'aide à la saisie du travail d'ingénierie.

Le périmètre global change l'économie du projet

Découvrir tout le dépôt coûte davantage avant la première modification, et c'est justement pour cela que cette étape gagne du temps sur les systèmes anciens. Les pannes coûteuses arrivent après qu'un changement local bon marché a traversé une limite invisible : pendant une clôture, une fenêtre batch, un rapprochement ou après le départ de la seule personne qui connaissait la séquence de reprise.

Le coût ne se limite pas à la réparation. Une mauvaise modernisation apprend à l'organisation à se méfier du système cible. Les équipes gardent l'application ancienne en doublure, comparent les résultats à la main et refusent les changements suivants. La réécriture est officiellement terminée alors que la migration opérationnelle ne l'est jamais.

L'analyse de tout le système évite un gaspillage plus discret : translittérer une architecture dépassée parce que l'agent ne comprend pas pourquoi elle existe. S'il ne voit qu'un programme, le choix apparemment le plus sûr consiste à reproduire ses paragraphes dans un autre langage. S'il voit les appelants, contrats de données, flux de jobs et comportement à la frontière, il peut préserver les résultats requis tout en remplaçant la structure accidentelle.

C'est la norme que nous appliquons lorsque CodeHero réécrit des systèmes anciens en Go, Rust, TypeScript et Postgres en moins de 30 jours. Ce délai court n'est crédible que si la découverte, le raisonnement entre langages et la vérification de parité portent sur le système entier, sans attendre que des humains fournissent les fichiers un à un.

Un agent IA n'a pas besoin d'une compréhension mystique de chaque décision historique. Il lui faut une limite honnête, des preuves pour les arêtes qu'elle contient et des tests aux endroits où le comportement en sort. Si votre agent de programmation ne peut pas nommer le job nocturne qui lit l'enregistrement qu'il veut modifier, il n'a pas gagné le droit de le modifier.