cool-solution — dev.blog
Tecnologie

Repo del giorno: Grok Build, il coding agent di xAI ora open source

Usiamo coding agent tutti i giorni, ma di come funzionano dentro vediamo poco: l'harness — il pezzo che assembla il contesto, interpreta le risposte del modello e smista le tool call — è quasi sempre una scatola chiusa. Il 15 luglio 2026 xAI ha fatto un'eccezione interessante: ha pubblicato su GitHub il sorgente completo di Grok Build, il suo coding agent da terminale, con licenza Apache 2.0. Non un progetto dimostrativo: è il codice Rust dell'agente vero, quello che l'azienda distribuisce come binario `grok`, sincronizzato periodicamente dal monorepo interno. In due settimane il repository ha superato le 19.000 stelle. L'ho scelto come repo del giorno perché, al di là del modello che ci gira sotto, è uno dei modi migliori che ho visto per studiare l'anatomia di un harness agentico di produzione — e perché si può compilare in proprio e puntare alla propria inference locale.

$ claude "refactor user.service to async/await" reading src/services/user.service.ts... proposing 12 edits across 3 files ✓ tests still pass (47 / 47) applying patch...AI PAIRsupervised

🔍 Cos'è Grok Build

Grok Build è il coding agent da terminale di xAI: una TUI fullscreen, interattiva anche col mouse, che legge il codebase, modifica i file con revisione dei diff, esegue comandi shell, cerca sul web e gestisce task lunghi. Lanciato in beta a maggio 2026 e pensato per chi lavora su codebase grandi, funziona in tre modalità: interattiva nel terminale, headless per script e pipeline CI, e dentro gli editor tramite l'Agent Client Protocol (ACP), lo stesso meccanismo con cui altri agenti si integrano negli IDE.

Il repository pubblicato contiene il sorgente Rust (99,6% del codice) della CLI/TUI e del runtime dell'agente. Il codice di prima parte è sotto Apache 2.0; le parti di terzi restano sotto le licenze originali. Un dettaglio che dice molto sullo stato dell'ecosistema: fra le notice di terze parti ci sono port in-tree delle implementazioni dei tool di openai/codex e di sst/opencode — gli harness open source si stanno letteralmente scambiando i pezzi.

La carta d'identità del repo
repo       xai-org/grok-build
cosa       coding agent da terminale (harness + TUI) di xAI, ora open source
come       Rust 99,6% · binario `grok` · TUI, headless o editor via ACP
estensioni skill, plugin, hook, server MCP, subagent
extra      local-first: compilalo tu e punta alla tua inference da config.toml
licenza    Apache 2.0 (prima parte) · ~19.600 stelle · sync dal monorepo

Repo ufficiale · xai-org/grok-build

Non un demo: è il sorgente dell'agente di produzione, sincronizzato periodicamente dal monorepo interno.

⚙️ Come si prova: binario o compilazione dal sorgente

La via rapida è il binario precompilato, pubblicato per macOS, Linux e Windows: uno script di installazione e il comando `grok` è pronto; al primo avvio apre il browser per l'autenticazione. È il percorso per chi vuole usare l'agente, non studiarlo.

La via interessante per chi legge questo articolo è la seconda: compilare dal sorgente con Cargo. Servono la toolchain Rust (bloccata da `rust-toolchain.toml`, la installa `rustup` alla prima build), DotSlash per scaricare gli strumenti ermetici in `bin/` (in particolare `protoc` per la generazione del codice dai proto) e poco altro. Il binario prodotto si chiama `xai-grok-pager`; le installazioni ufficiali lo distribuiscono come `grok`. macOS e Linux sono i sistemi di build supportati, Windows è best-effort.

Installazione e build dal sorgente
# Via rapida: binario ufficiale (macOS / Linux / Git Bash)
curl -fsSL https://x.ai/cli/install.sh | bash
grok --version

# Via studio: compilazione dal sorgente
cargo install dotslash          # prerequisito per bin/protoc
git clone https://github.com/xai-org/grok-build && cd grok-build
cargo run -p xai-grok-pager-bin              # build + avvio della TUI
cargo build -p xai-grok-pager-bin --release  # binario di release

Documentazione ufficiale · docs.x.ai

Il binario compilato si chiama xai-grok-pager: è lo stesso che le release ufficiali distribuiscono come `grok`.

🧩 L'anatomia dell'harness: i crate che contano

