Ruby y Rails cuando los agentes escriben el código: Matz y DHH con Jeremy Daer en Rails World 2026

Bueno, bienvenidos a todos. Tengo la sensación de que estamos manteniendo una gran conversación entre todos. Esta ha sido una conferencia diferente a cualquier otra a la que haya asistido jamás. Y creo que se pueden quitar la R, la L y la S de esa primera palabra. Porque todo gira en torno a la IA.

Ahora estamos aquí para hablar de cómo dar forma al futuro de Ruby on Rails. Y la ponencia de David de ayer dejó muchas cuestiones en el aire. ¿Cómo estamos dando forma a Ruby? ¿Cómo estamos dando forma a Rails? Fue una visión más amplia de a lo que se enfrenta el mundo de la programación en su conjunto. Y en momentos como estos, no dejo de oír a la gente preguntar por el futuro y pedir predicciones. Y parece que, precisamente cuando el futuro es más incierto, es cuando la gente más desea predicciones, seguridad y una idea de lo que vendrá después.

Así que creo que podemos partir de ahí. Dado que aún no lo sabemos, ¿qué podemos decir? ¿Qué creéis que pasará a finales de este año, a finales del año que viene? Empieza tú, Matz.

Todo cambia tan rápido en los últimos años que no sabemos muy bien hacia dónde va. De hecho, hace dos años no me habría imaginado dejar de usar Emacs como editor de código. Aunque sigo usando Emacs. Sí. Yo utilizo… todo mi código está escrito con Claude Code desde noviembre del año pasado, más o menos. Y las cosas eran totalmente diferentes de… eso es bastante complicado para mí.

¿David?

Creo que tienes toda la razón. Lo que nos ocupa ahora no es la certeza, sino las probabilidades. Y la probabilidad que veo es que, para finales de año, como dije ayer, no será la mayoría de la gente, sino prácticamente todo el mundo quien esté programando como Matz a través de sus agentes.

Ahora también entiendo por qué eso da tanta sensación de incertidumbre. Cambiar las cosas y mezclarlas así es como una gran ola, y no sabes cómo mantenerte en pie ni dónde colocarte para superarla. Pero creo que por eso tenemos la responsabilidad colectiva de dar un paso al frente y ayudarnos unos a otros. Lo primero es aceptarlo. Esto está pasando. Ninguno de nosotros tiene el poder, aunque quisiéramos, de detenerlo. Es como si estuviéramos pasando a toda velocidad por las etapas del duelo. Eso es lo que está pasando. Y sé que mucha gente ha dejado atrás la ira y se encuentra en alguna fase de negociación con el futuro. No funciona. La IA te escuchará y te atenderá, pero no cambiará su trayectoria.

Así que, en mi opinión, lo único que se puede hacer es superar lo antes posible la fase de negociación —y, con suerte, pasar rápidamente por la depresión— para llegar a la aceptación; ese es, en mi opinión, el único camino a seguir. Y una vez que llegues a la aceptación, espero que experimentes lo que yo he experimentado, lo que tanta gente ha experimentado: que el otro lado es increíble. Es maravilloso y divertido en todos los sentidos en que la programación es maravillosa y divertida, al hacer que las máquinas hagan cosas nuevas. Tenemos ideas y vemos cómo cobran vida, y con la IA esto ocurre mucho, mucho, mucho más rápido.

Sí, creo que algo que resulta especialmente desconcertante en esta época es que la gente está viviendo esa experiencia, pero al mismo tiempo también está viviendo la otra. Puedes usar un agente y ver cómo las cosas cobran vida, pero también está… Quiero decir, me siento un «rubyista», me siento un programador de Rails, y sin embargo hace meses que no me pongo en Vim a escribir código en Ruby. Así que, ¿dónde reside mi identidad?

Ayer David pidió que levantaran la mano quienes estuvieran escribiendo código en Ruby, pero yo voy a pedir otra votación a mano alzada. ¿Quién se siente «rubyista»? Sí, todos.

Entonces, nos encontramos en una situación diferente… ¿dónde nos situamos en este camino cuando la identidad, en cierto sentido, puede sobrevivir a nuestra práctica? Cuando nos llamamos a nosotros mismos «rubyistas» pero no programamos en Ruby, ¿qué es lo que queda?

Aunque la tecnología haya cambiado nuestra vida, creo que ahora podemos elegir cómo nos sentimos en nuestras actividades y en nuestra vida cotidiana. Por ejemplo, cuando la tecnología empezó a imponerse, digamos, hace 80 años, a la gente le preocupaba que las máquinas quitaran el trabajo a los humanos y que toda la producción o cosas por el estilo las hicieran las máquinas. Se hizo una película como «Tiempos modernos», de Chaplin, y luego… pero las cosas han ido de otra manera, de modo que hemos reducido la carga del trabajo en la producción, o podemos trabajar de forma diferente a como lo hacíamos hace 100 años. Ese tipo de cosas podrían ocurrir en la próxima década más o menos.

Sí. Y probablemente nuestras vidas como desarrolladores de software serían diferentes de lo que son ahora. Pero aun así, podemos elegir la creación tranquila, la actividad creativa en el ámbito del software, en lugar de que nos echen del sector. Un trabajo bien remunerado o algo por el estilo. Creo que ha llegado el momento de elegir el rumbo, nuestro rumbo, cómo me siento y cómo nos comportamos con la IA.

Creo que eso resume perfectamente la diferencia. Hace unos años di una conferencia en la que hablé de que no me veía a mí mismo como ingeniero de software. Esa identidad nunca me encajó. Me parecía demasiado seria, demasiado rigurosa. Me veía a mí mismo como un «escritor de software» y así me he visto durante muchos años. Así que, para aquellos que ya se sentían incómodos con la etiqueta de «ingeniero de software», creo que estáis en una posición mucho mejor para adoptar el nuevo papel de «creador de software». Se trata de una perspectiva más amplia. En realidad, hay más cosas que tener en cuenta, más cosas que aprender, que simplemente perfeccionar el arte de escribir código a mano.

Y mi gran revelación es que resulta más satisfactorio ser un creador de software que un mero escritor de software. Y me encantaba ser escritor de software, pero la parte de la creación, el paquete completo, es simplemente más satisfactoria. Y creo que nuestra sensibilidad como «rubyistas» está especialmente bien adaptada a estos tiempos. ¿Cuál es el valor humano que aportamos cuando trabajamos con agentes? Es el buen gusto. Es el sentido de la proporción. Es el sentido de la belleza. Todo lo que nos ha importado a la hora de escribir código en Ruby, la abstracción de eso es lo que va a convertirnos en buenos creadores de software, en buenos programadores de agentes.

