Cuándo delegar y cuándo no, cuándo verificar y con qué rigor, cuándo pedir una revisión externa (RDD) y qué modelo poner en cada rol. Todo con números de nuestro propio bench.
¿Esto infla el contexto del padre sin necesidad?
path:line.Dos o más unidades con superficies de edición disjuntas, cada una claramente más pesada que arrancar un subagente (varios archivos o ~100+ líneas).
Tests, docs y código del mismo comportamiento son UNA unidad. Una entrega que depende de otra anterior no es independiente.
Deriva las "Allowed edit surfaces" (paths/globs exactos) antes de lanzar. Es dueño de git. Un seam check al final: la suite completa, una vez.
Se dispara solo para un cambio de alto riesgo.
En cualquier otro caso, el test enfocado del cambio y la suite corren inline.
Alrededor de 150k tokens de contexto en el padre: pausa y delega la siguiente unidad acotada.
No es una cuarta razón para delegar por tamaño: es una red de seguridad del contexto.
Mapear, escritores paralelos, verificación de alto riesgo o respaldo de contexto. Nada más.
git diff.Entrega por referencia, nunca por paráfrasis: Spec: odd/tasks/feature.md, T2, S3-S4. Las specs citan las palabras exactas del usuario.
Efectos irreversibles: migraciones, reescribir o borrar datos guardados, cambios de formato.
Auth, permisos, credenciales, secretos, guards, sandbox.
Cambiar o quitar lo que otros ya consumen: API pública, flags, formatos de config, exports. Agregar una flag no es alto riesgo.
Locks, carreras, orden asíncrono.
Instaladores, release, CI, deploy, dependencias.
Ningún test detectaría una regresión.
Todo cambio cierra con Risk: item N (motivo) o Risk: none. Antes de "none": si el diff toca código compartido (opciones, parsers, helpers), es el ítem 3.
comando: resultado observado.En todos los niveles, el padre vuelve a correr un comando reportado antes de entregar.
Sesgo de modelo chico: si el writer corrió en un modelo chico (low effort o mini), sube el nivel uno.
mktemp -d), nunca en el workspace.Si después de eso sigue fallando, la decisión vuelve al humano.
Defectos conocidos que encontraba el verify viejo, dentro de la misma corrida.
Los que encuentra el verify nuevo, con cero falsas alarmas altas en 4 controles limpios.
El loop de corrección, que antes tardaba 97 min.
La diferencia: un checklist adversarial derivado de las specs más invariantes.
# el humano decide $ gentle-ai review mode status|enable|disable # el flujo assess → solo si reviewDue (alto riesgo) o el usuario lo pide inspect → START
Algo podría quedar expuesto, perderse o cambiar de forma irreversible.
Comportamiento ante fallos: errores, reintentos, timeouts, concurrencia.
Lo que otros leen o de lo que dependen: APIs, mensajes, docs.
Lógica que los tests deberían fijar.
Elige solo las lentes pertinentes a lo que tocaste.
Cumplir requisitos es trabajo de verify. Nunca elijas lentes para rechequear specs.
En nuestra base de revisión, 4 lentes encontraron lo mismo que 1 lente.
Un token de path hacía que cambios ordinarios pagaran 4 lentes.
Líneas de un capítulo de docs que recibió una revisión completa de 4 lentes.
Verify primero, review después: verify prueba las specs; review mira desde afuera lo que nadie pidió.
| Rol | Recomendado | Por qué |
|---|---|---|
| Orquestador | Frontera (Opus, GPT top), effort medio | Decide, dimensiona tareas, es dueño del riesgo. |
| Explorer | Gama media (Sonnet), effort por defecto | Lee y comprime; el padre hace un spot check. |
| Writer | Gama media (Sonnet), effort medio | Implementa contra specs literales y corre sus checks. |
| Verificador | Modelo fuerte, effort alto | Su trabajo es encontrar lo que el writer no vio. Nunca un modelo chico. |
| Copia/formato | Evita modelos chicos | Para trabajo byte-exacto: cp + diff. |
Pasa el modelo explícitamente por rol. Si lo omites, el subagente hereda el del padre (normalmente el más caro).
Un verificador en modelo chico emitió un resultado aprobado sin correr los tests.
Un modelo chico truncó un reporte de 637 a 209 líneas y aun así reportó "byte-perfect". Dos veces.
Sin modelo explícito, el subagente usa el del padre: normalmente el más caro.
Cambios ordinarios pagando 4 lentes por un token de path.
No confíes en autorreportes: verifica con comandos.
Por encima de Codex en tareas medianas (3 de 3) y grandes. En tareas chicas, empate.
Codex es más rápido y más barato en todo: alrededor de 3x en tareas grandes.
La calidad pasó del 3.º al 1.º lugar tras estos cambios.
Ganamos calidad, no velocidad. Decirlo así es parte del método.
Trabaja inline, delega con una razón, verifica en proporción al riesgo y reserva la mirada externa para lo que realmente puede romper algo.
github.com/Gentleman-Programming/gentle-ai · github.com/Gentleman-Programming/gentle-shell