El otro día me encontré con cuatro terminales abiertas, cada una con un agente trabajando en una parte distinta del sistema: uno refactorizando el módulo de autenticación, otro generando tests de integración para un servicio nuevo, un tercero explorando una migración de base de datos y el cuarto escribiendo el plan de un cambio en la capa de eventos. Cuatro líneas de trabajo en paralelo, todas avanzando, todas requiriendo mi atención intermitente para validar decisiones, corregir el rumbo, aprobar o rechazar. Y me descubrí pensando algo incómodo: esto no se parece en nada a lo que hacía hace dos años, y sin embargo es lo más productivo que he sido nunca.

La pregunta que me ronda desde entonces es si estamos ante el nacimiento de una métrica nueva, una que todavía no tiene nombre formal pero que yo llamo, a falta de algo mejor, Parallelization Index – el número de flujos de trabajo concurrentes que un ingeniero es capaz de orquestar de manera efectiva sin que la calidad se degrade.

La métrica silenciosa

Históricamente hemos medido a los ingenieros con proxies más o menos cuestionables: líneas de código, número de PRs, story points completados, tiempo medio de resolución de incidencias, y todos sabemos que estas métricas capturan actividad pero no necesariamente impacto, que son fáciles de gamificar y difíciles de interpretar, y que a menudo miden la velocidad del tipeo más que la calidad del pensamiento.

El Parallelization Index mide algo distinto: la capacidad de mantener contexto suficiente sobre múltiples flujos de trabajo simultáneos como para tomar buenas decisiones en cada uno de ellos. No es multitasking en el sentido clásico –no estás alternando entre tareas de forma frenética–, sino algo más parecido a dirigir una orquesta: cada sección toca su parte, pero alguien tiene que entender la partitura completa para que el resultado sea coherente.

Un ingeniero con un PI de 1 trabaja de forma secuencial: una tarea, un agente, un flujo. Es perfectamente válido y a veces es lo correcto –hay cambios que requieren atención total e indivisa–. Un ingeniero con un PI de 4 o 5 está conduciendo varios agentes en paralelo, revisando planes, validando outputs, tomando decisiones arquitecturales en contextos distintos, y manteniéndolo todo en la cabeza sin mezclar ni perder el hilo.

Lo que realmente mide

Si lo piensas, el PI es un proxy bastante decente de varias habilidades que siempre hemos valorado pero que nunca supimos cuantificar:

• Comprensión arquitectural: no puedes paralelizar lo que no entiendes. Si no tienes un modelo mental claro del sistema, cada agente adicional es una fuente de caos, no de productividad.
• Capacidad de descomposición: paralelizar requiere identificar líneas de trabajo independientes, lo que a su vez requiere entender las dependencias del sistema y saber cortar por las costuras correctas.
• Juicio técnico bajo presión: cuando cuatro agentes te piden decisiones en ventanas de tiempo solapadas, no puedes permitirte deliberar veinte minutos sobre cada una. Necesitas criterio rápido y fiable, el tipo de criterio que solo da la experiencia.
• Gestión de contexto: el recurso más escaso no es el tiempo de cómputo del agente sino el ancho de banda cognitivo del humano. Un PI alto implica una capacidad inusual para cargar y descargar contextos mentales sin perder información crítica.

En cierto sentido, el PI mide la capacidad de pensar en paralelo, que es probablemente lo más cercano a una definición operativa de eficiencia que he encontrado.

Las implicaciones incómodas

Si el Parallelization Index se convirtiera en una métrica real –y no digo que deba, solo que podría–, las implicaciones serían considerables.

La primera es que redefiniría lo que entendemos por productividad individual. Un ingeniero senior con un PI alto podría, en teoría, producir el output equivalente a un equipo pequeño. No porque trabaje más horas, sino porque su comprensión del sistema le permite orquestar más trabajo en paralelo. Esto es atractivo para las empresas y potencialmente peligroso para el mercado laboral, y no voy a fingir que no lo veo.

La segunda es que cambiaría la naturaleza de las entrevistas técnicas. Si lo que importa es la capacidad de orquestar agentes sobre un sistema complejo, evaluar eso se parece más a un ejercicio de dirección de proyecto en tiempo real que a invertir un árbol binario en una pizarra. Imagino entrevistas donde el candidato recibe un sistema con varios problemas y se le mide no cuántos resuelve secuencialmente sino cuántos es capaz de avanzar en paralelo sin comprometer la calidad.

La tercera, y la que más me inquieta, es que el PI tiene un techo cognitivo que probablemente no es entrenable más allá de cierto punto. La memoria de trabajo humana tiene límites bien documentados –el famoso 7±2 de Miller, o los 4 chunks de Cowan si somos rigurosos–, y si la capacidad de paralelización está fundamentalmente acotada por la memoria de trabajo, entonces el PI podría convertirse en una métrica que mide talento innato más que esfuerzo o experiencia, lo cual sería profundamente injusto como criterio de evaluación profesional.

Los riesgos de medir lo que se mueve

Toda métrica que se convierte en objetivo deja de ser una buena métrica –la ley de Goodhart es implacable–, y el PI no sería inmune. Puedo imaginar perfectamente a alguien abriendo seis agentes simultáneos no porque tenga la capacidad de gestionarlos sino porque quiere subir su número, produciendo seis flujos de trabajo mediocres en lugar de tres excelentes. La tentación del throughput sobre la calidad es vieja y resistente a los cambios de herramienta.

También existe el riesgo de que optimizar por PI erosione el trabajo profundo. Hay problemas –diseño de APIs públicas, decisiones de modelado de datos, depuración de race conditions– que requieren inmersión total, un PI de 1 sostenido durante horas, y si la cultura del equipo premia la paralelización, esos problemas podrían recibir menos atención de la que merecen porque nadie quiere ser el que tiene un PI bajo esa semana.

Una intuición, no una propuesta

De forma implícita, ya lo estamos midiendo. Cuando un tech lead observa que cierto ingeniero “mueve mucho” o “desbloquea al equipo” o “siempre tiene tres cosas avanzando”, está describiendo un PI alto sin darle nombre. Y cuando otro ingeniero se atasca intentando hacer dos cosas a la vez, está describiendo un PI bajo. El fenómeno existe, solo le falta la etiqueta.

El valor de un ingeniero se está desplazando de la capacidad de escribir código a la capacidad de orquestar su escritura. Alguna forma de medir esa orquestación terminará emergiendo, con este nombre o con otro. Lo único que espero es que cuando alguien lo convierta en un dashboard con semáforos de colores, al menos se acuerde de que un PI de 1 sostenido en el problema correcto vale más que un PI de 6 repartido en trivialidades.