Cos'è Command Code?

Command Code è un agente di coding a riga di comando pensato per modelli open, cioè non legati a un singolo laboratorio come Anthropic o OpenAI: si distingue da Claude Code, il prodotto omonimo di Anthropic con cui il nome si confonde facilmente, perché nasce da un'azienda diversa (Command Code, già Langbase, fondata da Ahmad Awais) e insegue un obiettivo diverso, cioè apprendere lo stile personale di chi scrive codice invece di limitarsi a eseguire istruzioni. Si installa con un pacchetto npm globale e si lancia dentro un progetto con il comando cmd. Il suo tratto più originale è "taste": ogni accettazione, rifiuto o modifica di una proposta diventa, secondo l'azienda, un segnale che alimenta un modello proprietario chiamato taste-1, descritto come un'architettura che combina un modello linguistico con componenti neuro-simboliche per trasformare quelle preferenze in vincoli riutilizzabili. È una promessa del produttore, non una proprietà misurabile da fuori, ed è bene trattarla come tale.

Leggi anche: Claude Code · Lo strumento di Anthropic per lo sviluppo agentico: nato nel terminale, oggi disponibile anche negli IDE, come app desktop e nel browser.

Cosa cambia rispetto agli strumenti simili

A differenza di opencode e di Pi, entrambi distribuiti con licenza MIT, Command Code non è open source: il pacchetto npm è dichiarato UNLICENSED. Vende piani a crediti, ma accetta anche le chiavi API dell'utente per provider compatibili con le API OpenAI o Anthropic, e in quel caso, secondo la documentazione, le richieste vanno direttamente al provider e all'azienda arriva solo telemetria disattivabile. "Il miglior agente per modelli open" è lo slogan con cui l'azienda si presenta, non un primato verificato da terzi. Il meccanismo di condivisione dello stile fra colleghi (taste push/pull) solleva la domanda più interessante per chi decide in azienda: dove vive quel profilo di preferenze, chi lo controlla e cosa succede quando le abitudini di un solo sviluppatore, magari il più prolifico, vengono imposte a tutto il team come impostazione predefinita. Un file di convenzioni versionato come AGENTS.md è una decisione esplicita e leggibile da chiunque; un modello che impara in silenzio da un singolo autore è l'opposto, e le due cose possono divergere senza che nessuno se ne accorga finché il codice non lo mostra.

Un esempio enterprise

Un team con tre sviluppatori senior e due junior adotta Command Code per accelerare la scrittura di microservizi. Dopo un mese lo strumento ha assorbito soprattutto le abitudini del senior che scrive di più: una particolare gestione degli errori, una libreria di validazione preferita, un modo di nominare i file di test. I junior ricevono suggerimenti coerenti con quello stile anche quando la convenzione di squadra scritta in AGENTS.md dice altro, perché nessuno ha ancora confrontato i due. Il rimedio è di processo, non tecnico: chi introduce lo strumento deve decidere se il profilo di preferenze converge verso AGENTS.md o lo scavalca, e mettere quella scelta per iscritto prima che il divario cresca da solo.

Perché conta per chi decide

Il vero costo di adozione non è la licenza mensile ma capire chi possiede lo stile del proprio team dopo che un modello proprietario lo ha assorbito: se quel profilo resta legato all'account dell'azienda che vende lo strumento, cambiare fornitore in futuro significa perdere anche quella parte, non solo riconfigurare un client. Vale lo stesso principio di reversibilità che guida la scelta fra agenti legati a un solo laboratorio e agenti indipendenti dal modello: prima di lasciare che un'abitudine individuale diventi il default del team, conviene chiedersi se quella convenzione dovrebbe stare in un file che tutti possono leggere, invece che in un modello che nessuno può ispezionare.