Puedes tener OwlMeans hoy mismo: un comando, cualquier agente

La gente no deja de preguntarme cuándo podrá usar OwlMeans. La respuesta honesta solía ser: cuando salga la Plataforma. Ahora hay una mejor: puedes usar la parte que más importa hoy mismo, sobre el agente en el que ya confías.

OwlMeans es un pipeline de desarrollo basado en IA. Describes lo que quieres en forma de historias de usuario, y un equipo de roles de IA especializados las convierte en aplicaciones fullstack de TypeScript que de verdad son tuyas. Bajo cada una de esas aplicaciones hay una sola biblioteca — OwlMeans Common — aquello con lo que están hechos todos nuestros proyectos. Esta semana recibió un paquete create-app. Un comando genera un proyecto fullstack completo que Claude Code o GitHub Copilot pueden desarrollar de principio a fin, con toda la guía para el agente ya incluida.

Quiero llevarte por lo que te da ese comando, por qué está construido así y cómo pasar de una carpeta vacía a una funcionalidad real respaldada por una base de datos sin escribir tú mismo una sola línea de fontanería.

El único comando

Elige tu gestor de paquetes:

bun create @owlmeans/app my-app
# o
npm create @owlmeans/app@latest my-app
# o
npx @owlmeans/create-app my-app

Y luego:

cd my-app
bun run dev          # API en :3000, web en :3001

Abre la app web, ve a la pantalla de Sesión, añade y quita unos cuantos elementos. Eso es una aplicación fullstack que funciona: un contrato compartido y tipado, un backend y un frontend en shadcn UI que se hablan entre sí. Ninguna base de datos que aprovisionar, ninguna autenticación que configurar, ningún boilerplate que hayas tenido que copiar de un tutorial.

Lo que obtienes es un pequeño monorepo con tres workspaces:

• common — el contrato compartido: los entrypoints de las rutas, los esquemas de validación y los tipos que usan ambos lados.
• api — el backend, sobre @owlmeans/server-app, que guarda los datos de demostración en un recurso en memoria.
• web — el frontend, sobre @owlmeans/web-panel, con navegación shadcn, un layout y pantallas.

Esa estructura no es un juguete. Es la misma forma que usan nuestras aplicaciones reales, reducida a lo esencial. Cuando te quede pequeño el almacén en memoria, cambias un paquete — te lo muestro exactamente más abajo.

Por qué está construido para que los agentes no se pierdan

Aquí va la verdad incómoda sobre los agentes de programación en 2026. No tienen antigüedad. Cada sesión empieza de cero, y cada invocación paga el precio completo de todo lo que tu código no logró hacer explícito. Las cifras son brutales: en una base de código mediana, la fase de exploración — el agente leyendo archivos solo para averiguar dónde está cada cosa — puede comerse el «60–70 % del total de tokens de entrada», y una sola tarea puede empujar cientos de miles, incluso millones de tokens acumulados a través del modelo. El agente es listo. El agente también «parte de cero salvo por lo que tú metes explícitamente en su ventana de contexto».

Así que la pregunta que dio forma a OwlMeans Common era simple: ¿qué aspecto tiene una base de código diseñada para que la lea algo que olvida todo entre sesiones?

La respuesta resultó ser justo lo que los buenos ingenieros siempre quisieron. La industria llegó a ello por su cuenta este año — «el código debería ser simple, explícito y aburrido… para que la IA no tenga decisiones que tomar», y los agentes «batallan con los comportamientos implícitos y las abstracciones ingeniosas». Esa es exactamente la restricción bajo la que construimos:

• Nada de esquemas de DI complicados. Los servicios son funciones fábrica de TypeScript de toda la vida, registradas con un alias de tipo string y obtenidas con context.service('alias'). Sin decoradores, sin metadatos, sin magia de contenedor que haya que aplicar ingeniería inversa.
• Nada de código generado. Sin paso de OpenAPI-a-cliente, sin codegen de esquemas, sin artefacto de build que haya que mantener sincronizado con la realidad. Lo que lees es lo que se ejecuta.
• Nada de YAML, nada de configuración desbordada. La configuración es TypeScript. Las rutas y la configuración son objetos planos.
• Todo explícito y rastreable. Cada servicio, cada ruta, cada recurso se puede encontrar buscándolo. Una persona puede seguirle el hilo. Un agente también — sin quemar mil tokens adivinando.

