“Cuando cualquiera puede construir cualquier cosa, saber qué merece ser construido se convierte en la habilidad clave.” - Kent Beck

Llevo meses escribiendo mucho menos código del que escribía antes. No cero, pero sí lo suficiente como para darme cuenta de algo incómodo: cada vez importa menos. Y no soy el único, el 84% de los desarrolladores ya usa IA en su trabajo o plantea usarla en breve.

Si generar código ya no es un problema, ¿a qué se tiene que dedicar un desarrollador?

Tu valor ya no está en escribir código

Hay algo curioso pasando en equipos que adoptan IA: producen más, pero no necesariamente mejor.
Más PRs, más velocidad… pero también más revisión, más fricción, y a veces más bugs. Los datos de Faros AI (10.000+ desarrolladores): 98% más PRs, pero el tiempo de revisión sube un 91% y los bugs por desarrollador crecen un 9%. No porque la IA sea mala, sino porque acelera justo la parte que no era el problema. El problema nunca fue escribir código. Es decidir qué construir, cómo validarlo y cómo mantenerlo bajo control.

La IA no funciona sola. El estudio de METR de principios de 2025 decía que desarrolladores experimentados tardaron un 19% más con IA. Pero usaron Cursor Pro directamente, sin preparar los repos, sin contexto, sin reglas, sin hooks. Así cualquier herramienta rinde mal.
Tienes que configurar tu entorno para que la IA trabaje bien.

Escribir código ya es trivial en muchos casos. Que ese código sea correcto y mantenible requiere invertir tiempo y esfuerzo en configurar el sistema.

Tres cosas a las que dedicarte si eres desarrollador

1. Arquitecto de guardarraíles: diseña el sistema que verifica, no verifiques tú

Martin Fowler distingue entre estar en el loop (revisas cada línea, que es totalmente insostenible) y estar sobre el loop (diseñas el sistema que revisa por ti). Lo llama Harness Engineering.

En la práctica esto es: linting automático, tests que ejecuta el propio agente en su loop, mutation testing como red de seguridad real, y LLM-as-judge, una IA evaluando el output de otra.
Addy Osmani lo resume muy bien: tu trabajo ya no es escribir código, es construir la fábrica que lo construye.

Tu responsabilidad pasa de revisar PRs a diseñar los controles que hacen la revisión innecesaria.

2. Ingeniero de especificaciones: define el qué, deja el cómo al agente

Cada vez más, el trabajo real del desarrollador es escribir buenas especificaciones: qué tiene que hacer esto, qué restricciones tiene, cómo sé que está bien hecho. El agente se encarga del cómo. La revisión deja de ser de código y pasa a ser de especificaciones.

Kent Beck habla de deflación de la programación y lo explica de forma muy clara: programar se está abaratando, como cuando un producto baja de precio. Lo que no se abarata es todo lo demás. Entender el problema, saber descomponerlo, tener criterio para decidir qué construir y qué no. Esas habilidades ahora valen más que nunca, precisamente porque el código ya no es lo escaso.

3. Habilitador de plataforma: consigue que otros no te necesiten

Este es el cambio más radical. Tu trabajo ya no es escribir el código del producto. Es conseguir que otros no te necesiten para escribirlo. Creas las herramientas, automatizaciones y guardarraíles para que POs, PMs, diseñadores y otros roles del negocio construyan directamente. Pero ojo: esto solo funciona si el punto 1 está resuleto. Sin los guardarraíles, dejar que esos roles desplieguen código a producción es una receta para el desastre.

Andrew Ng ya lo está viviendo: el ratio de 4 ingenieros por PM se está invirtiendo en algunos de sus equipos. El cuello de botella se ha movido de implementar a definir. Ya no hablamos de developer experience para devs, hablamos de developer experience para todos los roles.

El modelo de negocio también cambia, y tú con él

No solo hay cambio en rol, hay cambios en los modelos de negocio que nos obligan a adaptarnos. El SaaS tradicional te da herramientas para que los humanos hagan su trabajo. El nuevo modelo, Service as Software, ofrece agentes que hacen el trabajo directamente.
Hasta ahora pagabas por un software de atención al cliente (Zendesk, Intercom) y ponías personas a usarlo. El nuevo modelo es un agente que directamente resuelve las consultas del cliente. No pagas por la herramienta, pagas por cada consulta resuelta. Salesforce ya cobra así en Agentforce.

Aquí es donde se complica. Cada vez que el agente corre estás pagando. A veces acierta, a veces no. Y cuando no, no es un bug que apuntas en Jira: es un error que ya ha tomado decisiones y puede haber arrastrado otros detrás.

El cambio ya está aquí

El desarrollador no desaparece, pero su trabajo cambia:

• De escribir código a decidir qué código merece existir
• De revisar PRs a diseñar sistemas de validación
• De implementar features a habilitar que otros las construyan
• De developer experience para devs a developer experience para todos los roles

Ahora que el código es barato, lo escaso es el criterio.

Este artículo no existiría sin Gorka Moreno por compartir todo lo que están aprendiendo y Emilio Carrión por artículos como este.