![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/06\/image-4.png\")
<\/figure>\n\n\n\nLos frameworks que sobrevivan a los pr\u00f3ximos cinco a\u00f1os ser\u00e1n aquellos que est\u00e9n redise\u00f1ando sus convenciones tambi\u00e9n para este nuevo usuario. No deben sustituir al humano, sino permitir que agente e ingeniero trabajen juntos. El punto central de este art\u00edculo es que el framework, en la era agentica, deja de ser una \u201ccomodidad para quien escribe c\u00f3digo\u201d y se convierte en algo estructuralmente distinto: una capa de compresi\u00f3n cognitiva entre la intenci\u00f3n (humana o del agente) y la m\u00e1quina.<\/p>\n\n\n\n
De DX a ADX<\/h2>\n\n\n\n
Durante a\u00f1os, la m\u00e9trica dominante ha sido la Developer Experience (DX para los amigos): tiempo de setup, ergonom\u00eda de las APIs, calidad de los errores, hot reload, autocompletado. Era una m\u00e9trica calibrada para un cerebro humano leyendo c\u00f3digo pieza a pieza.<\/p>\n\n\n\n
En el \u00faltimo a\u00f1o (m\u00e1s o menos), est\u00e1 emergiendo una m\u00e9trica paralela que, a falta de mejor nombre, podemos llamar Agent Developer Experience (ADX). \u00bfQu\u00e9 es la ADX?<\/p>\n\n\n\n
Se refiere a lo f\u00e1cil que es, para un agente de IA:<\/p>\n\n\n\n
- \n
- navegar una codebase<\/li>\n\n\n\n
- entender qu\u00e9 modificar<\/li>\n\n\n\n
- hacer la modificaci\u00f3n correcta al primer intento<\/li>\n\n\n\n
- no romper aquello que no ve o que todav\u00eda no \u201cconoce\u201d<\/li>\n<\/ul>\n\n\n\n
La ADX no es lo opuesto a la DX: es su derivada, si queremos usar t\u00e9rminos matem\u00e1ticos. Las caracter\u00edsticas que hacen que un c\u00f3digo sea legible para un humano competente (convenciones estables, dependencias expl\u00edcitas, tipos end-to-end, side effects localizados) son las mismas que lo hacen manipulable por un LLM. Pero con una diferencia de escala: cuando el c\u00f3digo se genera en masa, incluso peque\u00f1as ambig\u00fcedades se amplifican en errores enormes y poco controlables.<\/p>\n\n\n\n
Seguro que lo hab\u00e9is visto: empiezas con una petici\u00f3n simple como \u201ccr\u00e9ame un hook de React\u201d y, veinte minutos despu\u00e9s, est\u00e1s perdido entre tests, linters que no pasan y un \u201cspaghetti code\u201d indescifrable.<\/p>\n\n\n\n
Los frameworks modernos est\u00e1n respondiendo a esta presi\u00f3n de forma bastante coherente: file-based routing, server components, typed routing\u2026 Son todas respuestas al mismo problema: reducir la variabilidad del output. Hacer que, para una intenci\u00f3n dada, exista un n\u00famero reducido de soluciones plausibles, idealmente una sola.<\/p>\n\n\n\n
La tesis de la compresi\u00f3n cognitiva<\/h2>\n\n\n\n
Para entender por qu\u00e9 esta convergencia no es casual, conviene dar un paso atr\u00e1s. Un sistema software complejo se caracteriza por la entrop\u00eda de decisiones que deben tomar quienes trabajan en \u00e9l:<\/p>\n\n\n\n
- \n
- \u00bfD\u00f3nde va ese componente?<\/li>\n\n\n\n
- \u00bfC\u00f3mo se hace fetch de datos?<\/li>\n\n\n\n
- \u00bfD\u00f3nde empieza el servidor?<\/li>\n\n\n\n
- \u00bfC\u00f3mo se declara una ruta?<\/li>\n<\/ul>\n\n\n\n
Cada pregunta admite m\u00faltiples respuestas t\u00e9cnicamente equivalentes, pero cognitivamente costosas.<\/p>\n\n\n\n
Un framework opinionado responde a estas preguntas antes de que se formulen. Reduce la varianza. Comprime el espacio de decisiones. Para un equipo humano esto es ergonom\u00eda. Para un agente de IA es algo m\u00e1s cr\u00edtico: es la condici\u00f3n para que su output sea verificable.<\/p>\n\n\n\n
Repit\u00e1moslo como un mantra: un LLM no \u201ccomprende\u201d el c\u00f3digo en sentido fuerte. Un LLM razona sobre patrones, sobre distribuciones estad\u00edsticas de tokens, sobre estructuras sint\u00e1cticas aprendidas durante el entrenamiento. Un LLM funciona mejor donde las estructuras est\u00e1n m\u00e1s representadas y son m\u00e1s estables.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/06\/image-5.png\")
<\/figure>\n\n\n\nUn App Router de Next.js, con su jerarqu\u00eda
app\/[segment]\/page.tsx<\/code>, es f\u00e1cil de representar para un modelo: a una ruta URL le corresponde un archivo, a un layout otro archivo, a un loading state otro m\u00e1s. Una SPA en React con react-router configurado manualmente en unApp.tsx<\/code>, con lazy imports dispersos y providers anidados, obliga al modelo a reconstruir un mapa que el framework ha decidido no imponer. El primer caso es legible. El segundo debe interpretarse.<\/p>\n\n\n\nLa diferencia, en producci\u00f3n, no es te\u00f3rica: <\/strong>se mide en el n\u00famero de archivos que el agente toca para implementar una feature, en la probabilidad de modificar el archivo correcto a la primera, y en la cantidad de c\u00f3digo que el senior tiene que reescribir durante el review.<\/p>\n\n\n\n
Anatom\u00eda de un framework \u201cAI-native\u201d<\/h2>\n\n\n\n
Ahora que hemos aclarado qu\u00e9 es la ADX y por qu\u00e9 es relevante, podemos analizar cinco caracter\u00edsticas que est\u00e1n emergiendo como patrones comunes en frameworks adaptados a la era agentica.<\/p>\n\n\n\n
Convenciones basadas en archivos comprensibles sin documentaci\u00f3n<\/h3>\n\n\n\n
Next.js App Router, \u00a0Nuxt<\/a>,\u00a0SvelteKit<\/a>,\u00a0SolidStart<\/a>,, Astro, \u00a0Qwik City<\/a>,\u00a0TanStack Start<\/a>:\u00a0: todos convergen en sistemas de ficheros donde la posici\u00f3n del archivo es informaci\u00f3n en s\u00ed misma. No es un detalle est\u00e9tico: es una API legible sin necesidad de manual (humano o m\u00e1quina). Una codebase con
app\/dashboard\/[id]\/page.tsx<\/code> yapp\/dashboard\/[id]\/layout.tsx<\/code> explica su arquitectura sin README.<\/p>\n\n\n\nReactividad expl\u00edcita, no m\u00e1gica<\/h3>\n\n\n\n
Los frameworks compiler-first (como Svelte) tienen una ventaja estructural: el c\u00f3digo se traduce de forma formal y determinista. Las runes de Svelte 5 y los signals de Solid o Angular son modelos declarativos de reactividad: no dependen del orden de ejecuci\u00f3n (como los hooks de React) ni de reglas de linting para ser correctos.<\/p>\n\n\n\n
Para un LLM que modifica reactividad, la diferencia es enorme. Un closure stale en un
useEffect<\/code> es un bug cl\u00e1sico que los agentes siguen reproduciendo. Una rune declarada con$state<\/code> es casi imposible de romper de la misma forma. Es precisamente este tipo de previsibilidad lo que la memoizaci\u00f3n intenta recuperar a nivel de compilador.<\/a><\/p>\n\n\n\n\n
Optimiza autom\u00e1ticamente tu aplicaci\u00f3n React gestionando la memorizaci\u00f3n por ti, eliminando la necesidad de usar manualmente
useMemo<\/code>,useCallback<\/code> yReact.memo<\/code>.<\/p>\n<\/blockquote>\n\n\n\nTipos end-to-end<\/h3>\n\n\n\n
TanStack Router<\/a> ha convertido el routing tipado en una caracter\u00edstica de primera clase: par\u00e1metros de ruta, search params y loaders son tipos que fluyen a trav\u00e9s de la app. Next.js est\u00e1 llegando a lo mismo por otra v\u00eda, con typed routes<\/a> y Server Actions tipadas en el boundary.<\/p>\n\n\n\n
Para un agente, el tipado end-to-end es una red de seguridad que evita toda una clase de outputs plausibles pero incorrectos.<\/p>\n\n\n\n
Server boundaries expl\u00edcitos<\/h3>\n\n\n\n
Los React Server Components, las Server Actions de Next.js y React Router 7, los loaders\/actions de TanStack Start, o los
+page.server.ts<\/code> de SvelteKit son intentos de hacer visible d\u00f3nde termina el cliente y d\u00f3nde empieza el servidor.<\/p>\n\n\n\nSin esta declaraci\u00f3n, cada componente es potencialmente todo a la vez. Un agente que genera c\u00f3digo debe adivinar. Con esta separaci\u00f3n expl\u00edcita, el problema desaparece.<\/p>\n\n\n\n
Metadatos estructurados e introspecci\u00f3n<\/h3>\n\n\n\n
Astro Content Collections con schema Zod,<\/a> frontmatter tipado, manifiestos de build, route manifests\u2026 Son formas de exponer la estructura de la app en formato legible por m\u00e1quinas. Aqu\u00ed entra MCP (Model Context Protocol)<\/a>, que se est\u00e1 convirtiendo en est\u00e1ndar de facto para exponer contexto y capacidades a agentes. Un servidor MCP que publica rutas, layouts y server functions de una app Next.js marca la diferencia entre un agente que hace grep y uno que hace queries estructuradas.<\/p>\n\n\n\n
Framework por framework, sin fanatismos<\/h2>\n\n\n\n
Vale la pena ver algunos ejemplos. Para cada uno se explora el mismo caso m\u00ednimo (una ruta que obtiene una lista de usuarios desde una API y la renderiza), porque es la forma m\u00e1s honesta de comparar c\u00f3mo se adaptan al ADX.<\/p>\n\n\n\n
La pregunta impl\u00edcita es siempre la misma: si a un agente le pido \u201ca\u00f1ade una p\u00e1gina \/users que liste usuarios\u201d, \u00bfcu\u00e1ntas decisiones tiene que tomar por s\u00ed solo y cu\u00e1l es la probabilidad de que las tome bien?<\/p>\n\n\n\n
Next.js (App Router)<\/h3>\n\n\n\n
Next.js es el ejemplo m\u00e1s claro de framework que se est\u00e1 transformando en protocolo. App Router, Server Actions, integraci\u00f3n nativa con el AI SDK de Vercel, soporte creciente de MCP, generadores como v0 que producen directamente c\u00f3digo Next.js: es un sistema donde las decisiones de runtime, build, edge y data fetching est\u00e1n predefinidas para un modelo mental concreto.<\/p>\n\n\n\n
La contrapartida es la concentraci\u00f3n: elegir Next.js significa adoptar, en gran medida, la visi\u00f3n de Vercel sobre el futuro de la web. <\/strong>Para muchos equipos es un trade-off razonable. Para otros, es una preocupaci\u00f3n leg\u00edtima, y el debate sobre React Server Components fuera del ecosistema Next es un s\u00edntoma evidente de ello.<\/p>\n\n\n
\/\/ app\/users\/page.tsx <strong>export<\/strong> <strong>default<\/strong> <strong>async<\/strong> <strong>function<\/strong> <strong>UsersPage<\/strong>() { <strong>const<\/strong> users = <strong>await<\/strong> fetch('https:\/\/api.example.com\/users') .then((r) => r.json()) <strong>return<\/strong> ( <<strong>ul<\/strong>> {users.map((u) => <<strong>li<\/strong> key={u.id}>{u.name}<\/<strong>li<\/strong>>)} <\/<strong>ul<\/strong>> ) }<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\nADX: la ruta del archivo es la URL, el componente es server-side por defecto (es un async server component), el fetch no requiere useEffect, ni react-query, ni un store. Un agente que recibe \u201ca\u00f1ade una p\u00e1gina \/users que liste los usuarios\u201d sabe exactamente d\u00f3nde crear el archivo, qu\u00e9 firma usar y que el fetch es server-side sin tener que tomar decisiones. El espacio de soluciones plausibles es min\u00fasculo.<\/p>\n\n\n\n
Modificar la p\u00e1gina para a\u00f1adir cach\u00e9, streaming o revalidaci\u00f3n requiere tocar el mismo archivo con primitivas bien conocidas (fetch con next.revalidate, , revalidatePath). Alta densidad de convenci\u00f3n por l\u00ednea de c\u00f3digo.<\/p>\n\n\n\n
React sin framework<\/h2>\n\n\n\n
React \u201cpuro y duro\u201d es la posici\u00f3n que la era agentica est\u00e1 penalizando m\u00e1s. No porque React sea obsoleto, sino porque la combinaci\u00f3n \u201cReact + Vite + react-router + tanstack-query + zustand + librer\u00eda de formularios + librer\u00eda de tablas\u201d es una colecci\u00f3n de decisiones locales \u00f3ptimas que no se comunican entre s\u00ed.<\/p>\n\n\n\n
Cada proyecto es casi artesanal.<\/strong> Cada agente, frente a uno de estos proyectos, tiene que reconstruir convenciones que no existen (o que est\u00e1n en la cabeza del desarrollador que cre\u00f3 el proyecto) y trabajar con \u201clo que hay\u201d.<\/p>\n\n\n
\/\/ src\/App.tsx <strong>import<\/strong> { BrowserRouter, Routes, Route } <strong>from<\/strong> 'react-router-dom' <strong>import<\/strong> { QueryClient, QueryClientProvider, useQuery } <strong>from<\/strong> '@tanstack\/react-query' <strong>const<\/strong> qc = <strong>new<\/strong> QueryClient() <strong>function<\/strong> <strong>UsersPage<\/strong>() { <strong>const<\/strong> { data, isLoading } = useQuery({ queryKey: ['users'], queryFn: () => fetch('\/api\/users').then((r) => r.json()), }) <strong>if<\/strong> (isLoading) <strong>return<\/strong> <<strong>div<\/strong>>Loading\u2026<\/<strong>div<\/strong>> <strong>return<\/strong> <<strong>ul<\/strong>>{data.map((u: any) => <<strong>li<\/strong> key={u.id}>{u.name}<\/<strong>li<\/strong>>)}<\/<strong>ul<\/strong>> } <strong>export<\/strong> <strong>default<\/strong> <strong>function<\/strong> <strong>App<\/strong>() { <strong>return<\/strong> ( <<strong>QueryClientProvider<\/strong> client={qc}> <<strong>BrowserRouter<\/strong>> <<strong>Routes<\/strong>> <<strong>Route<\/strong> path=\"\/users\" element={<UsersPage \/>} \/> <\/<strong>Routes<\/strong>> <\/<strong>BrowserRouter<\/strong>> <\/<strong>QueryClientProvider<\/strong>> ) }<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\nADX<\/strong>: nada est\u00e1ndar. El agente tiene que descubrir por s\u00ed mismo d\u00f3nde est\u00e1n declaradas las rutas (\u00bfun componente en alg\u00fan sitio? \u00bfun archivo routes.ts? \u00bfimports lazy?), qu\u00e9 fetcher se est\u00e1 usando (\u00bfreact-query? \u00bfswr? \u00bffetch directo? \u00bfun cliente API personalizado?), d\u00f3nde viven los providers, si hay SSR. Cada decisi\u00f3n es arbitraria, cada proyecto es distinto. La probabilidad de que el agente genere c\u00f3digo \u201cplausible pero incoherente con el resto\u201d es alta, y crece con el tama\u00f1o del repositorio.<\/p>\n\n\n\n
La verdadera pregunta que hay que hacerse en 2026 ya no es \u201cqu\u00e9 librer\u00eda de UI\u201d, sino \u201cqu\u00e9 framework alrededor de React\u201d.<\/p>\n\n\n\n
Angular<\/h2>\n\n\n\n