Más builder que coder

A fecha de octubre de 2026. Para quienes desarrollan software y se preguntan qué parte de todo eso seguirá siendo su trabajo dentro de cinco años. Ni réquiem ni paños calientes.

Para muchos de nosotros, programar nunca fue solo una profesión. Era aquello en lo que éramos realmente buenos. De ello dependían la autoestima, el reconocimiento en el equipo y, no menos importante, el sueldo.

Ese mismo oficio lo hace ahora una máquina en segundos, al menos en gran parte. Quien no sienta cierta inquietud ante esto no está mirando con atención.

La respuesta corta, por adelantado: el desarrollo de software no desaparece, pero se desplaza. Se aleja de escribir código y se acerca a describir, revisar y responsabilizarse. Este desplazamiento no afecta a todos por igual, y exige algo más que herramientas nuevas: otra forma de entenderse a uno mismo.

No escribo esto desde fuera: llevo décadas siendo un apasionado desarrollador y arquitecto de software. Y desde hace varios meses ya no programo – al menos no en el sentido clásico. Por suerte, en el camino he comprobado lo que un colega al que aprecio formuló así sobre sí mismo: soy más builder que coder.

Lo que está cambiando de verdad

Las herramientas han llegado y las ganancias son reales – pero peor repartidas de lo que promete la publicidad. Y el mercado laboral golpea primero a los más jóvenes.

El uso aumenta, el entusiasmo no. En la encuesta a desarrolladores de Stack Overflow, la proporción de usuarios de IA pasó del 44 por ciento (2023) al 62, luego al 79 y al 83 por ciento (2026). Una encuesta intermedia de abril de 2026 muestra casi el doble de uso de agentes que un año antes: un 59 frente a un 31 por ciento. La valoración positiva cayó del 72 por ciento (2024) a poco menos del 60 y en 2026 se sitúa en el 62 por ciento; la proporción de quienes ven la IA como una amenaza para su propio empleo subió en 2025 del 12 al 15 por ciento (Stack Overflow, sept. de 2026; encuesta de 2026).

La productividad percibida es una mala medida. METR realizó un estudio controlado: 16 desarrolladores experimentados de código abierto, 246 tareas reales en proyectos que conocían desde hacía años. Con IA tardaron un 19 por ciento más – y después calcularon que habían sido un 20 por ciento más rápidos (METR, julio de 2025).

Ese resultado ya está superado, y de una forma muy instructiva. El estudio de seguimiento, con herramientas de finales de 2025, muestra indicios de aceleración, pero apenas puede evaluarse: demasiados desarrolladores, sencillamente, ya no querían trabajar sin IA y evitaron el estudio o determinadas tareas (METR, feb. de 2026). Eso dice más sobre el estado de las cosas que cualquier porcentaje.

La IA amplifica lo que ya existe. El informe DORA 2025 de Google describe la IA como un amplificador: hace mejores a los buenos equipos y hace que los débiles empeoren más deprisa. Sin una base sólida de pruebas, cambios pequeños y procesos claros, aumenta el ritmo de entrega, pero se resiente la estabilidad (DORA 2025).

En mi caso, este amplificador actúa en la buena dirección. Eso no contradice el estudio de METR: midió en 2025 con los asistentes de entonces, una tarea tras otra. Yo trabajo con agentes, a menudo con varios en paralelo – y, según el propio METR, una medición del tiempo por tarea no puede captar eso. En un producto que llevo años construyendo, una IA resolvió nueve fallos documentados, uno de ellos inadvertido durante seis años; mis indicaciones cabían en diez líneas de chat. Una deuda técnica que llevaba siete años ahí desapareció en una noche. Y esta web se publicó un día después del primer commit. La base para ello es aquella de la que habla DORA: pruebas, pasos pequeños, salvaguardas claras.

