Factory e Droid: guida completa dall’installazione al code review
Factory offre agenti di programmazione chiamati Droid che lavorano nel terminale, nell'editor e su GitHub. Ecco come usarli dall'installazione al review automatico.
👁 114 letture
Factory offre agenti di programmazione chiamati Droid che lavorano nel terminale, nell’editor e su GitHub: leggono il progetto, propongono modifiche, scrivono codice e revisionano le pull request. Questa guida ti accompagna dall’installazione al code review automatico, seguendo la documentazione ufficiale di Factory.
Prima di iniziare: prepara il progetto
Droid lavora sul tuo repository, quindi vale la pena sistemare alcune cose prima del primo task. Uno stato pulito nel sistema di controllo versione, così ogni modifica dell’agente è visibile separatamente e facilmente reversibile. Test funzionanti e comandi per eseguirli, perché un agente che può verificare il proprio lavoro sbaglia meno spesso. Una breve descrizione del progetto in un file nel repository: come avviarlo, dove sono i moduli principali, quali sono le regole del team.
Se il progetto ha aree che l’agente non dovrebbe toccare, ad esempio la configurazione di produzione, scrivilo esplicitamente nelle linee guida.
Passo 1. Installazione
Installi Droid con un singolo comando. Su macOS e Linux è un comando che scarica l’installer dal sito di Factory, su Windows un comando in PowerShell, e se hai Node.js puoi installarlo tramite npm. Per utilizzarlo serve un account Factory, e al primo avvio effettui il login tramite browser.
Poi entri nella directory del progetto e avvii Droid con il comando droid.
Passo 2. Primo task
La guida ufficiale mostra come Droid legge il progetto, propone modifiche e aspetta la tua approvazione prima di cambiare qualsiasi file. All’inizio funzionano meglio i task piccoli: spiega la struttura del progetto, trova dove viene gestito il login, aggiungi la validazione a questo form.
Passo 3. Modalità specifica per modifiche più grandi
Per task più grandi serve la modalità specifica. Droid prima esamina il progetto e pianifica, e solo dopo scrive il codice. La documentazione la consiglia per modifiche architetturali, migrazioni, lavoro sensibile alla sicurezza e ogni task in cui vuoi vedere il piano prima di modificare i file. La attivi con la scorciatoia Shift + Tab nella riga di comando.
Dopo aver proposto il piano puoi approvare ogni modifica manualmente, dare a Droid maggiore autonomia o continuare a perfezionare il piano.
Passo 4. Livello di autonomia
Indipendentemente dalla modalità, imposti quanto autonomamente Droid può agire. La scorciatoia Ctrl + L alterna i livelli da disabilitato ad alto. All’inizio resta sul basso, finché non sai come Droid se la cava con il tuo progetto.
Passo 5. Editor
Droid funziona nel terminale di qualsiasi editor, e in VS Code ed editor della stessa famiglia può installare un’estensione che gli passa il file aperto, la selezione e gli errori dall’editor, e mostra le modifiche nella vista di confronto nativa. Verifichi lo stato dell’integrazione con il comando /ide. Per JetBrains e Zed la documentazione descrive connessioni separate.
Passo 6. Code review prima dell’invio
Il comando /review verifica le modifiche locali prima di inviarle. È una buona abitudine prima di ogni pull request: Droid cerca errori evidenti prima che li veda qualcuno del team.
Passo 7. Review automatico su GitHub
Il comando /install-code-review configura il review automatico delle pull request su GitHub o GitLab. Droid analizza le modifiche e aggiunge commenti su righe specifiche. Si concentra sugli errori, e ignora stile e piccole ottimizzazioni. Aggiungi le tue regole di review per il repository nel file delle linee guida nella directory di configurazione di Factory.
Esempio: primo giorno nel team
Installi Droid, chiedi di spiegare la struttura del progetto e di indicare i tre punti che cambiano più spesso. Poi in modalità specifica pianifichi una piccola funzione, approvi il piano e ogni modifica manualmente. Prima di inviare esegui /review, e alla fine della giornata configuri il review automatico per l’intero repository.
Questo primo giorno ha un altro vantaggio: insegna al team come leggere il lavoro dell’agente. Dopo alcuni task si vede in cosa Droid è forte, ad esempio nelle modifiche ripetitive su molti file, e dove ha bisogno di indicazioni più precise, ad esempio nella logica di business. Vale la pena annotare queste osservazioni nelle linee guida del progetto, perché ogni nuova persona nel team partirà dall’esperienza dei predecessori, non da zero.
Errori più comuni
- Alta autonomia all’inizio, prima di conoscere l’agente.
- Task grandi senza modalità specifica.
- Trattare il review automatico come sostituto dell’umano.
Come valutare la prima settimana
Dopo una settimana conta due cose. Quanti task Droid ha completato in modo che hai accettato la modifica senza correzioni, e quanti hanno richiesto il tuo intervento. Con un progetto ben preparato il primo numero cresce rapidamente. Verifica anche i commenti del review automatico: indicavano errori reali o principalmente rumore. Se prevale il rumore, aggiungi linee guida di review per il tuo repository, così l’agente sa a cosa prestare attenzione e cosa ignorare.
Solo quando i risultati sono buoni, aumenta il livello di autonomia dell’agente.
Se lavori da solo e non in team, le stesse regole funzionano su scala ridotta: affida all’agente task che puoi verificare rapidamente, e rivedi ogni modifica prima del merge, anche se nessun altro la vedrà.
More on this from NITIDO
magazine·Ideogram AI: test di Ideogram 4.5, prezzi ed esempiIdeogram 4.5 alla prova: test di 10 modifiche consecutive contro 7 modelli, gestione del testo, prezzi delle API e prompt dettagliati.