Con personas, mueve la autoridad a la información. Con agentes, al revés

En Turn the Ship Around!, David Marquet acaba de llegar como capitán al USS Santa Fe, el peor submarino de su flota. En una de sus primeras guardias da una orden de velocidad que ese submarino no puede cumplir. Físicamente no puede.

¿Y qué pasa? Nada. El oficial la repite, la cadena de mando la pasa, y todo el mundo intenta hacer algo imposible porque lo ha dicho el capitán.

Me leí el libro hace unas semanas, ahora que estoy liderando personas más de cerca que nunca. Y cuando llegué a esa escena pensé: esto me pasa. Pero no con mi equipo. Me pasa con los agentes.

Hace poco le pedí a uno que simplificara un servicio que calcula ventanas de entrega. Y lo simplificó, vaya si lo simplificó. Se cargó una rama que parecía código muerto y que en realidad cubría los festivos locales. Los tests en verde, claro, porque nadie había escrito nunca un test para ese caso.

El agente no me dijo "oye, ¿seguro?". Hizo exactamente lo que le pedí. Como la tripulación del Santa Fe.

De dónde sale esto

Llevo años como Staff Engineer apoyando equipos, pero últimamente estoy liderando personas de forma mucho más directa. Y a la vez, como casi todos, cada vez le paso más trabajo a agentes.

Estoy aprendiendo a delegar en dos sitios a la vez, y no paro de ver paralelismos.

Tampoco soy el primero. Addy Osmani escribió que tus agentes de código necesitan un manager. Viene a decir que cuando trabajas con agentes a escala, el problema deja de ser escribir buenos prompts y pasa a ser gestionar, y que lo que hace bueno a un tech lead te sirve casi tal cual.

Estoy de acuerdo con casi todo lo que dice. Pero cuando lo terminé me faltaba algo. Te dice qué hacer, pero no tanto por qué funciona, ni cuándo deja de funcionar.

Y para eso me ha servido Marquet, que acabó llevando el Santa Fe a ser uno de los submarinos mejor valorados de la flota, y el libro cuenta cómo lo hizo. Su idea central es pasar de un modelo en el que el capitán piensa y la tripulación obedece a otro en el que todo el mundo piensa y decide en su ámbito. Para eso se apoya en tres pilares: control (repartir las decisiones), competencia (que la gente sepa decidir bien) y claridad (que todo el mundo entienda el objetivo y los criterios). Y su tesis es que solo puedes repartir control si los otros dos están en su sitio. Esa tesis es la que a mí me sirve para saber cuándo puedo soltar el control con un agente sin que se me caiga todo.

La escalera (que seguramente ya usas)

La herramienta más práctica del libro es la escalera del liderazgo. Parte de una observación sencilla: la forma en que alguien te habla dice cuánta autonomía tiene.

En el escalón más bajo, la persona pide instrucciones: "dime qué hago". Un poco más arriba, te cuenta lo que ve y deja que decidas tú. Luego da su opinión ("creo que deberíamos…") y después propone algo concreto ("me gustaría hacer…"). A mitad de escalera está el "tengo intención de…": la persona ya ha decidido y solo te avisa por si tienes algo que objetar. Por encima, te informa de lo que ya ha hecho. Y en lo más alto ni siquiera hace falta que informe, porque lleva tiempo haciéndolo y todo el mundo lo sabe.

Lo que Marquet le pide al líder es que ayude a cada persona a subir. Si alguien te pregunta "¿qué hago?", en lugar de darle la respuesta le preguntas "¿tú qué harías?". Si te dice "creo que…", le pides que lo convierta en una propuesta. Cada vez que respondes con una orden, la persona se queda en el escalón en el que estaba.

En el libro la escalera tiene algún paso más. Aquí la he simplificado un poco.

Si la pones al lado de cómo trabajas con agentes, es casi calcada. Le he añadido una columna con lo que yo pido antes de subir a un agente de escalón:

El escalón clave es el "tengo intención de". En el Santa Fe, pasar del "¿puedo hacer esto?" al "tengo intención de hacer esto" hacía que pensara quien ejecutaba. El capitán solo tenía que decir "vale".

Con un agente es igual. Antes de que toque nada le pido un plan, para comprobar que ha entendido el problema y no lo resuelva mal a toda velocidad.

Y la escalera no es fija. A un agente no le das el último escalón porque sí, igual que no se lo darías a alguien que llegó al equipo la semana pasada. Lo vas subiendo cuando ves que puede. Que es justo de lo que van los pilares.

Claridad: el qué y el para qué, no el cómo

Empiezo por este porque es el que más claro veo, aunque en el libro va el último.

Marquet insiste mucho en dar objetivos y no métodos. Si le dices a alguien cómo hacer algo, le quitas la iniciativa y te pierdes soluciones mejores que la tuya.

Con agentes se nota un montón. "Añade un índice a esta tabla" es una instrucción. "Esta consulta tarda cuatro segundos en hora punta y la gente abandona, necesito que baje de 200 milisegundos" es un objetivo. Con lo primero, te añade el índice. Con lo segundo, a veces descubre que el problema era una N+1 y que el índice no pintaba nada.

La otra cosa que hacen en el Santa Fe es usar principios para decidir. Principios que la tripulación usaba de verdad cuando nadie le había dicho qué hacer.

Cuando leí esto pensé en el Modelo de Mercadona. Lo que más me llamó la atención al entrar no fue ningún proceso, sino que cualquiera, en tienda, en logística o en tecnología, entiende para qué hace lo que hace y usa eso para decidir cuando nadie le ha dicho qué hacer. Es justo lo que Marquet buscaba en el Santa Fe.

Para un agente, eso es el fichero de instrucciones del proyecto. Las convenciones, las decisiones de arquitectura, lo que aquí no se hace nunca. Si eso solo está en la cabeza de tres personas, el agente va a decidir como si no existiera. Igual que alguien nuevo, por cierto.

A mí me pasó con una regla que todo el equipo conocía y nadie había escrito: los cambios de esquema en tablas grandes se hacen en varios pasos, nunca en una sola migración. Entre personas funcionaba de boca en boca y con alguna review atenta. Hasta que un agente me generó una migración de golpe y no me quedó otra que escribirla. Y la siguiente persona que entró al equipo ya se la encontró documentada.

Competencia: con agentes, el que aprende es el repo

Para Marquet, dar control a alguien que no sabe hacer el trabajo es una temeridad. Por eso cambió las reuniones en las que él explicaba por otras en las que los responsables tenían que demostrar que estaban preparados. Menos informar y más certificar.

Con agentes eso ya lo tenemos: tests, tipos, linters, CI. Un agente con una buena batería de tests puede subir escalones tranquilamente, porque si se equivoca, se entera. Uno en un código sin tests está en el primer escalón, por mucho que nos queramos engañar.

Pasa lo mismo con la "acción deliberada", eso de parar y decir en voz alta lo que vas a hacer antes de tocar algo delicado. Es lo que le pides a un agente cuando le obligas a explicar el plan antes de un cambio gordo.

Pero hay una diferencia que me costó ver. Las personas aprenden. Cada error las deja un poco mejor y la próxima vez suben solas. Un agente no se acuerda de nada entre sesiones a no ser que alguien lo deje escrito.

Así que con personas inviertes en la persona. Con agentes inviertes en lo que tienen alrededor: el test que ahora pilla el fallo de la otra vez, la regla nueva en las instrucciones, la skill que explica cómo se hace algo. La competencia acaba viviendo en el repo.

Y te soy sincero, no sé si esto es algo temporal o va a ser siempre así. Con lo rápido que está mejorando la memoria de los agentes, igual en un año este párrafo no tiene sentido. Por ahora, es lo que hay.

Control: aquí es donde se da la vuelta

La idea más famosa del libro es que no hay que subir la información hasta quien manda, sino bajar el poder de decidir hasta quien tiene la información.

