En equipo
Todo lo anterior está escrito para una persona sola. Cuando son ocho, cambia el problema: no alcanza con que vos cubras las seis disciplinas si el resto no las cubre, porque el código que ellos mergean también es tuyo.
La unidad de adopción es el repositorio, no la persona.
Tres capas, y una regla para cada una
Antes de elegir herramientas hay que decidir dónde vive cada cosa. La mayoría de los problemas de adopción son de ubicación, no de producto: algo que tenía que estar en el repo terminó en la máquina de alguien. Las herramientas que aparecen en cada capa están clasificadas por dónde vive por defecto su configuración y su estado, no por dónde corre el software: un protocolo corre en tu máquina y su configuración igual va en el repositorio.
- 01Personal
Tu máquina
Tus atajos, tus preferencias de estilo, el historial de tus sesiones, el arnés que te gusta usar.
- La regla
- Si otra persona lo necesita para trabajar, no puede vivir acá.
- Cómo se pudre
- Se convierte en conocimiento tribal. “A mí me anda” deja de ser una frase y pasa a ser la arquitectura del equipo.
Se configura máquina por máquina. Nadie más lo hereda.
- 02Repositorio
El repositorio
El archivo de instrucciones, las skills, los hooks, los tipos, los tests, los specs. Todo lo que se versiona junto al código.
- La regla
- Si querés que aplique a todos sin avisarle a nadie, va acá. Se hereda al clonar.
- Cómo se pudre
- Configuración que nadie mantiene y que la gente termina desactivando en silencio porque estorba más de lo que ayuda.
Su configuración viaja con el código. Quien clona, la hereda.
- 03Equipo
El equipo
Decisiones de arquitectura con su porqué, convenciones acordadas, memoria compartida, presupuestos de gasto.
- La regla
- Solo lo que va a seguir siendo cierto dentro de seis meses, y solo si alguien se hace cargo de retirarlo cuando deje de serlo.
- Cómo se pudre
- Ruido. Cien observaciones guardadas de las que ninguna se puede contradecir, y dos que se contradicen entre sí sin que nadie lo note.
Qué escala y qué no
Lo que sigue no es una opinión sobre productos. Es un criterio: escala lo que se hereda sin que nadie tenga que avisar, y falla lo que depende de que cada persona se acuerde.
Escala
Hooks y controles deterministas
Corren igual en la máquina de todos y en CI. No dependen de que nadie se acuerde, y no se pueden convencer.
Skills versionadas en el repo
Un procedimiento escrito una vez que todos los agentes del equipo cargan igual. Se revisa en el PR como cualquier otro archivo.
Specs como artefacto del cambio
Le da a la revisión algo contra qué comparar que no sea la opinión del revisor sobre lo que probablemente se quería.
Un preset de configuración instalable
Que alguien nuevo llegue al mismo entorno con un comando. Si el setup lleva media jornada, la mitad del equipo se lo salta.
Tipos estrictos y una suite que corre en CI
La verificación que no requiere que un humano esté prestando atención en el momento justo.
No escala
El prompt maestro que circula por Slack
Nace desactualizado, se copia mal, y nadie sabe cuál es la versión vigente. Es una skill sin control de versiones.
Un stack de MCPs distinto por persona
Cada dev le da a su agente capacidades distintas, así que el mismo pedido produce resultados distintos. Las revisiones dejan de parecerse entre sí y nadie entiende por qué.
Memoria compartida sin curador
Se llena de historial de sesión y decisiones vencidas. Termina siendo un lugar donde el agente encuentra confirmación para cualquier cosa.
Medir líneas generadas por IA
Sube justo cuando el problema empeora. Es la métrica que premia el comportamiento que estás tratando de corregir.
Esperar que se adopte solo porque es mejor
Sin un dueño y sin tiempo asignado, la configuración envejece. Nadie se levanta un martes con ganas de mantener los hooks de otro.
Quién se hace cargo
No hacen falta puestos nuevos. Hacen falta dueños. Cada uno de estos tres se puede repartir entre gente que ya tenés, pero si ninguno tiene nombre, los tres se caen — y se caen despacio, que es la peor forma.
Dueño de la configuración
- De qué se hace cargo
- El preset del equipo: hooks, skills, archivo de instrucciones, qué se instala y en qué versión.
- Señal de que nadie lo tiene
- Cada dev tiene un setup distinto y las revisiones no se parecen entre sí.
Curador de la memoria
- De qué se hace cargo
- Qué entra a la memoria compartida, qué se retira, y qué hacer cuando dos decisiones se contradicen.
- Señal de que nadie lo tiene
- Hay dos decisiones opuestas guardadas sobre lo mismo y nadie sabe cuál rige.
Dueño del presupuesto
- De qué se hace cargo
- Qué modelo se usa para qué, cuánto se puede gastar en una revisión, y qué se corta cuando se pasa.
- Señal de que nadie lo tiene
- La factura del mes sorprende a alguien.
El caso difícil: memoria compartida
De las seis disciplinas, la memoria es la única cuya versión de equipo es un producto distinto de su versión personal. Por eso vale la pena mirarla de cerca, con un ejemplo concreto.
Engram, la herramienta de memoria del catálogo, guarda por defecto en tu máquina. Tiene además un modo compartido —`engram cloud`— que es opcional, se activa proyecto por proyecto y se puede alojar en tu propia infraestructura contra un Postgres tuyo. Eso último no es un detalle: si la memoria del equipo incluye por qué se descartó un proveedor, esa base es información de negocio.
El error más común es tratar la memoria compartida como un backup del historial personal. No lo es. Tu historial de sesión es ruido para los demás: contiene tus tanteos, tus vueltas atrás y tus preferencias de estilo. Volcarlo entero a la memoria del equipo no le da contexto a nadie — le da a todos ocho versiones de la misma discusión sin saber cuál ganó.
Y hay un problema que aparece solo cuando hay varios: la memoria se contradice. Dos personas guardan decisiones opuestas sobre lo mismo, con semanas de diferencia, y las dos siguen ahí. El agente lee ambas y elige una. Engram tiene un subcomando `conflicts` justamente para detectar esas relaciones, lo cual confirma que el problema es real y que no se resuelve solo.
La regla de fondo: una decisión vieja que ya no aplica es peor que no tener memoria. La ausencia te obliga a preguntar; la memoria desactualizada te responde con seguridad y se equivoca. Por eso retirar es tan parte del trabajo como guardar.
De quién es todo esto
La pregunta que nadie hace hasta que ya es tarde. No es sobre licencias de software: es sobre qué producís trabajando así, dónde queda y qué pasa el día que cambiás de proveedor —o el día que el proveedor cambia sin consultarte—.
Empecemos por la parte que el proveedor ya resuelve: el código que sale es tuyo. Los proveedores serios ceden los derechos que tengan sobre la salida, y en la práctica el código generado se parece a lo que produciría cualquiera resolviendo el mismo problema con las mismas librerías. Si tu abogado necesita el detalle, está en los términos de servicio del proveedor que uses; no lo busques en un blog.
Lo que sí está en discusión es todo lo demás. Trabajar así produce activos que no son código: las decisiones y su porqué, un índice de tu repositorio, las reglas que fue acumulando el equipo, los procedimientos que ya funcionan. Eso es capital, y casi nadie lo trata como tal.
La prueba es simple y es la misma que aplicamos a cada herramienta del catálogo: si mañana cambiás de agente, ¿qué sobrevive? Lo que vive en un archivo del repositorio sobrevive. Lo que vive en una capa que habla un protocolo abierto sobrevive. Lo que vive adentro de un producto que solo le habla a un agente, no — y el día que migres vas a descubrir que no estabas construyendo un activo, estabas alquilando una comodidad.
Y después está lo que sale de tu máquina, que es una pregunta distinta a la de propiedad y que conviene no mezclar. Con un modelo alojado, el contexto que se arma para cada pedido va al proveedor: los archivos que leyó, lo que pegaste, lo que dicen tus reglas. No es todo el repositorio de una, pero en una jornada de trabajo se va buena parte. Eso no es opcional, es cómo funciona: la única salida es correr el modelo vos, y eso lo pagás en hardware. Lo que sí es opcional es cuánto más se va, y hacia dónde. Cada herramienta que conectás es otro destino. Cada servicio de memoria es una copia de tus decisiones en la infraestructura de alguien más.
Nada de esto es un argumento para no usar nada. Es un argumento para saber qué elegiste. Un equipo que puede responder estas cuatro columnas de memoria tomó una decisión; uno que no puede, aceptó la que venía por defecto.
El código generado
Dónde vive
Tu repositorio, como cualquier otro commit.
Qué sale de tu máquina
Cada vez que pedís algo: el contexto de esa tarea viaja al proveedor del modelo. No es opcional, es cómo funciona.
Lo controlás si
Cae en tu repositorio y para compilarlo o correrlo no hace falta nada que controle el proveedor. La cuestión de los derechos es otra, y se resuelve en los términos de tu proveedor: verificalo ahí, no en un blog.
Las decisiones y su porqué
Dónde vive
Depende de vos. Un archivo del repositorio, un servicio de memoria, o la cabeza de tres personas.
Qué sale de tu máquina
Un servicio de memoria alojado las guarda en infraestructura de otro: es exactamente lo que le estás pagando que haga. Es una copia de cómo piensa tu equipo, sentada en un lugar que no administrás vos.
Lo controlás si
Podés exportarlas y leerlas con otro agente. Si solo las lee el producto que las guardó, no son un activo: son una suscripción.
El índice del código
Dónde vive
Una carpeta del proyecto, generada a partir de tu propio código.
Qué sale de tu máquina
Nada, si el índice se construye local. Todo, si delegás el indexado en un servicio remoto.
Lo controlás si
Se puede reconstruir desde cero con el repositorio. Un índice que no se puede regenerar es una dependencia disfrazada de comodidad.
Las reglas y los procedimientos
Dónde vive
Archivos versionados, revisados en el pull request como cualquier cambio.
Qué sale de tu máquina
Entran en la ventana en cada sesión, así que viajan igual que el código. Si tienen secretos adentro, los secretos viajan.
Lo controlás si
Están escritos en texto plano y en el repositorio. Es el activo más portable de todos, y el que menos cuesta construir.
Qué medir
Acá se equivoca casi todo el mundo, y se equivoca en la misma dirección: mide producción cuando el cuello de botella es verificación. Generar código se abarató; revisarlo, no. Medir lo primero te hace optimizar la parte que ya era barata.
Medí esto
- Tiempo desde que se abre un PR hasta que alguien lo entiende.
- Retrabajo: qué porcentaje de lo mergeado se toca de nuevo en dos semanas.
- Defectos que llegan a producción, comparados contra antes.
- Cuánto tarda alguien que entra al equipo en mergear su primer cambio solo.
No midas esto
- Líneas generadas por IA. Es una métrica que sube cuando el problema empeora.
- Porcentaje de código escrito por el agente. No distingue código bueno de código que vas a borrar.
- Cantidad de prompts o de sesiones. Mide actividad, no resultado.
- Velocidad de aceptación de sugerencias. Premia exactamente el reflejo que querés evitar.