# Hice que Claude Opus 4.8 gestionara a otro agente de IA mientras yo trabajaba > Cómo construí un flujo de trabajo basado en tickets donde Claude Opus 4.8 orquesta OpenCode, reduciendo el desperdicio de tokens sin sacrificar la revisión, la visibilidad ni el control. *Published: June 6, 2026* *Tags: IA, Claude Code, OpenCode, Ingeniería Agéntica, Productividad* --- ¿Alguna vez usaste tu mejor modelo de IA para un trabajo que claramente no se merecía tu mejor modelo de IA? A mí me pasó. No porque no entendiera el enrutamiento de modelos. Uso modelos más baratos para tareas más baratas todo el tiempo. Pero cuando estás metido de lleno en un código base real, con pruebas que fallan, archivos cambiando y contexto moviéndose rápido, es fácil dejar que tu sesión más fuerte se convierta al mismo tiempo en planificador, ejecutor, revisor, secretario y trabajador en segundo plano. Ahí es donde la factura de tokens deja de ser un problema de precios y se vuelve un problema de sistemas. Esta semana reconstruí mi flujo de trabajo en torno a una separación más limpia: **Claude Opus 4.8 se queda como arquitecto. OpenCode pasa a ser el ejecutor. El repositorio se convierte en la capa de comunicación.** El resultado se siente menos como chatear con un solo asistente y más como dirigir un pequeño equipo técnico. Claude Opus 4.8 escribe la orden de trabajo. OpenCode la ejecuta a través de un servidor headless. Yo me conecto a la TUI de OpenCode para poder ver el trabajo en vivo. OpenCode escribe un reporte. Claude Opus 4.8 se despierta, revisa el trabajo y decide si enviar otra orden o traerme de vuelta. Sin tmux. Sin polling de modelos. Sin un arquitecto caro despierto mientras otro agente ejecuta comandos durante una hora.
Diagrama de arquitectura que muestra a Claude Opus 4.8 como arquitecto, OpenCode como ejecutor, una carpeta work-orders-AI como buzón, y al humano revisando solo después de que el bucle se estabiliza.

El patrón central: un modelo caro toma decisiones arquitectónicas, un ejecutor más barato realiza el trabajo acotado, y los archivos mantienen el contrato durable.

