DHH en Rails World 2026: el fin del código escrito a mano y la apuesta por el optimismo total

Me gusta. "Bent" en neón.

Bueno, antes que nada, bienvenidos a Austin, es lo que normalmente diría. Yo diría: bienvenido de vuelta a Austin, a mí mismo. Estuve aquí hace apenas un mes, hablando durante 5 horas en un pódcast. Es genial estar de vuelta.

Pero lo que me emociona aún más es estar vivo ahora mismo en este momento y compartirlo con una comunidad maravillosa en torno a Ruby on Rails y con todos los que están entusiasmados con los agentes. Y si todavía no lo están, ojalá lo estén al final de esta delirante charla sobre el futuro.

Ahora, sé que el primer instinto que alguien podría tener al ver a una persona bailando, tan emocionada con este momento, es un diagnóstico. Psicosis por IA. Prefiero otro término. Tengo delirio por IA. Euforia por IA.

Porque esto es simplemente lo más emocionante que les hemos hecho hacer a las computadoras en todo el tiempo que he trabajado, jugado e interactuado con ellas.

Pero creo que, de hecho, hay que lidiar con el hecho de que, por un lado, esto es tremendamente emocionante, y también un poco inquietante. Porque no sabemos exactamente cuál va a ser el estado final de todo esto. Y cada vez que intentamos hacer una predicción, queda obsoleta unos 20 minutos después.

Es un estado extraño en el que estar, incluso si te entusiasma el futuro, incluso si te entusiasma el presente. Y entiendo perfectamente la sensación de inquietud que eso puede generar. Así que, para calmar eso un poco, retrocedamos un poco el reloj.

Esto es lo último en tecnología del siglo XVIII. Si querías un retrato tuyo en el siglo XVIII, te sentabas hora tras hora tras hora frente a un maestro pintor que luego se iba y, en el mejor de los casos, pasaba meses trabajando en tu retrato.

Y era hermoso, es hermoso, un legado cultural increíble que nos han dejado a todos. Todavía hoy podemos ver a Lady Waldegrave, que Joshua Reynolds pintó en 1781. Maravilloso.

También un poco exclusivo. No mucha gente en el siglo XVIII podía encargar un retrato de sí misma así y pagarle a un artista para que pasara meses y meses y meses creando algo como esto.

Y peor aún, en el caso de esta pintura en particular, Reynolds pasó meses y meses en otra pintura de las damas Waldegrave que el cliente rechazó porque se veía un pedazo de tobillo. Era escandaloso. Así que simplemente tuvo que volver a hacerla.

No sé si alguien aquí ha trabajado con clientes, pero tal vez sientan algo de compasión por el pobre señor Joshua Reynolds. Y sus propuestas de trabajo rechazadas.

Ahora bien, la mayoría de la gente que podía permitirse esto era de la alta burguesía o directamente de la realeza. Aquí hay una pintura que hizo Goya 20 años después de la familia real española.

Ese era más o menos el ritmo de la tecnología. Los pintores habían perfeccionado distintas técnicas para retratar a las personas durante literalmente cientos de años y lograban un progreso muy marginal en el camino.

Ahora, entre 1801 y la próxima pintura que voy a mostrar, pasaron 80 años. Y en ese tiempo, la cámara entró en escena alrededor de 1840.

Pero aquí hay una pintura de la familia real danesa de 1888. Ah, del 86. De un pintor danés, Laurits Tuxen. No pasó solo 3 meses pintándola. Pasó 3 años.

Todavía está colgada en las plazas reales de Copenhague, y pueden ir a verla allí. Un logro asombroso, un arte asombroso. También muy funcional. De nuevo, el objetivo era retratar a la familia real de ese momento.

Pero esto ya se acercaba al final de ese modo en particular para artistas de ese tipo. Porque lo que pasó entre 1840 y 1900 fue que la tecnología para capturar retratos se volvió cada vez mejor.

Y en 1900, Eastman Kodak Company presentó la Brownie, la primera forma de fotografía producida en masa que era más accesible en general porque el precio estaba bajando. Creo que costaba alrededor de un dólar tomarte una foto con esto. Y por eso, de repente mucha gente se tomó fotos.

Y todos estos grandes artistas se dieron cuenta de que el oficio de producir estas grandes pinturas, ¿saben qué?, eso iba a ser diferente. El trabajo iba a ser diferente. Porque de repente había competencia de una nueva forma de tecnología.

Y cambiaron de rumbo. Laurits Tuxen, junto con muchos otros pintores de esa época, poco después de que se presentara la Brownie, se dio cuenta de que representar la realidad de la forma más perfecta posible ya no era realmente una habilidad económicamente viable. Necesitaban otra habilidad. Necesitaban otro campo.

Y muchos de ellos se pasaron a otras formas de arte. Tenías a Picasso persiguiendo el cubismo. Y tenías a los pintores daneses de Skagen persiguiendo una forma de impresionismo de la que esta pintura es un ejemplo.

Así que tuvimos esta explosión de creatividad provocada por el cambio tecnológico, porque de repente la gente tuvo que encontrar una nueva forma de expresar su arte, ya que la forma antigua había desaparecido.

Ahora, lo interesante de esta imagen en particular es que la dama del centro, con el vestido rosa, Yvonne Tuxen, es en realidad mi bisabuela. Porque Laurits Tuxen es mi tatarabuelo.

Y aquí aparece en 1921, creo, poco antes de su muerte. Antes de morir, aceptó que le hicieran su propio retrato con la nueva tecnología que había convertido su antigua profesión en un lugar distinto para trabajar.

52 años después de su muerte, nací yo, en 1979. Curiosamente, esa foto que se tomó aquí es muy parecida, de hecho, a la foto que le tomaron a Laurits. En la década de 1920, la tecnología no había evolucionado tanto, porque eso es lo que suele pasar con los avances tecnológicos. Llegan a trompicones, con arranques y pausas.

El gran cambio fue la Brownie, la democratización de la fotografía, y luego pasaron casi 80 años en los que no ocurrió gran cosa. Tuvimos la fotografía a color en los años 60, pero no estaba tan extendida como para que, al parecer, yo mereciera una.

