AI per programmare: Factory AI, prezzi e quando conviene

Factory AI: come funziona questa AI per programmare?

Factory è una piattaforma per lo sviluppo software i cui agenti, chiamati Droids, possono esaminare un repository, proporre un piano, modificare file, eseguire verifiche e preparare una pull request: un insieme di modifiche da revisionare prima di integrarle nella codebase. Si usano da terminale, da un ambiente di sviluppo integrato (IDE) oppure dalle interfacce desktop e web di Factory. Con «sviluppo agent-native» si intende un metodo in cui si assegna un risultato da raggiungere e si verifica il lavoro prodotto, anziché richiedere ogni singola modifica. Il prodotto coordina modelli e strumenti di sviluppo: non è un nuovo linguaggio di programmazione né un modello da addestrare in proprio. La pagina prodotto di Factory ne descrive le funzionalità.

Verifica effettuata il 21 ottobre 2026 sulla documentazione e sui prezzi pubblicati da Factory. Questa valutazione si basa sulla documentazione, con esempi applicativi e calcoli dei costi; non presenta benchmark di programmazione né risultati di una prova diretta.

A chi conviene Factory e chi dovrebbe tenere l’agente che usa già?

Factory è adatto a un responsabile tecnico che cerca un processo di delega uniforme per sviluppatori con editor diversi, oppure vuole poter cambiare fornitore di modelli senza ricostruire ogni workflow. È meno convincente per un fondatore il cui agente attuale gestisce già repository, test e revisioni con poca supervisione.

Le alternative da valutare sono Claude Code di Anthropic, agente per lo sviluppo; Codex di OpenAI, agente per la programmazione; e Cursor, editor e piattaforma di agenti. Il confronto utile riguarda ciò che ciascun acquisto cambia nel modo di lavorare.

Sono valutazioni per orientare l’acquisto, non classifiche basate su benchmark. Claude Code, Codex e Cursor vanno già oltre una singola chat o un terminale. Avere più interfacce, da solo, non basta a dare un vantaggio a Factory.

Factory AI o Claude Code: quando scegliere l’uno o l’altro?

Factory merita attenzione quando si vuole usare Claude come una delle opzioni all’interno di un workflow più ampio. Claude Code è la scelta più semplice se l’organizzazione ha già costruito attorno al prodotto istruzioni, integrazioni e pratiche di revisione efficaci. Eseguire un modello Claude dentro Droid non equivale a usare Claude Code: gli strumenti disponibili, la selezione del contesto e il comportamento durante l’esecuzione dipendono dal prodotto che ospita l’agente.

Un responsabile con sviluppatori backend su JetBrains e frontend su Cursor, per esempio, potrebbe introdurre Factory per gestire una coda condivisa di interventi di manutenzione. È un motivo sensato per aggiungerlo. Chiedere a tutti di cambiare perché un altro modello ha prodotto una demo impressionante non lo è.

Per ora, lascia perdere Factory se il problema principale sono requisiti vaghi, test inaffidabili o una coda di pull request che nessuno revisiona. Sono ostacoli anche per i Droids. Mantieni Claude Code, Codex o Cursor e rendi prima il lavoro più facile da verificare. Il confronto tra Codex e Claude Code approfondisce la scelta tra questi due prodotti; la selezione di agenti AI per programmare allarga il confronto.

La valutazione che segue si basa su quattro criteri: qualità del contesto, controllo sull’esecuzione, continuità tra le interfacce e costo necessario per far accettare una modifica.

Factory AI Droid: mantieni l’editor, definisci bene il lavoro

Factory Droid può lavorare dentro un editor già in uso, quindi consente una piccola sperimentazione senza migrare a un altro editor. In VS Code, Cursor e Windsurf, l’integrazione fornisce il file attivo, il testo selezionato, i file aperti e la diagnostica, cioè i messaggi di errore e gli avvisi dell’editor. Supporta anche la visualizzazione nativa dei diff. Esegui droid nel terminale integrato, poi usa /ide per controllare la connessione. La documentazione di Factory sull’integrazione con gli IDE spiega la configurazione.

