Un developer ha pubblicato su GitHub un agente di coding che si riduce all’essenza: nove righe di Python, nessuna dipendenza esterna, un solo tool – la shell. Il codice, raccolto sotto il progetto smol-env/smol, nasce da una domanda radicale: quanto può essere minimale un assistente AI per lo sviluppo prima di diventare inutile? La risposta, per ora, è stupefacente: bastano un ciclo di input, una chiamata a un’API compatibile con OpenAI Responses, e un esecutore di comandi.

Il trucco sta tutto nell’uso della standard library. Richieste HTTP, parsing JSON, esecuzione di sottoprocessi e gestione delle sessioni sono affidate a moduli integrati in Python, senza importare librerie di terze parti. L’agente mantiene una cronologia dei messaggi in modalità append-only, sfrutta un session_id per la cache lato server e mostra in percentuale l’occupazione della finestra di contesto, tutto con una chiarezza che sfiora il didattico. Niente system prompt, niente toolchain complicati: solo l’invocazione di un custom tool chiamato “sh” che traduce i comandi in azioni concrete.

Per chi opera in ambienti on-premise o air-gapped, questo esperimento ha un sapore diverso. Non si tratta di una curiosità da hacker, ma di un principio: l’agente più utile è spesso quello che aggiunge meno strati possibili tra il modello e l’utente. In un contesto di deployment self-hosted, ogni dipendenza esterna è un vettore di rischio, un costo di manutenzione, un potenziale collo di bottiglia per la sicurezza. Un agente che gira con Python vanilla e comunica con un endpoint LLM locale (via vLLM, Ollama o qualsiasi server compatibile) azzera il debito di dipendenze e riduce la superficie d’attacco. La scelta di non usare system prompt, inoltre, taglia via token di overhead che, nel calcolo del TCO, diventano costi reali quando si processano migliaia di interazioni.

L’uso di un’API “custom tools”, ammesso dallo stesso autore come ancora poco supportata, è un segnale: il panorama API sta evolvendo per includere strumenti generici senza la rigidità dei function calling. In attesa che gli endpoint più diffusi lo adottino, basta modificare il nome del modello e il tipo di tool per far funzionare l’agente con qualsiasi interfaccia locale. È questa flessibilità che trasforma nove righe di codice in un manifesto di portabilità: lo stesso script può colloquiare con modelli open weight girati su hardware consumer, GPU industriali o cluster Kubernetes.

Le implicazioni vanno oltre la comodità. L’esistenza di un agente così scarno mette in discussione l’architettura ipertrofica di molti assistenti commerciali. Se un piccolo script può orchestrare un LLM in modo efficace, forse la complessità di piattaforme come GitHub Copilot o Cursor è, in buona parte, interfaccia e integrazione con IDE, non potenza intrinseca. Per le aziende che vogliono affiancare ai propri sviluppatori un copilota interamente in-house, senza mandare codice sorgente in cloud, un simile approccio minimalista è un prototipo di rotta alternativa: auditabile, personalizzabile, e governabile con gli stessi strumenti che già presidiano l’infrastruttura interna.

Di secondo ordine, si intravede una tendenza alla composizione: agenti a singolo file, in Python ma anche in Go (una versione da ~20 righe è già disponibile) o in Clojure (annunciata), che possono essere combinati senza dipendere da framework pesanti. Sul medio periodo, ciò sposta gli incentivi: la forza di un assistente AI non la fa più il vendor di tooling, ma la qualità del modello e la capacità di eseguire azioni affidabili. Per chi investe in hardware locale, questo significa che con poche decine di righe di codice si può sbloccare un’esperienza di co-sviluppo AI privata, riducendo la dipendenza da servizi esterni e rendendo ogni scelta infrastrutturale più libera.

La storia di queste nove righe è, in fondo, una lezione di minimalismo computazionale che l’industria dell’AI locale fatica ancora ad assimilare: non servono sempre orchestrazioni complesse per ottenere valore da un LLM. A volte basta un ciclo while e un po’ di buonsenso.