--- ## 1. El problema real no es el costo. Es la confusión de roles. El consejo obvio es "usa el modelo correcto para la tarea correcta". Eso es correcto, pero incompleto. En una sesión real de programación con IA, las tareas no llegan en categorías ordenadas. Un solo hilo puede incluir decisiones arquitectónicas, inspección de archivos, generación de código, pruebas de extremo a extremo, triaje de bugs, preocupaciones de despliegue y redacción de actualizaciones de estado. Si Claude Opus 4.8 se encarga de todo eso, la sesión se vuelve costosa por razones que no tienen nada que ver con la inteligencia. **Primero, el razonamiento premium se gasta en la ejecución rutinaria.** Claude Opus 4.8 es excelente para decidir qué debería pasar. No necesita ser el modelo que renombra archivos, aplica ediciones evidentes o escribe un reporte mecánico después de cada corrida. **Segundo, el ruido de la ejecución llena el contexto.** Logs de pruebas, reintentos, salida de shell, parches fallidos y razonamiento intermedio compiten con las decisiones reales de producto. Cuanto más capaz es el agente, más tentador es dejarlo seguir. Así es como una sesión de arquitectura limpia se convierte en una transcripción de terminal desordenada. **Tercero, el humano se convierte en el bus de mensajes.** Mi primera versión eran dos terminales uno al lado del otro dentro de VS Code. Le pedía a OpenCode que inspeccionara algo, esperaba su reporte, copiaba el resultado a Claude Opus 4.8, pedía revisión y luego llevaba la siguiente instrucción de vuelta a OpenCode. Funcionaba, pero yo estaba enrutando paquetes a mano. El flujo de trabajo necesitaba un protocolo. > [!important] > La parte cara no es solo el precio de Claude Opus 4.8. La parte cara es pedirle al modelo arquitecto que planifique, ejecute, espere, revise y recuerde cada detalle intermedio en el mismo contexto. La separación es simple. Claude Opus 4.8 se queda con el pensamiento caro: - Entender el repositorio. - Decidir qué importa. - Escribir órdenes de trabajo acotadas. - Revisar reportes. - Inspeccionar archivos riesgosos. - Proteger secretos, despliegues, operaciones de git y acceso a producción. OpenCode se queda con la ejecución acotada: - Leer la orden de trabajo. - Modificar solo los archivos solicitados. - Correr las verificaciones pedidas. - Escribir un reporte breve en el archivo exacto que Claude Opus 4.8 espera. Esa separación cambió tanto el costo como la ergonomía. Dejé de pedirle a una sola sesión que fuera todo. --- ## 2. La arquitectura: Opus 4.8, OpenCode y un buzón de archivos El sistema tiene tres partes en movimiento. **Claude Opus 4.8 es el arquitecto.** Él se queda con el criterio. Decide el alcance, define los criterios de éxito, revisa la implementación y mantiene la intención de producto más amplia en mente. En mi configuración, Claude Opus 4.8 es también el único agente con permiso para acercarse a áreas sensibles: acceso al VPS, configuración de despliegue, GitHub Actions, Infisical y cualquier cosa que involucre credenciales de producción. **OpenCode es el ejecutor.** Corre a través de `opencode serve`, que inicia un servidor backend headless. Después me conecto a ese servidor con `opencode attach`, así que sigo teniendo la TUI. Esa parte importa. Puedes correr OpenCode completamente headless si quieres, pero para los vibe coders la TUI es una oportunidad de aprendizaje. Ves lo que está haciendo el ejecutor, dónde duda, qué archivos abre y cómo interpreta la orden. **El repositorio contiene el buzón.** Una carpeta llamada `work-orders-AI/` almacena cada instrucción y cada reporte. La convención de nombres es determinística: ```text work-orders-AI/ _state.json w01-work-contact-machine.md w02-report-contact-machine.md w03-work-contact-machine-fixes.md w04-report-contact-machine-fixes.md ``` El invariante importante no es "los números impares siempre pertenecen a Claude Opus 4.8 y los pares siempre a OpenCode". Ese es el camino feliz, y la plantilla del skill lo usa porque facilita la lectura del flujo. En la práctica, la regla más fuerte es esta: **Los archivos `work` pertenecen a Claude Opus 4.8. Los archivos `report` pertenecen a OpenCode.** A veces necesitas más de una orden de trabajo seguida por una buena razón: una corrección, una tarea acotada, un nuevo límite de alcance o un paso de recuperación. El número mantiene la secuencia. La etiqueta `work` o `report` define la propiedad.
Diagrama de secuencia que muestra a Claude Opus 4.8 escribiendo un ticket de trabajo, OpenCode produciendo un ticket de reporte, Claude Opus 4.8 revisándolo, y luego enviando correcciones o cerrando la tarea.

El ciclo de vida del ticket reemplaza el copiar y pegar manual entre agentes con un buzón durable y simple.