Immagina un responsabile backend che debba modificare il modo in cui un’applicazione verifica i permessi degli account. Il compito utile non è «fai il refactoring dell’autorizzazione». È individuare tutti i punti di chiamata, preservare il comportamento per gli utenti esistenti, proporre la sequenza della migrazione e identificare i test in grado di rilevare una modifica involontaria dei privilegi.

Una descrizione del genere delimita il lavoro dell’agente e offre a chi revisiona criteri concreti per respingerlo. Un diff esteso, da solo, non dimostra che la migrazione sia corretta.

Come usa Factory AI una specifica?

La Spec Mode di Factory separa l’analisi e la pianificazione dall’implementazione. Legge il contesto pertinente e propone un piano, poi chiede l’approvazione; nella CLI, Shift+Tab permette di passare dalla modalità Normal alla modalità Spec e viceversa. Il livello di autonomia è un’impostazione distinta: stabilisce quali azioni possono procedere senza un’ulteriore conferma. La documentazione della modalità esplicita questa differenza.

Per la migrazione dei permessi, parti dalla Spec Mode e richiedi che il piano indichi i file coinvolti, le ipotesi sulla compatibilità e i passaggi di verifica. Respingi un piano che proponga di cambiare le regole di accesso senza spiegare come verrà preservato il comportamento esistente. Approva l’implementazione solo quando queste decisioni sono chiare.

Una sequenza pratica è questa:

1. Chiedi a Droid di individuare i punti di ingresso dell’autorizzazione e i test pertinenti.
2. Richiedi un piano che preservi il comportamento attuale e segnali i requisiti ancora incerti.
3. Esamina il piano, poi scegli un livello di autonomia adeguato al lavoro consentito.
4. Controlla il diff e i risultati dei test prima di aprire o accettare la pull request.

Il vantaggio è avere un momento di revisione prima che l’agente produca molto codice. Il limite è che anche un piano plausibile può essere sbagliato. I criteri di accettazione devono riguardare il comportamento, non soltanto la presenza di test.

C’è anche un limite specifico dell’editor: Factory documenta che l’integrazione con JetBrains non condivide automaticamente file aperti, selezioni, diagnostica o diff nativi di Droid. Un’adozione che coinvolge editor diversi deve tenerne conto, senza presumere che l’esperienza di VS Code sia disponibile ovunque.

Cambiare modello senza ricostruire il workflow

Factory consente di scegliere tra diverse famiglie di modelli mantenendo l’interfaccia Droid e la struttura delle attività. È utile per un team che vuole un metodo uniforme per delegare il lavoro, senza legare ogni workflow a un solo fornitore di modelli.

Il catalogo dei modelli di Factory attualmente include, tra gli altri:

• Anthropic Claude Opus 5.5 e Claude Sonnet 5.5.
• OpenAI GPT-6.1 Sol e GPT-6 Astra.
• Google Gemini 3.1 Pro e xAI Grok 4.7.
• Modelli aperti, tra cui Mistral Large 4, Kimi K3 e DeepSeek V4.1 Flash.

È un elenco esemplificativo dei modelli supportati, non una classifica di qualità né la garanzia che le policy di ogni account ne consentano l’uso.

Prendi una coda di aggiornamenti delle dipendenze. Assegna a ogni modello candidato la stessa modifica, le stesse istruzioni per i test e gli stessi criteri di completamento. Registra se porta a termine l’aggiornamento, se le verifiche passano e quanto intervento richiede a chi revisiona. Un modello che necessita di meno supervisione può giustificare consumi maggiori; uno meno costoso che lascia ripetutamente test non funzionanti potrebbe non convenire.

Per un confronto utile, attività e ambiente devono restare costanti. Cambiare insieme modello, istruzioni del repository e livello di autonomia rende il risultato impossibile da interpretare. Il catalogo di Factory prevede moltiplicatori di consumo e impostazioni di ragionamento diversi: «lo stesso numero di prompt» non è quindi una misura affidabile per confrontare i consumi.

