La inteligencia artificial ha llegado al desarrollo de software con la misma discreción con la que entra una cuadrilla de albañiles a reformar el piso de arriba: haciendo ruido, levantando polvo y prometiendo que todo estará terminado antes de lo previsto o en jerga técnica especializada “en dos patás”.
Y, para ser justos, código produce. Mucho. Igual que polvo en la obra… ¿Pero eso es señal de productividad?
Desde que tengo memoria, los responsables de negocio se han quejado siempre de lo mismo: que los desarrolladores son caros, que hacen falta demasiados, que su trabajo debería ser algo temporal y que, tarde o temprano, aparecería una máquina capaz de hacer lo mismo por menos dinero y sin pedir aumento de sueldo.
Llevamos treinta años esperando ese momento.
La paradoja es que, a medida que programar parecía hacerse más fácil, construir software se hacía bastante más complicado
Y, mientras tanto, cambios ha habido unos cuantos. Pasamos de los entornos legacy sobre mainframes (COBOL, AS/400… y toda aquella informática de bata blanca) a arquitecturas de cliente ligero, después a la web, al cloud, a los microservicios y a lenguajes cada vez más sencillos de utilizar y más sofisticados por dentro.
La paradoja es que, a medida que programar parecía hacerse más fácil, construir software se hacía bastante más complicado.
Porque cada simplificación traía detrás una nueva capa, una nueva herramienta y, casi siempre, un nuevo especialista. Aparecieron los DBA, QA, los DevOps, los desarrolladores frontend, backend, los product designers y toda una fauna profesional que no existía (o al menos no con esos nombres) cuando todo parecía reducirse a un señor delante de una pantalla verde.
Índice de temas
El nuevo paradigma de la ingeniería de software
Incluso llegamos a inventarnos un término para intentar reunirlos otra vez en una sola persona. Lo llamamos ‘Full Stack Developer’, quizá con la esperanza de que, de tanto repetirlo, terminara convirtiéndose en realidad.
Pero todos sabemos cómo acaba esa historia.
El desarrollador Full Stack, entendido como ese profesional que domina de verdad frontend, backend, infraestructura, seguridad, bases de datos, arquitectura, testing y además conoce el negocio, existe aproximadamente en el mismo sitio que el unicornio.
En este nuevo paradigma de la ingeniería de software, un producto (ya sea una plataforma, una app, un SaaS, una aplicación de escritorio o una humilde API) se parece cada vez más a un milhojas de pastelería fina: muchas capas, bien colocadas, cada una procurando no mezclarse demasiado con la de al lado, porque en cuanto empiezan a pegarse unas con otras aquello deja de ser arquitectura y pasa a ser engrudo.
La gracia está en que esas capas deben depender lo menos posible entre sí, para que mañana podamos cambiar una sin tener que llamar a media plantilla, parar producción y encomendar el despliegue a San Judas Tadeo o a San Isidoro de Sevilla, patrón oficioso de los informáticos con prisa.
Pero claro, el hojaldre solo no se sostiene.
Entre capa y capa hay nata. Mucha nata. Frameworks, librerías, servicios de terceros, APIs ajenas y piezas de software hechas por señores que no conocemos, que probablemente viven a varios husos horarios de distancia y en los que depositamos una fe considerable. Confiamos en ellos como el ciudadano confía en la independencia de la justicia, en la igualdad ante la ley o en que una administración pública vuelva a prestar servicio sin cita previa: con esperanza, cierta ingenuidad y un poco de orujo.
Esperamos que esos terceros hagan lo que prometen. Que corrijan los bugs. Que mantengan la compatibilidad. Que no abandonen el proyecto. Que una actualización no rompa de repente algo que llevaba cinco años funcionando sin que nadie supiera exactamente por qué.
Y confiamos en que cada versión sea mejor, compatible y gratis. ¡Que ya es confiar! Porque esa nata tecnológica viene con toda su grasa: dependencias, vulnerabilidades y deuda técnica. Y, si se deja demasiado tiempo fuera de la nevera, acaba criando bichos.
La medición de la productividad
Bien, ahora que ya tenemos una idea razonable de la complejidad de cualquier desarrollo, conviene preguntarse cómo se ha medido tradicionalmente la productividad. Métodos hay muchos, pero aquí no venimos a hacer academia, sino a hablar de lo que pasa de verdad.
En demasiadas empresas la medición acaba en manos de alguien no técnico, armado con una metodología de extraordinaria sofisticación que mezcla psicología, ilusionismo y una fe admirable en su propio criterio: el célebre método “¿Cómo va?”. Una disciplina que bien podría impartirse en alguna Cátedra Extraordinaria de Transformación Social Competitiva de la Complutense y que solo conoce un competidor serio en rigor científico: imprimir el código, ponerlo en una báscula y comprobar quién ha programado más kilos.
Esto no lo digo yo. McKinsey advierte expresamente de que métricas simples como líneas de código o commits pueden inducir comportamientos contraproducentes y ser manipuladas fácilmente.
En contadas ocasiones encontramos profesionales capaces de medir de verdad la productividad de un desarrollador. No basta con mirar cuántas tareas cierra o cuántos commits hace: hay que analizar su velocidad de entrega y su lead time frente a retos comparables, la cobertura y corrección de su código, las decisiones de diseño y arquitectura, las librerías y frameworks que introduce, las revisiones que exige (gastando el tiempo y la paciencia de otros), las marchas atrás, los controles de calidad, las reuniones, la documentación (obsoleta totalmente) y todo el esfuerzo necesario hasta que esa pieza queda correctamente integrada en el producto.
Y ahí no termina la historia. Un código puede ser correcto, tener un 99 % de cobertura y, aun así, provocar efectos colaterales al convivir con el resto del sistema. Esos efectos suelen presentarse con un nombre bastante molón: bugs.
Por eso hay que relacionar cada incidencia con el cambio que la originó y medir también el retrabajo que genera. El retrabajo es uno de los efectos más caros de la deuda técnica: si no se ataja pronto, crece, se propaga y cada mes cuesta más corregirlo. McKinsey lo resume bien: si esos bugs se atajan pronto, corregirlos suele costar alrededor del 20% de lo que costó provocarlos. Y como dice SquadMakers, si se deja macerar esa deuda técnica, el coste se multiplica con cada release que se despliega arrastrando esa herencia.
El retrabajo es uno de los efectos más caros de la deuda técnica: si no se ataja pronto, crece, se propaga y cada mes cuesta más corregirlo
Por tanto, la productividad no debería medirse por cuánto código produce un desarrollador, sino por el valor que entrega al proyecto y por todo el esfuerzo (propio y ajeno) que ha sido necesario para conseguirlo… y para evitar análisis subjetivos, debería estar basado en KPI comunes al resto del equipo donde se
evalúe la actividad particular de cada miembro y su aportación global al proyecto.
La productividad no debería medirse por cuánto código produce un desarrollador, sino por el valor que entrega al proyecto y por todo el esfuerzo (propio y ajeno) que ha sido necesario para conseguirlo
La IA, ¿la nueva panacea?
¿Y la IA? Sí, claro. A estas alturas ya la usa todo el mundo y se vende como la nueva panacea. Inversores y grandes empresas brindan ante la perspectiva de reducir la contratación de esos villanos, piratas y mercenarios que durante décadas hemos llamado desarrolladores; mientras, alguna gran consultora ya anticipa recortes superiores al 25% de sus plantillas, subida con entusiasmo a la nueva ola de la IA generativa, camino de la prometida ‘superinteligencia’.
Pero aparece un pequeño detalle, de esos que suelen estropear las presentaciones de PowerPoint: según Accenture, el 41% de los responsables tecnológicos identifica ya la IA como uno de los principales generadores de nueva deuda técnica. Conviene detenerse un momento en la cifra. Si antes hemos visto lo que cuesta arrastrar deuda técnica durante varias releases, imaginemos ahora cuánto dinero podemos quemar fabricándola a velocidad industrial.
El 41% de los responsables tecnológicos identifica ya la IA como uno de los principales generadores de nueva deuda técnica
Para medir la productividad de la IA aplicada al desarrollo de software hay que empezar, por tanto, por algo bastante menos glamuroso: identificar para qué la estamos utilizando. La IA funciona estupendamente en muchas tareas acotadas, pero su fiabilidad cae cuando el trabajo exige mantener durante horas contexto, decisiones y razonamientos encadenados.
En tareas que a un humano competente pueden llevarle entre dos y cuatro horas empiezan a aparecer las famosas ‘alucinaciones’; siempre suponiendo, además, que al otro lado haya alguien que sepa explicar correctamente lo que necesita mediante instrucciones y prompts razonables.
¿Ahorra tiempo la IA? Como respondería un gallego: depende.
Al principio, sin duda. Te quita trabajo repetitivo, genera código, propone soluciones y permite avanzar a una velocidad que hace unos años habría parecido ciencia ficción. Pero cuando aumenta la complejidad también crece la probabilidad de que empiece a inventar, interpretar mal el contexto o tomar decisiones que nadie le pidió.
Y entonces llega la segunda parte del espectáculo: revisar y corregir lo producido. Si uno es sensato, claro. Porque pocas tareas hay más ingratas que arreglar el código de otro; salvo, quizá, arreglar el código de otro que además no existe y está convencido de que lo ha hecho estupendamente.
Por eso, si antes medíamos las métricas de un desarrollador que trabajaba más o menos ‘solo’, ahora debemos asumir que ese desarrollador trabaja acompañado. Hace vibe coding, conversa con la IA, acepta unas propuestas, rechaza otras y delega parte de su trabajo. Ya no basta con mirar el código final: para entender su productividad tendremos que saber también qué pidió a la IA, qué prompts utilizó, qué aceptó sin tocar, qué corrigió y qué revisiones realizó antes de entregar.
Porque si queremos medir la productividad del desarrollador, tendremos que empezar a medir también la de su nuevo compañero de mesa.
El viejo modelo ‘al peso’
En esta nueva era, las métricas para evaluar la productividad tienen que ser mucho más finas que las que hemos utilizado hasta ahora. Ya no basta con confiar en la profesionalidad del desarrollador, porque puede ocurrir que su principal actividad consista en consumir tokens mientras la IA produce el código. Y, visto desde fuera, todo puede parecer impecable: commits diarios, buena cobertura, clean code, documentación correcta y una productividad de concurso.
El problema es lo que esas métricas no enseñan.
Porque debajo de esa superficie pueden esconderse precisamente las cosas que un buen code review humano sí detecta: una arquitectura mal planteada, decisiones técnicas tomadas por inercia, librerías o frameworks que ni siquiera se investigaron y que habrían permitido desarrollar mejor o escalar con menos esfuerzo, funcionalidades que nadie pidió y aparecen de regalo, o capas y capas de código innecesario generadas bajo una premisa muy propia de ciertos modelos: si más código parece más trabajo, entonces más código debe ser mejor.
Es el viejo modelo ‘al peso’, solo que ahora la báscula funciona a base de tokens.
Lamentablemente para quienes añoran aquellos tiempos en los que levantar una aplicación hacía aparecer, junto a la taza molona, un pequeño halo de hacker, aquello no va a volver.
El problema de los perfiles
El problema ahora es otro: los perfiles junior lo tienen cada vez más difícil para encontrar oportunidades, porque enseñarles exige tiempo, paciencia y seniority, tres bienes que nunca han abundado demasiado, y resulta difícil justificar ese esfuerzo si después su aportación no mejora lo que una IA es capaz de producir en unos minutos. Y en esto las universidades llegan tarde. Muy tarde.
Los senior, en cambio, salen reforzados. Traen algo que todavía no se compra por tokens: años de experiencia, librerías investigadas, frameworks probados y descartados, arquitecturas que funcionaron y otras que dejaron cicatrices, y una respetable colección de bugs que les robaron noches de sueño y les enseñaron aquello que ningún curso incluye en el temario.
La IA puede haber leído millones de repositorios; el senior recuerda perfectamente aquella madrugada en la que una dependencia aparentemente inocente tumbó producción. Y eso curte.
Pero también cambia el trabajo de quien dirige a esos desarrolladores. El responsable de un proyecto ya no puede seguir gobernando aquello mediante el ancestral “¿cómo vamos?”, una reunión los lunes y cierta habilidad para interpretar las caras del personal.
Necesita algo parecido al navegador de un coche moderno: un sistema inteligente conectado con repositorios, herramientas de gestión, desarrollo y despliegue que le diga dónde está, a qué velocidad avanza, dónde empieza a aparecer deuda técnica y en qué curva existe una probabilidad razonable de acabar en la cuneta.
Porque los problemas ya no son tan evidentes. Un código puede compilar, superar los tests, tener una cobertura magnífica y esconder detrás decisiones de arquitectura discutibles, deuda técnica o trabajo futuro suficiente para entretener al equipo durante varios sprints. Y si el responsable no es técnico, distinguirlo mirando Jira resulta aproximadamente tan fiable como diagnosticar el motor del coche observando el cuentakilómetros.
La Inteligencia de Ingeniería de Software
Para eso empiezan a aparecer las plataformas de Inteligencia de Ingeniería de Software: sistemas capaces de reunir la información dispersa entre repositorios, Merge Requests, incidencias, herramientas de producto y despliegues, analizarla y convertirla en una visión objetiva de lo que realmente ocurre.
Y aquí está probablemente el verdadero cambio.
La IA, bien utilizada, es una palanca extraordinaria. Puede permitir que un desarrollador bueno produzca más y mejor, elimine trabajo rutinario y dedique su tiempo a aquello donde todavía aporta verdadero valor: decidir, diseñar, revisar y resolver problemas. Pero una palanca sirve para multiplicar una fuerza; si se coloca mal, también multiplica el golpe.
Por eso la IA no cambia solamente el trabajo del desarrollador. Cambia también el de su responsable.
Pretender dirigir hoy un equipo remoto, diverso y de más de tres personas con las mismas técnicas con las que se hacía hace diez años es propio de un ludópata. Entre desarrolladores, agentes de IA, repositorios, incidencias, revisiones, despliegues y varias herramientas funcionando a la vez, resulta difícil sostener seriamente que una persona puede controlar lo que ocurre simplemente preguntando y mirando unos cuantos dashboards.
El responsable necesitará exactamente lo mismo que sus desarrolladores: una IA que le quite de encima el trabajo mecánico de analizar miles de datos y le permita dedicar su tiempo a entender qué está pasando y tomar decisiones
El responsable también tiene que evolucionar.
Y, paradójicamente, necesitará exactamente lo mismo que sus desarrolladores: una IA que le quite de encima el trabajo mecánico de analizar miles de datos y le permita dedicar su tiempo a lo que ninguna máquina debería decidir por él: entender qué está pasando y tomar decisiones.
