Filosofía

Por qué existe Argui

La IA agéntica cambió lo que una persona puede construir. Pero la velocidad sin estructura produce caos: código inconsistente, proyectos que se desvían del problema real, productos que funcionan en demos y fallan en producción.

Las respuestas existentes caen en dos extremos:

• Herramientas de ejecución pura — optimizan cómo el agente escribe código, pero ignoran todo lo que pasa antes: entender el problema, validar el alcance, definir la arquitectura. Asumen que ya sabes exactamente qué construir.
• Procesos corporativos trasplantados — ceremonias, story points, roles burocráticos. Estructura heredada de equipos humanos grandes que no tiene sentido cuando quien construye es una persona orquestando agentes.

Argui ocupa el espacio entre los dos: proceso real, sin teatro.

Principios

1. El problema antes que el código

Ningún agente escribe una línea hasta que el problema está investigado, documentado en PRDs (Product Requirements Document) y validado por un humano. Si el PRD está mal, todo lo que sigue está mal. La velocidad de la IA hace que los errores de definición se materialicen más rápido — no que desaparezcan.

2. Identidad antes que instrucción

Un agente no es un prompt con tareas. Es una perspectiva. Un agente implementador piensa distinto a un agente revisor, y esa diferencia de perspectiva es lo que produce calidad. Cuando el mismo agente crea y valida su propio trabajo, el sesgo de confirmación gana siempre.

3. La estructura llega antes que los ejecutores

Los estándares se definen antes de crear los agentes. La arquitectura se valida antes de escribir el backlog. El orden importa: cada paso le da contexto al siguiente. Invertir el orden produce patrones implícitos inconsistentes que nadie decidió conscientemente.

4. Validar con prototipo, no con código

Antes de construir, los PRDs se materializan en un prototipo navegable trazado al documento: cada bloque de la UI (interfaz de usuario) enlaza a la sección del PRD que lo define, y el feedback de los stakeholders ajusta ambos a la vez. Cambiar un prototipo cuesta horas; cambiar código de producción cuesta sprints. El prototipo aprobado se convierte en la referencia visual canónica — de él se consolida el design system, para que lo entregado se vea como lo aprobado.

5. El humano aprueba, no supervisa

Hay puntos del proceso donde el avance se detiene hasta que el humano aprueba explícitamente: la validación de PRDs, la aprobación del prototipo, cada prueba de QA (Quality Assurance), el cierre de cada ciclo. No es burocracia — es el mecanismo que mantiene el producto conectado a la realidad. La IA no sabe cuándo está equivocada; el proceso sí. Por eso en Argui no existe el flujo totalmente desatendido: la automatización acelera, pero nunca reemplaza la validación humana.

6. Proceso no es burocracia

Argui no tiene ceremonias, ni story points, ni reuniones de sincronización. Cada paso existe porque previene un modo de falla específico observado en proyectos reales. Si un paso no previene nada, se elimina. La metodología se mide por lo que evita, no por lo que documenta.

7. La eficiencia es parte del diseño

Orquestar agentes tiene un costo real en tokens, y ese costo se decide en el diseño — no en la factura. Cada agente declara el modelo más económico que ejecuta bien su tarea; los agentes caros se invocan tras un gate que confirma que hacen falta; las tareas de juicio se separan de las mecánicas. Un proceso que ignora su propio costo no es predecible — y la predictibilidad es la promesa central.

8. El conocimiento vive y evoluciona

El CLAUDE.md se actualiza con el proyecto. La metodología se actualiza con cada aplicación real. Nada en Argui es definitivo: es el estado actual de un conocimiento que mejora con la práctica. Los cambios que vienen de teoría sin práctica no entran.

El nombre no es decorativo

Argui viene del euskera argi: luz, claridad, lucidez. Es exactamente lo que esta metodología busca producir — claridad donde el desarrollo con IA tiende a la niebla: código que nadie decidió conscientemente, proyectos que se desvían, nadie sabe en qué punto está la entrega.

Pero apunta a algo más que claridad individual. En el País Vasco, el auzolan es el trabajo comunal en el que cada vecino aporta su oficio a una obra que nadie podría levantar solo, coordinados no por un jefe impuesto sino por una regla compartida y un propósito común. Esa es la estructura de esta metodología:

• El conocimiento está codificado en un sistema (el workflow), no en la cabeza de una persona.
• Quien lo aplica coordina sin ejecutar directamente (la sesión principal).
• Las fuerzas convocadas son especializadas y tienen identidad propia (los agentes).
• El resultado depende del orden y la intención de la convocatoria (el proceso).

Elegir esta raíz también es una declaración. La tradición cooperativa vasca —de Mondragón en adelante— demostró que los resultados duraderos no nacen de un ejecutor heroico, sino de estructura, soberanía y cooperación. La tecnología es nueva; saber organizar el trabajo común hacia un propósito no lo es.

Qué no es Argui

• No es una herramienta. No se instala, no tiene CLI (Command Line Interface), no automatiza la adopción.
• No es un framework de prompts. Los agentes son puntos de partida que requieren adaptación con juicio.
• No es una promesa de velocidad mágica. La velocidad es consecuencia de no improvisar, no un atajo.
• No es dependiente de un modelo. Funciona con cualquier IA con capacidades agénticas.

Para quién es

Para quien entiende que orquestar es una habilidad distinta a ejecutar, y quiere desarrollarla con un sistema probado en lugar de improvisarla en cada proyecto.