La parte che rende il repository una lettura preziosa è la separazione dei crate, perché rispecchia l'architettura tipica di un coding agent moderno. `xai-grok-pager` è la TUI — scrollback, prompt, modali, rendering. `xai-grok-shell` è il runtime dell'agente, con gli entry point leader, stdio e headless. `xai-grok-tools` implementa i tool veri e propri: terminale, modifica dei file, ricerca. `xai-grok-workspace` gestisce filesystem, version control, esecuzione e checkpoint. Attorno, i crate di contorno: configurazione, MCP, markdown, sandbox.

È esattamente la mappa che serve a chi vuole capire come funziona un agente: l'annuncio di xAI dichiara che il sorgente pubblicato copre il loop dell'agente (come si assembla il contesto, come si interpretano le risposte del modello, come si smistano le tool call), i tool, la UI del terminale con il diff viewer inline, e il sistema di estensioni. Se lavori con skill, plugin, hook o server MCP su un qualunque agente, qui vedi nero su bianco come vengono caricati e invocati.

Il giro di un prompt dentro l'harness
  1. 01
    ContestoL'agente assembla codebase, istruzioni ed estensioni nel contesto
  2. 02
    ModelloLa risposta del modello viene parsata dal runtime (xai-grok-shell)
  3. 03
    Tool dispatchLe tool call vengono smistate ai tool (xai-grok-tools)
  4. 04
    WorkspaceFile, VCS, esecuzione e checkpoint passano da xai-grok-workspace
  5. 05
    TUIDiff inline e revisione del piano nella TUI (xai-grok-pager)

La separazione dei crate rispecchia i pezzi canonici di un coding agent: loop, tool, workspace, interfaccia.

🏠 Local-first: il tuo binario, la tua inference

Il punto più concreto dell'apertura del sorgente è che Grok Build ora può girare completamente local-first: lo compili tu, lo punti alla tua inference — anche un modello servito in locale — e governi tutto dal `config.toml`. Per chi ha vincoli di riservatezza sul codice, è la differenza fra «mi fido della pipeline del vendor» e «so esattamente che cosa esce dalla mia macchina, perché posso leggerlo nel sorgente».

La documentazione utente, inclusa nel repository e pubblicata su docs.x.ai, copre il resto della superficie: scorciatoie da tastiera, slash command, configurazione, theming, server MCP, skill, plugin, hook, modalità headless e sandboxing. Sono gli stessi concetti che chi usa Claude Code o Codex CLI già conosce — cambiano i nomi dei file, non le idee.

Binario ufficiale vs build local-first

Binario ufficiale

  • Installazione in un comando, aggiornamenti gestiti
  • Autenticazione con l'account xAI al primo avvio
  • Inference sui modelli Grok via API
  • Nessuna visibilità su cosa fa il processo, oltre ai doc

Compilato dal sorgente

  • Build riproducibile con Cargo (toolchain bloccata)
  • Puoi puntare alla tua inference, anche locale
  • Tutto governato dal config.toml
  • Il comportamento è verificabile leggendo il codice

La modalità local-first è la novità vera dell'open-sourcing: harness leggibile e inference sotto il tuo controllo.

🏢 Perché è interessante, per sviluppatori e PMI

Per chi sviluppa, il valore non è (solo) un altro agente da provare: è un testo di riferimento. Le domande che ci facciamo configurando un agente — perché la skill non viene caricata? come vengono passati i risultati dei tool al modello? cosa entra davvero nel contesto? — qui hanno una risposta leggibile nel sorgente, in un linguaggio, Rust, che rende espliciti confini e responsabilità dei moduli. Anche solo confrontare come Grok Build, Codex e opencode implementano lo stesso tool di modifica file è una lezione di progettazione; i port in-tree dimostrano che le implementazioni sono ormai un patrimonio condiviso fra harness.

Per una PMI che sta introducendo agenti nei processi di sviluppo, il segnale è la maturazione dell'infrastruttura: i coding agent stanno convergendo su primitive comuni — skill, plugin, hook, MCP, subagent, sandboxing — e diventano componenti ispezionabili, non servizi opachi. La possibilità di compilare l'harness e tenere l'inference in casa apre scenari per chi ha requisiti stretti su dove passa il codice sorgente. Resta una valutazione da fare caso per caso: l'uso di default resta legato ai modelli e all'account xAI, e la governance va ragionata come per qualunque agente.

