¿La IA va a sustituir a los programadores? Estás preguntando mal
DominicodeHace unas semanas terminé una formación de Claude Code con un equipo de backend. Nueve personas. Al acabar, el más senior de la sala esperó a que se fueran los demás para hacerme la pregunta de verdad.
"Bezael, sin rodeos: ¿la IA va a sustituir a los programadores? Aquí ya no hay nadie de RRHH."
Le dije que la respuesta no le iba a gustar, porque no es sí ni es no. Es que la pregunta está mal hecha, y por eso lleva tres años sin producir nada útil aparte de hilos de Twitter.
La IA no va a sustituir a los programadores: está sustituyendo tareas de programación. Nadie automatiza puestos. Se automatizan tareas — y casi ningún puesto es una sola tarea.
Tu trabajo no es una cosa: la IA sustituye tareas, no puestos
Piensa en un abogado. Redacta escritos, busca jurisprudencia, interpreta la ley, negocia y responde de lo que firma. Las dos primeras se automatizan razonablemente bien hoy. Las tres últimas, nada.
Ahora hazlo con tu semana.
Un developer teclea implementación, busca en documentación, lee stack traces, escribe boilerplate, migra sintaxis vieja a sintaxis nueva. Y además decide la arquitectura, decide qué no se va a construir, negocia el alcance con producto, entiende el contexto que no está escrito en ningún ticket, y responde de lo que se despliega un viernes a las seis.
El primer grupo se está automatizando de verdad, hoy, no en 2030. El segundo no se ha movido ni un milímetro.
Lo que ocurre entonces no es que desaparezca el puesto. Es que cambia la proporción. Menos horas de lo mecánico, más horas de lo otro.
Y ahí está el problema real, el que casi nadie nombra: no todo el mundo quiere —o sabe— pasar más tiempo en la parte que queda.
El patrón tiene cincuenta años: el cajero automático no acabó con los cajeros
Esto ya pasó. Varias veces.
El caso mejor documentado es el del cajero automático. En 1990 había unos 100.000 instalados en Estados Unidos; dos décadas después rondaban los 400.000. Entre finales de los ochenta y mediados de los dos mil, la sucursal urbana media pasó de necesitar unos 21 empleados de ventanilla a unos 13.
El titular obvio era "los cajeros automáticos acaban con los cajeros humanos". Y durante dos décadas no ocurrió: el economista James Bessen documentó que el empleo total de cajeros de banca no solo aguantó el despliegue, sino que creció ligeramente.
¿Por qué? Porque operar una sucursal salía más barato y los bancos abrieron más. Y porque las tareas que no se automatizaron —vender, resolver el caso raro, sostener la relación con el cliente— pasaron a ser la mayor parte del puesto.
El empleado de ventanilla de 2005 hacía un trabajo distinto al de 1980 con el mismo nombre en la nómina.
Y aquí va la parte que casi nunca se cita, porque estropea la moraleja: a partir de 2010 el empleo de cajeros sí se hundió. Ha caído cerca de un 30% desde entonces, hasta quedar en poco más de 340.000 puestos. La banca online remató lo que el cajero automático solo había recolocado.
Esa es la lección completa, y es bastante más útil que la versión bonita: primero cambia la composición del trabajo; después, si la tecnología sigue avanzando, cambia el número de puestos. Los veinte años de margen no fueron una garantía. Fueron un plazo.
Lo mismo con la hoja de cálculo: desapareció sumar columnas a mano, y con ello buena parte del puesto de auxiliar contable — pero no la contabilidad. Lo mismo con el CAD: desapareció el tablero de dibujo, y el oficio de delineante se encogió, pero convertir una idea en un plano que se pueda construir sigue siendo trabajo de alguien.
En los tres casos, la composición del trabajo cambió antes que su existencia.
Lo nuevo hoy es la velocidad. El cajero automático tardó veinte años en reconfigurar una sucursal. Aquí el ciclo es de producto: lo que tu equipo hacía a mano en enero puede estar delegado en septiembre. No tienes una generación para adaptarte. Tienes un par de trimestres.
Sobre cómo se ha sentido ese cambio desde dentro escribí hace poco en Llevo 15 años programando: esto es lo que cambió con la IA. Este post es la otra mitad: qué haces con ello.
El riesgo real para un programador no es quedarse sin trabajo
Es quedarte solo con la parte difícil.
Si la IA te quita el 40% mecánico de la semana, lo que queda no es una semana más corta. Es la misma semana llena de decisiones y responsabilidad, sin los ratos de teclear a piloto automático que antes te servían de descanso mental.
La carga mental sube aunque las horas bajen. Y eso casi nunca se prevé.
Hay una consecuencia de gestión que va con esto: hay que decidir de antemano qué se hace con el tiempo que se libera, y decirlo en voz alta. Si no se decide, se llena solo de más volumen. Más tickets, más features, más PRs por revisar.
Ese es el momento exacto en el que has cambiado un trabajo llevadero por uno más intenso, con el mismo sueldo y peor cara. Si tu equipo está midiendo esto con líneas de código o PRs mergeados, te va a pasar sin que lo veas venir; sobre eso va cómo medir la productividad en equipos que usan IA.
Copiloto o agente: la pregunta que hacerle a cualquier herramienta de IA
La forma de usar IA que mejor funciona hoy es la menos vistosa: la persona conserva el criterio y la responsabilidad, y la herramienta se lleva el trabajo mecánico.
El mercado etiquetó eso como copiloto —un nombre comercial convertido en genérico— y ahora todo se llama igual. Así que cuando alguien te venda uno, la pregunta es siempre la misma:
¿Qué decide la herramienta y qué decides tú?
Si el que decide es el modelo, eso no era un copiloto. Era un agente con un nombre más tranquilizador. La diferencia técnica entre ambos la desgloso en IA generativa vs IA agéntica.
Esa frontera no la define el fabricante. La defines tú, en cada proyecto, cuando escribes el objetivo y los permisos. Por eso insisto tanto con las especificaciones: escribir la spec antes es el acto de decidir tú, por adelantado, lo que si no decidirá el modelo sobre la marcha. Lo desarrollo entero en el libro de Spec-Driven Development.
Y no, esto no es un consuelo: a quién sí le cambia el puesto
Decir que "cambia la mezcla" no significa que no haya consecuencias.
Si el 80% de tu puesto era la parte automatizable, tu puesto cambia de forma muy seria. No hace falta que desaparezca la profesión para que desaparezca tu encaje concreto en ella.
Por eso el ejercicio que viene no es opcional.
El ejercicio: audita qué parte de tu semana puede automatizar la IA
No es teoría. Se hace en veinte minutos y da un número incómodo.
Coge la semana pasada. Mira tu historial de git, tu calendario y tu gestor de tareas. Lista los bloques de trabajo reales —no las tareas del sprint, lo que hiciste de verdad— y clasifica cada uno.
La regla para clasificar, y hay que aplicarla con honestidad:
- Mecánica: pudiste describir lo que había que hacer en tres frases, y otro developer competente lo habría resuelto prácticamente igual.
- Criterio: tuviste que decidir algo que se podía haber decidido de otra forma, y no había respuesta correcta escrita en ningún sitio.
| Día | Bloque de trabajo | Horas | Tipo |
|---|---|---|---|
| Lun | CRUD del endpoint de facturación | 3h | Mecánica |
| Lun | Decidir si el estado vive en cliente o API | 40min | Criterio |
| Mar | Migrar 12 componentes a la nueva sintaxis | 4h | Mecánica |
| Mar | Negociar con producto qué sale del scope | 1h | Criterio |
| Mié | Depurar el timeout intermitente de staging | 2h | Criterio |
Suma las horas de cada columna y saca la proporción.
Si quieres el paso siguiente —qué delegas exactamente de la columna mecánica y cómo—, va entero en clasificar tareas con IA en desarrollo de software.
Ahora lee el resultado sin dramatismo:
Si sales 80% mecánica, eso es una señal, no un insulto. La mayor parte de tu semana está en la franja que se mueve primero. No significa que te vayan a echar el mes que viene: significa que tienes un par de trimestres para mover parte de esas horas al otro lado.
Si sales 80% criterio, enhorabuena a medias. Tu puesto es de los que la IA hace más productivos, y también más agotadores. Tu problema no es la sustitución: es la carga.
Y si sales 50/50, ese es más o menos el sitio donde está hoy un senior sano. El objetivo no es llegar a 0% mecánica. Nadie funciona así.
Repite el ejercicio dentro de tres meses. La proporción es la métrica; el número absoluto de un día suelto no dice nada.
Lo que haces mañana como programador
Haz la auditoría esta semana, con tu propio historial, y guarda el resultado.
Después, coge el bloque mecánico más grande —el que más horas se come— y delégalo de verdad: con contexto, con spec, con revisión tuya. No para ir más rápido. Para ver cuánto de tu semana era realmente insustituible cuando lo miras de cerca.
Esa es la única pregunta que importa, y no la contesta ningún informe de McKinsey. La contesta tu tabla.
Si quieres aprender a delegar esa parte sin soltar el criterio, es exactamente el flujo que enseño en Construye con IA: de la idea al producto con Claude Code. Y si lo prefieres sobre proyectos reales y con gente haciéndose las mismas preguntas, en Dominicode Labs es la conversación de cada semana.
Preguntas frecuentes
¿La IA va a sustituir a los programadores?
La pregunta no tiene respuesta útil porque mezcla dos cosas. La IA está sustituyendo tareas concretas de programación —boilerplate, migraciones mecánicas, búsqueda en documentación, primer diagnóstico de un stack trace— y no está sustituyendo otras: decidir arquitectura, negociar alcance, entender el contexto no escrito y responder de lo que se despliega.
Lo que cambia no es la existencia del puesto, sino la proporción entre sus tareas. Y cambia más rápido que nunca.
¿Qué tareas de developer se automatizan bien hoy?
Las que cumplen tres condiciones a la vez: se repiten, tienen un criterio de éxito verificable y el error se detecta rápido. Escribir la implementación cuando ya sabes qué quieres, generar tests de andamiaje, migrar sintaxis entre versiones, resumir un stack trace largo.
Lo que no se automatiza bien es lo que exige asumir consecuencias. Un modelo puede proponer una decisión de arquitectura; no puede responder de ella dentro de dos años.
Si mi semana sale 80% mecánica, ¿estoy en peligro?
Estás en la parte del puesto que se mueve primero, que no es lo mismo que estar en peligro inmediato. Es información, y mejor tenerla ahora que dentro de dos años.
Lo accionable: elige una de esas tareas mecánicas al mes y conviértela en algo que delegas y revisas, en lugar de algo que tecleas. El tiempo que recuperas lo inviertes en la columna de criterio: decisiones de diseño, escribir specs, revisar PRs de otros.
¿Qué diferencia real hay entre un copiloto y un agente?
Quién toma la decisión. En un copiloto, la persona conserva el criterio y la responsabilidad, y la herramienta ejecuta lo mecánico. En un agente, la herramienta decide la ruta y actúa.
Ninguno es mejor en abstracto: son herramientas para riesgos distintos. Lo peligroso es comprar un agente pensando que es un copiloto porque el fabricante lo llamó así. Si puede actuar sin que tú apruebes cada acción con consecuencias, es un agente y hay que tratarlo como tal.
¿Especializarme más me protege?
Especializarte en una tecnología concreta te protege poco; especializarte en un dominio de negocio, mucho. El conocimiento de una API estable es exactamente el tipo de cosa que un modelo tiene mejor memorizada que tú — con las APIs nuevas va al revés, pero eso se arregla pegándole la documentación.
Lo que sí acumula valor es lo que no se puede leer en la documentación: conocer el dominio del negocio, saber qué pregunta hay que hacer antes de escribir código, y tener el historial de decisiones que te dice por qué la opción elegante va a fallar aquí. Eso es criterio, y solo se construye con reps.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.