Moonshot AI ha rilasciato Kimi Code CLI, un coding agent da terminale che al 6 giugno 2026 conta 11 release, 1,9 mila stelle e 193 fork su GitHub. Il tool è pubblicato con licenza MIT, gira da riga di comando e porta i modelli Kimi nel flusso quotidiano dello sviluppo software.
Conta perché il terminale resta il luogo in cui molti sviluppatori prendono decisioni operative: leggono log, lanciano test, modificano file e controllano una build prima della consegna. Kimi Code prova a trasformare quel contesto in un ambiente agentico, dove l’AI osserva il progetto, chiama strumenti e corregge il piano in base ai risultati.
Kimi Code entra nella gara degli agenti da terminale
La notizia, rilanciata da MarkTechPost il 6 giugno, inserisce Moonshot AI nello stesso spazio degli assistenti di coding che non vivono solo nell’IDE, ma direttamente nella shell. Il repository ufficiale presenta Kimi Code CLI come successore della precedente esperienza kimi-cli, ora ricostruita su Node.js e TypeScript, con distribuzione tramite script o npm.
Nella documentazione ufficiale, Moonshot usa una definizione asciutta:
“Kimi Code CLI is an AI agent that runs in the terminal.”
Il punto non è solo la disponibilità del codice. La pagina prodotto di Kimi Code lo presenta come un benefit della membership Kimi e mostra il modello kimi-for-coding alimentato da Kimi K2.6. Qui nasce una distinzione importante: il client è aperto e MIT, mentre l’accesso operativo passa da OAuth Kimi Code o da una chiave API della piattaforma Moonshot. Per un team aziendale, questa differenza pesa più della schermata di installazione.
Come funziona Kimi Code nel flusso tecnico
Kimi Code lavora come coding agent, cioè un sistema che riceve un obiettivo, esplora il codice, usa strumenti locali e aggiorna il piano mentre procede. Secondo la guida ufficiale, può leggere e modificare codice, eseguire comandi shell, cercare file, recuperare pagine web, lanciare build e concatenare script. Le operazioni di sola lettura partono senza conferma; modifiche ai file e comandi shell richiedono approvazione.
L’installazione segue due strade. Lo script ufficiale non richiede Node.js già installato: scarica l’ultima release, verifica il checksum e mette l’eseguibile kimi nel PATH. L’alternativa npm richiede Node.js 24.15.0 o superiore. Su Windows serve anche Git for Windows, perché il CLI usa Git Bash come ambiente shell.
La parte più interessante arriva con l’orchestrazione. Kimi Code include tre sub-agent integrati: coder per interventi concreti sul codice, explore per esplorare repository in sola lettura e plan per ragionare su architettura e implementazione senza toccare i file. Ogni sub-agent lavora in un contesto isolato e restituisce solo il risultato al thread principale.
C’è poi il Model Context Protocol (MCP), spiegato in modo più ampio nel Glossario AI, che consente al modello di collegarsi a strumenti esterni come database, GitHub issue o filesystem. Kimi Code agisce da client MCP e permette di configurare server a livello utente o progetto anche tramite /mcp-config. Gli hook aggiungono script locali che scattano prima o dopo eventi specifici, per esempio bloccare comandi rischiosi o inviare notifiche.
La domanda che nessun annuncio ufficiale affronta fino in fondo è semplice: se un agente può leggere repository, lanciare shell e collegarsi a servizi interni, chi nel team decide quali azioni restano sempre vietate?
I limiti che contano davvero
La licenza MIT aiuta l’adozione, ma non risolve governance, sicurezza e responsabilità. Un agente nel terminale opera nello stesso spazio in cui vivono segreti, file di configurazione, script di deploy e credenziali dimenticate. Le conferme manuali riducono il rischio, però non sostituiscono policy interne, permessi del sistema operativo e controlli sui repository.
Moonshot stessa segnala un punto delicato nella documentazione degli hook: il design è fail-open. Se uno script di controllo va in errore o scade, il CLI non blocca automaticamente il lavoro. Per notifiche e controlli leggeri va bene; come barriera di sicurezza primaria no.
C’è anche un limite economico. Kimi Code rende aperto il client, non il costo dell’inferenza. Ogni sessione lunga, ogni sub-agent parallelo e ogni analisi di repository consuma token sul modello scelto. Per una software house con decine di sviluppatori, la metrica da guardare diventa il costo per pull request completata.
Cosa cambia per chi sviluppa in Italia
Per il lettore italiano, Kimi Code segnala che il mercato degli strumenti AI per sviluppatori non si giocherà solo dentro Visual Studio Code o JetBrains. Il terminale torna centrale perché offre accesso diretto al ciclo reale del software: codice, test, log, git, script di build e deploy.
Per startup, consulenti e team IT interni, il primo uso sensato non è affidargli un refactor critico. È provarlo su repository non sensibili, task ripetitivi, migrazioni controllate e test mancanti. La valutazione dovrebbe misurare tre cose: tempo risparmiato, interventi manuali richiesti e qualità delle modifiche dopo review umana.
Kimi Code non cambia il mestiere dello sviluppatore in una settimana. Cambia però la soglia d’ingresso per sperimentare agenti da terminale con sub-agent, MCP e automazioni locali. Chi in Italia gestisce codice, fornitori o team distribuiti ha una decisione concreta da prendere: definire ora regole di utilizzo, logging e ambienti consentiti, prima che questi strumenti entrino nei repository attraverso iniziative individuali.
Fonti citate
- Getting started | Kimi Code Docs , Moonshot AI / Kimi, consultata il 6 giugno 2026.
- Moonshot AI Releases Kimi Code CLI: A Terminal AI Coding Agent Built in TypeScript for Next-Gen Agents , MarkTechPost, 6 giugno 2026.