¿Cuántos tokens tiene una app de negocio? Un CRM completo en menos de 150k

La versión corta: un CRM completo cabe en menos de 150.000 tokens de metadatos tipados: la lógica de negocio — cada objeto, flujo, acción y permiso — se mantiene por debajo de 100.000, y la UI declarativa añade unos 50.000. La referencia app-crm incluida es aún menor: 1.792 líneas en 31 archivos, unos 16.000 tokens. Esa cifra de 16k describe la muestra de referencia, no el límite de un CRM completo de nivel producto. Ambos caben en una ventana de 200k. Lo llamamos software a escala de contexto: la AI puede sostener, razonar y refactorizar la aplicación entera mientras una persona revisa el diff.

Cuéntalo tú mismo

Los 16k no son un benchmark de producto completo. Son el recuento reproducible de la referencia CRM que acompaña al framework open source ObjectStack:

git clone https://github.com/objectstack-ai/objectstack
find objectstack/examples/app-crm/src -name '*.ts' -not -name '*.test.ts' \
  | xargs cat | wc -l
# → 1.792 líneas en 31 archivos ≈ 16k tokens (a ~4 caracteres por token)

Sistema	Archivos	Líneas	≈ Tokens	¿Cabe en 200k de contexto?
CRM de ejemplo (app-crm) — objetos, vistas, dashboard, flujo, permisos, traducciones	31	1.792	~16k	Sí — con 12× de margen
HotCRM — CRM completo de marketplace: 15 objetos, 17 flujos, 4 dashboards, 2 copilotos de AI, 4 idiomas	132	~18.000	menos de 150k en total (lógica de negocio bajo 100k + UI ~50k)	Sí — más de 50k de margen
Una base de código CRM convencional escrita a mano	miles	300k–1M+	millones	No — ni de lejos

La misma categoría de producto, dos escalas útiles: una muestra de referencia de ~16k y un CRM completo por debajo de 150k. Ambos están a escala de contexto; una base de código convencional no.

Por qué los tokens pasaron a ser la unidad correcta

Durante cincuenta años medimos el software en líneas de código porque la restricción vinculante era el lector humano. El lector cambió. Antes de que un agente de AI pueda cambiar un sistema con seguridad, tiene que cargarlo — y eso coloca cada base de código en uno de dos regímenes:

• Sistema mayor que el contexto. El agente hace grep, muestrea y adivina. Sus ediciones son locales; sus errores, globales. Cada cambio es arqueología a través de una cerradura.
• Sistema menor que el contexto. El agente lo lee todo — cada objeto, cada regla de permisos, cada dependencia — de una pasada. «¿Qué se rompe si cambio esto?» pasa de esperanza a pregunta con respuesta. Un cambio transversal — renombrar un concepto en el modelo de datos, los permisos, la API y la UI — es un único diff coherente.

No es una mejora incremental. Es un cambio de régimen, y la frontera está donde esté tu ventana de contexto.

Por qué la lógica de negocio se mantiene bajo 100k tokens

No por un truco de compresión — por eliminación. Una aplicación empresarial son dos cosas entrelazadas:

• Decisiones. Qué objetos existen, cómo se relacionan, quién puede ver qué campo, qué pasa cuando un lead convierte. Esa es tu ontología de negocio, y es genuinamente irreducible — nadie más que tú puede decidirla.
• Fontanería. Tablas, endpoints CRUD, pantallas de lista y detalle, middleware de permisos, escrituras de auditoría. Esto es esencialmente idéntico en toda app de negocio jamás escrita — es decir, derivable.

La apuesta de ObjectStack: conservar solo las decisiones en el artefacto y derivar toda la fontanería en el runtime. En el CRM de referencia incluido, esas 1.792 líneas son la lista de decisiones — metadatos tipados y validados con Zod. El esquema de base de datos, la API REST, la UI renderizada y las herramientas MCP se calculan a partir de ellas en cada arranque. Nada derivable se almacena, así que nada puede desviarse. En el HotCRM completo, esta separación mantiene la lógica de negocio bajo 100k tokens; la UI declarativa añade unos 50k y deja la aplicación entera por debajo de 150k.

Lo que no se comprime

Ser honesto con el límite importa más que el discurso:

• Algoritmos novedosos. Un optimizador de precios o un motor de matching a medida es código real y seguirá siéndolo. El formato tiene salidas de emergencia — las acciones y los plugins son TypeScript corriente.
• Experiencias a medida, al píxel. La UI dirigida por esquemas renderiza patrones empresariales muy bien; no es como se construye una web de marca o un juego.
• Integraciones exóticas. El conector a un servicio SOAP de hace treinta años sigue siendo código de conector.

Así que la afirmación es más estrecha que «todo se vuelve metadato» — y por eso más fuerte: el núcleo CRUD-más-workflow que constituye la mayor parte del software empresarial es derivable, y el residuo que de verdad importa — la ontología — cabe en el contexto.

Qué cambia cuando el software es a escala de contexto

1. La revisión se vuelve real. 1.792 líneas son una code review. 300.000 líneas son un ritual. Una persona puede leer el diff entero; la puerta de validación y la imposición de permisos y auditoría del runtime respaldan el resto.
2. El mantenimiento deja de pudrirse. Cuando el sistema entero cabe en contexto, el agente lo refactoriza completo en vez de parchear lo que ve. La curva de entropía habitual del software empresarial — cada cambio un poco más arriesgado que el anterior — se aplana.
3. La ontología sigue siendo tuya. La definición es un formato abierto Apache-2.0, archivos corrientes en tu repositorio — legibles por humanos, escribibles por cualquier agente, portables entre runtimes.

Prueba el bucle

Apunta tu agente de código a ObjectStack — el scaffold trae AGENTS.md y el paquete de skills, así que el agente arranca con las reglas del formato ya cargadas:

npm create objectstack@latest my-app && cd my-app
npx os dev --ui   # la app, funcionando — descríbele el siguiente cambio a tu agente

¿Prefieres el navegador antes que un repositorio? ObjectOS es la misma idea operada para ti — construye y pregunta online, con AI Builder, permisos y auditoría integrados.