Bring your own key (BYOK) significa configurare le proprie credenziali del fornitore di modelli o un endpoint compatibile. Factory supporta modelli personalizzati a livello personale, comprese le configurazioni locali. La documentazione BYOK, però, pone un limite importante alla portabilità: questi modelli personali sono disponibili nella CLI e nell’app desktop, ma non nelle interfacce web o mobile ospitate da Factory.

La conseguenza per l’acquisto è precisa. Factory può ridurre il lavoro necessario per cambiare modello all’interno di un workflow, ma occorre comunque verificare che il modello desiderato sia disponibile nell’interfaccia da cui verrà svolta l’attività. Una prova con un modello locale non convalida automaticamente la delega via web.

Desktop e web: verificare il lavoro delegato

L’app desktop di Factory è utile quando il risultato va esaminato visivamente insieme alla conversazione. La pagina prodotto elenca tra i contenuti visualizzabili in anteprima diff del codice, documenti, presentazioni, fogli di calcolo, PDF e siti web in esecuzione; consente inoltre di collegare commenti a righe di codice o elementi selezionati. È disponibile per macOS e Windows. Factory Desktop descrive anche la continuità delle sessioni tra desktop, web, mobile e CLI.

Per un fondatore con competenze tecniche che deve modificare la pagina delle impostazioni di un account, il workflow è semplice: descrivere il comportamento, esaminare il risultato visualizzato, associare il feedback all’elemento pertinente e revisionare le modifiche al codice prima del rilascio. Il feedback visivo aiuta a localizzare una richiesta come «questo errore va accanto al campo email». Non dimostra che il server rifiuti un aggiornamento non valido o che le impostazioni di un altro utente restino inaccessibili.

La distinzione conta quando si delega. Chi approva l’interfaccia e chi verifica il comportamento dell’applicazione possono essere persone diverse. Richiedi sia la modifica visibile sia le prove che il comportamento sottostante funzioni. Un’anteprima convincente non dovrebbe essere l’unico criterio di completamento.

Factory elenca anche connettori per strumenti come GitHub, Linear, Slack e Sentry. Possono fornire contesto autorizzato, ma collegare un sistema di tracciamento non rende preciso un ticket ambiguo. L’attività ha comunque bisogno di un responsabile, di un perimetro definito e di un risultato chiaro.

L’esecuzione remota introduce una seconda distinzione: l’interfaccia in cui si revisiona il lavoro non è il computer che lo esegue. I Droid Computers gestiti da Factory sono ambienti persistenti che conservano file, pacchetti installati, servizi e configurazioni tra una sessione e l’altra. Factory documenta anche un’opzione distinta, Remote Control, per una macchina già gestita dall’utente. La documentazione dei Droid Computers descrive entrambe le possibilità.

La persistenza è utile quando preparare l’ambiente richiede molto lavoro. Significa anche, però, che qualcuno deve essere responsabile del suo stato. Factory specifica che ricostruire un Environment non aggiorna un Droid Computer creato in precedenza dal suo snapshot. Chi gestisce la piattaforma dovrebbe quindi verificare lo stato della macchina prima di considerare un’esecuzione riuscita come riproducibile altrove.

Una software factory con l’AI parte da un’attività ripetibile

Factory diventa più interessante quando Droid gestisce una coda di attività ben definite senza che uno sviluppatore debba avviare manualmente ogni conversazione. Droid Exec è la modalità headless: un comando non interattivo che esegue un’attività e restituisce un risultato utilizzabile da uno script o da un sistema di integrazione continua (CI). Per impostazione predefinita opera in sola lettura; modifiche e comandi più estesi richiedono impostazioni di autonomia esplicite. La documentazione di Exec tratta formati di output, directory di lavoro e worktree Git isolati.

Un buon primo workflow è un’analisi del repository che produca riscontri verificabili da chi lo mantiene. Dopo aver installato Droid ed effettuato l’autenticazione, esegui questo comando da un repository:

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