Ese último punto es el juego entero. El código explícito y aburrido sale más barato de trabajar para un agente, y es la diferencia entre un asistente que edita con confianza el archivo correcto y uno que da bandazos por cuarenta.

Las cuatro ideas que le facilitan el trabajo al agente

Cuatro decisiones de diseño hacen la mayor parte del trabajo. No hace falta que las memorices, pero vale la pena verlas una vez, porque son la razón de que una petición a Claude Code aterrice limpia en lugar de desparramarse.

Inyección de contexto. El contexto de la aplicación contiene tus servicios y recursos y se pasa de arriba abajo. Registras un servicio como un closure fábrica y lo resuelves por alias. No hay nada oculto: todo el cableado es código corriente que un agente lee de una pasada.

Los entrypoints como protocolo fullstack universal. Esta es la clave de bóveda. Un entrypoint es una unidad de URL — un alias, una ruta, un método y un esquema de validación en línea — declarado una sola vez en common:

entrypoint(
  route(session.add, '/:sid/items', { parent: session.base, method: RouteMethod.POST }),
  filter(params(SessionParamsSchema), body(AddItemSchema)),
)

El backend elevate ese mismo entrypoint con un handler. El frontend lo elevate con una pantalla y lo llama con ctx.entrypoint(session.add).call({ params, body }). Una declaración es la única fuente de verdad para la ruta, la validación y los tipos en ambos lados. La cambias una vez y todo el stack sigue sincronizado. No hay una especificación de API aparte, ni un cliente generado que pueda quedar desfasado. Para un agente, esto significa que una nueva funcionalidad tiene una forma obvia y repetible: declara, implementa, llama.

Recursos unificados. Cada almacén de datos — en memoria, MongoDB, Redis, almacenamiento de objetos — implementa la misma interfaz Resource<T>: get, list, create, update, delete y unos cuantos parientes. El código de tu handler no cambia cuando cambia el almacenamiento. Cambiar el almacén en memoria de la demo por una base de datos real es, casi literalmente, un cambio de un solo paquete.

Un shadcn UI que es tuyo. La capa web está construida sobre shadcn y Tailwind v4, y los componentes viven en tu árbol de fuentes, no detrás de una dependencia. Es deliberado. shadcn «no es una biblioteca que instalas: es un generador de código… es tuyo», y se ha convertido en la biblioteca de componentes a la que recurre toda herramienta de IA para programar. El agente lee tu UI como React real y editable — el mismo código que ya conoce — en lugar de hurgar en un paquete opaco.

Completamente equipado de habilidades desde el primer día

Esta es la parte de la que más orgulloso estoy. El proyecto llega sabiendo ya cómo se le desarrolla.

