Nate: cuando el 10x individual con agentes no se traduce en más productividad de equipo

Por Nate's Substack · 27 de septiembre de 2026.

Nate arranca este briefing ejecutivo describiendo una situación que, según él, se está volviendo habitual dentro de los equipos: alguien descubre una forma de usar agentes de IA muy distinta a la del resto. Esa persona mantiene varias piezas de trabajo en marcha a la vez, vuelve de comer y se encuentra listo para revisar un problema que antes le habría llevado toda la tarde, y gasta dinero en tokens sin necesidad de justificarlo porque puede mostrar el resultado obtenido. Y aun así, dice Nate, el equipo en su conjunto sigue atrasado.

El argumento central es que esa combinación —una persona disparando su capacidad individual mientras la organización que la rodea no cambia al mismo ritmo— se va a volver cada vez más común. El código llega más rápido de lo que nadie puede revisarlo, un prototipo está listo antes de que quienes deben decidir qué debe hacer se hayan puesto de acuerdo, y la persona que podría zanjar una duda está metida en otras tres reuniones. Todo el mundo tiene mejores herramientas, pero el trabajo terminado sigue esperando en la cola.

Nate señala que la respuesta instintiva de gestión suele ser convertir a la persona rápida en profesora del resto: que documente su configuración, dé un taller, estandarice los prompts para que todos lleguen a su nivel. Reconoce que parte de eso puede ser útil, pero advierte de que también puede consumir precisamente la capacidad que se acababa de descubrir: se ha encontrado a alguien capaz de hacer un trabajo inusualmente bueno e inusualmente rápido, y el primer movimiento de la organización es darle otro trabajo más (enseñar a los demás).

Frente a eso, plantea una pregunta que considera mejor: cómo aumentar la productividad del equipo sin frenar a quienes ya se están moviendo rápido. Eso implica, según él, tomarse en serio las ganancias individuales y ser muy estricto sobre qué cuenta realmente como ganancia de equipo. Pone el ejemplo de que una persona produciendo diez veces más trabajo para que otras cinco lo revisen es, en realidad, un problema de capacidad de revisión, no un logro: frenar a esa persona hasta que la cola vuelva a sentirse familiar solo esconde el problema, no lo resuelve.

Como evidencia de que el fenómeno es real, el correo cita dos referencias concretas. Por un lado, Lauren Tan reportó cerca de mil pull requests fusionados en julio, dijo que iba camino de duplicar esa cifra, y finalmente reportó 2.462 en agosto. Por otro, el informe de hábitos de desarrolladores de Cursor de la primavera de 2026 encontró que el usuario del percentil 99 fusionó aproximadamente quince veces más pull requests que el autor mediano entre los que fusionan pull requests de forma activa. Nate matiza este último dato con cuidado: es una diferencia observada dentro de los usuarios de un producto, medida a través de un único tipo de output (pull requests fusionados); no implica que esas personas generasen quince veces más valor para el cliente, ni que la IA sea la causa de toda la diferencia. Lo que sí indica, dice, es que existe un rango de comportamiento muy amplio que merece ser investigado.

A partir de ahí, Nate propone seis principios para que un líder decida qué hacer con ese rango de comportamiento: hacer que el trabajo de los agentes sea utilizable por más de una persona; separar el trabajo que necesita perdurar del entorno que lo ejecuta; mantener a los humanos como responsables últimos; dejar el trabajo en un estado en el que otra persona pueda continuarlo; dar a los agentes una forma de comprobar la realidad; y eliminar procesos cuyo propósito original ya ha cambiado. Advierte de que la parte difícil no son los principios en sí, sino decidir cuánto de cada uno necesita el equipo concreto: aplicados sin cuidado, los seis pueden degenerar en burocracia innecesaria.

El correo enumera los temas que trata el briefing completo (accesible en el enlace al post): a dónde va realmente el tiempo ahorrado, con el ejemplo de que una ganancia de diez veces en la implementación puede acabar traduciéndose en solo 1,8 veces de ganancia para el negocio, según en qué parte del proceso esté el verdadero cuello de botella; qué estándares merece la pena imponer, distinguiendo entre exigir un test reproducible y exigir que todos usen los mismos prompts, señalando que esta segunda exigencia empeora a los mejores empleados; cómo evitar que el desarrollador más rápido acabe convertido en un servicio de soporte interno, sustituyendo talleres por comprobaciones reutilizables y pensando quién paga el mantenimiento de esas comprobaciones; y cómo evaluar si un despliegue de estas prácticas ha funcionado, mediante cinco medidas a seguir durante una prueba de dos semanas, entre ellas una pensada específicamente para detectar cuando la ganancia de productividad del equipo en realidad procede solo de su contribuidor más fuerte.

Como material adicional, Nate menciona el 'Faster Factory Kit', una guía que convierte los seis principios en acuerdos editables, incluye un ejemplo trabajado de exportación de facturas, un verificador de comprobaciones (check runner) funcional y una plantilla de puntuación para ejecutar la prueba la semana siguiente. Aclara que el vídeo del briefing cubre los seis principios, mientras que el texto del post desarrolla las contrapartidas de cada uno y cómo saber cuál necesita primero cada equipo.

El correo cierra con una nota promocional dirigida a los miembros del plan 'Executive Circle', indicando que además de estos briefings dominicales reciben acceso al servidor MCP de la biblioteca de Nate ('Nate's Library MCP server'), con un enlace para cambiar de plan.