El programador no desaparecerá por la IA, desaparecerá porque ya nadie quiere serlo

Una opinión técnica sobre el verdadero motor del cambio de paradigma en el desarrollo de software. El problema no es que la IA programe: es que los profesionales del resto del mundo nunca quisieron aprender a hacerlo, y por fin tienen quien lo haga por ellos.

1. La confesión: ya soy gerente, y no lo decidí yo

Cuando uso IA para programar ya no me siento programador. Me siento gerente de un laboratorio donde varios juniors programan con un nivel tan bajo de confiabilidad que hay que vigilarlos pedido tras pedido, bloque tras bloque, cada commit, cada test, cada decisión de arquitectura.

Mi stack principal es Python, FastAPI, PostgreSQL y React. He construido aplicaciones que funcionan en producción y he revisado código de gente mucho mejor que yo. No escribo desde el pánico ni desde la teoría. Escribo desde la mesa de trabajo, mirando lo que ya está pasando.

Cuando no uso la IA me siento programador. Y aun así, no me incomoda que aparezcan herramientas que prometan liberarnos del trabajo repetitivo. Al contrario: nos obligan a enfocarnos en lo que realmente aporta valor, que no es escribir líneas por escribirlas, sino interpretar el negocio y convertirlo en código. El giro está en que, históricamente, el programador ha tenido que hacer lo contrario: descifrar desde el código un dominio que no siempre conoce. Por eso, cuando el experto del negocio empieza a construir con ayuda de la IA, no está invadiendo la programación; está cerrando una brecha que siempre existió.

Y lo que está pasando es esto: el día que abrí mi editor de código (Windsurf o VS Code), dejé de codificar y empecé a corregir. Dejé de pensar en sintaxis y empecé a pensar en requisitos. Dejé de revisar pull requests humanos y empecé a aprobar diffs de un asistente que no se cansa, no se aburre, y no se ofende cuando le digo “esto está mal, vuelve a hacerlo”.

Cualquiera que use IA para desarrollar todos los días sabe a qué me refiero. La única pregunta honesta es: ¿cuánto tiempo falta para que ese laboratorio no necesite ya supervisión constante?

2. Lo que repiten los influencers

En el último año se ha consolidado en redes profesionales un coro tranquilizador que repite, con muchas variantes, una misma idea: los programadores no van a ser sustituidos por la IA. La argumentación popular es esta:

• “Las grandes empresas de IA están exagerando.” Dicen que el discurso “con la IA todos vamos a programar” es marketing puro, que la realidad es más compleja y que el oficio de programar requiere años de experiencia que no se reemplazan con un prompt.
• “La mayoría de la gente no quiere ni puede programar.” Argumentan que la programación sigue siendo difícil, que requiere paciencia, abstracción y rigor; que el ciudadano promedio nunca llegará a hacerlo bien.
• “Por lo tanto, el programador está a salvo.” El razonamiento se cierra solo: si los demás no programan y la IA no es tan buena como dicen, el rol del desarrollador profesional sigue intacto.

El coro suena sensato. Es cómodo. Y, a primera vista, parece responder con sobriedad a un discurso tecnológico exagerado. Pero parte de una premisa equivocada, y por eso llega a una conclusión equivocada.

3. Por qué se equivocan: el indicio ya está en los datos

El primer indicio de que el paradigma se mueve está en quienes supuestamente lo defienden. Las encuestas recientes de desarrolladores (Stack Overflow, JetBrains, GitHub Octoverse) reportan algo que en la sala de cualquier equipo de software ya es visible: una proporción creciente de programadores con experiencia está aceptando código generado por IA sin leerlo línea por línea. No es que confíen ciegamente en el modelo. Es que el costo cognitivo de revisar es más alto que la probabilidad de que algo grave se manifieste como consecuencia del código ofrecido por un agente entrenado con millones de dólares.

Vale la pena detenerse en eso, porque es contraintuitivo. Si los propios programadores seniors están dejando de leer el código, ¿no será que programar (la actividad de tipear caracteres en un editor) no es la parte del oficio que más valor aporta? ¿No será que tipear código siempre fue una tarea ergonómicamente incómoda, lenta y propensa a errores, y que la única razón por la que aún la hacen humanos es porque hasta hace muy poco no hubo alternativa?