Cada paquete @owlmeans/* trae su propia guía para el agente — habilidades de Claude Code e instrucciones de GitHub Copilot, con la versión emparejada a la del paquete. Cuando create-app termina de montar el andamiaje, despliega esa guía en el proyecto: las habilidades van a .claude/skills/, las instrucciones a .github/instructions/. También escribe un CLAUDE.md y un .github/copilot-instructions.md con directivas de memoria, más unos índices de memoria iniciales que ambos agentes leen al principio de cada sesión.

Así que cuando abres el proyecto y le pides a Claude Code que toque la capa de recursos, no tiene que ponerse a descubrir cómo funcionan los recursos de OwlMeans — la habilidad mongo-resource está ahí mismo. Cuando añade una ruta, la habilidad entrypoint está ahí mismo. Hay incluso una regla reuse-code integrada en CLAUDE.md que le dice al agente que busque un paquete @owlmeans/* existente antes de inventarse una solución propia. La primera vez que abras el proyecto, el agente te preguntará para qué es y escribirá tu respuesta en ambos archivos de contexto para no volver a preguntar nunca.

Nada de esto lo escribiste tú. No cableaste ningún andamiaje. Las habilidades, la memoria y las convenciones vinieron con el comando. Eso es lo que significa de verdad, en la práctica, «autosuficiente, completamente equipado de habilidades» — y es la misma maquinaria en la que se apoya nuestra Plataforma, entregada directamente en tus manos.

Paso a paso: del andamiaje a una funcionalidad real

Pongámoslo concreto. Digamos que quieres convertir el almacén en memoria de la demo en una funcionalidad real y persistente respaldada por MongoDB. No abres la documentación y te pones a cablear drivers. Generas el andamiaje y luego pides.

Primero, genera el andamiaje y arráncalo (sirve cualquier gestor):

bun create @owlmeans/app my-app     # o: npm create @owlmeans/app@latest my-app
cd my-app
bun run dev

Después, en Claude Code (o Copilot), arranca con una petición como esta:

Añade una funcionalidad persistente de notas respaldada por MongoDB. Usa @owlmeans/mongo y @owlmeans/mongo-resource en lugar del recurso estático en memoria. Declara los entrypoints y el esquema en sources/common, registra el recurso e implementa los handlers en sources/api, y añade una pantalla en sources/web. Reutiliza los paquetes @owlmeans/* existentes — sigue la habilidad reuse-code.

Esa petición funciona sin llevarte de la mano, y vale la pena entender por qué. El proyecto ya lleva consigo las habilidades para exactamente esto. El agente sabe que el cambio de recurso es uno a uno, porque cada recurso implementa la misma interfaz — el handler que hacía context.getStaticResource(...) pasa a ser context.resource(...) sobre una colección de Mongo, y las llamadas a create/list/delete son idénticas:

const notes = context.resource<NotesResource>(RES_NOTES)
await notes.create({ id, text, createdAt })
const { items } = await notes.list({ criteria: { ... } })

Sabe que el patrón del entrypoint sigue siendo el mismo — declara en common, elevate con un handler en api, elevate con una pantalla en web. Y sabe que tu UI es shadcn que puede editar directamente. Como la estructura es explícita y la guía viaja con el repositorio, el agente gasta sus tokens en construir tu funcionalidad en vez de reaprenderse el framework en cada sesión. Cuando más adelante actualices tus paquetes @owlmeans/*, vuelves a ejecutar npx @owlmeans/agent-skills y la guía se refresca junto con ellos.

Por qué esto es el comienzo, no la cosa entera

Seré claro sobre lo que esto es y lo que no es.

create-app es la biblioteca y la guía para el agente, puestas en tus manos para que lo conduzcas tú mismo con Claude Code o Copilot. Es genuinamente potente, y para muchos proyectos es todo lo que necesitas. La Plataforma OwlMeans — el pipeline completo de roles de IA especializados que convierte historias de usuario en software terminado y de tu propiedad — es la capa de encima, y está construida alrededor de esta misma biblioteca. Por eso precisamente puede hacer lo que hace a una fracción del coste: no anda explorando una base de código extraña en cada sesión ni paga el impuesto de la exploración, sino que opera sobre un framework diseñado desde los cimientos para ser explícito, repetible y barato de razonar. Nuestra meta es que la Plataforma construya estos proyectos con alrededor de diez veces menos tokens que un agente de programación sin gobierno abriéndose paso a duras penas por un repo desconocido.

Pero no tienes que esperar a eso. El cimiento sobre el que se sostiene la Plataforma se puede entregar hoy mismo, en un comando, sobre el agente por el que ya pagas. Ejecuta create-app, apúntale Claude Code y obtendrás un anticipo real de la manera OwlMeans de construir: tipada, explícita, completamente equipada de habilidades y tuya para quedártela.

Esa es la idea del equipo-alrededor-del-agente, hecha lo bastante pequeña para caber en tu terminal ahora mismo.