Escribo esto mientras tengo 3 ventanas de Claude Code abiertas, corriendo y trabajando en algunos “side-projects” / ideas. No son ideas nuevas; son simplemente ideas que tuve por muchos años y que, por falta de tiempo principalmente, y en algunos casos por estar limitado mi conocimiento, me eran imposibles de avanzar, o las comenzaba, pero luego las abandonaba.
Lo primero que se me viene a la mente es todo lo que “creé” o cocreé en el último mes y medio cuando me puse en serio a aprender las capacidades de Claude Code. Una app publicada en el App Store, otra en camino, una beta de un videojuego para publicar en Steam en los próximos meses, y ahora briefcase, una web app sobre un entorno privado, replicando aquella hermosa utilidad de Windows para llevar archivos y usarlos en otra computadora (sin dudas, un precursor de Dropbox).
Es rara la sensación para alguien que dedicó toda su carrera profesional y que seguramente tiene la mitad aún por delante, de ver un cambio tan profundo en la disciplina en tan pocos meses. No se confundan: los cambios han sido algo habitual en tecnología, pero el ritmo para ponerse “a tiro” era alcanzable; la forma de programar con lenguajes de alto nivel, como en mi caso, tecnologías de front end y php, no había cambiado tanto en 20 años. Si habían madurado, se habían profesionalizado y se habían convertido realmente en ciencias de la computación, con sus prácticas, técnicas y estandarizaciones. Pero desde que fueron incorporados este tipo de lenguajes que abstraen del lenguaje de máquina, no hubo en la tarea de un programador, un cambio tán radical.
Lo primero que se te viene a la mente, una vez que entendés que la tarea en sí cambia, es algo raro de describir: al tipear el código, al menos cuando uno trabaja solo, es claro quién hizo qué. Pero aquí, uno conversa, Claude Code crea un plan, uno lo revisa, hace correcciones y luego se ejecuta para tener, en unos pocos minutos, una primera versión funcional, sobre la que uno puede iterar rápidamente. ¿Es el equivalente a diseñado en California y hecho en China? ¿Son los chinos quienes hacen los iphones? No sé si es válida esa afirmación, ya que aquí el plan, gran parte de él, lo hace la IA. Y por otro lado, China tiene grandes teléfonos de Huawei y de Xiaomi, seguramente producto de entender cómo Apple diseña sus teléfonos. ¿Estamos enseñándoles también cómo pensamos en arquitectura de software, para perfeccionar sus datos de entrenamiento?
Marx, en 1844, postuló que la alienación era la deshumanización del trabajador bajo el capitalismo, quien perdía el control sobre su trabajo, su producto y su esencia humana. Al convertir el trabajo en mercancía, el obrero se siente extraño a su labor, produciendo para otro y reduciendo su vida a la mera subsistencia. Pero aquí, parece que el concepto fuera al revés, si quien hace el trabajo es la inteligencia artificial, ¿estamos nosotros despojándoles de su producto? O nosotros, al alejarnos del “craft”, nos estamos despojando de nuestra humanidad también.
Hay otro tema que también me tiene pensando habitualmente: el esfuerzo cognitivo. En mi carrera, en especial como autodidacta, los proyectos siempre fueron mi manera de aprender. Cuando quería hacer algo, un juego, un portal web, modelar algo en 3d, tenía que pelearme horas con una herramienta, una librería, entender su funcionamiento hasta que “lo entendía” y podía hacerlo funcionar. Ahora, al pedirle a la inteligencia artificial que haga todo el trabajo de tooling, setup, programación, ese esfuerzo cognitivo desaparece. Hice una app con Swift por primera vez, con integración con iCloud, sin tener que aprender su sintaxis. Como esto no se siente bien para mi, le pedi a Claude Code, que me haga una guia de los conceptos de swift, con ejemplos del app, y recursos adicionales para entender completamente su funcionamiento, pero esa guia, al solo leerla no va a producir ese esfuerzo cognitivo, y me estoy forzando en hacer alguna que otra feature de manera “manual” para aprender.
Pero es realmente un buen uso del tiempo aprender eso, ¿Si no va a importar tanto en qué esté hecho algo en los próximos meses? Si la producción de código baja a cero, creo yo que es más importante aprender a trabajar con los diferentes modelos, evaluarlos, armar workflows y prácticas correctas de verificación, que lo producido realmente no sólo sea más rápido, sino también mantenible y de mejor calidad que lo que podamos hacer nosotros.
Definitivamente no tengo ninguna respuesta a todo esto que menciono arriba, son solo reflecciones, pero aunque suenen pesimistas o un estado de gran confusión, puedo decir que a la vez, hacia muchos años que no disfrutaba de construir cosas.
