Durante mucho tiempo, programar bien fue el centro de nuestra identidad profesional.
Escribir código claro, escalable, fácil de mantener. Elegir el patrón correcto. Controlar la deuda técnica. No era solo una buena práctica: era el valor.
En los últimos meses, algo cambió de forma irreversible.
La IA ya no “acompaña” al programador. Programa. Hace one shots funcionales, refactors completos, tests razonables. Y lo hace en segundos, con una coherencia que hasta hace poco parecía ciencia ficción.
Pero el verdadero impacto no fue técnico. Fue identitario.
Lo más llamativo no fue ver código generado por una máquina, sino ver a programadores con muchos años de experiencia genuinamente incómodos. No tanto por miedo a quedarse sin trabajo, sino porque el rol tal como lo entendíamos empezaba a correrse de lugar.
Durante años dimos por hecho algo casi sagrado: Escribir buen código requería tiempo, experiencia y recorrido.
Hoy, una máquina puede hacerlo “suficientemente bien” en un instante.
Ese es el verdadero shock. No que la IA programe, sino que deja en evidencia que el valor del rol nunca estuvo solo en el código.
El problema nunca fue el clean code
Durante años confundimos el medio con el fin.
Nos formaron y nos autoformamos con una idea bastante clara: un buen programador es el que escribe código limpio, escalable y mantenible. Y eso sigue siendo relevante… pero ya no alcanza.
La IA pone este límite en evidencia de forma brutal. Si el código se puede generar, entonces el valor no estaba solo ahí.
He visto sistemas con arquitecturas impecables fracasar estrepitosamente. Y otros, con código imperfecto, prosperar y evolucionar.
¿Por qué? Porque el código no es el producto. Es una herramienta.
El verdadero valor siempre estuvo en otro lado:
- Entender el problema real.
- Decidir qué construir y qué no.
- Elegir trade-offs conscientes.
- Asumir deuda cuando corresponde.
- Diseñar sistemas que puedan cambiar sin romperse.
La IA no toma estas decisiones. Las deja en primer plano.
El código como medio, no como identidad
Cuando el código deja de ser escaso, deja de ser el centro.
Esto no implica que programar ya no importe. Implica que ocupa otro lugar en la escala de valor.
El código pasa a ser lo que siempre fue, aunque no lo admitiéramos: medio para materializar algo mayor una idea, un producto, un sistema.
Este cambio incomoda porque pega directo en cómo nos medimos. Muchos aprendimos a medir nuestro valor por:
- Lo elegante de una solución.
- Lo genérica de una abstracción.
- La cantidad de patrones que manejábamos.
Pero en un contexto donde una IA escribe código aceptable en segundos, esas métricas dejan de sostener el rol.
Lo que lo sostiene ahora es otra cosa: criterio.
Del programador al orquestador
Frente a este cambio, hay dos reacciones posibles. Aferrarse al rol clásico o evolucionar.
De esa evolución aparece con claridad una figura distinta: el orquestador.
El orquestador no deja de programar. Es alguien que entendió que su mayor aporte ya no está en escribir cada línea, sino en:
- Definir la arquitectura del sistema.
- Establecer patrones, límites y acuerdos.
- Delegar ejecución a la IA con intención clara.
- Revisar con ojo crítico lo generado.
- Asumir la responsabilidad final.
Este rol no es menos técnico, es más exigente. Pide mejores modelos mentales, más visión a futuro y una comprensión real de cómo los sistemas crecen, se rompen y se mantienen.
La IA ejecuta. El orquestador decide.
La arquitectura como lenguaje común
Cuando el código se vuelve abundante, la arquitectura se vuelve escasa.
No es lo mismo pedirle a una IA “resolvé este problema” que pedirle “implementá esta feature siguiendo una arquitectura feature-based, con separación clara entre dominio, infraestructura y UI”.
En el primer caso, la IA improvisa. En el segundo, opera dentro de un sistema de reglas.
Los patrones y las arquitecturas dejaron de ser discusiones teóricas para convertirse en un idioma de alto nivel para personas y máquinas. Son acuerdos, límites, carriles.
Quien no entiende arquitectura no puede evaluar lo que recibe. Quien sí la entiende, usa la IA como un multiplicador masivo de criterio.
En este contexto, saber arquitectura no es overengineering. Es poner orden en un escenario donde todo se puede generar.
El “prompt shooter”
Hay un perfil que hoy parece rendir muchísimo: el que tira prompts sin parar y resuelve tareas “a las patadas”.
Funciona… por un tiempo.
Ese enfoque genera cantidad, no solidez. El código compila, los tickets se cierran, pero el sistema se vuelve frágil, ilegible y difícil de modificar.
La combinación más peligrosa hoy es simple: base técnica débil + IA.
No construye seniority real. Genera una ilusión de productividad que se rompe cuando el proyecto crece y aparecen los costos reales: bugs, deuda escondida, decisiones mal tomadas.
La IA no disimula la falta de base. La expone más rápido que nunca.
Programar como hobby: la ventaja silenciosa
Hay una diferencia que no se puede fingir ni aprender rápido: cómo te vinculás con la programación.
Para algunos es solo un trabajo. Para otros, además, es curiosidad, exploración, disfrute.
No se trata de trabajar más horas. Se trata de que el interés no desaparece cuando termina el día.
Ese interés genera un efecto compuesto:
- Comprensión más profunda de estructuras.
- Mejor intuición para diseñar sistemas.
- Aprendizaje más rápido.
- Adaptación natural a cambios de paradigma.
En un mundo pre-IA, ambos perfiles podían convivir sin demasiada fricción. En el mundo post-IA, el que solo ejecuta tareas queda expuesto.
No es una custión moral. Es un privilegio que uno mismo se construye.
Donde realmente está el valor ahora
La IA no vino a reemplazar programadores. Llegó para desplazar el eje del rol.
El código sigue siendo importante, pero ya no es el centro. El centro ahora está en el criterio, la arquitectura, las decisiones y la responsabilidad.
El futuro no pertenece a quien escribe más código, sino a quien piensa mejores sistemas. Y ese rol, al menos por ahora, no se automatiza fácil.
Frente a este escenario, mi posición es clara:
No me define cuántas líneas de código escribo, sino las decisiones que tomo. Diseñar sistemas con sentido y hacerme cargo de ellos es lo que hoy le da valor al rol.
Ahí es donde elijo pararme.