“Cuando los seniors empiezan a saltarse la lectura del código, no es pereza. Es la primera señal de que la tarea ya está migrando hacia donde le corresponde.”

Y aquí aparece el segundo error de los influencers tranquilizadores: asumen que el lector promedio desea aprender a programar, cuando en realidad las personas que se están interesando en construir con IA lo que buscan es una forma más efectiva de desarrollar lo que tienen en mente, sin pasar por alguien que les cuesta caro y que tarda meses en entenderles. Los expertos del negocio (el gerente que conoce los flujos, el médico que vive la consulta, el comerciante que negocia con el cliente real, el ingeniero industrial que pisa la planta) no querían convertirse en programadores. Querían herramientas que tradujeran su conocimiento en soluciones reales. Y eso no es lo mismo.

4. El paradigma que muere: la exclusividad del código

En las plantas industriales que he visitado he visto el mismo patrón repetido durante años. El gerente de producción sabe perfectamente que necesita: un tablero con tres semáforos, una alerta cuando una línea baja del 80 % de OEE, un correo automático al supervisor cuando la temperatura se sale del rango. Lo dibuja en una servilleta en cinco minutos. Tres meses después, el proveedor de software entrega algo distinto, más caro de lo presupuestado, que además no encaja con el flujo real porque el ingeniero del proveedor nunca pisó el área de manufactura.

Ese desencuentro se repite en finanzas, marketing, medicina, ventas y logística. Durante décadas, el código fue exclusivo. No por elitismo, sino porque hace falta una formación larga para escribirlo bien, y eso lo encareció. Los expertos del negocio no tuvieron más opción que depender de un traductor humano caro y, además, difícil de gestionar.

Esa exclusividad se cae. Lo que llega a su fin no es el software ni el código abierto: es falso que GitHub vaya a colapsar, es falso que el open source vaya a desaparecer. Lo que termina es la exclusividad del código como barrera entre la idea y su materialización. Cuando algo tan grande cambia, al principio todo se vuelve un caos, y por eso vemos discursos en todas las direcciones. Las grandes empresas de tecnología saben lo que esto significa y la seguirán impulsando hasta que sea inevitable.

El programa no nace del programador. Nace del experto que conoce el negocio. El programador, durante toda la historia del software, ha hecho una cosa: interpretar ese conocimiento y convertirlo en una herramienta. Ese paso intermedio era inevitable mientras solo los humanos sabían escribir código. Hoy ya no lo es.

5. La transición del rol: del programador al gerente del laboratorio

El paralelo es exacto. Un gerente de una fábrica de software no necesita saber programar para hacer su trabajo. Necesita confiar en la calidad del equipo. Cuando esa confianza está, el gerente no mira líneas de código: mira indicadores, plazos, riesgos, presupuesto y arquitectura general. Aunque sepa programar, no lo hace, porque su valor agregado está en otra capa.

Eso mismo, exactamente eso, es lo que la IA está induciendo en el oficio del programador, pero acelerado y por etapas:

Cambio de paradigma del flujo de construcción de software: el intermediario humano da paso al agente.

Ese diagrama sintetiza tres momentos del mismo flujo. La posición histórica, donde el experto del negocio dependía de un programador humano para traducir su conocimiento al software. El momento intermedio que vivimos hoy, en el que ese mismo experto ha aprendido lo suficiente para dialogar con un agente todavía imperfecto y supervisarlo paso a paso. Y el destino hacia el que el oficio se mueve, en el que el experto, ya sólido en arquitectura, dirige agentes seniors que codifican con precisión.

• Hoy. Los agentes son juniors. Generan código convincente pero con errores sutiles, alucinaciones de librerías, atajos peligrosos. Hay que hacer micromanagement: leer, probar, devolver, repetir. Por eso, en esta ventana de transición, todavía hay que saber programar.
• Mañana. Los agentes alcanzan el nivel de un senior. Ya no es necesario revisar cada cambio: alcanza con definir bien qué se quiere, validar el resultado contra el negocio y mantener la arquitectura coherente. El micromanagement se evapora. El programador es gerente pleno.
• Pasado mañana. Los agentes son mejores que el mejor de nosotros. Múltiples agentes trabajan en paralelo, se coordinan entre ellos, se autocorrigen. El rol del humano es estratégico: decir qué se construye, para qué, y con qué prioridad.

