OpenCode + DDEV: cómo monté un entorno de desarrollo Drupal con 16 agentes de IA

Llevo meses trabajando con herramientas de IA para desarrollo. He probado Claude Code, Cursor, Copilot, y varias más que ni recuerdo. Todas tienen el mismo problema: o estás atado a un único proveedor, o la personalización de agentes es limitada. Así que decidí montar mi propio entorno.

Lo que voy a explicarte aquí es una configuración completa de OpenCode (alternativa open source a Claude Code) integrada con DDEV mediante contenedores Docker custom, con 16 agentes especializados, ejecución autónoma nocturna, proxy de modelos LLM y testing visual con Playwright. Son más de 7.000 líneas de configuración entre Markdown, JSON, YAML, Shell y Dockerfile. No es algo que montes en una tarde, pero el resultado merece la pena.

Qué es OpenCode y por qué no Claude Code

OpenCode es una herramienta CLI/TUI de código abierto para desarrollo asistido por IA. Si has usado Claude Code, la idea es similar: un agente que lee tu código, ejecuta comandos y propone cambios. La diferencia clave es que OpenCode es agnóstico de proveedor. Puedes conectar Anthropic, OpenAI, Fireworks, AWS Bedrock o cualquier API compatible con OpenAI.

¿Por qué no Claude Code directamente? Por coste y por flexibilidad. La API de Anthropic es cara. Sí, en Claude Code puedes intentar usar Haiku o Sonnet para algunas tareas, pero incluso esos modelos son significativamente más caros que modelos open source ejecutados en servidores de terceros como Fireworks. Con OpenCode puedo usar modelos open source que para muchas tareas son perfectamente viables y cuestan una fracción. Además, puedo crear agentes especializados con instrucciones, herramientas y modelos diferentes para cada tipo de tarea.

Por experiencia te puedo decir que la diferencia de coste no es menor. Cuando dejas un agente ejecutando tareas durante la noche (ya llegaremos a eso), la factura usando solo Anthropic se dispara. Con modelos open source en proveedores baratos, esas mismas sesiones cuestan mucho, pero mucho menos.

Tres contenedores, un ecosistema

Aparte de elegir OpenCode como herramienta, he montado una integración custom con DDEV para que todo corra dentro de contenedores Docker. Esto no es algo que venga de serie con OpenCode (podría haber hecho lo mismo con Claude Code o cualquier otra herramienta). La idea es tener un entorno reproducible donde la herramienta de IA, el servidor web y el navegador de testing convivan en la misma red Docker sin instalar nada en la máquina host.

La arquitectura se basa en tres contenedores. El contenedor OpenCode es donde corren los agentes de IA, tiene acceso al código del proyecto y puede ejecutar comandos Drush y Composer dentro del contenedor web. El contenedor Web es el estándar de DDEV: Drupal, Drush, las herramientas de calidad de código, lo de siempre. Y el contenedor Playwright, un navegador headless que los agentes pueden controlar para hacer testing visual, capturas de pantalla y navegar formularios.

Los tres comparten la misma red Docker, así que se ven entre ellos. OpenCode puede usar Playwright para validar visualmente un cambio y al mismo tiempo ejecutar un drush cr en el contenedor web. Todo sin salir del entorno.

He creado comandos DDEV custom (ficheros en .ddev/commands/host/) para simplificar el día a día. Con ddev opencode abro la interfaz interactiva, con ddev opencode ralph lanzo el modo autónomo, y con ddev phpunit o ddev phpstan ejecuto las herramientas de calidad directamente. Nada de entrar manualmente en contenedores ni recordar rutas.

16 agentes, cada uno a lo suyo

OpenCode usa una arquitectura de orquestador + subagentes. El agente principal analiza lo que le pides y delega a agentes especializados. He montado 16, divididos en cuatro grupos.

Los agentes de desarrollo: drupal-dev para backend, drupal-theme para frontend y Twig, drupal-test para PHPUnit, drupal-perf para performance y cache, drupal-update para actualizaciones de Composer y migraciones de BD, y twig-audit para auditar plantillas.

Los agentes de calidad: three-judges es un gate de calidad con tres jueces (Arquitecto, Seguridad, Rendimiento) que deben aprobar cualquier cambio significativo. output-verifier valida la precisión de los outputs generados.

Los agentes de contenido: blog-writer para artículos técnicos, sales-copy para landing pages, email-responder para emails profesionales.

Y los agentes de utilidad: applier para aplicar cambios mecánicamente al código, code-explorer para exploración rápida del codebase, deep-research para investigación profunda, ralph-planner para generar requisitos, y visual-test para testing con Playwright.

Cada agente con su modelo

No todos los agentes necesitan el mismo modelo detrás. Los agentes de calidad (three-judges, output-verifier) y el orquestador usan a día de hoy Claude Opus 4-6 porque es el modelo más capaz para tareas que requieren razonamiento complejo: evaluar arquitectura, detectar problemas de seguridad, tomar decisiones de diseño. Pero eso no significa que de aquí a un mes siga usando ese. Los modelos cambian cada pocas semanas y lo que hoy es el más listo mañana puede no serlo.