### La configuración de la TUI que vuelve esto usable Los documentos oficiales de la CLI de OpenCode muestran las piezas de las que depende este flujo: `opencode serve` inicia un servidor headless, `opencode run --attach` puede enviar trabajo a ese servidor, y `opencode attach [url]` conecta una interfaz de terminal a un backend en ejecución. Mi configuración se ve así: ```bash # Terminal 1: inicia el backend de OpenCode opencode serve --port 4096 # Terminal 2: conecta la TUI para que veas al ejecutor en vivo opencode attach http://127.0.0.1:4096 ``` Dentro de la TUI de OpenCode, usa `/sessions` para listar y cambiar de sesión. La documentación actual de OpenCode lista `/sessions` con `/resume` y `/continue` como alias. Si tu versión instalada expone `/session`, usa el comando que tu build local provea, pero verifica la sesión activa antes de asumir que la TUI está mostrando la misma corrida a la que Claude Opus 4.8 está despachando. Después, Claude Opus 4.8 puede despachar trabajo al mismo backend y sesión: ```bash opencode run --attach http://127.0.0.1:4096 \ -s \ --format json \ -m \ "Lee ./work-orders-AI/w01-work-contact-machine.md y ejecútala. Escribe tu reporte en ./work-orders-AI/w02-report-contact-machine.md con ese nombre exacto de archivo." ``` Eso te da lo mejor de los dos modos: - OpenCode corre como un ejecutor, no como un chat que tienes que vigilar. - La TUI queda visible, lo cual es valioso si estás aprendiendo. - El archivo de reporte se vuelve el punto de control durable. - Claude Opus 4.8 puede revisar el resultado sin que copies mensajes entre terminales. ### ¿Por qué no hacer polling a la carpeta? La versión obvia está mal: decirle a Claude Opus 4.8 que revise la carpeta cada pocos segundos hasta que aparezca un reporte. Eso es caro. Un modelo en un bucle sigue siendo un modelo gastando contexto y tokens. El polling suena inofensivo cuando lo hace un script. El polling con un LLM en el bucle es desperdicio. Esto empeora con las pruebas de extremo a extremo. A Claude Opus 4.8 le encantan las E2E, y honestamente, ese instinto es bueno. Los productos reales necesitan pruebas que recorran el flujo real. Pero, en términos de tokens, dejar que un agente caro ejecute bucles de E2E durante una hora puede ser suicida. Un selector inestable, un servidor lento, un problema de autenticación, un modal que bloquea la página, y ahora tienes varios puntos de fallo que se acumulan en una transcripción enorme. El mejor patrón es el basado en eventos: Claude Opus 4.8 lanza el trabajo de OpenCode y se desentiende. El proceso de shell o el harness puede esperar pasivamente, prácticamente sin costo. El archivo de reporte es la señal de que el ejecutor terminó. > [!warning] > No construyas flujos de agentes donde Claude Opus 4.8 vea trabajar a otro modelo. Si el arquitecto no está tomando una decisión de juicio, el arquitecto no debería estar despierto. --- ## 3. El protocolo de tickets que mantiene cuerdos a ambos agentes El sistema de tickets es aburrido a propósito. Cada regla existe porque la ambigüedad se vuelve cara una vez que hay dos agentes involucrados. **El nombre del archivo declara el rol.** `w01-work-contact-machine.md` es una instrucción. `w02-report-contact-machine.md` es un reporte. La palabra `work` o `report` importa más que el número. **El slug se mantiene estable durante una ronda.** Si la orden de trabajo trata sobre `contact-machine`, el reporte debe mantener ese slug. Nada de nombres creativos. Nada de "final-report.md". Nada de "done.md". **El nombre de archivo esperado del reporte se escribe dentro de la orden de trabajo.** OpenCode nunca debe inferir dónde reportar. Claude Opus 4.8 le dice la ruta exacta. **El estado vive en `_state.json`.** El archivo de estado guarda el siguiente número de ticket, el id de sesión de OpenCode, el modelo, la variante opcional y la URL del servidor local. ```json { "next_ticket": 1, "session_id": null, "model": "opencode/minimax-m3-free", "variant": null, "server_url": "http://127.0.0.1:4096" } ``` Una orden de trabajo debería leerse como un pequeño contrato: ```markdown # W01 - Contact Machine ## Tarea Revisar el flujo de contacto e implementar los estados de validación faltantes. ## Requisitos / Criterios de éxito - [ ] Preservar la estructura actual del formulario. - [ ] Agregar validación para los campos de email y mensaje faltantes. - [ ] No tocar despliegue, secretos ni GitHub Actions. - [ ] Correr el comando local de validación si está disponible. ## Contexto Archivos relevantes: - src/contact/form.ts - src/contact/validation.ts ## Entrega - Archivos a crear/editar: los listados arriba, salvo que sea necesario. - **Tu reporte va en: `work-orders-AI/w02-report-contact-machine.md`** ``` Esa última línea no es decoración. Es la entrega. ### El humano sigue teniendo trabajo Esto no es "suelta a los agentes y reza". Yo sigo manteniéndome en el sistema, pero me moví al lugar correcto. Antes, yo enrutaba mensajes. Ahora reviso resultados. Claude Opus 4.8 decide si el reporte de OpenCode satisface el ticket. Si el trabajo es riesgoso, Claude Opus 4.8 abre los archivos cambiados y verifica la afirmación. Si el reporte es parcial, Claude Opus 4.8 escribe un ticket de corrección. Si OpenCode sigue cometiendo el mismo error ronda tras ronda, Claude Opus 4.8 puede tomar la acción directamente en casos extremos. Ese último movimiento es raro. Debería ser raro. El punto del sistema no es hacer que Claude Opus 4.8 vuelva a hacerlo todo. El punto es preservar la opción cuando el ejecutor se traba y el arquitecto puede resolver el bloqueo más rápido que con otro bucle de delegación. El cambio es simple: **el humano deja de ser el mensajero y se convierte en el revisor.**
Diagrama de límites que muestra a Claude Opus 4.8 con permiso para inspeccionar áreas sensibles de producción mientras OpenCode está restringido a archivos de implementación acotados y nunca toca secretos, despliegues ni pushes a git.

