AKILI

El ciclo de vida de las especificaciones

1. Constitución

   Establece la base del proyecto —PRD, diseño de sistema y diseño detallado— como fuente de verdad duradera.

2. Propuesta

   Captura la intención de un cambio acotado como una propuesta ligera y revisable.

3. Especificación

   Convierte la intención aprobada en requisitos completos, diseño técnico y tareas trazables.

4. Ejecución

   Implementa cada tarea con un harness Leader → Implementer → Reviewer — el Reviewer audita a ciegas al Implementer y cualquier aborto fail-fast revierte limpiamente con git restore + git clean.

5. Validación

   Revisión humana, pruebas automatizadas y evidencia de validación registrada contra cada requisito.

6. Cierre

   Consolida la documentación, sincroniza el sistema de diseño y cierra la especificación.

El enrutamiento de modelos por niveles de capacidad asigna cada fase del ciclo de vida de AKILI a uno de seis niveles de capacidad con nombre propio, en lugar de correr todo sobre un único modelo fijo, de modo que la profundidad de razonamiento aplicada a una tarea coincide con lo que esa tarea realmente necesita.

• T1 · Architect

  Razonamiento profundo para arquitectura, decisiones de trade-off e intención, además del juicio de orquestación sobre la marcha que surge durante la ejecución.

• T2 · Coder

  Máxima productividad al escribir código y seguimiento de instrucciones para escribir el código y las pruebas que lo acompañan.

• T3 · Auditor

  Revisión crítica independiente —conformidad, bugs, desviación— realizada en un modelo distinto al que escribió el cambio.

• T4 · Context-Ingest

  Absorción de contexto extenso sobre código legado y documentación base, donde el tamaño de la ventana de contexto importa más que la profundidad de razonamiento.

• T5 · Fast-Cheap

  Formateo estructurado y resumen rápidos y económicos para tareas donde la profundidad no es el cuello de botella.

• T6 · Multimodal

  Razonamiento visual y de UI/UX sobre imágenes, capturas de pantalla y referencias de diseño.

El effort dial es un segundo ajuste, independiente del anterior, con cinco niveles —low, medium, high, xhigh y max— que controla cuánto razonamiento recibe una tarea puntual sin importar qué nivel de capacidad tenga asignado: el nivel es fijo por fase, el effort dial se ajusta por tarea.

• Low
• Medium
• High
• X-High
• Max

• author ≠ is not equal to auditor

  author ≠ auditor significa que el modelo que escribe un cambio nunca es el modelo que lo revisa: el registro de enrutamiento de AKILI exige que los niveles Coder y Auditor apunten a modelos concretos distintos, y si alguna vez coincidieran en el mismo modelo, escala automáticamente al Reviewer un nivel.

• ARCHITECT = BUILDER

  ARCHITECT = BUILDER mantiene al mismo modelo que razona la arquitectura como responsable de construirla, para que una decisión de diseño sobreviva intacta hasta el código en vez de ser reinterpretada por el modelo que termine implementándola.

• Reservar el razonamiento profundo para las decisiones

  Reservar el razonamiento profundo para las decisiones significa que el nivel más capaz se dedica a la propuesta, la especificación, la verificación y la orquestación sobre la marcha —las fases donde una decisión equivocada sale cara— mientras la ejecución y el trabajo de registro se enrutan a niveles más rápidos y económicos, de modo que el costo siga la dificultad en lugar de que cada tarea pague tarifa de arquitecto.

La delegación en AKILI está acotada en ambos extremos: un piso que la vuelve obligatoria a partir de cierto tamaño, y un techo que la vuelve un desperdicio a partir de cierto punto.

Cuándo delegar es obligatorio

1. Una revisión de un solo archivo se queda en el mismo hilo —la delegación solo empieza después de esa base.
2. Leer cuatro archivos completos o más pide levantar un scout en lugar de leerlos en el mismo hilo.
3. Escribir en dos archivos no triviales o más pide entregarle el trabajo a un Implementer.
4. Revisar un diff pide un Reviewer con contexto nuevo, nunca el mismo modelo que lo escribió.

Cuándo delegar es un desperdicio

• El techo de delegación marca el punto en que entregarle el trabajo a otro agente cuesta más de lo que ahorra: un subagente bien enfocado rinde más que varios para una tarea modesta.
• Comprometerse con una delegación ya hecha en vez de volver a derivar el mismo plan.
• Dar el brief preciso al subagente desde la primera vez, en lugar de iterar con instrucciones vagas.
• Poner un techo a cuántos subagentes corren en paralelo, en lugar de abrir el abanico sin límite.
• Nunca delegar la propia verificación: revisar el trabajo propio no es algo que se entregue a otro.