Constraint Decay: por qué los agentes IA fallan en código

Constraint decay en agentes IA es el fenómeno por el cual un agente LLM pierde progresivamente la capacidad de respetar restricciones estructurales predefinidas a medida que aumenta la complejidad de una tarea de generación de código. Según el paper publicado en arXiv en mayo de 2026, las tasas de aprobación caen hasta 30 puntos porcentuales cuando se agregan restricciones arquitectónicas reales sobre frameworks web como Django o FastAPI.

¿Qué es Constraint Decay en agentes IA?

Constraint decay en agentes IA es el deterioro progresivo en la capacidad de un modelo de lenguaje para mantener coherencia con restricciones estructurales a lo largo de una tarea de generación de código compleja. No es un fallo puntual: es una degradación acumulativa.

Ponele que tenés un agente al que le das estas instrucciones: “generá un endpoint de creación de usuarios usando Django REST Framework, con autenticación basada en tokens, siguiendo el patrón repositorio para la capa de datos y validaciones en el serializer, no en la vista”. El agente arranca bien, genera la vista, el serializer. Pero a medida que el código crece y las instrucciones se acumulan en el contexto, las restricciones anteriores empiezan a “evaporarse”. El modelo empieza a meter lógica de negocio en la vista, a hacer queries directamente en el endpoint, a saltarse el patrón repositorio. No con intención: simplemente porque mantener todas esas restricciones activas en un contexto largo degrada la atención sobre ellas.

El estudio que documentó este fenómeno usó un benchmark específico: 80 tareas de proyectos greenfield y 20 de implementación de features sobre 8 frameworks web distintos. La metodología comparó el rendimiento del agente con y sin restricciones arquitectónicas explícitas. La caída de hasta 30 puntos en tasa de aprobación no es un outlier: es el comportamiento esperado del sistema bajo presión estructural.

Por qué los agentes LLM no pueden manejar restricciones complejas

La mecánica detrás del problema tiene que ver con cómo los transformers manejan el contexto. A medida que el prompt crece (instrucciones iniciales, código generado, historial de herramientas usadas), la atención del modelo se distribuye entre más tokens. Las restricciones declaradas al principio del contexto compiten con todo lo que vino después.

Hay una diferencia estructural entre tareas “shallow” y tareas de producción. Una tarea shallow es “escribí una función que dado un array de enteros, devuelva el máximo”. Restricción mínima, contexto acotado, el modelo brilla. Una tarea de producción es otra cosa: patrones arquitectónicos, ORM con convenciones específicas, separación de capas, manejo de errores según estándar del proyecto, tests con fixtures. Cada requisito adicional no solo suma complejidad: activa lo que el estudio llama reasoning degradation (degradación del razonamiento sobre el conjunto de restricciones activas).

¿Y qué pasó cuando los investigadores probaron esto con tareas reales de producción? Lo que te imaginás: el agente generaba código que compilaba, pasaba checks sintácticos, pero fallaba en verificación de comportamiento porque había violado alguna de las restricciones estructurales silenciosamente. Sin error, sin excepción. El agente ni se enteró.

Análisis por framework: Flask vs Django vs FastAPI

Uno de los datos más interesantes del paper es la diferencia de rendimiento según el framework. No todos los entornos hacen sufrir igual a los agentes.

Framework	Tipo	Rendimiento relativo	Principal dificultad
Flask	Minimalista	Alto	Pocas convenciones predefinidas
FastAPI	Moderno/tipado	Medio-bajo	Dependencias, tipado estricto, async
Django	Batteries-included	Bajo	ORM, admin, convenciones MTV pesadas
Django REST Framework	DRF sobre Django	Bajo	Serializers, viewsets, router conventions

La lógica es simple: Flask es minimalista por diseño. Si el agente no sabe cómo organizar el proyecto, puede improvisar sin romper demasiado. No hay un ORM con sus propias restricciones de query, no hay patrones de vista dictados por el framework. El agente tiene más margen. Esto se conecta con lo que analizamos en protecciones de seguridad en sistemas críticos.

Django es el extremo opuesto. Tiene convenciones para casi todo: cómo nombrás los modelos, cómo escribís las migraciones, cómo estructurás las apps, cómo usás el ORM. Cada convención violada es un fallo potencial. El agente que no mantiene todas esas restricciones activas en el contexto genera código que parece Django pero no lo es.

FastAPI es interesante porque su tipado estricto y el uso de Pydantic agregan una capa extra de restricciones. El modelo tiene que mantener coherencia de tipos a través de schemas, rutas y handlers. Con un contexto largo, esa coherencia se fragmenta.

Errores en la capa de datos: el talón de Aquiles

Subís el modelo, le das las instrucciones del proyecto, definís los modelos de datos, arranca bien. Y en algún punto del workflow, el agente empieza a generar queries que violan las relaciones definidas. Una ForeignKey que se filtra como si fuera un campo directo. Un ManyToMany que se accede con sintaxis de OneToOne. Un `select_related` donde debería ir `prefetch_related`, generando N+1 queries que en producción van a destruir la base.