⚠️ Limiti e cautele prima di adottarlo

Qualche onestà. Il primo limite è di natura: è codice aperto, non un progetto di comunità. Le contribuzioni esterne non sono accettate, il repository è un mirror sincronizzato periodicamente dal monorepo interno (la storia pubblica parte con una manciata di commit e un file `SOURCE_REV` che registra lo SHA di origine), e il `Cargo.toml` di radice è generato e va trattato come read-only. Leggere sì, forkarlo anche, farci accettare una PR no.

Sul piano pratico: la build richiede prerequisiti non banali per chi non mastica Rust (DotSlash, protoc via strumenti ermetici), Windows come host di build è dichiaratamente best-effort, e l'esperienza «ufficiale» — autenticazione, modelli, changelog — resta agganciata all'ecosistema xAI. Infine, la fotografia delle stelle è di questi giorni e il progetto è giovane come open source: struttura dei crate e superficie di configurazione possono cambiare a ogni sync.

  • Niente contribuzioni esterne: repository in sola lettura per la comunità, sync periodico dal monorepo.
  • Cargo.toml di radice generato: si modificano i Cargo.toml per-crate, non quello globale.
  • Build con prerequisiti: toolchain Rust bloccata, DotSlash e protoc; Windows best-effort.
  • Default legato a xAI: senza configurazione local-first, autenticazione e inference passano dai servizi Grok.
  • Progetto giovane come open source: struttura e config possono cambiare fra un sync e l'altro.

✅ Da dove partire

Il percorso che suggerisco parte dalla lettura, non dall'uso: clona il repository e apri `crates/codegen/xai-grok-tools` per vedere come sono implementati i tool di modifica file e terminale, poi `xai-grok-shell` per il loop dell'agente. Se usi già un altro agente, confronta le implementazioni con quello che conosci: è il modo più rapido per capire cosa fa davvero il tuo strumento quotidiano. Come secondo passo, prova la build con Cargo e lancia la TUI; come terzo, sperimenta la configurazione local-first puntando a una inference tua.

Il segnale più ampio è la direzione dell'ecosistema: dopo Codex e opencode, anche xAI ha messo il proprio harness sul tavolo, con tanto di port dichiarati delle implementazioni altrui. Gli harness agentici stanno diventando infrastruttura comune e leggibile — e per chi costruisce software con gli agenti, saperli leggere sta diventando una competenza di base.

Domande frequenti su Grok Build

Cos'è Grok Build e a cosa serve?

È il coding agent da terminale di xAI: una TUI fullscreen che legge il codebase, modifica i file con revisione dei diff, esegue comandi e gestisce task lunghi. Funziona in modalità interattiva, headless per script e CI, o dentro gli editor via Agent Client Protocol. Dal 15 luglio 2026 il sorgente Rust completo è pubblicato su GitHub con licenza Apache 2.0.

Posso usarlo con modelli diversi da Grok o in locale?

Sì, è la novità principale dell'open-sourcing: compilando dal sorgente puoi puntare l'harness alla tua inference, anche un modello servito in locale, governando tutto dal config.toml. Il binario ufficiale, invece, si autentica con l'account xAI e usa i modelli Grok via API.

Posso contribuire al progetto?

No: le contribuzioni esterne non sono accettate. Il repository è un mirror del monorepo interno di xAI, sincronizzato periodicamente (il file SOURCE_REV registra il commit di origine). Si può leggere, forkarlo e compilarlo liberamente sotto Apache 2.0, ma lo sviluppo resta interno all'azienda.

Che cosa serve per compilarlo dal sorgente?

La toolchain Rust (bloccata da rust-toolchain.toml, la installa rustup alla prima build), DotSlash per gli strumenti ermetici in bin/ — in particolare protoc per la generazione del codice — e un host macOS o Linux (Windows è best-effort). Il comando è `cargo run -p xai-grok-pager-bin`; il binario prodotto si chiama xai-grok-pager, distribuito ufficialmente come `grok`.

Parliamone

Se questo tema ti riguarda, scrivimi: confrontarsi su codice e AI è sempre tempo speso bene.

Altri articoli del blog

semantic-caching-llm-dotnet-redis.md27 luglio 2026tips-claude-claude-md-luglio-2026.md24 luglio 2026claude-code-pretooluse-hook-proteggere-env-segreti-2026.md24 luglio 2026