En el mercado laboral, los primeros afectados son los principiantes. En Estados Unidos, en septiembre de 2025 el empleo de desarrolladores de software de entre 22 y 25 años estaba alrededor de un 20 por ciento por debajo de su máximo de finales de 2022; el de los colegas mayores se mantuvo estable o creció (Stanford Digital Economy Lab). Cuánto de eso se debe realmente a la IA sigue siendo discutido: el giro en los tipos de interés, la corrección tras la pandemia y el teletrabajo también influyen, y el efecto total sobre el empleo es pequeño por ahora (SIEPR, julio de 2026).

En Alemania la situación es parecida, solo que más discreta. Bitkom, la asociación alemana del sector digital, contabiliza 79.000 puestos de TI vacantes, frente a 149.000 en 2023 – sobre todo como consecuencia de la coyuntura económica. Solo el 10 por ciento de las empresas que usan IA en TI han suprimido por ello algún puesto aislado. Pero el 55 por ciento espera que desaparezcan las tareas clásicas de iniciación, y el 74 por ciento, que dirigir y controlar la IA gane importancia (Bitkom, sept. de 2026).

El panorama en una frase: ninguna extinción masiva de empleos de desarrollo, sino un desplazamiento que empieza en la puerta de entrada y desde ahí va subiendo.

Los miedos – y qué hay de cierto en ellos

Tener miedo no significa estar atrasado. La mayoría de las preocupaciones de los desarrolladores son una evaluación sobria de la situación, y algunas están sencillamente justificadas.

«Voy a sobrar». No es del todo infundado. Si una persona con agentes consigue lo que antes requería a tres, los equipos se planifican más pequeños y hay puestos que ni siquiera llegan a anunciarse. Según Bitkom, el 35 por ciento de las empresas que suprimen puestos o cuentan con hacerlo sustituyen por IA vacantes de TI – y en el 47 por ciento de esos casos los recortes afectan a profesionales experimentados, no solo a principiantes. Los datos no muestran recortes generalizados; que la experiencia por sí sola ya no protege, eso sí lo muestran con toda claridad.

«Para los principiantes ya no hay escalera». Esta preocupación está bien fundada. Las tareas con las que antes aprendían los juniors – bugs pequeños, formularios, interfaces estándar – hoy las hace la máquina. En un experimento de Anthropic (que es a su vez un proveedor de IA), los desarrolladores que aprendían una biblioteca nueva con ayuda de IA sacaron un 17 por ciento menos en la prueba de comprensión posterior; la mayor diferencia se dio en la depuración (Anthropic, ene. de 2026). Quien hoy no forma a juniors no tendrá seniors dentro de diez años – y eso no es un problema de los principiantes, sino de todo el sector.

«Estoy perdiendo el oficio». Los experimentados también lo notan: quien ya solo da el visto bueno pierde práctica. En la encuesta de Stack Overflow de 2025, alrededor del 20 por ciento dijo tener menos confianza en su propia capacidad para resolver problemas a causa de la IA; al 16 por ciento le costaba entender cómo o por qué funciona el código generado. El mecanismo que hay detrás lo describe en detalle Qué nos hace la IA.

«Pierdo lo que me gustaba». Es una preocupación de la que a menudo se sonríe y, sin embargo, es sencillamente humana. Muchos se hicieron desarrolladores porque les encanta escribir código: el flow, darle vueltas a un problema, la solución elegante. Quien en cambio se pasa el día revisando código generado por IA se siente enseguida degradado a corrector – y tiene derecho a lamentarlo.

«Respondo de un código que no he escrito». Cierto, y seguirá siendo así. Los resultados de la IA suelen ser casi correctos, y en el software «casi correcto» sale caro enseguida. Incluso en un futuro en el que la IA programe la mayor parte, tres cuartas partes de los encuestados de Stack Overflow (2025) preguntarían a una persona cuando no se fían de la respuesta de la máquina. La responsabilidad no pasa a la IA; se concentra en quien pulsa «Merge».

