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.

Este texto intenta ambas cosas. No restar importancia a los problemas – y, aun así, mostrar un camino transitable.

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 menores y peor repartidas de lo que promete la publicidad. Y el mercado laboral golpea primero a los más jóvenes.

El uso se dispara, 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 y luego al 79 por ciento (2025). 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. Al mismo tiempo, la valoración positiva cayó del 72 a poco menos del 60 por ciento, y la proporción de quienes ven la IA como una amenaza para su propio empleo subió del 12 al 15 por ciento (Stack Overflow, sept. de 2026).

La productividad percibida es una mala medida. El estudio más riguroso hasta la fecha es de METR: 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 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». Probablemente sea la preocupación más justificada. 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 la preocupación de la que más se sonríe y, sin embargo, la más 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 «casi correcto» es la categoría más cara del software. Incluso en un futuro en el que la IA programe la mayor parte, tres cuartas partes de los encuestados de Stack Overflow 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. La sensación de ir siempre por detrás no es imaginación, sino la percepción realista de un mercado que gira más deprisa que nunca.

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 la explicación más 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 exactamente 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? Según Bitkom, tres cuartas partes de las empresas esperan que precisamente esa dirección y ese control de la IA ganen importancia para los profesionales de TI.

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

La parte más difícil 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 es quien más tiempo se queda atascado 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. Para los experimentados es lo más incómodo. 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 quizá el conocimiento más 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 – y seguir haciendo algunas cosas uno mismo a propósito, no por nostalgia, sino para conservar el criterio.

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 más importante de todas: 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. Justo 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. Eso mantiene despierta justo la capacidad que necesitas para revisar.
9. Medir en lugar de fiarse de la sensación. El estudio de METR mostró lo mucho que pueden separarse la sensación y la realidad. 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 construir salvaguardas, evaluar resultados y acompañar a los principiantes – y permítete ser principiante durante un tiempo en el manejo de las herramientas.

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 precisamente esa postura comunicada con claridad.
• Los cimientos antes que la velocidad. Pruebas, cambios pequeños, retroalimentación rápida desde el pipeline: lo que sin IA era buena práctica se vuelve vital con IA. Si no, la IA sobre todo amplifica las debilidades que ya existen.
• Prever capacidad de revisión. El cuello de botella se desplaza de escribir a revisar. Quien no lo prevé obtiene más código y menos calidad.
• 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. Quien corta la escalera de entrada no tendrá dentro de unos años a nadie que sepa evaluar los resultados de la IA.
• 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. Los principiantes cargan con el mayor riesgo; los experimentados, con la mayor 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.