Conviene fijar ahora la conclusión que ese diagrama deja servida. El destino del oficio no es codificar mejor: es resolver mejor los problemas allí donde viven los expertos del negocio, en la planta, en la mesa de operaciones, en la línea de venta, en el laboratorio clínico, en el aula. El código nunca fue el fin; fue siempre la traducción imperfecta de un conocimiento que ya residía en otra cabeza. Cuanto más corto sea el camino entre el experto y el software que necesita, más fiel al problema será la solución.

Lo más concreto, lo más eficiente y lo más honesto con esa lógica, es que los propios expertos del negocio construyan sus soluciones, dirigiendo a un equipo de agentes programadores seniors. No hay para esto atajo ni alternativa: es el camino, y todos (cada quien desde su área productiva) vamos a tener que adaptarnos a él de una forma u otra. Conviene hacerlo ahora, mientras la ventana operativa sigue abierta.

Todos seremos sustituidos en la tarea de programar por agentes varias veces más eficientes que el mejor de nosotros. No tiene sentido ponerse en contra: tiene sentido aprender a dominarlos. La diferencia entre quien queda fuera y quien queda dentro es si se subió a tiempo al rol de gerente del laboratorio o se quedó defendiendo el rol de tipeador de código.

El profesional experto de hoy ya no podrá quedarse solo con el conocimiento de su profesión u oficio. Tendrá que aprender tecnología, especializarse en inteligencia artificial y entender la arquitectura del sistema, las dependencias, los servicios externos y las herramientas de versionamiento del código.

La IA ya es una realidad, los datos lo confirman. Desde 2024 la capacidad de los modelos de IA para completar tareas de ingeniería de software ha avanzado a un ritmo que no tiene precedente en ninguna otra tecnología de desarrollo. En 2019, los primeros modelos apenas podían encontrar un dato en la web en cuestión de segundos. Hoy resuelven bugs reales, refactorizan módulos completos y construyen features de principio a fin en tareas que a un programador humano le tomarían horas. La duración de lo que pueden hacer de forma autónoma se duplica cada pocos meses y la curva no muestra señales de desaceleración. Al contrario: cada nueva generación de modelos comprime el intervalo de mejora. La trayectoria apunta a un punto inevitable en el que los agentes no solo igualarán al mejor programador humano en tareas puntuales, sino que lo superarán de forma sostenida, predecible y replicable a escala. No se trata de si llegarán a ese nivel de confiabilidad casi perfecta, sino de cuándo.

Duración de tareas de ingeniería de software que los modelos de IA completan autónomamente con 50% de probabilidad. Eje vertical en escala logarítmica. Fuente: METR (metr.org/time-horizons).

Pero este giro no obliga solo al experto del negocio. El programador tradicional que decida sobrevivir a esta revolución, la que traen la IA y los agentes programadores, va a tener que aplicar con la misma precisión los fundamentos de la gestión estratégica del desarrollo de software. Es desde ese enfoque, y no desde el teclado, que se educa y se guía con efectividad a un agente. Significa respetar el ciclo de vida del software completo, sin saltarse un solo paso: planificación, ingeniería de requisitos, análisis, diseño, codificación, pruebas, despliegue y mantenimiento. Cada etapa pesa. Y aquí está lo incómodo: solo un porcentaje pequeño de programadores honra hoy esas fases, aun sin usar IA. Quien las descuidaba antes, con agentes va a producir desastres más rápido y a mayor escala.

Nada de lo anterior es especulación. Gartner, la firma de análisis más conservadora de la industria tecnológica, ya sitúa a los modelos fundacionales y a la IA generativa en la rampa de consolidación de su Hype Cycle 2025: pasaron el pico de expectativas infladas, cruzaron el valle de desilusión y ahora avanzan hacia la meseta de productividad real. El horizonte que Gartner estima para esa meseta es de dos a cinco años. No décadas: años. La madurez de estas tecnologías ya no es una promesa de laboratorio. Es una curva medida por la misma consultora que asesora a las empresas del Fortune 500.

Hype Cycle para la inteligencia artificial de 2025. Fuente: Gartner, Inc.

6. Los skills que importan, hoy y mañana