Así que veo como un motivo de celebración que la clase de «Top Gun» esté aquí tan bien posicionada, porque esto no tiene nada que ver con Rails. Ni siquiera tiene que ver con Ruby. Esta es la parte del discurso en línea que me resulta tan desconcertante, como si lo que está pasando fuera algo exclusivo de nuestra pequeña comunidad. ¿Estáis ciegos? Esto va a afectar a todo el mundo. Para todos los ámbitos, para todas las bibliotecas, para todos los marcos de trabajo, para todos los lenguajes.

Y hay un extraño enfoque miope en: «Ah, así que Rust es la próxima gran novedad». Me importa un comino Rust. Es decir, no voy a optar por ser programador de Rust porque ese papel ya se me ha quitado de encima. Rust es simplemente, ahora mismo, la herramienta más eficiente, y si mañana alguien lanza un Rust mejor, me cambiaré sin ninguna de las penurias que se están viviendo actualmente en esta sala con lo de Ruby, porque no tendré ningún ego invertido en Rust. Y creo que es totalmente posible que, muy pronto, ni siquiera estemos usando Rust. Pasaremos directamente al ensamblador, y el hecho de que no sea portátil no importará, porque simplemente escribiremos el código máquina necesario para cada plataforma en la que queramos estar, y adiós, Rust.

Así que no te aferres a esa idea de que, «vaya, tengo que pasarme al otro bando». Los bandos ya no existen. No estamos creando otros nuevos. Más adelante voy a comentar un poco qué podría ser lo óptimo para los agentes.

Creo que has dado en el clavo con una ansiedad fundamental cuando se plantea que, si sientes la energía, está ahí fuera y está disponible, pero si no la sientes por dentro, entonces hay un abismo entre lo que podría ser —es casi como lo que se espera de ti— y, no sé, la ansiedad y el temor ante las fuerzas de la naturaleza: ¿cómo puedo hacerles frente?

Cada persona tiene que vivir esta experiencia por sí misma. Es como cuando te dicen que va a haber un despido masivo y, bueno, que si te reciclas, vas a donde sea, aprendes a programar. ¿Y ahora qué? Así que, cuando hablamos de «creador profesional lleno de energía», ¿la gente lo siente así? Y quienes ya lo han sentido desde el principio tienen esa sensibilidad, así que no es nada nuevo. Pero para quienes se les pide que lo adopten, es una disciplina totalmente nueva.

Sí. Y, en parte, simplemente requiere que el tiempo haga su trabajo en el ego. Por eso existen las cinco etapas del duelo: para explicar a la gente que no es algo instantáneo. Para mí no lo fue. Quizá lo superé un poco más rápido que la mayoría, pero aun así tuve que pasar por esas etapas, y creo que eso está perfectamente bien. Debería haber espacio para sentir un poco de nostalgia por algo que te gustaba de verdad antes de poder pasar a algo que quizá te guste más o quizá no.

Cada uno de los cambios de paradigma que hemos vivido en informática ha dejado a algunas personas deseando que no hubiera ocurrido. Con Internet pasó exactamente lo mismo. Con los móviles pasó exactamente lo mismo. Hubo gente que, sencillamente, no quiso subirse al tren y se quedó en la estación. También habrá espacio para eso.

Sí, lo que me llama la atención aquí es que me metí en Ruby sin ningún interés por su valor económico. Me gustaba Ruby porque era Ruby y era divertido trabajar con él. Y lo era, en el sentido de que, como en tu ejemplo de los retratos, ¿hacia dónde se redirige a la gente cuando ya no se puede obtener reconocimiento económico por ese talento y esa experiencia? Bueno, ¿y si nunca lo hubieras necesitado en primer lugar? Quizás Ruby esté volviendo a su forma natural.

Sí. A diferencia de DHH, tengo un ego enorme con respecto a Ruby. Y toda mi vida depende de ello. Y por eso… pero creo que soy en parte responsable, digamos, del calentamiento global. Es una afirmación muy fuerte. Consume muchísima energía. Y luego, en la era de la IA, desde un punto de vista puramente económico, el aspecto financiero, Ruby no es la opción más adecuada.

Pero tenemos un enorme impulso e inercia debido a la gigantesca base de código de Rails, o de Ruby. Así que este año empecé a trabajar en un compilador alternativo de Ruby llamado Spinel, que compila el programa de Ruby en binario nativo. Y funciona con una rapidez impresionante y consume mucha menos memoria.

¿Cuánto?

Tal y como hemos comprobado, el programa realista del mundo real funciona con una vigésima parte de memoria. Así pues, supongamos que tu aplicación Rails consume 100 megabytes de memoria. El binario nativo de la aplicación compilada con Spinel consume 20 megabytes. Por lo tanto, eso es… ¿Qué? Son 5,5 megabytes, quiero decir.

Es que acabo de empezar con Spinel en marzo, así que aún está en pañales. Pero tiene mucho potencial. Y quizá la próxima vez vuelva a elegir Ruby. Y lo compile a un binario nativo para crear el backend.

Matz, me gustaría saber más sobre eso. Porque llevas muchos años con la idea de Spinel. Y has trabajado en mruby durante muchos años. Y cada uno tiene un lugar diferente dentro del mundo de la ingeniería y el desarrollo de software. Así que has reflexionado sobre qué puede ofrecer Ruby, en el caso de mruby, a un entorno embebido, o qué puede ofrecer Ruby a las personas. Y ahora Spinel parece plantearse: ¿qué puede ofrecer Ruby a los agentes? ¿Qué hace que Ruby sea Ruby? Si le quitas cosas, ¿sigue siendo Ruby?

Sí, no es algo que esté del todo claro. Pero a base de prueba y error he ido definiendo qué es Ruby y qué no lo es. Y el resultado es el CRuby que tenemos y que casi todo el mundo utiliza.