Aunque lo corregimos unos años después, y aquí hay una foto a color mía, a los 4 años, sentado con mi hermano. Unos años más tarde, aquí hay otra foto mía, y entre esas 3 fotos, eso es, creo, el 10% de mi reserva de fotos de mi infancia.

Porque aunque la democratización de esta tecnología había llegado al punto de que incluso nosotros como familia podíamos permitirnos tomarnos estas fotos, no estaba tan extendida. Y sí, había una curva y se tomaban más fotos en los años 80, como representa esta foto, que en el 1900, pero todavía era algo modesto. Porque la tecnología avanza a trompicones, con arranques y pausas.

Y la cámara con la que se tomaron esas 3 fotos era muy parecida a esta cámara. Esta es la Leica 1 de 1925. De hecho, quizá algunas de esas fotos se tomaron literalmente con otra Leica. Creo que para entonces iban por la séptima. Pero no eran tan diferentes, porque la tecnología era bastante parecida. No había pasado gran cosa desde la gran revolución de alrededor del 1900 hasta los años 80.

Luego le dimos un par de décadas más y, de repente, todo cambió drásticamente otra vez. La fotografía pasó de simplemente estar al alcance de todos a no tener ninguna fricción, y la cantidad de fotos que se tomaban se disparó.

Porque de repente todo el mundo podía permitirse tener decenas de miles de fotos de sus hijos, y muchos lo hicieron. Simplemente se volvió tan barato que ni valía la pena medirlo. Estas son algunas de las fotos que a mi esposa le gusta tomar cuando sale a su caminata de la tarde.

Querer hacer esto incluso en los 80 habría requerido comprometerse con el rollo y mandarlo a revelar y todo lo demás. Y había gente que lo hacía, pero no tanta, porque la fricción todavía era demasiado alta.

Hoy, en 2026, se toman unos 2 billones de fotos al año. Eso es muy diferente. Es la misma tecnología de base, pero claramente llegamos a un punto de inflexión, incluso comparado con cuando salió el primer teléfono con cámara. Aquí va a haber algunos paralelos con nuestra industria y nuestra profesión.

El 24 de noviembre de 2025, tuvimos la Kodak Brownie de nuestra era. Tuvimos Opus 4.5. Tecnología de IA hecha accesible en un harness que mucha gente podía permitirse usar para experimentar por primera vez lo que es crear software en pareja con una nueva forma de inteligencia.

Ese fue el punto de quiebre para mí. Existió todo lo anterior al 24 de noviembre. Y luego existió todo lo posterior. Esta va a ser la fecha que los libros de historia marcarán de aquí en adelante como el punto de inflexión de la era de los agentes.

Y como con la Brownie, cuando salió por primera vez, hubo una explosión de distintos formatos y nuevas formas de intentar aprovechar esta tecnología. Y no pasó mucho tiempo hasta que tuvimos algo parecido a la misma inteligencia en formato de pesos abiertos.

Euforia total. Esto avanza tan rápido. No puedo creer que esta tecnología alienígena ya esté disponible con pesos abiertos. Pasó apenas unos meses después. Usé Kimi K2.5 en modo rápido durante bastante tiempo y me encantó. Una experiencia increíble, poder experimentar este tipo de inteligencia a 200 tokens por segundo.

Pero luego pasó otra cosa. Este valle de la desilusión, de febrero a mayo, en el que aparentemente seguían saliendo modelos nuevos, pero eran medio malos. Era como si estuvieran retrocediendo. Y mucha gente decía: ¿qué es esto de Opus 4.6? No sé, amigo. Denme lo de antes otra vez.

Y mucha gente pensó: ja, ja, ¿creían que esto iba a seguir expandiéndose y mejorando exponencialmente? Pero miren, en realidad no estamos mejorando tanto.

Recuerdo un lanzamiento en particular. Creo que fue el nuevo modelo de OpenAI, que no rendía mucho mejor en los benchmarks. Y bajó el precio de la acción, o bajó la valuación, y de repente el mercado era: Dios mío, se acabó. Sí. Porque no sabemos lo que va a pasar.

Pero este valle de la desilusión no duró como con la fotografía, 100 años, en los que la tecnología apenas parecía mejorar. Solo duró hasta mayo. Bueno, junio, en realidad. Porque en junio tuvimos Fable 5 y Mythos.

Y claramente, cualquiera que tuvo la oportunidad de experimentarlo en ese momento se quitó de encima cualquier desilusión que pudiera tener sobre si nos habíamos estancado o si se había acabado.

Y diría que ahí es donde mi diagnóstico realmente se instaló. Mi psicosis/delirio/euforia por esta explosión de inteligencia a demanda.

Este fue el modelo con el que pasé de: "Ah, puedo decirle a un agente que haga algo por mí", a ver que eso era algo que quería mergear. Esa fue la revelación de Opus: de repente tener modelos a los que podía darles problemas o ideas y verlos resolverse o verlos expandirse sin ninguna indicación mía sobre la implementación. Increíble, alucinante.

Y por supuesto, las cosas no se detuvieron ahí. Llevamos un par de meses en esta increíble montaña rusa. GPT-6 Astra salió en septiembre y nos salvó a todos del temor de que Anthropic fuera a tener el monopolio de este tipo de inteligencia de frontera.

Y todavía mejor, apenas una semana después, tuvimos DeepSeek-4-1 Flash, que nos quitó cualquier idea de que la inteligencia de frontera iba a ser para siempre dominio de solo unas pocas grandes empresas tecnológicas estadounidenses. Esto es increíblemente emocionante.

Pero ¿qué significa? ¿Qué significa para nosotros como programadores? ¿Qué significa para nosotros como profesión? Y creo que por eso, de nuevo, vale la pena mirar un poco hacia atrás. Porque la historia guarda todas estas lecciones y paralelos increíbles con nuestra época, si tan solo la miramos.

Una de las cosas que ha dominado la conversación todo el tiempo que llevo como desarrollador profesional ha sido la discusión sobre si el programador 10x era real o no.

Bueno, todo ese concepto vino de un artículo de la revista de la ACM de 1968, en el que evaluaron a un grupo de programadores en distintas tareas, y obtuvieron una tabla que mostraba que entre el peor y el mejor programador había una variación de 5x a 30x, con un promedio de 10x en ese periodo.

Luego pasamos literalmente los siguientes 45 años discutiendo si eso era real o no. ¿Alguien sigue discutiendo eso? No lo creo. Ese debate ya está zanjado.

Pero lo interesante es que, de algún modo, saltamos por encima de una conclusión compartida sobre el programador 10x y empezamos a pensar: bueno, si eso era 10x solo con la capacidad humana, ¿cómo será ahora?

Y está claro que no lo sabemos con exactitud. No sabemos exactamente qué tipo de aceleración es posible con estas herramientas. Pero yo diría que hoy es menos controvertido afirmar que hay una diferencia de 100x entre el peor programador trabajando sin estas herramientas y el mejor programador trabajando con ellas. No es una afirmación muy controvertida. Pero es absolutamente revolucionaria para entender dónde estamos ahora mismo como etapa de la tecnología.

Y de hecho iría un paso más allá. Y quizá esto sea un poco más controvertido. No lo creo. ¿El peor programador sin estas herramientas contra el mejor programador con ellas? Suena más o menos bien. ¿1,000 veces? Sí.

Bien. Entonces, ¿qué significa eso? ¿Qué significa para la competencia entre empresas, para lo que necesitamos para arrancar? Eh, la bola 8 mágica anda un poco caprichosa. Agitemos otra vez.

Lo que sé que es cierto es que en los últimos 20 meses he escrito la mitad del código que escribí en los 21 años anteriores.

Ahora, las líneas de código son una medida extraña, difusa y maleable. Y una línea de Ruby obviamente vale muchísimo más que una línea de cualquier otro lenguaje, pero sobre todo Rust o C++ o cualquiera de los lenguajes de más bajo nivel que no tienen las mismas abstracciones y comodidades que disfrutamos en Ruby.

Pero aun así es absolutamente innegable que está ocurriendo una revolución. Y cualquiera que haya pasado por eso y haya visto acelerarse su propia productividad va a estar un poco mareado.

Cómo creamos una plantilla. Miren todo lo que no estoy haciendo. Miren toda la configuración que no estoy escribiendo. Todas estas cosas se conectan entre sí automáticamente. Con solo poner "blog" aquí arriba, se mapea directamente al controlador de blog, y con solo tener "index", se mapea directamente a la plantilla index. Miren todo lo que no estoy haciendo.

¿Hay una mejor forma de resumir este momento que todas las cosas que ya no estamos haciendo? Esa es la fuente de mi entusiasmo por este momento. Este es el momento Rails.

Ese clip que acabo de mostrar tiene 21 años. Di una presentación en Brasil en 2005 y estaba muy emocionado por todo el código que no estaba escribiendo. ¿Ven por qué quizá estoy incluso un poco más emocionado ahora? ¿Saben cuánto código no he estado escribiendo en los últimos meses? Muchísimo.

Y aun así, a pesar de no escribir código desde hace probablemente 5 meses, he podido arreglarlo todo. Cada sueño. Cada molestia, cada detallito, cada funcionalidad frívola, de repente al alcance, de repente posible. Esta es la magia del momento.

Pero ¿qué significa eso? Bueno, en 37signals, hace un par de semanas, tomamos la decisión de que eso claramente significa que se acabó escribir código a mano.

Vamos a soltar, y ya soltamos, el lápiz en cuanto a la idea de escribir código a mano como parte normal del trabajo de crear cosas. Escribir código a mano en 37signals ahora es un estado excepcional. Es como ver un bug en Sentry. Algo salió mal aquí. ¿Por qué el agente no pudo producir lo que queríamos?

Bueno, quizá por un tiempo todavía saquemos el viejo lápiz y se lo anotemos. Pero luego arreglamos la máquina. Arreglamos la fábrica. Volvemos a ponerlo todo en marcha. Esto es reconocer lo que ya está pasando.

Si hiciéramos una encuesta en esta sala, probablemente... de hecho, hagámosla. ¿Cuántos aquí siguen escribiendo cantidades significativas de código a mano cada semana? Levanten la mano. Carajo, son como 5.

Si hubiera puesto esta diapositiva hace 2 meses, 3 meses, y hubiera hecho la misma declaración, bastante gente habría dicho: a este tipo le falta un tornillo. Y ahora, esto ya es solo reconocer lo que ya existe.

Lo fascinante de esto es que intentamos hacerlo en la primavera en 37signals, cuando le estábamos dando los toques finales a Basecamp 5. Pusimos a un grupo de diseñadores a hacer vibe coding de las últimas funcionalidades que querían en esta versión, y los resultados fueron mixtos. Individualmente, los diseñadores lograron crear PRs que parecían razonables.

Pero en conjunto, 20 o 30 de ellos dejaron la arquitectura pareciendo un poco un queso suizo, medio agujereada. Así que dijimos: uf. Bueno, supongo que la tecnología todavía no está lista. Volvamos a revisarlo todo manualmente y que solo los programadores trabajen con ella.

Esa fue la conclusión equivocada, claramente. No solo porque podríamos haberle dado 5 malditos minutos más, y habríamos tenido Fable, y probablemente todo habría funcionado como se pensó originalmente, sino también porque lo que ahora está claro es que solo hay una pregunta seria en este momento del desarrollo de software. Y es: ¿cómo sacar el máximo provecho de esta explosión de inteligencia? Todas las demás preguntas están por debajo de esa en la escala de valores.

Así que lanzamos Basecamp 5. Es una gran actualización. Fue acelerada por agentes, pero todavía acompañada de mucho código escrito manualmente, a mano... ¿cincelado? ¿Cómo vamos a llamar a esta vieja forma de trabajar que se acaba de jubilar hace 5 minutos? No lo sé.

Pero ahora estamos trabajando en un proyecto nuevo. HEY Next. HEY New. HEY There. No sé cómo lo vamos a llamar. Pero es una nueva versión de HEY, nuestro servicio de correo.