È un esempio di invocazione, non un’esecuzione svolta per questa recensione. Da solo non dimostra la copertura dei test: chiamate dinamiche, test di integrazione e codice generato possono rendere errata una conclusione troppo semplice. Il risultato è una proposta di elenco di attività da sottoporre al manutentore.

Il passaggio successivo consiste nel far implementare a Droid una modifica ai test già approvata e circoscritta, su un branch o worktree separato, per poi eseguire le verifiche del repository. La verifica di accettazione deve restare indipendente da ciò che l’agente dichiara di aver fatto. A determinare il completamento devono essere il risultato della CI e la decisione di chi revisiona.

C’è un ostacolo all’automazione che può passare inosservato: una policy dei comandi che restituisce ask richiede comunque l’approvazione anche con autonomia High, e un job a esecuzione singola non può ottenere una conferma interattiva. Aumentare l’autonomia, quindi, non sblocca necessariamente un’automazione ferma. Factory documenta droid rules check per vedere in anticipo le decisioni delle policy. È un problema di configurazione da risolvere in modo consapevole, non un motivo per disattivare ogni controllo dei permessi.

Per lavori più estesi, la Mission Mode coordina worker e validazione. Richiede l’autonomia High o la deroga non sicura documentata; inoltre, nei piani individuali le Missions possono fermarsi al raggiungimento dei limiti di utilizzo. Parti da normali attività ben delimitate prima di promettere il completamento senza supervisione di una migrazione importante.

Il vantaggio è la ripetibilità: ogni volta gli stessi criteri di presa in carico, gli stessi limiti di autorizzazione e lo stesso insieme di riscontri. L’ostacolo è la responsabilità operativa. Qualcuno deve occuparsi di dipendenze, credenziali, perimetro delle attività e gestione degli errori. Il confronto tra piattaforme di software factory aiuta nella scelta successiva, se questo livello operativo conta più della singola sessione di programmazione.

Factory AI: prezzi e piani in base al lavoro da svolgere

Factory Teams è la scelta più immediata per un piccolo team che ha bisogno di fatturazione centralizzata. Business è il piano da valutare quando servono consumi condivisi regolati da contratto, gestione delle identità o policy amministrative. Non dare per scontato che il passaggio da un piano individuale a Teams includa questi controlli.

Queste sono le condizioni mensili riportate nella pagina dei prezzi di Factory, verificate il 21 ottobre 2026:

La pagina dei prezzi non pubblica quote di token. L’utilizzo è espresso soltanto come multiplo di Pro. Questi moltiplicatori non garantiscono un numero di attività e non consentono una conversione affidabile in pull request accettate. La documentazione dei piani per organizzazioni chiarisce che ogni postazione Teams ha i limiti di utilizzo di Pro; Business ed Enterprise prevedono invece consumi condivisi regolati dal contratto.

Cinque postazioni Teams costano $260 al mese: $60 + 5 × $40. Dieci costano $460. Se un team di cinque persone accettasse, per ipotesi, 20 pull request di Droid in un mese, la sola quota di abbonamento sarebbe di $13 per pull request accettata. È un calcolo, non una previsione di capacità: prima di confrontare il costo totale vanno aggiunti consumi extra, risorse di calcolo e tempo di revisione.

Spesso il problema è scegliere un piano che non copre le esigenze del workflow. Pro non offre i controlli aziendali elencati per Business. Teams non viene presentato come un piano con l’utilizzo di Plus per ogni postazione. Inoltre, la documentazione dei piani individuali include i Droid Computers gestiti in Pro, mentre la pagina commerciale dei prezzi li aggiunge a partire da Plus. Per il budget, fai riferimento alla pagina dei prezzi e verifica cosa è effettivamente incluso prima di basare il lavoro sulle risorse di calcolo gestite.

I limiti che possono fermare l’adozione

I limiti più rilevanti di Factory riguardano la coerenza tra interfacce e piani. Possono bloccarne l’adozione anche quando una singola sessione di programmazione sembra riuscita.

