Ho incluso qui la versione in miniatura di questo prompt perché la serie "I miei prompt preferiti" dovrebbe essere compatta, di facile lettura e autonoma. Ma oggi ho trasformato questo in un sistema davvero pazzesco. Non è rilevante se stai creando un altro programma CRUD in React o una lista TODO, ma se stai facendo qualcosa di piuttosto complicato in Rust o Golang, o qualcosa che coinvolge dati complessi, questo approccio è quasi spaventoso per quello che può fare. È un processo in 2 fasi. Ecco la Fase 1: --- Leggi attentamente TUTTI i file AGENTS dot md e README dot md e comprendi TUTTO di entrambi! Poi usa la modalità agente di investigazione del codice per comprendere appieno il codice, l'architettura tecnica e lo scopo del progetto. Poi, una volta che hai fatto un lavoro estremamente approfondito e meticoloso in tutto ciò e hai compreso a fondo l'intero sistema esistente e cosa fa, il suo scopo e come è implementato e come tutti i pezzi si collegano tra loro, ho bisogno che tu indaghi e studi in modo iper-intensivo e rifletta su queste domande in relazione a questo progetto: Ci sono altre gravi inefficienze nel sistema centrale? Luoghi nel codice dove 1) le modifiche sposterebbero effettivamente l'ago in termini di latenza/risposta e throughput complessivi; 2) in modo tale che le nostre modifiche sarebbero provabilmente isomorfe in termini di funzionalità così da sapere per certo che non cambierebbero gli output risultanti dati gli stessi input; 3) dove hai una visione chiara di un approccio ovviamente migliore in termini di algoritmi o strutture dati (nota che per questo puoi includere nelle tue contemplazioni strutture dati meno conosciute e algoritmi più esoterici/sophisticated/matematici, così come modi per riformulare il/i problema/i in modo che un altro paradigma venga esposto, come l'elenco mostrato di seguito (Nota: Prima di proporre qualsiasi ottimizzazione, stabilisci metriche di base (latency p50/p95/p99, throughput, memoria di picco) e cattura profili CPU/allocation/I/O per identificare i veri hotspot): - Eliminazione del pattern di query/fetch N+1 - zero-copy / riutilizzo dei buffer / I/O scatter-gather - costi del formato di serializzazione (overhead di parsing/encoding) - code a dimensione limitata + backpressure (prevenire l'esplosione della memoria e la latenza di coda) - sharding / lock a strisce per ridurre la contesa - memoizzazione con strategie di invalidazione della cache - tecniche di programmazione dinamica - teoria dell'ottimizzazione convessa - valutazione pigra / computazione differita - pattern di iteratore/generatore per evitare di materializzare grandi collezioni - elaborazione in streaming/chunked per lavoro limitato dalla memoria - pre-computazione e tabelle di lookup - lookup basato su indice vs scansione lineare - ricerca binaria (su dati e su spazio di risposta) - tecniche a due puntatori e finestra scorrevole - somme prefisse / aggregati cumulativi - ordinamento topologico e consapevolezza del DAG per grafi di dipendenza - rilevamento di cicli - union-find per connettività dinamica - traversata di grafi (BFS/DFS) con terminazione anticipata - Dijkstra's / A* per percorsi più brevi pesati - code di priorità / heap - tries per operazioni prefisse - filtri bloom per appartenenza probabilistica - alberi di intervallo/segmento per query di intervallo - indicizzazione spaziale (k-d trees, quadtrees, R-trees) - strutture dati persistenti/immutabili - semantica copy-on-write - pooling di oggetti/connessioni - selezione della politica di espulsione della cache (LRU/LFU/ARC) - selezione dell'algoritmo consapevole del batch - batching e coalescenza I/O asincroni - strutture senza lock per scenari ad alta contesa - furto di lavoro per parallelismo ricorsivo - ottimizzazione del layout di memoria (SoA vs AoS, località della cache) - short-circuiting e terminazione anticipata - interning delle stringhe per valori ripetuti - ragionamento di analisi ammortizzata tenendo in considerazione queste linee guida generali dove applicabile: VERIFICHE DI APPLICABILITÀ DP: - Sottoproblemi sovrapposti? → memoizza con chiave di stato stabile - Partizionamento/batching ottimale? → somme prefisse + DP di intervallo - Grafo di dipendenza con traversata ripetuta? → DP topologico a passaggio singolo VERIFICHE DI OTTIMIZZAZIONE CONVESSA: - Forzare l'allocazione/pianificazione esatta? → LP / flusso a costo minimo con rottura deterministica dei pareggi - Fitting di parametri continui con perdita esplicita? → minimi quadrati regolarizzati / QP - Grande obiettivo convesso decomponibile? → ADMM / metodi prossimali Nota anche che se ci sono librerie di terze parti ben scritte di cui sei a conoscenza che funzionerebbero bene, possiamo includerle nel progetto). REQUIREMENTS METODOLOGICI: A) Baseline prima: Esegui il test suite e un carico di lavoro rappresentativo; registra latenza p50/p95/p99, throughput e memoria di picco con comandi esatti. B) Profilare prima di proporre: Cattura profili CPU + allocazione + I/O; identifica i primi 3–5 hotspot per % tempo prima di suggerire modifiche. C) Oracolo di equivalenza: Definisci output + invarianti d'oro espliciti. Per spazi di input grandi, aggiungi test basati su proprietà o metamorfici. D) Prova di isomorfismo per ogni modifica: Ogni differenza proposta deve includere uno schizzo di prova breve che spiega perché gli output non possono cambiare (incluso ordinamento, rottura dei pareggi, comportamento in virgola mobile e semi RNG). E) Matrice delle opportunità: Classifica i candidati per (Impatto × Fiducia) / Sforzo prima di implementare; concentrati solo su elementi che probabilmente sposteranno in modo significativo p95+ o throughput. F) Diffs minimi: Un leva di prestazione per modifica. Nessun refactoring non correlato. Includi indicazioni di rollback se esiste un rischio. G) Guardrail di regressione: Aggiungi soglie di benchmark o ganci di monitoraggio per prevenire future regressioni. Usa ultrathink. --- Puoi eseguirlo una volta in Claude Code con Opus 4.5 e una volta in Codex con GPT 5.2 Codex (ho iniziato a usare solo High perché Extra High è semplicemente troppo lento per me a meno che non stia per andare a letto). Dopo che hanno finito, colpiscili ciascuno con circa 5 rapidi giri di questo: "Ottimo. Rivedi tutto di nuovo per eventuali ovvie omissioni o errori o sbagli, errori concettuali, gaffe, ecc. Usa ultrathink" Poi fai loro salvare gli output in questo modo: "OK, salva tutto questo come PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "OK, salva tutto questo come PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" Poi in Claude Code, fai: "Confronta ciò che hai fatto con PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md e prendi i migliori elementi da quello e intrecciali nel tuo piano per ottenere un piano ibrido migliore di entrambi i mondi modificando il tuo file di piano originale in loco." Poi questo: Rileggi AGENTS dot md così è ancora fresco nella tua mente. Ora leggi TUTTO di PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Poi controlla ogni bead super attentamente-- sei sicuro che abbia senso? È ottimale? Potremmo cambiare qualcosa per far funzionare meglio il sistema per gli utenti? Vogliamo un insieme completo e granulare di bead per tutto questo con compiti, sottocompiti e struttura di dipendenza sovrapposta, con commenti dettagliati in modo che l'intero sistema sia totalmente autonomo e auto-documentante (inclusi background rilevanti, ragionamento/giustificazione, considerazioni, ecc.-- qualsiasi cosa che vorremmo che il nostro "futuro io" sapesse sugli obiettivi e le intenzioni e il processo di pensiero e come serve gli obiettivi generali del progetto.). I bead dovrebbero essere così dettagliati che non abbiamo mai bisogno di consultare di nuovo il documento di piano markdown originale. Riflette accuratamente TUTTO il file di piano markdown in modo completo? Se sono necessarie modifiche, allora rivedi i bead o creane di nuovi o chiudi quelli non validi o non applicabili. È molto più facile e veloce operare nello "spazio di piano" prima di iniziare a implementare queste cose! NON SEMPLIFICARE TROPPO LE COSE! NON PERDERE ALCUNA CARATTERISTICA O FUNZIONALITÀ! Inoltre, assicurati che come parte di questi bead, includiamo test unitari completi e script di test e2e con ottimi log dettagliati in modo da poter essere certi che tutto funzioni perfettamente dopo l'implementazione. Ricorda di usare SOLO lo strumento `bd` per creare e modificare i bead e per aggiungere le dipendenze ai bead." Poi alcuni giri di: "Controlla ogni bead super attentamente-- sei sicuro che abbia senso? È ottimale? Potremmo cambiare qualcosa per far funzionare meglio il sistema per gli utenti? Se sì, rivedi i bead. È molto più facile e veloce operare nello "spazio di piano" prima di iniziare a implementare queste cose! NON SEMPLIFICARE TROPPO LE COSE! NON PERDERE ALCUNA CARATTERISTICA O FUNZIONALITÀ! Assicurati anche che come parte dei bead includiamo test unitari completi e script di test e2e con ottimi log dettagliati in modo da poter essere certi che tutto funzioni perfettamente dopo l'implementazione. Usa ultrathink." Poi lascia che lo sciame si scateni per implementare tutto. Poi preparati per la FASE 2.