Según el paper, los defectos más comunes en la capa de datos incluyen composición incorrecta de queries ORM, violaciones de runtime (acceder a atributos que no existen en el ORM según las relaciones definidas) y errores en la gestión de transacciones. Con SQLAlchemy, el patrón es similar: el agente pierde el hilo de la session management, mezcla contextos de sesión, genera código que funciona en tests simples pero falla con concurrencia real.

Lo que hace especialmente complicado este tipo de error es que no siempre levanta una excepción inmediata. Un query mal construido puede ejecutarse, devolver datos incorrectos y pasar tests unitarios que no verifican el comportamiento completo. La verificación estática no alcanza: necesitás tests de integración que prueben la capa de datos contra una base real (esto aplica también si montás el proyecto en un servidor; con donweb.com podés levantar entornos de staging con bases PostgreSQL reales para justamente este tipo de validación).

Cómo se degrada el rendimiento bajo presión estructural

El estudio distingue entre dos tipos de verificación: behavioral verification (el código hace lo que tiene que hacer, incluyendo edge cases y comportamiento con datos reales) y static verification (el código está bien formado sintácticamente, los imports están, los tipos coinciden). Los agentes actuales pasan static verification con bastante consistencia. El problema es la behavioral verification bajo restricciones.

La degradación no es lineal. El paper describe una sensibilidad acumulativa: las primeras dos o tres restricciones el agente las mantiene razonablemente bien. A partir de ahí, agregar una nueva restricción no solo activa ese requisito nuevo: desestabiliza los anteriores. Es como si el modelo tuviera un “presupuesto de atención” para restricciones y, una vez agotado, empieza a dropear las más antiguas del contexto activo.

Lo más problemático es que el agente falla de forma silenciosa. No dice “no puedo manejar tantas restricciones”. Genera código, lo presenta con confianza, y el error solo aparece cuando alguien (o algo) verifica el comportamiento. Sin verificador externo, el equipo puede asumir que el código está correcto. Ya lo cubrimos antes en capacidades de ChatGPT en código.

Mejores prácticas para usar agentes IA en código de producción

A partir de lo que muestra el paper y de lo que ya sabemos en la práctica, hay algunas cosas concretas que cambian el resultado.

Validación dual: tests + verificadores estáticos

No alcanza con correr el linter. Los verificadores estáticos (mypy, pylint, bandit para seguridad) atrapan una clase de errores, pero el constraint decay genera errores semánticos que pasan el análisis estático. Necesitás tests que verifiquen el comportamiento real: que el endpoint respeta el patrón arquitectónico, que el ORM no genera N+1, que las relaciones se usan correctamente.

Descomposición de tareas

En vez de darle al agente una tarea grande con 8 restricciones, partila en tareas con 2-3 restricciones cada una. El agente genera, vos validás, y recién ahí avanzás con el contexto ya verificado. Más lento, sí. Pero el código resultante es distinto.

Especificación explícita de restricciones en cada prompt

Las restricciones declaradas al inicio del conversation se diluyen. Reintroducillas en cada paso crítico. Si estás generando la capa de datos, el prompt tiene que incluir explícitamente “usá el patrón repositorio, no hagas queries directas desde el endpoint, usá select_related para relaciones 1-N”. No como recordatorio: como instrucción activa en ese turno.

Revisión humana no negociable para código de datos

La capa de datos es donde se concentran los errores más costosos. Un bug en la vista es generalmente visible rápido. Un bug en el ORM puede vivir meses en producción, degradando performance silenciosamente o retornando datos incorrectos que nadie detecta hasta que hay un incidente. La revisión humana en esta capa no es opcional.

Implicaciones para el futuro de la automatización de código

Hay una brecha real entre prototipado rápido y software de producción. Los agentes actuales son buenos para el primero. Para el segundo, tienen limitaciones estructurales que no se resuelven solo con un modelo más grande.

El paper proyecta que más del 40% de los proyectos con automatización agéntica van a experimentar fallos significativos en producción relacionados con constraint decay, salvo que incorporen verificadores estáticos automatizados en el pipeline. No es una advertencia vaga: es una proyección basada en los datos del benchmark. Para más detalles técnicos, mirá razonamiento en modelos de lenguaje.

La investigación futura apunta a dos líneas: constrained decoding (forzar al modelo a generar solo dentro de un espacio de tokens válidos según las restricciones) y arquitecturas de razonamiento que mantengan un “estado de restricciones activas” separado del contexto de generación. Nada de esto está disponible en producción todavía.

¿Eso significa que los agentes IA en código backend son inútiles? No. Significa que la narrativa de “el agente reemplaza al desarrollador en proyectos reales” está adelantada varios años respecto de lo que los benchmarks muestran.

