¡El developer ha muerto! ¡Larga vida al developer!

Tabla de contenido
Con la evolución de herramientas de desarrollo que hacen uso de la IA como GitHub Copilot, Claude Code, Cursor y compañía, es natural preguntarse si el rol del developer está en peligro de extinción.
Desde luego, ya no desarrollamos, o no deberíamos desarrollar, código a mano como antes. Ahora nos apoyamos en estas herramientas para generar código de manera más eficiente y mucho más rápida. Y en este contexto he visto multitud de artículos, posts y reflexiones donde hay quien afirma que el rol del developer está muerto, o que va a morir, o que va a ser sustituido por la IA; y, contrariamente, hay quien afirma que no, que todo es puro alarmismo.
Como todos tienen su propia opinión y, ya sabéis, las opiniones son como los culos, con perdón, todos tenemos una, voy a compartir la mía. Y lo haré desde mi experiencia actual: la de un developer que lleva más de 20 años desarrollando en equipo y que ha vivido la evolución desde los editores de texto hasta las modernas herramientas de IA.
El developer ha muerto #
Sí, el developer ha muerto, tal y como lo oís.
Y si eres developer, deberías cerrar los ojos, respirar hondo, tratar de identificar si de tu alrededor rezuma un tufillo raro… y reflexionar un poco sobre lo que acabo de decir.
Te ayudo con la reflexión. En tu día a día:
- ¿Cuántas veces has tenido que escribir código a mano, sabiendo que generalmente es código repetitivo o rutinario?
- ¿Cuántas veces has tenido que buscar en Google, Stack Overflow, Microsoft Learn o donde tocara cómo hacer algo?
- ¿Cuántas veces has tenido que revisar documentación para entender cómo funciona una API o una librería?
Si la respuesta a estas preguntas es “pocas veces” o “nunca”, entonces quizás no huelas a muerto después de todo. Pero si la respuesta es “muchas veces”, entonces quizás sí que hueles un poco a muerto y deberías empezar a alarmarte lo justo como para buscar un nuevo enfoque de tu rol como developer.
Vale, ¿y qué hacemos entonces? #
Lo primero es aceptar que el rol tradicional del developer ha muerto. O, siendo más precisos, ha muerto ese developer que se dedicaba principalmente a escribir código a mano, a irse a Google, a Stack Overflow o a la documentación para resolver cada duda, y a repetir una y otra vez el mismo tipo de trabajo mecánico.
Ese developer que, si era bueno y se preocupaba por escribir código limpio, eficiente y bien estructurado, se mantenía actualizado montándose proyectos desde cero para probar nuevas librerías y nuevas tecnologías. Ese developer artesano del código, por decirlo así, es el que ha recibido el golpe.
Y la IA lo ha desplazado casi de la noche a la mañana, porque hemos pasado de tener herramientas que apenas ayudaban a completar unas pocas líneas, a tener herramientas que son casi capaces de generar aplicaciones completas, con documentación y tests incluidos, en cuestión de minutos.
Ahora bien, ¿qué hacemos entonces? Como diría Alberto Díaz, “dedicarnos a profesiones con ia: fontanería, albañilería, etc.”. Bromas aparte, lo que creo que debemos hacer es adaptarnos a esta nueva realidad y aprovechar estas herramientas para:
- ser más eficientes,
- generar código de mejor calidad,
- centrarnos en tareas más creativas,
- y dedicar más tiempo a trabajo de mayor valor añadido.
Proceso de adaptación #
El proceso de adaptación a esta nueva realidad no es fácil, ni rápido, ni lineal. Requiere tiempo, paciencia, esfuerzo, aprendizaje y unas cuantas bofetadas de realidad. “¡Pues como siempre!”, dirás. Pero no, aquí no es exactamente como antes.
En el pasado te estudiabas un lenguaje, una librería o un IDE nuevo y, con mayor o menor estabilidad, eso era el conocimiento base. Podía evolucionar, claro, pero no dependía tanto de una variable externa y cambiante. Ahora la variable pesa una barbaridad, y esa variable es la propia IA: cómo te comunicas con ella, qué esperas de ella, qué grado de confianza le das, qué modelo eliges, cuándo iteras, cuándo la paras y le dices “hasta aquí”.
Basándome en mi experiencia actual, creo que este proceso se puede dividir en varias fases. No son necesariamente lineales ni secuenciales; más bien son iterativas, superpuestas y, sobre todo, muy personales. Cada uno de nosotros tiene su contexto, su experiencia y sus necesidades. Pero ahí va mi granito de arena.
Primera fase: primeros pasos #
En esta primera fase yo empezaría a familiarizarme con las herramientas de IA jugueteando en un pet project, sin presión, sin miedo a romper cosas, dejando que la IA me ayude a completar código en el propio IDE prediciendo lo que voy a escribir.
Por ejemplo, puedes empezar con algo tan simple como una función para calcular el factorial de un número. Pones una cabecera con un nombre descriptivo y dejas que la IA te vaya ayudando a autocompletar. Parece una tontería, pero no lo es. Te permite entender cómo se comporta, qué pistas recoge de tu estilo, cómo te puede acelerar y en qué cosas empieza a desviarse.
Aquí ya empiezas a notar que el desarrollo se acelera, porque la IA es especialmente buena ayudándote a generar código repetitivo, rutinario o previsible y, además, muchas veces lo hace con un estilo razonablemente alineado con el tuyo. Como en la película Lucy, aquí podríamos decir que estamos usando un 5%.
Segunda fase: andar por el pasillo de casa #
En esta segunda fase, con un poco más de confianza, yo ya empezaría a usar la IA desde la ventana de chat para pedirle tareas algo más complejas. Por ejemplo, generar una función de Fibonacci, modelar una clase o ayudarte con una pequeña pieza de arquitectura.
Aquí ya no se trata solo de dejar que la IA te ayude a completar código, sino de interactuar con ella de forma más activa: darle instrucciones claras, revisar lo que te devuelve, pedirle correcciones, iterar y ver cómo responde a cambios pequeños en la forma de pedir las cosas.
El salto respecto a la fase anterior no es brutal, pero ya empiezas a sentir que la IA hace cosas de verdad, que te ahorra tiempo y que, a veces, incluso escribe código mejor que tú. He dicho “a veces”. Podríamos ponerle un 15%.
Tercera fase: ¿empezamos a trotar? Ahora qué #
Aquí ya deberías haber ganado suficiente confianza y haberte vuelto lo bastante curioso y lo bastante cómodo, o perezoso, si lo prefieres, como para empezar a usar la IA a otro nivel.
Ya no hablamos de pedirle un método aislado, una optimización o una revisión puntual, sino pequeñas tareas completas: editar varios archivos, generar un modelo, preparar una API o tocar varias capas de una funcionalidad. Pero no seamos ambiciosos demasiado pronto, porque aquí es donde empiezan los problemas de verdad.
Podrías pedirle, por ejemplo, que genere un formulario de alta de usuario con validaciones, el modelo de datos correspondiente y el endpoint de la API para persistirlo en base de datos. Y aquí empieza a ser muuuuuy importante cómo le pides las cosas a la IA.
Porque una petición como “genérame el formulario de alta de un usuario y lo necesario para que se guarde en base de datos” parece clara en tu cabeza, pero en realidad no le has dado casi nada: ni restricciones, ni convenciones, ni estilo, ni arquitectura, ni stack, ni reglas de validación, ni expectativas de seguridad. Tú lo estás visualizando mientras lo escribes; la IA no.
Esto da para otro artículo entero, así que aquí solo adelanto una idea: en este punto deberías revisar el código que genera la IA con muchísimo cuidado. Itera hasta que se acerque exactamente a lo que quieres, porque esa iteración no solo mejora el resultado, también te enseña a comunicarte mejor con la herramienta.
Aquí ya deberías sentir que la IA es una herramienta realmente potente, que te ayuda a generar código muy rápido y que te permite centrarte más en tareas de mayor valor. Podríamos hablar de un 40% o un 50%.
Cuarta fase: no hemos apuntado a una maratón, ¡a correr, runners! #
Si has llegado hasta aquí, ya tienes experiencia con la IA, entiendes mejor cómo funciona, has desarrollado ciertas habilidades para pedirle las cosas y, espero, te has acostumbrado a revisar lo que genera. Sí, revisar. Eso sigue siendo obligatorio.
En esta fase ya deberías empezar a usar la IA para tareas bastante más complejas: el CRUD completo de una entidad, generación de tests unitarios, documentación, refactors amplios, revisiones de arquitectura e incluso agentes con instrucciones y contexto específico para ejecutar tareas de forma bastante autónoma.
Aquí ya no se trata solo de pedirle código, sino de pedirle que te ayude a avanzar con calidad, que optimice lo que ya tienes, que revise lo que ya has hecho y que incluso ejecute pruebas end-to-end o mantenga documentación. La IA pasa de ser una ayuda a convertirse en una compañera de carrera.
Y aquí es donde ya vamos a velocidad de crucero. Dependiendo del tipo de tarea, podríamos hablar de un 50%, un 80% o incluso más.
¡Larga vida al developer! #
Vamos a rebajar el nivel de alarmismo, matar el clickbait y ser un poco realistas. El developer no ha muerto, ni va a morir al menos en un futuro próximo. Lo que sí ha muerto es una forma concreta de trabajar.
Recuerdo que en la Universidad los profesores insistían mucho en la importancia de analizar el problema y diseñar una solución antes de ponerse a escribir código. Y, curiosamente, eso es justo lo que ahora vuelve a tener más valor que nunca. Solo que ya no a nivel de microtarea de sprint, sino a nivel de historia de usuario, funcionalidad, módulo, característica o producto.
Primero analizas y diseñas. Después le das a la IA el contexto adecuado para que implemente lo que tú ya has pensado. Ese, para mí, es el cambio de verdad.
Y por eso creo que hoy podemos afirmar dos cosas a la vez.
1. El developer ha muerto #
Ha muerto el developer que desarrollaba tareas ya troceadas, ya definidas, ya analizadas, con su definition of ready y su definition of done, y que se limitaba a escribir código a mano sin apoyarse en IA. Ese perfil ha dejado de ser competitivo frente a quien sabe usar estas herramientas para llegar antes y, muchas veces, con mejor resultado.
Si estás en ese punto, siento decírtelo, pero quizás deberías ir afinando el olfato para detectar el tufillo. Siendo realistas, todavía puede quedarles un tiempo, unos meses o quizás algo más, pero no mucho margen si el mercado sigue por donde va.
2. ¡Larga vida al developer! #
Tienen mucho futuro quienes hayan evolucionado, o estén en proceso de evolucionar, hacia un rol que se apoya en la IA para generar código, pero que dedica su tiempo y su energía a tareas de mayor valor añadido: análisis, diseño, arquitectura, revisión, criterio y responsabilidad.
Ese developer no solo sigue vivo. Ese developer, hoy por hoy, tiene ventaja competitiva.
Conclusión #
Vivimos un proceso de grandes cambios que sucede a un ritmo vertiginoso y que está afectando directamente a nuestra profesión, irónicamente impulsado por la propia tecnología que hemos creado y por los propios profesionales del sector.
No es un proceso de adaptación fácil, porque implica cambiar nuestra forma de pensar al abordar los desarrollos y porque comunicarse con la IA no es algo a lo que estuviéramos acostumbrados. La IA no entiende lo que le pedimos exactamente como nosotros creemos que lo estamos diciendo. Y ahí hay una curva de aprendizaje muy real.
Pero es un proceso que debemos afrontar con una mentalidad abierta y con una actitud proactiva. Porque si no lo hacemos, corremos el riesgo de quedarnos atrás y de perder relevancia como developers.
¡ Have fun & enjoy coding, con IA! 🚀