Te ascendieron sin preguntarte: de escribir código a dirigir software

Hace unos días leí la transcripción de una conversación entre dos personas que cambiaron la historia del software: Yukihiro "Matz" Matsumoto, creador del lenguaje Ruby, y David Heinemeier Hansson (DHH), creador de Ruby on Rails, el framework sobre el que se construyeron empresas como Shopify y GitHub.

Lo que me detuvo fue una frase de Matz. Contó que desde noviembre programa casi todo con un agente de inteligencia artificial. El hombre que inventó el lenguaje ya casi no lo escribe a mano. Si ellos cambiaron su forma de trabajar, esta noticia no es solo para programadores, es para cualquiera que construya algo con tecnología. Por eso este artículo está escrito para tres tipos de lectores: los programadores puristas, los profesionales que resuelven problemas con datos y herramientas, y los emprendedores que quieren construir algo propio.

Quiénes son y por qué importa lo que dicen

No hablan como analistas desde afuera. Son dos personas cuya identidad profesional está atada a escribir código, y aun así describen un cambio propio, sin dramatismo y con bastante honestidad. Matz admite que tiene "un ego enorme" con Ruby y que toda su vida depende de él. DHH cuenta que en la primera versión de Rails escribió todo él, en la segunda la mitad, y para la sexta y la séptima casi nada: solo dirección. Decidir hacia dónde ir, qué entra y qué sale.

Esa es la idea central de toda la charla: pasaron de escribir a dirigir.

Los cinco mensajes que sostienen la conversación

1. Aceptar lo que ocurre. DHH no habla de predicciones, habla de probabilidades. Su lectura es que por más que uno negocie con la IA, ella no cambia su trayectoria. Compara la reacción del gremio con las etapas del duelo: negación, enojo, negociación, tristeza y aceptación. Y agrega algo que me gustó: hay espacio para la nostalgia. Nadie tiene que fingir que no extraña lo que amaba.

2. Pasar de escritor a hacedor. El valor humano deja de estar en teclear líneas y pasa al gusto, el criterio y el sentido de proporción. Matz lo dice sin adornos: hoy trabaja con la IA como trabaja con los committers de Ruby. Pide una mejora, recibe una propuesta, la revisa y decide si entra.

3. No es un tema de un lenguaje. DHH insiste en que esto llega a todos los lenguajes y dominios. Casarse con el siguiente lenguaje de moda sería repetir el error, porque los bandos se están disolviendo.

4. El pastel no es fijo. Las aplicaciones que existen hoy van a requerir muchos menos programadores para mantenerse. Pero se van a crear muchísimas más. Su optimismo se apoya en eso: habrá más software que atender, no menos.

5. Lo que permanece es la alegría. Para Matz, la mayor contribución de Ruby al mundo no fue técnica sino humana: recordar que la alegría, la motivación y la libertad son recursos productivos. Y esos recursos, dice, los ponen los humanos, no las máquinas.

La analogía que me hizo sentido: el aserradero

Llevo más de 20 años en la industria maderera peruana, y cuando leí esto no pude evitar ver un aserradero.

Imagina al aserrador de toda la vida. Conoce cada troza, sabe por dónde cortar para sacar el mejor rendimiento, y su oficio es real y respetable. Ahora llega una línea automatizada con escáner que optimiza el corte. Nadie serio pregunta si el escáner "es mejor que la mano del maestro" en el corte individual. La pregunta importante es otra: ¿quién decide qué se corta, para qué pedido, con qué rendimiento y con qué calidad?

Ahí aparece el maestro de verdad. Su ojo ya no sirve para empujar la sierra, sirve para decidir qué debe producirse. Eso es exactamente lo que DHH llama gusto y sentido de proporción, y es lo que sigue siendo humano.

La analogía tiene más capas:

DHH usa una imagen parecida: no puedes agarrar el lápiz tan fuerte que no imagines lo que una calculadora puede hacer por ti.

Qué significa esto para cada uno

Si eres programador purista

