Cloudflare Reconstruyó Next.js Con IA en 7 Días
Un ingeniero. Una semana. Mil dólares.
Eso es lo que le costó a Cloudflare reconstruir Next.js desde cero.
No parchearlo. No envolverlo. No hacer ingeniería inversa de su salida de compilación como todos los demás habían estado intentando. Una reimplementación completa de la superficie de API de Next.js — Vite en lugar de Webpack, Cloudflare Workers en lugar de Node.js, y un modelo de despliegue que se ejecuta en el edge por diseño en vez de como algo añadido después.
El resultado se llama V-Next. Y cuando leí el anuncio por primera vez, mi reacción inicial fue una mezcla de "eso es impresionante" y "espera, ¿esto es realmente lo suficientemente estable como para considerarlo?" Esas dos sensaciones coexistieron durante aproximadamente un día, hasta que empecé a profundizar en los detalles técnicos y los datos de producción.
Esto es lo que cambió mi perspectiva: la cifra de $1,000 no es la parte interesante. El costo es solo el titular que capta la atención. Lo que realmente vale la pena examinar es la metodología — cómo un ciclo de retroalimentación asistido por IA, anclado en la propia suite de pruebas de código abierto de Next.js, convirtió lo que debería haber sido un proyecto de varios meses para un equipo en siete días de trabajo de un solo ingeniero. Esa metodología es más significativa que el framework en sí, porque describe algo sobre cómo se construirá el software complejo en el futuro.
También hay una decisión técnica enterrada en V-Next que la mayoría de los análisis pasan por alto — la que explica por qué la reducción del tamaño del bundle es del 57% y no del 15%. Llegaré a eso, pero primero necesitas entender por qué Cloudflare estaba motivado para hacer esto, porque la historia detrás le da sentido a las decisiones arquitectónicas.
El Problema de Dependencia de Vercel del Que Nadie Habla con Honestidad
Next.js es un software genuinamente excelente. Vercel construyó algo que resolvió problemas reales — renderizado amigable con SEO, generación estática, renderizado del lado del servidor, ISR, server actions — y lo envolvió en una experiencia de despliegue que hacía que todo se sintiera fácil. El framework y la plataforma crecieron juntos, y esa co-evolución es parte de lo que hizo dominante a Next.js.
También es exactamente lo que creó la tensión.
Vercel se ejecuta sobre Node.js completo. Eso le da acceso a toda la superficie de API de Node.js — módulos nativos, sistema de archivos, crypto, streams, todo. Las funcionalidades de Next.js evolucionaron asumiendo que esa compatibilidad completa estaba disponible. Algunas de esas funcionalidades — particularmente las configuraciones más avanzadas de ISR y los patrones de server actions — funcionan en Vercel y se convierten en dolores de cabeza de mantenimiento en todos los demás entornos.
Cloudflare Workers es un runtime diferente. No es Node.js. Es un entorno de ejecución personalizado basado en V8 con un subconjunto de API estándar web y una capa limitada de compatibilidad con Node.js. La compensación es significativa: Workers se ejecuta en el edge, en centros de datos en más de 300 ciudades, con tiempos de arranque en frío medidos en milisegundos en lugar de segundos. El perfil de rendimiento es genuinamente diferente. Pero ese rendimiento proviene de un runtime restringido, y Next.js nunca fue diseñado con esa restricción en mente.
El intento de la comunidad para cerrar esta brecha se llamó OpenNext — un proyecto de código abierto que intentó hacer funcionar Next.js en Cloudflare Workers adaptando la salida de compilación. El problema era arquitectónico. OpenNext tenía que hacer ingeniería inversa de lo que producía el proceso de compilación de Next.js y luego transformarlo para que funcionara en un runtime diferente. Cada vez que Vercel actualizaba los internos de Next.js (lo cual ocurre constantemente), algo en OpenNext se rompía. Los mantenedores siempre estaban persiguiendo al framework en vez de construir.
Cloudflare observó este ciclo el tiempo suficiente, evaluó el esfuerzo necesario para mantener OpenNext, y tomó una decisión diferente: dejar de adaptar la salida de Next.js y en su lugar reconstruir lo que la produce.
Eso es V-Next. Una implementación limpia de la superficie de API de Next.js — el mismo directorio app/, las mismas convenciones de enrutamiento, los mismos patrones de componentes que los desarrolladores ya conocen — pero escrito desde cero orientado a Cloudflare Workers.
Cómo la IA Construyó un Framework en Siete Días
La metodología es la parte de esta historia que sigue atrayendo mi atención.
La suite de pruebas de Next.js es pública. Es exhaustiva — cubre comportamiento de enrutamiento, modos de renderizado, patrones de obtención de datos, error boundaries, y unos cientos de casos más que definen exactamente cómo luce el comportamiento correcto de Next.js. Es el tipo de cobertura de pruebas que querrías para un framework del que dependen millones de aplicaciones.
El ingeniero de Cloudflare usó esas pruebas como la especificación. No la documentación. No el código fuente de Next.js. Las pruebas — porque las pruebas definen el comportamiento de manera inequívoca de una forma que la documentación en prosa nunca logra del todo.
El proceso se ejecutó como un ciclo de retroalimentación: la IA genera código, las pruebas se ejecutan, los fallos se devuelven a la IA, la IA revisa, las pruebas se ejecutan de nuevo. Repetir. La suite de pruebas de código abierto proporcionó la verdad fundamental hacia la cual la generación de IA necesitaba converger. Sin ese ancla, el código generado por IA se desviaría — produciendo algo que parecía comportamiento de Next.js pero que divergía en casos extremos de maneras que solo se manifiestan en producción.
El rol del ingeniero humano fue la supervisión y la corrección de rumbo. Cuando la IA malinterpretaba un requisito, cuando dos pruebas tiraban en direcciones incompatibles, cuando una solución generada técnicamente pasaba las pruebas pero implementaba algo semánticamente incorrecto — esos eran los momentos que requerían juicio humano. No la mayoría del trabajo. Pero el 10% crítico que determinaba si el resultado era realmente correcto.
La cifra de costo — $1,000 — refleja el gasto en cómputo de IA. Una semana de ejecuciones intensivas de agentes, iteraciones de pruebas y ciclos de revisión. Ese número solo va a disminuir a medida que los modelos se vuelvan más eficientes.
Lo que este enfoque requiere es una suite de pruebas exhaustiva que realmente especifique el comportamiento que estás tratando de replicar. La mayoría de los proyectos no tienen esto. Next.js sí lo tiene porque es un proyecto de código abierto maduro, intensamente mantenido, con miles de contribuidores que se preocupan por la corrección del comportamiento. La metodología que funcionó aquí funciona precisamente porque la especificación ya estaba codificada en pruebas. Esa es una restricción real, y vale la pena reconocerla.
Lo que me parece más interesante de la metodología es dónde invirtió su tiempo el ingeniero humano. No escribiendo código de implementación — la IA se encargó de eso. No ejecutando pruebas — CI se encarga de eso. El trabajo humano fue en gran parte semántico: evaluar si una solución generada que pasaba las pruebas estaba realmente implementando lo correcto. Las pruebas verifican comportamiento dentro de entradas definidas. No verifican que hayas elegido la arquitectura correcta para las próximas tres versiones del framework.
Esa distinción importa. Hay una clase de decisión — "¿el estado del enrutamiento debería vivir en memoria o reconstruirse desde la URL en cada solicitud?" — donde las pruebas no te dan una respuesta clara, pero las consecuencias arquitectónicas se acumulan con el tiempo. Estas son las decisiones donde la experiencia humana es innegociable. La IA puede generar ambos enfoques. Se necesita alguien que haya mantenido aplicaciones Next.js en producción para saber cuál causa problemas seis meses después.
La implicación para los equipos que estén considerando aplicar esta metodología a sus propios proyectos: necesitan una suite de pruebas densa y un experto del dominio que pueda auditar el resultado. La IA comprime el tiempo de implementación. No elimina la necesidad de juicio ingenieril. Esas dos cosas son diferentes, y confundirlas es la forma en que terminas con un código base que pasa todas sus pruebas y aún tiene problemas arquitectónicos fundamentales.
La Decisión Técnica Que Explica la Reducción del 57% en el Bundle
Aquí está lo que la mayoría de la cobertura sobre V-Next pasa por alto.
Cambiar de Webpack a Vite no es simplemente un intercambio de herramientas de compilación. Las dos herramientas tienen filosofías fundamentalmente diferentes sobre el empaquetado.
Webpack fue diseñado en una era de HTTP/1 donde empaquetar todo en menos archivos más grandes era la decisión correcta — menos viajes de ida y vuelta significaban mejor rendimiento. Vite fue diseñado después de que ES modules se volvieron universales, lo que cambió completamente las matemáticas de optimización. Vite usa ES modules nativos en desarrollo y Rollup bajo el capó para compilaciones de producción. Ambos están orientados a producir una salida más pequeña y más dirigida que Webpack.
Además de eso, Cloudflare Workers se ejecuta en el edge — lo que significa que la latencia geográfica ya está resuelta por la arquitectura del runtime. No estás compitiendo contra viajes de ida y vuelta de 200ms a un servidor distante. La ubicación en el edge se encarga de eso. Lo que estás optimizando cambia de "menos solicitudes HTTP" a "menor carga total." La filosofía de salida de Vite se alinea mejor con esa restricción.
La reducción del 57% en el tamaño del bundle no es magia. Es el efecto compuesto de una herramienta de compilación que produce una salida más ligera combinada con un objetivo de despliegue que no necesita las optimizaciones de la era de Webpack que añadían peso a los bundles en primer lugar.
Los tiempos de compilación 4 veces más rápidos siguen un razonamiento similar. La experiencia de desarrollo de Vite siempre ha sido más rápida que la de Webpack — reemplazo de módulos en caliente casi instantáneo, arranques en frío más rápidos, procesamiento paralelo que la arquitectura de plugins de Webpack dificultaba. Esa ventaja de velocidad se traslada también a las compilaciones de producción.
Lo Que V-Next Hace Con ISR
ISR es una de las funcionalidades más poderosas de Next.js y también la más difícil de portar a un runtime diferente. La implementación original de ISR en Next.js usa el sistema de archivos — escribe las páginas regeneradas en disco en el servidor, las sirve y revalida en segundo plano.
Cloudflare Workers no tiene sistema de archivos. Tiene Cloudflare KV — un almacén de clave-valor distribuido globalmente con velocidades de lectura a nivel de edge.
La implementación de ISR de V-Next usa KV como capa de almacenamiento. Las páginas se escriben en almacenes KV, se sirven desde ahí y se revalidan en el intervalo configurado. El comportamiento desde la perspectiva del desarrollador es el mismo. La implementación por debajo está adaptada a las restricciones del runtime de Workers.
Esto es en realidad una buena combinación. Las lecturas de KV en el edge son rápidas. La naturaleza distribuida globalmente de KV significa que las páginas con ISR están disponibles cerca de los usuarios en las más de 300 ubicaciones de centros de datos de Cloudflare sin configuración adicional. En Vercel, ISR requiere un comportamiento específico de caché en el edge que configuras por ruta. En V-Next con Cloudflare, la distribución es una propiedad de la capa de almacenamiento en sí.
Lo Que V-Next Significa Si Estás Construyendo Algo Hoy
Antes de empezar a migrar nada: V-Next es experimental. Cloudflare ha sido claro al respecto, y es el enfoque correcto. Varias aplicaciones reales están ejecutándose en producción — incluyendo CIO.gov, lo cual es un respaldo significativo — pero los casos extremos son reales.
Esto es lo que aún no funciona completamente:
Las analíticas de Open Graph en edge runtime no se portan limpiamente. Si dependes de ellas para vistas previas de compartido social en configuraciones específicas, prueba antes de comprometerte.
Los bindings de blobs en KV y los bindings de Postgres tienen limitaciones. V-Next usa las primitivas de almacenamiento de Cloudflare, y los patrones complejos de integración con bases de datos que funcionan en un entorno Node.js chocan con las restricciones del runtime de Workers. Prisma con conexiones directas a Postgres, por ejemplo, requiere Hyperdrive (el servicio de proxy de base de datos de Cloudflare) para funcionar correctamente.
Turbopack no está integrado. Si has adoptado Turbopack para la velocidad de desarrollo local, en V-Next estás usando Vite — que es rápido, pero es una herramienta diferente y algunas configuraciones específicas de Turbopack no se trasladarán.
El scaffolding de Create Next App no tiene un equivalente en V-Next todavía. Estás configurando proyectos manualmente o adaptando configuraciones existentes.
Algunas API específicas de Vercel de las que Next.js depende silenciosamente no existen en V-Next. Si estás usando @vercel/og, @vercel/analytics, o paquetes similares proporcionados por Vercel que se integran con los internos de Next.js, estos necesitan alternativas.
Proyectos donde V-Next tiene sentido ahora mismo:
Si estás empezando un proyecto nuevo y planeas desplegarlo en Cloudflare Workers de todos modos, V-Next merece consideración seria. Obtienes la superficie de API de Next.js que ya conoces, compilaciones más rápidas, bundles más pequeños, y no heredas las restricciones de Webpack.
Si estás en Vercel y los costos son un punto de presión, vale la pena hacer benchmarks. El modelo de precios de Cloudflare (el ancho de banda es más barato, el cómputo en el edge es más económico para ciertos patrones de uso) puede hacer que la economía sea significativamente diferente a escala.
Si estás ejecutando un sitio de contenido con alto tráfico y uso intensivo de ISR, el enfoque respaldado por KV tiene ventajas reales para el rendimiento de lectura global.
Proyectos para los que conviene esperar por ahora:
Las aplicaciones complejas de Next.js que usan muchas funcionalidades específicas de Vercel o dependen de patrones avanzados de API de Node.js van a chocar con muros de compatibilidad. La superficie de migración es demasiado grande para software experimental.
Aplicaciones con requisitos estrictos de estabilidad. Los sistemas críticos de producción no pertenecen en frameworks experimentales a menos que tengas una capacidad de ingeniería seria para manejar lo inesperado.
Las Partes de Esto Que Deberían Incomodarte
Reacción honesta: V-Next me impresionó. El enfoque técnico es sólido, los números de rendimiento son reales, y la metodología de desarrollo asistida por IA representa algo genuinamente nuevo sobre cómo se pueden construir frameworks.
Y: no estoy seguro de que Cloudflare sea el héroe de esta historia.
Vercel construyó Next.js. Lo publicaron como código abierto, lo mantuvieron, financiaron su desarrollo durante años. Cloudflare usó esa superficie de código abierto — específicamente la suite de pruebas que el equipo de Vercel invirtió un esfuerzo enorme en construir — para crear un producto competidor. Eso es legalmente correcto. Es lo que permite el código abierto. Pero vale la pena nombrar lo que es: Cloudflare se benefició directamente de la inversión de Vercel para competir con la plataforma de Vercel.
El problema de la dependencia de proveedor tampoco desaparece. Se reubica. V-Next está diseñado para Cloudflare Workers. ISR se ejecuta en Cloudflare KV. Los assets se sirven desde Cloudflare R2. Si adoptas V-Next, no estás atado a Vercel — estás atado a Cloudflare. La dependencia simplemente cambió de manos.
Mi opinión impopular: eso podría ser el intercambio correcto para muchos equipos. Cloudflare es propietaria de su infraestructura de punta a punta — centros de datos, cómputo, ancho de banda, almacenamiento. Esa integración vertical es una ventaja real para la predictibilidad de precios y la optimización del rendimiento. Vercel está construyendo sobre AWS, lo que añade una capa a la estructura de costos. Pero los desarrolladores deberían entrar con los ojos bien abiertos sobre lo que realmente significa "escapar de la dependencia de proveedor" aquí.
También hay un panorama estratégico más amplio que vale la pena tener en mente. Cloudflare adquirió Astro — otro framework frontend popular — antes en esta línea temporal. V-Next es parte de un patrón: Cloudflare ya no solo vende infraestructura. Están construyendo una plataforma de desarrollo full-stack con opiniones definidas que compite con Vercel a través de múltiples frameworks simultáneamente. El estado final hacia el que están trabajando es uno donde todo el ecosistema de despliegue frontend — framework, herramientas de compilación, CDN, almacenamiento, cómputo — vive dentro de la superficie de producto de Cloudflare.
Eso no es inherentemente malo para los desarrolladores. La competencia entre Vercel y Cloudflare por la experiencia del desarrollador va a empujar a ambas plataformas a mejorar. Pero vale la pena reconocer la estructura de incentivos detrás de V-Next. Esta es una jugada de adquisición de clientes, no una contribución filantrópica al ecosistema de frameworks. Cloudflare quiere el tráfico, la retención y el cómputo facturable que viene con ejecutar tus aplicaciones de producción. V-Next es el medio técnico para ese fin comercial.
Entender eso no hace peor a V-Next. Solo clarifica el lente a través del cual Cloudflare tomará decisiones sobre su desarrollo futuro. Las funcionalidades que te mantengan en la infraestructura de Cloudflare serán priorizadas. Las funcionalidades de portabilidad que faciliten irse no lo serán.
La historia del desarrollo asistido por IA también necesita un encuadre cuidadoso. Un ingeniero + IA + una semana es notable. También es un ingeniero que entendía Next.js profundamente, entendía Cloudflare Workers profundamente, y podía evaluar el resultado generado por IA con precisión. La IA comprimió el cronograma de implementación. La experiencia humana determinó si el resultado comprimido era correcto. Ambas partes de esa ecuación importan.
Lo Que Los Números Realmente Muestran
Permíteme ser concreto sobre lo que está demostrado y lo que aún se está estableciendo.
Tiempos de compilación 4 veces más rápidos: medidos contra proyectos reales, no aplicaciones de juguete. Si tu pipeline de CI está gastando 8-12 minutos en compilaciones de Next.js, estás viendo compilaciones de menos de 3 minutos con V-Next. Eso se acumula en un equipo — menos cambios de contexto esperando compilaciones, retroalimentación de CI más rápida, más iteraciones por día.
Bundles 57% más pequeños: esto es significativo para el Time to Interactive, especialmente en móvil. Una reducción del 57% en el tamaño del bundle se traduce directamente en cargas de página más rápidas en conexiones limitadas. Para sitios de contenido, esto afecta tanto la experiencia de usuario como las puntuaciones de Core Web Vitals.
CIO.gov ejecutando V-Next en producción: un sitio del gobierno de EE.UU. con tráfico real y requisitos reales de cumplimiento ejecutando software experimental es una señal significativa. Los equipos de TI gubernamentales no toman riesgos a la ligera. El hecho de que migraron es un dato.
Lo que aún no está establecido: la estabilidad a largo plazo bajo patrones de carga complejos, la superficie completa de compatibilidad a lo largo de la diversidad real del uso de Next.js en bases de código en producción, y la trayectoria de mantenimiento una vez que V-Next alcance las versiones actuales de Next.js.
Rastrea estas métricas si estás probando V-Next: tiempo de compilación (los logs de CI te dan esto inmediatamente), tamaño del bundle (los informes de salida de compilación de Cloudflare reportan esto), y Time to Interactive (Lighthouse o WebPageTest contra producción). Esos tres números te dicen si las ventajas teóricas se están manifestando en tu aplicación específica.
Una nota práctica: configura primero un despliegue en paralelo. Ejecuta V-Next junto con tu despliegue existente en Vercel en rutas no críticas antes de hacer el cambio completo. Esto te da benchmarks con tráfico real sin riesgo en producción. Las brechas de compatibilidad que importan para tu proyecto específico aparecerán rápidamente bajo condiciones reales — mucho más confiablemente de lo que cualquier prueba interna puede revelar. Dos semanas de tráfico en paralelo con tus patrones reales de usuarios valen más que cualquier comparación de benchmarks del proyecto de otra persona.
La Parte Que Vale la Pena Reflexionar
Un ingeniero y un modelo de IA reconstruyeron un framework frontend importante en siete días, y el resultado se ejecuta en producción en sitios reales incluyendo un dominio gubernamental.
Eso no es un benchmark. Es una prueba de concepto de cómo se puede construir software complejo.
La suite de pruebas de Next.js actuó como la especificación. La IA actuó como el motor de implementación. La experiencia humana actuó como la puerta de calidad. Esa división del trabajo va a aparecer en más proyectos de software en los próximos 18 meses — no solo reconstrucciones de frameworks, sino migraciones complejas, ports de librerías, y reimplementaciones de API donde el comportamiento correcto ya está definido pero el trabajo de implementación es prohibitivo.
La pregunta interesante no es si Cloudflare puede terminar V-Next. Tienen la capacidad de ingeniería y el motivo de infraestructura. La pregunta interesante es qué se reconstruye después, por quién, y qué hace eso a la suposición de que el software complejo requiere equipos de personas durante largos períodos de tiempo.
Si un framework puede ser reconstruido en una semana, ¿qué más se puede?
Esa es la pregunta que V-Next realmente está haciendo. La respuesta va a transformar cómo pensamos sobre el costo y el ritmo del trabajo de ingeniería ambicioso — y como alguien que construye profesionalmente con agentes de IA, esa pregunta es significativamente más emocionante para mí que cualquier número de benchmark.
🤝 Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- 🔗 Fiverr (desarrollos e integraciones personalizadas): fiverr.com/s/EgxYmWD
- 🌐 Portafolio: mejba.me
- 🏢 Ramlit Limited (soluciones empresariales): ramlit.com
- 🎨 ColorPark (diseño y branding): colorpark.io
- 🛡 xCyberSecurity (servicios de seguridad): xcybersecurity.io
