Hasta hace poco, un programador que utilizaba IA introducía una pregunta en el chatbot, copiaba el fragmento de código generado y lo pegaba en el proyecto. Hoy, ese modelo de trabajo se parece cada vez menos a eso.
El programador puede asignar una tarea a un agente, darle acceso al repositorio, permitirle analizar el código existente, ejecutar pruebas, modificar muchos archivos, corregir errores y luego preparar el cambio para revisión. El ser humano no desaparece del proceso. Lo que cambia es el lugar donde su trabajo aporta más valor.
Según el estudio JetBrains Developer Ecosystem Survey 2026, que abarcó a más de 15 mil programadores profesionales de todo el mundo, entre mayo y julio de 2026 el 90% de los encuestados utilizaba AI coding agents en el trabajo al menos una vez por semana, y el 68% lo hacía a diario.
Ya no es un experimento de unos pocos entusiastas. Es un cambio en el modelo de trabajo.
La IA ya no es solo un “asistente para código”
Conviene distinguir dos cosas.
El asistente de IA ayuda al programador.
El AI coding agent ejecuta la tarea.
Es una diferencia aparentemente pequeña, pero desde el punto de vista de la organización del trabajo es enorme.
El asistente puede proponer una función, explicar un error, generar un fragmento de SQL o escribir una prueba. Sin embargo, sigue siendo el ser humano quien realiza la mayor parte de las operaciones.
El agente puede recibir una instrucción mucho más general:
“Añade la posibilidad de filtrar pedidos por estado. Revisa la arquitectura existente. Implementa el backend y el frontend. Añade pruebas. Ejecuta la test suite y corrige los errores.”
Y empieza a trabajar.
Revisa la estructura del proyecto. Busca los archivos adecuados. Analiza dependencias. Modifica el código. Ejecuta pruebas. Recibe un mensaje de error. Intenta corregirlo. Vuelve a ejecutar las pruebas.
Ya no es autocomplete con esteroides.
Es un ejecutor de tareas que opera dentro del entorno de desarrollo.
Y aquí empieza el verdadero cambio de rol del programador
Si la IA puede generar varios cientos de líneas de código en cuestión de decenas de segundos, el valor del programador ya no puede medirse únicamente por el número de líneas escritas.
Empiezan a contar otras competencias.
¿Puede el programador definir bien el problema?
¿Entiende la arquitectura del sistema?
¿Sabe qué información transmitir al agente?
¿Puede evaluar si la solución realmente encaja en el sistema existente?
¿Puede diseñar pruebas?
¿Detectará que el agente resolvió el problema localmente, pero creó un problema tres capas más arriba?
¿Sabe cuándo detener al agente?
Eso significa un desplazamiento del peso del trabajo.
Menos: “Escribamos este código desde cero.”
Más: “Diseñemos la solución, definamos las limitaciones, proporcionemos el contexto adecuado, comprobemos el resultado y decidamos si puede desplegarse.”
El programador empieza a parecerse al líder de un pequeño equipo
Imaginemos un proyecto en el que trabajan varios agentes.
Uno analiza el código existente.
Otro prepara el backend.
Un tercero trabaja en la interfaz.
Un cuarto genera pruebas.
Un quinto analiza la seguridad.
El ser humano puede coordinar su trabajo, transmitir contexto y tomar decisiones.
¿Suena como un equipo de desarrollo?
En cierto sentido, sí.
La diferencia es que los “empleados” no son personas.
Y precisamente por eso surge una nueva competencia: gestión del desarrollo agentic.
Aquí no se trata de gestionar personas, calendarios o presupuestos. Se trata de gestionar el flujo de trabajo realizado por sistemas de IA.
El programador debe ser capaz de dividir un problema grande en tareas, definir dependencias, transmitir el contexto adecuado y crear un mecanismo de control de resultados.
Eso se parece mucho más al trabajo de un arquitecto que al tradicional copiar y pegar código.
La herramienta más importante del programador hoy puede ser el contexto
Un agente es tan bueno como buena sea la información que reciba.
Se puede decir: “Añade inicio de sesión de usuarios.”
Y se puede decir: “Añade inicio de sesión de usuarios. El sistema utiliza el mecanismo actual de OAuth. No cambies la estructura de la tabla de usuarios. Las sesiones se almacenan en el lado del servidor. No introduzcas una nueva biblioteca sin justificación. Mantén la compatibilidad con la aplicación móvil. Añade pruebas para inicio de sesión, cierre de sesión, sesión caducada y token inválido.”
La segunda instrucción no es simplemente más larga.
Es una mejor especificación.
El agente recibe limitaciones, contexto empresarial y técnico, y criterios de aceptación.
Por eso, en el mundo de los agentes cobra cada vez más importancia la capacidad de trabajar con contexto. El programador no solo le dice a la IA, qué hacer. También debe decir, en qué entorno hacerlo, qué no se puede cambiar y cómo sabremos que la tarea se ha realizado correctamente.
¿El mayor error? Confundir la velocidad de generación con la velocidad de creación de software
Esto es muy importante.
El agente puede generar una función en 30 segundos.
Eso no significa que la función esté lista para producción en 30 segundos.
El código hay que entenderlo. Probarlo. Integrarlo. Verificarlo en términos de seguridad. Comprobar su rendimiento. Verificar su coherencia con la arquitectura. Analizar su impacto en los demás elementos del sistema.
La IA puede acortar drásticamente la fase de producción de código, pero no elimina la necesidad de ingeniería.
Al contrario.
Cuanto más fácil es generar código, más fácil es generar también código malo.
Y el problema empieza cuando el ser humano ya no es capaz de entender lo que ha aceptado.
Por eso el ser humano sigue en el ciclo
Los datos de Stack Overflow de abril de 2026 muestran una imagen muy interesante. El uso de agentes en el trabajo aumentó hasta el 59%, pero el 63% de los tecnólogos encuestados declaró que rara vez o nunca permite que los agentes actúen de forma totalmente autónoma. El 60% de los encuestados bloquea a los agentes la posibilidad de realizar cambios no aprobados en los sistemas.
Esto muestra algo importante.
El mercado no avanza simplemente hacia: “La IA lo hace todo, el ser humano solo mira.”
Mucho más realista es el modelo: “La IA realiza cada vez más trabajo, pero el ser humano sigue controlando la dirección, las limitaciones y el resultado.”
Esa es una diferencia fundamental.
El programador no tiene que escribir manualmente cada función. Sin embargo, sí debe saber por qué existe una función determinada, cómo funciona y si debería estar en el sistema.
El nuevo programador tendrá que ser bueno en varios mundos distintos al mismo tiempo
Las competencias clásicas de programación siguen siendo importantes.
El conocimiento de lenguajes de programación, bases de datos, arquitectura, protocolos, seguridad, pruebas o infraestructura no desaparece solo porque la IA pueda generar código.
Al contrario.
Si alguien no entiende el sistema, le resultará difícil evaluar si la solución generada es buena.
A esto, sin embargo, se suman nuevas habilidades.
El programador debe entender las limitaciones de los modelos. Debe saber preparar el contexto. Debe saber cómo dividir las tareas entre agentes. Debe saber diseñar el proceso de verificación. Debe entender los costes de las llamadas, los permisos de los agentes, el acceso a los datos y el riesgo de ejecutar operaciones automáticas.
Y, sobre todo, debe aprender a decirle a la IA no solo: «hazlo».
Sino también: «hazlo de esta manera, porque...».
Esto también puede cambiar la forma de construir los equipos de TI
Durante años, escalar un equipo de desarrollo significaba incorporar más personas.
¿Más funciones? - Más programadores.
¿Proyecto más grande? - Equipo más grande.
¿Más clientes? - Más personas.
El desarrollo agéntico puede cambiar esta relación.
Eso no significa automáticamente que un programador sustituya a diez otros. Sería una suposición demasiado simplista.
Pero sí puede significar que un programador experimentado pueda supervisar un alcance mucho mayor de trabajo realizado automáticamente.
En la práctica, esto implica un desplazamiento del cuello de botella.
Hoy la limitación puede ser el número de personas que saben escribir código.
Mañana la limitación puede ser el número de personas que sepan diseñar bien, delegar y verificar el trabajo realizado por la IA.
¿Y qué pasa con el junior?
Aquí la situación se vuelve especialmente interesante.
La IA puede generar muy rápido una solución que antes un junior escribiría durante varias horas.
Pero el junior puede no saber si la solución es la correcta.
Eso crea una paradoja.
La IA puede acelerar el aprendizaje de la programación, porque permite experimentar, hacer preguntas y analizar soluciones más rápido.
Al mismo tiempo, puede dificultar el desarrollo de una comprensión fundamental del sistema, si el programador joven acepta código ya hecho sin intentar entender cómo funciona.
Por eso, el futuro de los juniors no tiene por qué significar: «la IA les quitará el trabajo».
Puede significar algo más práctico: El junior que solo sabe escribir código tendrá muchas más dificultades. El junior que sabe entender el código, probar soluciones, analizar problemas y trabajar con agentes construirá un perfil de competencias completamente distinto.
Es la diferencia entre un operador de herramienta y un ingeniero.
El error más caro sigue cometiéndolo el ser humano
Un agente puede generar código incorrecto.
Pero la decisión de desplegarlo todavía puede tomarla una persona.
Y precisamente por eso la responsabilidad del software no se transfiere mágicamente a la IA.
Si un agente crea una función que funciona correctamente en un escenario de pruebas, pero incumple las reglas de negocio, el problema no es que la IA «no entendiera la empresa».
El problema es el proceso que permitió que ese cambio siguiera adelante.
Eso lleva a un cambio muy importante en la forma de pensar sobre la calidad.
Ya no basta con preguntar: «¿El programador escribió un buen código?»
Cada vez con más frecuencia hay que preguntar: «¿El equipo creó un buen proceso para crear código con ayuda de la IA?»
Es una pregunta mucho más amplia.
El agente no sustituye al arquitecto. Aumenta la importancia de la arquitectura
Cuanto más código puede generarse automáticamente, mayor es la importancia de la estructura del sistema.
Una arquitectura bien diseñada permite al agente trabajar dentro de límites definidos.
Una aplicación mal diseñada, en cambio, puede hacer que el agente empiece a rodear los problemas en lugar de resolverlos.
Por eso, la arquitectura, la documentación, las pruebas, los estándares de codificación, CI/CD, la monitorización y el control de acceso pasan a ser no menos importantes, sino potencialmente aún más importantes.
La IA puede acelerar el trabajo en un entorno bien preparado.
No arreglará automáticamente todo el caos organizativo y arquitectónico.
Pero sí puede ampliarlo muy rápidamente.
El futuro no pertenece al programador que escriba más código
Probablemente esta sea la conclusión más importante de todo el cambio.
Durante mucho tiempo, la programación se asoció con escribir código.
Ahora el código se está volviendo cada vez más barato y rápido de producir.
Eso desplaza el valor hacia arriba.
Hacia la comprensión del problema.
El diseño de la solución.
La toma de decisiones.
El control de calidad.
La arquitectura.
La seguridad.
La integración.
La comprensión del negocio.
Y el uso hábil de los agentes.
El programador del futuro puede pasar menos tiempo frente al teclado, pero eso no significa necesariamente que tenga menos trabajo.
Su trabajo simplemente puede verse distinto.
En lugar de escribir manualmente cada función, diseñará la forma en que las funciones se crean.
En lugar de corregir cada error por su cuenta, construirá un proceso que permita a los agentes encontrar y corregir errores.
En lugar de ser el único ejecutor, se convertirá en la persona que marca la dirección del trabajo de varios ejecutores digitales.
Y quizás precisamente por eso, la pregunta más importante del futuro no será: «¿Puede la IA programar?»
Sino: «¿Somos capaces de construir software de forma que la IA pueda trabajar rápido y el ser humano siga sabiendo lo que está pasando?»
Porque en el mundo de los agentes, la mayor ventaja no será solo tener IA.
Será la capacidad de controlarla.
