Nunca fue tan fácil producir código. La máquina completa funciones antes de que terminemos de formular el problema. Genera tests mientras todavía estamos decidiendo qué testear. Propone arquitecturas cuando apenas empezamos a entender el dominio. Por primera vez en la historia del software, escribir dejó de ser la parte más lenta de programar.

Y eso, que suena a liberación, esconde una trampa sutil.

Porque la velocidad de la herramienta puede crear la ilusión de que también se aceleró el entendimiento. Antes, el cuello de botella estaba en los dedos: traducir una idea a sintaxis consumía tiempo, atención, esfuerzo. Ahora ese cuello de botella volvió a estar donde siempre debió estar —en la cabeza— pero sin que nos hayamos preparado para sostenerlo.

La era del copiloto no eliminó la fricción. La desplazó. Y si no registramos ese desplazamiento, corremos un riesgo profundo: producir cada vez más código con cada vez menos claridad.

Vivir deliberadamente, programar deliberadamente

En 1845, Henry David Thoreau se retiró a una cabaña junto al lago Walden. No buscaba aislamiento ni rechazaba la civilización. Buscaba algo más preciso: dejar de vivir por inercia. “Fui a los bosques porque quería vivir deliberadamente”, escribió en Walden. “Enfrentar solo los hechos esenciales de la vida, y ver si no podía aprender lo que ella tenía que enseñar, y no descubrir, cuando llegara la hora de morir, que no había vivido.”

La palabra clave es deliberadamente. No lentamente. No nostálgicamente. Deliberadamente: con intención, con elección, con conciencia de lo que se hace y por qué.

Thoreau no estaba en contra del progreso. Estaba en contra de dejarse arrastrar. De que la velocidad del mundo exterior dicte el ritmo del mundo interior. De confundir movimiento con dirección.

Hoy, frente a un copiloto que completa código más rápido de lo que podemos leerlo, la pregunta de Thoreau vuelve con fuerza inesperada: ¿estamos eligiendo cómo trabajamos, o estamos siendo arrastrados por la velocidad de la herramienta? ¿Estamos programando deliberadamente, o simplemente aceptando lo que aparece en pantalla porque llegó rápido y se ve razonable?

El verdadero riesgo de una época acelerada no es correr mucho. Es dejar de elegir el ritmo.

Knuth y el código escrito para humanos

Si Thoreau ofrece el marco existencial, Donald Knuth ofrece la encarnación técnica de esa misma ética.

Knuth es, para muchos, uno de los más influyentes científicos de la computación vivos. Su obra monumental —The Art of Computer Programming, que comenzó en 1962 y sigue en proceso— es un monumento al rigor, la profundidad y la paciencia intelectual. Pero hay otra contribución suya, menos citada y quizás más relevante para este momento: Literate Programming.

La idea es radical en su simplicidad: un programa no debería escribirse para la máquina, sino para un ser humano que necesita entenderlo. Knuth proponía que el código y su explicación fueran una misma cosa —un texto coherente donde la lógica se despliega como un argumento, no como una secuencia opaca de instrucciones.

“Los programadores deberían ser vistos como ensayistas”, escribió Knuth. No porque programar sea literatura, sino porque programar es —en su mejor versión— organización deliberada del pensamiento. El código no solo debe correr: debe poder ser comprendido. No solo debe funcionar: debe poder ser explicado.

En su conferencia “Computer Programming as an Art” (1974), Knuth fue más lejos: defendió la programación como práctica intelectual y formal, no como mera ejecución mecánica. La computadora ejecuta; el programador da forma. Y la forma importa.

La ética de Knuth no es lentitud romántica. Es respeto por la claridad. Es la convicción de que un programa escrito sin cuidado no es solo un programa feo: es un programa que generará confusión, errores y deuda técnica mucho después de que su autor haya olvidado por qué lo escribió así.

La paradoja del ensayista

La IA desplomó el costo de generar código. Todo lo que antes consumía horas puede aparecer en segundos. No tiene sentido defender la escritura manual de código repetitivo como si fuera una virtud.

Pero la abundancia de código produce un efecto que Knuth no anticipó y que sin embargo su obra ilumina mejor que ninguna otra.

Knuth pedía que el programador fuera ensayista: que el código fuera un argumento, una narración coherente donde cada decisión se explica y cada nombre se elige con cuidado. Esa exigencia asumía algo que ya no es cierto: que el programador es el autor del código.

Hoy, el copiloto escribe. El programador recibe. El código llega sin narrativa, sin explicación de por qué está así y no de otra manera, sin registro de qué alternativa se descartó ni qué nombre se eligió y por qué. Llega como artefacto funcional, no como argumento intelectual.