Pero no hay una solución única para todos. Por eso, algunas personas prefieren JRuby para entornos empresariales. CRuby es demasiado grande para los microdispositivos integrados. Y además —o quizá el propio Ruby sea demasiado lento para ello—, incluso con el compilador JIT que hemos incorporado recientemente. Así que una parte del lenguaje Ruby centrada en el rendimiento se puede compilar en binario nativo y ejecutarse a una velocidad impresionante. Y eso significa que, al menos por ahora, solo yo puedo trazar la línea entre lo que es Ruby y lo que no lo es.

Pensando en el papel de Ruby en cosas como Roundhouse —por si no todo el mundo conoce Roundhouse, es una… Es una forma de tratar Ruby como una especie de… o una aplicación de Ruby on Rails a modo de «oráculo de conformidad» al que un agente puede recurrir como especificación, y que luego generará o bien Ruby puro sin Rails, o bien otros lenguajes. ¿El «scaffolding» de Ruby está ahí, o es un medio para preservar Ruby, o es algo que sería un… ¿un único paso tras el cual dejarías de lado la aplicación de Ruby?

Cada persona es diferente. La creación de software tiene distintos aspectos. Y lo más probable es que, según mis previsiones, la mayoría de la gente se centre en la dirección del producto y la gestión del mercado del producto. Pero hay quienes se sienten muy motivados por la parte de la programación. Así que eso sería, al menos como carrera profesional, algo que se nos quitaría en un futuro bastante cercano.

Pero, al mismo tiempo, eso nos enseña a centrarnos en resolver nuestros problemas. Y si en el pasado carecíamos, digamos, de la capacidad, la habilidad o la experiencia para ofrecer o crear una solución, ahora los agentes pueden ayudarnos de tal forma que, aunque no tengamos los conocimientos suficientes, podamos crear una solución de todos modos. Esa es la situación.

Pero aún así, por lo que yo veo, no todo el mundo va a… no todo el mundo va a crear una solución. La mayoría de nosotros, la mayoría de los seres humanos, simplemente estamos esperando soluciones. Así que, en ese caso, los proveedores de soluciones son, en cierto modo, los elegidos, como nosotros aquí. Por lo tanto, lo único que podemos hacer es potenciar nuestra capacidad y ofrecer una solución para toda la humanidad. Eso es más importante que proporcionar una tecnología específica y centrarnos en ella, como dice DHH.

Pero aun así, aun así, Ruby es un lenguaje estupendo. Y es el lenguaje favorito de mucha gente. Además, el propio Ruby motiva a la gente. Incluso en la era de la IA, la motivación es el recurso más importante que pueden aportar los seres humanos, que solo pueden aportar los seres humanos, y no la IA.

Creo que Ruby tiene un papel maravilloso que desempeñar en su regreso a la cima. Recuerdo que cuando aprendí Ruby por primera vez, fue a través de artículos de la revista IEEE Magazine escritos por Dave Thomas y otros autores que describían conceptos de código utilizando Ruby, y yo pensaba que estaban escribiendo pseudocódigo. Creía que no era ejecutable, pero sí lo era. Y creo que, a medida que avanzamos hacia este ámbito en el que ya no escribiremos nosotros mismos la mayoría o la mayor parte de las líneas de código, de vez en cuando querremos entender el algoritmo y cómo funciona, y Ruby es el mejor lenguaje de programación para explicar conceptos. Así que, si en lugar de que Dave Thomas me explicara los conceptos en la revista IEEE Magazine, ahora dispongo de un agente que me explique mi código en Rust mediante Ruby, eso me parece un regreso al esplendor increíble.

La otra cosa que diría es que creo que a la mayoría de la gente le cuesta pensar más allá del «pastel fijo». Y creo que ahí es donde radica parte de la ansiedad. Se imaginan que el mundo del futuro tendrá el mismo número de aplicaciones que tenemos ahora, y luego se imaginan que necesitaremos muchos menos programadores para crear esas aplicaciones. Y eso va a ser así. El número de aplicaciones que hay hoy en día en el mundo requerirá muchísimos, muchísimos menos programadores para su mantenimiento y desarrollo. Pero podemos crear más. Crearemos más.

Esa es precisamente la exuberancia del momento: que estamos creando muchísimo más software. Cada una de las estadísticas que ves de GitHub y el motivo por el que se colapsa cada cinco minutos se debe a que hay una explosión en la creación de software. Ese es el auge. Ese es el auge. Tendremos muchísimas más aplicaciones de las que ocuparnos, y vamos a necesitar gente que lo haga. Por eso tengo este enorme optimismo en nombre de los programadores que aceptan el futuro y se lanzan a su nuevo papel como creadores de software. Vamos a trabajar en muchas más cosas, y eso es emocionante. Es bueno. Es seguridad laboral. Pero no va a suceder si te aferras tanto al lápiz que no puedes imaginar que la calculadora te ayude.

Es interesante recordar los primeros años de la década de 2000 y el auge de la programación extrema, cuando disponer de un lenguaje muy fluido merecía totalmente la pena. El coste de ejecución del lenguaje era insignificante en comparación con los costes de desarrollo. Y, por supuesto, el precio de cambiar una especificación, tener un ciclo de desarrollo ajustado e introducir conceptos como el desarrollo basado en pruebas. Y no dejo de ver una gran ironía en la situación en la que nos encontramos ahora. ¿Y cuáles son los artefactos de nuestro trabajo? ¿Es Markdown? ¿Son las especificaciones? ¿Es todo aquello que precedió a la programación extrema y de lo que nos deshicimos debido a las características negativas de los ciclos largos y el alto coste, y que ahora tiene un coste nulo? Entonces, ¿hemos vuelto al «gran diseño inicial» y a las metodologías en cascada?

No lo sé. Pero la metodología concreta y específica tiene menos importancia hoy en día porque la estructura del código tiene menos relevancia, ya que ya no tocamos el código. Pero, bueno, ahora tenemos algo que formalizar y aprender durante los próximos años. Se trata de cómo crear una visión del software, cuál debería ser la solución, y determinar cuál debería ser la solución, y cuál es el problema. Y gestionar la IA para construir la solución.

Todos conocéis el «vibe coding», y también habéis oído las historias de fracasos del «vibe coding», como que, bueno, está bien crear juegos como el Tetris, pero en cuanto intentas crear una aplicación realista, muchos de los intentos fracasaron estrepitosamente. Pero, en cambio, la gente que nos rodea, a mi alrededor, como los colaboradores de Ruby, intentan hacer «vibe coding» con las herramientas, como parte de la filosofía de Ruby, en el estilo del «vibe coding». Y, sorprendentemente, tienen una tasa de éxito sorprendentemente alta. Y eso significa que nosotros, los programadores con cierta experiencia, sabemos cómo dirigir la creación de software. O sabemos cómo definir el objetivo de los agentes. Ese tipo de cosas tenemos que formalizarlas y transmitirlas a las próximas generaciones de desarrolladores de software.

