OpenClaw + Claude Code Super Tutorial: Un solo sviluppatore può costruire un intero team di sviluppo!

Oggi condivido un caso pratico davvero esplosivo. (Alla fine dell'articolo troverai il tutorial)

Un sviluppatore indipendente ha costruito un sistema di AI Agent utilizzando OpenClaw + Codex/CC. Quali risultati ha ottenuto?

94 commit in un giorno, 7 PR completati in 30 minuti, e in quel giorno ha anche tenuto 3 riunioni con i clienti, senza mai aprire l'editor.

Questo è realmente accaduto nel gennaio 2026. L'autore ha reso pubblica l'architettura del sistema, il flusso di lavoro e la configurazione del codice. Dopo averlo letto, ho pensato che questo approccio fosse davvero degno di essere studiato, quindi l'ho organizzato in questo articolo per condividerlo con te.

Se stai usando Codex o Claude Code, o sei interessato a OpenClaw, questo articolo ti darà molte ispirazioni.

Un solo sviluppatore, 94 commit di codice in un giorno

Iniziamo a dare un'occhiata ad alcuni dati per percepire la potenza di questo sistema:

• Massimo di 94 commit in un giorno (media di 50 commit al giorno)
• 7 PR completati in 30 minuti
• La velocità dal pensiero al lancio è così rapida che può "consegnare le richieste dei clienti nello stesso giorno"

L'autore ha utilizzato questo sistema per sviluppare un vero prodotto B2B SaaS, abbinato alla vendita diretta del fondatore, riuscendo a soddisfare la maggior parte delle richieste funzionali nello stesso giorno. Quanto è veloce? Quando i clienti fanno una richiesta, possono vedere i risultati nello stesso giorno, trasformandosi direttamente in utenti paganti.

E i costi? Solo $190 al mese (Claude $100 + Codex $90), i principianti possono iniziare con soli $20.

Potresti chiederti: è solo una questione di accumulare strumenti AI e generare codice spazzatura?

No. La cronologia Git dell'autore sembra quella di "aver appena assunto un team di sviluppo", ma in realtà è solo lui. Il cambiamento chiave è: è passato da "gestire Claude Code" a "gestire un maggiordomo AI, che a sua volta gestisce un gruppo di Claude Code".

• Prima di gennaio: scrivere codice direttamente con Codex o Claude Code
• Dopo gennaio: utilizzare OpenClaw come livello di orchestrazione, permettendo a questo di gestire Codex/Claude Code/Gemini

L'effetto di questo cambiamento è che il sistema può completare automaticamente quasi tutti i compiti da semplici a mediamente complessi, senza necessità di intervento umano.

Perché Codex e Claude Code da soli non sono sufficienti?

A questo punto, potresti pensare: Codex e Claude Code sono già molto potenti, perché aggiungere un ulteriore livello di orchestrazione?

La risposta dell'autore è molto diretta: Codex e Claude Code non sanno praticamente nulla della tua attività. Vedono solo il codice, non l'intero quadro aziendale.

C'è una limitazione fondamentale: la finestra di contesto è fissa, puoi solo scegliere uno dei due.

Devi decidere cosa inserire:

• Riempire di codice → nessuno spazio per il contesto aziendale
• Riempire di storia dei clienti → nessuno spazio per il codice

Quindi, quando usi Codex o Claude Code da soli, ti troverai ad affrontare questi problemi:

• Non sa per quale cliente è stata creata questa funzionalità
• Non sa perché la richiesta simile precedente è fallita
• Non sa la tua posizione di prodotto e i principi di design
• Può lavorare solo in base al codice attuale e al tuo prompt

OpenClaw ha cambiato questa equazione.

Funziona come livello di orchestrazione, posizionandosi tra te e tutti gli strumenti AI. Il suo ruolo è:

• Detenere tutto il contesto aziendale (dati dei clienti, verbali delle riunioni, decisioni storiche, casi di successo/fallimento)
• Tradurre il contesto aziendale in prompt precisi, da fornire a specifici Agent
• Consentire a questi Agent di concentrarsi su ciò che sanno fare meglio: scrivere codice

Facciamo un paragone:

• Codex/Claude Code = chef professionisti, si occupano solo di cucinare
• OpenClaw = chef principale, conosce i gusti dei clienti, le scorte di ingredienti, la posizione del menu, e fornisce istruzioni precise a ogni chef

Ecco perché è necessario un sistema a doppio livello: attraverso la specializzazione del contesto, piuttosto che sostituire con modelli più potenti.

Architettura specifica del sistema a doppio livello: livello di orchestrazione + livello di esecuzione

Diamo un'occhiata all'architettura specifica di questo sistema.

Due strati, ognuno con il proprio compito:

Cosa può fare OpenClaw (strato di orchestrazione)?

• Leggere tutte le registrazioni delle riunioni nelle note di Obsidian (sincronizzazione automatica)
• Accedere al database di produzione (solo in lettura) per ottenere la configurazione del cliente
• Avere accesso API da amministratore, può ricaricare direttamente il cliente e rimuovere i blocchi
• Scegliere il giusto agente in base al tipo di compito
• Monitorare i progressi di tutti gli agenti, se falliscono, analizzare le cause e regolare il prompt per riprovare
• Notificare l'autore tramite Telegram una volta completato

Cosa può fare l'Agente (strato di esecuzione)?

• Leggere e scrivere nel codice sorgente
• Eseguire test e build
• Inviare codice e creare PR
• Rispondere ai feedback della revisione del codice

Punto chiave: l'Agente dello strato di esecuzione non avrà mai accesso al database di produzione e non vedrà le informazioni sensibili del cliente. Hanno solo il "minimo contesto necessario per completare questo compito".

Questo design è intelligente: il confine di sicurezza è chiaro, garantendo al contempo l'efficienza.

Flusso di lavoro completo: 8 passaggi dalla richiesta del cliente alla fusione della PR

Ora entriamo nella parte centrale. Utilizzerò un caso reale dell'autore della scorsa settimana per guidarti attraverso l'intero processo.

Contesto: un cliente aziendale ha chiamato, dicendo di voler riutilizzare le impostazioni già configurate e condividerle all'interno del team.

Passo 1: Richiesta del cliente → OpenClaw comprende e scompone

Dopo la chiamata, l'autore ha parlato con Zoe (il suo OpenClaw) riguardo a questa richiesta.

La cosa sorprendente qui: zero costi di spiegazione. Poiché tutte le registrazioni delle riunioni vengono sincronizzate automaticamente in Obsidian, Zoe ha già letto il contenuto della chiamata e sa chi è il cliente, il loro scenario aziendale e la configurazione esistente.

L'autore e Zoe hanno scomposto la richiesta in: creare un sistema di template che consenta agli utenti di salvare e modificare la configurazione esistente.

Poi Zoe ha fatto tre cose:

• Ricaricare il cliente - utilizzare l'API da amministratore per rimuovere immediatamente le restrizioni all'uso del cliente
• Recuperare la configurazione del cliente - ottenere le impostazioni esistenti del cliente dal database di produzione (solo in lettura)
• Generare il prompt e avviare l'agente - impacchettare tutto il contesto e fornirlo a Codex

Passo 2: Avviare l'agente

Zoe ha creato per questo compito:

• Un worktree git indipendente (ambiente di branch isolato)
• Una sessione tmux (per far funzionare l'Agente in background)

# 创建 worktree + 启动代理 git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install

tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high Perché usare tmux? Perché consente di intervenire a metà strada.

Se l'AI si discosta, non è necessario uccidere e ricominciare, basta inviare comandi direttamente in tmux:

# 代理方向错了 tmux send-keys -t codex-templates "Fermati. Fai prima il livello API, non preoccuparti dell'UI." Enter

代理需要更多上下文

tmux send-keys -t codex-templates "La definizione del tipo è in src/types/template.ts, usa quella." Enter Nel frattempo, il compito verrà registrato in un file JSON:{ "id": "feat-custom-templates", "tmuxSession": "codex-templates", "agent": "codex", "description": "Funzione di modelli di email personalizzati per clienti aziendali", "repo": "medialyst", "worktree": "feat-custom-templates", "branch": "feat/custom-templates", "startedAt": 1740268800000, "status": "running", "notifyOnComplete": true}

Passo 3: Monitoraggio automatico

Un compito cron controlla lo stato di tutti gli agenti ogni 10 minuti.

Punto chiave: non si tratta di "chiedere" all'agente come sta procedendo (questo consumerebbe molti token), ma di controllare fatti oggettivi:

• La sessione tmux è ancora attiva?
• È stata creata una PR?
• Qual è lo stato del CI?
• Se è fallito, è necessario riavviare? (massimo 3 tentativi)

Questo script di monitoraggio è 100% deterministico, consuma pochi token e notifica l'autore solo quando è necessario un intervento umano.

Questo è in realtà una versione migliorata del Ralph Loop, di cui parleremo in dettaglio più avanti.

Passo 4: Creazione della PR da parte dell'Agente

L'agente scrive il codice, fa un commit, un push e poi crea una PR usando gh pr create --fill.

Nota: a questo punto l'autore non riceverà notifiche. Perché una PR di per sé non rappresenta "completato".

La definizione di "completato" è:

• ✅ PR creata
• ✅ Branch sincronizzato con main (senza conflitti)
• ✅ CI passato (lint, controllo dei tipi, test unitari, test E2E)
• ✅ Approvato dal revisore Codex
• ✅ Approvato dal revisore Claude
• ✅ Approvato dal revisore Gemini
• ✅ Se ci sono modifiche all'interfaccia utente, devono essere incluse delle schermate

Solo se tutti questi requisiti sono soddisfatti, si considera veramente completato.

Passo 5: Revisione automatizzata del codice

Ogni PR sarà esaminata da tre agenti:

• Revisore Codex — il revisore più affidabile - esperto nel rilevare casi limite
• Può individuare errori logici, gestione degli errori mancanti, condizioni di gara
• Tasso di falsi positivi molto basso

• Revisore Gemini Code Assist — gratuito e facile da usare - può scoprire problemi di sicurezza e scalabilità trascurati da altri revisori
• Fornisce suggerimenti di correzione specifici
• Da non perdere

• Revisore Claude Code — praticamente inutile - eccessivamente cauto, suggerisce sempre di "considerare di aggiungere..."
• La maggior parte dei suggerimenti è eccessivamente progettata
• A meno che non sia contrassegnato come "critico", viene saltato direttamente

Tutti e tre i revisori commenteranno direttamente nella PR.

Passo 6: Test automatizzati

Il pipeline CI eseguirà:

• Controlli di lint e TypeScript
• Test unitari
• Test E2E
• Test Playwright (eseguiti in un ambiente di anteprima identico a quello di produzione)

La nuova regola aggiunta la scorsa settimana: se la PR modifica l'interfaccia utente, è necessario allegare uno screenshot nella descrizione, altrimenti il CI fallirà direttamente.

Questa regola ha notevolmente ridotto il tempo di revisione — l'autore può vedere rapidamente cosa è stato modificato dallo screenshot, senza dover accedere all'ambiente di anteprima.

Passo 7: Revisione manuale

Ora, l'autore riceve una notifica su Telegram: "PR #341 è pronta, può essere revisionata."

A questo punto:

• CI è tutto verde
• Tre revisori AI hanno approvato
• Lo screenshot mostra le modifiche all'interfaccia utente
• Tutti i casi limite sono stati registrati nei commenti della revisione

La revisione dell'autore richiede solo 5-10 minuti. Molte PR non le guarda nemmeno nel codice, ma si limita a guardare lo screenshot e le unisce direttamente.

Passo 8: Fusione

La PR viene fusa. Ogni giorno un compito cron pulisce i worktree isolati e i registri delle attività.Il processo completo, dalla richiesta del cliente al codice online, potrebbe richiedere solo 1-2 ore, mentre l'effettivo impegno dell'autore potrebbe essere stato solo di 10 minuti.

Tre meccanismi per rendere il sistema più intelligente

Meccanismo 1: Ralph Loop migliorato — non solo ripetere, ma imparare

Potresti aver sentito parlare del Ralph Loop: estrarre il contesto dalla memoria → generare output → valutare i risultati → salvare l'apprendimento.

Ma la maggior parte delle implementazioni ha un problema: ogni ciclo utilizza lo stesso prompt. Ciò che si impara migliora il recupero futuro, ma il prompt stesso è statico.

Questo sistema è diverso.

Quando l'Agent fallisce, Zoe non riavvia con lo stesso prompt. Analizza il motivo del fallimento con il contesto aziendale completo e poi riscrive il prompt:

❌ Esempio cattivo (prompt statico): { "Implementa la funzionalità di template personalizzati" }

✅ Esempio buono (regolazione dinamica): { "Fermati. Il cliente vuole X, non Y. Queste sono le loro parole durante la riunione: Vogliamo mantenere la configurazione esistente, non crearne una nuova da zero. Concentrati sul riutilizzo della configurazione, non sulla creazione di un nuovo processo." }`Zoe può fare questo tipo di aggiustamenti perché ha un contesto che l'Agent non ha:

• Cosa ha detto il cliente in riunione
• Cosa fa questa azienda
• Perché la richiesta simile precedente è fallita

Inoltre, Zoe non aspetta che tu assegni compiti, cerca attivamente lavoro:

• Mattina: scansiona Sentry → scopre 4 nuovi errori → avvia 4 Agent per indagare e riparare
• Dopo la riunione: scansiona i verbali → scopre 3 richieste di funzionalità menzionate dai clienti → avvia 3 Codex
• Sera: scansiona il log di git → avvia Claude Code per aggiornare il changelog e la documentazione per i clienti

L'autore torna da una passeggiata e su Telegram appare: "7 PR sono pronti. 3 nuove funzionalità, 4 correzioni di bug."

I modelli di successo vengono registrati:

• "Questa struttura di prompt è molto efficace per la funzionalità di fatturazione"
• "Codex deve ricevere in anticipo le definizioni dei tipi"
• "Deve sempre includere il percorso del file di test"

Il segnale di ricompensa è: CI approvato, tre revisioni del codice approvate, fusione manuale. Qualsiasi fallimento attiva il ciclo.

Più tempo passa, migliore diventa il prompt scritto da Zoe, perché ricorda cosa ha avuto successo.

Meccanismo 2: Strategia di selezione degli Agent — trovare esperti diversi per compiti diversi

Non tutti gli Agent sono ugualmente forti. L'autore riassume la strategia di selezione:

• Codex(gpt-5.3-codex) — principale - logica di backend, bug complessi, rifattorizzazione di più file, compiti che richiedono inferenza tra repository di codice
• Lento ma completo
• Rappresenta il 90% dei compiti

• Claude Code(claude-opus-4.5) — velocista - lavoro frontend
• Pochi problemi di autorizzazione, adatto per operazioni git
• (L'autore lo usava più frequentemente in passato, ma ha cambiato dopo l'uscita di Codex 5.3)

• Gemini — designer - ha senso estetico
• Per un UI bello, prima lascia che Gemini generi le specifiche HTML/CSS, poi passa a Claude Code per implementarle nel sistema dei componenti
• Gemini progetta, Claude costruisce

Zoe seleziona automaticamente l'Agent in base al tipo di compito e trasferisce l'output tra di essi. I bug del sistema di fatturazione vanno a Codex, le correzioni dello stile dei pulsanti a Claude Code, il nuovo design del cruscotto prima a Gemini.

Meccanismo 3: Dove si trova il collo di bottiglia? RAM

C'è una limitazione inaspettata: non è il costo dei token, non è la velocità dell'API, ma è la memoria.

Ogni Agent ha bisogno di:

• Il proprio worktree
• Le proprie nodemodules
• Eseguire build, controllo dei tipi, test

5 Agent in esecuzione contemporaneamente = 5 compilatori TypeScript in parallelo + 5 esecutori di test + 5 set di dipendenze caricati in memoria.

Il Mac Mini dell'autore (16GB di RAM) può eseguire al massimo 4-5 Agent contemporaneamente, oltre inizia a fare swap, e deve pregare che non costruiscano contemporaneamente.Quindi ha comprato un Mac Studio M4 Max (128GB RAM, $3500), che arriverà a fine marzo. Ha detto che condividerà se ne vale la pena.

Puoi anche costruire: da zero a funzionante in soli 10 minuti

Vuoi provare questo sistema?

Il modo più semplice:

Copia l'intero articolo a OpenClaw e digli: "Implementa un sistema di cluster Agent per il mio codice secondo questa architettura."

Poi, esso:

• leggerà il design dell'architettura
• creerà script
• imposterà la struttura delle directory
• configurerà il monitoraggio cron

Fatto in 10 minuti.

Devi preparare:

• Un account OpenClaw
• Accesso API a Codex e/o Claude Code
• Un repository git
• (opzionale) Obsidian per memorizzare il contesto aziendale

2026: Un'azienda da un milione di dollari per una sola persona

L'autore ha detto una frase alla fine che trovo molto ispiratrice:

"Vedremo un gran numero di aziende da un milione di dollari per una sola persona emergere a partire dal 2026. Il leverage è enorme, appartiene a coloro che capiscono come costruire sistemi AI di auto-miglioramento ricorsivo."

Ecco come appare:

• Un orchestratore AI come tua estensione (proprio come Zoe per l'autore)
• Delegare il lavoro a Agent specializzati, gestendo diverse funzioni aziendali
• Ingegneria, supporto clienti, operazioni, marketing
• Ogni Agent si concentra su ciò in cui è bravo
• Tu rimani concentrato e hai il controllo totale

La prossima generazione di imprenditori non assumerà 10 persone per fare ciò che una sola persona con un sistema può fare. Costruiranno in questo modo—mantenendo piccole dimensioni, agendo rapidamente, pubblicando ogni giorno.

Ora ci sono troppi contenuti spazzatura generati dall'AI. Varie esagerazioni, vari demo appariscenti di "centri di controllo delle attività", ma nulla di realmente utile.

L'autore dice che vuole fare l'opposto: meno esagerazioni, più documentazione del processo di costruzione reale. Clienti reali, entrate reali, invii reali pubblicati in produzione, e anche veri fallimenti.

Questo è tutto per l'articolo.

Riepilogo dei punti chiave:

• Architettura a doppio livello: il livello di orchestrazione detiene il contesto aziendale, il livello di esecuzione si concentra sul codice
• Automazione completa: processo in 8 passaggi dalla richiesta al PR, la maggior parte dei compiti completati con successo al primo tentativo
• Apprendimento dinamico: non esecuzione ripetitiva, ma adattamento della strategia in base ai motivi di fallimento
• Costi controllabili: partenza da $20/mese, uso intensivo $190/mese

Se stai anche esplorando l'applicazione pratica dell'automazione AI, spero che questo caso possa darti qualche spunto.

Riferimento:[[HTMLPLACEHOLDER_0]]