¿Qué queda del trabajo de developer cuando la IA escribe el código?

El momento en que algo cambia

Imagina que necesitas añadir una funcionalidad a un proyecto Django. Le das a un LLM unas pocas frases describiendo lo que quieres. Cuando vuelves con el café, el código está hecho. Más o menos perfectamente.

No es un caso hipotético. Es lo que ya le está pasando a desarrolladores en activo. Y no es solo una cuestión de productividad: es un punto de inflexión que sacude algo más profundo. Si el código ya no requiere de ti, ¿qué requiere?

Esta pregunta no tiene una respuesta cómoda. Pero sí tiene una respuesta honesta, y eso es lo que vamos a intentar aquí.

La crisis de identidad que nadie menciona en los webinars de IA

Hay una conversación que ocurre en paralelo a todos los titulares sobre productividad con IA. Es la conversación que tienen los desarrolladores entre ellos, en foros y canales privados, cuando nadie del equipo de dirección está mirando.

Y suena más o menos así: 'Entré en este campo porque me encanta resolver problemas, encontrar patrones, construir sistemas. No entré para supervisar lo que genera una máquina.'

Eso no es resistencia al cambio. Es una pregunta legítima sobre identidad profesional. Durante años, escribir código bien —con precisión, con elegancia, entendiendo profundamente el problema— era el núcleo del trabajo. Ahora ese núcleo se está desplazando, y no todo el mundo sabe hacia dónde moverse.

Algunos desarrolladores lo han verbalizado sin rodeos: si querían decirle a otros cómo hacer las cosas, habrían optado por ser project managers. El sueldo habría sido mejor. El problema no es solo que la IA programe, sino que también razona, sugiere y en cierta medida decide. Eso cambia qué significa ser el experto en la sala.

Qué está pasando realmente en las empresas

El escenario que más preocupa no es el del developer que usa LLMs para ir más rápido. Ese es el escenario optimista. El que preocupa es el otro: el del directivo que, después de ver que un empleado sin formación técnica puede hacer un commit en GitHub con ayuda de Claude, concluye que la supervisión técnica es prescindible.

En algunas empresas ya está ocurriendo. Perfiles no técnicos construyen herramientas internas con IA. El QA se convierte en copiar y pegar entre el asistente y el sistema de tickets. La documentación la genera automáticamente el modelo. Y la dirección, encantada con la reducción de costes a corto plazo, da por hecho que el resto puede seguir el mismo camino.

El problema es que este enfoque funciona hasta que no funciona. Y cuando falla, falla en producción.

Los LLMs no son deterministas. El mismo prompt puede producir resultados diferentes en distintas ejecuciones. Eso los hace inadecuados para tareas críticas sin verificación humana: una migración de base de datos mal ejecutada, un pipeline de CI/CD con un bug silencioso, o una integración que filtra datos que no debería. La IA no asume responsabilidad por esos errores. Alguien tiene que hacerlo.

Los roles que van a crecer y los que van a menguar

Siendo directos: los roles centrados en código repetitivo, boilerplate y tareas CRUD tienen los días contados tal como los conocemos hoy. No porque sean fáciles, sino porque son exactamente el tipo de trabajo para el que los LLMs están optimizados. Un junior que pasa el día generando formularios y endpoints estándar tiene menos valor diferencial que hace tres años.

Eso no significa que los juniors vayan a desaparecer. Significa que el perfil que se busca va a cambiar más rápido de lo que el mercado laboral sabe procesar.

Por otro lado, hay roles que están ganando peso real:

• Arquitectura y diseño de sistemas: decidir cómo se estructura una solución, qué tecnologías se eligen, cómo se gestionan los trade-offs entre rendimiento, mantenibilidad y coste. Esto requiere criterio y experiencia acumulada. Un LLM puede sugerir opciones, pero no puede asumir las consecuencias de la decisión.
• Supervisión y validación de código generado por IA: alguien tiene que revisar que lo que produce el modelo sea seguro, auditable y coherente con el resto del sistema. Este rol no es glamuroso, pero es crítico y cada vez más demandado.
• DevOps e infraestructura: aquí hay un matiz importante. Varios desarrolladores están pivotando hacia este espacio pensando que es una extensión natural del desarrollo. No lo es. Son disciplinas distintas con años de aprendizaje propios. El salto es posible, pero requiere humildad y tiempo real de formación.
• Tech leads y roles de toma de decisiones estratégica: gestionar la tensión entre lo que la IA puede hacer, lo que el negocio quiere y lo que es técnicamente responsable. Ese equilibrio no se puede delegar a un modelo.

