Cuatro frameworks vistos por un agente

En algún momento de este año la pregunta «qué framework uso» cambió de significado para mí sin hacer ruido. La mayor parte del código de mis proyectos lo escriben ahora agentes. Yo describo, reviso y dirijo; ellos teclean. Y un framework que es un placer para una persona no es necesariamente uno en el que un agente pueda trabajar. Un agente no recuerda la documentación de diez años de práctica. La lee, ahora mismo, página a página, y después acierta con la funcionalidad o no.

Así que monté un experimento pequeño. Un producto, una plataforma de clubes de lectura: cuentas, clubes, reuniones, debates, correo, algo de actualización en vivo. Una especificación. Cuatro frameworks: Ruby on Rails, Next.js, Go con Gin y Django. Los agentes construyeron. Yo me senté al lado y apunté dónde se atascaban.

Dónde vive la documentación

La primera sorpresa llegó antes de la primera línea de código. Para una persona, la documentación es un sitio web. Para un agente, un sitio web es una serie de peticiones de red, cada una a una página que puede describir o no la versión instalada.

Next.js resultó ser el único que trae la documentación con el paquete: varios cientos de páginas Markdown dentro de node_modules, la versión exacta, más un AGENTS.md, un llms.txt y un servidor MCP dentro del servidor de desarrollo. El agente abrió la carpeta y leyó. Sin adivinar para qué versión estaba escrita la página.

Django tiene la referencia más grande de las cuatro, con diferencia, pero se esconde en el archivo fuente de PyPI. Una instalación normal no la trae, así que el agente tiene que saber que debe ir a buscarla. Rails tiene medio centenar de guías, todas en la web, nada en la gema. Gin tiene un sitio pequeño, en parte desactualizado, y un enlace a llms.txt que devuelve 404. Lo que go doc te da en local es la API, no cómo encajan las piezas.

Qué viene en la caja

Después empezó la construcción, y apareció un segundo patrón: cuánto del producto contiene ya el framework.

Ver trabajar al agente de Rails era casi aburrido. Base de datos, migraciones, formularios, sesiones, tareas en segundo plano, correo en ambas direcciones, WebSockets, campos cifrados: todo lo que el producto necesitaba en el servidor ya estaba ahí, y el agente adivinaba el sitio correcto para cada pieza antes de leer nada. Para todo el backend tiró de dos librerías de terceros.

El agente de Django lo pasó parecido en el servidor, hasta que llegó a la interfaz. En Django no hay Turbo, así que las actualizaciones parciales de página y cualquier cosa interactiva hubo que escribirlas a mano.

El agente de Next.js vivió la imagen especular. Las herramientas de frontend son las mejores de las cuatro, desde imágenes y fuentes hasta actualizaciones optimistas y modales con su propia URL. El backend, en cambio, se montó con una docena de librerías, cada una con su documentación, cada una una cosa más que hacer ligeramente mal.

El agente de Go escribió más código que nadie. Gin es un router HTTP; CSRF, sesiones, mensajes flash y plantillas de layout hubo que escribirlos desde cero. La librería estándar cubre mucho por sí sola, criptografía, correo, plantillas, pero a trozos, sin el pegamento.

Qué tan rápido descubres que te equivocaste

Lo tercero que observé fue el ciclo: cambiar algo, ejecutar las comprobaciones, ver el resultado. Para un agente ese ciclo lo es todo, porque el agente no tiene la sensación de que algo va mal. Solo tiene el resultado de una prueba.

Rails y Django ejecutan toda su batería de pruebas en unos tres segundos, directamente contra el código del servidor, sin navegador. Go tarda siete, o setenta si le pides que busque carreras de datos. Next.js tarda veinticinco, porque las server actions y los server components no se pueden ejecutar fuera de un navegador, así que quedan las pruebas end-to-end. Diez veces más lento, y muchas menos pruebas. Para un agente es la diferencia entre comprobar cada cambio y comprobar uno de cada diez.

Las trampas

Cada framework tuvo un par de sitios donde la documentación y la realidad no coinciden, y un agente se fía de la documentación más que una persona.

Un ejemplo de una guía de Rails llama a un método que no existe. Los generadores de Rails sobrescriben archivos en silencio cuando no hay terminal, que es justo como los ejecuta un agente. En Next.js, una respuesta en streaming vuelve como 200 donde debería haber sido 401 o una redirección, y el ejemplo de CSP de la guía rompe la build de producción. El streaming de Gin se cae en las pruebas que su propia documentación recomienda, y un error de plantilla se sirve como página en blanco con estado 200. En Django, los límites del nuevo DB_CASCADE solo aparecen en los system checks, y serialized_rollback rompe en silencio las pruebas vecinas.

El agente de Go gastó uno de cada cinco minutos en cosas así: comportamiento no documentado de Gin y de las librerías de alrededor. El de Django, la mitad, y solo en las funcionalidades más nuevas, porque la referencia describe el comportamiento con suficiente precisión como para que rara vez tengas que descubrirlo ejecutando.

El marcador

Puntué cada framework en diez cosas que le importan a un agente: dónde está la documentación y si los ejemplos funcionan, qué tan completo y previsible es el framework, qué viene integrado, herramientas, mensajes de error, facilidad de prueba, actualizaciones y trampas ocultas. Sobre diez, Django quedó en 8,0, Rails en 7,8, Next.js en 6,1 y Go con Gin en 6,05.

La diferencia entre Django y Rails es ruido. La diferencia entre esos dos y los otros dos, no. Django gana por precisión y herramientas; los ejemplos funcionan tal como están escritos y check --deploy caza errores de configuración antes de que lo haga producción. Rails gana por lo integrado y lo previsible. Next.js tiene la mejor entrega de documentación y lo más flojo en todo lo demás en cuanto sales del navegador.

La imagen a la que siempre vuelvo es esta.

Qué elegiría

Si el trabajo lo hace un agente, la elección ya no va de gustos.

• Un backend rico con una UI simple: Django. Documentación precisa, comprobaciones de tres segundos.
• Un producto full-stack con interfaz interactiva: Rails. Todo integrado por ambos lados, y el agente siempre sabe dónde va cada cosa.
• Una interfaz compleja sobre una API existente: Next.js. En frontend nada se le acerca.
• Un servicio de API con mucha carga: Go con Gin. Tipos estrictos y un solo binario, pero prepárate para escribir tú la capa de aplicación.

Mi opción por defecto sigue siendo Rails, y este experimento me dejó más tranquilo con eso, no menos. Pero Django se ganó mucho respeto, y la próxima vez que un producto sea casi todo servidor y apenas interfaz, probablemente dejaré que un agente lo construya ahí.

El informe completo con todos los gráficos está en pages.bgmlv.com/rails-vs-nextjs, en ruso. Versiones, para que conste: Rails 8.1, Next.js 16, Gin 1.12 sobre Go 1.27, Django 6.1, PostgreSQL debajo de los cuatro.