Ir al contenido principal

La nueva seniority no es saber usar IA: es convertir procesos en sistemas

El valor de un desarrollador senior ya no está solo en escribir código rápido. Está en entender procesos, diseñar sistemas mantenibles y usar IA y automatización con criterio técnico.

Luis Miguel García Briz7 min de lectura
Compartir
La nueva seniority no es saber usar IA: es convertir procesos en sistemas
Cargando audio...

Durante años, ser buen desarrollador significaba escribir buen código.

Después significó escribir buen código, entender arquitectura, trabajar en equipo, entregar sin romper producción y saber mantener sistemas vivos.

Ahora está pasando otra cosa.

Con IA, copilotos, agentes de desarrollo, automatizaciones y herramientas cada vez más potentes, mucha gente está mirando solo una parte del cambio:

> “Ahora se programa más rápido.”

Pero creo que esa no es la lectura importante.

La lectura importante es otra:

> El valor del desarrollador senior ya no está solo en escribir código.

> Está en convertir problemas ambiguos en sistemas que funcionan.

Y eso cambia bastante la conversación.

La IA no elimina la seniority. La expone.#

Un junior con IA puede generar más código que antes.

Un perfil medio con IA puede resolver tareas que hace unos años le habrían costado mucho más.

Pero cuando el problema deja de ser “hazme este componente” y pasa a ser:

  • este proceso falla cada semana
  • este cliente necesita una integración con su ERP
  • este equipo pierde horas copiando datos entre herramientas
  • esta aplicación legacy hay que mantenerla sin romper negocio
  • esta API tiene que escalar sin convertirse en una caja negra
  • este workflow automático mueve información sensible
  • esta incidencia se repite y nadie ha diseñado una solución de fondo

Ahí la IA por sí sola no basta.

Ahí hace falta criterio.

Y el criterio sigue siendo muy humano.

Programar más rápido no siempre significa entregar mejor#

Una de las trampas actuales es confundir velocidad con avance real.

Puedes generar mucho código muy rápido y aun así empeorar un proyecto.

Puedes automatizar un proceso y crear una bomba de mantenimiento.

Puedes conectar cinco APIs con n8n y que todo parezca magia hasta que algo falla a las tres de la mañana.

Puedes pedirle a un agente que refactorice medio repositorio y terminar con una solución que compila, pero no encaja con la arquitectura real.

La pregunta importante ya no es:

> ¿Puedes hacerlo más rápido?

La pregunta es:

> ¿Puedes hacerlo bien, mantenerlo y explicar por qué esa solución tiene sentido?

Ahí es donde el perfil senior sigue marcando diferencia.

El nuevo perfil valioso está en el cruce#

Cada vez veo más valor en perfiles que no están solo en una caja.

No solo backend.

No solo frontend.

No solo DevOps.

No solo IA.

No solo automatización.

Sino perfiles capaces de cruzar todo eso para resolver problemas reales.

Un perfil capaz de entender una necesidad de negocio, bajarla a requisitos, diseñar una API, revisar un flujo de datos, automatizar una parte repetitiva, conectar herramientas, controlar errores, documentar el proceso y dejar algo mantenible detrás.

Ese cruce es muy potente.

Porque muchas empresas no tienen un problema de “falta de código”.

Tienen un problema de:

  • procesos manuales
  • herramientas desconectadas
  • datos duplicados
  • legacy difícil de tocar
  • dependencia excesiva de personas concretas
  • tareas repetitivas que nadie ha parado a sistematizar
  • falta de trazabilidad
  • integraciones improvisadas
  • automatizaciones sin control
  • deuda técnica invisible

Y ahí un desarrollador con base backend, mentalidad de producto y criterio de automatización puede aportar muchísimo.

Automatizar no es poner un workflow bonito#

Automatizar en serio no es conectar nodos y celebrar que funciona una vez.

Automatizar en serio es preguntarse:

  • qué pasa si una API cae
  • qué pasa si llega un dato incompleto
  • qué pasa si el proceso se ejecuta dos veces
  • qué pasa si alguien cambia el formato de entrada
  • qué logs quedan
  • quién recibe el error
  • cómo se reintenta
  • cómo se audita
  • cómo se revierte
  • qué parte debe ser automática y qué parte necesita revisión humana

Eso es ingeniería.

Aunque lo montes con n8n.

Aunque uses IA.

Aunque el workflow parezca visual y sencillo.

La diferencia entre una automatización amateur y una automatización útil está en las preguntas que haces antes de ponerla en producción.

La IA necesita contexto, límites y revisión#

Con los agentes de desarrollo pasa algo parecido.

La gente habla mucho de prompts.