El resto de agentes (desarrollo, contenido, utilidades) funcionan con modelos más baratos. No voy a especificar cuáles porque no lo veo relevante. La idea es que generar código, aplicar cambios mecánicos o redactar contenido son tareas donde un modelo menos potente rinde perfectamente bien y cuesta una fracción. La clave del sistema es esa separación: modelos inteligentes para tareas inteligentes, modelos baratos para todo lo demás.

El patrón Applier

Esta es una decisión arquitectónica que me costó llegar a ella, pero ha marcado la diferencia. La idea es simple: separar los agentes que analizan de los que escriben.

Los agentes de desarrollo (drupal-dev, drupal-theme, etc.) solo pueden leer ficheros y ejecutar comandos. Cuando proponen un cambio, generan bloques SEARCH/REPLACE como propuesta. No tocan el código directamente.

El agente applier recibe esos bloques y los aplica mecánicamente. Usa un modelo pequeño y barato con temperatura 0.0 para máxima precisión y mínimo coste.

¿Qué consigues con esto? Que un agente de análisis no modifique accidentalmente ficheros que no debería. Y que puedas revisar las propuestas antes de aplicarlas. He visto esto muchas veces en herramientas de IA: el agente analiza bien, pero al escribir se pasa de listo y cambia cosas que no le has pedido. Con el patrón Applier eso no pasa.

Ralph Loop: ejecución autónoma nocturna

El loop de Ralph es un sistema que permite a OpenCode trabajar de forma independiente en tareas complejas, sin intervención humana.

El flujo tiene dos fases. En la fase de planificación le pasas un fichero requirements.md con el objetivo, los requisitos y los criterios de éxito. Ralph analiza el código existente y crea tareas con prioridades (P0 a P3) usando Beads, un sistema de tracking de tareas persistente basado en Git. En la fase de ejecución entra en un bucle: consulta las tareas pendientes, trabaja en la de mayor prioridad, la cierra, y repite. Si descubre trabajo adicional, crea nuevas tareas. Cuando no quedan tareas pendientes, termina.

Lo que nadie te cuenta es que la clave del loop de Ralph no es el bucle en sí, sino la combinación de opencode run (modo no interactivo) con permisos en modo allow (sin prompts de confirmación). Eso permite ejecución completamente autónoma.

¿No es peligroso? Ahí está el matiz. Los agentes no pueden hacer git commit, git push, ni ninguna operación Git destructiva. Está bloqueado en la configuración de permisos. Así que dejas Ralph trabajando toda la noche, y por la mañana haces un git diff, revisas el resultado y commiteas tú. El humano siempre tiene la última palabra.

He usado el loop de Ralph para refactorizaciones grandes, corrección masiva de errores de PHPCS y PHPStan, y para implementar features completas partiendo de un fichero de requisitos. Funciona especialmente bien con los audit fixers: ficheros de instrucciones específicas para corregir automáticamente errores de calidad de código.

El proxy LLM que te ahorra dinero

Usar un único proveedor de IA es hacerse trampas al solitario con los costes. Un modelo premium es brutal para razonamiento, pero usarlo para aplicar un SEARCH/REPLACE mecánico es tirar dinero.

La solución es LiteLLM como proxy. Tengo un servidor que actúa como gateway unificado (compatible con la API de OpenAI) y enruta cada petición al modelo más adecuado. Las tareas complejas de planificación y evaluación de calidad van al modelo premium del momento. El desarrollo y análisis de código van a un modelo intermedio. La aplicación mecánica de cambios va al modelo más barato que encuentre que funcione bien con temperatura 0.0. Y para ejecución autónoma nocturna elijo según el presupuesto.

Lo importante es que tengo configurados modelos de Anthropic, OpenAI, Fireworks, AWS Bedrock y otros proveedores. Si mañana sale un modelo open source que rinda mejor que lo que uso hoy, añado el modelo en LiteLLM y le digo a cada agente en la configuración de OpenCode qué modelo tiene que usar. Es una configuración muy simple, se cambia en un momento.

¿Cuánto te ahorras? Depende mucho del tipo de tarea y de si es algo corto o una sesión larga que dejas corriendo durante horas. Pero fácilmente puedes estar hablando de dos o tres veces más barato que usar la API de Anthropic para todo. Dicho esto, lo más rentable en relación calidad/precio a día de hoy sigue siendo la suscripción de Claude. El ahorro real viene cuando necesitas ir más allá de lo que la suscripción te permite, especialmente en sesiones largas del loop de Ralph donde el consumo se dispara.

Skills: recetas para tareas repetitivas

Los skills son instrucciones detalladas que se invocan como comandos dentro de OpenCode. Piensa en ellos como recetas paso a paso para operaciones comunes de Drupal. He creado 12 skills, pero los que más uso a diario son estos.