La pregunta razonable que sigue es: ¿en qué conviene invertir el tiempo de aprendizaje? El brief de Fase 1 de este artículo dejó dos listas, una para la ventana de hoy y otra para el horizonte donde los agentes son confiables.

Hoy, mientras los agentes son juniors

• Saber programar, incluida la lectura crítica del código del agente. Sin esta capacidad no se puede hacer micromanagement efectivo: el agente entregará código convincente y nadie detectará el atajo peligroso enterrado en el medio.
• Arquitectura de software. El agente aún no decide bien dónde corta un sistema, qué datos viven dónde, qué servicio orquesta cuál. Esa capa estratégica todavía depende del humano.
• Comunicar requisitos con precisión. La calidad del prompt define la calidad del producto. Es el skill más trasladable: ya lo tenían los buenos product owners y los buenos consultores. Ahora se aplica a un agente.
• Diseño de pruebas y validación. Si el agente codifica, alguien tiene que asegurarse de que el código hace lo que promete. Saber escribir tests que cubran lo que importa pasa a ser un skill diferenciador.

Mañana, cuando los agentes sean senior o master

• Criterio de negocio y dominio. Lo que ya tienen los expertos del negocio. Esto no se reemplaza: alguien tiene que saber para qué sirve el software, qué problema resuelve y cuánto vale resolverlo.
• Arquitectura de sistemas a alto nivel. No la del módulo, la del conjunto: cómo se integran las aplicaciones, cómo se asegura la seguridad, dónde viven los datos, qué pasa cuando algo falla. Es más estratégica y sobrevivirá más tiempo que la programación fina.
• Gestión de equipos híbridos (humanos y agentes). Coordinar varios agentes en paralelo, asignar prioridades, monitorear costos, gestionar riesgos. El nuevo rol gerencial puro.
• Pensamiento crítico y juicio. Saber decirle a un agente: “esto no es lo que se necesita, aunque parezca correcto”. La capacidad transversal de evaluar resultados contra el problema real, no contra la elegancia técnica.

Honestidad obligatoria. Estos skills tampoco son eternos. Es previsible que con el tiempo varios de ellos sean asumidos por agentes especializados (uno para arquitectura, otro para validación, otro para gestión de proyecto). La única que probablemente sobreviva al final es la primera: conocer profundamente el dominio del negocio. Por eso conviene tener un pie firme en una industria real, no solamente en el stack técnico.

7. Una pregunta abierta: ¿token o salario?

El argumento tecnológico, a estas alturas, está resuelto. Los agentes ya programan, mañana programarán mejor, pasado mañana programarán mejor que cualquiera. La pregunta que decide la velocidad del cambio no está en la tecnología: está en una hoja de cálculo bastante más prosaica.

¿Cuánto cuesta el token frente a cuánto cuesta el desarrollador humano? El día que el costo agregado de los tokens necesarios para construir, mantener y operar un sistema sea menor que el costo agregado de un equipo humano que haga lo mismo, el reemplazo se vuelve inevitable. No porque alguien lo decrete. Porque cualquier empresa que no lo haga quedará en desventaja frente a sus competidores que sí lo hicieron.

Ese momento todavía no ha llegado de forma generalizada. En tareas puntuales ya está cerca. En equipos completos todavía hay margen. Y ese margen, mientras dure, es la ventana operativa que tienen los programadores actuales para hacer la transición al rol gerencial. No es una ventana infinita.

“La sustitución no se decide en lo tecnológico. Se decide en la unidad costo por feature entregado. Y los tokens se abaratan más rápido de lo que crecen los sueldos.”

Si este contenido le resultó útil

⭐ Para profundizar: junto a este artículo se publica un documento de referencias bibliográficas que reúne las fuentes primarias que sostienen cada argumento. Estudios académicos, encuestas globales y reportes públicos de la industria, con cita textual y enlace directo a cada fuente, para que pueda verificar los datos y llegar a sus propias conclusiones. Disponible en el repositorio público: github.com/leanmasterpymes/opinion_ia_programar/referencias.

💬 Comparta este artículo con quien dentro de su organización deba decidir cuándo iniciar la transición del rol de programador.

📩 Si desea conversar sobre cómo su equipo o empresa debe prepararse para la transición del rol de programador, puede contactarme mediante mensajes directos.

Artículo de opinión · Repositorio · Licencia MIT · Leanmaster Pymes