«Ya no doy abasto». Cada mes un modelo nuevo, una herramienta nueva, un flujo de trabajo nuevo. Según Bitkom, el 61 por ciento de las empresas espera que los profesionales de TI estén sometidos a más presión para formarse continuamente. Así que la sensación de ir siempre por detrás no es imaginación.

Ninguna de estas preocupaciones se disuelve con buenas palabras. Pero para cada una hay una respuesta que es algo más que «aprende prompting y listo».

Lo que no es cierto – en ninguno de los dos bandos

El debate se resiente de que ambos bandos cuentan historias demasiado simples. Quien quiera orientarse debería conocer las dos.

Lo que el bando del hype cuenta mal:

• «Pronto nadie necesitará desarrolladores». Los datos no lo muestran. En Estados Unidos, las ofertas de empleo para desarrolladores de software crecieron últimamente incluso más deprisa que las de otras profesiones, y las empresas que implantaron la IA de forma amplia contrataron después a más personas, no a menos (SIEPR). En muchos despidos que se justifican con la IA, ni siquiera entre los economistas hay acuerdo sobre si la IA es la causa o solo una explicación cómoda.
• «Con IA, todo el mundo es diez veces más productivo». Teclear más rápido no significa entregar más rápido. El cuello de botella se desplaza de escribir a revisar, probar y coordinar – y quien no se pone al día ahí produce, sobre todo, errores más deprisa.
• «El prompting es la nueva competencia clave». Los trucos de prompt caducan con cada modelo. Lo que queda es la capacidad de describir y acotar un problema con tanta claridad que una persona o una máquina pueda resolverlo. Antes eso se llamaba análisis de requisitos.

Lo que el bando de la defensiva cuenta mal:

• «Es una moda que pasará». Cuando desarrolladores experimentados evitan un estudio remunerado porque tendrían que hacer la mitad de sus tareas sin IA, eso ya no es un fuego de paja.
• «El código de IA es basura por definición». El código de IA es tan bueno como el contexto, las pautas y la revisión que lo rodean. El código malo suele surgir allí donde ya antes se trabajaba sin pruebas ni una arquitectura clara.
• «Tengo demasiada experiencia para cambiar a estas alturas». Es justo al revés: el criterio, el olfato para la arquitectura y el conocimiento del dominio son lo que hace falta para dirigir la IA y evaluar sus resultados. Aquí la experiencia no es un lastre, sino el capital – si uno la pone en juego en lugar de defenderla.
• «Si no lo uso, no me afecta». El mercado se mueve igualmente. Según Bitkom, el 63 por ciento de las empresas espera que en el futuro se necesiten conocimientos de IA en todas las profesiones de TI.

Roles en transformación: de escribir a responsabilizarse

Durante mucho tiempo, el código fue el bien escaso. Ahora es barato – lo escaso es la claridad, el criterio y alguien que dé la cara por el resultado.

Claridad significa: ¿qué hay que construir exactamente, para quién, con qué condiciones? Criterio significa: ¿es correcto, seguro, mantenible, y encaja en el conjunto? Responsabilidad significa: ¿quién le explica al cliente por qué no funciona?

Una imagen ayuda: quien antes era albañil pasa más bien a ser jefe de obra. Pero un buen jefe de obra tiene que saber levantar una pared – si no, no ve cuándo se tuerce. Así que el oficio no desaparece; se desplaza de ejecutar a evaluar.

Cada rol lo vive de forma distinta:

Rol	Lo que se reduce	Lo que crece
Principiante	Las tareas rutinarias como campo de práctica	Saber leer, depurar y explicar código; entender en lugar de copiar
Desarrollador	Boilerplate, lógica estándar, consultar documentación	Descomponer tareas, aportar contexto, revisar resultados, pruebas como especificación
Senior / arquitecto	Implementar uno mismo	Fijar salvaguardas (arquitectura, convenciones, reglas para agentes), revisiones, mentoría
Pruebas / QA	Escribir casos de prueba a mano	Estrategia de pruebas, criterios de aceptación, la revisión de la revisión
Team lead / product owner	Estimar en días-persona	Requisitos precisos, priorización, decisiones más rápidas

