Durante años, dominar un framework significaba aprender una sintaxis y un conjunto de convenciones para un lenguaje específico. En mi caso aprendí Symfony, Zend Framework y Laravel para PHP; Django y FastAPI para Python; Express, Astro y Next.js para Node. Cada lenguaje tenía sus ecosistemas, y la ventaja —personal y profesional— venía en buena parte de cuánto habíamos estudiado esos ecosistemas.

La popularidad de un framework se medía por proxies bien establecidos: estrellas en GitHub, downloads en npm, cuotas en encuestas como las de Stack Overflow o el Octoverse anual. Esos números reflejaban cuánta documentación, cuántos ejemplos y cuánta comunidad había detrás. Y por lo tanto, qué tan fácil era contratar gente para mantener un sistema o resolver dudas en producción.

Esa lógica está empezando a quedarse corta.

Los modelos de lenguaje ya saben sintaxis. Saben los patrones de cada framework, sus clases, sus métodos, sus convenciones y sus anti-patrones. No solo saben Django; saben la forma idiomática de combinarlo con Celery, con Redis, con Postgres. Y eso solo va a mejorar. La cantidad de conocimiento que un modelo puede recuperar y aplicar correctamente sobre un framework crece con cada generación. La velocidad con la que lo hace, también.

Cuando el modelo absorbe la sintaxis, lo escaso ya no es el conocimiento de la sintaxis. Lo escaso es la calidad de la definición.

Ese desplazamiento cambia el problema entero. Si la responsabilidad principal del desarrollador se mueve desde “saber escribir el código” hacia “saber describir lo que hay que construir”, entonces es natural que también se muevan los frameworks. No al nivel de archivos .py, .js o .php, sino al nivel del flujo de trabajo: cómo capturamos ideas, cómo las convertimos en especificaciones funcionales, cómo las ejecutamos en lotes adecuados al esfuerzo del modelo y cómo dejamos rastro auditable de todo lo construido.

El flujo que estoy probando

En las últimas semanas estuve usando la misma metodología en dos o tres proyectos, mejorándola en el camino. No es un canon ni pretendo que lo sea; son prompts y plantillas que he ido afinando. Empezó como un solo archivo y fueron apareciendo otros conforme los primeros resultados pedían más estructura. El patrón empieza a sostenerse, y vale la pena describirlo.

El flujo tiene cuatro etapas, encadenadas pero no rígidas:

1. Draft. Un documento abierto donde escribo o dicto ideas sin estructura. Suelo usar dictado por voz; lo importante es bajar la fricción de captura. El draft puede crecer mientras el resto del pipeline avanza, sin tener que detenerme a darle forma.

2. To-Do procesado. Otro paso —en realidad otro prompt— toma el draft y lo transforma en un documento funcional, agrupado por batches de ejecución. El tamaño de cada batch se elige para maximizar los resultados del modelo según el nivel de esfuerzo configurado. Aquí ya no hay ambigüedad: cada batch describe entregables específicos y verificables.

3. Ejecución de batch. Otro programa lee el documento de batches y ejecuta el siguiente. Mientras lo hace, corre el lint, corre el build, corre los tests, y crea las pruebas automatizadas necesarias para cubrir lo que acaba de implementar. Cuando termina, el batch queda marcado como hecho.

4. Done + Changelog. El detalle de la implementación se mueve a un documento done, y se registra una entrada en el changelog del repositorio en formato estándar. El documento de batches queda limpio: solo lo que falta. El detalle vive en otro lado.

Ese último punto importa más de lo que parece. Los documentos del framework no los leen solo humanos: los leen los mismos agentes. Optimizar la longitud de cada documento no es una manía estética; es economía de tokens. Si el archivo que el modelo carga para implementar el siguiente batch trae arrastrando todo el historial de lo ya construido, cada ejecución se vuelve más cara, más lenta y más ruidosa. Mantener cada documento en su propósito —draft para captura, to-do para próxima acción, done para registro, changelog para auditoría— mejora la señal con la que el modelo trabaja. Y esa misma lógica vale para cualquier otra transición que se le agregue al sistema.

Esto explica un patrón que se repite en proyectos asistidos por IA: muchos flujos empiezan funcionando bien y luego se degradan. No suele ser que el modelo empeore. Es que el contexto se desordena. Se mezclan en los mismos archivos ideas pendientes, decisiones pasadas, implementaciones ya hechas, bugs corregidos, deuda técnica, instrucciones generales y detalles obsoletos. El framework debería evitar esa entropía desde el diseño, no rescatarla cuando ya pasó. Por eso el batch funciona como unidad crítica: suficiente información para ejecutarse bien, pero no tanta como para contaminar el contexto siguiente.

Para aterrizarlo: en los proyectos donde aplico esto, el framework vive como un conjunto de archivos en el repositorio.

docs/
  DRAFT.md                          # captura libre, dictada o tipeada
  TODO.md                           # batches funcionales pendientes
  DONE.md                           # detalle de batches ya completados
  TESTING.md                        # estado de cobertura y pruebas
  WORKFLOW-1-DRAFT-TODO.md          # prompt: draft → to-do
  WORKFLOW-2-TODO-CODE.md           # prompt: ejecutar siguiente batch
  WORKFLOW-3-TESTING.md             # prompt: ciclos de pruebas
  WORKFLOW-4-REFACTOR.md            # prompt: ciclos de refactor
  WORKFLOW-5-COMPACT-MIGRATIONS.md  # prompt: compactación de documentos

CHANGELOG.md                        # registro auditable, formato estándar
README.md                           # contexto persistente del proyecto
CLAUDE.md                           # instrucciones permanentes para el agente