Y luego, por ejemplo, soy el líder del «vibe coding» porque desde hace quince años he estado practicando el «vibe coding». He estado practicando el «vibe coding» porque soy el líder de la comunidad principal de Ruby, y les pregunto a los colaboradores: «Vale, ¿qué os parece si añadimos esta función?». Y entonces, inteligencia orgánica. La inteligencia creó el software. Y yo lo probé, lo revisé y dije: «Vale, vamos a integrarlo». ¿Y qué tal si mejoramos el recolector de basura de esta manera? Y los colaboradores aportan código, lo hemos mejorado tanto. Genial. Así es como trabajamos ahora mismo. Todo el mundo tiene a su alrededor a colaboradores clave. Así es como trabajamos. Así es como trabajaremos a partir de ahora.

No te equivoques. Es un ascenso. A veces te ascienden a un puesto que no te interesa, pero creo que este ascenso, si le dedicas cinco minutos, te resultará inmensamente satisfactorio, porque he tenido exactamente la misma experiencia que Matz con Rails durante muchos años, quizá décadas. En la primera versión de Rails, lo escribí todo yo solo. En la segunda, quizá la mitad. Y para cuando llegamos a la sexta y la séptima, casi nada en absoluto. Solo la dirección. ¿Hacia dónde queremos ir? ¿Qué es bueno? ¿Qué está de moda y qué no? Eso es a lo que ahora todos tenemos acceso.

Lo que también es cierto es que el «dilema del innovador» suele describir lo que les ocurre a las empresas ya establecidas cuando surge una nueva tecnología. Al principio, la nueva tecnología parece un juguete. No es una amenaza. Solo sirve para cosas de gama baja. ¿Por qué nos iba a importar? Tenemos la mayor parte del mercado y contamos con los grandes clientes, y a ellos no les importan los juguetes. Cualquiera que estuviera por allí cuando Ruby saltó a la fama por primera vez recordará esta historia. «No es escalable». ¿Lo recuerdas? Eso es lo que la gente dice ahora sobre la IA. Y se equivocan exactamente de la misma manera en que se equivocaron con Ruby y Rails al principio.

Porque el «vibe coding» no solo funciona y produce resultados excelentes, sino que además está mejorando a un ritmo absolutamente astronómico. Así que cualquier cosa que ahora mismo no sea escalable, lo será dentro de cinco minutos. Eso está claro. Por eso debemos tener cuidado de no quedarnos estancados como los de siempre. De no menospreciar los «juguetes». Hablando de burlarse… Porque, por un instante, no hacen lo que queremos. Pero lo harán.

Percibo ecos de esto en el desprecio hacia la IA, en calificar las cosas de «slop» y en referirse a ellas como «proxies de carne y hueso». ¿Y hasta qué punto son esto —y son expresiones sugerentes y, a menudo, ciertas en cierto sentido—? ¿Y hasta qué punto crees que son diagnósticos reales y hasta qué punto son una forma de afrontar la situación?

El 90 % es una forma de afrontar la situación.

¡Vaya! No lo sé. Es que no lo sé. Es que odio hacer predicciones. No se me da bien predecir el futuro.

Por eso tenemos que basarnos en probabilidades. No en predicciones, ni en certezas, sino en probabilidades. Probabilidad. Y lo más probable es que esto sea una forma de salir del paso. Cuanto antes te deshagas de esas muletas, antes podrás correr. Y es cierto que, mientras aprendemos a utilizar estos sistemas sacando el máximo partido tanto a nuestras capacidades como a las de ellos, vamos a recurrir a algunas formas subóptimas de hacerlo. Y el «meat proxy» es una de ellas.

Si te pasas el tiempo copiando y pegando entre agentes y mensajes de error, deberías plantearte dejar que el agente lea los mensajes de error directamente. ¿Por qué estás metido en el bucle? ¿Por qué estás ahí como un «proxy de carne y hueso»? Sal de ese papel. Es insatisfactorio e ineficaz. Muchas cosas son así cuando empiezan a funcionar. Están un poco a trompicones. No están del todo pulidas. No tenemos un proceso perfecto. No contamos con las herramientas perfectas. Y nos las apañamos durante un tiempo, pero deberíamos tener la ambición de aspirar a algo más alto. Así que el insulto de «marioneta de carne y hueso» no es más que un peldaño temporal para ir de A a B.

Sin embargo, lo de «slop» es una excusa de primer orden. La idea de que los agentes no pueden escribir código original, de alta calidad y libre de errores es, a estas alturas, simplemente una ilusión. Es mucho más delirante, una psicosis por la IA mucho más grave que el optimismo sobre lo que pueden hacer, porque es como esconder la cabeza bajo el ala. Así que lo del «slop», creo que ya es hora de dejarlo. Ni siquiera la «granada de slop» va a durar mucho más.

Creo que «granada de slop» capta algo que «slop» no capta, porque es «slop» más la forma de presentarlo. Y ahí es cuando la gente tiene la sensación de que es «slop», cuando se les echa encima. Y es como si no se hubiera llevado hasta el final. Si tienes una idea, bueno, es como recibir un comunicado de prensa que no se ha pensado bien, y ahora te toca a ti dedicarle atención para analizarlo y entenderlo. Y la «granada de slop» es entonces que tienes que averiguar si merece la pena lanzarlo. Así que hay… ¿qué falta ahí? Hay más que solo escribir el código.

No me importan en absoluto las «granadas de slop». Simplemente las veo como sugerencias y no tengo por qué aceptarlas. Y si la sugerencia me gusta, mi agente la analizará a fondo y me presentará una implementación impecable. Prefiero con creces las solicitudes de incorporación de cambios (pull requests) y las incidencias abiertas por los agentes. Son de mayor calidad que cualquier solicitud de incorporación de cambios o incidencia que haya creado jamás un ser humano medio en cualquier repositorio que haya tenido el privilegio de gestionar. Eso no significa que tenga que aceptar la implementación. De hecho, es incluso mejor, porque si no has escrito tú el código, no sentirás ninguna pérdida cuando lo borre todo y lo reescriba. Bueno, yo no lo reescribiré, lo hará mi agente, pero tú ya no estarás apegado a esas líneas de código. Eso es una bendición.