Más difícil es lo que no aparece en ninguna tabla: la imagen de uno mismo. «Soy lo que programo» ya no se sostiene. Más sólido es: «Me encargo de que se construya software que resuelva un problema real – y sé justificar por qué es correcto».

A eso se suma que el conocimiento del dominio vale cada vez más que el de los frameworks. Una IA conoce cada API de .NET, pero no las particularidades de una facturación de energía ni las reglas no escritas de la casa del cliente. Quien entiende el dominio para el que construye es difícil de sustituir.

Desarrollo personal: más que una herramienta nueva

El cambio es mitad proyecto técnico y mitad proyecto personal. La segunda mitad casi siempre se subestima.

Reconocer un final. El consultor organizacional William Bridges distinguía entre el cambio, que viene de fuera, y la transición interior que cada uno tiene que recorrer por sí mismo. Toda transición empieza con un final; luego viene una zona intermedia incierta, y solo después un nuevo comienzo. Quien hace como si nada cambiara se queda atascado más tiempo en la zona intermedia. Ayuda reconocer con sinceridad lo que uno va a echar de menos.

Anclar de nuevo la autoestima. Quien mide su valor por la cantidad de código que ha escrito él mismo pierde frente a cualquier máquina. Son más sólidos los criterios que una IA no puede cumplir: el problema resuelto, la buena decisión, la confianza de clientes y colegas.

Permitirse volver a ser principiante. Sobre todo a los experimentados les cuesta. Las nuevas formas de trabajar se sienten más lentas y torpes durante las primeras semanas – es normal y no demuestra que no sirvan.

Hablar y escribir con claridad. Quien sabe describirle bien una tarea a una IA también sabe describírsela a un colega: nombrar el objetivo, poner las suposiciones sobre la mesa, fijar criterios de aceptación. Lo mismo vale para las conversaciones con las áreas de negocio. Hacer las preguntas adecuadas se convierte en la tarea central – y eso es comunicación, no técnica.

Juzgar y contradecir. Una IA siempre suena convencida. Decirle «Eso está mal» a una respuesta rápida, amable y segura de sí misma requiere confianza en uno mismo (más sobre esto en Convincente, pero falso). Y frente a superiores que ahora esperan el triple, hace falta valor para asumir compromisos realistas.

Transmitir. La experiencia no pierde su valor; se convierte en una tarea docente. Explicar por qué se descarta una solución que aparentemente funciona es un conocimiento valioso que un senior puede transmitir hoy.

Encontrar el propio ritmo. Nadie tiene que dominar cada herramienta el día en que sale. Quien se reinventa cada semana acaba quemado. Mejor: aprender a fondo una herramienta, comprobar con calma qué merece la pena.

El cambio en la práctica

El camino hacia el desarrollo asistido por IA no pasa por cursos, sino por trabajo real – en pasos pequeños y verificables.

