Un desarrollador que ha invertido 3.000 horas perfeccionando un flujo de trabajo integral con Claude ha publicado los detalles de un sistema que desafía las prácticas convencionales en el desarrollo asistido por inteligencia artificial. El enfoque, que combina primeros principios, desarrollo dirigido por especificaciones, testing exhaustivo y validaciones en cascada, representa un cambio paradigmático en cómo se estructura la colaboración entre humanos y modelos de lenguaje.
El núcleo de la filosofía subyacente es contraintuitivo: más contexto no equivale a mejor desempeño. Según el autor, las ventanas de token expandidas representan una "trampa cognitiva" que degrada la inteligencia operativa del sistema. En su lugar, propone un enfoque de "contexto curado" donde cada fase del desarrollo recibe únicamente la información necesaria y verificada para su ejecución específica.
La arquitectura del sistema implementa una jerarquía cognitiva clara: Claude Opus maneja la estrategia y diseño; Sonnet se dedica a la implementación; Haiku actúa como intermediario para modelos externos como Kimi y GLM. Cada transición entre fases implementa un "control de calidad" automático que bloquea el progreso hasta que se cumplen criterios de validación formales.
El flujo operativo es extraordinariamente granular. Comienza con /arm, un proceso conversacional donde Opus extrae requisitos, restricciones y decisiones críticas a través de diálogo estructurado. Después, /design aplica análisis de primeros principios validado contra documentación en vivo. La fase /ar implementa lo que el autor denomina "revisión adversarial": tres modelos distintos critican el diseño en paralelo, cada uno con diferentes puntos ciegos entrenados, basándose en acceso al sistema de archivos y documentación del proyecto.
La fase /plan transforma el diseño aprobado en un documento de ejecución tan específico que evita ambigüedades. Las tareas se definen en grupos de cinco por agente, sin conflictos de archivos, con rutas exactas y ejemplos de código completos. Los casos de prueba se definen en tiempo de planificación, no después de la compilación.
La ejecución ocurre en /build, donde Opus coordina mientras que múltiples instancias de Sonnet construyen en paralelo, cada una con su propia terminal. Después de la compilación, un pipeline post-build secuencial o paralelo aplica auditorías: /denoise elimina código muerto, /qf y /qb validan guías de estilo, /qd verifica documentación, /security-review escanea vulnerabilidades OWASP.
Un principio crítico distingue esta arquitectura: "separación de contextos para ejecución y validación". El agente que construye el código nunca lo valida. Esto previene la "alucinación validada", donde los sistemas refuerzan sus propios errores.
El costo de token inicial representa solo el 0,8% de una ventana de 200.000 tokens, sugiriendo que la curación agresiva de contexto no sacrifica eficiencia económica. El sistema incorpora "stress-testing de suposiciones": múltiples perspectivas de modelos distintos critican el mismo diseño, exponiendo puntos ciegos que una única perspectiva ocultaría.
El autor enfatiza que el sistema preserve "intención y agencia" contra "gaslighting cognitivo" y "tercerización cognitiva". La premisa fundamental es que el código es un pasivo; el juicio es un activo. Los agentes deben respetar la velocidad de pensamiento humana sin automatizar decisiones que requieren comprensión contextual profunda.
Esta arquitectura emerge en un momento crítico en la industria de IA. Mientras que la mayoría de flujos de trabajo siguen el patrón lineal prompt → plan → code, este enfoque cuestiona si esa secuencia es óptima. La introducción de "validación adversarial" con múltiples modelos y la "verificación contra documentación en vivo" representa una respuesta a problemas bien documentados de confiabilidad en sistemas de IA: alucinación sobre bibliotecas, recomendaciones de patrones desactualizados y decisiones de arquitectura no fundamentadas.
El sistema también responde a una fricción operativa común: agentes que piden "aclaraciones" porque el plan fue insuficiente. Al forzar planes exquisitamente detallados en fase de ejecución, el autor elimina ambigüedad sin requerir intervención humana iterativa.
La implicación más amplia es que la eficacia de sistemas con IA depende menos de capacidad bruta del modelo y más de arquitectura de flujos de trabajo que respeten limitaciones cognitivas, tanto de humanos como de máquinas. Conforme la industria migra desde "prompting mágico" hacia "ingeniería de sistemas", frameworks como este señalan direcciones de maduración.
