Image: AI generated
El mismo modelo. El que alucinaba en el chat web entrega una función de 200 líneas en Claude Code de un solo tiro. El /goal de Codex resuelve un issue completo. El modelo no se volvió repentinamente más inteligente. Lo que cambió es la estructura.
Por qué funcionan
El bucle en la IA conversacional es así:
LLM → humano → LLM → humano
Todo el feedback es lenguaje natural. Generación probabilística seguida de evaluación probabilística. La precisión se degrada como un producto.
El bucle en los agentes de código es diferente:
LLM → generación de código → guardar archivo → ejecutar test → pass/fail → LLM
LLM → edición de código → build → éxito/fallo → LLM
LLM → type check → mensaje de error → LLM
Hay puertas deterministas dentro del bucle. El sistema de archivos guarda exactamente lo que se escribió. Un test es pass o fail. El compilador dice que está mal cuando está mal. Estos inadvertidamente sirven como ratchets.
Un LLM es un componente no fiable. Pero construir un protocolo fiable sobre componentes no fiables es un fundamento de la ingeniería. Von Neumann demostró matemáticamente en 1956 que solo con votación por mayoría, componentes ruidosos pueden realizar cálculos fiables (Von Neumann, 1956). TCP construye entrega fiable sobre una red no fiable. RAID construye almacenamiento fiable sobre discos no fiables. ECC construye computación fiable sobre memoria no fiable.
La razón por la que los agentes de código funcionan es la misma. Un LLM no fiable se complementa con verificadores deterministas (tests, builds, linters, type checkers). El estudio SWE-agent demostró que incluso el mismo modelo muestra rendimiento drásticamente diferente según el diseño del Agent-Computer Interface (Yang et al., NeurIPS 2024). Es la topología, no la capacidad del modelo, lo que causa el éxito.
Pero ¿por qué colapsan?
Funcionan, dije. Pero a veces colapsan. ¿Por qué?
Porque los ratchets que están presentes por casualidad y los ratchets diseñados conscientemente son cosas diferentes.
Existen zonas sin ratchet
¿Cuando un agente edita código sin tests? El build pasa, lint pasa, pero la funcionalidad está rota. En zonas sin puertas deterministas, el LLM juzga probabilísticamente, y los juicios probabilísticos se degradan como producto.
De 200 endpoints, 180 tienen tests y 20 no. El agente maneja 180 perfectamente y planta bugs silenciosamente en los 20. Por eso obtienes “casi listo, pero algo anda mal.”
La información del feedback es insuficiente
Hice un experimento de ordenación con 1.000 palabras. CPU: 0,08ms al 100%. LLM: 438 segundos al 97,7%. Eso ya es notable — 97,7% mediante cognición pura. Pero el verdadero descubrimiento estaba en otro lugar.
Varié solo el nivel de feedback sobre el mismo resultado:
| Feedback | Resultado |
|---|---|
| Ninguno | 6 errores (99,4%) |
| “Hay errores” | 10 errores (99,0%) — peor |
| “Hay 23 errores” | 1 error (99,9%) |
| “6 errores, aquí están” | 0 errores (100%) |
Decirle solo “estás equivocado” causa sobre-corrección y empeora las cosas. Darle un conteo crea un objetivo hacia el cual perseguir. Darle ubicaciones logra la perfección.
La mayoría de los agentes hoy operan en el segundo nivel. Cuando un test falla, saben “algo está mal”, pero no transmiten la razón estructural. Los mensajes de error existen, pero son síntomas, no causas.
Los puntos ciegos existen y la repetición no los arregla
En el experimento de ordenación, el LLM dejó 6 errores en R2. En R3, reportó “sin errores.” En R4b, reportó de nuevo “sin errores.” Pasó por alto los mismos 6 de la misma manera.
Sin pistas, no importa cuántas repeticiones, convergió en 99,4%. Solo cuando se le dijo “quedan 6” finalmente alcanzó el 100%.
Lo mismo ocurre con los agentes de código. El agente crea un bug, se auto-revisa con “se ve bien”, y cuando se le dice que lo arregle de nuevo, pasa por alto el mismo punto. Huang et al. (2024) mostraron que sin feedback externo, la autocorrección de errores de razonamiento por LLMs en realidad degrada el rendimiento (Huang et al., ICLR 2024). Por eso retry no es la respuesta. Los puntos ciegos son una limitación estructural de la naturaleza probabilística del modelo, no falta de esfuerzo.
La multiplicación funciona a escala
97,7% de precisión encadenada dos veces: 0,977² = 95,4%. Tres veces: 93,2%. Diez veces: 79,2%.
Un agente editando un solo archivo lo hace bien. ¿Pero pedirle refactorizar 100 archivos? Incluso al 97% por paso, 100 pasos dan 0,97¹⁰⁰ = 4,8%. El fracaso está virtualmente garantizado.
Esta es la explicación matemática de “vibe coding colapsa en 200 endpoints.” En proyectos pequeños, el número de encadenamientos es bajo para que la probabilidad aguante. En proyectos grandes, la multiplicación se vuelve catastrófica.
¿Qué se necesita?
Las razones para funcionar y las razones para colapsar apuntan al mismo lugar: la presencia o ausencia de puertas de verificación determinista.
Los agentes actuales dependen de ratchets que están presentes por casualidad (tests, builds, linters). Diseñarlos conscientemente los hace más fuertes.
Lo que significa diseñar ratchets conscientemente:
Primero, identificar zonas sin ratchet. Código sin tests, APIs sin schemas, datos sin tipos. Todo lugar donde el agente juzga probabilísticamente es una vulnerabilidad.
Segundo, aumentar el contenido informativo del feedback. Devolver solo pass/fail induce sobre-corrección. “Dónde, por qué y cómo lo real difiere de lo esperado” debe entregarse de forma estructurada.
Tercero, insertar puertas deterministas entre pasos de encadenamiento. Ejecutar 10 pasos de una vez hace la multiplicación catastrófica, pero bloquear con un ratchet en cada paso resetea la degradación.
Los LLMs son generadores notables. Ordenan 1.000 palabras al 97,7% de precisión mediante cognición pura. Los humanos no pueden hacer esto. Pero cualquier cosa menos del 100% colapsa bajo la repetición. 0,977 al cuadrado es 0,954.
Los agentes de código funcionan no porque el modelo sea inteligente. Funcionan porque hay puertas deterministas dentro del bucle. Colapsan porque esas puertas faltan.
La generación puede ser probabilística. La verificación debe ser determinista.
Artículos relacionados
- Ratchet Pattern — Cómo hacer que un agente termine el trabajo — La estructura y principios del patrón ratchet
- La topología del feedback importa más que el IQ del modelo — Por qué la estructura de feedback importa más que la capacidad del modelo
- Las restricciones son contratos — Cómo las restricciones racionales liberan los sistemas
- filefunc — Un archivo, un concepto — Estructura de código nativa para LLM
- Pensamiento AI: 5 pasos para romper premisas con primeros principios — Cómo pensar con IA
Referencias
- Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” In Shannon, C.E. & McCarthy, J. (Eds.), Automata Studies, Annals of Mathematical Studies, No. 34, Princeton University Press, pp. 43-98.
- Saltzer, J.H., Reed, D.P., & Clark, D.D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems, 2(4), 277-288.
- Patterson, D.A., Gibson, G., & Katz, R.H. (1988). “A Case for Redundant Arrays of Inexpensive Disks (RAID).” Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, pp. 109-116.
- Hamming, R.W. (1950). “Error Detecting and Error Correcting Codes.” The Bell System Technical Journal, 29(2), 147-160.
- Yao, S. et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.
- Shinn, N. et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
- Jimenez, C.E. et al. (2024). “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
- Yang, J. et al. (2024). “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” NeurIPS 2024.
- Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
- Kamoi, R. et al. (2024). “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs.” TACL, 12, 1298-1318.
- Cemri, M. et al. (2025). “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657.
- Arbuzov, M.L., Shvets, A.A., & Beir, S. (2025). “Beyond Exponential Decay: Rethinking Error Accumulation in Large Language Models.” arXiv:2505.24187.
Registro de cambios
- 2026-05-16: Versión inicial