Llevo 15 años programando: esto es lo que cambió con la IA
DominicodeHace quince años, construir una funcionalidad significaba abrir un archivo en blanco y teclear cada línea hasta que compilaba. Cuando me atascaba, Stack Overflow. Cuando Stack Overflow fallaba, la documentación. Cuando la documentación mentía, prueba y error durante horas. Así aprendí el oficio y así trabajé la primera mitad de mi carrera.
Esta mañana he construido un módulo completo sin teclear una sola línea de implementación a mano.
Llevo quince años en esto y he visto pasar muchas modas. El desarrollo de software con IA no es una más. Es lo único que ha cambiado de raíz cómo hago mi trabajo. Pero no por la razón que casi todo el mundo repite en LinkedIn.
Lo que ha cambiado no son las herramientas. Es el rol.
Ya no me pagan por escribir código. Me pagan por decidir qué código debe existir, especificarlo bien y verificar que lo que se ha escrito es correcto. El tecleo —la parte que durante quince años fue la mayor parte del oficio— se ha vuelto la parte barata.
Y si quieres la definición limpia, esta es la mía: el desarrollo de software con IA es la práctica de construir software delegando la escritura del código a modelos y agentes, mientras el developer se reserva las tres decisiones que siguen siendo suyas —qué construir, cómo debe encajar y si lo generado es correcto—.
De escribir código a orquestarlo: así se programa con IA hoy
Antes, un día productivo se medía en líneas. Hoy se mide en decisiones acertadas.
La sesión de esta mañana fue así: abrí un documento, describí qué quería —el comportamiento, los límites, los casos que no debía tocar—, se lo pasé a un agente y me fui a por café. Cuando volví, había un diff de trescientas líneas esperándome.
Mi trabajo empezó ahí. Leerlo entero. Cuestionar tres decisiones. Rechazar una. Aprobar el resto.
No escribí la implementación. La orquesté.
Si tuviera que resumir el cambio en una tabla, sería esta:
| Antes | Ahora | |
|---|---|---|
| Unidad de medida | Líneas escritas | Decisiones acertadas |
| Cuello de botella | Teclear rápido y conocer la API | Especificar con precisión |
| Habilidad clave | Saber escribir código | Saber leer y revisar código |
| Riesgo principal | Bugs por descuido | Deuda por código que nadie entendió |
| Tu rol | Autor | Director y revisor |
Y ese cambio no fue de un día para otro. Fue una escalera. Primero el autocompletado —GitHub Copilot en 2021—, que adivinaba el final de la línea. Después el chat, ChatGPT y compañía, al que le pegabas un error y te devolvía una respuesta plausible. Y ahora el agente autónomo, del estilo de Claude Code o Cursor, que lee tu repo, ejecuta comandos, mira la salida y decide el siguiente paso sin ti. Si todavía andas en el primer escalón, la guía de Agentes de IA es el mejor sitio para entender qué hace distinto al último.
Esa forma de trabajar en bucle —delegar, observar, corregir, repetir— tiene su propia disciplina, y la desarrollé entera en Loop Engineering: la evolución del desarrollo con IA. Porque diseñar bien ese bucle es hoy más determinante que elegir el modelo de moda.
El cuello de botella del desarrollo de software con IA se movió: ahora está en especificar
Durante años, el cuello de botella era teclear rápido y conocer la API de memoria. El que escribía más limpio y más rápido ganaba.
Hoy el cuello de botella es otro: describir con precisión lo que quieres.
Un agente hace lo que le pides al pie de la letra, no lo que querías decir. Todo lo que no especificas, lo inventa. Y lo inventa con una seguridad que asusta.
Por eso el trabajo de más valor ya no es escribir la función. Es escribir la especificación de la función: el resultado esperado, los límites, los casos borde, lo que queda explícitamente fuera del alcance.
Esto no es teoría. Es la metodología que uso a diario y la que documenté entera en el libro de Spec-Driven Development: especificar primero, delegar después. Si quieres el porqué antes que el cómo, lo cuento en Spec-Driven Development: la forma de evitar el caos con la IA.
El developer que sabe redactar una buena especificación multiplica su trabajo. El que sigue tratando al agente como un buscador —"hazme esto"— se pasa el día corrigiendo basura.
Lo que NO ha cambiado (y por qué el senior vale más que nunca)
Aquí está la parte incómoda para los que venden que la IA ya programa sola.
Nada de esto elimina al developer con criterio. Lo hace imprescindible.
Un agente escribe trescientas líneas en dos minutos. Pero no sabe si esas trescientas líneas encajan en tu arquitectura. No sabe si van a ser un infierno de mantener dentro de un año. No sabe si acaba de duplicar una lógica que ya existía en otro módulo. El agente optimiza para que el criterio de parada se cumpla, no para que el sistema siga vivo dentro de dos años.
Ese juicio sigue siendo tuyo.
Y no es una manía mía de señor mayor. El informe DORA 2025 de Google Cloud, hecho con cerca de 5.000 profesionales de todo el mundo, encontró que el 90% ya usa IA en su trabajo y más del 80% dice que le ha subido la productividad. Pero un 30% reconoce tener poca o ninguna confianza en el código que esa IA genera.
Ahí tienes la foto exacta del oficio hoy: casi todos delegamos, casi nadie firma a ciegas. Esa distancia entre "lo uso todos los días" y "no me fío" es, literalmente, la descripción de tu nuevo puesto de trabajo.
Y ojo con confundir velocidad con progreso. Generar código rápido no es lo mismo que avanzar rápido. Un diff de trescientas líneas que nadie entiende no es velocidad, es deuda con intereses. Por eso "más rápido" y "mejor" no son la misma métrica, y desarrollé cómo distinguirlas en Cómo medir la productividad de un equipo con IA.
Hay tres cosas que la IA no ha tocado, y son exactamente las que definen a un buen ingeniero:
- El criterio. Saber qué construir y, sobre todo, qué no construir.
- La arquitectura. Decidir cómo encajan las piezas para que el sistema aguante el paso del tiempo.
- Saber leer código. Porque revisar es la nueva forma de escribir. Un diff que no entiendes es un diff que no puedes aprobar.
Lo diré claro: hoy saber leer código importa más que saber escribirlo. Escribir lo hace la máquina. Leerlo, entenderlo y detectar dónde se ha equivocado sigue siendo humano.
Al que no se adapta no lo sustituye la IA
El miedo que oigo en cada charla es siempre el mismo: "¿La IA me va a quitar el trabajo?".
No. Pero un developer que orquesta, especifica y revisa bien va a hacer el trabajo de tres que siguen tecleando línea a línea. Y las empresas lo van a notar en la nómina antes de lo que crees.
No te sustituye la IA. Te sustituye el compañero que sabe usarla.
La brecha ya no está entre el que programa y el que no. Está entre el que ha movido su trabajo hacia arriba en la cadena —del tecleo a la decisión— y el que sigue midiendo su día en líneas escritas a mano, orgulloso de un esfuerzo que la máquina hace gratis.
Esa segunda persona no está en peligro por la IA. Está en peligro por negarse a cambiar de rol.
Qué puedes hacer hoy
Si llevas años programando y sientes que el suelo se mueve, tienes razón. Se mueve. Pero a tu favor, si haces el cambio a tiempo.
Deja de medir tu jornada en líneas escritas. Empieza a medirla en decisiones acertadas, especificaciones claras y diffs bien revisados.
Coge mañana una tarea aburrida y acotada —migrar un módulo, añadir tests a un servicio— y en vez de teclearla, especifícala y delégala. Luego siéntate a revisar el resultado como revisarías el pull request de un junior brillante pero despistado. Ahí, en esa revisión, es donde vas a hacer tu trabajo de senior a partir de ahora.
Ese es el músculo nuevo. Y como todo músculo, se entrena.
Si quieres ver este flujo completo montado de principio a fin —de la idea a un producto funcionando, especificando y delegando de verdad— es exactamente lo que construimos en el curso Construye con IA. Y si prefieres hacer el cambio acompañado, con proyectos reales y gente que ya está en esto, te espero en Dominicode Labs.
El código dejó de ser el trabajo. El criterio para dirigirlo es el trabajo. Muévete hacia ahí.
Preguntas frecuentes
¿La IA va a reemplazar a los programadores?
No a los programadores con criterio. La IA reemplaza el tecleo, que era la parte mecánica del oficio, no el juicio. Un agente escribe código muy rápido, pero no decide qué construir, no diseña una arquitectura que aguante el tiempo ni sabe si su propia solución es mantenible. Lo que sí ocurre es que un developer que sabe orquestar, especificar y revisar hace el trabajo de varios que siguen escribiendo cada línea a mano. El riesgo no es la IA: es no adaptarse a usarla.
¿Necesito seguir aprendiendo a programar si la IA escribe el código?
Sí, y hoy más que nunca. La IA escribe código, pero alguien tiene que leerlo, entenderlo y decidir si es correcto. No puedes aprobar un diff que no comprendes ni detectar un fallo de arquitectura si no sabes cómo debería estar construido. Saber programar deja de ser una habilidad de producción y pasa a ser una habilidad de criterio y revisión. Sin esa base, delegar en un agente es apostar a ciegas.
¿Por dónde empiezo a programar con IA?
Por una tarea real, aburrida y acotada, no por un proyecto ambicioso. Coge algo que sepas hacer a mano en media hora —migrar un módulo, añadir tests, actualizar una dependencia—, escríbele una especificación clara al agente en lugar de un "hazme esto" y luego revisa el resultado línea a línea. Cuando eso te salga limpio, sube el listón. Trabajar primero la especificación y después delegar es la base de la metodología Spec-Driven Development, y es el orden que evita el caos.
¿Qué habilidades necesita hoy un developer?
Tres que la IA no cubre. Criterio para decidir qué construir y qué no. Arquitectura para que las piezas encajen y el sistema sobreviva al paso del tiempo. Y capacidad de leer código ajeno —ahora, código generado— para revisarlo y aprobarlo con confianza. A eso se suma una habilidad nueva: saber especificar con precisión lo que quieres, porque todo lo que no le dices al agente, se lo inventa. El tecleo rápido ya no está en la lista.
¿Sigue haciendo falta un developer senior si la IA programa sola?
Más que antes. La IA baja el coste de escribir código, lo que multiplica la cantidad de código que se genera y, con él, la superficie donde algo puede salir mal. Alguien tiene que poner criterio arquitectónico, revisar lo que produce el agente y frenar las decisiones que optimizan por cerrar la tarea a costa de la mantenibilidad. Ese trabajo es exactamente el de un senior. La IA no elimina ese rol: lo hace el más valioso del equipo.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.