Gran parte de la fricción en las comunidades de código abierto del pasado se debía a que la gente se encariñaba con las líneas de código porque, casualmente, habían dedicado mucha energía a escribirlas, y les costaba renunciar a ellas cuando aparecían líneas de código mejores. Yo nunca he tenido ese problema. No creo que queden muchas líneas de código en el código base de Rails que haya escrito yo personalmente. ¡Maravilloso! Mejora, progreso, algo mejor. Creo que el hecho de que ya no escribamos el código a mano permite que más gente experimente eso: una creación de líneas de código sin ego y, por lo tanto, un apego únicamente a las ideas, a las mejores ideas y a la mejora.

Sí. Creo que podemos gestionar el aluvión de solicitudes de incorporación de cambios e incidencias con la ayuda de la IA. Por ejemplo, ayer me desperté, me duché y revisé mi GitHub, y vi que no teníamos ninguna incidencia ni ninguna solicitud de incorporación de cambios para Spinel. Qué bien. Y luego me levanté, vine andando hasta aquí y mantuve una charla. Y justo antes de su ponencia, me llegaron 20 incidencias y una solicitud de incorporación de cambios en solo una hora. Y entonces saqué el móvil y abrí la aplicación de Claude. A continuación, le pedí a Claude que, bueno, solucionara esos problemas en la solicitud de incorporación de cambios. Y al final de la charla, cuando salí, Claude ya había resuelto automáticamente esos 12 problemas. Así es como lo hacemos, así es como creamos el software. Todo ha cambiado. Y podemos aprovechar el valor de la IA utilizando la propia IA.

Eso me lleva a otra cosa que iba a preguntar. A medida que hemos avanzado en estos últimos nueve meses, la verdad es que la gente ha ido aceptando en general que, bueno, estos modelos pueden generar un código excelente, y sigue buscando aquello que no pueden hacer. ¿Y cuál es esa pequeña brecha que no deja de reducirse, ese ámbito humano en el que siempre vamos a tener algún tipo de superioridad? ¿Y por qué aferrarnos a eso, para empezar? Pero uno de ellos es la sensación de tener buen criterio. Ahora bien, cuando veo a Claude gestionar todos esos asuntos, repasarlos uno por uno y tomar las decisiones acertadas, me pregunto: ¿sigue siendo eso un factor limitante? ¿Son los humanos los que ejercen su buen criterio, o en qué medida cedemos a los agentes la capacidad de decidir?

En la medida en que su competencia lo justifique. Y su competencia se mide por tu confianza en que la última solicitud de incorporación de cambios se gestionó correctamente, igual que harías con cualquier persona. Observo a los agentes y busco los mismos indicios que buscaría en un programador que trabajara para 37signals. ¿Está esta persona preparada para asumir más responsabilidad? ¿Con qué frecuencia tengo que supervisar su trabajo? Y cuanta más experiencia adquiere el agente o el empleado, menos lo superviso, más confío en él, más doy por hecho que lo ha hecho bien y más acepto también que existe el riesgo de que no sea así. Si leo cada línea de código, sabré qué hace cada una de ellas.

Si dejo de leer las líneas de código, tengo que basarme en los resultados y en la confianza. Y, de vez en cuando, el agente cometerá un error. ¿Quién de nosotros no ha cometido alguno? ¿Quién de nosotros no ha escrito código deficiente con errores que podría ser más rápido? Todos nosotros, todo el tiempo. ¿Por qué tienes esa exigencia de que la nueva inteligencia deba ser perfecta y estar libre de fallos desde el primer día? Esa es la psicosis de la IA. Esa es la ilusión de la IA. Esta inteligencia está mejorando rápidamente, pero aún no es perfecta, y nosotros tampoco lo somos. Entonces, ¿cuál es el problema?

Existe una asimetría en la norma. Me refiero a algo similar a lo que ocurre con los vehículos autónomos, en los que cualquier colisión es una colisión de más y, sin embargo, se producen decenas de miles de colisiones al año, pero es el ser humano quien tiene el control. Entonces, ¿hay algo en que sea el ser humano quien tenga el control, quien esté al volante, que resulte más excusable? ¿Generar fallos, errores y fallos de software, y suponer un riesgo?

En una sociedad dominada por las demandas judiciales, sí. En una sociedad sensata que se rige por los resultados, no. Hay diferentes sociedades en todo el mundo que abordan este problema de formas muy distintas. En Dinamarca no existen las demandas por daños personales. Simplemente no es una categoría de trabajo. No es una rama del derecho que tenga ningún impacto en cómo se toman las decisiones. A esas sociedades les irá mejor. Porque ahora mismo, por desgracia, nos enfrentamos al problema de contar con una tecnología de conducción superior que, según los datos que he visto, tiene aproximadamente ocho veces menos probabilidades de sufrir una colisión que un ser humano medio y, sin embargo, se dice: «Bueno, no sé, una sola colisión ya es demasiada». Entre 40 000 y 45 000 personas mueren cada año en Estados Unidos a causa de accidentes de tráfico. Si pudiéramos mejorar esa cifra ahora mismo y reducirla a una octava parte, 30 000 personas seguirían vivas a finales de año que, de otro modo, no lo estarían. Una sociedad que opta por ignorar eso no es una sociedad sensata.

Pues sí, me hace pensar en otras aplicaciones de estas mismas cosas, porque no se trata de un fenómeno exclusivamente relacionado con la programación. La gente está buscando aplicar estas mismas cosas en el ámbito sanitario y en la ingeniería en general. ¿Te gustaría que un equipo de IA diseñara un puente nuevo? Me refiero a ingeniería de verdad.

Sí. Pero hay algo que me preocupa. Aunque creemos el software, si utilizamos agentes sin conocer los detalles, la solución seguirá dependiendo de componentes de software ya existentes, como el compilador de Rust, Ruby on Rails o el intérprete de Ruby, lo que sea, Linux o PostgreSQL. Y entonces, como dependemos cada vez más de los agentes, los demás componentes se volverían cada vez más transparentes. Y aunque esos componentes, en su mayoría software de código abierto, son muy importantes y viables para la sociedad, esta no los vería ni se preocuparía por ellos. Esa es mi mayor preocupación. Cuanto más transparentes se vuelven los componentes, menos se preocupa la sociedad por ellos, por su mantenimiento y por su sostenibilidad. Esa es mi preocupación, y tenemos que trabajar para mantener esos componentes, incluidos Ruby on Rails, Linux y las bases de datos.

