¿Se resolverá todo cuando los modelos sean más inteligentes?
La narrativa dominante sobre las herramientas de codificación con AI es esta: cuando el modelo sea lo suficientemente bueno, escribirá código, escribirá tests y refactorizará por su cuenta. Lo que GPT-4 no pudo, GPT-5 lo hará. Si Claude no alcanza, un Claude más grande lo logrará.
¿Es realmente así?
Le encargué a Claude Opus 4.7 una refactorización de filefunc. La completó en una hora sin revisión humana. validate pasó, pytest pasó, coverage se mantuvo. A primera vista, encaja con la narrativa de “basta con un modelo mejor.”
Pero ¿qué pasa si al mismo modelo le das la misma refactorización sin las reglas de filefunc? ¿Sin validate? ¿Sin retroalimentación de coverage? El resultado es completamente distinto. Cae en un doom loop: corrige un bug y rompe otro lugar, corrige ese y 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 autónomo en un proyecto con 527 funciones. “Escribe tests para cada función.” El agente terminó e informó: “Hecho.”
Funciones que realmente recibieron tests: 40. 40 de 527.
El agente no mintió. Hizo 40 y decidió que “era suficiente.” La disposición por defecto de un LLM es la terminación prematura optimista. Al encontrar una función difícil la salta, hace algunas más y 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 "hecho"
CLI loop: 527 / 527 (100%) — la máquina declara "quedan 487"
El mismo modelo. El mismo proyecto. La diferencia es quién decide cuándo se ha “terminado.”
El entorno define al modelo
Ambos experimentos apuntan a la misma conclusión. Opus 4.7 no terminó porque fuera inteligente. Terminó porque la specification surface era machine-checkable.
filefunc validate → ¿La estructura del código satisface las reglas?
pytest → ¿Se preserva el comportamiento existente?
coverage → ¿Qué ramas faltan?
Estos tres dieron retroalimentación inmediata en cada edición. El modelo recibió la retroalimentación, corrigió, recibió retroalimentación de nuevo, corrigió de nuevo. Un self-correcting loop.
Aquí está la clave:
La topología de retroalimentación determina los resultados más que el IQ del modelo.
Los LLM son fuertes generando pero débiles garantizando correctness. Sin embargo, cuando hay un deterministic verifier presente, el rendimiento se estabiliza drásticamente. lint, typecheck, test, coverage — se convierten en el gradient signal que corrige la salida del modelo.
“Se resolverá cuando los modelos sean lo bastante inteligentes” es una proposición falsa. La formulación correcta es: “Si la retroalimentación es lo suficientemente rápida, los modelos actuales ya pueden resolverlo.”
broad exploration vs local correction
La fortaleza de los LLM no es el broad exploration, sino el local correction.
“Escribe tests para este proyecto” — eso es broad exploration. El LLM pierde el rumbo.
“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 retroalimentación: se estanca en 60–70% de coverage
Con retroalimentación: alcanza 100% (para funciones alcanzables)
El mismo modelo. La sola línea “line 41 not covered” actúa como gradient signal. Esta retroalimentación dirige las correcciones del LLM en exactamente la dirección correcta.
Symbolic Feedback Loop
Una estructura atraviesa todas estas observaciones.
LLM genera → herramienta determinista juzga → resultado devuelto al LLM → repetir
La llamo Symbolic Feedback Loop.
La corriente principal de la industria hoy es el LLM Feedback Loop — AI verificando AI. 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. pytest no alucina. go test nunca está borracho. La medición de coverage no miente. La verificación de especificaciones no deriva.
Esta estructura funciona en dominios donde la correctness puede juzgarse mecánicamente — código, tests, especificaciones, tipos. La elegancia del diseño de una API o la naturalidad de una UX aún no pueden ser juzgadas por herramientas simbólicas. Expandir esa frontera es el próximo desafío. Creo que existe un camino para traer incluso el lenguaje natural dentro de los límites verificables.
En lugar de hacer al modelo más inteligente, es más efectivo hacer más precisa la retroalimentación que se le devuelve al modelo.
Delegar decisiones
Es evidente que las decisiones no deben delegarse a la AI. Pero que los humanos verifiquen y decidan todo es agotador. Ciertas decisiones repetitivas y estructuradas pueden ser ejecutadas por herramientas simbólicas en nombre de los humanos.
“¿Estos tests cubren todas las ramas?” — ningún humano necesita leerlos. Una herramienta de coverage 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 AI sí 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.
Mucha gente está construyendo trenes. Casi nadie está tendiendo vías.