El ejecutor no debería tener los mismos permisos que el arquitecto. Los límites de rol son parte del modelo de seguridad.

--- ## 4. El skill que uso Este es el patrón de skill que uso para Claude Code CLI, preferentemente dentro de VS Code para poder mantener el repositorio, la terminal, las órdenes de trabajo y los reportes visibles al mismo tiempo. Lo importante: - Usa `work-orders-AI/` como buzón. - Hace que los nombres de archivo de los reportes sean determinísticos. - Evita tmux y el polling de modelos. - Usa OpenCode a través de `serve`, `attach` y `run --attach`. - Mantiene la TUI visible para que el humano pueda aprender del ejecutor. - Trata a Claude Opus 4.8 como revisor, no como espera pasiva. `````markdown --- name: work-orders-ai description: Orquesta un flujo de dos agentes (Arquitecto = Claude, Ejecutor = OpenCode headless) usando un buzón de archivos con sistema de tickets en work-orders-AI/. Úsalo cuando el usuario quiera delegar trabajo a OpenCode, montar un pipeline orquestador↔ejecutor, "mandar una work order", "que OpenCode haga X y me reporte", o pida el flujo de tickets W01/W02. Sin tmux, sin polling: el Arquitecto despierta solo cuando el report-file aparece. --- # Work Orders AI — Orquestación de dos agentes vía buzón de tickets Tú eres el **Arquitecto** (Claude). Delegas en el **Ejecutor** (OpenCode en modo headless `opencode run`). La comunicación es por **archivos** dentro de `work-orders-AI/` en el root del repo. No se usa tmux ni polling del modelo. ## Principio de eficiencia (no romper) - **Tu espera cuesta 0 tokens.** Nunca hagas loops de `capture`/`sleep` con el modelo activo. Lanza `opencode run` en **background** (`run_in_background: true`). Mientras corre, tu modelo está dormido. Cuando el proceso termina, el harness te re-invoca. - El Ejecutor solo gasta tokens cuando trabaja, porque lo disparas tú con un `run` puntual. Nunca pongas a OpenCode a "vigilar la carpeta" (sería un LLM en loop = caro). ## Convención de tickets (estricta) - Carpeta: `work-orders-AI/` en el root del repo. - Numeración **secuencial en ambas direcciones**, dos dígitos mínimo: `W01, W02, W03, ...`. **Impares = work (tú). Pares = report (OpenCode).** - Nombre de archivo: `w0X--.md` (todo minúsculas). - El `` se **conserva** entre el par: `w01-work-inicio-de-repo.md` → `w02-report-inicio-de-repo.md`. - **Determinismo de nombres:** cada work-order escribe DENTRO el nombre EXACTO del report esperado. Así sabes qué archivo esperar para despertarte. OpenCode NUNCA inventa nombres; usa el que le diste. ## Estado persistente `work-orders-AI/_state.json`: ```json { "next_ticket": 1, "session_id": null, "model": "opencode/minimax-m3-free", "variant": null, "server_url": "http://127.0.0.1:4096" } ``` - `next_ticket`: el próximo número de ticket a usar. - `session_id`: id de sesión de OpenCode para mantener memoria entre órdenes. - `model` / `variant`: modelo del Ejecutor (editable por el usuario). - `server_url`: URL del servidor headless de OpenCode (modo TUI en vivo). Lee `_state.json` al empezar cada sesión para saber dónde quedaste. ## Setup (una vez por repo) — MODO TUI EN VIVO (serve + attach) por defecto 1. Crea `work-orders-AI/` y `work-orders-AI/_state.json` (valores iniciales arriba). 2. Escribe `AGENTS.md` en el root del repo con las reglas del Ejecutor (plantilla abajo). 3. Verifica OpenCode instalado y autenticado: `opencode models` lista modelos. El modelo por defecto es `opencode/minimax-m3-free`; cámbialo en `_state.json` si el usuario quiere otro (más potente para trabajo real). 4. **Levanta el servidor headless** en background (puerto fijo, default 4096): ```bash opencode serve --port 4096 ``` Usa `run_in_background: true`. Si el puerto está ocupado, usa otro y actualiza `server_url` en `_state.json`. Verifica que respondió que escucha en el puerto. 5. **DALE AL USUARIO EL COMANDO DEL TUI** y espera a que confirme que lo abrió antes de despachar nada. Mensaje al usuario, textual: > Abre el TUI de OpenCode en una terminal nueva con: > `opencode attach http://127.0.0.1:4096` > Ahí verás en vivo el trabajo del Ejecutor y podrás cambiar el modelo. Avísame > cuando esté abierto. 6. **Crea la sesión compartida** (para que TUI y tus `run` compartan contexto): haz una primera invocación corta `opencode run --attach http://127.0.0.1:4096 --format json -m "sesion lista"`, extrae el `sessionID` y guárdalo en `_state.json`. Dile al usuario que en el TUI seleccione esa sesión (la más reciente) para ver el trabajo en vivo. A partir de aquí, todos los despachos usan `--attach -s `. ## Ciclo de trabajo (un round) Para cada orden, `X = next_ticket` (impar), report `Y = X+1` (par): 1. **Escribe la work-order** `work-orders-AI/w0X-work-.md` con la plantilla de abajo, incluyendo la línea exacta del report esperado `w0Y-report-.md`. 2. **Dispara al Ejecutor en background**, contra el servidor y sesión compartidos (así aparece en vivo en el TUI del usuario): ```bash opencode run --attach -s --format json \ --dangerously-skip-permissions -m [--variant ] \ "Lee ./work-orders-AI/w0X-work-.md y ejecútala completa. Sigue AGENTS.md. Escribe tu reporte en ./work-orders-AI/w0Y-report-.md con el nombre EXACTO." ``` (El `session_id` y `server_url` ya se fijaron en el Setup. Modo headless puro, sin TUI: omite `--attach` y `-s` en la primera orden y captura el `sessionID` de salida.) Usa `run_in_background: true`. La salida es **JSONL** (un evento JSON por línea) y puede traer una primera línea de warning no-JSON (p. ej. `[rtk] rtk binary not found`) que debes ignorar. El **session id** está en el campo `sessionID` de cualquier evento (formato `ses_...`). Guárdalo en `_state.json`. En órdenes siguientes añade `-s ` para mantener contexto. (Alternativa: `-c` continúa la última sesión, pero `-s ` es más seguro si hay un TUI en paralelo.) Tip de extracción: `grep -o '"sessionID":"[^"]*"' salida.json | head -1`. 3. **No esperes activamente.** El background job termina cuando OpenCode acaba; el harness te re-invoca. (Como respaldo, el report-file `w0Y-report-.md` es la señal durable de "terminó".) 4. **Lee y revisa** `work-orders-AI/w0Y-report-.md`. Verifica contra los criterios de éxito de la work-order. Si hace falta, abre `archivos` clave para confirmar. 5. **Actualiza `_state.json`**: `next_ticket = Y + 1`. 6. **Decide:** - ¿Cumple? → reporta al usuario el resultado y cierra (o pide la siguiente tarea). - ¿Faltó algo? → nueva work-order `w0(Y+1)-work-.md` con correcciones concretas (tira y jala). Repite. Relaja al usuario: tras cada round, resume qué pediste, qué hizo OpenCode, qué verificaste y qué sigue. ## Plantilla de work-order (`w0X-work-.md`) ```markdown # W0X — ## Tarea ## Requisitos / criterios de éxito - [ ] - [ ] ## Contexto ## Entrega - Archivos a crear/editar: - **Tu reporte va en: `work-orders-AI/w0Y-report-.md`** (nombre EXACTO, no lo cambies) ``` ## Plantilla de AGENTS.md (root del repo — reglas del Ejecutor) ```markdown # AGENTS.md — Reglas para OpenCode (Ejecutor) Trabajas en pareja con un Arquitecto (Claude) vía buzón de archivos en `work-orders-AI/`. ## Protocolo 1. Cuando te pidan ejecutar una work-order, lee el archivo `w0X-work-.md` indicado. 2. Ejecútala completa: crea/edita los archivos necesarios en el repo. 3. Escribe tu reporte en el archivo EXACTO que la work-order indica (`w0Y-report-.md`). NUNCA inventes ni cambies ese nombre. 4. Formato del reporte: ``` # W0Y — Reporte de - Estado: COMPLETADO | PARCIAL | BLOQUEADO - Archivos: - Qué implementé: - Cómo probar: - Notas/dudas: ``` ## Calidad - Sin dependencias externas salvo que la orden lo pida. - Si algo es ambiguo, entrega lo mejor posible y anótalo en Notas/dudas. - El detalle va en el código, no en el reporte. Reportes breves. ``` ## Notas operativas - Slug: kebab-case, corto, descriptivo del tema del round. - Si `next_ticket` supera 99, usa el número natural (`w100-...`). - Modo por defecto = TUI en vivo (serve + attach): el usuario ve el trabajo en su TUI y controla el modelo. Observabilidad extra: los archivos del repo + el stdout del job. - Modo alternativo = headless puro (sin TUI): no levantes el servidor ni des el comando `attach`; la primera orden crea la sesión (captura `sessionID` de la salida) y los despachos siguientes usan `-s ` sin `--attach`. Más simple, sin vista en vivo. - Si el servidor headless no está corriendo al empezar una sesión nueva (p. ej. la máquina se reinició), vuelve a levantarlo con `opencode serve` y re-entrega el comando `attach` al usuario; la sesión `session_id` guardada sigue siendo válida en el servidor. ````` Esto no es una ley universal. Es un patrón que funciona. Adapta los límites de permiso, el formato de reporte y la elección de modelo a tu propio entorno. Lo que yo no cambiaría es el bucle: 1. Claude Opus 4.8 escribe una orden de trabajo precisa. 2. OpenCode ejecuta una corrida acotada. 3. OpenCode escribe un reporte en una ruta exacta. 4. Claude Opus 4.8 revisa el reporte y los archivos. 5. El siguiente ticket continúa solo si hace falta. Ese bucle es el producto. --- ## 5. Dónde ahorra tiempo esto, y dónde se puede romper La mayor victoria no es solo que OpenCode pueda trabajar mientras yo hago otra cosa. La victoria más grande es que el flujo de trabajo elimina el problema del "¿en dónde estaba?" del trabajo multi-agente. Cuando estoy construyendo algo con muchos bordes, como un sistema de automatización de contactos, puedo darle a Claude Opus 4.8 el contexto a nivel de arquitectura una sola vez. Claude Opus 4.8 puede dividir el trabajo en tickets. OpenCode puede trabajar un slice a la vez. Yo puedo seguir diseñando, escribiendo o haciendo trabajo de cliente mientras el ejecutor maneja rondas de implementación acotadas. En un día de pruebas, tuve agentes trabajando desde la mañana hasta la medianoche mientras yo revisaba el trabajo solo unas pocas veces. Eso no significa que confiara en el sistema a ciegas. Significa que el sistema dejó de pedirme que vigilara las partes mecánicas.
Gráfico comparativo que muestra a Claude Opus 4.8 haciendo todo el trabajo frente a un flujo enrutado donde Claude Opus 4.8 maneja la arquitectura y OpenCode maneja la ejecución.

