Ho costruito una fabbrica di software che funziona davvero. Ecco cosa ho imparato.

Le software factory vanno molto di moda in queste ultime settimane. Allora ne ho costruita una.

Ecco cosa ho imparato, come funziona e come puoi costruirne una in un pomeriggio.

I miei obiettivi

Doveva essere davvero semplice, qualcosa che funzionasse e non richiedesse un sacco di supervisione. Idealmente, doveva funzionare interamente con il mio abbonamento Claude esistente.

Sembra ingenuo, ma essenzialmente, a meno che non si integri facilmente nel mio flusso di lavoro attuale, non sarà qualcosa che rimarrà. Non voglio costruire questo sistema e dover cambiare tutte le mie abitudini solo per usare questo nuovo sistema. So per esperienza che se succede, non funzionerà a lungo termine e cadrà nell'irrilevanza.

Quindi invece di affrontare tutto come un unico grande sforzo, l'ho suddiviso in due fasi distinte:

1. Pre-triage – capire cosa fare
2. Implementazione – fare effettivamente le cose

Al centro c'è Linear, la fonte di verità di quali lavori devono essere fatti.

Ogni software factory deve avere questo repository centralizzato del lavoro da fare, che siano issue di GitHub, Linear o qualcos'altro. Dovrebbe essere quello che già usi, in modo che sia facilmente estendibile per qualsiasi sistema per aggiungere lavoro che agenti o umani possano poi prendere e completare.

Linear con un'issue generata automaticamente tramite il loop System Health Check

La pipeline ha giunture definite intenzionalmente che rendono il processo di costruzione di una software factory effettivamente gestibile:

1. Creare lavoro (loop con MCP)
2. Archiviare lavoro (Linear)
3. Completare lavoro (agente SDLC)

Suddividendolo, non devi costruire contemporaneamente sia la parte di pre-triage che quella di implementazione (e in realtà lo sconsiglio per evitare un'over-engineering). Linear rende l'interfaccia tra cosa "fare" e cosa stiamo effettivamente "facendo" ben definita e facile da estendere.

Passo di Pre-Triage

Nel diagramma sopra, il lavoro procede da sinistra a destra. Il lato sinistro è dove viene creato il lavoro e contiene un numero qualsiasi di sistemi (umani, agenti o API) che aggiungono cose da fare. Tutti gli output creati in questo passo di pre-triage vengono inseriti nel nostro Linear.

Alcuni loop che girano in un ambiente cloud di Claude

In questo passo abbiamo tre loop principali:

1. Loop System Health Check (cioè un bug finder) – questo loop viene eseguito ogni giorno alle 5 del mattino ed è connesso a qualche server MCP: Posthog per il monitoraggio degli errori; Vercel per la diagnostica di sistema; e Linear per creare issue.
2. Loop dei Miglioramenti UX e del Feedback Clienti – questo loop viene eseguito ogni lunedì alle 9 del mattino e scansiona ogni nuovo feedback, ogni chat di supporto clienti da Intercom/Fin e tutte le replay di sessione di Posthog. Le replay di sessione sono una miniera d'oro. Puoi vedere dove avvengono i rage click o dove gli utenti hanno difficoltà e sono confusi.
3. Loop di Analisi del Churn – questo viene eseguito ogni giorno alle 6 del mattino e analizza ogni cliente che ha cliccato su "cancella" nelle ultime 24 ore. Recupera i dati di pagamento e utente da Stripe (inclusi email e posizione), poi guarda la replay di sessione di questo cliente in Posthog per vedere cosa stava facendo prima di cancellare. Recuperiamo il loro utilizzo da Supabase per vedere se era un ICP sbagliato, se non hanno mai vissuto quel momento "wow" o se hanno incontrato bug. Il report viene inviato a Slack e l'agente crea (o commenta) issue se sono correlate a clienti in churn per aumentare la priorità.

Per eseguire effettivamente questi agenti in modo consistente, ho mantenuto le cose semplici e ho usato Claude Code Cloud Routines.

Niente over-engineering con un Hetzner VPS, un Mac mini carico di caffeina, ecc. È di gran lunga il modo più semplice che ho trovato per sfruttare il tuo abbonamento Claude Code esistente e creare agenti sempre attivi che possono essere attivati su un orario o tramite un evento webhook. E a tutti quelli che dicono "ma che dire del vendor lock-in!!" – è letteralmente solo del testo. Sentiti libero di copiare il prompt dove vuoi, io volevo solo la cosa più semplice ed economica da configurare che funzionasse in modo affidabile.

E un altro motivo per usare Claude Code Cloud Routines è che gli ambienti cloud di Anthropic hanno una stretta parità con Claude in esecuzione locale.

Cloud Claude Routines

Ovviamente non hanno le tue variabili d'ambiente (che possono essere aggiunte alla configurazione dell'ambiente cloud, se necessario), ma se imposti una connessione MCP tramite i connettori dell'App Desktop, sia il tuo Claude CLI locale che quello remoto possono usarli, a differenza di Codex. Questa è stata la killer feature per me ed è ciò che rende questi loop di agenti di pre-triage così efficaci. Rende anche facile eseguire un sacco di sessioni in parallelo senza preoccuparti della memoria del tuo laptop.