Y sin embargo, la exigencia de Knuth no desapareció con la autoría. Se volvió más urgente. Porque alguien tiene que darle forma intelectual a lo que la máquina produjo. Alguien tiene que convertir el artefacto en argumento, el output en explicación. Alguien tiene que poder decir por qué este código resuelve este problema de esta manera, y no de las otras tres maneras que también compilaban.

Literate programming en la era del copiloto no es escribir código como ensayo. Es leer, evaluar y reescribir código ajeno hasta que se convierta en uno.

Qué debería seguir siendo lento

No todo debe desacelerarse. Hay cosas que conviene acelerar: la generación de boilerplate, la búsqueda de documentación, la escritura de tests repetitivos, la exploración inicial de soluciones. Acelerar eso libera tiempo y energía para lo que importa.

Pero hay zonas del trabajo técnico que deberían resistir la aceleración. No por nostalgia, sino porque la calidad del software depende de ellas:

  • Entender bien el problema antes de saltar a la solución. La primera respuesta plausible rara vez es la última respuesta correcta.
  • Definir nombres y conceptos. Nombrar es pensar. Un nombre mal elegido contamina la comprensión de todo el sistema. Knuth trataba los nombres como decisiones de diseño, no como etiquetas. Para él, un buen nombre no describe lo que el código hace: organiza cómo se piensa el sistema.
  • Narrar la solución. No solo implementar sino poder explicar por qué está así. Qué alternativa se descartó. Qué compromiso se aceptó. Si no podés narrar tu código como un argumento, quizás no lo entendés lo suficiente. Knuth diría que un programa que no se puede explicar es un programa que no se terminó de pensar.
  • Leer el código generado como si lo hubiera escrito otra persona. Porque lo escribió otra persona. Y esa otra persona no dejó notas, no explicó sus decisiones, no narró su razonamiento. Todo eso lo tenés que reconstruir vos. Un ejemplo cotidiano: el copiloto genera una función que extrae, transforma y persiste datos. Compila, tests pasan. Pero nadie puede explicar por qué ese manejo de errores está ahí y no una capa más arriba, por qué ese nombre y no el que usa el resto del equipo. Hasta que alguien narre esas decisiones, el código funciona pero nadie lo posee intelectualmente.
  • Decidir arquitectura. La arquitectura es una forma de lentitud productiva. Es el momento donde se define qué será fácil y qué será difícil durante años.
  • Discutir criterios con el equipo. Las decisiones técnicas más importantes no son individuales.

Cuanto más rápido aparece el código, más despacio debería aparecer nuestra confianza en él. No todo cuello de botella es un problema. Algunos protegen la calidad.

Programar deliberadamente en la era del copiloto

La salida no es rechazar la IA. Sería tan absurdo como rechazar la calculadora o el compilador. La salida es construir una relación más deliberada con ella.

La cuestión ya no es si vamos a trabajar con copilotos. Eso está decidido. La cuestión es qué tipo de disciplina intelectual vamos a sostener cuando los usemos.

Knuth ofrece una respuesta que va más allá de la cautela: exigir que el código tenga forma intelectual. No solo que funcione, sino que se pueda explicar. No solo que compile, sino que argumente. Esa exigencia no desaparece porque la máquina escribió el código. Al contrario: cuando el autor no es humano, la responsabilidad de darle forma intelectual recae enteramente en quien lo acepta.

Esto tiene una dimensión organizacional que no se puede eludir. Los rituales de desarrollo (code review, sesiones de diseño, discusiones de arquitectura) no son burocracia heredada de una época más lenta. Son espacios donde el código se convierte en argumento. En la era del copiloto, un code review no es solo verificar si el código funciona: es verificar si alguien puede narrar por qué está así.

Vivimos en culturas que premian velocidad. En ese contexto, la deliberación puede parecer un lujo. Pero es exactamente lo contrario: es la inversión que evita la deuda técnica del código que nadie entendió. Lo que se genera en segundos y se acepta sin narración puede costar años de mantenimiento.

No necesitamos una ingeniería más lenta. Necesitamos una ingeniería más deliberada. Una que use la velocidad de la máquina sin abdicar la claridad del pensamiento. Que genere con la IA y revise con la inteligencia que ninguna IA puede reemplazar: la que viene de entender el problema, de conocer el contexto, de asumir las consecuencias.

Programar deliberadamente no es programar por nostalgia. Es negarse a construir por inercia. Es recordar que la responsabilidad sigue llegando a nombre del humano, aunque el código haya sido sugerido por una máquina.

La pregunta ya no es cuánto código podemos generar. La pregunta es con cuánta deliberación queremos construir lo que ese código va a producir.

¿Qué partes de tu proceso sentís que se aceleraron sin que lo eligieras? ¿Dónde defendés todavía la lentitud? ¿Cómo cambia tu forma de trabajar cuando la herramienta va más rápido que tu pensamiento?