Questa pagina è tradotta dalla documentazione inglese. Comandi, identificatori ed esempi restano invariati. Runtime 7.24.4 · SDK 2.6.7. Testo inglese

Perché AX Code

Stato: Attivo Ambito: stato attuale Ultima revisione: 2026-08-25 Responsabile: responsabili di AX Code

La maggior parte degli agenti di programmazione ottimizza il momento in cui si scrive il codice. AX Code ottimizza il momento dopo: decidere se tenere ciò che l’agente ha prodotto.

Che cosa ottimizza AX Code

L’output dell’agente è economico da generare e costoso da revisionare. Quando un agente tocca venti file in tre moduli, il problema di chi revisiona non è «questa riga è corretta» ma «che cosa ha fatto davvero, supera i controlli, e che cosa succede se devo annullarlo».

AX Code è costruito intorno a quel problema:

Evidenza. Ogni sessione è registrata come un log di eventi tipizzato — decisioni di instradamento, attività del modello, passi, chiamate di strumenti, risultati degli strumenti — più istantanee dei file prese durante l’esecuzione.
Verifica. Dove una soglia è applicabile, decidono i controlli propri del repository. I candidati di Arena e l’applicazione di un refactoring con soglia eseguono typecheck, lint e test prima che un risultato sia accettato.
Reversibilità. I punti di istantanea sono recuperabili per passo, non solo per sessione, incluse le modifiche delegate a sessioni annidate nella stessa directory di lavoro.
La tua decisione. AX Code classifica, assegna punteggi e riporta. Non fa il merge al posto tuo.

A chi è rivolto

Pubblico primario:

ingegneri senior e staff che fanno modifiche consequenziali
responsabili di progetti open source e di piattaforme interne
team che operano repository Git medi o grandi
ingegneri che valutano refactoring, migrazioni e correzioni tra moduli
chiunque esegua lavoro di agente non presidiato o pianificato che una persona deve auditare dopo

Non è il pubblico primario:

chi vuole il completamento automatico in linea
un utente che fa una modifica rapida e usa e getta
un team la cui priorità è la delega cloud completamente gestita
chi non vuole usare Git o eseguire i controlli del repository

In quei casi un assistente di editor più leggero è davvero lo strumento migliore, e questa pagina preferisce dirlo piuttosto che esagerare.

In che cosa differisce

Invece di una lista di funzioni che invecchia, ecco che cosa ottimizza ciascuna categoria:

Categoria	Ottimizza	Dove AX Code differisce
Agenti di modello di prima parte	l’esperienza di un solo modello, da capo a fondo	AX Code è indipendente dal modello e tiene il registro in locale
Agenti nell’editor	il flusso interattivo dentro l’IDE	AX Code punta al passo di revisione e audit, non al passo di digitazione
Agenti di terminale leggeri	velocità e semplicità	AX Code accetta più concetti in cambio di un registro ispezionabile
Agenti cloud	delega gestita e autonomia	AX Code tiene esecuzione ed evidenza sulla tua macchina, Apache-2.0

Diverse capacità che AX Code distribuisce sono, al 2026, ampiamente disponibili altrove: sandbox, checkpoint e ripristino, MCP, hook, skill, subagenti, isolamento dei worktree, pianificazione, scelta del provider e l’esecuzione di un prompt su più modelli. Nessuna di queste, da sola, è un motivo per scegliere AX Code.

La combinazione più difficile da assemblare altrove è: un’implementazione candidata isolata, subordinata ai controlli propri del repository, con verifica classificata prima di tutto, con l’intero registro di esecuzione conservato in locale ed esportabile — e senza merge automatico.

Che cosa non affermiamo

Il posizionamento è utile solo se regge al contatto con il prodotto. In modo esplicito:

replay ricostruisce; non riesegue. Ricostruisce e verifica il flusso di eventi registrato. Non riesegue modelli, strumenti o il mondo esterno.
risk è un’euristica deterministica, calcolata da churn, stato di validazione, fallimenti degli strumenti, percorsi toccati e motivi di file sensibili alla sicurezza. Non è una probabilità, una confidenza calibrata o una garanzia di sicurezza.
branch biforca lo stato della sessione, non un ramo Git né un worktree. Arena è il percorso di implementazione dei worktree Git.
compare confronta le esecuzioni, non il codice sorgente. Riporta rischio, percorso decisionale e conteggi di eventi: non è un visualizzatore di diff del codice.
Le soglie di verifica non sono universali. Si applicano ai candidati di arena e all’applicazione di refactoring con soglia. Le modifiche interattive ordinarie non vengono verificate in automatico.
La prosa di AX Wiki è generata dal modello a partire da fonti citate. Il quadro di pianificazione, validazione, aggiornamento incrementale e sezioni protette intorno a essa è deterministico.
La visibilità del ponte CLI è parziale. AX Code registra per intero la propria esecuzione degli strumenti; il lavoro che avviene dentro un processo CLI del fornitore è visibile solo attraverso l’output di quel ponte.
Alcune capacità sono su adesione. Il runtime workflow richiede AX_CODE_WORKFLOW_RUNTIME=1.

Provenienza, in chiaro

AX Code è nato sulla base di codice OpenCode con licenza MIT. Questo è conservato in NOTICE e dichiarato nel README, non nascosto.

Ciò che DEFAI ha costruito su quelle fondamenta è l’oggetto di questa pagina: il livello di evidenza di esecuzione, il motore deterministico di debug e refactoring con verifica su worktree ombra, il grafo di intelligenza del codice e l’analisi di impatto, le modalità di esecuzione council e arena, il compilatore AX Wiki, la sandbox a livello di sistema operativo e AX Code Desktop.

Integrarsi con un progetto non significa derivarne. La sezione di provenienza del README, e NOTICE, esistono per portare gli obblighi di licenza sotto Apache-2.0 sezione 4(d): elencano solo gli upstream di cui AX Code copia e ridistribuisce davvero il codice. I progetti con cui AX Code si limita a parlare non sono elencati lì, per quanto da vicino siano stati studiati mentre si costruiva il ponte. Il caso più chiaro sono i provider CLI: Claude Code, Codex CLI, Grok Build CLI e Muse Code CLI sono nominati nelle tabelle dei provider perché AX Code invoca quei binari locali e riusa le loro sessioni di accesso, non perché il loro codice sia distribuito qui. I motivi di ID di modello, le tabelle di capacità e il parsing specifico del fornitore in packages/ax-code/src/provider/ sono la logica di interoperabilità propria di AX Code. I file che sono davvero derivazioni letterali portano un’intestazione di provenienza di una riga che nomina l’upstream, così un audit può distinguere il riuso deliberato da una pulizia mancata.

Avanti

Evidenza di esecuzione — i comandi che rendono revisionabile un’esecuzione
Modifiche multi-modello verificate — council e arena
Inizia qui — il modello mentale del prodotto