Un ingeniero de Cloudflare y un modelo de lenguaje reimplementaron el API surface de Next.js sobre Vite en cinco días; el experimento reabre el debate sobre qué significa 'construir software' en 2026.
Un ingeniero de Cloudflare usó IA para reimplementar el 94% del API surface de Next.js 16 sobre Vite en cinco días laborales, generando bundles 57% más pequeños y builds 4x más rápidos en pruebas iniciales.
En febrero de 2026, Cloudflare publicó un post de blog que desató un debate sobre qué significa construir software en la era de la IA: un solo ingeniero, con un modelo de lenguaje como asistente de programación, reimplementó desde cero la superficie de API de Next.js sobre Vite en aproximadamente una semana de trabajo. El proyecto se llama vinext, está publicado en GitHub bajo licencia MIT y tiene más de 1.700 tests de Vitest y 380 tests de Playwright de end-to-end. El costo total fue USD 1.100 en tokens de API. Cloudflare publicó el blog post en febrero, y el proyecto fue redescubierto y amplificado esta semana por Pragmatic Engineer y LogRocket. Los números de rendimiento son llamativos: en una aplicación de 33 rutas, vinext compila en producción en 1,67 segundos usando Vite 8 con el bundler Rolldown, frente a 7,38 segundos de Next.js 16 con Turbopack —una mejora de 4,4x. Los bundles cliente son 72,9 KB comprimidos frente a 168,9 KB de Next.js, una reducción del 57%. Cloudflare atribuye ambas mejoras a la arquitectura de Rolldown (el bundler Rust que sucede a Rollup en Vite 8) y a un modelo de SSR más simple que el de Next.js 16. El ángulo contrario es el más importante: vinext cubre el 94% del API de Next.js y tiene cero minutos de tráfico de producción real. Next.js 16 tiene cinco años de uso en miles de aplicaciones y maneja casos extremos —internacionalización compleja, middleware de rewrite, cachés de ISR con invalidación parcial— que el test suite de vinext no cubre. El ingeniero de Cloudflare lo deja claro en el blog: «esto no es un reemplazo de producción; es una prueba de concepto sobre la velocidad a la que se puede construir software hoy». Para equipos de desarrollo costarricenses que evalúan migrar proyectos Next.js, la recomendación es monitorear vinext durante los próximos seis meses antes de cualquier decisión.
El compilador nativo de TypeScript escrito en Go ya pasa más del 95% del test suite existente; los gaps restantes son casos extremos de emit modes legacy que el equipo de Microsoft tiene en la hoja de ruta de julio.
El equipo de TypeScript en Microsoft publicó el 30 de abril una actualización del estado de Project Corsa —el port del compilador TypeScript a Go— confirmando que tsgo supera el 95% del test suite oficial de TypeScript. Los brechas restantes se concentran en tres áreas: el modo de emit legacy (--module commonjs con decoradores de TypeScript 4.x), las transformer APIs que usan algunos plugins de herramientas de construcción, y el soporte de metadata para decoradores en modo experimental. El equipo apunta a cerrar estas brechas antes de julio para lanzar las primeras versiones beta públicas de TypeScript 7.0. TypeScript 6.0, publicado el 23 de marzo como versión de transición, introdujo las APIs de compatibilidad entre el compilador antiguo en JavaScript y tsgo, permitiendo que proyectos que usan el type checking de TypeScript (sin emit de JavaScript) puedan ya beneficiarse de la velocidad de tsgo en sus pipelines de CI. La promesa de 10x en velocidad de compilación se confirma en benchmarks: el repositorio de TypeScript-Go en GitHub documenta compilaciones completas del propio repositorio de TypeScript en 1,2 segundos con tsgo, frente a 13 segundos con tsc 5.x. Para los desarrolladores costarricenses que trabajan en proyectos TypeScript grandes —particularmente en empresas de servicios financieros o de software médico donde los repositorios tienen cientos de miles de líneas de código tipado—, la migración a TypeScript 7.0 con tsgo podría reducir los tiempos de CI de manera significativa. El primer paso práctico hoy es instalar `typescript-go` como devDependency experimental y ejecutar `npx tsgo --noEmit` sobre el proyecto para medir la diferencia de velocidad sin riesgo de romper el build.
La coexistencia de Turbopack en el ecosistema Next.js y Rolldown/Vite 8 en el resto del ecosistema JavaScript crea una división práctica que los equipos de plataforma empiezan a gestionar con políticas explícitas.
Vercel reportó esta semana que Turbopack ya impulsa más del 90% de sus deployments de producción, habiendo reemplazado completamente a Webpack en el pipeline de Next.js. Sin embargo, en el ecosistema JavaScript fuera de Next.js —proyectos Vue, SvelteKit, Astro, Remix sin Next y aplicaciones React con Vite—, el bundler dominante sigue siendo Vite, que con el lanzamiento de Vite 8 y el bundler nativo Rolldown en Rust registra velocidades de HMR de 60 milisegundos en proyectos medianos. LogRocket documentó en su análisis de mayo 2026 que la división práctica es clara: Turbopack para proyectos full-stack con Next.js desplegados en Vercel; Vite 8 + Rolldown para todo lo demás. La decisión de Cloudflare de construir vinext sobre Vite en lugar de sobre Turbopack —siendo Turbopack el bundler más avanzado en el ecosistema React— tiene sentido en este contexto: Vite es más portable y no está acoplado a la infraestructura de Vercel. El ángulo contrario proviene de Dan Abramov, quien publicó el 30 de abril en su blog que la fragmentación de bundlers en el ecosistema JavaScript es «el costo oculto de la innovación sin coordinación»: cada equipo que adopta Vite 8 o Turbopack tiene que mantener configuraciones de desarrollo y producción distintas, gestionar incompatibilidades entre plugins y asumir el riesgo de migraciones en el futuro. Abramov argumenta que el ecosistema necesita un proceso de estandarización similar al que tiene el kernel Linux para los sistemas de archivos. Para los equipos de frontend costarricenses, la recomendación práctica es simple: si ya están en Next.js, quédense con Turbopack; si están en Vite, actualicen a Vite 8.
La estadística que más circuló entre ingenieros de software esta semana no viene de un laboratorio de IA sino de GitHub: en mayo de 2026, el 46% del código en repositorios activos de empresas que usan GitHub Copilot o herramientas equivalentes fue generado total o parcialmente por asistentes de IA. El dato fue publicado el 1 de mayo en el blog de GitHub como parte de su reporte semestral de uso de Copilot. La cifra era del 31% en noviembre de 2025. El salto de 15 puntos porcentuales en seis meses tiene implicaciones prácticas concretas para los procesos de revisión de código. McKinsey publicó en febrero un estudio de 4.500 desarrolladores que encontró que las herramientas de IA reducen el tiempo en tareas de codificación rutinaria en un 46%, pero que el tiempo de revisión de código aumentó proporcionalmente porque los revisores tienen que verificar la corrección de código que el autor original no escribió manualmente ni puede defender con el mismo nivel de familiaridad. El resultado es que la velocidad neta de desarrollo aumentó, pero la deuda técnica en documentación y comprensión del código también aumentó. Para los equipos de desarrollo en Costa Rica —donde empresas multinacionales de software y servicios tecnológicos en Zona Franca adoptan estas herramientas con diferentes niveles de madurez—, la brecha entre equipos que han actualizado sus prácticas de revisión para código generado por IA y los que no es ya visible en la calidad del software entregado. El primer cambio práctico es simple pero frecuentemente omitido: etiquetar en los commits y pull requests qué porcentaje del diff fue generado por IA, para que el revisor pueda calibrar su nivel de escrutinio.
— El umbral del 50% de código escrito por IA está a semanas de cruzarse en los repositorios más activos; los equipos de ingeniería que no han actualizado sus prácticas de code review están operando con herramientas del pasado.
Google I/O 2026 se celebra el 19 de mayo en el Shoreline Amphitheatre y en formato online simultáneo. Los temas centrales confirmados en la agenda preliminar publicada el 2 de mayo son cuatro: Android 17 con sus nuevas APIs de AI-on-device (la versión que ejecuta modelos pequeños directamente en el procesador del teléfono sin conexión a internet); Gemini para desarrolladores con el nuevo modelo de embeddings y las APIs de computer use; Firebase 2.0 como plataforma agent-native con integración nativa de AI Studio; y las novedades de Kotlin 2.2 y Jetpack Compose. Firebase merece atención especial: el equipo de Google transformó la plataforma durante el primer trimestre de 2026 en una infraestructura orientada a agentes de IA, con almacenamiento de estado para sesiones de agentes, funciones de vectores y un SDK de «Antigravity» para desplegar agentes de Gemini directamente desde un proyecto de Firebase sin configuración de infraestructura adicional. El equipo de Firebase anunció el 30 de abril que la integración con AI Studio es nativa en la nueva versión y que el «Firebase Data Connect» —su solución de base de datos relacional para aplicaciones web— sale de beta el mismo día que I/O. Para los desarrolladores costarricenses que trabajan con aplicaciones Android o con infraestructura Firebase —hay varios equipos en empresas de Zona Franca y en startups locales que usan ambas tecnologías—, el I/O del 19 de mayo es el evento más relevante del semestre. Las sesiones de I/O están disponibles gratuitamente en YouTube en español con traducción simultánea desde las 10 a.m. hora de la Costa del Pacífico (12 m. hora Costa Rica).
La noticia de la semana no es un lanzamiento sino una demostración: vinext de Cloudflare muestra que en 2026 un ingeniero con un modelo de lenguaje puede reimplementar el API surface de uno de los frameworks más complejos del ecosistema JavaScript en una semana, por USD 1.100 en tokens. Eso no significa que vinext sea producción-ready ni que Next.js vaya a desaparecer, pero sí significa que el costo marginal de crear alternativas de herramientas de desarrollo ha caído varios órdenes de magnitud. La pregunta que esto abre para las empresas de software —costarricenses y globales— es si tiene sentido seguir pagando licencias de herramientas propietarias cuando las alternativas open source pueden construirse en días. La próxima semana, TypeScript 7.0 Project Corsa tendrá su actualización mensual con el estado de los gaps del test suite, y es posible que se anuncie una fecha concreta para la primera beta pública. El 19 de mayo, Google I/O marcará el primer gran evento de desarrolladores del segundo semestre; los 16 días de aquí allá son una ventana para explorar Firebase 2.0 agent-native antes de que los anuncios del I/O actualicen todo el marco de referencia.