Come gestisco da solo un business di moduli PrestaShop con una flotta di agenti AI

Qualche mese fa ho scoperto che i miei agenti AI avevano lasciato 154 repository Git dirty - e la soluzione non era un prompt migliore, ma un organigramma.

Non 154 file. 154 repository. Decine di codebase di moduli, ciascuna con modifiche non committate impilate una sull'altra - alcuni esperimenti a metà, alcuni lavori davvero buoni che semplicemente non erano mai stati rilasciati. Agenti diversi, in momenti diversi, avevano fatto ognuno un pezzo e poi erano passati oltre. Nessuno aveva committato. Nessuno aveva pulito. Il lavoro non era esattamente perso. Era peggio che perso. Era ingarbugliato, e non riuscivo più a capire quali mani avessero toccato cosa.

L'istinto, quando un agente AI fa qualcosa di stupido, è correggere il prompt. Aggiungere una riga. "Committa sempre il tuo lavoro quando hai finito." "Non lasciare mai repository dirty." Ci ho provato. Non regge - e quando capisci perché, cambia tutto il modo in cui lavori con questi strumenti.

Questo è il racconto di come gestisco davvero lo shop: una persona, un catalogo di ben oltre cento estensioni PrestaShop pubblicate in sei lingue, più una manciata di veri negozi online che gestisco personalmente con quegli stessi moduli. Molto del lavoro ripetitivo di sviluppo e supporto passa attraverso una flotta di agenti AI - sempre sotto la mia revisione; architettura, decisioni di release e approvazione finale restano a me. Quello che segue è la parte che nessuno mette nella pagina di vendita - gli errori specifici che quegli agenti hanno fatto, e il meccanismo che ho costruito perché non possano farli due volte.

L'agente è un dipendente brillante con amnesia totale

Il modello mentale che funziona davvero è questo. Il tuo agente AI è un contractor davvero eccellente - veloce, preparato, instancabile - che ha zero memoria di aver mai lavorato per te prima. A ogni sessione entra dalla porta uno sconosciuto brillante. Non ha mai visto la tua codebase. Non conosce le tue convenzioni. Non sa che la cosa che sta per fare ha rotto la produzione il mese scorso, perché lui non c'era. Per quanto riguarda la sua memoria, non c'era nessuno.

Non puoi sistemare quella persona con un set di istruzioni più furbo all'ingresso. Un prompt è una conversazione. Evapora quando la sessione finisce. Ti serve ciò che ogni vera organizzazione costruisce per non dipendere dalla memoria di una sola persona: conoscenza istituzionale durevole, scritta e applicata. Documenti di onboarding. Runbook. Una checklist pre-commit appesa al muro. Guardrail che rendono fisicamente difficile la mossa sbagliata.

Non scrivo prompt migliori. Scrivo memoria migliore. L'amnesia è costosa solo se costringi l'agente a reimparare tutto ogni volta che entra.

Quindi il mestiere non è prompt engineering. Il mestiere è costruire l'organizzazione attorno all'amnesico. E la singola realizzazione più utile che ho avuto è questa: ogni guardrail nel mio setup è una cicatrice. Corrisponde a un momento specifico, datato, in cui un agente ha fatto qualcosa di sbagliato, io ne ho sentito il dolore, e ho trasformato quel dolore in una regola che l'ambiente applica per sempre. La mia configurazione non è una lista dei desideri. È una cartella clinica.

Ecco le cicatrici.

Cicatrice #1: l'agente che ha cancellato la cartella vendor e buttato giù lo shop

Alcuni dei miei moduli dipendono da librerie interne condivise - codice che riuso in tutto il catalogo. Per ragioni di deploy, quelle librerie vivono nella cartella vendor/ di ogni modulo, ma vengono copiate lì da uno script di sync, non gestite dal normale package manager. È una configurazione insolita, e un agente amnesico non ha modo di saperlo.

Così una sera dello scorso autunno un agente doveva aggiungere una dipendenza, e ha fatto la cosa corretta da manuale: ha eseguito composer install. Il package manager ha guardato il manifest, ha visto una pila di file in vendor/ che non aveva messo lui, e li ha utilmente cancellati. Le classi sono sparite. Il live store ha iniziato a restituire 500 nel momento in cui un cliente apriva una pagina che autoloadava uno dei trait mancanti.

L'agente non aveva torto secondo la sua logica. Aveva torto perché non aveva la mia memoria. Non puoi uscirne in modo affidabile con un prompt - "stai attento con composer" è esattamente il tipo di istruzione morbida che un agente dimentica sotto pressione. Quindi la soluzione non è una frase. È un muro:

# pre-tool hook: refuse the dangerous command outright
if command matches "composer install" or "composer update":
    BLOCK
    tell the agent: "This wipes synced packages. Use
    'composer dump-autoload', then re-run the sync script."

Ora l'errore è indisponibile. Un agente fresco, senza memoria del blackout, non può comunque riprodurlo, perché l'ambiente dice no prima che il danno avvenga. Questa è la differenza tra un prompt e una cicatrice: il prompt spera; la cicatrice impone. Ora ho una piccola libreria di questi hook, e ognuno di loro è un pomeriggio che non riavrò.

Cicatrice #2: i 154 repository dirty

Torniamo all'inizio. Il groviglio è successo perché avevo risolto un altro problema - far girare molti agenti in parallelo - senza costruire il livello di coordinamento che il parallelismo richiede davvero.

Far girare un agente è una conversazione. Far girare una flotta è logistica, e la logistica è un insieme di problemi che nessun prompt risolve:

• Vanno in throttle e si bloccano. Lancia cinque job pesanti insieme e si accumulano, si fermano e vanno in timeout. La soluzione è stata infrastruttura: un runner che mette in coda e bilancia i job tra worker paralleli e mette un watchdog su ogni run, così l'uso concorrente pesante non si accumula e non congela tutto. Gli agenti non gestiscono la propria capacità. Lo fa l'organizzazione.
• Collidono. Due agenti che modificano lo stesso modulo nello stesso momento corrompono il lavoro l'uno dell'altro. La soluzione è un file lock per modulo - un agente prende il modulo, lavora, lo rilascia. Con una variante imparata nel modo duro: un lock il cui processo proprietario è morto non è lavoro attivo, è spazzatura. Quindi il lock controlla se il suo proprietario esiste ancora e ripulisce automaticamente i lock stantii. Un sistema di coordinamento che va in deadlock sui fantasmi è peggio di nessun sistema.
• Committano il bucato degli altri. Questa era la vera radice dei 154. Un agente che finiva il proprio task eseguiva l'equivalente di "commit everything" - e spazzava dentro lo stesso commit il lavoro incompleto di tre altri agenti. Così il percorso di commit ha ricevuto un gate: un agente può mettere in stage solo i propri file, mai un "add everything" generico. Letteralmente non può committare lavoro che non ha fatto.

Nessuna di queste tre cose è furba. Sono il meccanismo noioso di un posto di lavoro che funziona: timbrare, non toccare la scrivania di qualcuno nel mezzo di un progetto, non firmare per un pacco che non è tuo. Ho dovuto costruirle una per una perché un agente specifico, in un giorno specifico, ha fatto il contrario.

Il coordinamento deve abilitare il completamento, non congelarlo. I lock esistono per impedire a due agenti di modificare un file insieme - non per trasformare "lavoro finito" in "lavoro congelato". Committare è un checkpoint, non una gabbia.

Quell'ultima riga conta più di quanto sembri. La prima versione del mio locking era troppo rigida, e gli agenti hanno iniziato a starsene fermi ad aspettare lock che non appartenevano più a nessuno. Un sistema di sicurezza che impedisce al lavoro di finire non è sicurezza - è solo un fallimento diverso. La regola ora è che il coordinamento deve rendere finire più facile che non finire, altrimenti va riprogettato.

Cicatrice #3: non lasciare mai che un agente impari sul negozio del cliente

Questa è l'unica regola che non ho aspettato di meritarmi nel modo duro. All'inizio, un agente ha "solo controllato una cosa" su uno shop live - e i dieci secondi prima che confermassi che in realtà non era cambiato nulla sono bastati a rendere il principio non negoziabile: gli agenti costruiscono e testano prima su una copia usa e getta, e toccano qualsiasi cosa rivolta al cliente solo dopo che una modifica è stata provata.

Un agente fresco non ha istinto per capire in quale ambiente si trovi. Per lui, una shell è una shell. Quindi l'ambiente fa la distinzione al suo posto: le operazioni rischiose vengono instradate per default verso cloni usa e getta, la produzione è trattata come un luogo separato e protetto, e i comandi distruttivi per abitudine che si lanciano su una dev box (svuotare una directory di cache, resettare lo stato) sono bloccati o reinstradati su tutto ciò che vede un cliente reale. L'agente non deve ricordare la differenza tra "il mio sandbox" e "lo shop di qualcuno". L'organizzazione la ricorda per lui.

Questo è il singolo guardrail che vorrei far conoscere a un cliente, perché è quello che protegge lui. Il motivo per cui un aggiornamento di modulo raramente arriva con una sorpresa è che le modifiche rivolte ai clienti passano prima da una prova generale completa - su uno shop usa e getta, dove un errore non costa nulla - prima della release.