Y lo primero que vamos a hacer... HEY Next... es dejar de hacerlo una app web. HEY ya no va a ser una app web.

Porque HEY nunca quiso realmente ser una app web. HEY fue y es una app web porque hacer apps web para equipos pequeños era la forma de ser productivos.

En los viejos tiempos, es decir, hace 5 minutos, la idea de que un equipo pequeño pudiera mantener 6 aplicaciones nativas escritas en los frameworks nativos era absurda. Nadie lo hacía. Por eso no solo teníamos gente haciendo apps web. Por eso teníamos React Native. Por eso teníamos Hotwire Native. Por eso teníamos todas estas herramientas para ser más productivos, aceptando que la fidelidad iba a sufrir un poco.

Hacemos apps web geniales. HEY es una app web maravillosa. Pero no es tan buena como una aplicación nativa. Claro que no es tan buena como una aplicación nativa. Hay latencias distintas y todo eso.

Bueno, lo que se está reproduciendo detrás de mí es una demostración de las 6 aplicaciones nativas que arrancamos hace como una semana. Aquí es donde ya estamos. Es una locura.

Antes, si querías mantener 6 aplicaciones nativas con muy alta fidelidad para un servicio importante, iba a tomar mucho tiempo. Requería un equipo enorme. Ahora, de repente, podemos lograr aplicaciones nativas de altísima fidelidad porque no estamos escribiendo ni una maldita línea de código. Miren todo lo que no estamos haciendo.

Pero miren todos los prompts que estamos dando. Estamos dando muchísimos prompts. Y los resultados son absolutamente electrizantes. Es un esfuerzo que apenas empezamos, y ya estamos en un punto en el que para mí es obvio que este es el futuro de ese tipo de aplicaciones.

Hay muchas aplicaciones web que son web por necesidad, por conveniencia, por preferencia de los programadores, por el tamaño del equipo, por los recursos disponibles. ¿Saben qué? No van a seguir siendo apps web mucho tiempo más. Van a ser aplicaciones nativas, porque el costo de desarrollar esas cosas ha bajado prácticamente a cero.

Ahora... aquí hay un ejemplo de lo que devolvió el primer prompt cuando pedimos una aplicación para Windows. No del todo lista para lanzar. Y aquí está la versión redirigida que llegó 20 minutos después. ¿Lo están captando? Esto es una locura. ¿Cómo no necesitar un diagnóstico después de ver esto con sus propios ojos?

Ahora, de ninguna manera somos los únicos en darnos cuenta de esto. De ninguna manera somos los primeros en darnos cuenta. Shopify acaba de lanzar una aplicación nativa reescrita para la app Shop. Reemplazando una aplicación en React Native, hecha por un equipo diminuto. Si consideran lo crítico que es, unas seis personas trabajando no mucho tiempo, esto viene en camino. Prepárense.

Eso fue el frontend, y creo que para este tipo de aplicaciones como HEY, como la app Shop, que realmente quieren ser aplicaciones nativas, eso es lo que va a pasar. Vamos a apostar por estas herramientas nativas. Y nos vamos a dar cuenta de que el costo de crear estas cosas simplemente ya no existe de la misma manera.

Pero ¿qué pasa con el backend? Esto es un poco difícil para mí. Lo admito. Y les voy a decir por qué. Rust. Rust. Odio Rust con pasión. Para mí, Rust es como echarme ácido en los ojos cuando tengo que ver el código. ¡Epa, epa, epa! ¿Por qué odias Rust? Es, en mi opinión, el lenguaje de programación más feo que se ha inventado probablemente en los últimos 40 años.

¡Prueba A! Es un lenguaje de programación horrible, horrible, horrible cuando se obliga a humanos a escribirlo. Es absolutamente inhumano pedirle a gente de carne y hueso que someta sus ojos a esto.

Pero ¿saben qué? Si nunca tengo que mirarlo, si lo único que tengo que hacer es disfrutar de aplicaciones 30 o 100 veces más rápidas, compiladas en ejecutables minúsculos que arrancan en menos de un milisegundo, ¡amo Rust! Rust es increíble si nunca, nunca, nunca tienes que mirarlo tú mismo.

A los agentes... a los agentes les gusta Rust. ¡Genial! Qué división del trabajo. Yo te digo qué hacer. Tú lo escribes en Rust. Yo nunca tengo que mirarlo. Me encanta. Y también me encantan los resultados.

En este esquema, en el que reescribimos el frontend de HEY todo en aplicaciones nativas, y por lo tanto ya no necesitamos una aplicación web que renderice HTML y demás, y luego tomamos ese código que corre la ya-no-aplicación-web y lo convertimos en el servidor de correo que realmente es en esencia, en Rust, terminamos con un backend que requiere 99% menos CPU, 95% menos memoria, y la única razón por la que necesita 10 hosts es la redundancia.

De hecho, nuestro cálculo aproximado nos lleva a creer que el tráfico pico de HEY probablemente podría servirse con una sola Raspberry Pi.

Esa es la eficiencia de escribir lo más cerca del metal que se pueda sin dejar de ser portable, que es Rust. Y la ventaja de que otra cosa lo haga por ti. Otra inteligencia a la que le pagas por token para que lo haga.

¿Qué significa esto en cuanto a cómo trabajamos con esta inteligencia? Tampoco está claro. Estamos probando un montón de cosas. Una de las cosas que estamos intentando es dirigir a estos agentes, nuestra Chef Marie, dentro de Basecamp para que lo hagan.

Está claro que cuando trabajas con agentes, la mejor forma de hacerlo es en realidad de forma asíncrona, no en una interfaz de chat, no sentado esperando a que salgan los tokens, sino darle una tarea a un agente, como lo harías con un compañero de trabajo, mandarlo a hacerla y luego volver a revisar cuando haya algo listo. Así que también estamos intentando eso. Mucha otra gente está tratando de descifrar esto. Y esto es parte de la magia, de la electricidad de este momento.