Eso me hace pensar, David, en lo que decías sobre los inconvenientes de la abstracción. ¿En qué momento dejamos de lado esos componentes y cada uno se inventa el suyo propio? Y pienso en cosas como, por ejemplo, cuando hablamos de bibliotecas concretas: ¿por qué no prescindir de una biblioteca de WebSockets e implementar directamente el protocolo WebSockets? Y todo el mundo… Me refiero a que es un amplio ecosistema con un montón de implementaciones diferentes que evolucionan de forma independiente y con sus propias funciones de optimización, que deben ser capaces de interoperar. Y mi mente de ingeniero piensa inmediatamente: «Bueno, hay desventajas claras, como las ineficiencias a gran escala; si

hay un error, hay que arreglarlo en un solo sitio en lugar de en 100 000». Pero, ¿qué opinas tú?

Esta es la próxima frontera. Darnos cuenta de que las abstracciones de nuestros propios códigos son obstáculos para la concurrencia y el paralelismo. Y lo mismo ocurre, en cierta medida, con nuestros marcos de trabajo y nuestros lenguajes. Y, con el tiempo, llegaremos al nivel del fotón, directamente a la física.

Y que todos nuestros esfuerzos a lo largo de los últimos 60 años de desarrollo de software han consistido en hacer frente a los límites de la cognición humana. Y si esos límites ya no se aplican, tampoco lo hacen las soluciones.

Por eso, me imagino perfectamente que el futuro del software se parecerá más a la vanguardia de la jugabilidad generativa que tenemos ahora. Ya existen modelos capaces de generar mundos de juego sobre la marcha. La idea de que podamos acabar en un mundo en el que los sistemas operativos, los controladores de dispositivos, los marcos de trabajo y los lenguajes se generen sobre la marcha parece ciencia ficción en este momento, pero también lo parecía, hace muy poco, la idea de que estos agentes pudieran escribir todas nuestras aplicaciones web por nosotros y liberarnos del lápiz.

Así que creo que, en realidad, necesitamos más ciencia ficción, más juego imaginativo, porque eso es lo que va a guiar nuestra imaginación en el futuro. Gran parte de nuestra imaginación actual tiene su origen en obras como 2001: Una odisea del espacio. Gran parte de nuestra idea sobre los peligros de la IA proviene de HAL 9000, de «Terminator» y de obras de ciencia ficción escritas hace entre 40 y 100 años.

Necesitamos mejor ciencia ficción en este momento porque todas esas historias ya se han hecho realidad en cierta medida y, por lo tanto, necesitamos nuevos horizontes que nos den nueva inspiración sobre cómo podría ser una nueva era de la informática.

¿Crees que hay limitaciones de velocidad a las que nos enfrentamos de inmediato cuando hablamos de, por ejemplo, si quiero saltarme la libc y comunicarme directamente, ya sabes, mediante microcódigo con una CPU? Es como si eso fuera a requerir muchos más tokens. ¿Qué es lo que se activa dentro de un modelo? Hay otros tipos de barreras de eficiencia, aparte de la eficiencia en tiempo de ejecución y la eficiencia en el tiempo de desarrollo. Ya hemos reducido al mínimo el tiempo de desarrollo.

Sí.

O bien, en el bucle de retroalimentación, el coste es casi nulo. Así que pensamos: «Bueno, no tengo que pagar el coste de ningún otro… cualquier lenguaje que me ofrezca una alta expresividad». Así que elijamos Rust porque va a reducir drásticamente el coste de ejecución. Pero, ¿qué hay del coste del ciclo, de los tokens que se gastan para representar la realidad y operar dentro de ella?

Creo que ahora mismo estamos ante algo parecido al Commodore 64. Tenemos un agente de 1 MHz. Y el año que viene tendremos uno que funcione 10 veces más rápido, y al año siguiente, 100 veces más rápido, y los humanos somos sencillamente incapaces de comprender colectivamente el crecimiento exponencial.

Así que todas nuestras preocupaciones actuales sobre la eficiencia y el coste de los tokens son relevantes en este momento, y deberías prestar atención o tu factura de tokens se disparará. Pero esa atención es una consideración a corto plazo. Por supuesto que esto se va a abaratar.

Una vez más, esa tontería apocalíptica del «decrecimiento» —que Anthropic y OpenAI nos van a dejar en la estacada— es simplemente una muestra de ignorancia económica. Los modelos de peso abierto ya son fenomenalmente buenos. Hay competencia. Nunca ha habido tanta competencia en un nuevo campo de la informática como la que tenemos ahora mismo con la IA.

Ninguno de los cambios de paradigma anteriores tuvo nada parecido en términos de competencia. Cuando llegó la telefonía móvil, teníamos dos actores: Google y Apple. Cuando se dividió la informática de sobremesa, teníamos Windows y Apple. Ahora tenemos un millón de proveedores de tokens. Quizá Anthropic y OpenAI vayan en cabeza, pero su ventaja se mide en meses, si no en semanas.

No hay nada de qué preocuparse, amigos. Las cosas van a mejorar. Va a salir más barato. Va a ser aún mejor.

Hace unos meses, Matz Endo-san hizo esta observación sobre Ruby como el lenguaje más eficiente en cuanto al uso de tokens.

Sí. Hace varios meses, nosotros —el equipo de Kaleido— analizamos varios lenguajes, entre ellos Ruby, Python, JavaScript y TypeScript, así como Rust, Kotlin, Go y Haskell. Y resulta interesante que haya tres lenguajes de entre… no lo recuerdo, probablemente 13. Esos tres lenguajes presentan una eficiencia considerable tanto en el número de tokens como en el tiempo de ejecución. Y esos lenguajes son Ruby, Python y JavaScript, JavaScript puro.

Y, curiosamente, el tipado estático no contribuye ni a la eficiencia en el número de tokens ni a la eficiencia en tiempo de ejecución.

¡Te lo dije!

