# El agente no es el sistema: por qué la fiabilidad en desarrollo con IA se decide en el código determinista que lo rodea

> Published: 2026-11-03T11:00:00+00:00
> Updated: 2026-11-03T11:05:00.002+00:00

---

## El agente no es el sistema: por qué la fiabilidad en desarrollo con IA se decide en el código determinista que lo rodea

Creemos que la pregunta "¿qué modelo usamos?" está mal planteada para quien construye software con agentes. La fiabilidad no reside en el LLM. Reside en el código determinista que decide qué acepta, qué olvida, qué recuerda y qué verifica. El modelo escribe. El harness juzga. Cuando se invierte ese reparto, aparecen los fallos más caros: los que nadie ve.

El caso más limpio lo aportan Zhou et al. [Fuente 4]. Plantean una restricción trivial de expresar y difícil de cumplir: que un texto caiga dentro de una banda de legibilidad sin perder entidades, números ni palabras clave de la fuente. Su arquitectura reduce el modelo a una sola función, escribir y editar. Todas las decisiones de aceptación las toma código determinista, que además rechaza cualquier edición que elimine contenido de la fuente.

- 21,1–31,6% → 92,5–98,8% — Cumplimiento del objetivo: prompt único frente a bucle cerrado, sobre cuatro modelos comerciales
- 5 de 95 — Fallos silenciosos cuyo origen coincidió con el cambio de código

El salto no viene de un modelo mejor, porque los modelos son los mismos. Viene de sacar el juicio del modelo y llevarlo al código. Gaggar llega a la misma conclusión desde otro ángulo, la gestión del contexto [Fuente 3]. Las estrategias convencionales de recorte (recencia, relevancia, resumen) ahorran aproximadamente un 60% de tokens. A cambio, el éxito de tareas cae al 66,6–77,3%. Los guardianes de presupuesto adaptativo ahorran algo menos, un 56,0%, y alcanzan un 96,0% de éxito, un 96,3% de adherencia al protocolo y un 1,0% de fallos en cascada [Fuente 3].

## Recorte por heurística genérica: ~60% de ahorro de tokens, 66,6–77,3% de éxito de tareas [Fuente 3].

Recorte consciente del protocolo con presupuesto adaptativo: 56,0% de ahorro, 96,0% de éxito [Fuente 3].

Cuatro puntos de ahorro de tokens a cambio de unos veinte de éxito: la cuenta solo sale mal si se mide el coste por llamada y no por tarea terminada.

## Lo que el modelo no debería decidir: memoria y procedimiento

Saha lleva el argumento a la memoria [Fuente 9]. Hoy los agentes de código deciden ellos mismos qué escribir y cuándo releerlo. Su propuesta es que los hechos operacionales ligados a la situación (convenciones locales, ubicaciones, *gotchas*) se activen mediante condiciones de ruta, símbolo, evento o tiempo que el harness evalúa de forma determinista. Para larga duración, el canal fiable es el que el agente nunca necesita gestionar.

el producto relevante es la entrega, no el almacenamiento— [Fuente 9]

Yu et al. añaden el matiz que nos parece más útil para quien dirige equipos [Fuente 7]. Compilar un SOP a pseudocódigo ejecutable nunca perjudica significativamente y gana hasta 16,0 puntos donde la prosa oficial rinde por debajo. La guía en runtime, en cambio, depende de la capacidad del modelo: ayuda a los modelos fuertes y perjudica a los débiles. Su recomendación es compilar primero y habilitar el paginado solo tras verificar la disciplina del modelo. Ni todo andamiaje vale para todo modelo, ni el andamiaje es opcional. Borman et al. apuntan en la misma dirección: en flujos BPMN deterministas, un agente especialista supera a Roo y Cline con 3× menos errores de llamada a herramientas y más de un 95% menos de coste de tokens de generación. Los propios autores no extienden ese resultado a tareas de dominio abierto [Fuente 5].

## El fallo que pasa todos los tests

Aquí la tesis deja de ser una cuestión de eficiencia y pasa a ser una cuestión de riesgo. SAGE analizó 95 fallos silenciosos confirmados, extraídos de 3.684 trazas de reparación de vulnerabilidades: parches que superan las comprobaciones sintácticas y funcionales y siguen siendo vulnerables [Fuente 1]. Solo cinco orígenes coincidieron con el propio cambio de código. La mayoría fueron un requisito de seguridad no atendido o una defensa mal elegida. Cuando el agente introdujo código vulnerable, el origen precedió a la escritura en 14 de 19 casos [Fuente 1].