Cada WORKFLOW-*.md es, en términos prácticos, un programa escrito en lenguaje natural. El número en el nombre marca su orden lógico cuando se encadenan. El resto de los documentos —DRAFT, TODO, DONE, TESTING, CHANGELOG— son los datos sobre los que esos programas operan.

Refactor, pruebas y release como ciudadanos del framework

El pipeline de batches cubre la implementación en línea recta, pero un proyecto real necesita más que eso. Por eso el framework también incorpora ciclos a demanda, fuera del flujo principal:

  • Refactorización de frontend: componentización, consistencia visual, rediseño, análisis funcional, análisis de usabilidad, revisión de la arquitectura general.
  • Refactorización de backend: seguridad, buenas prácticas de API, separación de responsabilidades, manejo de errores, validaciones, performance, cobertura de pruebas, revisión de arquitectura.
  • Pruebas automatizadas: unitarias, smoke, regresión, end-to-end. No siempre se corren con cada batch, pero deberían correr antes de cada release.
  • Análisis de seguridad: tampoco se ejecuta en cada batch, pero debe ejecutarse a demanda y, sobre todo, antes de cualquier corte de versión.

El punto no es “limpiar código”. Cada uno de estos ciclos abre una pregunta distinta sobre el sistema: si la interfaz expresa bien el producto, si los componentes están bien separados, si las APIs reparten responsabilidades como deberían, si los tests cubren lo que un agente implementó y nunca volvió a tocar. Si un agente implementa una funcionalidad y nadie valida que sigue funcionando después, el flujo se vuelve rápido pero frágil. La IA produce mucho código y lo produce rápido; sin estos ciclos a demanda, ese código se convierte en deuda invisible.

Cuando se trabaja con agentes es fácil caer en una ejecución continua: un batch, otra corrección, otra mejora, otra refactorización. Eso puede ser productivo durante el desarrollo, pero no reemplaza a una release. Una release no es solo publicar código; es cerrar un ciclo de sentido. Funciona como una frontera: marca qué está listo, qué fue validado, qué queda pendiente, qué se aprendió y qué se puede comunicar. Ese último concepto —el de release— es la pieza que aún no he formalizado del todo. Hoy tengo implementadas las transiciones de draft → to-do → ejecución → done → changelog. El siguiente paso es darle al ciclo un cierre explícito: una etapa donde refactorización, pruebas y revisión de seguridad funcionen como condiciones de salida antes de marcar una versión.

Para mí, cada uno de estos prompts es un programa. Solo que escrito en lenguaje natural, no en código.

En qué se diferencia esto de Spec Driven Development

Hay iniciativas como Spec Driven Development —y dos o tres más que han ganado tracción últimamente— que apuntan en una dirección parecida: subir la abstracción del trabajo del desarrollador. Reconozco el valor que tienen; en ciertos contextos pueden ser perfectamente útiles.

Mi inquietud con esos enfoques es distinta. Asumen una separación grande entre la planificación y la ejecución, con ciclos de vida de documentación relativamente lentos. Tiene sentido si el modelo que ejecuta es lento o poco confiable. Tiene cada vez menos sentido si el modelo puede implementar batches en minutos, con buena calidad, y con una curva de mejora que no muestra señales de detenerse.

Lo que propongo no exige esa separación. El draft puede seguir creciendo mientras los batches se ejecutan. El to-do puede actualizarse en paralelo. El humano dosifica su tiempo entre captura, refinamiento y revisión, pero el pipeline sigue moviendo trabajo. La rigidez secuencial deja de ser una virtud.

Cuando el código abunda, el workflow importa más

La IA hace que producir código sea más barato. Pero producir buen software no se vuelve automático por eso; al contrario. Si el código se vuelve más abundante, el desorden también: más archivos, más decisiones implícitas, más deuda técnica, más documentación obsoleta, más pruebas faltantes, más contexto acumulado. Por eso importa el framework. Pero no solo el framework de código: también el framework de trabajo. El sistema que decide cómo entra una idea al proyecto, cómo se transforma en especificación, cómo se divide en batches, cómo se ejecuta, cómo se prueba, cómo se documenta, cómo se refactoriza, cómo se prepara para release y cómo se conserva memoria sin inflar el contexto.

Por qué creo que esta es la dirección de viaje

Los frameworks que aprendimos —Symfony, Django, FastAPI, Express, Next.js, Astro y todos los demás— nos dieron mucho. Nos dieron convenciones, productividad y un terreno común sobre el cual contratar y construir equipos. Eso no desaparece. Pero el plano donde se decide la productividad se está moviendo.

Si la calidad de lo que construyes se traslada a la calidad de tus especificaciones, los frameworks también deberían trasladarse. No para reemplazar a Django o a Next.js, sino para vivir un nivel más arriba: organizando cómo capturamos intención, cómo la convertimos en plan, cómo la ejecutamos y cómo dejamos rastro.

Quizá la próxima generación de frameworks no empiece como librerías instalables con npm install o pip install. Quizá empiece como convenciones de documentos, prompts versionados, workflows repetibles, reglas para agentes, estructuras de repo: lenguaje natural convertido en sistema operativo de desarrollo.

No estoy proponiendo un estándar. Lo que comparto son prompts que he ido moldeando en pocas semanas mientras los uso en proyectos reales. Hay mucho espacio para parametrizar, mejorar y ajustar todo esto. Pero la dirección me parece lo suficientemente clara como para empezar a hablar de ella en voz alta. Y, también, para construir desde estudios como Moxe asumiéndola como punto de partida.