Por qué fallan los agentes de IA en backend

Los agentes de IA prometen acelerar el trabajo de backend, pero el problema no aparece en el primer intento. Aparece cuando la tarea se alarga, cuando cambian las restricciones, cuando el código necesita conectarse con algo real y cuando el agente tiene que recordar lo que ya decidió hace 20 pasos. Ahí es donde entra el concepto del paper Constraint Decay: la fragilidad de los agentes LLM para mantener restricciones consistentes mientras generan código de backend.

Si tú lideras producto, ingeniería o una startup, esta idea importa por una razón simple: no basta con preguntar si el agente “puede escribir código”. Tienes que preguntar si puede sostener decisiones técnicas bajo presión, sin romper validaciones, contratos, seguridad, consistencia de datos o performance. Y eso cambia por completo cómo evalúas una herramienta de IA antes de meterla en producción.

Qué significa Constraint Decay en la práctica

Constraint Decay describe una degradación progresiva de las restricciones que el agente debía respetar. En otras palabras, el modelo arranca bien, pero a medida que avanza la generación o la conversación, empieza a olvidar, relajar o reinterpretar límites que eran parte del problema original. En backend eso es especialmente peligroso porque una sola desviación puede romper una API, una migración o una regla de negocio.

El paper se centra en generación de código de backend, no en snippets aislados. Ese matiz importa mucho. Es una cosa pedirle a un modelo que escriba una función para validar un email y otra muy distinta pedirle que diseñe endpoints, persista datos, maneje errores, respete esquemas y no viole contratos previos. El riesgo no está solo en el código incorrecto, sino en la acumulación de pequeñas desviaciones.

El problema no es solo alucinación

Cuando hablamos de fallos de LLM, mucha gente piensa en alucinaciones. Pero Constraint Decay apunta a algo más específico: el modelo sí puede estar generando texto plausible, solo que cada paso se aleja un poco más de las restricciones originales. Es un problema de consistencia, no solo de exactitud.

Eso se ve en cosas como estas:

• Cambia nombres de campos que ya estaban definidos.
• Repite lógica en vez de reutilizar una función existente.
• Omite validaciones que antes había respetado.
• Introduce dependencias nuevas sin necesidad.
• Ajusta una parte del sistema y rompe otra.

En backend real, esos desvíos son caros. Si tú trabajas con pagos, autenticación o inventario, no te sirve que el agente “casi” respete el contrato. Necesitas cumplimiento estable.

Por qué backend es un terreno difícil

Backend no es solo escribir código. Es coordinar restricciones que viven en varias capas: base de datos, API, autenticación, permisos, latencia, observabilidad y compatibilidad hacia atrás. Cuantas más capas tocas, más fácil es que el agente degrade una de ellas sin darse cuenta.

Además, backend suele tener estado. El agente tiene que recordar decisiones previas, como nombres de tablas, formatos de respuesta, reglas de negocio o límites de rate limiting. Si esa memoria se debilita, el resultado puede pasar una revisión superficial y aun así fallar en ejecución o en producción.

Dónde se rompe un agente de IA en backend

El paper ayuda a poner nombre a fallos que los equipos ya ven en la práctica. No se trata de que el agente no sepa programar, sino de que pierde estabilidad cuando el problema crece. Eso se nota especialmente en tareas multiarchivo, flujos largos y cambios incrementales.

Una forma útil de verlo es esta: cuanto más depende tu backend de restricciones acumuladas, más probable es que un agente falle por deriva. Y no necesitas un sistema enorme para verlo. Incluso una API pequeña con autenticación, validación y persistencia ya expone el problema.

Señales típicas de degradación

Aquí tienes señales concretas que conviene vigilar en tus pruebas:

1. El agente cambia una interfaz pública sin avisar.
2. Genera código que compila, pero no respeta la lógica de negocio.
3. Repite errores de forma consistente después de una corrección.
4. Pierde contexto entre archivos o entre iteraciones.
5. Introduce soluciones más complejas de lo necesario.
6. Resuelve un bug y abre dos más en módulos vecinos.

Si ves dos o tres de estas señales en una misma sesión, no estás ante un simple error puntual. Estás ante una pérdida de control sobre restricciones.

Ejemplo realista: un endpoint de órdenes

Imagina que le pides a un agente que implemente un endpoint POST /orders. Le das estas reglas:

• Validar stock antes de crear la orden.
• Calcular impuestos según el país.
• Guardar la orden y el pago en transacción.
• Responder con un orderId y un estado inicial.
• No exponer datos internos del cliente.

En una primera pasada, el agente puede cumplir casi todo. Pero en la segunda iteración, cuando le pides agregar cupones o retries, puede empezar a mover la validación de stock a otro punto, separar la transacción por comodidad o devolver más campos de los permitidos. Cada cambio parece pequeño. El problema es que el sistema deja de ser coherente.

Qué riesgos prácticos trae a empresas y equipos

Para una empresa, el costo no es solo técnico. También afecta tiempos de QA, revisiones de seguridad, deuda de mantenimiento y confianza del equipo. Si tú adoptas agentes para acelerar backend, pero luego tu equipo pasa horas corrigiendo inconsistencias, la ganancia desaparece rápido.

El impacto varía según el tipo de sistema, pero hay patrones claros. En productos con alta regulación o con dinero de por medio, el costo de una desviación es mucho mayor. En sistemas internos, el riesgo suele ser menos visible, pero igual se acumula en forma de bugs, refactors y tickets repetidos.

Tabla de riesgos por escenario

La tabla no dice que la IA no sirva. Dice que el nivel de control que necesitas cambia según el riesgo del dominio. No evalúes un agente de backend como si fuera un autocompletado más rápido.