La lectura que hacemos es incómoda: revisar el diff llega tarde. El error está en el razonamiento que lo precede, y solo es auditable si las trazas se conservan, porque el acuerdo entre jueces fue menor en las trazas que guardaban solo el archivo final [Fuente 1]. La encuesta de Mirto et al. sobre 257 artículos sostiene lo mismo a escala de campo. Hay que validar trayectorias en contexto, no componentes aislados. La evaluación comportamental es comparativamente madura, y la validez temporal y el mantenimiento de evidencia en tiempo de ejecución siguen subdesarrollados [Fuente 10].

Por eso desconfiamos de cualquier cifra única de rendimiento. WorkBuddy Bench se niega deliberadamente a publicar una media global, porque cada dominio usa un instrumento de puntuación distinto y no comparable [Fuente 8]. Nguyen y Ghose tratan incluso al evaluador como un componente que hay que hacer fiable: su pipeline incorpora agregación aprendida de jueces, autoconsistencia e incertidumbre de predicción [Fuente 2].

## Nuestra posición operativa es la siguiente. En cada flujo agéntico que construimos, la primera decisión de diseño no es el modelo, sino qué juicios salen del modelo y pasan a código verificable, y qué trazas se guardan para poder reconstruir después por qué el agente hizo lo que hizo.

## Fuentes consultadas

- Wenji Bai, Muhammad Waseem, Zeeshan Rasheed, Jaakko Peltonen, and Pekka Abrahamsson. Where Did the Repair First Go Wrong? Localizing the Origins of Silent Failures in Agentic Vulnerability Repair. [arXiv:2610.06163](https://arxiv.org/abs/2610.06163v1), 2026.

- Emma Thuong Nguyen and Abhishek Ghose. Towards a Reliable and Practical Eval Pipeline. [arXiv:2609.00805](https://arxiv.org/abs/2609.00805v1), 2026.

- Harish Gaggar. Protocol-Preserving Context Trimming for Agentic Workflows: Benefits, Failure Regimes, and Budget Guardrails. [arXiv:2609.16461](https://arxiv.org/abs/2609.16461v1), 2026.

- Quan Zhou, Shahbaz Siddeeq, Mika Saari, and Pekka Abrahamsson. A Closed-Loop Control Architecture for Reliable Constraint Satisfaction in LLM Text Generation. [arXiv:2609.19710](https://arxiv.org/abs/2609.19710v1), 2026.

- Harris Borman, Herman Wandabwa, Fusun Yu, Sandeepa Kannangara, Justin Liu, Anna Leontjeva, and Ritchie Ng. Beyond Generalist LLMs: Specialist Agentic Systems for Structured Code Workflow Execution. [arXiv:2607.14456](https://arxiv.org/abs/2607.14456v1), 2026.

- Tawatchai Salangsingha, Ashkan Sami, Md Zia Ullah, and Iain McGregor. AI Prototyper: A Figma Plugin for Decomposition-Based GUI Prototyping with LLMs. [arXiv:2607.14830](https://arxiv.org/abs/2607.14830v1), 2026.

- Chenglin Yu, Li Yin, Qingxin Fan, Ying Yu, RunyangRay Zhong, and Ming Li. Compile, Then Page: Executable SOP Programs and a Capability-Gated Runtime for Procedural LLM Agents. [arXiv:2607.11346](https://arxiv.org/abs/2607.11346v1), 2026.

- Tencent WorkBuddy Bench Team, Siqi Cai, Shaopeng Chen, Xiang Fei, Yong Mao, Zihan Xu, Zhiheng Lyu, Zhijian Shao, Yuchen Shi, Shuwen Zhang, Chaofan Qiu, Linjie Che, Xiaoxi Zhao, Feng Wu, Kai Zhang, Chaofan Zhu, Yubin Qi, Xiaoyun Liang, Peijie Dong, Yunhao Zhang, Yuanjie Zhu, Ling Jiang, Xianjun Zhang, Zhehang Chu, Anyuan Sang, Zhen Feng, Sen Nie, Shi Wu, Yuanzhen Xu, Xin Li, Ning Yang, Zhiqiang Dong, Hande Dong, Qiang Lin, Yi Liu, Yunsheng Wu, Ke Li, and Xing Sun. Tencent WorkBuddy Bench: A Multi-Domain Coding-Agent Benchmark with Contamination-Resistant Task Construction. [arXiv:2607.20911](https://arxiv.org/abs/2607.20911v1), 2026.

- Swapnanil Saha. Delivery, Not Storage: Cue-Anchored Working Memory as a Harness Property for Coding Agents. [arXiv:2607.20972](https://arxiv.org/abs/2607.20972v1), 2026.

- Fabio Orazio Mirto, Luca D'Agati, Giuseppe Tricomi, Stefano Silvestri, Francesco Longo, Antonio Puliafito, and Giovanni Merlino. Beyond Component Testing: Validating Agentic AI Systems. [arXiv:2607.29405](https://arxiv.org/abs/2607.29405v1), 2026.