1. Empezar con algo pequeño y real. Nada de apps de demostración, sino una tarea manejable de tu propio día a día: pruebas para código existente, un script de migración, documentación que falta.
2. Pasar del autocompletado a los agentes. El chat y las sugerencias de código son un comienzo. La forma de trabajar solo cambia cuando un agente lee archivos, ejecuta comandos y lanza las pruebas por sí mismo – con salvaguardas claras.
3. Poner el contexto por escrito. La arquitectura, las convenciones, las prohibiciones y los términos del dominio van en un archivo del proyecto que el agente lee cada vez que arranca (por ejemplo AGENTS.md, CLAUDE.md o copilot-instructions.md). Por qué eso marca tanta diferencia lo explica Cuando al modelo se le acaba el contexto.
4. Primero que planifique, luego que construya. Pide un plan y corrígelo antes de que se escriba código. Un plan equivocado cuesta dos minutos; un código equivocado, dos horas.
5. Convertir las pruebas en la especificación. Sin pruebas, el trabajo con agentes es una lotería. Deja tranquilamente que se generen pruebas – pero revísalas tú mismo, porque son el contrato.
6. Leer cada diff como el de un colega nuevo. La regla básica: no hagas merge de nada que no sepas explicar.
7. Al aprender, preguntar en lugar de delegar. Quien aprende algo nuevo debería pedir explicaciones y plantear preguntas conceptuales en lugar de recoger código ya hecho. Ese comportamiento distinguió, en el experimento de Anthropic, a los participantes que aprendieron mucho de los que retuvieron poco. Muchas herramientas tienen para ello modos propios de aprendizaje o de explicación.
8. Practicar sin IA a propósito. Cazar de vez en cuando un bug por tu cuenta, diseñar tú mismo un módulo – no por nostalgia, sino para conservar el criterio.
9. Medir en lugar de fiarse de la sensación. Anota en unas cuantas tareas el tiempo, el retrabajo y los errores – con y sin IA.

Si estás empezando: no demuestres que sabes generar código, sino que lo entiendes. Leer código, depurar, justificar una decisión – eso te distingue de cualquiera que solo envía prompts. Y búscate un dominio que de verdad te interese.

Si llevas mucho tiempo en esto: tu experiencia es la palanca, no el obstáculo – úsala para las salvaguardas, las revisiones y el acompañamiento de los principiantes.

Para equipos y responsables

Que el cambio salga bien rara vez se decide en la herramienta, sino en la organización que la rodea. Quien tiene responsabilidad de liderazgo carga aquí con la mayor parte.

• Formular una postura clara. ¿Qué herramientas están permitidas, qué datos pueden entrar, quién responde de qué? La falta de claridad produce o IA en la sombra o parálisis. Entre los fundamentos que DORA señala para una adopción exitosa de la IA figura esa postura comunicada con claridad.
• Los cimientos antes que la velocidad. Pruebas, cambios pequeños, retroalimentación rápida desde el pipeline y tiempo suficiente para revisar: lo que sin IA era buena práctica se vuelve obligatorio con IA.
• Seguir contratando principiantes – y formarlos de otra manera. Un plan de formación en lugar de un plan de sustitución: los juniors explican en la revisión lo que ha construido el agente, resuelven a propósito tareas sin IA y trabajan codo con codo con los experimentados.
• No gastarse las ganancias enseguida. Quien convierte cada hora ganada directamente en más tickets o en menos personal le quita al equipo el tiempo para aprender – y obtiene miedo en lugar de compromiso.
• Hablar del miedo. Las conversaciones abiertas sobre las preocupaciones aportan más que las tasas de uso en un dashboard. La seguridad psicológica es la condición para que la gente informe de los errores de la IA en lugar de ocultarlos.
• Redefinir las trayectorias profesionales. ¿Qué significa «senior» en un equipo con agentes? Deberían valorarse el criterio, la calidad de las decisiones y la capacidad de hacer mejores a los demás – no el número de commits.

Conclusión

La respuesta a «¿Qué será de nosotros?» es: será distinto, y para algunos más duro que para otros. A los principiantes les toca primero; los experimentados caen en la tentación de seguir como si nada. Ambas cosas tienen solución, pero no se resuelven solas.

Se seguirá necesitando software, probablemente más que nunca. Lo que hace falta son personas que entiendan qué hay que construir, sepan juzgar si es correcto y respondan por ello. Eso no es un descenso de artesano a corrector, sino el paso de ejecutar a responsabilizarse – si se da de forma consciente.

Revisado el 5 de octubre de 2026 tras comentarios de lectores: menos superlativos, más conciso y ampliado con mi experiencia con agentes. Actualizado el 7 de octubre de 2026 con la encuesta de Stack Overflow de 2026.