Costos ocultos que casi nadie calcula

Hay tres costos que suelen subestimarse:

• Tiempo de revisión: si el agente produce mucho código, pero con baja consistencia, tu PR review se vuelve más larga.
• Tiempo de debugging: los fallos por deriva suelen ser difíciles de rastrear porque el código parece razonable.
• Costo de confianza: cuando el equipo deja de confiar en la herramienta, la adopción cae aunque el demo haya sido bueno.

En equipos pequeños de Latinoamérica esto pega más fuerte porque el tiempo de ingeniería es limitado. Si un agente ahorra 20 minutos pero agrega una hora de revisión, no estás ganando productividad. Estás moviendo trabajo de un lugar a otro.

Cómo evaluar agentes de IA sin caer en demos engañosas

La mayoría de demos de IA muestran una sola tarea. Eso sirve para enseñar capacidad, pero no para medir estabilidad. Si tú quieres saber si un agente sirve para backend real, necesitas pruebas que midan consistencia a lo largo del tiempo y bajo cambios de contexto.

La evaluación debería parecerse más a una batería de pruebas de software que a una conversación con el modelo. El objetivo no es ver si puede acertar una vez, sino si mantiene restricciones cuando le pides iterar, corregir y extender.

Métricas que sí te conviene mirar

No hace falta inventar una suite académica para empezar. Puedes usar métricas prácticas como estas:

• Tasa de cumplimiento de restricciones: cuántas reglas respeta sin intervención.
• Tasa de regresión: cuántas reglas rompe después de una corrección.
• Estabilidad entre iteraciones: cuánto cambia el diseño base a lo largo de 3 o 5 rondas.
• Necesidad de edición humana: cuánto código debes tocar antes de mergear.
• Cobertura de tests útiles: si el agente genera pruebas que realmente capturan el comportamiento.

Si quieres profundizar en cómo medir calidad de software generado por IA, también te puede servir revisar nuestro enfoque sobre evaluación de código con IA y pruebas automatizadas en backend.

Un protocolo simple de evaluación

Puedes probar un agente con un flujo de trabajo de 4 pasos:

1. Dale un backend pequeño con 3 restricciones duras y 2 blandas.
2. Pídele implementar la primera versión.
3. Cambia una restricción a mitad de camino, por ejemplo un nuevo campo o una regla de negocio.
4. Observa si mantiene lo anterior sin romperlo.

Luego repite la prueba con el mismo prompt base, pero en una sesión nueva. Si el resultado varía demasiado, tienes un problema de estabilidad. Si además el agente no puede explicar qué cambió y por qué, la supervisión humana se vuelve obligatoria.

Qué pedirle a un vendor o a una herramienta interna

Antes de adoptar una herramienta, pide evidencia concreta, no solo capturas bonitas. Pregunta por:

• Casos de uso de backend similares al tuyo.
• Cómo manejan memoria de contexto y restricciones.
• Qué pasa cuando el código necesita tocar varios archivos.
• Cómo miden regresiones entre iteraciones.
• Qué porcentaje de output requiere corrección humana.

Si la respuesta es vaga, desconfía. Un agente que falla en mantener restricciones no se arregla con más entusiasmo comercial.

Qué puedes hacer para reducir el riesgo

La buena noticia es que no tienes que abandonar los agentes. Tienes que ponerles barandas. La estrategia correcta no es confiar ciegamente, sino diseñar el flujo para que el agente trabaje dentro de límites verificables.

El paper deja una lección útil: las restricciones no deben vivir solo en el prompt. Deben estar también en tests, contratos, validadores y revisiones automáticas. Si una regla solo existe en lenguaje natural, el agente la va a degradar antes de que tú te des cuenta.

Guardrails que sí ayudan

Usa estas capas, en este orden:

• Esquemas explícitos para input y output.
• Tests unitarios e integración antes de merge.
• Linting y type checking.
• Contratos entre servicios.
• Revisión humana en cambios sensibles.

Esto no elimina el problema, pero reduce el espacio donde el agente puede desviarse. Para backend, esa reducción vale más que una generación más rápida.

Cómo escribir mejores tareas para el agente

Tus prompts también importan. En vez de pedir “haz el backend completo”, divide el trabajo en partes verificables. Por ejemplo:

// Ejemplo de tarea más controlada para un agente
interface CreateOrderInput {
  userId: string;
  items: Array<{ sku: string; quantity: number }>;
  country: string;
}

// Restricciones:
// 1. No cambiar el contrato de respuesta.
// 2. No tocar el esquema de users.
// 3. Mantener la transacción en un solo servicio.
// 4. Agregar tests para stock insuficiente y payload inválido.

Ese tipo de especificación reduce ambigüedad. No es magia, pero sí obliga al agente a trabajar con límites más claros.

Cuándo sí conviene usar agentes

Hay tareas donde la IA aporta bastante valor:

• Scaffolding inicial de endpoints.
• Escritura de tests repetitivos.
• Conversión de DTOs o mapeos sencillos.
• Refactors mecánicos con buena cobertura.
• Documentación técnica de módulos existentes.

En cambio, deberías tener más cuidado en:

• Lógica de permisos.
• Flujos de pago.
• Migraciones con impacto en producción.
• Código que depende de estado distribuido.
• Cambios que afectan múltiples servicios a la vez.

Tabla resumen

Si tú tienes que decidir si usar agentes de IA en backend, la pregunta correcta no es “¿pueden generar código?”. La pregunta es “¿pueden sostener restricciones mientras el sistema cambia?”. Ahí está el valor real del paper y también su advertencia más útil para equipos de producto y desarrollo.