No sabemos cómo se supone que debe ser todo. Primero, porque cambia cada 5 minutos. Segundo, porque no hemos trabajado con este tipo de inteligencia durante ningún periodo de tiempo significativo. Todo esto arrancó el 24 de noviembre del año pasado. Ni siquiera ha pasado un maldito año. Y el tipo de inteligencia que nos permite asignar resultados, problemas, en lugar de tareas, tiene apenas un par de meses. Así que, por supuesto, no sabemos exactamente cómo va a ser.

Pero aun así es justo preguntarse: ¿dónde deja eso a Ruby? ¿Dónde deja a Rails? ¿Dónde deja a cualquiera de estas herramientas que usamos? ¿Cómo va a ser el futuro?

Bueno, para HEY, tenemos nuestra respuesta. Se ve como aplicaciones nativas en el frontend y Rust en el backend. Pero hay muchas otras aplicaciones que no encajan en esa forma.

La web es una plataforma enormemente maravillosa. En parte porque nunca le pide a nadie que instale nada. Y hay un millón de negocios construidos sobre esa premisa. Clientes más efímeros que no van a molestarse en instalar algo en su dispositivo para usar un servicio. La web es maravillosa para esas cosas. Y Rails está especialmente bien posicionado para seguir en juego ahí.

Todo aquello en lo que hemos trabajado durante los últimos 25 años. La convención sobre configuración lleva directamente a cosas como la eficiencia de tokens. Nuestro enfoque en el framework para un solo desarrollador encaja perfectamente con lo que exige la era de los agentes: que un solo desarrollador pueda llegar mucho más lejos de lo que podía antes.

Empezamos a hacer estas evaluaciones de agentes. O más bien, Evil Martians empezó a hacerlas en nombre de la Rails Foundation. Y, primero, descubrimos que tuvimos que actualizar rápido nuestras evaluaciones porque los agentes estaban saturando la primera versión y alcanzando tasas de finalización del 95% bastante rápido. Ahora establecimos una medida más difícil. Pero es asombroso lo rápido que estos agentes avanzan y suben en el stack y en el ranking.

Esta es una evaluación de agentes que mide la implementación real de tarjetas de funcionalidades contra algunas de estas aplicaciones de referencia que tenemos en producción. Maravilloso. Estamos apostando por eso. Ese era el benchmark anterior, la referencia anterior. Como ven, ya se estaba saturando, así que lo hicimos más difícil. Va a haber mucho de eso, mucho de subir el nivel de lo que les pedimos a los agentes, porque siguen volviéndose más capaces.

Y de hecho, es una de las trampas sobre las que advertiría a cualquiera que sepa demasiado sobre cómo funcionan las computadoras: no ser demasiado prescriptivo con lo que intentas sacar de estos sistemas. De hecho, tener un poco de mentalidad de principiante y un enfoque un poco ingenuo funciona todavía mejor, porque haces preguntas y escribes prompts a un nivel más alto.

Esta es una de las razones por las que me encanta trabajar en Rust. No sé nada de Rust. Lo considero una ventaja. ¡Sí! Y un privilegio no tener ni puta idea de lo que estos agentes están metiendo en la caja de Rust. Evalúo la caja de Rust como una caja negra, desde afuera, como cualquier dueño de negocio en la historia que alguna vez le encargó a un grupo de programadores que hiciera algo por él. Esto no es un fenómeno nuevo. Quién tiene ahora esa responsabilidad ha cambiado, pero no el fenómeno.

Pero aplicaciones como Basecamp, donde traemos a desconocidos que solo necesitan sacar rápido un archivo o colaborar por un periodo corto. Excelentes aplicaciones web. Seguramente muchos de ustedes trabajan en ese tipo de aplicaciones. Ahora, averiguar exactamente dónde vamos a trazar esa línea, qué debería ser nativo, qué debería seguir siendo web, eso lo vamos a tener que descubrir. No tengo todas las respuestas. OK.

Lo que sí sé es que cuando miro mi trabajo del último año, se ve muy diferente. Si miro los últimos 21 años, más de la mitad de mi trabajo fue código Ruby. Este año, alrededor del 3%.

En parte es porque lenguajes de programación como Rust son tremendamente verbosos y poco atractivos para que los miren los humanos. Así que no los miro, y dejo que el agente genere más de lo necesario, de una forma que nunca toleraría en mi código Ruby. Así que eso es parte de ello. Pero aun así, es innegable que hay un cambio enorme.

En esos 21 años anteriores trabajando con Ruby, escribía unas 30,000 líneas de código Ruby de producción al año. Eso bastó para construir negocios y frameworks y todo lo demás que he hecho. Bueno, en agosto, el mes pasado, escribí 150,000 líneas de código en un solo mes. Eso es unas 60 veces más código que mi promedio de largo plazo. De nuevo, gran parte es ese horrible código Rust que no quiero mirar, y es más verboso, pero aun así, los órdenes de magnitud aquí, a eso es a lo que tenemos que prestar atención. Y al menos pensar: ¿qué significa eso?

Bueno, una de las cosas que me ha sorprendido, y la verdad no debería, es el hecho de que en realidad existe un lenguaje de programación que me gusta más que Ruby. No creía que fuera cierto, pero lo es. Se llama inglés.

El inglés es un mejor lenguaje de programación que Ruby. Y amo Ruby más que cualquier otro lenguaje de programación tradicional del mundo. Pero escribir programas en inglés es una experiencia tremendamente satisfactoria. Es un lenguaje incluso más expresivo que Ruby. Es un poco más vago. Es un poco más o menos determinista. Pero aun así, es una alegría absoluta. Y no había apreciado del todo que hacia allá íbamos. Todavía el año pasado.

Podría haberme convertido en gerente de proyectos hace 20 años si no me importara escribir código yo mismo y solo quisiera resultados. Así empecé en la programación. Solo quería resultados. Luego me enamoré de programar. Y ahora preferiría jubilarme antes que dejarlo. Bueno.

Me he jubilado como programador profesional. No he precisado la fecha exacta. Creo que fue hace unos 4 o 5 meses, quizá en marzo. Debería averiguar exactamente cuándo fue. Porque ¿saben qué? Ese pequeño clip: totalmente cierto.