Cicatrice #4: fallo fallire ad alta voce, non con educazione

Lasciato solo, un agente utile coprirà un problema. Qualcosa che si aspettava non c'era, quindi sostituisce silenziosamente un default, avvolge la chiamata in un fallback "per sicurezza" e va avanti. Il task sembra riuscito. Sul negozio di un cliente, un workaround silenzioso è peggio di un errore visibile - perché l'errore visibile viene corretto oggi, mentre quello silenzioso viene rilasciato e aspetta.

Quindi l'istruzione permanente è l'opposto del riflesso: quando qualcosa non va, crash loudly. Non inventare un fallback per nascondere un pezzo mancante. Non aggiungere imbottitura difensiva che trasforma un bug in una risposta sottilmente sbagliata. Esponilo, fermati e lascia decidere a un umano. Insieme alla regola dev-first, questo significa che i fallimenti brutti accadono nella sala prove, dove brutto è esattamente ciò che vuoi, e lo scopo è che i clienti vedano la take riuscita, non quelle fallite.

La parte che rende tutto economico: memoria, fatta apposta

Le cicatrici impediscono agli agenti di rompere le cose. Ma l'abitudine che rende economica tutta l'operazione è quella che trasforma l'amnesia da tassa in errore di arrotondamento.

Il modo ingenuo di usare un agente su un task ricorrente è rispiegarglielo ogni volta. Ri-allegare i file di esempio. Ri-descrivere i passaggi. Ri-derivare quali path contano e quali trappole mordono. Paghi prezzo pieno, in token e in tempo reale, per conoscenza che avevi già scoperto la settimana scorsa. È l'amnesico che reimpara ogni mattina le uscite antincendio dell'edificio.

Così ho creato una regola per gli agenti stessi: alla fine di un task, scrivi la nota. Non una pagina di diario - un memo operativo. Dove vivono i file rilevanti. La sequenza esatta che ha funzionato. La singola cosa non ovvia che farà inciampare il prossimo run. Queste note vivono in un albero organizzato, e - questa è la parte che molti si perdono - c'è un indice di una riga per ogni nota, caricato proprio all'inizio di ogni sessione. L'amnesico entra, legge il sommario e sa all'istante cosa l'azienda già sa e dove cercarlo.

# a representative note — boring on purpose, and that's the point
task: regenerate the catalog cover images
where: assets/covers/  (source templates in build/covers/)
steps: 1) run the build script  2) QA with the check script
gotcha: never touch a confirmed-good render; only regen the broken one
last run: 2026-05 — clean; the QA script caught one bad render

Questa è l'intera tesi in un'abitudine. Un prompt furbo rende migliore questo run. Una nota scritta rende più economico ogni run futuro, qualunque agente lo prenda. La memoria istituzionale capitalizza; i prompt no. La prima volta che faccio qualsiasi cosa qui è costosa. La decima costa quasi nulla, ed è economica proprio perché le prime nove hanno scritto ciò che avevano imparato.

Che aspetto ha davvero un task che passa da questo sistema

Messo insieme, un job di routine gira come un piccolo team ben addestrato, non come una sessione di chatbot:

1. Un agente legge l'indice, prende la nota per questo tipo di task e parte già a buona parte del percorso invece che da zero.
2. Prende il lock sul modulo che sta per toccare, così nient'altro può collidere con lui.
3. Lavora su una copia usa e getta. Se qualcosa non va, fallisce ad alta voce lì - non su uno shop live.
4. Quando prova a finire, i guardrail reggono: non può eseguire il comando che una volta ha cancellato una cartella vendor, e può committare solo i propri file, non il lavoro a metà seduto nel repo accanto.
5. Riscrive ciò che ha imparato, così la nota è un po' più precisa per il prossimo agente - magari uno completamente diverso.

Nota quanto poco di tutto questo sia "prompting". Il prompt è una riga: fai il task. Tutto ciò che lo rende sicuro, veloce e ripetibile vive nell'ambiente, non nel messaggio. Questo è tutto il trucco.

Il registro buono-vs-cattivo, e perché ogni "buono" significa solo "ha memoria"

Le persone mi chiedono consigli per usare l'AI in modo efficiente, aspettandosi trucchi di prompt. La lista vera è più noiosa e molto più utile, e ogni voce è la stessa idea con vestiti diversi - dare all'amnesico una memoria e un'officina preparata:

• Cattivo: incollare codice in un chatbot gratuito e copiare a mano la risposta indietro. Buono: far girare gli agenti dove vive il lavoro - sulla macchina, con accesso reale ai file e agli strumenti - così non bisogna descrivere nulla che possa semplicemente essere letto.
• Cattivo: un disco disordinato dove ogni task inizia con l'agente che cerca dove stanno le cose. Buono: un albero di materiali organizzato, così "trova la cosa" è una consultazione, non una spedizione.
• Cattivo: l'agente fa grep su tutto il disco e legge venti file per trovare una funzione. Buono: preparare l'officina - ricerca veloce e connector che gli permettono di interrogare direttamente database, browser e container in esecuzione invece di indovinare.
• Cattivo: ricostruire da zero ogni volta lo stesso task a più passaggi. Buono: la nota riutilizzabile e l'indice che la fa emergere.
• Cattivo: un agente tuttofare per tutto. Buono: instradare il lavoro - il modello più bravo nel ragionamento backend attento prende il backend; quello con migliore giudizio su interfaccia e parole prende quelli. Come formare un team in base ai punti di forza.

Uno sconosciuto con amnesia in un edificio ben gestito - scaffali etichettati, un manuale chiaro, strumenti affilati pronti e guardrail sui macchinari pericolosi - è sorprendentemente produttivo. Lo stesso sconosciuto lasciato in una stanza disordinata con un briefing verbale vago è un rischio. Stesso lavoratore. La differenza è interamente l'organizzazione.

Dove l'AI aiuta, e dove la revisione umana vince ancora

Dopo tutto questo, ho un senso abbastanza netto del confine.

L'AI vince sul meccanico, sul parallelo e sul ben delimitato. Propagare una modifica su decine di moduli. Stendere la prima versione di qualunque cosa. Estrarre e trasformare dati strutturati. Eseguire di nuovo da una nota un workflow preparato. Indagare un bug ostico con più pazienza di quanta ne abbia io alle 6pm. Quando il task ha una risposta giusta conoscibile e un percorso per raggiungerla, un agente ben attrezzato è più veloce di me e non si annoia alla terza ripetizione.

La revisione umana vince su giudizio, gusto e conseguenze. Qualsiasi cosa per cui un cliente paga. Qualsiasi cosa con peso legale o finanziario - ed è esattamente per questo che le correzioni di fattura sopra ricevono una firma umana, non un invio automatico. Le decisioni architetturali in cui la risposta "giusta" dipende da dove voglio che sia l'azienda tra un anno, non da ciò che il codice dice oggi. E il gusto dell'ultimo miglio nella scrittura e nel design, dove "tecnicamente corretto" e "davvero buono" sono cose diverse, e solo una delle due tiene un cliente.

La linea non è fissa, neanche. Ogni cicatrice in questo pezzo è un punto in cui una volta ho affidato a un agente qualcosa per cui non era pronto, mi sono fatto mordere, e ho spostato la linea. Questa è la vera abilità - non decidere una volta dove finisce l'AI, ma prestare attenzione a dove fallisce e regolare il confine più velocemente di quanto gli errori possano accumularsi.

Perché tutto questo dovrebbe importarti se compri da me

Ecco la versione onesta, perché l'inquadramento di un pezzo così può scivolare in un punto dove non voglio arrivare. Gli agenti non fanno i miei moduli al posto mio, e non te lo direi mai. Costruiscono impalcature, eseguono gli strumenti che non ho voglia di eseguire a mano, preparano prime bozze e intercettano gli errori degli altri - tutto dentro un insieme di guardrail che mi sono guadagnato un outage alla volta. Giudizio, architettura e approvazione restano miei.

Ciò che questa disciplina compra per te, dall'altra parte di un modulo o di un ticket di supporto, è noioso nel senso migliore. La stessa regola che impedisce a 154 repository di ingarbugliarsi è la regola che impedisce a una release di uscire a metà. Lo stesso muro che ferma un agente dal cancellare una cartella vendor è il motivo per cui un cattivo aggiornamento ha molte meno probabilità di lasciare la mia officina. La stessa abitudine dev-first che protegge i miei shop di test protegge i tuoi. Un processo attento upstream è ciò che downstream si sente come affidabilità silenziosa.

Se c'è una cosa da portare via, è questa: smetti di regolare il prompt e costruisci la memoria. L'agente dimenticherà tutto nel momento in cui la sessione si chiude - quindi metti tutto ciò che vale la pena ricordare in un posto dove non possa dimenticarlo, e rendi gli errori che non vuoi mai più vedere impossibili, non solo scoraggiati. Fallo, e una flotta di amnesici brillanti smette di essere un rischio e inizia ad assomigliare molto a un team.