Se implementi solo questo passo di pre-triage, otterrai comunque un sacco di leverage anche se non costruisci il passo successivo in cui il lavoro viene completato.

Inizia in piccolo con un singolo loop, provalo, perfezionalo, poi aggiungine altri. Scopri quali routine puoi creare oggi che inseriscano lavoro nuovo e di alta qualità nel tuo issue tracker esistente, e poi fai quello che fai già oggi per l'implementazione.

Passo di Implementazione

La versione più basilare del passo due è dare al tuo agente un ID issue e dire di completarlo. Questo è ciò che la maggior parte delle persone fa già oggi quando lavora con gli agenti, tuttavia probabilmente non è ciò che vuoi se stai leggendo questo, perché ora sei tu il collo di bottiglia nel loop, avviando un agente direttamente in una sessione.

Invece, ho costruito un modo per attivare sessioni Claude Code remote direttamente da Linear.

Da un'issue Linear a Claude

Funziona così:

1. Per prima cosa, identifica come vuoi attivare una nuova sessione Claude. Per noi, aggiungiamo un'etichetta 'auto' a un'issue Linear che dà il via a questo nuovo compito.
2. Poi, Linear invia un evento webhook al nostro servizio API webhook interno (una nuova app Hono interna) che analizza l'evento e poi inoltra le informazioni corrette alla Claude Routine.
3. Infine, questo servizio API leggero fa una richiesta POST ad Anthropic che attiva la Claude Routine con un prompt iniziale.

Usare un'etichetta 'auto' come trigger ci permette di controllare l'esecuzione automatica delle nuove sessioni Claude.

Per impostazione predefinita, i passi di pre-triage non includono queste etichette 'auto' e richiedono che un essere umano aggiunga l'etichetta che attiva l'agente per iniziare il lavoro (mantenendo l'uomo nel loop). Ecco perché chiamiamo il passo 1 il passo di pre-triage, perché qualcosa sta ancora capendo su cosa lavorare, sia tramite coinvolgimento umano o tramite un agente che fa looping e guarda le nuove issue aggiunte e avvia nuove sessioni di implementazione.

Tuttavia, poiché anche un agente può facilmente aggiungere un'etichetta, i loop di pre-triage potrebbero creare nuove issue con l'etichetta 'auto' per impostazione predefinita, che avvia una nuova sessione Claude. Usare un'etichetta diventa un modo molto flessibile per iniziare nuovi lavori di implementazione, automaticamente da un agente o da noi umani.

Un servizio di routing leggero per avviare sessioni Claude

Poiché Linear supporta i webhook, l'intero sistema "push quando viene aggiunta un'etichetta" funziona. L'unico svantaggio è che dobbiamo avere un'API pubblica che riceve questi webhook e formatta gli eventi e i dati del payload per attivare Claude Code. Questo nuovo servizio aggiunge anche le intestazioni di autenticazione corrette, motivo per cui Linear non può attivare direttamente la routine.

In alternativa, potresti avere una routine programmata che si avvia ogni tanto e tenta di implementare qualsiasi nuova issue non in corso con l'etichetta auto.

Per il prompt effettivo della routine, consiglio di costruire una skill riutilizzabile che percorre l'intero SDLC, chiamata ad esempio /implement o /do, che rende facile dire semplicemente "/do ISSUE-NNN", che documenta come procedere correttamente attraverso i passi per recuperare il contesto dell'issue, implementare il lavoro, verificare nel browser, creare la PR e monitorare i commenti.

Quindi il prompt della Claude Routine, attivato dall'evento Linear, può avere un prompt molto semplice. Ecco il mio:

Recupera l'issue fornita e usa la skill /do per implementare la modifica richiesta e creare una pull request. Recupera solo l'issue esatta fornita. Se è già completata o in corso, fermati.

Il riferimento all'issue non appare in questo messaggio: arriva come un messaggio di follow-up separato racchiuso in un tag \<routine-fire-payload>\, inviato immediatamente dopo questo, nella stessa sessione. Aspetta quel messaggio prima di decidere se è stata fornita un'issue. Concludi che l'issue non esiste, o che non ne è stata data nessuna, solo dopo averla cercata nel messaggio \<routine-fire-payload>\ e aver confermato che l'issue di riferimento non esiste realmente.

Quando inizi il lavoro, commenta l'issue, impostala su "In Progress" e aggiorna l'issue con tutto ciò che è significativo mentre procedi. Prefissa sempre i commenti delle issue Linear con [Claude].

Quindi a questo punto hai sessioni Claude Remotion parallele attivate tramite API, che implementano issue, aprono PR (e, si spera, verificano il loro lavoro tramite Playwright o Agent Browser).

È essenzialmente una software factory completa, completamente osservabile, che funziona mentre dormi e che opera interamente sul tuo abbonamento Claude Code.