drupal-audit ejecuta el módulo Drupal Audit (drush audit:run con filtrado por módulo) para PHPCS, PHPStan, PHPUnit, Twig y complejidad ciclomática. Es el punto central de calidad de código. run-quality-checks es el fallback con PHPCS + PHPStan + PHPUnit para cuando el módulo Audit no está instalado. drupal-module-scaffold genera el esqueleto completo de un módulo custom. playwright-browser-testing hace testing visual con capturas y navegación de formularios. Y drush-commands da acceso rápido a los comandos Drush habituales: cache rebuild, config export/import, user login.

Cada skill tiene el procedimiento completo, incluyendo qué herramienta usar, qué formato de salida esperar y cómo manejar errores. Los agentes los invocan automáticamente cuando detectan que una tarea encaja con un skill disponible.

Permisos: autonomía con red de seguridad

La filosofía de permisos es clara: los agentes pueden leer y escribir código libremente, ejecutar cualquier comando de desarrollo, pero nunca pueden hacer operaciones Git destructivas. Pueden hacer git diff, git log y git status, pero git commit, git push, git pull, git checkout y git reset están bloqueados. El usuario siempre revisa y commitea manualmente.

También he configurado un sistema de notificaciones de escritorio. El contenedor OpenCode envía notificaciones al host cuando necesita atención, completa una tarea o detecta un error. Así puedo dejar Ralph corriendo y enterarme cuando termine o cuando algo falle, sin estar pegado a la terminal.

El flujo de trabajo real

Para que no quede en teoría, así es como trabajo en el día a día.

En modo interactivo abro ddev opencode, le pido lo que necesito ("implementa el servicio X", "corrige los errores de PHPStan en este módulo"), el orquestador delega al agente adecuado, el applier aplica los cambios, y los three-judges validan. Yo reviso y commiteo.

En modo Ralph escribo un requirements.md con lo que quiero, lanzo ddev opencode ralph, y me voy a hacer otra cosa (o a dormir). Por la mañana, git diff y revisión.

Después de meses trabajando con esta configuración, la realidad es que no volvería atrás. No porque la IA genere código perfecto (no lo hace), sino porque la automatización de las tareas repetitivas y la calidad forzada por los three-judges han cambiado mi forma de trabajar.

Lo que más valor me aporta no es la generación de código en sí. Es la combinación de agentes especializados con gates de calidad automáticos. Antes, la revisión de código era algo que hacía yo solo, con las limitaciones que eso tiene. Ahora tengo tres "jueces" revisando arquitectura, seguridad y rendimiento antes de que yo vea nada.

¿Es perfecto? No. Los agentes a veces se atascan en bucles, los modelos baratos generan código mediocre que los judges rechazan, y configurar todo esto lleva tiempo. Pero si trabajas con Drupal a diario y estás buscando cómo integrar IA de verdad en tu flujo de trabajo, esta es la configuración más completa que he conseguido montar. Y lo digo siendo consciente de que la he montado yo, así que puede que no sea del todo objetivo.

Por qué no lo comparto (de momento)

Sé que alguien estará pensando "¿y dónde me descargo todo esto?". La realidad es que la configuración tal como la tengo ahora mismo tiene muchas cosas personales: credenciales, rutas específicas de mis proyectos, instrucciones de agentes con contexto de mis clientes. No es algo que pueda subir a un repositorio tal cual. Tendría que hacer una limpieza importante para dejarlo en un estado compartible, y ahora mismo no es mi prioridad.

Lo que sí puedo decir es que la idea general no es complicada de replicar si ya trabajas con DDEV y tienes experiencia con Docker. OpenCode tiene buena documentación, LiteLLM también, y los agentes al final son ficheros Markdown con instrucciones. El trabajo gordo está en afinar las instrucciones de cada agente y en el loop de Ralph, que es un script bash de unas 500 líneas.

Cómo ha cambiado mi forma de trabajar

Después de más de una década picando código a la vieja usanza, la forma de trabajar ha cambiado muchísimo. Y no hablo de hace dos años. Hablo de los últimos meses. Cada modelo nuevo que sale mueve el suelo un poco más, y lo que funcionaba hace tres meses ya se puede hacer de forma más eficiente hoy.

Como freelance, esto tiene un impacto directo. Las horas que necesito para llegar a la misma solución que antes se han reducido de forma notable. Tareas que antes me llevaban una tarde entera de picar código, depurar y probar, ahora las resuelvo en una fracción de ese tiempo. Y no es que la IA haga el trabajo por mí: yo sigo revisando, decidiendo y commiteando. Pero la parte mecánica, la parte repetitiva, esa ya no la hago yo.

Y esto va a seguir cambiando. Cada mes que pasa los modelos mejoran, salen herramientas nuevas, y lo que hoy parece una configuración compleja probablemente se simplifique. Lo único que tengo claro es que quedarse trabajando como hace 5 años ya no es una opción.