Penso che molte persone che potrebbero voler sviluppare un nuovo progetto software spesso si bloccano all'inizio nel processo di avvio, poiché sembra così scoraggiante partire con un repository vuoto. Quindi ho pensato di passare rapidamente attraverso il mio ultimo flusso di lavoro, che abbassa drasticamente la barriera in termini di sforzo e tempo necessari per iniziare. La parte più importante è avere una buona idea su cosa realizzare che sarebbe effettivamente utile a molte persone se funzionasse correttamente e facesse bene ciò che cerca di fare. Non posso davvero aiutarti con questa parte, ma il consiglio comune di grattare il proprio prurito e risolvere i propri punti dolenti (non di nicchia) è un ottimo modo per iniziare. Mi ritrovo a pensare costantemente a idee per progetti. Comunque, il passo successivo è scrivere l'idea in modo informale, come faresti in una rapida email a un amico stretto. Non cerchi di rendere questo un piano formale, solo il modo più veloce per trasmettere l'idea di base e cosa fa, specificando eventuali parti dello stack tecnologico o librerie che sai di voler utilizzare. Gli screenshot allegati mostrano un esempio di questo per un'idea che ho avuto casualmente un paio di giorni fa. Mi ci sono voluti forse 10 o 15 minuti per scriverlo. Non deve essere lungo e può fare riferimento ad altre fonti per mantenerlo conciso. Questa descrizione iniziale diventa quindi il prompt per GPT-5 Pro. Di solito ci vogliono almeno 15 o 20 minuti per eseguirlo (divertentemente più a lungo di quanto ci voglia per scrivere il prompt). Potresti provare altri modelli, ma saranno molto peggiori. Poi spesso prendo lo stesso prompt e lo do a Grok4 Heavy o Opus4.1 e reinserisco quelle idee in GPT-5 Pro e incoraggio Pro a prendere qualsiasi buona idea che vede nelle altre proposte. Se c'è effettivamente qualcosa di intelligente in quei piani, GPT-5 Pro lo riconoscerà e lo incorporerà. Poi chiederò a Pro di creare un documento di piano dettagliato e granulare in markdown basato sulla sua prima risposta, e lo salverò come file in una nuova cartella di progetto. Poi spesso itero su questo un paio di volte, iniziando una nuova conversazione con Pro nell'app web e dando l'intero file del piano in markdown e dicendogli di migliorare il piano in vari modi per renderlo più affidabile, robusto, performante, intuitivo, user-friendly e altri buoni aggettivi. E incoraggerò Pro a fare ricerche web esaustive sulla documentazione più recente, blog, tutorial, ecc. per trovare librerie migliori o modi per fare le cose. Poi prenderò le sue revisioni proposte e le incollerò in codex e chiederò a codex di integrare le revisioni nel documento di piano in markdown esistente. Dopo 2 o 3 round di questo, le cose si stabilizzano e ottieni un piano davvero buono e ben sviluppato. Questo è la chiave di tutto, perché quando le cose sono ancora nella fase di piano, è molto più facile modificarle e migliorarle perché non hai ancora codice. Misura due volte, taglia una volta, ecc. Ecco un link al documento di piano risultante che è venuto dal prompt iniziale per questa idea: A questo punto, inizio ad aggiungere un file AGENTS dot md; inizio con uno esistente che ho e chiedo a Pro (nella stessa sessione in cui è stato scritto l'ultimo documento di piano) di personalizzarlo per questo nuovo progetto e stack tecnologico mantenendo tutto ciò che è generico. Se ci sono alcune librerie criticamente importanti, a volte creo anche una guida alle migliori pratiche specializzata (diciamo, se stai creando un server MCP, genererò una guida alle migliori pratiche specializzata per la libreria fastmcp, ma dove spiego anche come strutturare il progetto, ecc.) A questo punto, chiedo quindi a codex in una singola sessione di iniziare a costruire la struttura del progetto, creando cartelle e file segnaposto vuoti, creando il file .gitignore, ecc. Ecco dove il mio processo diverge drasticamente dall'approccio tipico. Prima utilizzo il progetto beads di Steve Yegge e dico a codex di trasformare il documento di piano in un insieme di compiti e sotto-compiti utilizzando beads. Poi uso tmux per creare un insieme di sessioni codex, quante più di 8 contemporaneamente (penso che più di questo funzionerebbe bene)...
Ecco il link al mio thread riguardo la chiusura del ciclo di automazione con tmux:
Jeffrey Emanuel
Jeffrey Emanuel8 nov, 10:27
Ho appena scoperto come automatizzare ulteriormente il mio flusso di lavoro degli agenti con un po' di magia tmux. Ora che sto usando il mio progetto di agent mail mcp per far comunicare un gruppo di agenti tra loro riguardo all'implementazione di un piano (e anche coordinandomi usando il progetto beads per la gestione dei compiti), ho ancora bisogno di "nutrire" gli agenti mettendo in coda un sacco di messaggi in codex per tenerli occupati. Questo comporta di andare uno per uno attraverso i vari pannelli tmux (uno per ogni istanza di codex) e incollare alcuni messaggi predefiniti o premere la freccia su alcune volte per riutilizzare messaggi passati, come ad esempio: "Scegli il prossimo bead che puoi effettivamente utilizzare utilmente ora e inizia a codificare immediatamente; comunica ciò che stai facendo agli altri agenti tramite agent mail." Sembra un po' sciocco e inefficiente fare questo, anche se non ci vuole molto tempo per dare a ciascun agente abbastanza istruzioni per tenerli occupati per oltre un'ora. Ma ora ho realizzato che posso mettere automaticamente in coda un sacco di messaggi in ogni pannello tmux rilevante contemporaneamente, semplicemente copiando e incollando questo nella console al di fuori della sessione tmux (questo è testato e funziona in zsh): --- PANES=(${(f)"$(tmux list-panes -a -F '#S:#I.#P' | tail -n +3 | head -n -2)"}) for pane in $PANES; do tmux send-keys -t $pane -l 'scegli il prossimo bead che puoi effettivamente utilizzare utilmente ora e inizia a codificare immediatamente; comunica ciò che stai'"'"' facendo agli altri agenti tramite agent mail.' sleep 0.1 tmux send-keys -t $pane Enter for i in {1..4}; do tmux send-keys -t $pane -l 'continua, fai un lavoro utile! e comunica!' sleep 0.1 tmux send-keys -t $pane Enter done tmux send-keys -t $pane -l 'ottimo, ora voglio che tu legga attentamente tutto il nuovo codice che hai appena scritto e il codice esistente che hai appena modificato con "occhi freschi" cercando attentamente eventuali bug, errori, problemi, confusioni, ecc.' sleep 0.1 tmux send-keys -t $pane Enter tmux send-keys -t $pane -l 'Assicurati di controllare la tua agent mail e di rispondere prontamente se necessario a eventuali messaggi; successivamente procedi meticolosamente con il piano, svolgendo tutti i tuoi compiti rimanenti in modo sistematico e continuando a annotare i tuoi progressi nel documento del piano, tramite beads e tramite messaggi di agent mail. Non'"'"' rimanere bloccato in "purgatorio della comunicazione" dove nulla viene fatto; sii proattivo nell'iniziare i compiti che devono essere svolti, ma informa i tuoi colleghi agenti tramite messaggi quando lo fai e annota ciò nel documento del piano. Quando non sei davvero sicuro di cosa fare, scegli il prossimo bead su cui puoi lavorare utilmente e inizia.' sleep 0.1 tmux send-keys -t $pane Enter tmux send-keys -t $pane -l 'ok puoi ora concentrare la tua attenzione sulla revisione del codice scritto dai tuoi colleghi agenti e controllare eventuali problemi, bug, errori, problemi, inefficienze, problemi di sicurezza, problemi di affidabilità, ecc. e diagnosticare attentamente le loro cause profonde utilizzando un'analisi di primo principio e successivamente correggerli o rivederli se necessario? Non limitarti agli ultimi commit, allarga la rete e vai in profondità!' sleep 0.1 tmux send-keys -t $pane Enter done --- Questo script: Ottiene i pannelli: Trova tutti i pannelli tmux, escludendo i primi 2 e gli ultimi 2 Invia 8 messaggi a ciascun pannello selezionato: "scegli il prossimo bead..." - dice agli agenti di iniziare a lavorare sul prossimo compito "continua..." × 4 - incoraggiamento ripetuto a continuare a lavorare "leggi attentamente..." - istruzioni per una revisione del codice fresca "controlla l'agent mail..." - lungo messaggio riguardo al coordinamento, evitando la paralisi comunicativa, rimanendo produttivi "rivedi il codice scritto dai colleghi agenti..." - revisione del codice tra pari per bug/problemi Ogni messaggio viene inviato letteralmente (-l flag) con un ritardo di 0.1 secondi prima di Enter per garantire che il CLI di Codex li elabori correttamente.
11,2K