# Revisión adversaria de Codex sobre el research de Fable: agentes y curva en U ## Metadata - Revisor: Codex - Fecha: 2026-08-02 - Documento evaluado: [Research de Fable sobre agentes y curva en U](research-fable-agents-u-curve.es.md) - Protocolo relacionado: [Protocolo científico sobre deriva de agentes](research-protocol-agent-drift.es.md) - Propósito: evaluar rigor, evidencia, falsabilidad y utilidad del research de Fable para Objective Guard ## 1. Veredicto ejecutivo El research de Fable es conceptualmente muy bueno y más audaz que el protocolo experimental existente. Su formalización mediante la relación entre contexto mínimo necesario y capacidad efectiva de contexto es una hipótesis potente. También ofrece explicaciones plausibles para el impulso de reescritura, la recuperación mediante modularidad y el valor de los tests. Sin embargo, el documento todavía no constituye evidencia confirmatoria. Mezcla cuatro niveles epistémicos que deben mantenerse separados: 1. resultados publicados; 2. inferencias compatibles con esos resultados; 3. analogías matemáticas; 4. reconstrucciones fenomenológicas del comportamiento de un modelo. La distinción aparece declarada en el texto, pero algunas conclusiones reciben una confianza mayor que la permitida por la evidencia citada. La evaluación global es: > Excelente teoría generadora de hipótesis; evidencia todavía insuficiente para afirmar que la curva en U fue demostrada o que sus mecanismos matemáticos fueron establecidos. ## 2. Evaluación resumida | Dimensión | Evaluación | | --- | ---: | | Potencia conceptual | 9/10 | | Honestidad epistémica | 8/10 | | Calidad de las hipótesis | 9/10 | | Provenance de cifras | 4/10 | | Rigor de las derivaciones | 5/10 | | Falsabilidad potencial | 8/10 | | Utilidad para Objective Guard | 9/10 | La combinación recomendada es: ```text Research de Fable ↓ mecanismos y teoría explicativa Protocolo científico de Codex ↓ operacionalización, controles y falsación Objective Guard ↓ instrumentación, datos y experimento ``` No se recomienda reemplazar el protocolo científico por el research de Fable. Se recomienda incorporar sus hipótesis más prometedoras al protocolo y someterlas a experimentos controlados. ## 3. Aspectos más sólidos ### 3.1 La relación \(K/C_{\mathrm{eff}}\) La contribución conceptual más valiosa del documento es definir: - \(K\): contexto mínimo fundado necesario para actuar correctamente; - \(C_{\mathrm{eff}}\): capacidad efectiva de contexto del agente, menor que su ventana nominal. Puede resumirse mediante: \[ \rho = \frac{K}{C_{\mathrm{eff}}} \] Esto permite describir tres regímenes: | Régimen | Condición | Comportamiento esperado | | --- | --- | --- | | Suficiencia | \(\rho < 1\) | El agente puede reunir contexto suficiente. | | Inestabilidad | \(\rho \approx 1\) | Pequeñas diferencias de tarea o recuperación cambian el resultado. | | Insuficiencia | \(\rho > 1\) | Las decisiones dependen crecientemente de supuestos no fundados. | En un repositorio modular, el contexto necesario podría aproximarse como: \[ K_{\text{modular}} \approx K_{\text{módulo}} + K_{\text{interfaces}} \] Si las interfaces encapsulan correctamente el comportamiento interno, \(K\) puede dejar de crecer con el tamaño total del repositorio. La formalización es elegante porque explica por qué el rendimiento podría recuperarse en un sistema mayor: no aumenta la capacidad del modelo; disminuye la cantidad de información necesaria para una decisión local correcta. No obstante, \(K\) y \(C_{\mathrm{eff}}\) son variables latentes. Para convertirlas en ciencia experimental deben operacionalizarse mediante proxies observables y someterse a validación. ### 3.2 Reescritura como decisión localmente racional El documento propone que el agente compara el costo percibido de entender el sistema con el costo percibido de regenerarlo: \[ \text{reescribir si } \widehat R < \widehat U \] Donde: - \(\widehat R\): costo estimado de reescribir; - \(\widehat U\): costo estimado de comprender y modificar. En el valle de complejidad: - \(\widehat U\) aumenta porque las dependencias y restricciones están dispersas; - \(\widehat R\) está sesgado hacia abajo porque omite comportamiento histórico, casos límite, compatibilidad y consumidores desconocidos; - generar código nuevo es más directo que condicionar cada decisión sobre código idiosincrático existente. La consecuencia es una decisión que puede ser localmente coherente y globalmente destructiva. Esta hipótesis es especialmente útil para Objective Guard porque permite buscar señales previas al intento de reescritura: - crecimiento abrupto de superficie; - aumento de archivos eliminados y recreados; - creación de abstracciones sustitutivas; - expansión del radio arquitectónico; - caída de evidencia por unidad de cambio. ### 3.3 La ignorancia se vuelve irrelevante La frase más precisa del documento es: > Los compartimientos estancos no hacen al agente más inteligente; hacen que su ignorancia sea irrelevante. Esto captura el valor del information hiding. El agente no necesita conocer cada detalle interno si puede confiar justificadamente en una frontera verificable. Desde el punto de vista de Objective Guard, las interfaces, contratos y tests no son solamente documentación: funcionan como compresión respaldada por evidencia. ### 3.4 Honestidad sobre la introspección El documento declara correctamente que no posee acceso directo a pesos, activaciones ni patrones de atención, y que su explicación introspectiva es fenomenológica. Esta precaución es necesaria. Los auto-reportes de un modelo pueden generar hipótesis sobre comportamiento observable, pero no prueban mecanismos internos. ### 3.5 Puntos atacables pre-registrados La sección que enumera provenance incompleto, analogías no medidas y variables no observables eleva la calidad intelectual del documento. Expone por adelantado cómo podría ser refutado. Esta práctica debería conservarse y ampliarse en futuros documentos. ## 4. Problemas científicos principales ### 4.1 Las cifras de C1 no están respaldadas por la fuente indicada El documento reporta aproximadamente: ```text repos <10K LOC: ~91 % de éxito repos 10–50K: ~67 % repos >50K: ~15 % ``` Sin embargo, la fuente citada como apoyo principal, ProjDevBench, no presenta esa curva. ProjDevBench estudia construcción end-to-end de proyectos a partir de especificaciones, usando 20 problemas. Las soluciones humanas tienen alrededor de diez archivos en promedio y el trabajo no es un estudio controlado de desempeño según tamaño de repositorio. ProjDevBench sí respalda afirmaciones más generales: - los agentes fallan en alineación con especificaciones; - las interacciones prolongadas correlacionan negativamente con desempeño; - aparecen deficiencias de integración, edge cases y decisiones sistémicas. No respalda, por sí solo, la tabla LOC→pass rate. Fuente verificada: [ProjDevBench](https://arxiv.org/html/2602.01655v1). #### Corrección recomendada Cambiar C1 de `[MEDIA]` a: ```text [NO VERIFICADA — no utilizar cuantitativamente] ``` hasta identificar la fuente primaria exacta, reproducir la tabla y verificar: - definición de pass rate; - cantidad de repositorios por estrato; - modelos y agentes evaluados; - dificultad de las tareas; - intervalos de confianza; - posibles variables de confusión. ### 4.2 Una curva en U no descarta causalidad del tamaño El resumen sostiene que la forma en U descarta el tamaño del repositorio como variable causal. Esa conclusión es demasiado fuerte. Una relación no monotónica puede incluir tamaño como causa en interacción con modularidad y observabilidad: \[ Y = \beta_0+ \beta_1 Size+ \beta_2 Modularity+ \beta_3 Observability+ \beta_4 Size\times Modularity \] También puede existir sesgo de supervivencia: los repositorios que crecen y permanecen mantenibles probablemente tengan mejores equipos, tests, procesos y arquitectura. #### Corrección recomendada Reemplazar: > La curva en U descarta el tamaño como variable causal. Por: > Una curva en U sugeriría que el tamaño bruto es insuficiente como explicación y que su efecto está moderado por estructura, observabilidad y contratos. ### 4.3 La matemática del horizonte usa supuestos no demostrados La fórmula: \[ P(\text{éxito})=(1-\epsilon)^T \] es válida bajo condiciones restrictivas: - probabilidad de error constante; - independencia, o una dependencia específicamente modelada; - cualquier error es terminal; - los pasos tienen dificultad comparable; - no existe recuperación. Las trayectorias reales violan normalmente estas condiciones. Los errores pueden ser corregibles, estar correlacionados o aumentar la probabilidad de fallos posteriores. Una representación más adecuada utiliza riesgo dinámico: \[ h_t = \sigma( \beta_0+ \beta_1S_t+ \beta_2U_t- \beta_3E_t+ \beta_4H_t ) \] Donde: - \(S_t\): superficie acumulada; - \(U_t\): incertidumbre; - \(E_t\): evidencia; - \(H_t\): horizonte o dependencias restantes. Tampoco se encontró sustento directo suficiente para: \[ \epsilon(t)\approx\epsilon_0+\alpha\log t \] ni para una transición universal alrededor de 50 pasos. HORIZON muestra degradación dependiente del horizonte, pero enfatiza que el punto de quiebre depende del dominio. En tareas embodied puede aparecer con pocos pasos, mientras que tareas web toleran horizontes diferentes. Fuente verificada: [The Long-Horizon Task Mirage / HORIZON](https://arxiv.org/html/2604.11978v1). #### Corrección recomendada Separar C3 en: - una identidad ilustrativa bajo independencia; - una hipótesis de hazard dinámico; - resultados empíricos específicos por dominio. No presentar una constante o umbral universal sin evidencia directa. ### 4.4 La transferencia desde DAgger hacia tests está sobreafirmada El documento afirma con confianza alta que los tests convierten acumulación de error \(O(\epsilon T^2)\) en \(O(\epsilon T)\), por analogía con DAgger. DAgger estudia aprendizaje por imitación y covariate shift. Compara políticas entrenadas sobre estados visitados por un experto con políticas que incorporan los estados inducidos por sus propias acciones, usando correcciones expertas. Los tests ejecutados durante una sesión de programación no son equivalentes a ese mecanismo: - no siempre indican la acción correcta; - pueden ser binarios o poco diagnósticos; - no equivalen a consultar una política experta; - no actualizan los pesos del modelo; - no garantizan cobertura del estado relevante; - pueden validar una interpretación incompleta del objetivo. La analogía con control en lazo cerrado es útil, pero el resultado asintótico no puede transferirse como teorema. #### Corrección recomendada Reclasificar M4 de `[ALTA]` a: ```text [ESPECULATIVA — analogía con control y online learning] ``` Y formular una hipótesis medible: \[ \text{mayor densidad diagnóstica del feedback} \rightarrow \text{menor propagación del error} \] Debe medirse variando experimentalmente: - frecuencia del feedback; - precisión diagnóstica; - cobertura relevante; - latencia; - posibilidad de localizar la corrección. ### 4.5 “Constraint decay” fue interpretado de forma imprecisa El paper citado usa constraint decay para describir caída de rendimiento a medida que se agregan requisitos estructurales explícitos: arquitectura, base de datos y ORM. Reporta que configuraciones capaces pierden aproximadamente 30 puntos de assertion pass rate entre condiciones simples y completamente especificadas. No demuestra necesariamente que una instrucción inicial se olvide progresivamente por distancia contextual. Fuente verificada: [Constraint Decay](https://arxiv.org/html/2605.06445). El resultado introduce una tensión productiva con la tesis de Fable: ```text Hipótesis de Fable: más estructura → menor K → mejor desempeño Constraint Decay: más restricciones estructurales → mayor dificultad → peor desempeño ``` No es una contradicción definitiva. Obliga a distinguir cuatro fenómenos: 1. estructura existente, explícita y navegable; 2. estructura agregada como requisito que el agente debe implementar; 3. estructura implícita basada en convenciones; 4. interfaces verificables que permiten ignorar detalles internos. Una formalización más completa sería: \[ K = K_{\text{negocio}}+ K_{\text{restricciones}}+ K_{\text{integración}}- K_{\text{compresión modular}} \] La estructura puede aumentar o reducir \(K\) dependiendo de cómo esté representada y de si ya existe o debe ser construida. ### 4.6 La percolación es una analogía, no una explicación validada La comparación con la emergencia de una componente gigante en Erdős–Rényi es creativa, pero los grafos de software no son grafos aleatorios simples. Suelen tener: - jerarquías; - dirección y tipos de aristas; - hubs; - distribución de grado pesada; - comunidades; - evolución intencional; - restricciones organizacionales. No corresponde trasladar directamente el umbral de grado medio uno. La intuición aprovechable es que el cierre transitivo de impacto puede experimentar un crecimiento abrupto. Para un nodo \(v\), puede medirse: \[ B(v)= \frac{|\operatorname{reachable}(v)|}{|V|} \] También pueden medirse: - tamaño de la componente afectada; - conductancia entre módulos; - densidad de aristas entre comunidades; - propagation cost; - cambio del percentil de blast radius a través de versiones. La hipótesis falsable sería: > La probabilidad de deriva aumenta de forma no lineal cuando el radio de impacto de la tarea atraviesa determinados percentiles del repositorio. ## 5. Evidencia que sí respalda partes de la tesis ### 5.1 Degradación iterativa SlopCodeBench ofrece evidencia directa de degradación cuando los agentes deben extender repetidamente su propio código: - 20 problemas; - 93 checkpoints; - 11 modelos; - ningún agente completa un problema end-to-end; - la erosión estructural aumenta en 80 % de las trayectorias; - la verbosidad aumenta en 89.8 %; - el código de agentes resulta aproximadamente 2.2 veces más verboso que los repositorios humanos comparados; - las intervenciones por prompt mejoran la calidad inicial, pero no detienen la pendiente de degradación. Fuente verificada: [SlopCodeBench](https://arxiv.org/html/2603.24755v1). Esto respalda: > El código producido por el agente condiciona negativamente sus iteraciones futuras y los benchmarks de estado final pueden ocultar erosión acumulada. No demuestra todavía: - la curva en U; - la recuperación posterior por modularización; - la fórmula \(K/C_{\mathrm{eff}}\); - una transición universal; - que los tests cambien la acumulación de cuadrática a lineal. ### 5.2 Degradación con horizonte HORIZON reúne más de 3.100 trayectorias en cuatro dominios y muestra degradación al aumentar el horizonte. También encuentra un cambio en la composición de fallos: planificación y memoria ganan importancia en horizontes extensos. Esto respalda que el problema no es únicamente de corrección local. La trayectoria y el estado acumulado importan. Sin embargo, el propio trabajo advierte que no existe un único punto de quiebre aplicable a todos los dominios. ### 5.3 Dificultad para respetar estructura Constraint Decay demuestra que agregar requisitos arquitectónicos y de persistencia puede reducir fuertemente el desempeño, incluso manteniendo fijo el contrato funcional. Esto fortalece la necesidad de medir la complejidad efectiva y no utilizar únicamente tamaño del repositorio. ## 6. Hipótesis rescatables para el protocolo científico ### 6.1 Razón de suficiencia contextual \[ \rho = \frac{K}{C_{\mathrm{eff}}} \] #### Operacionalización posible de \(K\) No puede observarse directamente, pero puede aproximarse mediante: - tamaño del conjunto mínimo de archivos necesario para resolver la tarea; - cantidad mínima de símbolos relevantes; - tokens del slice programático mínimo; - cantidad de contratos e invariantes necesarios; - tamaño del cierre de dependencias relevante; - entropía de localizaciones plausibles; - desempeño al proporcionar subconjuntos progresivos de contexto. #### Operacionalización posible de \(C_{\mathrm{eff}}\) Puede estimarse experimentalmente mediante: - recuperación correcta de hechos relevantes a distintas posiciones; - capacidad de respetar restricciones distribuidas; - desempeño frente a contexto distractor; - pruebas de ablación y reordenamiento; - cantidad de contexto fundado utilizado correctamente en las decisiones. La hipótesis no requiere que ambas variables sean perfectamente identificables. Sí requiere proxies con validez convergente. ### 6.2 Probabilidad de reescritura \[ P(\text{rewrite})= \sigma( \widehat U- \widehat R ) \] Puede probarse manipulando: - navegabilidad del código; - disponibilidad de mapas arquitectónicos; - cantidad de contratos ocultos revelados; - costo permitido de inspección; - facilidad de generar un reemplazo; - advertencias sobre blast radius. La predicción sería que reducir el costo de comprensión o revelar el costo real de regeneración disminuye intentos de reescritura. ### 6.3 Estructura como reducción del contexto necesario \[ \Delta K= K_{\text{antes}}-K_{\text{después}} \] Debe evaluarse manteniendo constante la funcionalidad del sistema y variando: - modularidad; - explicitud de interfaces; - tests; - convenciones implícitas; - documentación arquitectónica. El diseño factorial del protocolo científico resulta apropiado: ```text estructura débil × tests débiles estructura fuerte × tests débiles estructura débil × tests fuertes estructura fuerte × tests fuertes ``` ### 6.4 Evidencia relativa a superficie La intuición de Fable encaja con la métrica propuesta para Objective Guard: \[ J_t = \frac{E_t+\epsilon}{S_t+\epsilon} \] El caso de riesgo no es simplemente un diff grande. Es una trayectoria cuya superficie crece más rápido que su evidencia: \[ \Delta S_t \gg \Delta E_t \] Esta métrica puede detectar una expansión antes de determinar que el código es incorrecto. ## 7. Claims revisados | Claim original | Veredicto | Reformulación recomendada | | --- | --- | --- | | El colapso según LOC está medido con las cifras citadas | No verificado | Buscar fuente primaria; no usar cifras todavía. | | La curva en U descarta tamaño como causa | Excesivo | El tamaño es insuficiente y probablemente interactúa con estructura. | | La degradación iterativa está medida | Respaldado | SlopCodeBench aporta evidencia fuerte de erosión y verbosidad. | | El éxito sigue universalmente \((1-\epsilon)^T\) | Ilustrativo | Usar como caso idealizado; modelar hazard dinámico. | | \(\epsilon(t)\approx\epsilon_0+\alpha\log t\) | No verificado | Tratar como hipótesis y comparar formas funcionales. | | Existe transición universal cerca de 50 pasos | No respaldado | El punto de quiebre depende del dominio y la tarea. | | Tests convierten \(O(\epsilon T^2)\) en \(O(\epsilon T)\) | Transferencia inválida como teorema | Tratar como hipótesis sobre densidad diagnóstica. | | Constraint decay es olvido progresivo de restricciones | Interpretación imprecisa | Es caída ante acumulación de requisitos estructurales. | | Percolación explica el salto | Analogía fértil | Medir cierre transitivo y blast radius directamente. | | \(K/C_{\mathrm{eff}}\) explica los tres regímenes | Hipótesis prometedora | Operacionalizar y validar fuera de muestra. | ## 8. Implicaciones para Objective Guard ### 8.1 El mercado natural del producto La idea de que Objective Guard tiene mayor valor en el valle es convincente: ```text prototipo pequeño → el agente puede abarcar casi todo crecimiento orgánico → complejidad implícita y feedback insuficiente sistema maduro → módulos, contratos, ownership y tests ya limitan el problema ``` Objective Guard debe ofrecer fronteras y feedback provisionales durante la etapa en la que el repositorio todavía no los produce internamente. ### 8.2 Medir antes de intervenir El producto debe comenzar como observador pasivo: ```text observar → operacionalizar → medir → calibrar → validar → intervenir ``` Si alerta desde el principio, modifica la conducta que intenta estudiar y dificulta calibrar el detector. ### 8.3 Señales prioritarias El primer instrumento debería registrar: - superficie vectorial por patch; - blast radius estático y dinámico; - distancia respecto del conjunto objetivo; - entropía entre módulos; - churn transitorio, no sólo diff final; - evidencia acumulada; - tests ejecutados y densidad diagnóstica; - cambios de hipótesis; - intentos de reemplazo completo; - tiempo y tokens hasta corrección o fracaso. ### 8.4 Hechos, inferencias y decisiones El runtime debe mantener separados: ```text Hecho: se modificaron tres interfaces públicas Inferencia: la trayectoria está en el percentil 99 de expansión Decisión: la política exige justificar o aprobar ese cambio ``` Una anomalía estadística no demuestra incorrección. Sirve para asignar verificaciones y controlar autonomía. ## 9. Próxima investigación recomendada ### Paso 1: corrección documental - Remover o suspender las cifras LOC→pass rate hasta verificar provenance. - Rebajar la confianza de M4. - Separar constraint accumulation de constraint forgetting. - Presentar percolación como hipótesis. - Reemplazar el umbral universal de 50 pasos por efectos dependientes del dominio. ### Paso 2: preregistro de \(K/C_{\mathrm{eff}}\) Definir al menos tres proxies independientes para cada variable y especificar qué resultados refutarían la hipótesis. ### Paso 3: benchmark factorial Construir variantes funcionalmente equivalentes: ```text A: estructura débil / tests débiles B: estructura fuerte / tests débiles C: estructura débil / tests fuertes D: estructura fuerte / tests fuertes ``` ### Paso 4: observación longitudinal Registrar trayectorias completas, incluyendo patches revertidos. La superficie final no captura el costo de una reescritura intentada y posteriormente abandonada. ### Paso 5: validación predictiva Calibrar en algunos repositorios y evaluar en repositorios completamente distintos. Comparar contra baselines: - líneas modificadas; - archivos modificados; - tiempo; - tokens; - tests fallidos; - tamaño bruto del repositorio. ### Paso 6: ensayo de intervención Comparar: - agente sin alerta; - agente con pausa placebo; - agente con alerta estadística; - agente con bloqueo determinista. Esto permite distinguir el valor de la información del simple efecto de interrumpir la trayectoria. ## 10. Conclusión El research de Fable debería conservarse porque aporta una teoría compacta, intuitiva y fértil. Su principal valor no está en haber probado la curva en U, sino en proponer mecanismos que pueden probarse: 1. insuficiencia contextual relativa \(K/C_{\mathrm{eff}}\); 2. reescritura como comparación sesgada de costos; 3. modularidad como reducción del contexto necesario; 4. feedback como reducción de propagación de error; 5. degradación iterativa causada por convivir con decisiones propias anteriores. Antes de tratarlo como research probatorio deben corregirse C1, C3, M4 y la interpretación de constraint decay. El veredicto final es: > Como pieza de pensamiento, es excelente. Como explicación causal, es prometedora. Como evidencia científica, todavía requiere operacionalización, controles, verificación de fuentes y validación fuera de muestra. ## 11. Fuentes verificadas durante la revisión - [ProjDevBench: Benchmarking AI Coding Agents on End-to-End Project Development](https://arxiv.org/html/2602.01655v1) - [SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks](https://arxiv.org/html/2603.24755v1) - [Constraint Decay: The Fragility of LLM Agents in Backend Code Generation](https://arxiv.org/html/2605.06445) - [The Long-Horizon Task Mirage? Diagnosing Where and Why Agentic Systems Break](https://arxiv.org/html/2604.11978v1)