Hay desarrolladores que ya han hecho esta transición y describen el resultado con una mezcla de alivio y nostalgia. Echan de menos la programación tranquila, la satisfacción de resolver un problema elegante ellos solos. Pero también reconocen que su vida fuera del trabajo ha mejorado, que resuelven problemas con mayor impacto, y que la toma de decisiones a nivel superior tiene su propio tipo de satisfacción.

Usar IA bien es una habilidad en sí misma

Hay una trampa sutil en la adopción de LLMs que vale la pena nombrar: confundir usar IA para cada paso con usar IA sabiamente.

El desarrollador que delega todo el razonamiento al modelo acaba con dos problemas. Primero, pierde la capacidad de detectar cuándo el output es incorrecto, porque ha dejado de ejercitar el músculo de pensar el problema. Segundo, se vuelve completamente dependiente de una herramienta que, por su naturaleza no determinista, no garantiza consistencia.

La estrategia que funciona es más matizada: iterar primero con tu propio criterio, usar el LLM para las partes tediosas (buscar en el codebase, generar tests de cobertura básica, escribir documentación, hacer boilerplate), y mantener el control sobre las decisiones que importan. Esto preserva el expertise y, de paso, hace que el output de la IA sea mucho mejor porque quien lo supervisa entiende lo que está mirando.

No es una estrategia heroica. Es simplemente no tirar por la borda años de conocimiento técnico por el entusiasmo del momento.

El problema real para las pymes: el coste oculto de la automatización sin criterio

Para una empresa en crecimiento, el ROI de integrar LLMs en el flujo de desarrollo es real. Menos tiempo en tareas repetitivas, documentación más ágil, prototipos más rápidos. Eso no está en discusión.

Lo que sí está en discusión es qué pasa cuando esa integración se hace sin preservar expertise técnico interno. Porque los problemas que vienen después son difíciles de atribuir directamente a la IA: fragilidad técnica acumulada, decisiones de arquitectura que nadie sabe justificar, código que funciona pero que nadie entiende lo suficiente como para mantener cuando algo falla.

Además, si la empresa usa LLMs en la nube para tareas que involucran datos de clientes o información interna sensible, hay una capa de cumplimiento normativo que no desaparece porque el proceso lo gestione un modelo. Alguien tiene que asegurarse de que esos flujos están bien configurados y que los datos van a donde deben ir.

La confianza empresarial en la IA para tareas críticas se irá ganando de forma gradual, a medida que los modelos demuestren consistencia en entornos controlados. Pero esa confianza no se gana automáticamente, y las empresas que avancen demasiado rápido sin la supervisión adecuada van a pagar el aprendizaje en producción.

La recomendación práctica es clara: invertir en perfiles mid-senior que entiendan tanto las capacidades reales de los LLMs como sus limitaciones, y que puedan actuar como puente entre lo que la tecnología puede hacer y lo que el negocio necesita que funcione de forma fiable.

¿Y si simplemente te deprime perder el código?

Hay una parte de esta conversación que los artículos sobre el futuro del trabajo suelen ignorar porque no encaja bien en el formato optimista.

Para mucha gente, escribir código no era solo un medio para un fin. Era la fuente de una satisfacción muy específica: la precisión, la lógica, el momento en que pequeñas abstracciones se componen en algo que funciona. Eso tiene valor en sí mismo, y es legítimo lamentarlo cuando desaparece como parte central del trabajo.

No todo el mundo quiere ser arquitecto o tech lead. Algunos desarrolladores simplemente quieren programar bien. Y la pregunta de si ese espacio va a seguir existiendo —en nichos, en proyectos concretos, en empresas que valoren la artesanía técnica— es una pregunta abierta y honesta.

Lo que sí parece claro es que la respuesta no está en resistirse a los LLMs ni en adoptarlos sin criterio. Está en entender qué parte de lo que haces tiene valor que la IA no puede replicar todavía, y apostar fuerte por eso.

Para algunos será la arquitectura. Para otros, la seguridad o la infraestructura. Para otros, quizás, buscar contextos donde el código artesanal siga siendo la norma. Pero en cualquier caso, la decisión se toma mejor con información que con miedo.

Si gestionas un equipo técnico o estás pensando cómo integrar estas herramientas en tu empresa, vale la pena preguntarse qué roles internos son realmente estratégicos y cuáles estás a punto de erosionar sin darte cuenta.