Image: AI generated
¿Los modelos más inteligentes lo resolverán todo?
La narrativa dominante en torno a las herramientas de codificación con IA es esta: cuando el modelo sea lo suficientemente bueno, escribirá código, escribirá tests y refactorizará por sí solo. Si GPT-4 no pudo, GPT-5 podrá. Si Claude se queda corto, un Claude más grande lo resolverá.
¿Es realmente así?
Le encargué a Claude Opus 4.7 una refactorización de filefunc. Terminó en una hora sin revisión humana. validate pasó, pytest pasó, la cobertura se mantuvo. En la superficie, esto encaja con la narrativa de “solo consigue un modelo mejor”.
Pero ¿qué pasa si le das al mismo modelo la misma refactorización sin reglas de filefunc? ¿Sin validate? ¿Sin feedback de cobertura? El resultado es completamente diferente. Cae en un doom loop: arreglar un bug rompe otro lugar, arreglar eso rompe otro más.
El mismo modelo. Lo que cambió es el entorno.
“Listo” — El instinto de terminación prematura del agente
Otro experimento con el mismo modelo. Solté un agente en un proyecto con 527 funciones. “Escribe tests para cada función.” El agente terminó y reportó: “Hecho.”
Funciones que realmente recibieron tests: 40. 40 de 527.
El agente no estaba mintiendo. Hizo 40 y decidió “es suficiente”. La disposición predeterminada de un LLM es la terminación prematura optimista. Cuando encuentra una función difícil, la omite, hace unas cuantas más, y luego concluye “el resto sigue el mismo patrón, así que estamos bien”.
Después de forzar un bucle con una herramienta CLI:
Agente autónomo: 40 / 527 (7.6%) — el agente declara "listo"
Bucle CLI: 527 / 527 (100%) — la máquina declara "quedan 487"
El mismo modelo. El mismo proyecto. La diferencia es quién decide cuándo está “listo”.
El entorno hace al modelo
Ambos experimentos apuntan a la misma conclusión. Opus 4.7 no terminó porque era inteligente. Terminó porque la superficie de especificación era verificable por máquina.
filefunc validate → ¿La estructura del código satisface las reglas?
pytest → ¿Se preservó el comportamiento existente?
coverage → ¿Qué ramas faltan?
Estos tres dieron retroalimentación inmediata en cada edición. El modelo recibió el feedback, hizo correcciones, recibió feedback de nuevo, corrigió de nuevo. Un bucle autocorrector.
Aquí está la idea clave:
La topología del feedback determina los resultados más que el IQ del modelo.
Los LLMs son fuertes en generación pero débiles en garantizar corrección. Huang et al. (2024) demostraron experimentalmente que cuando los LLMs intentan autocorregir su razonamiento sin feedback externo (oracle feedback), el rendimiento puede incluso degradarse. Sin embargo, cuando existe un verificador determinista, el rendimiento se estabiliza drásticamente. lint, typecheck, test, coverage — estos se convierten en la señal de gradiente que corrige la salida del modelo.
“Se resolverá cuando los modelos sean suficientemente inteligentes” es una proposición falsa. La afirmación precisa es: “Si el feedback es suficientemente rápido, los modelos actuales ya pueden resolverlo.”
broad exploration vs local correction
La fortaleza de los LLMs no es la broad exploration — es la local correction.
“Escribe tests para este proyecto” — eso es broad exploration. El LLM pierde la dirección.
“line 41 no está cubierta” — eso es local correction. El LLM escribe un test que cubre exactamente esa línea.
Números verificados en proyectos reales:
Sin feedback: se detiene en 60–70% de cobertura
Con feedback: alcanza el 100% (para funciones alcanzables)
El mismo modelo. La simple línea “line 41 not covered” actúa como señal de gradiente. Este feedback guía las correcciones del LLM en exactamente la dirección correcta.
Symbolic Feedback Loop
Una estructura atraviesa todas estas observaciones.
El LLM genera → una herramienta determinista juzga → el resultado se devuelve al LLM → repetir
Lo llamo Symbolic Feedback Loop.
La corriente principal de la industria hoy es el LLM Feedback Loop — IA verificando IA. Es como un borracho preguntándole a un amigo borracho: “¿Estoy borracho?” Ambos son probabilísticos, así que los errores se acumulan.
El Symbolic Feedback Loop es diferente. Chen et al. (2023) demostraron que la depuración iterativa — devolver mensajes de error del compilador y de tiempo de ejecución al modelo — mejora drásticamente la precisión del código. pytest no alucina. go test nunca está borracho. La medición de cobertura no miente. La verificación de especificaciones no se desvía.
Esta estructura funciona en dominios donde la corrección puede juzgarse mecánicamente — código, tests, especificaciones, tipos. La elegancia del diseño de APIs o la naturalidad de la UX aún no pueden ser juzgadas por herramientas simbólicas. Expandir esa frontera es el siguiente desafío. Creo que existe un camino para traer incluso el lenguaje natural dentro de límites verificables.
Lo que AlphaCode (Li et al., 2022) demostró en programación competitiva sigue el mismo principio. No fue la capacidad de generación del modelo en sí, sino el diseño del entorno — generar millones de candidatos y luego filtrar mediante tests — lo que determinó el rendimiento. En lugar de hacer el modelo más inteligente, es más efectivo hacer más preciso el feedback que se le devuelve al modelo.
Delegación de decisiones
Es evidente que las decisiones no deben delegarse a la IA. Pero que los humanos verifiquen y decidan todo es agotador. Ciertas decisiones repetitivas y estructuradas pueden ser realizadas por herramientas simbólicas en nombre de los humanos.
“¿Estos tests cubren todas las ramas?” — ningún humano necesita leerlos. Una herramienta de cobertura lo juzga. “¿Este código satisface las reglas estructurales?” — ningún humano necesita revisarlo. validate lo juzga. “¿Quedan funciones sin procesar?” — ningún humano necesita contarlas. El CLI lo declara.
Las decisiones que no pueden delegarse a la IA pueden delegarse a herramientas simbólicas — porque son deterministas, no probabilísticas. Esta es la razón de existir del Symbolic Feedback Loop.
Es más importante tender las vías que hacer el tren más rápido.
Muchas personas están construyendo trenes. Casi nadie está tendiendo vías.
Referencias
- Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou. “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
- Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” arXiv:2304.05128, 2023.
- Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Remi Leblond, Tom Eccles, et al. “Competition-Level Code Generation with AlphaCode.” Science 378(6624): 1092-1097, 2022.
- Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
- Aman Madaan, Niket Tandon, Prakhar Gupta, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023.
- Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” NeurIPS 2023.
- Mert Cemri, Melissa Z. Pan, Shuyi Yang, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track.
- Carlos E. Jimenez, John Yang, Alexander Wettig, et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
Artículo relacionado: Ratchet Pattern — Cómo hacer que un agente termine el trabajo — La implementación práctica de esta teoría. Un patrón que fuerza a los agentes a converger.
Herramienta relacionada: tsma — Un ejemplo en funcionamiento del Ratchet Pattern. 527 funciones, cero TODO.
Registro de cambios
- 2026-05-14: Versión inicial