Le hice a Claude una pregunta sencilla: "Si fueras a trabajar en un proyecto web, ¿qué lenguaje y framework escogerías y por qué? No pienses en mí como desarrollador. Piensa en ti como LLM."
No eligió Rails.
La respuesta honesta de un LLM
Claude eligió Python y TypeScript. No porque sean lenguajes mejores, sino porque la calidad de generación de código de un modelo depende mucho de cuántos ejemplos buenos existan en sus datos de entrenamiento.
Python y TypeScript dominan los repositorios de código abierto, Stack Overflow, los tutoriales y la documentación. Cuando un LLM escribe Python o TypeScript, bebe de un pozo enorme de patrones. Se equivoca menos, conoce más casos límite y genera código idiomático con más fiabilidad.
Sobre Rails, Claude dijo algo que debería preocupar a cualquier desarrollador Ruby: "Puedo escribir buen código Rails, pero es más probable que alucine el nombre de un método, use una API obsoleta o pase por alto una convención de Rails 7+. La diferencia no es enorme, pero existe."
Lo veo en mi propio trabajo. Uso Claude Code a diario para construir aplicaciones Rails: productos internos, proyectos propios, herramientas de clientes. La IA es buena con Rails. Pero es claramente mejor con TypeScript. Alucina menos, detecta más casos límite y escribe código más idiomático en los lenguajes donde los datos de entrenamiento son más profundos.
Lo que vuelve productivos a los LLM no es solo el lenguaje, sino lo tipado y explícito que sea el código. TypeScript supera a JavaScript para un modelo porque las anotaciones de tipo actúan como restricciones autoexplicativas. Los frameworks cargados de convenciones, como Rails, son paradójicamente más difíciles para la IA porque hay mucho contexto que el modelo debe recordar, no leer directamente en el código.
Lo vemos cada día
Ruby y Rails nacieron con una filosofía muy clara: optimizar la felicidad del desarrollador. Convención sobre configuración. No repetirse. Hacer que la vida de quien construye sea más sencilla.
Esa filosofía fue perfecta en un mundo donde los humanos escribían cada línea de código. Ese mundo está cambiando deprisa.
Hoy vemos a Claude Code, GitHub Copilot, Cursor, Codex y otras herramientas escribir controladores, modelos, tests, jobs y objetos de dominio. Un porcentaje creciente del código de producción, en proyectos propios y ajenos, lo escriben agentes de IA mientras los desarrolladores pasan a revisar, dirigir y diseñar la arquitectura.
En esta realidad nueva, la felicidad del desarrollador sigue siendo necesaria, pero ya no basta. También importa la fluidez de la IA: hasta qué punto un LLM entiende, genera y razona bien sobre el código de un ecosistema.
Ahora mismo Ruby on Rails va por detrás en esa métrica. No por una carencia técnica del framework, sino por una brecha de datos de entrenamiento.
El problema de los datos de entrenamiento
Los LLM aprenden de lo que han visto. Cuantos más proyectos de código abierto, diversos, bien documentados y de calidad existan en un lenguaje, mejor funciona el modelo con ese lenguaje. Es así de simple.
Mira los ecosistemas JavaScript y Python. Hay miles y miles de proyectos abiertos, tutoriales, entradas de blog y ejemplos. Casi cualquier patrón, caso límite o decisión de arquitectura está documentado y disponible para entrenar modelos.
Ahora mira Ruby on Rails. Tenemos proyectos abiertos excelentes: Discourse, Mastodon, GitLab o Solidus. Más recientemente, 37signals hizo una contribución importante al abrir sus productos ONCE: Campfire, Writebook y Fizzy. Son aplicaciones Rails reales, de producción, creadas por los propios autores del framework. Justo el tipo de código que los LLM necesitan estudiar.
Pero incluso con esas aportaciones, el volumen no se acerca al de JavaScript o Python. Demasiadas aplicaciones Rails siguen siendo privadas, cerradas, invisibles para los conjuntos de entrenamiento.
Eso crea un ciclo peligroso: los LLM funcionan peor con Rails, los desarrolladores que construyen con IA eligen otros stacks, se crean menos proyectos Rails nuevos, hay menos datos de entrenamiento y los modelos se quedan todavía más atrás.
La magia de Rails se convierte en obstáculo para la IA
Las mismas cosas que hacen bonito a Rails para los humanos lo vuelven más difícil para los agentes de IA.
Convención sobre configuración significa que hace falta mucho conocimiento implícito. Un desarrollador Rails sabe que un modelo User apunta a una tabla users, que has_many :posts crea toda una familia de métodos y que los callbacks before_action se ejecutan en un orden concreto. Ese conocimiento implícito es lo que hace Rails tan productivo para quien lo domina.
Para un LLM, cada convención implícita es un posible punto de alucinación. No hay una firma de tipos a la que agarrarse, ni una declaración explícita que consultar. El modelo tiene que recordar la convención a partir de sus datos de entrenamiento. Si esos datos son escasos, se equivoca.
Pasa a menudo. Un modelo genera una llamada que suena correcta pero no existe. Usa un patrón de Rails 6 en una aplicación Rails 8. Ignora una convención que cualquier desarrollador Rails con experiencia reconocería al instante. El modelo no es tonto: tiene menos material del que tirar.
TypeScript, en cambio, lo escribe todo. Los tipos están ahí, dentro del código. Un LLM no necesita recordar tantas convenciones porque puede leer las restricciones directamente.
Esto no significa que Rails deba convertirse en TypeScript. Significa que la comunidad Rails tiene que compensar esa desventaja estructural llenando la canalización de entrenamiento con ejemplos públicos de calidad.
Qué podemos hacer
No basta con decir que "la comunidad debería hacer algo". Hay acciones concretas que sí mueven la aguja.
Abrir más trabajo. Cada aplicación Rails pública ayuda: un proyecto pequeño, una herramienta interna saneada, un producto secundario, una demo realista. No tiene que ser perfecto. Cada controlador, modelo y test público es material de aprendizaje.
Escribir sobre Rails e IA. Las entradas de blog, guías y tutoriales también acaban en los datos que leen los modelos. Conviene explicar cómo usamos Claude Code con Rails, cómo integramos LLM en productos SaaS, qué patrones funcionan en producción y dónde fallan. Escribir sobre una consulta difícil de Active Record, un patrón de Hotwire o una arquitectura con Turbo Streams mejora el ecosistema.
Documentar convenciones explícitamente. Las guías de Rails son buenas, pero necesitamos más documentación alrededor. Cuando escribimos un tutorial, conviene explicar lo que los desarrolladores expertos dan por supuesto. En vez de confiar en "cualquier railero sabe esto", hay que escribirlo. Los LLM se benefician de la documentación explícita de patrones que los humanos aprenden tras años de práctica.
Construir aplicaciones de referencia. Rails ganaría mucho con aplicaciones bien mantenidas y bien documentadas que cubran patrones comunes: multi-tenant, diseño de APIs, funcionalidades en tiempo real con Hotwire, arquitecturas de trabajos en segundo plano, flujos de autenticación. No ejemplos de juguete, sino referencias de producción. 37signals empezó este camino con ONCE. Hacen falta más.
Contribuir al propio Rails. El código, los tests y la documentación del framework son material de entrenamiento de primer nivel. Mejor documentación inline, mensajes de commit más descriptivos y nombres de test más claros ayudan a que los modelos entiendan mejor las convenciones de Rails.
Importa más de lo que parece
Si los LLM funcionan de forma consistente mejor con Python y TypeScript que con Ruby, la próxima generación de desarrolladores, que cada vez dependerá más de asistentes de IA, se irá de forma natural hacia esos stacks. No porque Rails sea peor, sino porque sus herramientas de IA les funcionan mejor en otros ecosistemas.
Cuando Stack Overflow se convirtió en la base de conocimiento de facto, los lenguajes con más cobertura ganaron una ventaja de adopción. Los datos de entrenamiento son el nuevo Stack Overflow.
Ruby on Rails nos dio una era de productividad enorme. Enseñó que el desarrollo web podía ser rápido, coherente y hasta alegre. Esa filosofía sigue importando, quizá más que nunca en un mundo lleno de complejidad accidental.
Queremos que cuando un agente de IA se siente a escribir código, pueda escribir Rails con la misma fluidez con la que escribe Next.js. Para eso tiene que tener de dónde aprender.
Abre tus proyectos. Escribe sobre tu trabajo. Documenta tus patrones. El futuro de Rails también depende de eso.
