Build in public: cosa sto imparando a scrivere software con un agent AI

20/08/2026
Francesco Massimo Gallo

Questo non è un tutorial “come diventare 10× con l’AI”. È un diario di lavoro. Sto costruendo e mantenendo software legato a logistica, contenuti e automazioni (stack multi-tenant, API, code, integrazioni). Per farlo uso Cursor come ambiente con agent. Dopo settimane di uso quotidiano, alcune lezioni sono più utili di qualsiasi benchmark.

La premessa tecnica l’ho già collegata alla ricerca Cursor sulla semantic search: l’agent lavora meglio se sa recuperare il codice giusto, non solo se “scrive bene”. Qui racconto cosa cambia nel modo di lavorare.

1. Il prompt breve batte il brief romanzo (se il repo è indicizzato)

All’inizio tendevo a spiegare tutto nel messaggio: architettura, eccezioni, storia del bug. Ora parto spesso da una domanda di navigazione (“dove si valida lo scope tenant prima del binding?”) e lascio che semantic search + grep aprano i file. Solo dopo restringo il compito.

È coerente con l’idea di dynamic context discovery e con il context engineering di Anthropic: il contesto buono è quello minimo ad alto segnale, non il dump.

2. L’agent eccelle sul “come è fatto oggi”, meno sul “cosa dovrebbe fare il magazzino”

Su refactor, test mirati, allineamento a pattern esistenti (controller sottili, logica nei servizi, job con un tentativo e timeout lunghi) Cursor mi accelera. Sulle decisioni di dominio — cosa promettere a una PMI, quale KPI è calcolabile da un CSV, se un audit da remoto è onesto — l’agent può solo riflettere ciò che gli do io. Se gli do marketing, produce marketing.

Build in public significa dirlo: l’AI non sostituisce la validazione con clienti e dati reali. Serve a muovere codice e documentazione più in fretta dopo che il problema è circoscritto.

3. Grep resta sacro (e va bene così)

Cursor stessa insiste: semantic search e grep insieme. Nella pratica:

  • semantic quando cerco un concetto (“attribuzione lead”, “guard crediti OpenAI”);
  • grep quando cerco un simbolo, uno slug, una chiave di schedule, un permesso RBAC.

Se forzo solo uno dei due, perdo pezzi. È banale, ma è la differenza tra una patch chirurgica e un “file simile trovato a caso”.

4. I confini che mi sono imposto

Alcune regole, scritte così le posso contraddire in pubblico se le rompo:

  1. Niente modifiche a credenziali, `.env`, token OAuth nei prompt o nei commit suggeriti dall’agent.
  2. Su multi-tenant: ogni query sensibile deve filtrare esplicitamente per `tenant_id`; se l’agent “dimentica”, il review umano è bloccante.
  3. Niente pubblicazione o comandi con effetti esterni (WordPress live, Mailchimp, Meta) senza conferma esplicita.
  4. I test (PHPUnit) e la build frontend restano il cancello, non un optional.

Queste regole non sono anti-AI: sono anti-incidente. Un agent veloce senza cancelli è solo un modo elegante di fare danni più in fretta.

5. Cosa misuro (ancora in modo grezzo)

Non ho un dashboard da paper. Misuro cose banali:

  • quante volte riapro la stessa area del codice a mano perché l’agent ha sbagliato file;
  • quanti follow-up servono per arrivare a una PR accettabile;
  • se la patch rispetta i pattern del repo o introduce uno stile parallelo.

La ricerca Cursor parla di code retention e di follow-up di utenti insoddisfatti quando manca la semantic search. Io non replico il loro A/B test: osservo solo se, sul mio lavoro, diminuiscono i giri a vuoto. Finora sì — soprattutto sui repository più densi.

6. Perché lo racconto su LogisticaIT

Perché chi legge LogisticaIT valuta stack e processi, non solo carrier e scaffali. Il software di magazzino e le piattaforme di marketing automation condividono un tratto: sistema complesso + dati sensibili + integrazioni fragili. In quel contesto “usare l’AI” senza parlare di recupero contesto, review e limiti è incompleto.

Uso Cursor. Lo dichiaro. Non lo vendo come scorciatoia sul mestiere: lo uso come leva sul recupero di contesto e sulla velocità di iterazione, dentro un processo che resta umano su requisiti, sicurezza e go-live.

Se stai valutando lo stesso percorso, parti da tre domande:

  1. Il tuo codebase è abbastanza grande da rendere costosa la ricerca manuale?
  2. Hai test o checklist che fermano una patch sbagliata?
  3. Sai distinguere i task di navigazione/refactor dai task di decisione di dominio?

Sulle prime due Cursor (con semantic search + grep) mi aiuta. Sulla terza, no — e va bene così.

Per approfondire

Note per la pubblicazione

  • Continuazione naturale dell’articolo sulla semantic search; link interno consigliato dopo il go-live del pezzo 1.
  • Tono diario / build in public; evitare CTA commerciali su Cursor.
  • Categorie: Logistics + Informatica.

Leave a comment

Iscriviti alla newsletter

Articoli recenti