Para complementar eso, teniendo en cuenta que los agentes… lo más cercano que se me ocurre es decir que se lo pasan bien con estos lenguajes eficientes en cuanto a tokens. Pueden llegar rápidamente al resultado que buscan. Y si tuviera alguna medida más precisa de la satisfacción de los agentes, sería que hubieran seguido el método de «escalada de la colina».

Sí, es una suposición un poco arriesgada, pero creo que, ya sabes, un lenguaje de programación que resulta agradable para las personas, diseñado para disfrutar programando, probablemente… ese lenguaje también resulte agradable para las IA.

Transmisión en Android con Ruby.

Lo interesante de esto es que Chad Fowler realizó una prueba de rendimiento con una serie de tareas representativas, y Ruby no fue elegido en ninguna de ellas. Y lo que más… lo que se utilizaba con mayor frecuencia era Python, JavaScript, etc., dependiendo del tipo de problema. Y quizá esto refleje el entrenamiento previo con lo que habían visto. Así que utilizan lo que conocen.

¿Cómo se orienta un modelo? Bueno, en el sentido de que aquí nos estamos desviando un poco del tema. Estamos diciendo que vamos a permitir que los modelos lo hagan todo, y sin embargo los modelos ya tienen su propio sentido interno de «Rails». Es en lo que se han entrenado. Entonces, ¿cómo conseguimos que los modelos hagan lo que queremos? Y bueno, quizá eso esté contaminando un poco el marco, porque no es necesariamente que hagan lo que queremos, sino que obtenemos lo que se les ha enseñado. ¿Es eso lo que queremos?

No creo que a los agentes les importe. Si quieres que te hablen en Ruby, te hablarán en Ruby, y lo hacen muy bien. Las evaluaciones de los agentes que hemos estado realizando demuestran precisamente eso. Son eficientes en cuanto al uso de tokens. Les encanta hablarte en Ruby.

Hablan en Python por defecto porque es el lenguaje con el que se formaron los investigadores de aprendizaje automático que han estado trabajando en estos sistemas. Pero eso no tiene nada que ver con qué lenguaje dominan mejor. Podrían hablarte perfectamente en Ruby. A ellos les da igual. Hablan todos los lenguajes con fluidez.

Además, centrarse en el preentrenamiento se vuelve muy miope muy rápidamente, y creo que nos quedamos atrapados en esa visión desde el principio, cuando nos planteábamos cómo podíamos ayudar a los laboratorios a enseñar a los modelos a usar mejor Ruby, porque teníamos la idea de que necesitaban ver mucho Ruby para escribir bien en Ruby. No, no es así. Los principios del buen desarrollo de software son universales, y da igual si aprenden esas reglas en JavaScript, Python o Smalltalk. Las traducirán a su forma final igual de bien.

Este es el segundo error de la era pasada: pensar que son como loros. Solo están repitiendo lo que les hemos dicho. No, no es así. Son pensadores increíblemente creativos. De hecho, por eso suponen un reto tan grande: en materia de seguridad, son increíblemente creativos a la hora de encadenar múltiples ataques combinados. Y por eso nos cuesta tanto hacerles frente y necesitamos nuestros propios agentes para defendernos de ellos.

La creatividad está ahí. De hecho, si acaso, son más creativos que los humanos que los dirigen. Así que aprovecha eso. Haz que te hablen en Ruby cuando eso sea lo que prefieras ver. Cuando quieras examinar el código, por supuesto que deberían hablar en Ruby, porque Ruby es el mejor lenguaje de programación para los humanos. Así que haz que te lo traduzcan, y luego pueden volver a hablar en código máquina de ensamblador directamente a la CPU.

Eso es lo que hace Spinel.

Sí. Me gustaría hablar un poco sobre lo que hay más allá de Rails. Tenemos Rails para el desarrollo web. Es una especie de manifestación concreta de lo que nosotros, como programadores, aportamos al mundo de la tecnología. Me refiero a los últimos 20 años. Y eso está cambiando. Nuestro dominio es más sólido, más amplio. Podemos hacer más cosas. Y, sin embargo, hay una sensación de: «Quiero conservar Rails». Y no tiene por qué ser necesariamente el framework, pero ¿qué hay de los valores de Rails?

Y tú, David, con Omarchy, estás empezando algo nuevo. Y es que… sus valores son atractivos. Y Matz, con MINASWAN… Matz es majo, así que nosotros también lo somos. Eso nunca me ha parecido del todo acertado, porque es como si no hicieras algo solo porque otra persona sea de una determinada manera. Pero es casi como dar permiso para una forma de interactuar con un lenguaje.

Que está bien valorar las cosas que Ruby valora. Y, al tener ese permiso, se crea un filtro excelente para saber quién se siente atraído por ese lenguaje. Así que, vosotros dos, como fundadores, ¿qué es lo próximo para vosotros?

No lo sé, pero respeto mucho a Linus Torvalds porque creó Linux. Es un gran logro. Pero, además, creó Git. Una cosa ya es toda una historia, pero crear dos grandes obras es casi una leyenda.

Y luego yo… por eso respeto tanto a David. Pero, ya sabes, él creó Ruby on Rails y Omarchy; vale, está escribiendo una leyenda. Yo estoy creando Ruby. ¿Qué tal otra cosa? Sí, déjame pensarlo.

Bueno, creo que es muy importante que las personas encuentren su tribu, que encuentren a otras personas a las que les gusten las mismas cosas que a ellas, que tengan la misma visión del mundo —no del todo, pero sí compartida—, porque necesitamos un poco de fricción. Necesitamos un poco de desacuerdo para poder aprender unos de otros.

Y creo que la razón por la que todos levantaron la mano cuando se les preguntó «¿te consideras un Rubyista?» es que compartimos una visión común sobre la importancia de Ruby como forma de expresión a la hora de programar máquinas. Eso es realmente importante. No todo el mundo lo comparte en absoluto. Hay mucha gente a la que Ruby le desagrada enormemente. Hay mucha gente a la que no le gusta Omarchy, ni Rails, ni cualquier otra cosa en la que haya participado. Eso está bien.

Sería tremendamente aburrido si a todos nos gustaran las mismas cosas exactamente de la misma manera y solo hubiera un lenguaje de programación, un marco de trabajo y un sistema operativo en este mundo. Quizá habría sido eficiente, pero desde luego no sería nada divertido. Porque los seres humanos somos tremendamente diversos en nuestras formas de pensar. Y respondemos de manera diferente a las distintas tecnologías, a los distintos paradigmas y a las distintas metodologías.

