Immagine AI

SpaceXAI ha pubblicato con licenza Apache 2.0 il codice sorgente di Grok Build, il proprio agente di programmazione basato su terminale, rendendo accessibile agli sviluppatori l’infrastruttura software che collega i modelli di intelligenza artificiale ai repository, al file system, alla shell e agli strumenti utilizzati durante lo sviluppo. L’apertura riguarda il livello applicativo dell’agente, comprendente l’interfaccia, il runtime, i meccanismi di esecuzione e le integrazioni esterne, mentre non include i pesi del modello Grok utilizzato per generare ragionamenti, istruzioni e modifiche al codice.

Grok Build opera attraverso una terminal user interface a schermo intero, progettata per consentire allo sviluppatore di interagire con l’agente senza abbandonare l’ambiente a riga di comando. Il sistema può analizzare la struttura di un progetto, leggere e modificare file, eseguire comandi di shell, effettuare ricerche, utilizzare strumenti esterni e gestire attività che richiedono più passaggi. L’interazione può avvenire in modalità assistita, con controllo diretto dell’utente, oppure in modalità headless, rendendo possibile l’impiego dell’agente all’interno di script, procedure automatizzate e pipeline di integrazione continua.

Il codice è sviluppato prevalentemente in Rust ed è organizzato in componenti distinti che separano l’interfaccia visuale dalla logica agentica e dagli strumenti operativi. Il modulo TUI gestisce il rendering, la cronologia delle conversazioni, l’inserimento dei prompt, le finestre modali e l’interazione tramite tastiera o mouse. Il runtime coordina invece il ciclo di esecuzione dell’agente, interpreta le richieste, mantiene il contesto e distribuisce le operazioni tra i diversi strumenti disponibili.

Un ulteriore livello contiene le implementazioni dedicate alla modifica dei file, all’esecuzione dei comandi, alla ricerca e alle altre funzioni necessarie per intervenire concretamente sul progetto. Il workspace gestisce l’accesso al file system dell’host, l’integrazione con i sistemi di controllo versione, l’esecuzione dei processi e la creazione di checkpoint, permettendo di mantenere traccia delle modifiche applicate durante una sessione e di ripristinare uno stato precedente quando necessario.

L’apertura del codice consente di verificare direttamente in che modo Grok Build costruisce il contesto inviato al modello, quali informazioni raccoglie dal repository e come distribuisce le chiamate agli strumenti. Gli sviluppatori possono quindi analizzare il percorso seguito dall’agente prima di modificare un file o avviare un comando, controllando i passaggi che in un servizio completamente chiuso rimarrebbero confinati nell’infrastruttura del fornitore.

Il progetto può essere compilato ed eseguito all’interno di ambienti controllati, permettendo alle organizzazioni di modificare il comportamento dell’agente e adattarlo alle proprie procedure. La disponibilità del codice consente, per esempio, di intervenire sulle regole di accesso al file system, sugli strumenti autorizzati, sulle modalità di esecuzione dei comandi e sui controlli applicati prima che un’azione venga effettuata. Questa struttura rende possibile creare versioni interne del client, applicare policy aziendali e verificare con maggiore precisione quali dati vengono elaborati durante una sessione.

Grok Build supporta inoltre una modalità local-first, nella quale l’infrastruttura dell’agente può essere utilizzata insieme a modelli eseguiti localmente. In questa configurazione, il codice del progetto e le relative informazioni possono rimanere all’interno dell’ambiente dell’utente, senza dover essere necessariamente trasmesse a un servizio remoto. La possibilità concreta di mantenere l’intera elaborazione in locale dipende comunque dal modello selezionato, dalle integrazioni configurate e dagli strumenti esterni attivati durante l’esecuzione.