Tu identidad puede sobrevivir a tu práctica. La pregunta que hizo el moderador, "¿qué queda cuando uno se llama rubista pero ya no escribe Ruby?", es dura, y no tiene respuesta rápida.

Lo que sí veo es que los mismos Matz y DHH sostienen que Ruby puede seguir siendo el lenguaje en el que los humanos leen y entienden lo que las máquinas producen. Un agente puede generar el código en otro lenguaje y explicártelo en el que prefieres. Tu ventaja es entender el porqué, auditar y rechazar lo que está mal. La artesanía no muere: cambia de lugar. Pasa de ser el estándar a ser el criterio.

Si eres profesional (analista, jefe de planta, administrador)

Para ti, la barrera de entrada bajó. Ya no necesitas ser programador para crear una solución a tu medida: un tablero, un control de trazabilidad, una automatización que hoy haces a mano en Excel.

Pero fíjate en lo que exige esa nueva capacidad. La habilidad crítica deja de ser escribir y pasa a ser definir bien el problema. Quien sabe exactamente qué necesita, cuáles son las reglas de su proceso y qué resultado es aceptable, está en ventaja. Eso lo tienes tú, y no lo tiene una máquina.

Si eres emprendedor

Construir un producto digital cuesta una fracción de lo que costaba y sale al mercado en menos tiempo. Eso también lo sabe tu competencia. La ventaja ya no está en poder construir, está en conocer un problema del negocio con tanta profundidad que sepas exactamente qué construir.

Por eso creo que los emprendedores con años de experiencia sectorial tienen una oportunidad enorme. Cuando construyo herramientas para la industria forestal, lo que me da ventaja no es saber programar mejor que nadie, es haber vivido los problemas de trazabilidad, despacho y almacenamiento en planta durante dos décadas.

El contrapunto: lo que no me convence

Sería deshonesto dejarlo así, sin objeciones.

• Hay sesgo de interés. Ambos son figuras de un ecosistema que necesita seguir siendo relevante. DHH, en particular, vende optimismo con mucha convicción.
• Varias afirmaciones no tienen evidencia. Que la crítica al "slop" sea "90% cope", que los costos van a bajar sí o sí, o que iremos hacia el código máquina, son apuestas. Razonables para algunos, pero apuestas.
• Sus casos de éxito son de expertos. Matz cuenta que los committers de Ruby tienen una tasa alta de éxito programando con IA. Eso demuestra que dirigir bien exige saber qué pedir, no que cualquiera pueda hacerlo desde cero.
• Falta una respuesta a cómo se forma el criterio. Si el criterio es lo que nos queda, ¿cómo lo desarrolla la próxima generación si nadie escribe código? Nadie en el panel lo resolvió.
• El riesgo de Matz es real. Si los componentes de código abierto sobre los que se apoya todo se vuelven invisibles, ¿quién los mantiene? Esa preocupación merece más atención que el entusiasmo.

Conclusión: dejar de ser el intermediario

Una de las ideas más prácticas de la charla es el llamado "meat proxy": la persona que se queda copiando y pegando mensajes de error entre un sistema y otro. DHH lo dice sin filtro: es una tarea poco satisfactoria y poco efectiva, y hay que salirse de ese rol.

Creo que eso aplica mucho más allá del código. Cada uno de nosotros tiene tareas en las que hace de intermediario entre sistemas que deberían comunicarse solos: pasar datos de un Excel a otro, transcribir información de un formato a otro, repetir verificaciones que una regla clara podría hacer sola.

Te dejo un reto para esta semana: identifica una tarea que hoy haces a mano y pregúntate qué pasaría si la dirigieras en lugar de ejecutarla. No hace falta que la automatices ya. Basta con definir con claridad qué resultado esperas y qué reglas debe respetar.

Y una pregunta para cerrar, porque quiero leer tus respuestas: ¿te sientes hoy más escritor o más director de lo que haces?

Si este tema te interesa, cuéntame en los comentarios desde qué lado lo ves: programador, profesional o emprendedor.