Esta página é uma tradução da documentação em inglês. Comandos, identificadores e exemplos permanecem iguais. Runtime 7.24.4 · SDK 2.6.7. Original em inglês

Por que o AX Code

Status: Ativo Escopo: estado atual Última revisão: 2026-08-25 Responsável: mantenedores do AX Code

A maioria dos agentes de código otimiza o momento de escrever código. O AX Code otimiza o momento seguinte: decidir se vale a pena ficar com o que o agente produziu.

O que o AX Code otimiza

A saída de um agente é barata de gerar e cara de revisar. Quando um agente mexe em vinte arquivos de três módulos, o problema de quem revisa não é “esta linha está correta”, e sim “o que ele de fato fez, se passa e o que acontece se eu precisar desfazer”.

O AX Code é construído em torno desse problema:

• Evidência. Cada sessão é registrada como um log de eventos tipado — decisões de roteamento, atividade do modelo, passos, chamadas de ferramenta e resultados de ferramenta — mais instantâneos de arquivo tirados durante a execução.
• Verificação. Onde uma barreira pode ser imposta, as próprias checagens do repositório decidem. Candidatos da Arena e a aplicação de refatoração com barreira executam verificação de tipos, lint e testes antes de um resultado ser aceito.
• Reversibilidade. Os pontos de instantâneo são recuperáveis por passo, não só por sessão, inclusive alterações delegadas a sessões aninhadas no mesmo diretório de trabalho.
• A sua decisão. O AX Code classifica, pontua e informa. Ele não faz o merge por você.

Para quem ele é

Público principal:

• engenheiros seniores e staff que fazem alterações de consequência
• mantenedores de código aberto e de plataformas internas
• equipes que operam repositórios Git de médio e grande porte
• engenheiros que avaliam refatorações, migrações e correções entre módulos
• quem executa trabalho de agente sem supervisão ou agendado, que uma pessoa precise auditar depois

Não é o público principal:

• quem quer autocompletar no próprio texto
• quem faz uma edição rápida e descartável
• uma equipe cuja prioridade é delegação totalmente gerenciada na nuvem
• quem não quer usar Git nem executar as checagens do repositório

Nesses casos, um assistente de editor mais leve é de fato a ferramenta melhor, e esta página prefere dizer isso a exagerar.

Em que ele difere

Em vez de uma lista de recursos que envelhece, eis o que cada categoria otimiza:

Várias capacidades que o AX Code distribui estão, em 2026, amplamente disponíveis em outros lugares: sandbox, pontos de verificação e restauração, MCP, hooks, skills, subagentes, isolamento em worktree, agendamento, escolha de provedor e a execução de um prompt em vários modelos. Nenhuma delas, sozinha, é motivo para escolher o AX Code.

A combinação mais difícil de montar em outro lugar é: uma implementação candidata isolada, condicionada às próprias checagens do repositório, com a verificação em primeiro lugar na classificação, o registro completo da execução retido localmente e exportável — e sem merge automático.

O que não afirmamos

O posicionamento só é útil se sobreviver ao contato com o produto. De forma explícita:

• replay reconstrói; não executa de novo. Ele remonta e verifica o fluxo de eventos registrado. Não volta a executar modelos, ferramentas nem o mundo exterior.
• risk é uma heurística determinística, calculada a partir de rotatividade, estado da validação, falhas de ferramenta, caminhos tocados e padrões de arquivo sensíveis à segurança. Não é uma probabilidade, uma confiança calibrada nem uma garantia de segurança.
• branch bifurca o estado da sessão, não um ramo Git nem uma worktree. A Arena é o caminho de implementação com worktree do Git.
• compare compara execuções, não código-fonte. Informa risco, caminho de decisão e contagens de eventos — não é um visualizador de diff de código.
• As barreiras de verificação não são universais. Elas valem para candidatos da arena e para a aplicação de refatoração com barreira. Edições interativas comuns não são verificadas de forma automática.
• A prosa do AX Wiki é gerada por modelo a partir de fontes citadas. O planejamento, a validação, a atualização incremental e o quadro de seções protegidas ao redor dela são determinísticos.
• A visibilidade da ponte de CLI é parcial. O AX Code registra por completo a própria execução de ferramentas; o trabalho que acontece dentro de um processo de CLI do fornecedor só é visível pela saída dessa ponte.
• Algumas capacidades são opcionais. O runtime workflow exige AX_CODE_WORKFLOW_RUNTIME=1.

Proveniência, em linguagem direta

O AX Code começou na base de código do OpenCode, licenciada sob MIT. Isso está preservado no NOTICE e declarado no README, em vez de ficar escondido.

O que a DEFAI construiu sobre essa base é o assunto desta página: a camada de evidência de execução, o motor determinístico de depuração e de refatoração com verificação em worktree sombra, o grafo de inteligência de código e a análise de impacto, os modos de execução council e arena, o compilador do AX Wiki, o sandbox no nível do sistema operacional e o AX Code Desktop.

Integrar-se a um projeto não é derivar dele. A seção de proveniência do README, e o NOTICE, existem para carregar obrigações de licença sob a Seção 4(d) da Apache-2.0 — eles listam apenas origens cujo código o AX Code de fato copia e redistribui. Projetos com os quais o AX Code apenas conversa não são listados ali, por mais de perto que tenham sido estudados ao construir a ponte. Os provedores de CLI são o caso mais claro: Claude Code, Codex CLI, Grok Build CLI e Muse Code CLI aparecem nas tabelas de provedores porque o AX Code invoca esses binários locais e reutiliza as sessões de login deles, não porque algum código deles seja distribuído aqui. Padrões de ID de modelo, tabelas de capacidade e a análise específica de fornecedor em packages/ax-code/src/provider/ são a lógica própria de interoperabilidade do AX Code. Arquivos que de fato são derivações literais carregam um cabeçalho de proveniência de uma linha nomeando a origem, para que uma auditoria distinga reutilização deliberada de uma limpeza que ficou faltando.

A seguir

• Evidência de execução — os comandos que tornam uma execução revisável
• Alterações verificadas com vários modelos — council e arena
• Comece aqui — o modelo mental do produto