Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Pourquoi AX Code

Statut : actif Portée : état actuel Dernière revue : 2026-08-25 Responsable : mainteneurs d’AX Code

La plupart des agents de programmation optimisent le moment de l’écriture du code. AX Code optimise le moment d’après : décider s’il faut garder ce que l’agent a produit.

Ce qu'AX Code optimise

La sortie d’un agent est peu coûteuse à produire et coûteuse à revoir. Quand un agent touche vingt fichiers dans trois modules, le problème du relecteur n’est pas « cette ligne est-elle correcte », mais « qu’a-t-il réellement fait, est-ce que cela passe, et que se passe-t-il si je dois l’annuler ».

AX Code est construit autour de ce problème :

• Preuves. Chaque session est enregistrée comme un journal d’événements typés — décisions de routage, activité du modèle, étapes, appels d’outils, résultats d’outils — plus des instantanés de fichiers pris pendant l’exécution.
• Vérification. Là où une barrière est applicable, les contrôles propres à votre dépôt décident. Les candidats d’arène et l’application de refactorisation sous barrière exécutent la vérification de types, le lint et les tests avant qu’un résultat soit accepté.
• Réversibilité. Les points d’instantané sont récupérables étape par étape, et pas seulement par session, y compris les changements délégués à des sessions imbriquées dans le même répertoire de travail.
• Votre décision. AX Code classe, note et rapporte. Il ne fusionne pas à votre place.

À qui il s'adresse

Public principal :

• ingénieurs seniors et staff qui font des changements lourds de conséquences
• mainteneurs de projets open source et de plateformes internes
• équipes qui exploitent des dépôts Git moyens à grands
• ingénieurs qui évaluent des refactorisations, des migrations et des correctifs transverses aux modules
• toute personne qui lance un travail d’agent sans surveillance ou planifié, qu’un humain doit auditer ensuite

Pas le public principal :

• quelqu’un qui veut une autocomplétion en ligne
• un utilisateur qui fait une modification rapide et jetable
• une équipe dont la priorité est une délégation cloud entièrement gérée
• quelqu’un qui refuse d’utiliser Git ou d’exécuter les contrôles du dépôt

Dans ces cas, un assistant d’éditeur plus léger est réellement le meilleur outil, et cette page préfère le dire plutôt que de survendre.

En quoi il diffère

Plutôt qu’une liste de fonctions qui se périme, voici ce que chaque catégorie optimise :

Plusieurs capacités livrées par AX Code sont, en 2026, largement disponibles ailleurs : bac à sable, points de contrôle et restauration, MCP, crochets, skills, sous-agents, isolation par worktree, planification, choix du fournisseur, et exécution d’une invite sur plusieurs modèles. Aucune de ces capacités, seule, n’est une raison de choisir AX Code.

La combinaison plus difficile à assembler ailleurs est : une implémentation candidate isolée, conditionnée aux contrôles propres du dépôt, classée vérification d’abord, avec l’enregistrement d’exécution complet conservé en local et exportable — et aucune fusion automatique.

Ce que nous ne prétendons pas

Un positionnement n’est utile que s’il survit au contact du produit. Explicitement :

• replay reconstruit ; il ne réexécute pas. Il rebâtit et vérifie le flux d’événements enregistré. Il ne relance ni les modèles, ni les outils, ni le monde extérieur.
• risk est une heuristique déterministe, calculée à partir du volume de changements, de l’état de validation, des échecs d’outils, des chemins touchés et des motifs de fichiers sensibles à la sécurité. Ce n’est ni une probabilité, ni une confiance calibrée, ni une assurance de sécurité.
• branch dérive l’état de session, pas une branche Git ni un worktree. L’arène est le chemin d’implémentation par worktree Git.
• compare compare des exécutions, pas le code source. Il rapporte le risque, le chemin de décision et les comptes d’événements — ce n’est pas une visionneuse de diff de code.
• Les barrières de vérification ne sont pas universelles. Elles s’appliquent aux candidats d’arène et à l’application de refactorisation sous barrière. Les modifications interactives ordinaires ne sont pas vérifiées automatiquement.
• La prose d’AX Wiki est générée par un modèle à partir de sources citées. Le cadre de planification, de validation, de mise à jour incrémentale et de sections protégées qui l’entoure est déterministe.
• La visibilité du pont CLI est partielle. AX Code enregistre en entier sa propre exécution d’outils ; le travail qui se passe dans un processus CLI de fournisseur n’est visible qu’à travers la sortie de ce pont.
• Certaines capacités sont sur activation. Le runtime workflow exige AX_CODE_WORKFLOW_RUNTIME=1.

Provenance, sans détour

AX Code a commencé sur la base de code OpenCode sous licence MIT. Cela est conservé dans NOTICE et indiqué dans le README, plutôt qu’enfoui.

Ce que DEFAI a construit sur cette base est le sujet de cette page : la couche de preuves d’exécution, le moteur déterministe de débogage et de refactorisation avec vérification par worktree fantôme, le graphe d’intelligence de code et l’analyse d’impact, les modes d’exécution conseil et arène, le compilateur AX Wiki, le bac à sable au niveau du système, et AX Code Desktop.

S’intégrer à un projet n’est pas en dériver. La section de provenance du README, et NOTICE, existent pour porter les obligations de licence au titre d’Apache-2.0, section 4(d) — elles ne listent que les amonts dont AX Code copie et redistribue réellement le code. Les projets auxquels AX Code se contente de parler n’y figurent pas, quelle que soit l’attention avec laquelle ils ont été étudiés pendant la construction du pont. Les fournisseurs CLI en sont le cas le plus clair : Claude Code, Codex CLI, Grok Build CLI et Muse Code CLI sont nommés dans les tableaux de fournisseurs parce qu’AX Code invoque ces binaires locaux et réutilise leurs sessions de connexion, et non parce que leur code est livré ici. Les motifs d’identifiants de modèles, les tableaux de capacités et l’analyse propre au fournisseur dans packages/ax-code/src/provider/ sont la logique d’interopérabilité propre d’AX Code. Les fichiers qui sont réellement des dérivations textuelles portent un en-tête de provenance d’une ligne nommant l’amont, afin qu’un audit distingue une réutilisation délibérée d’un nettoyage oublié.

Suite

• Preuves d’exécution — les commandes qui rendent une exécution révisable
• Changements multi-modèles vérifiés — conseil et arène
• Commencer ici — le modèle mental du produit