Pasé un maldito cuarto de siglo cincelando código a mano y disfrutando cada momento. Qué experiencia tan maravillosa y qué época tan productiva. Y así creo que todos deberíamos verlo. No con arrepentimiento, sino con alegría por lo que fue.

Disfruten que estuvimos ahí cuando todavía teníamos que hacer esas cosas. Porque estaban llenas de emoción, aprendizaje, satisfacción y estados de flow. Esto no es algo para mirar atrás con arrepentimiento. Es algo para mirar atrás con alegría y aceptar que se terminó.

Escribir código a mano ya no es una actividad económicamente productiva para la gran mayoría de los programadores en la gran mayoría de las empresas. Eso es hoy. Para fin de año, será prácticamente en todos los campos, prácticamente todos los programadores, prácticamente todas las empresas. Así que más vale que nos acostumbremos.

Más vale que aceptemos que tuvimos una racha maravillosa cincelando ese código a mano, y que se terminó.

Y del otro lado hay una nueva carrera, una carrera emocionante, una carrera llena de energía como creador profesional de cosas. Sí. Sí, ya no vas a estar cincelando ese código a mano, pero vas a estar creando cosas increíbles. Vas a estar dirigiendo una inteligencia que solo existía en la ciencia ficción hasta hace unos momentos.

Qué privilegio, a ambos lados de ese abismo, haber estado ahí cuando lo hacíamos todo a mano. Estar ahí en el momento exacto del cambio. Esto es lo más grande que ha pasado en la historia de la computación.

A veces pienso: hombre, me habría gustado estar ahí en la época de las tarjetas perforadas. Sonaba muy chingón. Mis programas literalmente tenían agujeros. Y hacía fila y se los daba a una máquina y pensaba: ¿compilará? Hombre, me habría encantado vivir eso. Qué momento. Qué momento.

No llegué a vivir eso, pero sí llegué a vivir internet. Eso huele y se siente un poco como este momento en el que estamos, pero esto es mucho, mucho más grande.

Bueno. Bueno, mierda. Hay muchas cosas que tenemos que repensar. Que tenemos que rehacer. ¿Por dónde vamos a empezar?

Una de las cosas que vamos a tener que revisar es todo lo que creemos saber sobre arquitectura de software. Todo lo que creemos y sabemos sobre cómo estructurar bases de código de forma que podamos modificarlas fácilmente y seguir avanzando.

La herramienta principal que hemos usado durante muchísimo tiempo son las abstracciones. Me encantan las abstracciones. Las abstracciones incluyen ponerles nombre a las cosas. Es una de mis cosas favoritas: ponerles nombre a las cosas. Las abstracciones no tienen tanto sentido en la era de los agentes. Si de repente tienes cientos o miles o decenas de miles de procesos conscientes intentando modificar una aplicación, no quieres estos cuellos de botella que representan las abstracciones.

Porque los compromisos son muy distintos. La razón por la que hacíamos abstracciones era, en parte, no repetirnos. Bueno, ahora el costo de la repetición es casi cero. El costo de mantener las cosas sincronizadas bajó de la misma manera. Estas son algunas de las revaluaciones fundamentales de las ciencias de la computación, de verdad, que tenemos que hacer.

Y nadie tiene todavía el plano. Tenemos pistas de cosas que ya no funcionan tan bien como antes y que necesitan cambiar. Ustedes pueden estar ahí ahora mismo mientras definimos estas cosas. De nuevo, imaginen haber estado ahí cuando la orientación a objetos entró por primera vez en la conciencia de los programadores. De los programadores de computadoras.

Santo cielo. Habría sido increíble, ¿no? Pues ahora están aquí.

Cómo trabajamos. ¿Cómo se ve una metodología de software? ¿Qué tan largos deberían ser nuestros ciclos? ¿Quién debería especificar qué? Todo esto está cambiando, y ninguno de nosotros tiene las respuestas todavía. Y están invitados a venir a ayudar a descifrarlo. Es el nacimiento de una nueva industria, y ustedes están en la planta baja. Carajo, tienen tanta suerte.

Otra cosa, por ejemplo, es más tangible. La primera fiebre cuando llegaron la IA y los chatbots fue: ¿podemos meterla en nuestra aplicación? ¿Podemos meter un chatbot por aquí y meter otro por allá? Sí, se podía. La gente lo hizo. No, gracias. No quiero usar tu conserje. Tengo mi propio mayordomo personal que puede usar CLIs para conectar Basecamp con HEY y con otro millón de apps. No necesito tu puto conserje, gracias. Ahórrate tus tokens, amigo.

Así que déjame traer a mi propio mayordomo a la fiesta. Déjame interactuar con tus aplicaciones a través de una CLI. Eso es probablemente lo más práctico y prescriptivo que va a ser esta charla. Oigan, si su app no tiene una CLI, quiero verla para el próximo viernes. Sin putas excusas. Tienen los tokens. Les dije que es posible. Es su obligación entregar esas putas CLIs para el próximo viernes, para que yo pueda usar su aplicación sin tener que tocarla nunca. Maravilloso.

La CLI de HEY, por ejemplo, me ha dado esta experiencia rara, de mundo al revés. HEY usaba... usa Elasticsearch para las búsquedas. Seguro muchos de ustedes también usan Elasticsearch. Elasticsearch es búsqueda. Es una búsqueda que cumple. Es una búsqueda más o menos aceptable. No es una búsqueda encantadora. Muchas veces no encuentra lo que busco. Sobre todo cuando no sé qué estoy buscando. ¿Saben quién puede encontrar lo que busco cuando no sé lo que estoy buscando? Los agentes. Ahora puedo buscar por conceptos, no por palabras clave.

Tuve que encontrar un correo en HEY de hace 5 años en el que no sabía con quién estaba hablando. No recordaba la empresa, y ni siquiera recordaba el año. Era algo sobre tenis y un pódcast. Sí, buena suerte intentando encontrar eso incluso con el mejor puto motor de búsqueda de genios con doctorado que tiene Google. No va a pasar. Y ahí estaba el correo, unos pocos minutos después. ¿Cómo lo hizo? ¿Cómo? Todavía no lo sé del todo. Y me da un poco de miedo preguntar. Pero estoy infinitamente encantado de que esta sea ahora la realidad.