En un submarino tiene todo el sentido. El que está en la sala de máquinas sabe mucho más de esa sala que el capitán. Hacer que suba la información para que decida el capitán es más lento y sale peor. Que decida él.

En un equipo pasa lo mismo. La gente que toca el código y habla con negocio todos los días suele saber más que yo para decidir. Mi trabajo es que tengan claro a dónde vamos, y a partir de ahí que decidan ellos.

Con un agente es justo al revés. Llega sin saber nada. No sabe por qué ese módulo está así, ni el incidente que tuvimos hace dos años, ni qué le importa a negocio este trimestre. Eso lo sé yo.

Así que con agentes toca hacer el movimiento contrario. Mueves la información hacia donde has puesto la autoridad.

Esto tiene nombre, ahora lo llamamos ingeniería de contexto. No estoy descubriendo nada nuevo. Pero creo que Marquet explica muy bien por qué importa. Y también por qué tanta gente se frustra con los agentes: les dan autonomía y no les dan contexto. Es como el capitán que delega en alguien que acaba de subir al barco y luego se sorprende de que decida mal.

Y alguien dirá: "ya, pero a una persona nueva también tienes que darle contexto". Claro. La diferencia es que la persona lo va pillando sola: va a reuniones, se come incidentes, habla con negocio. El agente solo sabe lo que alguien le ha dejado escrito donde pueda leerlo, ya sea en las instrucciones, en una memoria o en los tests.

Así que lo que quieres es montarlo para que el agente lo vaya acumulando y, con eso, vaya subiendo escalones. Que en el fondo es volver a Marquet por otro camino: cuando la información está donde trabaja el agente, ya puedes darle la autoridad a él.

Lo que no encaja (y lo que me han enseñado los agentes)

Tengo que decir que media parte del libro no aplica.

Marquet habla mucho de confianza, de cuidar a la gente, de su carrera, del orgullo de pertenecer a algo, de reconocer el trabajo en el momento. Nada de eso tiene sentido con un agente. Y no quiero que esto se lea como "trata a tu equipo como si fueran agentes".

Lo que sí me ha pasado es que los agentes me hacen de espejo.

Si no sé explicar lo que quiero sin decir cómo hacerlo, un agente me lo deja claro en diez minutos. Con un equipo ese mismo problema tarda meses en salir, y para entonces ya le has echado la culpa a que "no entienden el negocio".

Si no puedo evitar revisar cada línea que escribe un agente, seguramente también estoy revisando de más lo que hace mi equipo. Y si me cuesta subir a un agente de escalón aunque los tests estén en verde, igual el problema de confianza lo tengo yo.

A mí me pasó con las reviews. Me pillé leyendo línea a línea cada diff de un agente que llevaba semanas sin fallar en un tipo de tarea muy concreto. Cuando me pregunté por qué, la respuesta no me gustó nada: no me fiaba de lo que no había hecho yo. Y luego vi lo mismo en cómo revisaba las PRs de mi equipo.

Y funciona al revés también. Cuando un agente la lía y en vez de pensar "qué malo es este modelo" pienso "¿qué contexto le faltaba?", estoy practicando justo lo que debería preguntarme cuando alguien de mi equipo toma una mala decisión.

El capitán que ya no está

Marquet dice que a un líder se le mide cuando se va. El Santa Fe siguió funcionando de maravilla años después de que él se fuera, y muchos de sus oficiales acabaron mandando sus propios barcos.

Con los agentes creo que hay algo parecido. Lo que dice si lo estás haciendo bien es si lo que has montado alrededor (los tests, los principios escritos, el contexto) les deja trabajar bien sin que estés tú mirando.

No tengo ni idea de cómo va a evolucionar esto. Igual en un par de años los agentes aprenden solos y la mitad de lo que he escrito aquí sobra. De verdad, no lo sé.

Lo que sí sé es que estoy aprendiendo a delegar en dos sitios a la vez, y que cada uno me está ayudando con el otro.

Pregunta para ti: ¿te has pillado haciendo con agentes algo que luego has reconocido en cómo lideras a tu equipo?