Gentle Shell · Lo que viene
La próxima versión,
medida antes de salir.
Antes y ahora.
Todo lo que entró a main después de v4.0.0: un verify que prueba en vez de opinar, delegación solo cuando paga, un review nativo que se paga solo cuando hace falta, y los números del bench contra Codex que lo respaldan.
En una pantalla · Antes y ahora
Qué cambió respecto de la versión anterior
🔎Verify
Antes revisaba los tests del writer: 0 de 9 defectos conocidos. Ahora deriva sus propias pruebas de cada regla del pedido, en una copia aislada: 8 de 9, sin falsas alarmas. Corre siempre según el riesgo, con una tanda de corrección y un rechequeo acotado.
⇉Delegación
Antes delegaba por tamaño y le pasaba al worker un resumen. Ahora delega solo por una razón con nombre (paralelismo o contexto), la spec viaja por referencia y, sin razón, trabaja inline. Dos features: 10.9 min → 3.2 a 3.6 min.
⚖Review nativo (RDD)
Antes: 4 lentes en todo lo que fuera alto, y medio siempre con una sola. Ahora el agente elige las lentes según lo que tocó, el RDD entra solo en riesgo alto o si lo pedís, y verify se queda con las specs.
💎Bench contra Codex
Calidad ciega: de 3.º a 1.º en las tres tareas. Tarea chica: 3.6 → 1.9 a 2.3 min. Loop de correcciones: 97 min · USD 3.65 → 19 a 34 min, sin timeout.
Mismo modelo que Codex (Sol 6.1 low) en todos los roles. El detalle, slide por slide, más adelante.
El bench · Cómo medimos
Contra Codex, con el mismo modelo
🧩Tres tareas
Una chica, dos features juntas y una feature con dos entregas en commits revisables.
🙈Aceptación oculta
Una suite que el agente nunca ve. Medimos el costo hasta algo que la pasa, no la primera respuesta.
⚖Revisión ciega
Soluciones anonimizadas y mezcladas, sin saber de qué agente salió cada una.
Gentle Shell con Sol 6.1 low en todos los roles · Codex CLI con Sol 6.1 y su esfuerzo por defecto
El bench · Antes y ahora
Arrancamos perdiendo. Hoy:
| Caso | Antes | Hoy | Codex |
|---|
| Calidad · chica y mediana | 3.º, debajo de Codex | 1.º · arriba en 4 de 5 | — |
| Calidad · grande | La mejor era la de Codex | 1.º | 2.º |
| Tarea chica | 3.6 min | 1.9 a 2.3 min | 1.8 min |
| Dos features | 10.9 min | 3.2 a 3.6 min · 7.3 con verify | 2.8 min |
| Loop de correcciones | 97 min · USD 3.65 | 19 a 34 min · sin timeout | — |
| Verify en defectos conocidos | 0 de 9 | 8 de 9 · 0 falsas alarmas | — |
| Dos entregas | 2 rondas vacías | 17.5 a 17.9 min · USD 0.68 a 0.74 | 6.1 min · USD 0.23 |
Todas aceptadas en la primera ronda. Corridas únicas o de 2 a 3 repeticiones: tomalo como dirección, no como decimal exacto.
Verify · Según el riesgo
No opina: prueba
El verify deriva sus propias pruebas de cada regla del pedido, chequea invariantes (un comando rechazado deja los datos idénticos) y ejecuta todo en una copia aislada.
0/9Verify viejo: revisaba los tests del writer.
8/9Verify nuevo: sin falsas alarmas en las soluciones limpias.
Cuánto verificar
- Pasivo (docs, comentarios): releer la estructura.
- Medio: el writer corre sus checks. Si escribió un modelo chico, suma un verificador.
- Alto: verificador independiente, siempre.
- Una tanda de corrección y un rechequeo acotado. Si queda algo: "Needs your decision".
Subagentes · Delegar por una razón
Delegar cuesta. Solo con motivo.
⇉ParalelismoDos o más unidades independientes, lanzadas juntas, con archivos que no se pisan.
◎ContextoEl orquestador se está llenando y conviene descargar trabajo.
$"El worker es más barato"Lo medimos: no paga. El token barato no es trabajo barato.
Sin un motivo con nombre, trabaja inline. En la tarea de dos features: 10.9 min delegando → 3.2 a 3.6 min.
Tests · TDD por requisito
Ni tests de relleno, ni tests de menos
La revisión ciega mostró que nuestros tests eran más flojos que los de Codex. Probamos cuotas ("dos bordes") y copiar los tests del proyecto: ninguna sirvió.
REDUn test por regla pedidaCon los casos que esa misma regla nombra: ejemplos, bordes y errores.
⛨PRESERVEUn test por cada comando u opción existente que el cambio toca, aunque nadie lo haya pedido.
∅Nada másSin buscar casos porque sí.
Con eso, la calidad ciega pasó del 3.º al 1.º.
Calibrar el riesgo
Un cambio pedido no es riesgo. Lo que rompés de rebote, sí.
🎲Misma tarea, dos veredictos
"Riesgo alto" en una corrida, "sin riesgo" en otra. Y el motivo citado era el cambio que el usuario pidió.
🐛El bug real, en otro lado
En código compartido que nadie pidió tocar: un comando hermano empezó a aceptar en silencio una opción nueva y a guardar datos mal. Codex también se lo perdió.
🩹Nada de parches
Una regla específica para el parser: 0 de 2. La sacamos y pusimos una definición general de qué cuenta como "tocado".
"¿Eso no debería hacerlo solo?" Si el prompt necesita conocer el benchmark, memorizaste la respuesta.
Cerrar el trabajo
⏸Sin auto-pausas
En la tarea de dos entregas, se frenaba solo entre una y otra, esperando a un usuario que no existía. Ahora una frase dubitativa no es una parada: si no le dijiste que pare, sigue.
🔁Correcciones acotadas
- Una tanda de corrección para todos los bloqueos.
- Un rechequeo, solo de esos bloqueos.
- Si queda algo: "Needs your decision".
97 min → 19 a 34 min · sin timeout
Review nativo · Las lentes, medidas
Mismos 10 diffs, cuatro versiones de las lentes
9 defectos conocidos plantados en diffs reales, más cambios limpios de control. Cada celda, dos corridas.
| Prueba | Qué cambió | Defectos encontrados | Falsos graves en cambios limpios | Costo |
|---|
| T3 | Base: cuatro lentes, sin herramientas | 2 / 9 | 0 | — |
| T4b | Prompts nuevos de las lentes | 4 / 9 | 2 | USD 2.57 |
| T14 | Las lentes pueden ejecutar comandos (sandbox) | 4 / 9 | 4 | USD 3.69 |
| T15 | Una lente con el rol del verificador de requisitos | 7 / 9 | 0 | USD 1.48 |
Darle herramientas a la lente no encontró nada nuevo y duplicó los falsos. Lo que subió el recall fue el rol: chequear cada regla del pedido con pruebas propias.
Review nativo · Cada uno en lo suyo
Ese 7/9 era trabajo de verify
El verificador de requisitos ya existe: es el verify de ODD, que corre antes, con herramientas y una prueba por regla pedida. Meterlo dentro del RDD era duplicarlo.
"Verify corre antes supuestamente, la idea del Rdd es tener una vista externa, aislada sin influencia de 4 puntos distintos sobre tu proyecto."
El reparto
- Verify: siempre, según el riesgo del cambio. Dueño de las specs.
- RDD: la mirada de afuera. Ve el pedido solo como intención, no re-chequea specs.
- El RDD entra solo en riesgo alto, o cuando vos lo pedís.
- Las lentes siguen sin herramientas: T14 mostró que ejecutar no les suma.
Review nativo · Lo que entró a main
Pagar solo las lentes que importan
⚖Proporcional al riesgogentle-ai #5345. Misma severidad para el mismo hallazgo. El pedido entra como intención. El refuter determinístico solo corre si el runtime lo soporta.
🔍El agente elige las lentesgentle-ai #5348 · gentle-shell #1849. Según lo que tocó, elige entre risk, resilience, readability y reliability, y explica por qué.
🛡Verify siempre, RDD solo en altogentle-ai #5351 · gentle-shell #1852. El aviso de fin de turno (Claude y Pi) solo salta si hay un review pendiente.
Antes, el agente nunca elegía: medio caía siempre en una sola lente, alto en las cuatro. Ahora la elección tiene un motivo.
Contrato 1.3.0 en main, sale en la próxima release. Rechazar un START sin lentes elegidas queda en pausa: primero medimos cuántos agentes las eligen.
El bench · Lo que la aceptación no ve
Todos pasaron. No todos estaban bien.
🧪Tarea chicaEl test de Codex dejaba clavado como correcto un bug con el monto vacío. El test protege el bug.
💬Dos featuresCambió el mensaje de error de un comando hermano que nadie pidió tocar, sin test.
🐛Dos entregasEl import aceptaba categorías inexistentes en los grupos de splits.
Codex fue más rápido. Pero esa vuelta, alguien la tiene que hacer después. La iteración que te ahorrás es el bug en producción.
El bench · La brecha abierta
Gana en calidad. En lo grande, todavía tarda.
En la tarea de dos entregas, Gentle Shell tarda unas 3 veces lo que Codex. Se va sobre todo en un verify por cada entrega.
~1.3xTarea chica, contra Codex. 1.º en calidad.
~1.3xDos features, contra Codex. 1.º en calidad.
~3xDos entregas. 1.º en calidad. La brecha que estamos cerrando.
?Trabajo largo, varios frentes: donde los subagentes valen. Se mide aparte.
Cómo usarlo hoy
La combinación que mejor midió
Recomendado
- El mismo modelo fuerte en todos los roles, esfuerzo bajo.
- Background prendido en sesiones interactivas: el orquestador queda libre.
- Delegar solo por una razón; verify según el riesgo.
Si querés gastar menos
- DeepSeek V4 Flash en todo: la mitad de Codex, solo para trabajo chico y mediano.
- En cambios grandes de varias entregas, no: perdió con y sin background.
- Fuerte orquestando y barato escribiendo: no se justifica.
Trabajar en paralelo
Lanzá, seguí, te avisa
⏱Jobs en background
bash_background para builds, CI o servers: te avisa una vez cuando terminan. /gentle:jobs para verlos y frenarlos. #1835
📡monitor
Cada línea de un comando llega como evento mientras corre: logs, checks de CI, lo que quieras filtrar. #1844
📬Nada se pierde
Los resultados de subagentes en background ya no se pierden si llegan en mal momento. #1833
Y el TODO suma estados bloqueado (con qué espera) y descartado (a propósito). #1832
Entre sesiones
Tus sesiones se encuentran
Cada sesión publica en qué anda: un nombre reconocible, el repo, el área, los issues y PRs que toca. Las demás la encuentran y le avisan, siempre con tu consentimiento.
Por @decode2 · #1701 y #1702
Lo nuevo
- Buscar trabajo publicado por repo, área, tag, issue o PR.
- Consultar el estado que otra sesión publicó, sin tocar su contexto privado.
- Pedirle razonamiento a otra sesión: una llamada paga, con tu permiso explícito.
Comunidad
No lo hicimos solos
🤝Gentle Shell
- @decode2: coordinación y consultas entre sesiones.
- @danielgap: el perfil de la sesión se respeta en lanzamientos, status y uso.
- @matraket: los subagentes arrancan sin el trabajo de inicio del padre.
⚙Gentle AI
- @dnlrsls: instalador, OpenCode, sync, workspaces anidados y más.
- Y todos los que reportaron, probaron y revisaron.
Sin humo
Lo que todavía no
- Windows: anda, pero no está verificado de punta a punta.
- Trabajo largo con varios frentes y correcciones a mitad de camino: el valor real de los subagentes, todavía sin medir.
- Selección de lentes obligatoria: en pausa hasta medir cuántos agentes ya las eligen solos.
Cierre
Medir · Arreglar una cosa ·
Volver a medir.
Todo esto está en main y sale con la próxima versión de Gentle Shell y Gentle AI. Si lo probás antes, contanos qué encontraste.
github.com/Gentleman-Programming/gentle-shell · gentle-ai.gentlemanprogramming.com