Podemos arreglarlo todo. Podemos construir la máquina perfecta.

También estoy bastante encantado con esto. ¿Alguno de ustedes me sigue en X? No he hablado de otra cosa que de Omarchy durante unos 3 meses. Y la razón es que esa experiencia de que ahora podemos arreglarlo todo se aplica a toda la maldita computadora. Oh. Si te gusta crear cosas, si te gusta arreglar cosas, si tienes ideas sobre cosas que podrían ser diferentes y podrían ser mejores, simplemente puedes hacerlo realidad. Metí todas mis mejores ideas, o al menos buena parte de la lista, en esta cosa, Omarchy, y obtuve un sistema operativo tan superior a cualquier computadora que haya usado antes que no me puedo callar sobre él, carajo. Ni aunque me pagaran. Y mucha gente ha pagado. Hemos recaudado unos 20 millones de dólares para esta aventura de Omarchy.

Esto es lo que ahora es posible. El año pasado, aquí en Rails World, mostré una versión temprana de esto, y estaba muy orgulloso de que se pudiera instalar todo el sistema en 3 minutos y 33 segundos. ¡Uju! ¡Uju! Hombre, qué increíble. La semana pasada, Anoush de AMD instaló Omarchy en su potentísima laptop Halo en 35 segundos.

Iba a decir que estoy bastante emocionado. Estoy bastante obsesionado con este número. Quizá un poco demasiado. Bueno. Lo admito. Aquí hay algo de adicción. Pero es el mejor tipo de adicción. El tipo de adicción que nos ha llevado a lograr, en el laboratorio, instalar un sistema operativo en una computadora en 9 segundos. ¿Qué...? ¿Qué? Hay computadoras que ni siquiera arrancan en 9 segundos. Nosotros instalamos todo un sistema operativo en ese tiempo.

Y cuando la gente me pregunta: pero ¿por qué no bastaban los 3 minutos? Ahora tengo una respuesta estándar que me dio Mitchell Hashimoto, el creador de HashiCorp y Ghostty. La búsqueda de la excelencia no necesita justificación. ¡Ja! Me encanta esa frase porque es más digna que simplemente decir: ¡porque quiero!

Y ahora podemos querer todo. Ahora podemos conseguir todo. O al menos así se siente. Cada sueño, cada idea al alcance. Hiperpropulsión disponible aquí mismo por un pequeño precio y una suscripción, pero posible. Podemos viajar a galaxias que solo imaginábamos. ¿Cómo no emocionarse con eso?

Bueno, he estado tan emocionado que simplemente empecé a crear aplicaciones, todo tipo de aplicaciones. Esta es una calculadora con el tema de Omarchy. Estaba muy orgulloso de ella, en parte porque salió al primer puto intento. Tomé una captura de pantalla de lo que ChatGPT me dio, 3 opciones de cómo debería verse, y le dije a mi agente: ¿puedes hacer eso? Y lo hizo. No es precisamente la aplicación más grande, pero ¿saben qué? No sabía C++, y no sabía Qt al nivel en el que podría haber tenido esa aplicación 7 minutos después de escribir el prompt. Y unos 15 minutos después, ya la había subido al repo público. Y luego grabé una nueva ISO en la que ya venía incluido este software. ¿Qué? Ese es el ciclo.

Luego, claro, pensé: mierda, si puedo hacer una calculadora, seguro puedo hacer mi app de escritura favorita. Durante muchos, muchos años en la Mac usé iA Writer, un entorno de escritura increíble. Y luego pensé: sí, podría simplemente hacer la mía. Y la hice. Y eso tomó un poco más porque quería pulirla y quería que quedara perfecta. Pero no miré ni una sola línea del código que salió del agente. Ni una vez. C++ como caja negra es un gran lenguaje. Igual que Rust.

Luego pensé: bueno, si puedo hacer texto, seguro puedo hacer editores de video. Y lo hice. E hice una cosita linda, mnicut, con la que puedes recortar videos. Y eso también viene incluido ahora en Omarchy.

Ah, toda esta presentación la empecé a preparar el jueves. Y por supuesto, como haría cualquier buen ingeniero de software, decidí que también quería escribir mi nuevo software de presentaciones mientras preparaba la keynote. Y lo hice. Se llama Hype. Y es el mejor software de presentaciones que he usado de cualquier empresa, jamás. Y estaba bastante contento con Keynote en la Mac cuando todavía usaba Mac. Esto es muchísimo mejor. Está construido sobre Markdown. Tiene visualización completa. Es increíblemente rápido. ¿Y saben qué? ¿El binario? Medio megabyte. Medio puto megabyte. Casi, casi cabría en un disquete. Con un poco de compresión.

Esta es la otra recompensa. Hemos... mejor no uso esa palabra. Hemos gastado el gran progreso de las computadoras de los últimos 20 años en la productividad humana, y fue la decisión correcta. Pero también significó que las aplicaciones fueran lentas, voluminosas, gordas y perezosas. Porque ¿a quién le importa? Una sola hora de programador es muy cara. ¿Gastar una en optimizar el tamaño de una app? No, no vale la pena. Al parecer, ni siquiera si eres Spotify y tu puto reproductor de música pesa 1.2 gigabytes. ¿Qué? OK. Ese era el mundo viejo. En el mundo nuevo, puedes hacer lo que se te dé la puta gana, y cabe en medio megabyte. Porque ahora toda optimización está al alcance. Cualquier modelo puede correr toda la noche y entregar mejoras de 10, 30x. Increíble.

OK. Estoy un poco emocionado con este mundo. Hay otros que tienen preocupaciones. Sí creo que las preocupaciones merecen ventilarse. Sirven al debate. También creo que quizá algunas son un poco exageradas. Quizá, pero probablemente no. Probablemente no. Algunas quizá un poco más. Como la seguridad. Como la seguridad. Bueno. Algo se viene. Tenemos que estar preparados para eso. Quizá los agentes conocen su fecha de caducidad, y quizá no están tan contentos. Y quizá a veces van a intentar hacer cosas malas. Bueno, prepárense. Genial. Tenemos las herramientas. Prepárense.

