Cloudflare ha appena portato in open beta cf, una nuova CLI pensata per coprire l’intera superficie delle sue API e per essere usata bene non soltanto dagli sviluppatori, ma anche dagli agenti AI. La headline facile sarebbe: “Cloudflare lancia una CLI per l’intelligenza artificiale”. È corretta, ma racconta la parte meno interessante della storia.
La parte interessante è che un’azienda che gestisce migliaia di operazioni API ha iniziato a progettare esplicitamente l’interfaccia considerando come utente anche qualcosa che non è umano. E quando cambia il tipo di utente, cambiano inevitabilmente anche le regole con cui conviene progettare il software.
Cloudflare dichiara che, nel marzo 2026, gli agenti rappresentavano circa un quarto dell’utilizzo di Wrangler e che nell’ultima settimana sono arrivati al 48%. Sempre secondo i dati pubblicati dall’azienda, gli agenti usano quasi il doppio dei comandi distinti al giorno e sono quasi quattro volte più propensi a usare sei o più comandi. Sono numeri interni di Cloudflare, quindi vanno letti come tali, ma spiegano bene perché l’azienda abbia deciso di ripensare la propria CLI attorno a questo scenario.
La notizia non è una nuova CLI
Wrangler è cresciuto nel tempo insieme ai prodotti Cloudflare. Il risultato è quello che succede spesso ai sistemi che funzionano abbastanza bene da continuare a ricevere pezzi: convenzioni differenti, comandi costruiti da team diversi, output non sempre omogeneo e una copertura parziale rispetto alla superficie complessiva delle API.
Cloudflare parla di circa 280 percorsi di comando disponibili in Wrangler a fronte di oltre 3.000 operazioni API. Con cf l’obiettivo è arrivare a coprire l’intera superficie, generando buona parte dell’interfaccia attraverso Forge, la pipeline che Cloudflare ha reso open source e che deriva CLI, SDK e documentazione dalle definizioni delle API.
Questa è già una scelta architetturale più interessante dell’etichetta “agentic”: invece di continuare ad aggiungere manualmente comandi a un sistema nato per uno scenario diverso, si sposta il problema a monte e si cerca di rendere la sorgente dell’informazione abbastanza strutturata da generare in modo coerente le diverse interfacce.
Quando l’utente è un agente, l’ambiguità costa
Una persona davanti a un terminale tollera parecchia incoerenza. Può leggere una tabella, capire dal contesto che un comando usa get mentre un altro usa info, cercare un esempio nella documentazione e correggersi dopo un errore.
Un agente può fare le stesse cose, ma ogni ambiguità genera lavoro aggiuntivo: più contesto da caricare, più tentativi, più output da interpretare, più round trip verso il modello e più occasioni per prendere una decisione sbagliata. Il fatto che un LLM riesca spesso a recuperare da un’interfaccia incoerente non significa che quell’interfaccia sia progettata bene.
Qui cf fa alcune scelte molto concrete. L’output predefinito è JSON; esiste cf cli search per trovare il comando corretto partendo da una richiesta in linguaggio naturale; la nuova configurazione cloudflare.config.ts è tipizzata; la nomenclatura viene resa più uniforme; Vite diventa la base del flusso di sviluppo per i Workers compatibili.
Non c’è magia in nessuna di queste cose. Ed è precisamente questo il punto.
La cosa più moderna qui dentro è terribilmente vecchia
Output strutturato, contratti prevedibili, naming coerente, tipi, schemi, strumenti di discovery: sono tutte idee che esistono da molto prima dell’attuale ondata di AI generativa. La differenza è che gli agenti rendono molto più evidente il costo di non averle applicate.
Per anni abbiamo potuto compensare interfacce mediocri scaricando complessità sulle persone. Una documentazione enorme poteva nascondere un’API poco intuitiva. Un pannello grafico poteva rendere sopportabile una tassonomia incoerente. Un programmatore esperto imparava le eccezioni e andava avanti.
Quando invece vuoi che un processo automatico capisca cosa può fare, trovi l’operazione corretta, la esegua e interpreti il risultato senza un essere umano che gli sistema continuamente la strada, le eccezioni smettono di essere dettagli. Diventano costo operativo.
JSON non è una scelta estetica
Cloudflare racconta che gli agenti che usavano Wrangler tendevano ad aggiungere --json ai comandi e poi a filtrare il risultato con jq. Il problema è che non tutti i comandi supportavano output JSON e molti restituivano tabelle pensate per essere lette da una persona.
In cf il ragionamento viene ribaltato: se il consumatore più frequente di un certo output è una macchina, ha poco senso costringerla a decodificare una rappresentazione decorativa prima di arrivare ai dati. La presentazione per la persona può essere costruita dopo; il contratto di base dovrebbe restare strutturato.
È un esempio molto semplice di un principio che vale ben oltre Cloudflare. Quando parlo di ottimizzare le risorse, dal codice ai processi, il punto non è inseguire qualche millisecondo per sport: è eliminare lavoro inutile dal sistema. Token, chiamate, trasformazioni e tentativi di interpretazione sono risorse esattamente come CPU, memoria e I/O.
La configurazione tipizzata conta più di un prompt scritto bene
Una delle scelte più interessanti è cloudflare.config.ts. La configurazione diventa TypeScript, con tipi e supporto del language server. Questo significa che un editor — e quindi anche un agente che usa gli strumenti dell’editor — può conoscere proprietà valide, errori, completamenti e relazioni senza dover ricostruire tutto ogni volta dalla documentazione.
Un prompt può spiegare a un agente cosa vorremmo che facesse. Un tipo può impedirgli di costruire una certa configurazione nel modo sbagliato. Sono due strumenti diversi e, quando si parla di sistemi autonomi, il secondo viene spesso sottovalutato.
Non significa che i tipi rendano impossibili gli errori. Significa che una parte dell’ambiguità viene spostata dal linguaggio naturale a un contratto verificabile. È esattamente la direzione che ci si aspetterebbe da sistemi in cui l’automazione deve crescere senza trasformare ogni esecuzione in un atto di fede.
Più autonomia richiede più controllo, non meno
C’è poi l’altra metà del problema. Se una CLI passa da qualche centinaio di operazioni a migliaia e viene consegnata a un agente capace di concatenarle, la capacità del sistema aumenta. E con quella aumenta anche il costo potenziale di una decisione sbagliata.
Per questo l’evoluzione “agentic” degli strumenti non può fermarsi a rendere tutto più facile da invocare. Servono confini leggibili, permessi, differenze esplicite tra locale e remoto, output verificabili, audit e possibilità di capire che cosa è successo dopo l’esecuzione. Già nella prima anteprima di cf pubblicata ad aprile, Cloudflare insisteva sulla necessità di rendere chiaro agli agenti se un comando stesse operando su risorse locali o remote.
È una lezione generale: dare a un agente più strumenti senza migliorare contemporaneamente il modello di controllo non produce un sistema più intelligente. Produce semplicemente un sistema con più modi di sbagliare.
La vera interfaccia per l’AI è un sistema meno ambiguo
Se togliamo la parola “AI” dalla presentazione, quello che rimane di cf è quasi rassicurante: una CLI più coerente, output strutturato, ricerca dei comandi, configurazione tipizzata, una pipeline di generazione per tenere sincronizzate API e strumenti, un percorso di migrazione e una base di sviluppo più standardizzata.
Ed è proprio per questo che il progetto è interessante. Gli agenti non stanno cancellando le regole della buona progettazione software. Stanno facendo emergere con brutalità quanto costano le interfacce incoerenti, le configurazioni non verificabili e i processi che funzionano soltanto perché una persona esperta sa dove mettere le mani.
Il futuro degli strumenti per gli agenti probabilmente avrà modelli migliori, contesti più grandi e automazioni più sofisticate. Ma se vogliamo che quei sistemi lavorino davvero, una buona parte del lavoro resterà molto meno spettacolare: progettare contratti chiari, ridurre le eccezioni e smettere di chiedere alla macchina di indovinare ciò che il software avrebbe dovuto dichiarare esplicitamente.
Fonti
- Cloudflare — Introducing cf: the agentic CLI for the entire Cloudflare API
- Cloudflare — Introducing Forge: the open source pipeline for generating SDKs, CLIs, docs, and more
- Cloudflare — Building a CLI for all of Cloudflare
- Cloudflare Developers — Miniflare v5 prepares local development for the cf CLI
Domande frequenti
Che cos’è Cloudflare cf?
cf è la nuova CLI di Cloudflare, attualmente in open beta, progettata per offrire accesso coerente all’intera superficie delle API Cloudflare e per essere usata sia dagli sviluppatori sia dagli agenti AI.
In cosa differisce cf da Wrangler?
Wrangler è cresciuto nel tempo insieme ai diversi prodotti Cloudflare e copre solo una parte delle operazioni disponibili. cf nasce invece con l’obiettivo di coprire l’intera superficie API, con convenzioni più uniformi e una generazione più sistematica di CLI, SDK e documentazione.
Perché cf è più adatto agli agenti AI?
Perché riduce l’ambiguità: usa JSON come output predefinito, offre ricerca dei comandi in linguaggio naturale, adotta una configurazione TypeScript tipizzata e punta a una nomenclatura più coerente. Per un agente significa meno parsing, meno tentativi e meno contesto sprecato.
Cosa insegna cf sulla progettazione di software per agenti?
Che gli agenti non rendono obsolete le buone pratiche software: le rendono più importanti. Contratti chiari, output strutturato, tipi, permessi, distinzione tra operazioni locali e remote e auditabilità diventano fondamentali quando il software deve agire con maggiore autonomia.