Errores comunes al usar agentes IA para código backend

Asumir que el código generado respeta las restricciones porque no dio error

Un agente puede generar código Python válido que viola todas las restricciones arquitectónicas del proyecto. La ausencia de error de sintaxis no es validación de comportamiento. Necesitás tests específicos que verifiquen el cumplimiento de cada restricción estructural.

Dar todas las restricciones al inicio y no reinsertalas

Las restricciones en el turno 1 de la conversación se degradan con cada turno adicional. Si usás un agente multi-step, reinsertá las restricciones críticas en los prompts de cada paso donde sean relevantes. No como recordatorio educado: como instrucción explícita.

Usar el mismo agente para greenfield y para features sobre código existente

El paper distingue entre estos dos tipos de tareas porque el perfil de error es distinto. En un proyecto greenfield, el agente puede imponer su propio patrón. En features sobre código existente, tiene que inferir y respetar el patrón ya establecido, lo que agrega una capa de restricciones implícitas que el agente raramente detecta por completo. Los resultados del benchmark son peores para feature implementation que para greenfield.

Confiar en frameworks con muchas convenciones sin documentarlas explícitamente

Si usás Django, el agente “sabe” Django en general, pero no sabe cómo tu proyecto específico usa Django. Las convenciones locales (cómo organizás los managers, cómo nombrás los serializers, qué campos ponés en abstract models) hay que especificarlas. El agente no las infiere del contexto de forma confiable.

Preguntas Frecuentes

¿Qué es constraint decay en agentes IA?

Constraint decay es la degradación progresiva de la capacidad de un agente LLM para respetar restricciones estructurales predefinidas a medida que crece la complejidad del contexto. Un estudio de mayo de 2026 documentó caídas de hasta 30 puntos porcentuales en tasa de aprobación al agregar restricciones arquitectónicas reales sobre frameworks web. Lo explicamos a fondo en soluciones de Google para IA.

¿Por qué los agentes LLM fallan con código backend complejo?

La atención del modelo se distribuye entre más tokens a medida que el contexto crece, lo que reduce la “presión de atención” sobre restricciones declaradas temprano en el contexto. Los agentes generan código sintácticamente válido que viola restricciones arquitectónicas sin emitir ninguna señal de error, lo que hace el fallo silencioso y difícil de detectar sin verificadores externos.

¿Cuál es la diferencia entre agentes IA en Django versus Flask?

Flask es minimalista y tiene pocas convenciones predefinidas, lo que le da al agente más margen para improvisar sin violar restricciones del framework. Django tiene convenciones para casi todo (ORM, estructura de apps, patrones de vista), y cada convención adicional es un vector de fallo. El benchmark del estudio mostró que los agentes rinden mejor en frameworks minimalistas.

¿Qué errores comete un agente IA al generar código con arquitectura predefinida?

Los errores se concentran en la capa de datos: queries ORM mal compuestas, violaciones de runtime al acceder a atributos según relaciones incorrectamente inferidas, problemas de gestión de sesiones con SQLAlchemy, y lógica de negocio mezclada en capas equivocadas. Estos errores pasan la verificación estática pero fallan en tests de comportamiento con datos reales.

¿Cómo afectan las restricciones al rendimiento de modelos de lenguaje en generación de código?

Las restricciones no se acumulan linealmente en dificultad: agregar una nueva restricción puede desestabilizar el cumplimiento de las anteriores. El fenómeno es especialmente marcado en tareas de feature implementation sobre código existente, donde el agente tiene que inferir y respetar convenciones implícitas del proyecto además de las restricciones explícitas del prompt.

Conclusión

El paper sobre constraint decay pone números a algo que cualquier equipo que haya usado agentes en código de producción ya intuía: los agentes fallan de forma no obvia, generando código que parece correcto pero viola las restricciones estructurales del proyecto. La caída de 30 puntos en tasa de aprobación no es un dato menor.

Lo que cambia con este estudio es que ahora hay evidencia empírica para justificar prácticas que muchos equipos ya aplican por intuición: descomposición de tareas, reinserción de restricciones en cada paso, validación dual con tests de comportamiento. Si tu equipo está evaluando cuánto automatizar con agentes, este benchmark es un insumo concreto para calibrar expectativas y decidir dónde poner la revisión humana.

La brecha entre “el agente puede generar código” y “el agente puede generar software de producción que respete una arquitectura real” sigue siendo grande. Eso no hace inútil la herramienta. Hace necesario entender dónde aplica y dónde no.

Fuentes

• arXiv 2605.06445 — Constraint Decay: The Fragility of LLM Agents in Back End Code Generation (paper original)
• arXiv HTML — versión completa del paper con tablas y resultados por framework
• PlanetaChatbot — Colapso backend: agentes de IA como nueva capa lógica
• Xataka — IA permitió que los desarrolladores programen rápido; ahí está el problema