Francesco Massimo Gallo 
Sviluppo software che tocca magazzino, ecommerce, integrazioni e automazioni editoriali. Non è un monorepo da tutorial: è un sistema multi-tenant con API, job asincroni, connettori e regole di dominio che cambiano con i clienti. Per lavorarci ogni giorno uso Cursor come ambiente di sviluppo con agent AI. Non perché “l’AI scrive tutto”, ma perché su un codebase grande il vero collo di bottiglia non è digitare: è trovare il pezzo giusto prima di toccarlo.
Questo pezzo è build in public: condivido uno strumento che uso davvero e le ragioni tecniche, non una recensione da influencer. Parto da una ricerca pubblicata dal team di Cursor sulla semantic search negli agent.
Il problema reale: “dove gestiamo autenticazione / sync inventario / coda pubblicazione?”
In un progetto piccolo, grep e memoria bastano. In un progetto con decine (o centinaia) di servizi, la domanda tipica non è “come si scrive un `if`”, ma:
- dove vive la regola di ownership del tenant?
- chi aggiorna lo stato di un ordine prima che arrivi al WMS?
- quale job ripubblica su WordPress e con quali timeout?
Sono domande in linguaggio naturale. Un agent che risponde bene deve recuperare i file giusti, non solo generare testo plausibile. Cursor lo fa combinando ricerca per significato (semantic search) e ricerca letterale (grep/regex). Nella loro valutazione offline, la presenza della semantic search alza in media di circa 12,5% l’accuratezza nel rispondere a domande sul codebase (range 6,5%–23,5% a seconda del modello). Nei test online, su repository con oltre 1.000 file, aumenta anche la probabilità che il codice prodotto resti nel progetto.
Numeri da prendere per quello che sono: metriche di un produttore, su un bench interno. Per me contano perché descrivono un problema che vivo: su codebase grandi, cercare solo per stringa esatta lascia fuori pezzi “semanticamente” collegati ma con nomi diversi.
Semantic search ≠ “leggi tutto il repository”
L’idea sbagliata è che l’AI “conosca” il progetto. In realtà costruisce (e aggiorna) un indice: spezza il codice in chunk, genera embedding, recupera i segmenti più vicini alla domanda. Cursor spiega anche come rendere sostenibile l’indicizzazione su repo enormi — Merkle tree, aggiornamenti incrementali, riuso sicuro degli indici nel team — nel post Securely indexing large codebases.
Il punto operativo, per chi sviluppa software di logistica, è questo: il contesto è una risorsa scarsa. Non puoi infilare tutto il WMS nella finestra del modello. Devi far sì che l’agent carichi solo ciò che serve, quando serve. È lo stesso spirito del context engineering di Anthropic: meno dump statico, più recupero just-in-time.
Cursor lo chiama anche dynamic context discovery: pochi dettagli fissi in prompt, più strumenti (grep, semantic search, file) per tirare dentro solo il segnale utile.
Perché lo uso sul mio stack (non in astratto)
Uso Cursor sul lavoro quotidiano su piattaforme legate a LogisticaIT / Sweet e alle automazioni che ci girano intorno: Laravel, Vue, integrazioni WordPress, job di generazione contenuti, sync social, scope multi-tenant. Tre motivi pratici:
- Navigazione più veloce del “dove”. Domande tipo “dove filtriamo per `tenant_id` prima di pubblicare?” o “chi chiama OpenAI con guard sui crediti?” trovano più spesso il percorso giusto se la ricerca non è solo lessicale.
- Meno iterazioni a vuoto. Un agent che apre i file sbagliati spreca tempo e introduce regressioni. La ricerca ibrida (semantica + grep) riduce quel giro a vuoto — Cursor stessa conclude che la combinazione batte l’uso esclusivo di grep.
- Allineamento al modo in cui lavoro già. Non sostituisco test, review e ownership dei dati. Uso l’agent per accelerare esplorazione, bozze di patch e refactor mirati; la responsabilità del merge resta umana, soprattutto su integrazioni e multi-tenant.
Non è magia: se i nomi sono ambigui, se manca un test, se il requisito è confuso, l’agent amplifica anche l’errore. La semantic search migliora il recupero, non la verità di business.
Cosa non chiedo (ancora) a un agent
Nel dominio logistica/software operativo resto cauto su:
- modifiche a integrazioni live (Shopify, corrieri, WordPress) senza ambiente di prova;
- decisioni di privacy e minimizzazione dati;
- “ottimizzazioni” di magazzino inventate da un report AI senza validazione sul campo;
- commit massivi non revisionati su regole di tenant isolation.
Qui la lezione della ricerca Cursor e del context engineering coincide con il buon senso operativo: meglio un contesto piccolo e corretto che un dump enorme e rumoroso.
Build in public: perché lo scrivo qui
Scrivo su LogisticaIT perché il pubblico non è solo “developer che amano gli IDE”. Sono persone che scelgono stack, integrano WMS/ecommerce e valutano se l’AI nel ciclo di sviluppo è marketing o leva. La mia risposta, oggi, è pragmatica: uso Cursor; mi interessa soprattutto la qualità del recupero di contesto; misuro il valore in meno tempo perso a cercare e in patch più aderenti al codice esistente, non in slogan di produttività.
Se ti occupi di software per operations, la domanda utile non è “quale modello è il più forte?”, ma: il tuo agent riesce a trovare, nel tuo repository, il pezzo che conta prima di modificarlo?
Fonti
- Stefan Heule, Emily Jia, Naman Jain — Improving agent with semantic search, Cursor, 6 nov 2025
- Cursor — Securely indexing large codebases
- Cursor — Dynamic context discovery
- Anthropic — Effective context engineering for AI agents, 29 set 2025
- Cursor — Composer: Building a fast frontier model with RL
Note per la pubblicazione
- Linkare almeno la fonte principale Cursor e Anthropic nel corpo.
- Tono build in public: non trasformare in landing commerciale di Cursor.
- Categorie: Logistics + Informatica.
