Escribí las reglas de cómo trabaja mi equipo, con sus ejemplos y sus razones. La semana pasada las medí sobre 250 tickets reales: se cumplían en el 6%.
Lo que me sirvió no fue ese 6%. Fue partir la muestra en dos y ver que la misma regla, con el mismo texto, se cumplía en 67% de un lado y en 3% del otro.
Hace unos días conté cómo mi automatización perdía el 36% de los datos sin dar un solo error. Este post es el mismo problema una capa más arriba: no el dato que se pierde en silencio, sino la regla que nadie está aplicando mientras todos creemos que sí.
¿Por qué mi agente de IA ignora las reglas que le escribí?
Porque una regla escrita depende de que alguien se acuerde de aplicarla en el momento exacto, y un agente no se acuerda de forma confiable.
Mi equipo trabaja con una regla simple: ningún ticket nace incompleto. Título que diga el resultado y no el archivo, fecha, responsable, y una etiqueta que indique si un agente puede tomarlo solo o si hace falta criterio humano. Está escrita, argumentada, y cada parte existe porque su ausencia costó algo.
En algunos de mis repositorios esa regla tiene una revisión que corre sola antes de dejar crear el ticket. En otros, solo está escrita.
Ese fue el corte:
| Tickets bien etiquetados | |
|---|---|
| Donde la revisión corría | 67% |
| Donde solo estaba escrita | 3% |
Veintidós veces mejor, con el mismo texto y el mismo modelo. La diferencia entera está en si algo ejecutaba la regla o no.
Ya había escrito sobre las reglas que conviene poner en un archivo de contexto. Sigo pensando que ese archivo vale, y ahora sé para qué sirve de verdad: es el insumo de la verificación, no el control.
¿Cómo mido si mi proceso se está cumpliendo de verdad?
Contando, una vez, a mano. Tardé veinte minutos.
Tomé los 250 tickets creados en 30 días por los siete equipos, y revisé cinco cosas en cada uno: fecha, responsable, quién lo ejecuta, contenedor y título. Catorce cumplían las cinco. Ciento sesenta y seis no tenían ni una sola etiqueta.
Ese número no aparecía en ningún tablero, y nadie lo había pedido. El proceso "funcionaba" porque los documentos estaban bien escritos y nadie se quejaba de ellos.
Guardé la consulta. Un número que solo se puede tomar una vez no sirve para saber si mejoraste: dentro de un mes vas a tener una impresión, y las impresiones siempre dicen que sí mejoró.
Te dejo algo gratis para empezar por el lado correcto. La estructura de carpetas, prompts y plantillas que uso con clientes para armar su primer agente está completa en gabrielneuman.com/como-instalar-claude-code. Es gratis y no pide nada a cambio.
¿Dónde tiene que vivir una regla para que se cumpla?
Donde pasa el trabajo. Y ahí me equivoqué al primer intento.
Mi explicación inicial fue cómoda: la gente crea tickets fuera de la herramienta donde vive la revisión, desde el teléfono o en una junta. Molesto, pero comprensible.
Fui a ver proyecto por proyecto y no era eso. En uno de mis proyectos de integración convivían once tickets impecables y diecinueve sin una sola etiqueta, el mismo día.
Los diecinueve estaban escritos con el estilo de la casa, con títulos como "Geolocalización del pánico: el dato que ya nos mandaban y estábamos tirando". Eso no lo escribe alguien de prisa desde el celular.
Lo escribió uno de mis propios agentes, trabajando en un repositorio donde la revisión no estaba instalada. En mi CRM interno la proporción fue uno contra dieciocho.
La causa quedó clara: mi verificación viaja con el repositorio, y el trabajo se produce en repositorios que no la tienen. El repositorio donde guardo el método se protege a sí mismo perfectamente. Los demás, no.
De ahí salió la regla que ahora uso para decidir dónde poner cualquier control: la verificación tiene que viajar con quien hace el trabajo. Durante años eso fue el repositorio, así que ponerla ahí era obvio. Hoy quien hace el trabajo es un agente, y un agente cambia de repositorio cada hora.
¿Conviene poner un agente a revisar, o basta con una validación automática?
Las dos, en un orden que importa por lo que cuesta cada una.
Que el título empiece con un verbo, que haya fecha y responsable, que el ticket cuelgue de un proyecto: eso son comprobaciones de sí o no. Se escriben una vez, corren en un script y cuestan lo mismo hoy que en un año. No necesitan un modelo.
Saber si ese ticket duplica algo que ya existe, a qué proyecto pertenece, o si el alcance alcanza para que un agente lo tome solo: eso pide leer el resto del tablero. Ahí sí vale pagar una corrida de modelo, y es donde un agente aporta algo que un script no puede.
El orden no es intercambiable. Si pones al agente primero, pagas una corrida por cada ticket para descubrir que faltaba una fecha. Si pones la comprobación primero, al agente le llega menos trabajo y te cuesta menos cada mes.
Es la misma lógica que aplico cuando uso Claude Code para la gestión de proyectos: lo determinista se escribe como verificación, y el criterio se delega.
¿Qué parte de esto no se arregla poniendo más agentes?
La fila de espera. Y era mi número más incómodo.
La misma medición me devolvió 32 trabajos terminados, esperando que alguien los revisara. El más viejo llevaba diecisiete días. Dieciséis habían entrado el mismo día, en bloque.
Eso no es falta de capacidad para producir. Es una fila sin dueño claro y unos accesos que nadie terminó de repartir.
Y ahí está la trampa del momento que estamos viviendo con los agentes: la tentación es acelerar la parte que ya era rápida. Yo puedo cerrar el 6% mañana y subir la producción otro tanto, y lo único que voy a lograr es que la fila de 32 llegue a 60.
Por eso ese es el primer arreglo de mi lista, antes que cualquier automatización nueva. Sobre esto escribí también cuando conté qué cambia cuando los agentes empiezan a trabajar por ti: el cuello de botella se mueve, y casi nunca se mueve hacia donde estás mirando.
Lo que voy a hacer con esto
Cuatro movimientos, en orden de lo más barato:
- La verificación viaja con el agente, no con el repositorio. Corre en cualquier proyecto, incluido el que se clona por primera vez esta tarde.
- Una red en la herramienta donde vive el tablero, para lo que de verdad nunca pasa por un repositorio: el cliente que escribe, la junta, el formulario.
- Comprobación barata primero, criterio de modelo después. En ese orden, por lo que cuesta cada uno.
- El medidor guardado, para que dentro de un mes haya un número y no una sensación.
Y antes de los cuatro, vaciar la fila de 32.
Si tienes un manual de proceso escrito, la pregunta que yo no me había hecho es cuántas de esas reglas se están cumpliendo ahora mismo, y cuál fue la última vez que alguien lo contó en vez de suponerlo. Cuenta una sola regla sobre los últimos treinta días. El número te va a decir si tienes un sistema o una carta de buenas intenciones.