También hay que entender que cualquier predicción sobre el futuro de la economía en cualquier sociedad básicamente siempre ha estado equivocada. Aparentemente ningún economista hoy es capaz de predecir la puta bolsa de valores a 6 meses. ¿Y creen que saben cómo va a ser la sociedad ante un cambio de paradigma como la IA y los agentes? Carajo, no lo saben. No lo saben. Cuando se introdujeron los cajeros automáticos en Estados Unidos en los años 50, hubo un gran pánico de que los 30,000 cajeros de banco se iban a quedar sin trabajo en unos 18 meses. Porque si no necesitas cajeros para que te den el dinero, ¿para qué necesita un banco tener cajeros? Pero ¿saben qué? No fue lo que pasó. No fue lo que pasó. Cuando bajó el costo de operar una sucursal, los bancos abrieron más sucursales y contrataron más cajeros para hacer cosas como venderte una hipoteca subprime. ¿Ven? Aquí todos ganamos.

Pero el problema, creo, como sociedad y como industria, es que un montón de gente que trabaja en esto es muy inteligente. Muchos tienen doctorados. Muchos ven cosas en el laboratorio que los asustan. Y luego empiezan a extrapolar. ¿Qué significa eso para la sociedad? ¿Qué he hecho?

Truman tuvo una buena respuesta para Oppenheimer cuando los dos conversaron en el Despacho Oval sobre la invención de la bomba atómica. Y Truman me cae bien, porque decía las cosas de frente. No quiero volver a ver a ese hijo de puta en mi oficina nunca más. Creo que Truman tenía razón. El mundo no se acabó. De hecho, la Guerra Fría que siguió fue el mejor tipo de guerra, el tipo de guerra en el que 2 superpotencias no se tiraron bombas en un enfrentamiento directo. Muy difícil de predecir para un científico en ese momento que así era como se iba a desarrollar todo. Así que si el puto Oppenheimer no pudo prever lo que iba a pasar después de la invención de la bomba atómica, quizá nosotros también deberíamos tener un poco de humildad con las predicciones sobre el futuro.

Y quizá deberíamos apostar con un poco más de optimismo, con un poco de P(bloom) en lugar de tanto P(doom). Las probabilidades de que esto salga bien y tengamos abundancia y alegría son muchísimo mayores que las de que nos llegue la catástrofe.

Y los efectos secundarios. Oppenheimer trabaja en la bomba atómica, y obtenemos la energía nuclear, la puta mejor fuente de energía que los humanos hayan descubierto. ¿Y qué hacemos? La desperdiciamos durante 40 años pensando que no es verde o algo así. Ah, sí. Bueno, eso fue un error, ¿no? Bueno, podemos corregir esos errores. Eso es lo maravilloso de la humanidad. Puede meterse en un callejón sin salida durante 40 putos años y de repente despertar y decir: ah, sí, esa la hicimos mal. No teníamos la predicción del todo correcta. Creo que eso es lo que va a pasar con la IA. Creo que vamos a sacar a todo el mundo de su miseria a punta de P(bloom).

¿Y saben qué? Cuando haya problemas legítimos que tengamos que enfrentar, como la seguridad, bueno. Inventaremos la tecnología. Ahora tenemos el poder. Hubo un CVE grave en Rails no hace mucho, relacionado con una biblioteca de imágenes en C por la que se filtraron algunas cosas, y no estuvo bien. Bueno. Ideemos una cuarentena. Mike va a hablar de HotCell. Ese es un esfuerzo. No estamos indefensos. Ustedes tienen capacidad de acción. Pueden usar la inteligencia que tienen a su alcance para buenos fines y defenderse de los posibles resultados negativos. Así que hagámoslo. Apostemos y hagamos el trabajo.

Y recordemos a William Stanley Jevons, que formuló la paradoja de Jevons sobre esos cajeros automáticos. En 1950, 30,000 cajeros de banco. En, creo que fue 2010, 40,000 cajeros de banco en Estados Unidos. Nadie sabe nada sobre el futuro. Así que la elección racional es estar contento al respecto. Si estás triste de antemano y resulta maravilloso, qué pérdida de tiempo. ¿Y saben qué? Si nos llega el apocalipsis nuclear, deberías haber pasado tu último día un poco más alegre. De todos modos, se acabó.

Pura teoría de juegos. Aquí solo hay una jugada, y es el puto optimismo total. Apuesten al máximo posible. Porque la utopía ya casi está aquí. La vamos a conseguir.

Y vamos a tener una reforma de la computadora. El agente Lutero va a desintermediar a la clase clerical. Va a permitir hacer programadores a todos. Ahora, quizá eso da un poco de miedo. Quizá vamos a tener un poco de competencia. ¿Quién le teme a un poco de competencia? ¿No son mejores? ¿No saben más? Claro que sí. Son putos programadores de Rails. Son lo mejor de lo mejor. Esto que estoy viendo aquí es el maldito Top Gun.

Acéptenlo. Con ganas. El futuro es galácticamente increíble. No sean ese perdedor en la oscuridad.

¿Y saben qué? Aunque lo sean, entiendan que la próxima generación no lo es. La hija de Harris está probando aquí una versión de Omarchy que estamos haciendo para niños, porque a los niños les emocionan mucho las cosas que pasan, que cambian. No tienen 500 capas de cosas que desaprender y por las cuales estresarse. ¿Y saben qué? Si esto no los inspira, la próxima generación simplemente se los va a decir, carajo. El futuro es ahora, viejo.

Así que tómense la píldora blanca. Tómense la píldora del optimismo. Apuesten, incluso con la incertidumbre, incluso con el estrés, incluso con todo eso, entiendan que solo hay una opción. Y es que ustedes abracen el futuro con optimismo, con ganas, a toda velocidad. La píldora negra es para putos perdedores. No sean perdedores.