Anubhav dedicó seis meses a afinar su entorno para el agente y expuso la pila de ocho capas que, en sus palabras, «finally worked»: un archivo de memoria de proyecto corto (insiste en mantenerlo «under 500 tokens on purpose» para lograr aciertos de caché), reglas acotadas por ruta, el modo de planificación, un único subagente revisor de solo lectura sobre un modelo barato, skills, hooks, cinco servidores MCP y worktrees paralelos con modo headless en la CI. Su conclusión es tajante: «The stack is the workflow. The workflow is the multiplier. The prompt is just the last five percent.» Con esa frase final estoy de acuerdo por completo. Mi desacuerdo está en otro sitio: llevo bastante más de seis meses construyendo una pila parecida —con equipos de varios agentes, revisión y pruebas en paralelo, enrutamiento de contexto y capas de reglas duras— y precisamente la primera capa que Anubhav llama el cimiento es la que se derrumba a mi escala.
Mi tesis es sencilla. El consejo de «mantén el archivo de memoria diminuto» es correcto para un desarrollador en solitario dentro de un único repositorio. Pero en cuanto tienes reglas de cumplimiento de varias organizaciones que no pueden fijarse a rutas de archivo, un archivo plano y pequeño deja de ser una virtud y se convierte en una capacidad que falta. Anubhav confunde dos problemas distintos: el coste en tokens del contexto de fondo y la autoridad y la precedencia de las reglas. Su receta de ocho capas resuelve solo el primero.
Dónde tiene razón, y de verdad
Casi todo en su artículo es el punto donde yo empecé en su día, y son los primitivos correctos. Las reglas acotadas por ruta ahorran tokens exactamente como él describe: un archivo de convenciones de migraciones no debería cargarse cuando el agente toca el frontend. El modo de planificación con un subagente de solo lectura al que se le niegan explícitamente write y edit es buena higiene: la exploración y la revisión viven en un contexto aislado, no en el bucle principal.
Su énfasis en los Deferred Permissions es especialmente acertado. Poder pausar a un agente a mitad de una ejecución headless, aprobar la acción fuera del proceso y reanudar exactamente en el mismo punto es el primitivo correcto para trabajos nocturnos. Antes, como él bien señala, una ejecución nocturna que necesitaba hacer push a main o bien corría con los permisos desactivados o fallaba a las tres de la madrugada. Sus subagentes con una allowlist de herramientas estrecha, rebajados a un modelo barato, también son sensatos: el modelo caro se queda con el razonamiento difícil mientras el revisor corre barato en segundo plano. Aquí no discuto: lo uso.
Dónde choca con su techo
El techo empieza justo donde Anubhav pone el cimiento. Su primera capa es el consejo de mantener diminuto el archivo de memoria raíz porque «Cache hit rates drop noticeably past ~500 tokens». El argumento de los tokens es correcto. Pero equipara en silencio «más barato en tokens» con «mejor estructurado», y esos son ejes distintos.
A mí las reglas me llegan a la vez de varias organizaciones y equipos. Algunas son reglas de cumplimiento duras: qué puede y qué no puede aparecer en los mensajes de commit para ciertos remotos, qué acciones en producción exigen una aprobación nominal, qué regla de la organización no puede sobrescribir una capa de equipo más estrecha. Estas reglas no se filtran por ruta de archivo. Deben dispararse por organización, equipo y función —por dónde estás y en nombre de quién trabajas, no por qué archivo editas—. El mecanismo acotado por ruta de Anubhav simplemente no aplica aquí: no existe un glob que exprese «esta regla de la organización sobrescribe la regla del equipo».
Por eso no meto todo en un archivo ni lo encojo: enruto las reglas al inicio de la sesión a lo largo de tres ejes: organización, equipo, función. Solo la terna relevante se carga en el contexto. Eso resuelve ambos problemas a la vez: tokens y precedencia. Anubhav resuelve solo los tokens; su «archivo pequeño» elimina el coste de fondo pero no dice nada sobre qué regla gana cuando dos capas se contradicen. A su escala la pregunta nunca surge. A la mía surge el primer día.
El segundo punto donde choca con el techo es su único revisor de solo lectura. Un subagente revisor sin garantía de terminación es peligroso precisamente porque asume en silencio que una pasada de revisión converge. En mi montaje la revisión y las pruebas corren en paralelo, y a veces entran en conflicto: el revisor dice «blocker», el tester dice «verde». ¿Quién tiene razón? Un solo subagente no tiene respuesta para eso, ni un límite superior de iteraciones. Por eso mi arquitectura tiene un guard duro de cinco iteraciones y un orquestador líder que arbitra el empate entre revisor y tester. Esa es justo la parte cara que asume una arquitectura de equipo, y la que un único revisor sobre un modelo barato no cubre.
Un detalle más sobre su approval gate. Su hook de seguridad para los push a main es un emparejamiento de cadenas: case "$cmd" in *"git push"*" main"*). Captura la forma familiar del comando. Pero un emparejamiento de cadenas se elude de forma trivial: con otro comando sinónimo, una variable, un alias. Mis approval gates son semánticos: se disparan ante una clase de acción (una escritura en un sistema externo compartido, una operación destructiva en producción), no ante una cadena concreta. Esa es la diferencia entre «protección frente a una errata» y «protección frente a una elusión».
Qué hacer al respecto
Si trabajas en solitario en un único repositorio, toma la receta de Anubhav entera: es precisa. Un archivo de memoria pequeño e imperativo, dos o tres reglas acotadas por ruta, un hook de formateo, el modo de planificación para todo lo arriesgado. Deferred Permissions: obligatorio.
Pero en cuanto entran en juego reglas de varias organizaciones, deja de pensar en el tamaño del archivo y empieza a pensar en enrutamiento y precedencia. Separa los dos ejes que Anubhav pega: los tokens son sobre la caché, la autoridad es sobre qué regla sobrescribe a cuál. Lleva las reglas de cumplimiento duras a una capa que se cargue según el contexto de la sesión, no por glob. Y en cuanto la revisión pasa de una sola pasada, dale un límite superior explícito de iteraciones y un árbitro para los conflictos; de lo contrario, el «revisor barato» algún día entrará en un bucle infinito en una ejecución cara.
En lo esencial coincidimos: la pila vence al prompt. Anubhav simplemente se detiene en la línea de base desde la que yo empecé. Su octava capa es mi capa cero.