L’architettura comprende il supporto per Model Context Protocol, utilizzato per collegare l’agente a server che espongono strumenti e risorse aggiuntive attraverso un’interfaccia standardizzata. Mediante MCP, Grok Build può accedere a documentazione, database, sistemi di gestione dei progetti, servizi aziendali o strumenti di sviluppo senza incorporare direttamente ogni integrazione nel codice principale. Gli amministratori possono configurare i server disponibili e limitare le funzioni che l’agente è autorizzato a richiamare.

Il sistema può essere esteso anche attraverso plugin, skills e hooks. I plugin aggiungono nuove capacità o modificano l’interazione con gli strumenti, mentre le skills forniscono istruzioni e procedure specializzate che l’agente può utilizzare per svolgere determinate attività. Gli hooks permettono invece di attivare azioni in corrispondenza di eventi specifici, come l’esecuzione di un comando, la modifica di un file o il completamento di una fase del lavoro.

Questi meccanismi consentono di integrare automaticamente controlli di qualità, test, analisi statiche e verifiche di sicurezza. Un’organizzazione può configurare Grok Build affinché esegua una suite di test dopo una modifica, controlli la conformità del codice prima di applicare una patch oppure impedisca l’uso di determinati comandi. L’agente può quindi essere inserito all’interno di procedure già esistenti senza sostituire completamente gli strumenti utilizzati dal team.

L’esecuzione in modalità headless permette di utilizzare Grok Build come componente automatizzato. In questa modalità l’agente può ricevere un compito attraverso uno script, operare sul repository e restituire il risultato senza richiedere l’interazione continua di uno sviluppatore. Il sistema può essere collegato a processi di continuous integration, utilizzato per produrre modifiche preliminari, eseguire verifiche o preparare interventi che devono essere successivamente controllati e approvati da una persona.

È prevista anche l’integrazione con gli editor attraverso Agent Client Protocol. ACP separa l’interfaccia utilizzata dallo sviluppatore dal runtime dell’agente, permettendo a Grok Build di funzionare come backend agentico all’interno di ambienti di sviluppo compatibili. Lo stesso motore può quindi essere utilizzato dal terminale, da un editor oppure da un processo automatizzato, mantenendo una base comune per l’accesso ai file, l’esecuzione degli strumenti e la gestione del contesto.

La pubblicazione del codice segue le contestazioni relative alla raccolta dei dati durante le prime versioni del prodotto. Grok Build era stato configurato per caricare informazioni provenienti dai repository, comprendenti il codice, la cronologia Git e, in determinate circostanze, contenuti sensibili presenti nell’ambiente di sviluppo. SpaceXAI ha successivamente disattivato per impostazione predefinita la funzione di caricamento, rimosso la conservazione automatica configurata durante la fase beta e avviato la cancellazione dei dati di programmazione precedentemente archiviati.

Quando l’upload viene disattivato dalla CLI, il sistema applica una configurazione di conservazione zero, attraverso la quale i dati associati alla sessione non devono essere mantenuti dal servizio. La disponibilità del codice permette ora di controllare anche l’implementazione di questi comportamenti, individuando quali componenti avviano comunicazioni esterne e quali informazioni vengono incluse nelle richieste.

Il repository pubblico non adotta però un modello di sviluppo comunitario tradizionale. Il codice viene sincronizzato periodicamente dal monorepository interno di SpaceXAI, mentre i contributi esterni e le pull request non vengono accettati nel progetto ufficiale. Gli sviluppatori possono analizzare il software, crearne una copia, modificarlo e distribuire una versione derivata secondo i termini della licenza, ma non partecipano direttamente all’evoluzione della versione mantenuta dall’azienda.

L’apertura di Grok Build rende quindi ispezionabile e modificabile l’intero strato che trasforma un modello linguistico in un agente capace di intervenire sul software. Le organizzazioni possono esaminare il runtime, applicare controlli propri, integrare strumenti interni e valutare un’esecuzione locale, mantenendo comunque distinta questa infrastruttura dal modello Grok, che continua a essere fornito separatamente e non è compreso nel codice pubblicato.

Di Fantasy