OpenClaw + Claude Code Tutorial: Un sol desenvolupador pot construir un equip de desenvolupament complet!
OpenClaw + Claude Code Tutorial: Un sol desenvolupador pot construir un equip de desenvolupament complet!
Avui comparteixo un cas pràctic molt impressionant. (Al final de l'article hi ha un tutorial)
Un desenvolupador independent, utilitzant OpenClaw + Codex/CC, ha creat un sistema d'Agent AI. Quins resultats ha aconseguit?
94 enviaments en un dia, 7 PR completats en 30 minuts, i en aquest dia també va tenir 3 reunions amb clients, sense obrir l'editor.
Això va passar realment al gener de 2026. L'autor ha fet públic l'arquitectura, el flux de treball i la configuració del codi del sistema, i després de llegir-ho, em sembla que aquesta idea val molt la pena aprendre, així que l'he organitzat en aquest article per compartir-ho amb tu.
Si tu també estàs utilitzant Codex o Claude Code, o si estàs interessat en OpenClaw, aquest article et donarà moltes idees.
Un sol desenvolupador, 94 enviaments de codi en un dia
Primer, mirem alguns dades per sentir la potència d'aquest sistema:
- Màxim de 94 enviaments en un sol dia (mitjana de 50 enviaments diaris)
- 7 PR completats en 30 minuts
- La velocitat des de la idea fins al llançament és tan ràpida que es pot "entregar la demanda del client el mateix dia"
I quant costa? Cada mes $190 (Claude $100 + Codex $90), un principiant pot començar amb només $20.
Potser et preguntes: ¿Això no és només acumular una pila d'eines d'AI i generar codi brossa de manera frenètica?
No. La història de Git de l'autor sembla com si "acabi de contractar un equip de desenvolupament", però en realitat és només ell. El canvi clau és: ha passat de "gestionar Claude Code" a "gestionar un majordom AI, que després gestiona un grup de Claude Code".
- Abans de gener: escriure codi directament amb Codex o Claude Code
- Després de gener: utilitzar OpenClaw com a capa d'orquestració, permetent que gestioni Codex/Claude Code/Gemini
Per què Codex i Claude Code per separat no són suficients?
En aquest moment, potser penses: Codex i Claude Code ja són molt potents, per què afegir una capa d'orquestració?
La resposta de l'autor és molt directa: Codex i Claude Code no saben gairebé res sobre el teu negoci. Només veuen codi, no veuen el panorama complet del negoci.
Hi ha una limitació fonamental aquí: la finestra de context és fixa, només pots escollir una cosa.
Has de decidir què hi poses:
- Omplir de codi → no hi ha espai per al context del negoci
- Omplir d'històric de clients → no hi ha espai per al repositori de codi
- No sap per a quin client es fa aquesta funcionalitat
- No sap per què va fallar la darrera demanda similar
- No sap la teva posició de producte i els principis de disseny
- Només pot treballar en funció del codi actual i del teu prompt
Actua com a capa d'orquestració, situada entre tu i totes les eines d'AI. El seu paper és:
- Tenir tot el context del negoci (dades dels clients, registres de reunions, decisions històriques, casos d'èxit/fallida)
- Traducir el context del negoci en prompts precisos, que es donen a agents concrets
- Permetre que aquests agents se centrin en el que saben fer millor: escriure codi
- Codex/Claude Code = xef professional, només cuina
- OpenClaw = xef principal, coneix els gustos dels clients, l'estoc d'ingredients, la posició del menú, i dóna instruccions precises a cada cuiner
Arquitectura específica del sistema de dues capes: capa d'orquestració + capa d'execució
Vegem l'arquitectura específica d'aquest sistema.
Dues capes, cadascuna amb la seva funció:
Què pot fer OpenClaw (capa d'orquestració)?
- Llegir tots els registres de reunions de les notes d'Obsidian (sincronització automàtica)
- Accedir a la base de dades de producció (permissos de només lectura) per obtenir la configuració del client
- Tenir permisos d'API d'administrador, pot recarregar directament el client per desbloquejar
- Seleccionar el proxy adequat segons el tipus de tasca
- Monitoritzar el progrés de tots els proxies, si falla analitzar la causa i ajustar el prompt per tornar a intentar
- Notificar l'autor a través de Telegram un cop completat
Què pot fer l'Agent (capa d'execució)?
- Llegir i escriure al repositori de codi
- Executar proves i construccions
- Presentar codi i crear PR
- Respondre als comentaris de la revisió de codi
Aquest disseny és intel·ligent: la frontera de seguretat és clara, alhora que garanteix l'eficiència.
Flux de treball complet: 8 passos des de la necessitat del client fins a la fusió del PR
Ara entrem a la part central. Amb un cas real de l'autor de la setmana passada, et guiaré a través del procés complet.
Context: Un client empresarial va trucar, dient que volia reutilitzar la configuració que ja havien establert i compartir-la dins de l'equip.
Pas 1: Necessitat del client → OpenClaw entén i descompon
Després de la trucada, l'autor i Zoe (el seu OpenClaw) van parlar sobre aquesta necessitat.
La màgia aquí: zero costos d'explicació. Com que tots els registres de reunions es sincronitzen automàticament a Obsidian, Zoe ja havia llegit el contingut de la trucada, sabia qui era el client, el seu escenari empresarial i la configuració existent.
L'autor i Zoe van descompondre la necessitat en: fer un sistema de plantilles que permeti als usuaris desar i editar la configuració existent.
A continuació, Zoe va fer tres coses:
- Recarregar el client — Utilitzant l'API d'administrador per aixecar immediatament les restriccions d'ús del client
- Obtenir la configuració del client — Obtenint la configuració existent del client de la base de dades de producció (només lectura)
- Generar el prompt i iniciar el proxy — Enviant tot el context empaquetat a Codex
Pas 2: Iniciar el proxy
Zoe va crear per aquesta tasca:
- Un git worktree independent (entorn de branca aïllat)
- Una sessió tmux (per permetre que l'Agent s'executi en segon pla)
# 创建 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 Per què utilitzar tmux? Perquè permet intervenir a mitges.
Si la IA es desvia, no cal matar-ho i començar de nou, simplement enviar ordres directament a tmux:
# 代理方向错了 tmux send-keys -t codex-templates "Atura't. Primer fes la capa API, no et preocupis per la UI." Enter
代理需要更多上下文
tmux send-keys -t codex-templates "La definició de tipus està a src/types/template.ts, utilitza aquella." Enter Al mateix temps, la tasca es registrarà en un fitxer JSON.{ "id": "feat-custom-templates", "tmuxSession": "codex-templates", "agent": "codex", "description": "Funció de plantilles de correu electrònic personalitzades per a clients empresarials", "repo": "medialyst", "worktree": "feat-custom-templates", "branch": "feat/custom-templates", "startedAt": 1740268800000, "status": "running", "notifyOnComplete": true}### Pas 3: Monitorització automàticaUn treball cron comprova cada 10 minuts l'estat de tots els agents.Punt clau: no es tracta de "preguntar" a l'Agent com va (això consumeix molts tokens), sinó de comprovar fets objectius: - La sessió tmux encara està activa? - S'ha creat alguna PR? - Quin és l'estat del CI? - Si ha fallat, cal reiniciar? (màxim 3 intents)Aquest script de monitorització és 100% determinista, molt eficient en l'ús de tokens, i només notificarà l'autor quan sigui necessària la intervenció manual.Això és en realitat una versió millorada del Ralph Loop, que es detallarà més endavant.### Pas 4: Creació de PR per part de l'AgentL'Agent escriu el codi, fa un commit, el puja, i després crea la PR amb gh pr create --fill.Atenció: en aquest moment l'autor no rebrà cap notificació. Perquè una PR en si mateixa no representa "completada".La definició de "completada" és: - ✅ PR creada - ✅ Rama sincronitzada amb main (sense conflictes) - ✅ CI aprovat (lint, comprovació de tipus, proves unitàries, proves E2E) - ✅ Revisió de Codex aprovada - ✅ Revisió de Claude aprovada - ✅ Revisió de Gemini aprovada - ✅ Si hi ha canvis d'UI, s'han d'incloure captures de pantallaNomés si es compleixen tots els requisits, es considera realment complet.### Pas 5: Revisió de codi automatitzadaCada PR serà revisada per tres Agents: - Revisor de Codex — El revisor més fiable - Expert en detectar casos límit - Pot identificar errors lògics, gestió d'errors que falten, condicions de competència - Taxa de falsos positius molt baixa - Revisor d'Assistència de Codi Gemini — Gratuït i fàcil d'utilitzar - Pot detectar problemes de seguretat i escalabilitat que altres revisors poden haver passat per alt - Proporcionarà suggeriments de correcció específics - No es desaprofita - Revisor de Codi Claude — Pràcticament inútil - Excessivament prudent, sempre suggereix "considerar afegir..." - La majoria de les seves suggerències són un disseny excessiu - A menys que estigui marcat com a "crític", es salta directament.Tots tres revisors comentaran directament a la PR.### Pas 6: Proves automatitzadesEl canal CI executarà: - Comprovacions de Lint i TypeScript - Proves unitàries - Proves E2E - Proves de Playwright (executades en un entorn de previsualització idèntic a l'entorn de producció)La nova regla afegida la setmana passada: si la PR modifica l'UI, s'ha d'adjuntar una captura de pantalla a la descripció, d'altra manera el CI fallarà directament.Aquesta regla ha reduït significativament el temps de revisió — l'autor pot veure ràpidament la captura de pantalla per saber què s'ha modificat, sense haver de fer clic a l'entorn de previsualització.### Pas 7: Revisió manualAra, l'autor rep una notificació de Telegram: "PR #341 està llesta per a la revisió."En aquest moment: - CI tot verd - Tots tres revisors AI han aprovat - La captura de pantalla mostra els canvis d'UI - Tots els casos límit estan registrats en els comentaris de revisió.L'autor només necessita de 5 a 10 minuts per revisar. Moltes PR les aprova sense mirar el codi, només mirant la captura de pantalla.### Pas 8: FusióLa PR es fusiona. Cada dia hi ha una tasca cron que neteja els worktrees aïllats i els registres de tasques.El procés complet, des de la demanda del client fins al desplegament del codi, pot trigar només 1-2 hores, mentre que la inversió real de l'autor pot ser només de 10 minuts.
Tres mecanismes per fer el sistema més intel·ligent
Mecanisme 1: Versió millorada del Ralph Loop — No només repetir, sinó aprendre
Potser has sentit parlar del Ralph Loop: extreure context de la memòria → generar sortida → avaluar resultats → guardar aprenentatge.
Però la majoria d'implementacions tenen un problema: cada cicle utilitza el mateix prompt. El que s'aprèn millora la recuperació futura, però el prompt en si és estàtic.
Aquest sistema és diferent.
Quan l'Agent falla, Zoe no reinicia amb el mateix prompt. Ella porta el context empresarial complet, analitza la causa de la fallada i després reescriu el prompt:
❌ Mal exemple (prompt estàtic): { "implementar funció de plantilla personalitzada" }
✅ Bon exemple (ajust dinàmic): { "Atura. El client vol X, no Y. Aquest és el que van dir a la reunió: Volem mantenir la configuració actual, no crear-ne una de nova des de zero. L'important és reutilitzar la configuració, no crear un nou procés." }`Zoe pot fer aquest tipus d'ajustaments perquè té context que l'Agent no té:
- El que el client va dir a la reunió
- A què es dedica aquesta empresa
- Per què va fallar la darrera demanda similar
- Al matí: escaneja Sentry → descobreix 4 nous errors → inicia 4 Agents per investigar i reparar
- Després de la reunió: escaneja les notes de la reunió → descobreix 3 demandes de funcionalitat mencionades pel client → inicia 3 Codex
- Al vespre: escaneja el git log → inicia Claude Code per actualitzar el changelog i la documentació del client
Els patrons d'èxit es registren:
- "Aquesta estructura de prompt és molt efectiva per a la funcionalitat de facturació"
- "Codex necessita tenir les definicions de tipus per avançat"
- "Sempre s'ha d'incloure la ruta dels fitxers de prova"
Com més temps passa, millor és el prompt que escriu Zoe, perquè recorda què pot tenir èxit.
Mecanisme 2: Estratègia de selecció d'Agents — Diferents tasques busquen diferents experts
No tots els Agents són igual de potents. L'autor resumeix l'estratègia de selecció:
- Codex(gpt-5.3-codex) — Principal - Lògica de backend, bugs complexos, reestructuració de múltiples fitxers, tasques que necessiten inferència entre repositoris de codi
- Lent però exhaustiu
- Representa el 90% de les tasques
- Claude Code(claude-opus-4.5) — Competidor ràpid - Treball de frontend
- Menys problemes de permisos, adequat per a operacions git
- (L'autor l'utilitzava més abans, però va canviar a Codex 5.3)
- Gemini — Dissenyador - Té estètica de disseny
- Per a una UI bonica, primer deixa que Gemini generi les especificacions HTML/CSS, després les passa a Claude Code per implementar-les al sistema de components
- Gemini dissenya, Claude construeix
Mecanisme 3: On està el coll d'ampolla? RAM
Aquí hi ha una limitació inesperada: no és el cost dels tokens, no és la velocitat de l'API, sinó la memòria.
Cada Agent necessita:
- El seu propi worktree
- Les seves pròpies nodemodules
- Executar construccions, comprovacions de tipus, proves
L'autor del Mac Mini (16GB RAM) pot executar com a màxim 4-5 Agents alhora, més enllà comença a fer swap, i ha de pregar que no construeixin alhora.Així que va comprar un Mac Studio M4 Max (128GB RAM, $3500), que va arribar a finals de març. Va dir que compartirà si val la pena o no.
També pots construir-ho: des de zero a funcionar en només 10 minuts
Vols provar aquest sistema?
La manera més senzilla:
Copia tota aquesta article a OpenClaw i digues-li: "Seguint aquesta arquitectura, implementa un sistema de clúster d'Agents per al meu repositori de codi."
Aleshores, farà:
- Llegir el disseny de l'arquitectura
- Crear scripts
- Configurar l'estructura de directoris
- Configurar la monitorització cron
Necessites preparar:
- Compte d'OpenClaw
- Accés a l'API de Codex i/o Claude Code
- Un repositori git
- (Opcional) Obsidian per emmagatzemar el context empresarial
2026: Una empresa de milions de dòlars d'una sola persona
L'autor diu al final de l'article una frase que trobo molt inspiradora:
"Veurem una gran quantitat d'empreses de milions de dòlars d'una sola persona apareixent a partir de 2026. El palanqueig és enorme, pertany a aquells que entenen com construir sistemes d'IA d'auto millora recursiva."
Així és com es veu:
- Un orquestrador d'IA com la teva extensió (com Zoe per a l'autor)
- Delegar treball a Agents especialitzats, gestionant diferents funcions empresarials
- Enginyeria, suport al client, operacions, màrqueting
- Cada Agent es concentra en el que fa millor
- Tu et mantens concentrat i amb control total
Ara hi ha massa contingut generat per IA que és brossa. Tot tipus de bombolles, tot tipus de demos elegants de "centres de control de tasques", però sense res realment útil.
L'autor diu que vol fer el contrari: menys bombolla, més documentació del procés de construcció real. Clients reals, ingressos reals, enviaments reals publicats en entorns de producció, també hi ha fracassos reals.
Aquesta és la fi de l'article.
Revisió dels punts clau:
- Arquitectura de doble capa: la capa d'orquestració conté el context empresarial, la capa d'execució se centra en el codi
- Automatització completa: un procés de 8 passos des de la demanda fins al PR, la majoria de les tasques es completen amb èxit a la primera
- Aprenentatge dinàmic: no és una execució repetida, sinó ajustar l'estratègia segons les causes del fracàs
- Cost controlat: a partir de $20/mes, ús intensiu $190/mes
Adreça de referència:[[HTMLPLACEHOLDER_0]]