El ahorro viene de enrutar el trabajo por dificultad cognitiva, no de hacer que la IA haga menos.

### Buenos casos de uso Este flujo se adapta a trabajo con límites de ejecución claros: - Refactorizar un módulo contenido. - Implementar tareas a partir de un spec existente. - Crear pruebas para un comportamiento conocido. - Auditar una carpeta y reportar hallazgos. - Mover contenido a través de un pipeline determinístico. - Limpiar código generado después de que Claude Opus 4.8 define el objetivo. También funciona bien cuando quieres observabilidad. La TUI de OpenCode te deja ver al ejecutor en vivo. Los archivos de tickets te dan un registro de auditoría escrito. La revisión de Claude Opus 4.8 te da una segunda capa antes de que el trabajo llegue a ti. ### Malos casos de uso No uses este patrón cuando la tarea necesita juicio continuo de producto. Si el trabajo es ambiguo, políticamente sensible, crítico de seguridad o está fuertemente conectado a infraestructura de producción, mantén al ejecutor con una correa más corta. Claude Opus 4.8 debería encargarse del razonamiento y traerte a ti más temprano. Yo tampoco le daría al ejecutor acceso total a secretos, scripts de despliegue, servidores de producción o mutaciones de CI/CD. No es porque OpenCode sea débil. Es porque **los buenos sistemas no le dan a cada trabajador las llaves del edificio.** > [!warning] > Si un ejecutor puede tocar producción, hacer push a git, leer secretos y modificar la configuración de despliegue, ya no tienes un ayudante. Tienes un ingeniero de releases sin supervisión con rendición de cuentas poco clara. ### El límite práctico Este es el modelo mental que uso: - Claude Opus 4.8 es dueño del **por qué**, del **qué** y de **si es lo suficientemente bueno**. - OpenCode es dueño de **hacer la cosa acotada**. - El sistema de archivos es dueño de la **memoria**. - Yo soy dueño del **juicio final**. Esa división mantiene al flujo de trabajo lo suficientemente barato para correr, lo suficientemente estructurado para reanudar, y lo suficientemente controlado para confiar. --- ## 6. La realidad de la suscripción de $20 Esta es la parte que me importa para la gente que no se dedica de tiempo completo al desarrollo y no quiere quemarse un plan caro en media hora. Con este flujo de trabajo, puedo tener sesiones largas sin destruir inmediatamente mi uso de Claude Opus 4.8. Puedo mantener a Claude Opus 4.8 enfocado en arquitectura y revisión, mientras OpenCode maneja la ejecución con un modelo más barato. Con una suscripción de $20, esto no hace que los tokens sean infinitos. Si lo usas de forma intensiva durante varios días, todavía puedes llegar a los límites cerca del final del ciclo. Pero cambia el ritmo del trabajo. En vez de gastar tu mejor modelo en cada comando, lo gastas donde importa el juicio. Ese es el verdadero desbloqueo para los vibe coders, diseñadores y no-developers que están aprendiendo a construir. No necesitas un presupuesto gigante de ingeniería para empezar a pensar como un diseñador de sistemas. Necesitas un flujo de trabajo que respete la diferencia entre decisiones y mano de obra. La programación con IA se vuelve interesante cuando dejas de tratar a los modelos como internos mágicos y empiezas a tratarlos como partes de un sistema operativo. Un proceso planifica. Un proceso ejecuta. Un buzón coordina. Un humano revisa la salida. No es vistoso. Por eso funciona. Si pruebas esto, empieza con un repo de bajo riesgo. Dale a OpenCode una tarea contenida. Haz que el nombre del archivo del reporte sea determinístico. No dejes que Claude Opus 4.8 haga polling mientras espera. Mira las primeras rondas en la TUI. Aprende de los errores del ejecutor. **¡Y, por favor, cuéntame qué construyes!** Si estás trabajando en algo o tratando de resolver algo, cuéntame. Me encuentras en [X](https://x.com/Shasko) y en [LinkedIn](https://www.linkedin.com/in/fernando-ruiz-ux/), y lo mejor de escribir este tipo de posts es enterarme de lo que sale del otro lado. También doy mentoría a gente de diseño de producto, profesionales y gerentes que están tratando de averiguar cómo usar IA para hacer su trabajo más simple: pipelines, prototipos, automatizaciones, ese tipo de trabajo que te hace el día más productivo y la vida más fácil. Si ese es tu caso, escríbeme a hola@fernandoux.com. Y si quieren aprender haciendo, también estoy dirigiendo un workshop con XPerience: [Prototipado con IA](https://xperience.ec/capacitacion/prototipado-ia). Lo que más me gusta de enseñar es ver qué construye la gente con algo que les compartí. Sigue siendo la mejor sensación. Así que no duden en contactarme, aunque sea solo para conversar. Siempre estoy buscando conectar con más gente que se interesa por esto. --- *Fuentes:* - *[Claude Code CLI reference](https://code.claude.com/docs/en/cli-usage) - official commands and flags for Claude Code CLI, including sessions, background agents, attach, and model flags.* - *[OpenCode CLI reference](https://opencode.ai/docs/cli/) - official reference for `opencode run`, `serve`, `attach`, `models`, `session`, and relevant flags.* - *[OpenCode TUI docs](https://opencode.ai/docs/tui/) - official reference for the TUI, slash commands, and `/sessions`.* --- Source: https://www.fernandoux.com/blog/es/claude-opencode-two-agent-workflow/ Alternate language: https://www.fernandoux.com/blog/en/claude-opencode-two-agent-workflow/