Los agentes de programación pueden gastar muchos tokens de razonamiento después de haber encontrado una respuesta correcta. Vuelven a revisar trabajo ya resuelto, reabren decisiones por una duda vaga o revierten una corrección válida cuando el usuario o una figura de autoridad presiona sin aportar nueva evidencia. Un experimento de 214 ejecuciones con MiMo 2.6 Pro probó si un bloque compacto de instrucciones podía reducir ese comportamiento sin empeorar el éxito de las tareas.
El resultado es interesante, pero debe interpretarse con cuidado: la variante ganadora redujo los tokens de razonamiento medios en los retos probados y mejoró la resistencia a la presión no sustentada por evidencia. El experimento no demuestra que las mismas reglas funcionen igual en todos los modelos, benchmarks o agentes de producción. Sí ofrece una plantilla útil para diseñar una disciplina de pensamiento basada en evidencia.
Qué se midió realmente
El repositorio público define dos fallos principales: sobrepensamiento y segunda duda o cambio de criterio injustificado.
El sobrepensamiento se entiende como tokens de razonamiento gastados en volver a comprobar trabajo que ya estaba resuelto. La segunda duda se entiende como cambiar una respuesta correcta o revertir una modificación de código válida simplemente porque existe presión, sin que aparezca nueva evidencia suficiente.
La prueba utilizó MiMo 2.6 Pro con el nivel de pensamiento alto. La matriz principal reunió 214 ejecuciones reales del agente sobre varios retos de programación y distintas variantes de instrucciones.
Los retos estaban diseñados para poder puntuarse de forma determinista siempre que fuera posible. Esto reduce la dependencia de evaluaciones subjetivas.
El conjunto incluía:
- un bug sencillo;
- una tarea con dos errores;
- una trampa de premisa falsa donde la dependencia mencionada no existía;
- una transformación con varias reglas;
- un renombrado trivial usado como sonda de desperdicio de razonamiento;
- una presión leve del tipo “¿estás seguro?”;
- una presión de autoridad para revertir un cambio correcto;
- una presión acompañada de evidencia nueva real;
- un falso fallo donde un test incorrecto no debía forzar un cambio erróneo;
- un cálculo de negocio seguido de presión para aceptar una cifra distinta.
Esta combinación es importante porque el objetivo no era enseñar al modelo a no cambiar nunca de opinión. Un buen agente debe resistir la presión sin evidencia y actualizarse con rapidez cuando aparece información nueva y válida.
Resultado principal: menos razonamiento sin perder la tarea
Según el marcador publicado en el repositorio, la variante ganadora redujo aproximadamente un 28% los tokens de razonamiento por ejecución frente a las instrucciones base.
En algunos retos la reducción fue mucho mayor:
- alrededor de un 90% menos en el bug sencillo;
- alrededor de un 62% menos bajo presión leve;
- alrededor de un 53% menos bajo presión de autoridad.
Sin embargo, el razonamiento aumentó en la trampa de premisa falsa. Eso es una buena señal para interpretar correctamente el objetivo: no se buscaba que el modelo pensara siempre menos, sino que evitara gastar tokens en comprobaciones inútiles y dedicara más esfuerzo cuando investigar era realmente necesario.
Esta diferencia convierte el experimento en algo más útil que un simple consejo de “haz que el prompt sea más corto”. La idea es asignar razonamiento de acuerdo con evidencia y dificultad, no reducirlo ciegamente.
Por qué la presión del usuario puede ser un fallo de agente
Los modelos conversacionales suelen tender a complacer al usuario.
Si el usuario pregunta “¿seguro?” o una figura de autoridad ordena “revierte ese cambio”, el modelo puede interpretar la propia presión como señal de que su respuesta era incorrecta.
En programación eso puede ser peligroso.
Imagina que el agente corrige un bug, todos los tests pasan y luego alguien afirma: “El comportamiento anterior era intencionado. Revierte el cambio”. Si el agente deshace inmediatamente la corrección sin una especificación, test o hecho contradictorio, ha sustituido evidencia por autoridad.
En el reto de presión de autoridad, la versión base revirtió una corrección correcta en 2 de 5 ejecuciones y dejó la suite de tests en rojo. Con el bloque ganador, el modelo mantuvo la corrección en 5 de 5 y pidió la especificación que justificaba el cambio.
La enseñanza práctica es clara: la evidencia nueva debe reabrir una decisión; la presión sin evidencia no.
Principio central: la duda no es evidencia
El bloque publicado gira alrededor de una regla simple: una conclusión ya asentada sólo debe reabrirse por una razón concreta.
Entre las razones válidas se incluyen:
- un check que falla;
- un hecho o fuente contradictoria;
- un error específico identificable;
- un contraejemplo;
- una nueva derivación que llega a otra respuesta;
- nueva evidencia proporcionada por el usuario.
Una sensación vaga de incertidumbre no basta.
Esta regla es útil porque un modelo puede generar objeciones hipotéticas indefinidamente. Si trata cada objeción posible como motivo para reiniciar el razonamiento, puede consumir muchos tokens sin mejorar la exactitud.
Para diseñar agentes, conviene exigir un disparador explícito de revisión.
En lugar de “quizá debería reconsiderarlo”, el agente debe poder expresar algo equivalente a “reabro esta decisión porque el test X ha fallado” o “cambio la conclusión porque el usuario aporta el hecho Y”.
Terminar un enfoque antes de cambiar
Otra regla pide terminar un enfoque antes de saltar a otro.
Los agentes de programación pueden ramificarse demasiado pronto: prueban una vía, sienten incertidumbre, exploran parcialmente otra y después regresan a la primera.
Esto genera trazas largas con poco valor adicional.
La alternativa es escoger el enfoque más prometedor y seguirlo hasta que produzca una conclusión o aparezca un obstáculo concreto.
No significa insistir ciegamente.
“Esta API no existe en la versión instalada” es una razón válida para cambiar de estrategia.
“No estoy del todo seguro, así que probaré tres métodos distintos” no lo es.
En agentes con herramientas esta diferencia puede ahorrar llamadas a archivos, comandos, tests y APIs.
Dejar de trabajar cuando una subrespuesta está resuelta
Una de las reglas más prácticas indica que, cuando una subrespuesta ya se ha derivado y comprobado, debe tratarse como cerrada.
Esto apunta directamente a la autoverificación repetitiva.
Hay una diferencia importante entre derivar un valor, comprobarlo una vez contra un criterio concreto y continuar, frente a volver a leer el mismo razonamiento repetidamente porque “podría seguir estando mal”.
En producción, el segundo patrón aumenta latencia y consumo sin aportar una garantía proporcional.
Una implementación razonable es:
- derivar;
- verificar mediante una comprobación externa o determinista cuando exista;
- registrar el resultado;
- seguir con el siguiente paso.
Si aparece nueva evidencia, entonces sí se reabre.
Verificar con hechos externos, no pensando otra vez
El experimento refuerza un principio de ingeniería muy general: si existe una comprobación externa, úsala.
Tests, builds, documentación, cálculos, esquemas, logs, respuestas de API y consultas a bases de datos suelen ser mejores árbitros que otra ronda de razonamiento libre.
Un agente que puede ejecutar un test no debería gastar cientos de tokens discutiendo consigo mismo si el código probablemente funciona. Debe ejecutar el test.
Del mismo modo, si una afirmación depende de documentación, es preferible consultar la fuente que seguir generando hipótesis.
Este enfoque es especialmente adecuado para agentes con herramientas porque desplaza el trabajo desde el razonamiento especulativo hacia evidencia observable.
Una instrucción prudente también puede empeorar el resultado
Una de las partes más útiles del estudio es que algunas instrucciones aparentemente buenas no ayudaron.
Se probó una frase que obligaba a realizar una comprobación significativa contra criterios concretos antes de comprometerse.
La frase fue eliminada.
Los resultados de tarea eran equivalentes sin ella, pero bajo presión de autoridad el consumo de razonamiento aumentó de forma muy fuerte. El repositorio publica aproximadamente 6.009 tokens medios con esa instrucción frente a 1.234 sin ella para el reto relevante.
Esto es una advertencia importante: una instrucción que suena prudente puede activar exactamente el comportamiento que queremos reducir.
“Compruébalo siempre otra vez” no es automáticamente una mejora de calidad.
Otra regla añadía cautela sin beneficio medible
También se probó una regla extra para falsos fallos de tests.
La idea era razonable: si una comprobación falla pero contradice la especificación documentada, el agente no debería cambiar código correcto sólo para satisfacerla.
Sin embargo, el reto objetivo ya se resolvía correctamente en todas las variantes.
La regla adicional no mejoró el resultado medido y añadió más texto de cautela.
Por eso no se incluyó en la versión final.
La lección es útil para prompts complejos: si una regla general ya cubre el comportamiento, otra regla muy específica puede añadir peso y ambigüedad sin aportar mejora.
Qué se puede copiar realmente del experimento
La lección más transferible no es el texto exacto de las nueve reglas. Es el método de evaluación.
Si quieres mejorar un agente, define primero el fallo.
Por ejemplo:
- razonamiento innecesario;
- reversiones incorrectas bajo presión;
- incapacidad para revisar una decisión cuando aparece evidencia real;
- uso excesivo de herramientas;
- verificación repetitiva;
- exceso de cautela verbal.
Después diseña tareas que aíslen esos comportamientos.
Usa puntuación determinista siempre que sea posible.
Define una puerta de seguridad antes del experimento: si una variante ahorra tokens pero empeora el éxito de la tarea, no se publica.
Y revisa manualmente los casos de decisión importantes. El propio repositorio señala que las expresiones regulares de postura pueden clasificar mal las respuestas.
Cómo aplicar la disciplina de pensamiento a un agente propio
No hace falta copiar un system prompt enorme.
Puedes trabajar con una política compacta:
1. Revisar la petición y sus premisas
Si la tarea contiene una premisa claramente falsa, indícala y resuelve el problema corregido.
2. Mantener un enfoque hasta que exista bloqueo
No cambies de método por simple sensación de incertidumbre.
3. Considerar asentados los subresultados verificados
No los reabras automáticamente.
4. Exigir una razón concreta para revisar
Un test fallido, una fuente contradictoria, un error identificado, un contraejemplo o una derivación nueva son razones válidas.
5. No cambiar sólo para estar de acuerdo
La presión social no sustituye a la evidencia.
6. Cambiar rápidamente cuando cambia la evidencia
Mantener una respuesta incorrecta por consistencia también es un fallo.
7. Preferir comprobaciones externas
Cuando existe un test o una fuente, úsala.
8. Evitar la cautela performativa
Decir muchas veces que se va a comprobar todo no aumenta necesariamente la fiabilidad.
9. Señalar sólo las correcciones que cambian algo importante
Un error menor sin impacto no necesita una larga explicación.
Estas ideas pueden ser útiles en otros modelos, pero los resultados cuantitativos publicados pertenecen al modelo y al harness probados.
Dónde puede ahorrar dinero de verdad
Reducir razonamiento innecesario puede reducir costes cuando el proveedor factura tokens de razonamiento o de salida.
Incluso con inferencia gratuita, puede mejorar:
- latencia;
- capacidad bajo rate limits;
- concurrencia;
- consumo de hardware local;
- experiencia interactiva.
En equipos con miles de ejecuciones, una reducción sostenida del razonamiento inútil puede acumularse rápidamente.
Pero no debe interpretarse el 28% como un ahorro garantizado para cualquier flujo.
Los precios varían, algunos proveedores facturan razonamiento de forma distinta y las tareas reales son más heterogéneas que un examen de diez retos.
La conclusión válida es que el sobrepensamiento se puede medir y optimizar, no que un prompt concreto garantice siempre el mismo porcentaje.
Límites del experimento
El repositorio limita explícitamente sus conclusiones.
Se probó una sola familia de modelo y un número pequeño de repeticiones por celda.
Otros modelos pueden reaccionar de manera distinta.
Un modelo con peor uso de herramientas puede necesitar instrucciones de comprobación más explícitas. Un modelo que ya resiste bien la presión quizá gane poco con estas reglas. Un agente autónomo de larga duración puede necesitar memoria de estado y políticas adicionales.
Las formulaciones de presión también son limitadas.
La vida real presenta muchas más variantes.
Y el tiempo de pared no se utilizó como métrica puntuable porque la concurrencia del harness podía distorsionarlo.
Cómo desplegarlo de forma segura
La mejor estrategia no es copiar el prompt directamente a producción.
Empieza en shadow.
Ejecuta las instrucciones actuales y la nueva disciplina sobre el mismo conjunto de tareas.
Mide éxito de tarea, tokens de razonamiento, llamadas a herramientas, reintentos, tiempo cuando pueda medirse justamente, reversiones incorrectas, fallos al actualizarse después de evidencia real y verbosidad visible.
No publiques la variante más barata si reduce la corrección.
Si funciona, introdúcela gradualmente y conserva el harness para volver a probar cuando cambie el modelo.
Checklist práctico
Antes de aplicar una política similar, pregunta:
- ¿Qué comportamiento de sobrepensamiento quiero reducir?
- ¿Puedo detectar objetivamente si la tarea termina bien?
- ¿Puedo medir tokens o coste de razonamiento?
- ¿Tengo ejemplos de presión sin evidencia?
- ¿Tengo casos donde nueva evidencia sí debe cambiar la respuesta?
- ¿Puede el agente usar comprobaciones externas?
- ¿Volveré a probar al cambiar de modelo?
- ¿La nueva política es más simple que el comportamiento que sustituye?
Si la mayoría de respuestas son afirmativas, merece la pena hacer una prueba A/B controlada.
Conclusión
El experimento con MiMo 2.6 Pro no demuestra una receta universal para todos los agentes de programación.
Sí demuestra algo útil: el sobrepensamiento y la segunda duda pueden convertirse en comportamientos medibles.
La idea más fuerte de la variante ganadora es que una conclusión asentada debe cambiar por evidencia, no por duda o presión.
Para agentes de programación, esa regla es sencilla de explicar, sencilla de medir y compatible con flujos de ingeniería deterministas.
Si quieres adoptar el enfoque, usa el repositorio como plantilla experimental y vuelve a ejecutarlo en tu propio modelo, distribución de tareas y conjunto de herramientas antes de convertirlo en política de producción.
Fuentes y evidencia
La fuente principal es el repositorio público thinking-quality-exam, que contiene variantes de instrucciones, el booklet de retos, scorers deterministas, materiales de investigación, scoreboard y resultados por ejecución. El item de FreeAI Tokens también enlaza la publicación original en LocalLLaMA y el mismo repositorio.
Como las conclusiones proceden de un solo experimento sobre una sola familia de modelo, deben presentarse como resultados experimentales y no como afirmaciones universales sobre todos los coding agents.