El rol del developer está cambiando de foco: en lugar de escribir cada línea de código, buena parte del día a día pasa por dar instrucciones claras y supervisar el trabajo de un agente de inteligencia artificial. Ese cambio no elimina la necesidad de conocimiento técnico, todo lo contrario: para dar indicaciones correctas a una herramienta como IBM Bob, el developer necesita entender bien qué significa una aplicación, cómo funciona un patrón como modelo-vista-controlador y qué implica cada decisión de arquitectura, porque sin ese criterio de base es fácil perderse en el proceso.
De escribir a supervisar
La ganancia más concreta de este cambio es la eliminación de tareas repetitivas y sencillas, ese tipo de trabajo mecánico que en la jerga de desarrollo suele llamarse “talacha”: crear un método básico, escribir código CSS casi idéntico entre pantallas, ajustar valores de ancho y alto una y otra vez. Antes, resolver algo tan simple como obtener una fecha en Java implicaba buscar el fragmento de código adecuado y copiarlo; hoy, ese tipo de tarea se resuelve con una instrucción directa al agente.
El impacto se nota especialmente en equipos de frontend, donde una idea de interacción visual —que un elemento se mueva, cambie de color al pasar el mouse, se adapte a distintas pantallas— antes implicaba cientos de líneas de código repetitivo. Delegar esa parte del trabajo en un agente acelera el tiempo de desarrollo y el go-to-market, y permite ejecutar una idea sin necesidad de invertir tanto tiempo en el detalle técnico de implementarla.
Lo que Bob no puede reemplazar
Ese avance, sin embargo, no borra la diferencia entre programar y desarrollar software. Programar es escribir líneas de código, algo que un agente como Bob puede resolver bien. Desarrollar software es un proceso más amplio, que exige decisiones que siguen siendo responsabilidad del developer.
La primera es la chispa creativa: ninguna IA va a proponer por sí sola una interfaz innovadora o una idea disruptiva; eso sigue naciendo de una persona que después trabaja junto al agente para construirla. La segunda es la visión arquitectónica: definir dónde se va a desplegar un sistema, cuánta capacidad de procesamiento en paralelo necesita, qué paradigma de programación conviene usar o qué recursos de memoria y CPU son necesarios son decisiones que la IA puede ayudar a planificar, pero no toma por su cuenta si no se le pide explícitamente. La tercera es la validación final: alguien tiene que confirmar que lo que hizo el agente funciona correctamente dentro de todo el ecosistema, y esa responsabilidad sigue siendo humana.
Nuevas habilidades necesarias
Trabajar bien con este tipo de herramientas requiere dominar el prompt engineering, una habilidad que llegó para quedarse. Pero el punto que suele pasarse por alto es que esto no reemplaza el conocimiento técnico: lo vuelve todavía más necesario. Un developer que no entiende en profundidad un lenguaje como COBOL, o que no maneja bien temas de seguridad y vulnerabilidades, difícilmente pueda darle a Bob instrucciones precisas ni detectar errores en lo que el agente produce.
Ahí aparece una versión actualizada del viejo problema de “garbage in, garbage out”: si el prompt de partida es malo porque quien lo escribe no terminó de entender el problema, el resultado también lo será, sin importar qué tan sofisticada sea la IA detrás. Saber desarrollar software, conocer lenguajes de programación en profundidad y entender el contexto de seguridad que rodea a cada proyecto siguen siendo, en definitiva, la base sobre la que se apoya cualquier avance de productividad que ofrezca un agente de IA.
De mantenerse esta tendencia, la frontera entre programar y desarrollar software probablemente se vuelva cada vez más nítida: la escritura de código seguirá automatizándose, mientras que las habilidades que hoy distinguen a un buen developer —criterio de arquitectura, conocimiento profundo de lenguajes y seguridad, capacidad de validar lo que produce un agente— pasen a ser, más que nunca, el verdadero diferencial del rol.
Compartir nota:
