TL;DR: se le istruzioni del tuo coding agent vivono solo nelle impostazioni di un’app, il team dipende da quell’app. Metti regole, comandi e limiti in un file versionato nel repository; poi usa le configurazioni specifiche dei vari strumenti come adattatori, non come unica fonte.

Il 14 agosto 2026 Cursor ha annunciato di essere stata acquisita da SpaceX. Per chi sviluppa siti WordPress o automazioni, la notizia non impone di cambiare editor. Ricorda però una cosa più concreta: anche uno strumento centrale nel workflow può cambiare proprietà, modelli e priorità.

Il problema pratico compare quando il comportamento dell’agente dipende da istruzioni salvate soltanto nel pannello locale: standard PHP, cartelle da non toccare, test obbligatori, regole di sicurezza e procedura di deploy. Un nuovo collaboratore o un secondo coding agent non vede quel contesto. Il risultato è codice incoerente oppure, peggio, una modifica rischiosa eseguita con regole diverse.

La soluzione: una fonte versionata nel repository

Crea un file AGENTS.md nella root del progetto e trattalo come documentazione operativa. Cursor lo supporta come formato Markdown per le istruzioni dell’agente e permette anche file annidati nelle sottocartelle. Il vantaggio non è il nome del file in sé: è avere regole leggibili, revisionabili e vicine al codice.

Per un progetto WordPress, il file dovrebbe dire almeno quali standard seguire, quali comandi eseguire e quali azioni richiedono uno stop. Può indicare, per esempio, di usare escaping e sanitizzazione, non modificare plugin vendor, eseguire test e lint prima della consegna e non leggere o committare file con credenziali.

I passaggi essenziali

  1. Raccogli le regole che cambiano davvero l’output. Parti dagli errori già accaduti, non da un manuale teorico. Limiti di sicurezza, struttura del progetto e definition of done hanno priorità.
  2. Scrivi istruzioni verificabili. “Fai codice pulito” è vago. “Esegui composer lint e npm test prima di chiudere” permette un controllo.
  3. Tieni fuori i secret. Documenta dove recuperarli e quali variabili servono, senza copiare token, password o contenuti di .env.
  4. Collega le regole specifiche del tool. Se usi configurazioni proprietarie, falle puntare alla fonte canonica o mantienile ridotte alle sole differenze necessarie.
  5. Prova la portabilità. Affida a un secondo agente un task reversibile, come correggere un test o spiegare una funzione. Verifica diff, comandi eseguiti e rispetto dei divieti.

Questo test completa bene un pilot di coding agent misurato su 30 giorni: oltre al tempo risparmiato, controlla quanto lavoro serve per spostare regole e contesto tra strumenti.

L’errore da evitare

Non riversare nel file tutto il manuale aziendale. Le regole troppo lunghe consumano contesto, si contraddicono e diventano obsolete. Cursor consiglia istruzioni focalizzate, operative e collegate a esempi canonici nel repository. Se una regola è già applicata da un linter, lascia che sia il linter a farla rispettare.

Take finale

La mia regola è semplice: il coding agent può cambiare, la definition of done no. Versiona il comportamento atteso insieme al codice e prova periodicamente il progetto con un secondo strumento. Il lock-in più costoso non è l’abbonamento; è il contesto operativo che nessuno ha scritto.

Fonti