Fareed Khan describió cómo montó una organización de ingeniería a partir de subagentes de Claude Code (artículo original): un orquestador en el papel de staff engineer, un plantel de roles especializados, un «employee handbook» de más de catorce skills y gates duros en cada transición del pipeline design → plan → execute → review → ship. Yo opero mis propios equipos de subagentes — cuatro roles, revisión paralela obligatoria con control de tests, aislamiento en git worktrees, tope de cinco iteraciones por ciclo de correcciones — así que leí el artículo como el setup de producción de otro ingeniero, no como un manifiesto. Punto por punto: dónde coincido, qué adopto, qué no me creo.
El aislamiento de contexto es el núcleo, y funciona
La tesis central: el subagente no hereda el historial de la sesión; recibe exactamente lo que la tarea necesita. El autor lo llama protección contra el «senior cansado» que, tras una hora de trabajo, confunde los requisitos de features vecinas. Mi experiencia lo confirma: en un equipo de cuatro roles, el revisor que nunca vio el intercambio entre orquestador y desarrollador encuentra problemas que un contexto compartido desgastado pasa por alto de forma sistemática. Contexto fresco por rol es la vía más barata de subir la calidad del trabajo multiagente — más barata que cualquier truco de prompts. Lo que ese aislamiento cuesta en tokens es un tema aparte.
Verification-before-completion: lo adopto como regla
La fórmula del autor: «declarar terminado el trabajo sin verificación es deshonestidad, no eficiencia». La acompaña una tabla afirmación → evidencia obligatoria: «los tests pasan» significa salida fresca del comando en ese mismo mensaje — no «deberían pasar» ni «ayer pasaban». En mi caso esta disciplina vivía como hábito, sin estar fijada como regla — y el hábito es lo primero que cede bajo presión de deadline. Me llevo la formulación a mis plantillas de equipo casi literal.
TDD para documentación: la mejor idea del artículo
Un skill no cuenta como terminado hasta pasar un ciclo RED/GREEN en un subagente limpio: primero se registra que sin el skill el agente rompe la regla bajo presión, después que con el skill la cumple. Casi nadie testea así la documentación, aunque los skills son código que ejecuta un LLM. Aparte, una observación certera: la description de un skill debe responder «cuándo aplicarlo», no «qué hace» — si no, el modelo lee la descripción, decide que captó la idea y nunca abre el texto completo. Revisé mis propios skills: la mitad de las descriptions está mal escrita exactamente en ese sentido.
La regla del 1%: elegante, pero no me la creo
La regla — «si existe aunque sea un uno por ciento de probabilidad de que un skill aplique, el agente está obligado a invocarlo» — protege el proceso de la erosión por racionalizaciones («si solo es una pregunta»). El problema es el precio: la obligatoriedad total convierte cada pregunta menor en una procesión de lecturas de skills. Es más barato enrutar: el skill se dispara por tipo de tarea, no por probabilidad de aplicabilidad. La erosión del proceso se caza mejor con una auditoría ocasional de sesiones que con un impuesto sobre cada acción.
La Delete Rule: también la dejo pasar
La exigencia de borrar todo el código escrito antes del test — sin «guardarlo como referencia» — se declara Iron Law. Como manifiesto se entiende: los tests-after verifican lo que se implementó, los tests-first verifican lo que debería implementarse. Como práctica diaria es derrochadora: tirar un borrador funcional para reescribir lo mismo contra un test se justifica en un escenario de entrenamiento y casi nunca en una tarea real con presupuesto.
Conclusión
Un armazón rígido con iron laws compensa donde varios agentes trabajan largo tiempo y sin supervisión: la previsibilidad vale más que los tokens. Para un setup personal conviene llevarse tres cosas — aislamiento de contexto por rol, un verification gate antes de cualquier «listo» y el test RED/GREEN para los propios skills — y dejar el armazón atrás. El autor, eso sí, discute limpio: el sistema está publicado como repositorio abierto, de modo que el desacuerdo se resuelve con experimento y no con retórica. Qué le pasa a ese marco cuando las reglas se multiplican — tuning a escala.