Tutto quello che documento su questo sito — la v6 del bot BTC, i filtri della v1.30 di Kimera, la ricerca a doppia fase su 210.240 barre — è stato sviluppato in collaborazione con modelli di intelligenza artificiale. Non "aiutato ogni tanto": sviluppato con, come si sviluppa con un collega senior che scrive velocissimo, conosce ogni API e non si offende quando gli si dice che ha torto.
Ma questo articolo è l'opposto dell'entusiasmo di default. Perché l'AI applicata al trading ha due modalità d'uso, e la differenza tra le due è la differenza tra un moltiplicatore e un acceleratore di rovina.
Modalità oracolo vs modalità collega
Modalità oracolo (sbagliata): "dammi una strategia vincente", "prevedi dove va il prezzo", "scrivimi un EA profittevole". Chi la usa così ottiene codice sintatticamente perfetto costruito su premesse mai verificate — cioè il modo più efficiente mai inventato per industrializzare l'overfitting. L'AI non conosce l'edge: se l'edge non c'è (e spesso non c'è), l'AI vi fabbrica comunque, su richiesta, l'illusione meglio rifinita della storia.
Modalità collega (corretta): l'umano possiede la domanda, l'ipotesi e il criterio di verifica; l'AI moltiplica la velocità di esecuzione di ogni passo — implementazione, analisi, revisione, ricerca. Il collo di bottiglia del lavoro quantitativo non è mai stata l'intelligenza: è sempre stato il tempo per scartare le idee sbagliate. L'AI comprime il costo di ogni iterazione da giorni a minuti.
Il contratto di lavoro in 5 regole
Regola 1 — La specifica la scrivo io, e contiene la logica finanziaria
Il prompt per un modulo non è "scrivi un trailing stop": è una specifica con cosa, vincoli, casi limite e perché finanziariamente. Se non so spiegare cosa deve fare un modulo, il problema non è di programmazione. Un esempio reale, per il guardiano del rischio di un EA:
Implementa in MQL5 un modulo "risk guardian" per il mio EA con queste specifiche esatte: CONTESTO FINANZIARIO: opero su un conto prop con daily loss limit 4% e max drawdown 10%. Il mio limite interno deve scattare PRIMA di quello della firm (3% daily), perché spread notturni, gap e slippage possono violare il limite contrattuale anche a mercato "fermo". REQUISITI: 1. Daily loss limit: se equity <= equity_inizio_giornata × (1 − 3%), chiudi TUTTE le posizioni e blocca ogni nuovo ingresso fino al giorno successivo. 2. Max drawdown: se equity <= picco_storico_equity × (1 − 8%), stessa procedura, ma il blocco è permanente finché non lo rimuovo a mano. 3. Il blocco deve avere un LATCH: una volta scattato resta scattato. Nessuna riaccensione automatica infragiornaliera. 4. Il controllo va fatto su EQUITY, mai su balance: il rischio vivo è nelle posizioni aperte. 5. Il picco di equity deve sopravvivere ai riavvii dell'EA (crash, ricompilazione, riavvio VPS). CASI LIMITE da gestire esplicitamente: cambio di giorno a cavallo di posizioni aperte; riavvio dell'EA con latch attivo; che timezone usa il server per il rollover del "giorno". Prima del codice: spiegami in 5 righe come intendi strutturarlo, così verifico che abbiamo capito la stessa cosa.
Notate la differenza con "scrivimi una protezione dal drawdown": ogni numero ha una motivazione, i casi limite sono elencati, e chiedo la struttura prima del codice. Il margine 3% vs 4% non è pignoleria: la violazione per un'ombra di spread alle 23:00 è un classico documentato.
Regola 2 — L'AI propone, i dati dispongono
Ogni idea — mia o del modello — passa dallo stesso imbuto: fattibilità sui dati, in-sample/out-of-sample, robustezza. Nessuna eccezione per carisma. Le idee dell'AI hanno un vantaggio (sono istantanee e numerose) e un pericolo simmetrico: sono plausibili per costruzione. Il modello è addestrato a produrre cose che suonano giuste — e la plausibilità non è evidenza. Il prompt per la fase di fattibilità:
Ho questa ipotesi di trading: [ipotesi in UNA frase, con la fonte dell'edge: chi paga e perché]. Scrivi uno script Python che la verifichi sui dati allegati (CSV OHLCV, barre chiuse) PRIMA di qualsiasi implementazione: 1. Calcola l'edge lordo medio per trade in basis points, su tutti gli orizzonti da 1 a 48 barre. 2. Sottrai un costo round-trip realistico di [X] bps. 3. Confronta contro il baseline "sempre long su tutte le barre": il pattern deve battere QUELLO, non lo zero. 4. Spacca i risultati: primi 70% dei dati (in-sample) vs ultimi 30% (out-of-sample). Se il segno dell'edge cambia tra IS e OOS, dichiaralo come verdetto negativo. VINCOLO ASSOLUTO: ogni feature deve usare solo informazione disponibile alla chiusura della barra precedente. Elenca a fine script tutti i punti dove un look-ahead sarebbe potuto entrare e come l'hai evitato.
Regola 3 — Verifica antagonista
Dopo ogni pezzo di lavoro consegnato, la sessione successiva comincia con l'incarico opposto. L'AI è un ottimo revisore di sé stessa se glielo si chiede esplicitamente — e un pessimo revisore spontaneo, perché di default ottimizza per accontentarvi:
Sei un revisore ostile. Questo codice/analisi è stato scritto da qualcun altro e il tuo compito è demolirlo: 1. Trova gli errori nel codice, in particolare: look-ahead nascosti, confronti tra float senza tolleranza, stato locale che diverge dallo stato del server/broker. 2. Elenca ogni assunzione non verificata. 3. Dimmi perché il risultato potrebbe essere un artefatto invece che un edge. 4. Trova il numero che tradisce il contratto: c'è qualche costante (baseline, limite, soglia) dedotta dallo stato corrente invece che scritta come costante contrattuale? Non essere diplomatico. Ogni problema che non trovi ora lo troverà il mercato con i miei soldi.
Il punto 4 non è teorico: un bug del genere — il limite di drawdown calcolato su un balance letto a runtime invece che sulla baseline contrattuale del conto prop — è sopravvissuto a tre letture umane sul mio bot BTC. È emerso solo con una revisione antagonista chiesta con quel mandato esplicito.
Regola 4 — Il codice si legge riga per riga prima di toccare denaro
Tutto il codice generato che va in produzione lo leggo e lo capisco. Non per sfiducia romantica: perché la responsabilità non si delega. L'errore dell'AI sul conto è il mio errore. Gli errori tipici del codice generato si concentrano in punti prevedibili — ne ho fatto una checklist per MQL5.
Regola 5 — Log delle decisioni
Di ogni scelta non ovvia (perché 2× i costi nel cost-gate? perché 120 secondi di hold massimo?) resta una riga scritta con la motivazione. Sei mesi dopo, quando un numero sembra arbitrario, la riga c'è. L'AI è eccellente nel mantenere questa documentazione — se la si incarica di farlo:
Da ora in poi, ogni volta che fissiamo un valore numerico non derivato matematicamente (soglie, moltiplicatori, timeout), aggiungi una riga al file DECISIONI.md nel formato: [data] [parametro=valore] [motivazione in una frase] [alternativa scartata e perché]
Dove l'AI eccelle e dove sbaglia, in questo mestiere
Eccelle: implementazione veloce da specifica chiara; traduzione tra linguaggi (il prototipo Python di un filtro → MQL5); analisi esplorativa dei dati ("trova le anomalie in questi 590 trade"); sintesi di letteratura accademica (36 paper letti e schedati in ore, non giorni); refactoring di codice esistente.
Sbaglia sistematicamente: inventa dettagli plausibili quando mancano informazioni (versioni di API, comportamenti del tester) invece di dichiarare l'incertezza; introduce look-ahead silenziosi negli script di backtest se la specifica non lo vieta esplicitamente; tende ad aggiungere complessità invece che toglierla; degrada in sessioni lunghe e disordinate.
Il flusso completo, con i tempi veri
Come nasce un upgrade, con i tempi reali della v1.30 di Kimera come riferimento:
| Fase | Chi | Tempo |
|---|---|---|
| Analisi dei 590 trade, identificazione dei tagli | AI come analista sui dati esportati | mezza giornata |
| Decisione sui filtri da adottare | Umana | 10 minuti |
| Specifica scritta dei filtri e del guardiano | Umana | 30 minuti |
| Implementazione MQL5, casi limite inclusi | AI | 1 ora |
| Revisione antagonista + lettura riga per riga | AI + umana | 1 ora |
| Re-backtest di conferma | Tester | il tempo del tester |
Totale: un giorno lavorativo per un upgrade che ha dimezzato il drawdown di un sistema. Prima dell'AI, lo stesso ciclo costava una-due settimane — quando trovavo la voglia di farlo, che è il punto vero: l'AI non ha reso il metodo possibile; l'ha reso abbastanza economico da essere praticato sempre.
Per la pipeline dati su cui gira tutto questo: Ricerca quantitativa con Python e i feed API di Binance.