Pero cada vez me interesa menos el prompt perfecto y más el contexto operativo.

Un agente puede ser muy útil si sabe:

  • cómo está organizado el proyecto
  • qué convenciones se siguen
  • qué zonas son sensibles
  • qué dependencias no debe tocar
  • qué patrones ya existen
  • qué tests tiene que ejecutar
  • qué significa “bien hecho” dentro de ese repositorio

Sin eso, el agente improvisa.

Y cuando un agente improvisa dentro de un proyecto real, puede generar mucho trabajo extra.

Por eso archivos como AGENTS.md, CLAUDE.md o documentación interna orientada a agentes empiezan a tener tanto sentido.

No porque sean moda.

Sino porque convierten conocimiento disperso en instrucciones accionables.

Y eso, otra vez, es trabajo de seniority.

El backend vuelve a ser más importante, no menos#

Durante un tiempo parecía que todo el foco estaba en la capa visible:

interfaces, frameworks frontend, experiencia de usuario, componentes, diseño.

Todo eso sigue importando.

Pero con IA y automatización, el backend vuelve a ponerse en el centro de muchas decisiones.

Porque alguien tiene que diseñar:

  • APIs estables
  • permisos
  • trazabilidad
  • colas
  • jobs
  • integraciones
  • validaciones
  • límites
  • reintentos
  • seguridad
  • datos consistentes
  • observabilidad

La IA puede ayudarte a escribir código.

Pero no debería decidir sola cómo se protege un dato sensible, cómo se modela una entidad crítica o cómo se recupera un proceso fallido.

Eso sigue necesitando cabeza técnica.

El perfil que me parece más interesante#

Si tuviera que resumir el perfil developer que más interesante me parece ahora mismo, diría algo así:

> Alguien que sabe programar, pero no se queda en programar.

> Alguien que entiende procesos, negocio, sistemas, automatización e IA, y sabe unirlo todo con criterio.

No hace falta ser experto en absolutamente todo.

Pero sí hace falta tener una base sólida y curiosidad suficiente para conectar piezas.

Backend.

APIs.

Legacy.

Automatización.

IA aplicada.

DevOps básico.

Documentación.

Testing.

Producto.

Comunicación.

Eso no cabe bien en una etiqueta clásica.

Pero cada vez encaja mejor con los problemas reales de muchas empresas.

Para recruiters y equipos técnicos#

Creo que aquí también hay una oportunidad para quien busca perfiles técnicos.

Quizá no siempre el candidato más interesante es quien lista más frameworks.

Quizá es quien puede explicar:

  • cómo reducir trabajo manual
  • cómo mejorar un proceso interno
  • cómo convertir una integración frágil en algo mantenible
  • cómo usar IA sin perder control
  • cómo convivir con legacy sin odiarlo
  • cómo entregar mejoras pequeñas sin romper sistemas grandes
  • cómo hablar con negocio y bajar la solución a código

Ese tipo de perfil no siempre brilla en una keyword search.

Pero en el día a día puede ahorrar muchísimo tiempo, ruido y coste.

Mi forma de verlo#

Para mí, la dirección está bastante clara.

El desarrollo web no va solo de crear pantallas.

Tampoco va solo de escribir endpoints.

Ni siquiera va solo de usar IA.

Va de construir sistemas que ayuden a trabajar mejor.

A veces eso será una API.

A veces será una automatización.

A veces será un panel interno.

A veces será limpiar un proceso legacy.

A veces será documentar bien un flujo para que un agente de IA pueda trabajar sin romper nada.

A veces será decir que no a una automatización porque todavía no hay suficiente control.

Y esa mezcla, bien hecha, tiene mucho valor.

Conclusión#

La IA va a cambiar muchas cosas.

Pero no creo que el valor del desarrollador senior desaparezca.

Creo que se desplaza.

Menos valor en picar código repetitivo.

Más valor en entender problemas, diseñar sistemas, poner límites, automatizar con cabeza y decidir qué merece la pena construir.

La nueva seniority no va de saber usar todas las herramientas nuevas.

Va de saber cuándo usarlas, cómo integrarlas y cómo evitar que se conviertan en deuda técnica con interfaz bonita.

Dicho fácil:

> El futuro no es el developer que más código genera.

> Es el que mejor convierte procesos reales en sistemas mantenibles.

Avisos sin ruido

Nuevas herramientas, cuando salgan.

Deja tu email y te aviso cuando publique calculadoras, herramientas o aprendizajes técnicos relevantes.

Este aviso llega a [email protected] para gestionarlo manualmente. Sin spam ni listas raras. Puedes darte de baja cuando quieras desde desuscribirte.