Supportare un editor non significa offrire le stesse funzionalità. JetBrains non dispone della condivisione automatica di file, selezioni e diagnostica descritta per gli editor della famiglia VS Code. L’Agent Panel di Zed non ripristina le precedenti sessioni di Factory Droid. Un team che adotta Droids come standard ha comunque bisogno di un onboarding specifico per ciascun editor e di un metodo per recuperare il contesto. Factory documenta queste differenze.

Il BYOK personale non è disponibile nelle interfacce web o mobile ospitate da Factory. Un modello configurato in locale può essere centrale nella scelta, per ragioni di costo o di gestione dei dati. Quella configurazione non è disponibile su tutte le interfacce di Factory. Verifica il percorso di esecuzione remota previsto prima di acquistare sulla base di una demo locale. La restrizione è esplicita.

I moltiplicatori di utilizzo non definiscono una capacità garantita. La documentazione dei piani individuali descrive finestre mobili indipendenti di 5 ore, 7 giorni e 30 giorni. Un abbonamento superiore non trasforma queste finestre in una quota di token pubblicata o in una garanzia di completamento. Se una scadenza verso un cliente dipende dall’esecuzione senza supervisione, concorda la capacità contrattuale anziché estrapolarla da una breve sperimentazione. Le regole di utilizzo individuale di Factory precisano anche che le Missions si fermano quando viene raggiunto un limite di utilizzo.

L’accesso alle risorse di calcolo gestite va confermato. La discrepanza tra Pro e Plus è rilevante per un fondatore che prevede di far eseguire il lavoro lontano dal proprio portatile. La tabella dei piani di questa recensione si basa sulla pagina dei prezzi; la documentazione in conflitto non dimostra che sia incluso un upgrade gratuito. Verifica inoltre le condizioni delle risorse di calcolo separatamente dal consumo dei modelli: la dicitura «agenti cloud» non equivale a un’infrastruttura interamente compresa nel prezzo.

Le regole sui permessi non isolano il sistema operativo. Lo precisa la stessa documentazione di Factory sull’autonomia. Il fatto che un comando sia consentito non dimostra che sia innocuo, e un’istruzione in linguaggio naturale che vieta di toccare la produzione non crea una barriera di rete. Per una sperimentazione, scegli accessi e ambiente adeguati all’attività; per applicare vincoli a livello di organizzazione, valuta i controlli dei piani su preventivo.

Questi limiti suggeriscono un’adozione circoscritta. Introduci Factory in un workflow in cui ambiente, modello, permessi e responsabile della revisione siano noti. Estenderlo a tutti i repository prima di aver definito queste scelte crea un lavoro di coordinamento che può annullare i vantaggi della delega.

Recensione di Factory AI: il criterio per decidere

Factory merita spazio quando riduce il lavoro umano necessario per trasformare un compito definito in una modifica accettata. Scelta dei modelli, più interfacce ed esecuzione remota sono utili solo se migliorano questo risultato.

Affiancalo all’agente attuale quando manca una soluzione soddisfacente per una coda condivisa di manutenzione, un workflow tra editor diversi o un confronto ragionato tra modelli. Sostituisci l’agente in uso per quella categoria di attività solo dopo aver verificato, su lavori confrontabili, un minor impegno di revisione o un costo totale inferiore, senza indebolire i controlli di accettazione. Rinuncia se Factory duplica un workflow che Claude Code, Codex o Cursor gestiscono già bene.

Il primo passo concreto, già da lunedì, è una piccola valutazione affidata a un responsabile del risultato:

Factory è un candidato credibile per questa valutazione. La documentazione descrive un sistema di agenti ampio e configurabile. Non dimostra che gli ingegneri produrranno lavoro migliore semplicemente sostituendo con Droid l’agente che conoscono già.

Domande frequenti

Ricevi la AI Business Workflow Audit Checklist attraverso la newsletter per definire attività, permessi, responsabile della revisione e costo operativo prima di estendere l’adozione degli agenti.