Abrí el repositorio de un proyecto de facturación multitenant que llevábamos meses desarrollando. Lo cloné en una máquina nueva, instalé el sistema, y escribí /run-task sin decirle nada más.
En dos minutos tenía el mapa completo: Laravel 12 con multi-tenancy, Vue 3 en el front, MySQL, Sanctum para auth. Detectó los comandos de test, marcó las carpetas de configuración de tenants como zona crítica, registró el MCP de Laravel solo. Todo antes de tocar una línea de código.
No le expliqué nada. Lo leyó solo.
Ese momento fue la confirmación de que lo que había armado los meses anteriores valía la pena.
A fin de año me di cuenta de algo incómodo: estaba perdiendo más tiempo corrigiendo a la IA que el tiempo que me ahorraba usándola.
No era un problema de la herramienta. Era un problema de cómo la estaba usando.
Cada vez que abría un proyecto, Claude arrancaba desde cero. Sin contexto. Sin saber qué stack usábamos, qué carpetas no tocar, cómo correr los tests. Yo se lo explicaba. Implementaba algo. Yo revisaba. Había algo raro. Lo corregía. Volvía a explicar. El ciclo se repetía hasta que el tiempo "ahorrado" ya no existía.
En diciembre y enero, justo cuando el tema de los agentes de IA explotó, decidí que si iba a seguir usando estas herramientas en serio, necesitaba armar algo mejor.
Así nació el onMedia Dev System.
El problema real
Cuando trabajás con IA en desarrollo, hay tres fricciones que nadie menciona mucho:
El contexto se pierde siempre. Cada sesión arranca desde cero. No importa cuántas veces le hayas explicado el proyecto — la próxima vez, no sabe nada.
Los proyectos se pisan. Si trabajás en varios proyectos a la vez, como es nuestro caso en onMedia, el caos crece. ¿Qué configuración aplica a cuál? ¿Este colega puede usar el sistema sin romper su flujo?
La IA implementa y planifica al mismo tiempo. Eso suena bien en teoría. En la práctica, mezclar roles genera inconsistencia. Si le pedís que piense y ejecute a la vez, hace las dos cosas a medias.
La solución: separar roles
La idea central del sistema es simple: Claude no implementa. Orquesta.
Hay dos herramientas trabajando juntas:
Claude Code — orquesta, planifica y revisa. Es el cerebro.
OpenCode — implementa el código. Es las manos.
Claude decide qué hay que hacer y cómo. OpenCode lo ejecuta. Claude después revisa si está bien. Nadie hace dos cosas a la vez.
Esto resolvió el problema de calidad casi de inmediato.
El flujo en la práctica
Cuando arranco una feature nueva, escribo /run-task en Claude Code. Eso dispara un pipeline de cinco pasos que corre solo:
Check — verifica que el sistema esté bien configurado
Context — lee el proyecto y construye el mapa (más sobre esto abajo)
Plan — Claude planifica qué hay que hacer, archivo por archivo
Implement — OpenCode ejecuta el plan
Review — Claude revisa el resultado, corre los tests, aprueba o rechaza
Al final del paso 5, el sistema me hace un handoff: "testeá esto y decime qué encontraste". Yo pruebo. Si hay algo para ajustar, escribo /iterate "lo que encontré" y el ciclo se repite sin tener que rearmar nada. Cuando está todo bien, /close archiva el plan y guarda lo aprendido en memoria.
Tres comandos. Sin liturgia.
El discovery automático
Este es el detalle que más me cambió el día a día.
La primera vez que corrés /run-task en un proyecto, el sistema lanza el Explorer — un subagente cuyo único trabajo es entender el proyecto desde cero, sin asumir nada.
El Explorer abre los archivos de dependencias (composer.json, package.json, requirements.txt, el docker-compose), recorre la estructura de carpetas, detecta los comandos de test, y con todo eso genera un archivo .ai/context.md que queda commiteado en el repo.
Ese archivo es la fuente de verdad. Stack con versiones, rutas, entry points, convenciones, qué carpetas son de solo lectura. La próxima vez que alguien abra ese proyecto — yo, un colega, la sesión de mañana — el sistema ya sabe todo.
No hay que explicar nada nunca más.
Y si el proyecto es Laravel, instala y registra el MCP de Laravel automáticamente, para que Claude pueda consultar modelos, rutas y esquema en tiempo real sin que yo haga nada.
Multi-proyecto sin conflicto
Trabajamos con multiples clientes. Tener un sistema de IA que se confunda entre proyectos no es una opción.
La solución fue simple: cada proyecto tiene su propio contexto en una carpeta .ai/ dentro del repositorio. El sistema vive ahí, aislado. No sabe nada de los otros proyectos y no interfiere con ellos.
Además — y esto fue importante para compartirlo con colegas — el sistema no hace nada hasta que vos lo activás. No hay configuración invasiva que tome control de Claude Code desde el arranque. Duerme en el proyecto hasta que escribís /run-task. Eso significa que un colega puede tener el sistema instalado sin que cambie nada de su flujo habitual, y activarlo cuando quiera probarlo.
La memoria
Hay un detalle más que me parece valioso mencionar.
El sistema tiene memoria persistente global. Una base de datos SQLite que vive en tu máquina y es compartida entre todos los proyectos. Cada vez que /close archiva un plan, guarda lo aprendido: errores que aparecieron, decisiones que se tomaron, patterns que funcionaron.
La próxima vez que arranques un proyecto similar, el sistema ya tiene esa base. No arranca desde cero nunca más.
Lo que cambió
No fue la velocidad de escritura de código. Eso mejoró, sí, pero no es el cambio principal.
Lo que cambió es que dejé de ser el intérprete entre el proyecto y la IA. Antes yo era el que sabía el contexto y tenía que transmitírselo en cada sesión. Ahora el sistema lo sabe. Yo solo dirijo.
El problema que tenía en diciembre — más tiempo corrigiendo que ahorrando — desapareció. No porque la IA sea mejor, sino porque el sistema que la rodea es más inteligente.
Si trabajás con Claude Code o estás pensando en empezar a usarlo en serio para desarrollo, el sistema está disponible para instalar. En los próximos días voy a compartir cómo instalarlo paso a paso.
¿Usás IA en tu flujo de desarrollo? ¿Cuál es la fricción que más te cuesta resolver?