El prolongado debate en la comunidad de programadores sobre el tipado estático frente al tipado dinámico es un ejemplo perfecto de ello. Por muchos argumentos que les lances a los que están en un bando u otro, no cambiarán de opinión porque no han llegado a esas posturas mediante el razonamiento, por lo que tampoco es posible hacerles cambiar de idea con argumentos. Algunas de esas posturas son simplemente fundamentales, casi como programas preinstalados en su cerebro.

Emacs.

¡Exacto! Tabulaciones frente a espacios, Emacs frente a Vim. Esas son precisamente las líneas divisorias, y debemos tenerlas, y debemos celebrarlas. Tenemos que celebrarlas y tenemos que encontrar otras nuevas.

Así que, cuando avancemos hacia el futuro y los agentes escriban cada vez más nuestro código, necesitaremos nuevas formas de conectar con los demás, crear camaradería y encontrar una tribu. Creo que esta comunidad tiene una oportunidad única para hacerlo juntos. Ya sabéis que veis gran parte del mundo de la misma manera. Así que, mientras nos adentramos en lo que sea que nos depare el futuro, quedaos por aquí. Lo pasaremos bien.

Así que, si no podemos predecir el futuro, quiero decir, quizá podamos prepararnos para él y disfrutar del presente. ¿Qué crees que es lo que Ruby on Rails ha hecho realmente bien en estas últimas décadas?

Para mí, se trata de centrarse en la autonomía. Que los programadores puedan llegar mucho más lejos de lo que lo harían con herramientas menos eficientes, placenteras y bonitas. Ruby fue para mí una revelación mágica, porque no solo me proporcionó una herramienta práctica para crear aplicaciones web, sino que también fue una fuente inagotable de alegría y motivación para dedicarme a ello.

Creo que en las comunidades de Ruby on Rails lo hemos entendido mejor que nadie. Una comprensión de la psicología humana, de lo que impulsa la productividad. Una parte muy importante de eso es exactamente lo que has dicho: la motivación. Se trata de trabajar con herramientas ergonómicas y bellas que crean algo que, a simple vista, puede parecer frívolo. Código que parece poesía. Más allá de si se ejecuta rápido.

Ahora bien, esta es la otra faceta de este momento actual. Creo que es importante entender que hay aplicaciones en las que el rendimiento es crítico y que pueden mejorarse reescribiéndolas en algo como Rust. Y luego hay muchas, muchas, muchas, muchas más en las que esa eficiencia no importa en absoluto. La gran mayoría de las aplicaciones de Rails ya pueden ejecutarse en una sola Raspberry Pi. No necesitan más velocidad que esa. Y luego, cuando se requiera más hardware, se puede cambiar.

Así que voy a seguir creando todas las nuevas aplicaciones web que escriba en Ruby on Rails. Es una forma maravillosa de empezar. Y me resultará muy satisfactorio echar un vistazo entre bastidores y ver cómo los agentes generan este precioso código. Y luego, si llega el momento en que algo se haga tan popular que resulte económicamente ventajoso reescribirlo en Rust o en código máquina, simplemente lo haremos. Y luego podremos volver a convertirlo a Ruby si así nos apetece, por un momento de puro placer y aprecio por la bella poesía del código.

Todo esto es flexible. Podemos ir en una dirección o en la otra. No hace falta que te quedes atado y pienses: «Dios mío, ahora tengo que ser programador de Rust». No te condenaría a ese destino. Confía en mí.

Menos mal.

Por lo que yo creo, la mayor contribución de la comunidad Ruby al mundo es mostrarte la importancia de la alegría y la motivación dentro de una comunidad en el ámbito de la programación. Los seres humanos necesitamos motivación para hacer cualquier cosa. Por eso, necesitamos estar motivados para crear software o, ya sabes, para crear cualquier cosa… y también para mejorar la sociedad.

Y nosotros… cuando sentimos alegría, podemos ser mucho más productivos en el desarrollo de productos… en desarrollo. Ese tipo de cosas no formaban parte del sentido común hace 30 años. Por eso, esa es la mayor contribución del lenguaje Ruby.

Y el principio básico, siempre y cuando las preocupaciones humanas sigan siendo las mismas en el futuro, creo yo. Así que la motivación importa. La alegría importa y la libertad importa. Ese tipo de cosas seguirán siendo igual. Pero, ya sabes, la tecnología va y viene, y quizá en el futuro Ruby sea menos importante, o llegue a serlo, pero, en cualquier caso, la alegría, la motivación y la libertad seguirán siendo muy importantes.

Gracias. Seguirá siendo importante para todos nosotros, tanto para los desarrolladores como para los creadores.

Claro que sí.

Sí, cuando pienso en la felicidad de un programador, es una combinación de autonomía y alegría. Y hay algo que quizá tenga que ver con la felicidad profesional de un programador, y es que también te pagan. Es un reconocimiento de lo que estás creando y de tu relevancia en el ámbito profesional; de que tienes un futuro haciendo este tipo de trabajo.

Así que, por último, echando la vista atrás —y esto es realmente como una colaboración de 20 años entre Ruby on Rails, la autonomía y la alegría—, ¿qué es lo que más agradeces?

Lo que más agradezco es que Matz nos haya permitido a mí y a otros miembros de la comunidad de Rails terminar el libro que él comenzó. Ha situado al programador de aplicaciones al mismo nivel que al diseñador del lenguaje, de tal forma que no podríamos distinguir la diferencia.

Agradezco a DHH y a la comunidad de Rails por dar a conocer Ruby al mundo. Antes de Rails, Ruby ya existía, pero prácticamente nadie lo conocía. Y luego, gracias a Rails, todo el mundo empezó a utilizarlo, y muchas aplicaciones —como Shopify, GitHub y las primeras versiones de Twitter— se crearon con Ruby on Rails, y todo el mundo empezó a utilizarlo.

Y en el pasado, muchísimas startups utilizaban Ruby on Rails, y consiguieron, obtuvieron beneficios y cambiaron el mundo. Eso me llena de alegría. Y me dio cierta autoestima. Y gracias a Rails, puedo dedicarme a Ruby a tiempo completo. Así que, sí, agradezco muchísimo la existencia de DHH y de Rails.

Matz, David, gracias a los dos por todo.

Gracias.