Deuda técnica en IA generativa: RAG, agentes y código generado

En muchos sistemas de inteligencia artificial (IA) en producción, el código del modelo no era la parte más costosa. La deuda se acumulaba alrededor: datos, dependencias, configuración, procesos de entrenamiento, consumidores y monitorización. La IA generativa no ha corregido ese problema. Ha añadido colecciones documentales, o corpus, índices, instrucciones para el modelo, o prompts, proveedores externos y agentes capaces de elegir pasos o usar herramientas. También produce código a una velocidad que puede superar el tiempo y la atención disponibles para entenderlo.

La conclusión práctica es incómoda: cambiar de modelo, mejorar la búsqueda o adoptar un flujo dirigido por especificaciones puede reducir una deuda y crear otra. Un sistema mantenible responde cuatro preguntas: qué cambió, qué depende de ello, cómo se comprueba y cómo se revierte o repara.

Una señal de deuda grave es que el equipo ya no pueda atribuir, comprobar o revertir un cambio del sistema.

Este artículo parte de un diagnóstico publicado en 2015 para construir un marco actual. El paper aporta el antecedente y el vocabulario. El objeto del análisis son los sistemas de IA generativa: la generación aumentada por recuperación (RAG), que busca información externa antes de responder; los agentes, que pueden encadenar decisiones o acciones; el código generado; y el desarrollo dirigido por especificaciones (Spec-Driven Development, SDD), que define comportamiento, límites y criterios de aceptación antes de implementar.

La deuda invisible no nació con los modelos de lenguaje

El antecedente más útil para entender el problema es Hidden Technical Debt in Machine Learning Systems. Sculley y otros investigadores de Google lo publicaron en 2015. Su imagen más recordada mostraba el código de aprendizaje automático (Machine Learning, ML) como una caja pequeña dentro de un sistema mucho mayor. Lo decisivo era el cambio de unidad de análisis: un modelo preciso puede formar parte de un producto frágil, caro de modificar e imposible de explicar.

El trabajo describía deudas que una interfaz de código no revela. Un dato puede conservar su tipo y perder su significado; una predicción puede cambiar el comportamiento de los usuarios y, con él, los datos futuros. El principio CACE, «si cambia algo, cambia todo» (Changing Anything Changes Everything), resume ese acoplamiento: modificar una variable, el muestreo o el filtrado puede alterar el comportamiento del sistema completo. El diagnóstico puede condensarse en este mapa:

Dos criterios del paper siguen siendo especialmente prácticos. Una capa de corrección puede resolver un fallo y convertirlo, a la vez, en dependencia de la siguiente capa. Y una señal marginal puede exigir permisos, validaciones y monitorización durante años. Por eso cada dependencia debería superar una prueba de eliminación: qué métricas empeoran al retirarla y qué complejidad desaparece.

El paper también identificaba una deuda cultural. Aparece cuando los incentivos premian añadir variables y mejorar métricas, mientras que retirar funciones, ganar reproducibilidad, estabilizar la operación o ampliar la monitorización reciben menos reconocimiento. En IA generativa reaparece si se cuenta el volumen producido y se omite el trabajo de revisión y retirada. Ningún registro de deuda compensa que el equipo carezca de tiempo o autoridad para eliminar una dependencia.

El tiempo completa el diagnóstico. La distribución de los datos y la relación entre señales y resultados cambian: es la deriva de datos y de concepto. Las predicciones alteran las señales que el sistema observará después, y vigilar el procesador, la memoria o los errores del servidor no detecta que una señal ha perdido su significado. Los trabajos posteriores convirtieron parte de aquel diagnóstico en pruebas sobre datos, modelos, infraestructura y monitorización. La enseñanza que interesa aquí es anterior a cualquier herramienta para operar modelos: la deuda de IA es deuda de sistema.

Qué cambia con la IA generativa

La IA generativa conserva aquellas deudas y amplía su radio. No inventa los principios de operación fiable; concentra más componentes cuyo comportamiento es probabilístico. También hace habitual que una salida textual proponga consultas, planes o acciones que el sistema debe validar y autorizar antes de ejecutar. Cuando el modelo se consume como servicio gestionado, el sistema incorpora una dependencia externa: el proveedor puede cambiar la versión, el precio, la latencia, la ventana de entrada o el comportamiento. El sistema añade instrucciones, ejemplos, políticas, recuperadores, herramientas y verificadores.

También cambia la relación entre producción y revisión. La IA puede reducir el coste marginal de proponer otra implementación, otro conector o una variante de prompt; sigue siendo necesario comprenderla, compararla, integrarla, asegurarla y mantenerla. Cuando generar otra versión tarda menos que revisarla con garantías, el cuello de botella pasa a la aceptación del cambio. Este desfase facilita acumular deuda antes de que el equipo reconozca que ha aumentado el número de activos bajo su responsabilidad.

En la práctica, la IA amplifica las fortalezas y las debilidades del sistema de entrega. Preguntar si «aumenta la productividad» en abstracto oculta esa diferencia. Un equipo con contratos, pruebas, revisión y facilidad de reversión puede convertir la generación rápida en ciclos de aprendizaje más cortos. Sin esos controles, la mayor velocidad amplifica la incertidumbre y traslada más trabajo a la revisión.

En la práctica, trataría como activos versionados al menos estos elementos:

• modelo y proveedor, con fecha y parámetros efectivos;
• instrucciones de sistema, plantillas y políticas;
• corpus, parser, estrategia de segmentación, modelo de embeddings e índice;
• herramientas disponibles para cada agente, permisos y límites de acción;
• conjuntos de evaluación, jueces, umbrales y reglas de abstención;
• trazas necesarias para atribuir una respuesta sin conservar datos de más;
• especificaciones, código, dependencias y decisiones arquitectónicas.

Versionar ayuda a reconstruir una decisión durante la vida operativa del sistema. El sistema que conserva la traza debe aplicar un control de acceso específico y conservarla solo durante el plazo necesario; cuando proceda, la supresión debe propagarse desde el sistema fuente conforme a los principios y derechos del Reglamento General de Protección de Datos (RGPD).

También probaría la sustitución de cada proveedor externo. Para modelos o reordenadores sin estado, ejecutaría una muestra versionada por una ruta alternativa o degradada. Compararía sus resultados con la ruta principal en calidad, coste, latencia y casos que pasan a revisión. Un servicio con datos o efectos pendientes exige además exportar configuraciones y estado, continuar o compensar operaciones y revocar accesos. Sin ese ensayo, el componente puede estar bien trazado y seguir sin ser reemplazable.

En RAG, la fuente es canónica y la recuperación es derivada

Un pipeline, o cadena de procesamiento, de RAG con índice persistente parece lineal cuando se dibuja deprisa: cargar documentos, crear embeddings, buscar fragmentos y pedir una respuesta al modelo. En producción es una cadena de decisiones. El contenido procede de una fuente local o se incorpora mediante un conector; un analizador o parser conserva o pierde estructura; una estrategia divide el texto; los metadatos habilitan filtros; el modelo de embeddings define un espacio; el recuperador selecciona candidatos; un reordenador puede cambiar su prioridad; y el prompt determina cómo se usan.

CACE reaparece con toda claridad. Cambiar la segmentación altera las unidades que se pueden recuperar. Cambiar el modelo de embeddings modifica las distancias. Añadir un filtro puede mejorar la precisión y excluir la única evidencia válida. Aumentar top-k, el número máximo de fragmentos recuperados, puede mejorar la cobertura; también puede introducir versiones contradictorias que empeoran la generación.

Por eso distinguiría dos capas:

1. La fuente canónica gobernada. Conserva el contenido o el mecanismo para volver a obtenerlo, junto con identidad, procedencia, versión, vigencia, ámbito, permisos y política de retención.
2. El índice derivado. Contiene fragmentos, vectores y campos preparados para una estrategia concreta de recuperación. Debe ser reemplazable y poder reconstruirse desde la fuente durante su vida operativa.

En sistemas que recuperan mediante búsqueda léxica, consultas estructuradas o API sin un índice persistente, el mismo criterio se aplica a los artefactos de recuperación. Consultas, filtros, versiones de conectores y respuestas deben poder atribuirse sin convertirlos en la fuente canónica.

Los permisos de la fuente deben propagarse a los fragmentos. Copiar la lista de acceso resulta insuficiente. Siempre que el motor lo permita, la autorización restringe la consulta antes de recuperar candidatos según identidad, recurso, ámbito, finalidad y vigencia. Si el filtrado exige una preselección, esta se ejecuta dentro de la misma frontera de confianza. Ningún candidato pasa al reordenador, al modelo ni a un servicio externo antes de autorizarse. El invariante exige que ningún candidato salga del entorno de recuperación sin autorización; el orden interno del motor puede variar. Cuando faltan los datos necesarios, el flujo se detiene.

«Canónica» tampoco significa que cada documento sea verdadero ni que deba ser inmutable. Significa que su estado, autoridad y cambios se gobiernan fuera del índice. Si cambia el criterio de segmentación o el modelo de embeddings, el índice anterior deja de representar esa versión del sistema y debe reconstruirse antes de ponerla en servicio. Sin una fuente gobernada que conserve el contenido o garantice la recuperación de la misma versión del corpus y sus metadatos, no puede reconstruirse ese corpus. Cuando existe esa fuente gobernada, el índice es un artefacto de despliegue, no el único lugar donde sobrevive el conocimiento.

Un manifiesto de construcción debería relacionar, como mínimo, la versión del corpus y del parser, reglas de normalización, segmentación, embeddings, metadatos, filtros, recuperador, reordenador y fecha de creación. La respuesta debe registrar una huella de ese manifiesto. Para atribuir una ejecución, la traza relaciona esa huella con el despliegue y la consulta efectiva. También identifica filtros, parámetros, fragmentos con sus versiones y metadatos del proveedor. Esta evidencia no garantiza reproducir literalmente una salida generativa, especialmente cuando el proveedor no ofrece una versión fijable o el modelo es no determinista.

Los agentes añaden cascadas. Si un primer agente clasifica la consulta, un segundo diseña un plan, un tercero recupera y un cuarto ejecuta una acción, la salida de cada uno se convierte en dato de entrada del siguiente. Un error plausible al principio puede llegar al final con apariencia de decisión confirmada. Cada frontera necesita contrato, validación y un límite de autoridad; encadenar más modelos no constituye una verificación independiente.

En integraciones con una plataforma de gestión del aprendizaje (LMS), esta separación es decisiva. El contenido admite búsqueda semántica, pero el estado actual, la identidad y las reglas de acceso no deberían convertirse sin más en fragmentos. Relevancia, autoridad, vigencia y permiso son decisiones diferentes.

Mitigar la deuda de RAG exige reconstruir las evidencias y atribuir cada respuesta

No existe una configuración universal para reducir la deuda de RAG. Hay un conjunto de controles que ayuda a localizar el fallo, estimar el interés que genera y revertir el componente responsable.

Evaluar por separado la recuperación y la generación permite localizar dónde apareció el fallo y reduce el riesgo de intervenir sobre el componente equivocado. La separación solo resulta útil si el corpus de prueba y las métricas representan las consultas que el sistema recibirá en producción.

Una tríada útil, formada por la proporción de evidencias relevantes recuperadas, la fidelidad y la relevancia de la respuesta, es un buen comienzo, no un cuadro de mando completo. Añadiría precisión de recuperación, vigencia, autorización, resolución de conflictos y acierto al abstenerse. Tampoco hablaría de una única «tasa de alucinación»: mezcla fallos de cobertura, evidencia, utilización y seguridad que requieren responsables distintos.

La búsqueda híbrida combina coincidencias de palabras con proximidad semántica. El reranking, o reordenación de resultados, vuelve a ordenar los candidatos mediante una regla de fusión o un segundo modelo; según la técnica, añade cómputo, parámetros, latencia o proveedores. Ambas opciones pueden mejorar un caso concreto y también introducir modos de fallo. Las incorporaría solo si, en una evaluación versionada, la mejora alcanza el umbral fijado antes de la prueba en los segmentos que justificaron el cambio, sin rebasar los límites de coste, latencia o seguridad. Si no, son nueva deuda presentada como sofisticación.

La evaluación debe entrar en el ciclo de entrega. Cada cambio de fuente, parser, segmentación, embeddings, recuperador, reordenador, prompt o modelo debe activar las pruebas correspondientes. Los de mayor riesgo se prueban en modo sombra, sin mostrar sus resultados a los usuarios, o se despliegan de forma gradual. Una prueba de revocación fija un plazo acordado. Dentro de él comprueba que la persona o el servicio afectados dejan de recuperar el recurso desde índices y cachés. El acceso se mantiene para quienes siguen autorizados. La reversión incluye el índice, la configuración y el código.

Los agentes necesitan límites para actuar, no solo para responder

Un agente no se limita a redactar. Puede consultar herramientas, encadenar decisiones y modificar sistemas externos. Esa diferencia cambia la deuda: una respuesta equivocada puede descartarse; un reembolso efectuado, un mensaje enviado o un registro borrado puede exigir una reparación y quizá no admita una reversión completa.

El reembolso duplicado es un incidente. La deuda está en el diseño que permite repetirlo, impide detectarlo o encarece su reparación.

Para contener los reintentos usaría idempotencia. La misma operación lógica conserva una clave estable y, si se repite con los mismos parámetros, el sistema devuelve el resultado anterior sin volver a ejecutar el efecto.

No daría a un agente acceso genérico a todas las herramientas disponibles. Cada llamada debe ejecutarse en nombre de una persona o un servicio identificados, con credenciales acotadas, y el sistema de destino debe volver a autorizar la acción, el recurso y la finalidad. El plan del agente no concede permisos. Separaría las consultas de las acciones y reservaría los permisos de escritura para el tramo que realmente los necesita. Ante una autorización dudosa, la ejecución se detiene. Si la herramienta solo ofrece roles amplios, el adaptador debe ser el único camino autorizado: valida una autorización interna acotada, mantiene fuera del alcance del agente la credencial amplia del destino y ejecuta únicamente la operación aprobada. Una credencial efímera solo añade granularidad cuando el destino valida ese ámbito. Si el adaptador puede eludirse o no limita recurso y acción, el agente se limita a preparar una propuesta para un flujo humano independiente.

La confirmación importa porque el texto del modelo no demuestra que la operación se haya completado. La confirmación debe proceder del sistema que conserva el estado. La idempotencia solo evita duplicar el efecto cuando el sistema que lo ejecuta reconoce la misma clave para la misma operación lógica, comprueba que los parámetros coinciden y conserva el resultado durante la ventana de reintentos. Una clave nueva por intento no impide repetir la operación; tampoco lo hace un registro local creado después del efecto. La idempotencia no vuelve reversible la operación. Cuando una acción no puede deshacerse, esa limitación y su procedimiento de reparación deben conocerse antes de autorizarla.

La clave reutilizable vive en el almacén de idempotencia del sistema que ejecuta el efecto o del proveedor, con acceso restringido. La traza de auditoría conserva un identificador de correlación no reutilizable y la confirmación.

En este diseño, la traza general no conserva credenciales, claves de acceso ni la clave reutilizable de idempotencia. Registra únicamente los metadatos no secretos necesarios para investigar: identidad efectiva, herramienta, acción, recurso, ámbito, política y decisión de autorización, además del tipo, emisor, caducidad e identificador de la credencial.

Evaluaría por separado si el plan elige pasos permitidos y si los efectos son correctos. Un agente puede elegir un plan razonable y fallar al ejecutar una herramienta, o completar todos los pasos de un plan que nunca debió aprobarse. La traza debe permitir localizar la frontera defectuosa sin conservar conversaciones, datos personales o credenciales que no hagan falta para investigar.

Para agentes mediría, por herramienta y nivel de riesgo, propuestas no autorizadas sobre propuestas totales; operaciones sin confirmación sobre operaciones ejecutadas; duplicados sobre reintentos; compensaciones sobre efectos completados; y rechazos o modificaciones humanas sobre solicitudes de aprobación. Para cada medida fijaría la ventana, los segmentos y el umbral antes del despliegue.

El código generado desplaza la deuda hacia comprensión, arquitectura y seguridad

Cuando producir otra versión cuesta menos que revisarla con garantías, la deuda se desplaza hacia la aceptación del cambio. Antes de integrarlo, alguien debe aportar evidencia de que respeta el dominio, reutiliza las abstracciones existentes, cubre los casos límite previstos y ha superado controles de seguridad proporcionales al riesgo. El riesgo residual debe quedar identificado y aceptado por quien corresponda, y el código debe poder mantenerse sin repetir la conversación que lo originó.

El prompting ad hoc favorece soluciones locales. «Añade una ruta al servicio» no explica a qué capa corresponde la operación ni qué autorización se aplica. Tampoco indica el contrato de errores, la biblioteca interna que registra la operación o los consumidores que deben conservar compatibilidad. El modelo completa los huecos con patrones plausibles. Dos peticiones parecidas pueden introducir dos maneras de validar, registrar o transformar lo mismo.

La información parcial sobre el repositorio favorece la reinvención de la rueda, pero el acceso masivo tampoco garantiza coherencia. Un agente puede leer una utilidad y no saber que debe usarla, o encontrar tres implementaciones y elegir la que el equipo intenta retirar. La arquitectura necesita reglas explícitas y verificables: dependencias permitidas, capas, propietarios, contratos y excepciones fechadas.

La deuda de comprensión aparece cuando el equipo aprueba el resultado y es incapaz de explicar sus invariantes o modificarlo con seguridad. Esto conecta con una distinción que ya planteé al analizar cómo medir la productividad del desarrollo con IA: la unidad útil es el cambio validado y estable, con la revisión y el retrabajo incluidos.

Los problemas observados alrededor del código asistido por modelos no forman una deuda nueva y aislada. Reaparecen en el diseño, los defectos, la documentación, los requisitos y las pruebas; la comprensión limitada atraviesa todas esas categorías. La evidencia disponible todavía es pequeña y no permite atribuir toda esa deuda a la generación de código. Sí refuerza el criterio operativo: producir más deprisa no resuelve las decisiones pendientes.

Tres planos de seguridad que no deben mezclarse

Las vulnerabilidades introducidas en el código generado se revisan con los controles habituales de ingeniería: modelado de amenazas, revisión, pruebas, análisis estático, análisis de dependencias y detección de secretos. Que el código proceda de un modelo no cambia las categorías de vulnerabilidad ni rebaja el nivel de comprobación exigible.

La aplicación que incorpora un modelo de lenguaje abre otra superficie de riesgo: inyección de instrucciones, uso inseguro de salidas, acceso excesivo a herramientas, filtración de información o debilidades en vectores y embeddings. Un equipo necesita ambos mapas. Aplicar los riesgos propios de una aplicación generativa al código generado deja fuera vulnerabilidades convencionales; aplicar solo el primero ignora que un texto que no es de confianza puede alterar el comportamiento del sistema.

Hay un tercer plano: el agente y el entorno desde el que se modifica el software. El acceso al repositorio, la red, los secretos, el gestor de paquetes y la integración continua (CI) deben quedar aislados y sujetos a permisos mínimos. El contenido del repositorio también puede incluir instrucciones maliciosas; una nueva dependencia o un cambio en CI no deberían aprobarse solo porque formen parte del parche generado. Los marcos específicos para agentes ayudan a ordenar este tercer plano, pero no sustituyen los controles de ingeniería del repositorio ni los permisos del sistema de destino.

SDD puede adelantar controles antes de integrar el código generado

RAG, agentes y código generado acumulan deuda durante el diseño y la operación. El desarrollo dirigido por especificaciones, o SDD por sus siglas en inglés, parte de una especificación persistente, la spec. Esta describe el comportamiento, los límites, las interfaces y los criterios de aceptación antes de integrar el código. La arquitectura sigue siendo una decisión humana: una spec no la sustituye.

En el extremo opuesto, el prompting ad hoc o vibe coding consiste en pedir cambios mediante conversaciones informales y aceptar la solución a medida que parece funcionar, sin un contrato previo suficientemente preciso. SDD intenta reducir esa improvisación mediante cuatro mecanismos. Su efecto debe medirse en cada contexto: una especificación no demuestra que las decisiones sean correctas ni que vayan a disminuir los defectos.

1. Un marco persistente de decisiones

Antes de generar código, la especificación fija propósito, alcance, tipos, estados, errores, contratos y decisiones de integración. Puede combinar texto estructurado en Markdown con contratos que una máquina pueda validar: OpenAPI para interfaces, JSON Schema para estructuras de datos o modelos de tipos como Pydantic y Zod. El formato depende de lo que deba comprobarse.

La especificación actúa como contrato versionado de decisiones y límites: reduce lo que el modelo tiene que adivinar y conserva decisiones entre sesiones. Para prevenir duplicación debe enumerar los módulos internos, servicios compartidos y bibliotecas obligatorias o permitidas. Para proteger la arquitectura debe declarar también dependencias prohibidas y excepciones.

Su efecto tiene un límite claro. Si la arquitectura no está decidida, la spec solo documentará una ambigüedad o esconderá una decisión improvisada con más formalidad.

2. Verificación determinista del cumplimiento

Los criterios de aceptación y los contratos dan pie a controles automáticos: formato, análisis de estilo y errores, tipos, validación de esquemas, pruebas unitarias, de contrato y de integración, y reglas arquitectónicas. Si cada criterio se vincula a una comprobación ejecutable y obligatoria, la integración continua puede rechazar las incompatibilidades antes de que lleguen a la rama principal. Para impedir que un fallo llegue a la rama, esa comprobación debe ser obligatoria en la política de integración.

Los invariantes deterministas se comprueban con mecanismos deterministas. Las evaluaciones probabilísticas requieren corpus, jueces, umbrales y versiones explícitos. Una prueba demuestra que el código cumple lo que comprueba; no que la especificación sea correcta ni completa.

Siempre que el riesgo lo justifique, el validador decisivo debería tener un modo de fallo distinto del generador y basarse en una regla determinista, otra implementación, otro conjunto de datos o una revisión humana. Si el mismo modelo deriva la spec, el código y las pruebas, puede reproducir el mismo supuesto equivocado en las tres capas y obtener una falsa sensación de acuerdo. Usar otra instancia del mismo modelo no garantiza independencia.

3. Reutilización explícita de la arquitectura existente

Una spec bien conectada al repositorio indica qué abstracciones se reutilizan, dónde se extiende un contrato y qué equipo es responsable de la interfaz. Esto reduce la tentación de crear otra utilidad, otro cliente para servicios web o una nueva representación del mismo estado.

Una instrucción en prosa resulta insuficiente. Las reglas de dependencias, los catálogos de servicios, los analizadores de arquitectura y las pruebas de contrato convierten la intención en una restricción. Si el modelo propone una nueva dependencia, debe justificar qué función falta, qué alternativa se evaluó y cómo se retirará.

4. Código regenerable dentro de límites estables

Cuando un componente está aislado, carece de estado propio y cumple contratos ejecutables, su implementación puede tratarse como reemplazable. Si acumula parches, el equipo ajusta la especificación, regenera una propuesta y la somete a las mismas pruebas. El valor duradero reside en el contrato y en la evidencia, no en cada línea de una implementación concreta.

No todo el software es desechable. Migraciones de datos, efectos laterales, formatos persistidos, compatibilidad pública, requisitos regulatorios y conocimiento tácito hacen que borrar y regenerar pueda destruir información o repetir errores ya resueltos. La regeneración funciona mejor en adaptadores, transformaciones y componentes acotados detrás de interfaces estables.

La comparación queda así:

Algunas herramientas materializan este desplazamiento desde el prompt hacia artefactos de especificación, planificación y tareas. Ayudan a sostener el flujo, pero su existencia no demuestra que SDD reduzca defectos en cualquier tipo de proyecto.

La especificación también puede acumular deuda

SDD desplaza parte de la deuda hacia la especificación. Esta puede quedar obsoleta, contradecir otra, fijar una mala decisión o describir con enorme precisión algo que el producto todavía necesita descubrir. Si el código cambia sin actualizarla, aparece una divergencia entre especificación y código, o spec drift. Si se actualiza solo para reflejar lo que ya hizo el código, deja de dirigir y se convierte en documentación tardía.

Para reducir el riesgo de que quede obsoleta, la especificación se incorpora al ciclo de vida:

1. cada cambio identifica la decisión o contrato que modifica;
2. CI valida esquemas, ejemplos, contratos y criterios ejecutables;
3. la solicitud de integración muestra la diferencia de spec junto a código y pruebas;
4. las excepciones tienen propietario, motivo y fecha de revisión;
5. producción aporta señales para corregir supuestos y casos ausentes;
6. los artefactos obsoletos se retiran en lugar de conservarse como autoridad ambigua.

La sobreespecificación también genera interés. Definir pronto detalles reversibles encarece cada cambio y puede encaminar al modelo con mucha precisión hacia la solución equivocada. Especificaría con rigor propósito, invariantes, interfaces, datos, seguridad y criterios de aceptación. Mantendría abiertas las decisiones locales que sean baratas de cambiar y no alteren contratos.

No daría por demostrada una reducción general de defectos. La evidencia observacional disponible usa indicadores indirectos y no permite saber si los repositorios estudiados aplicaban SDD de forma explícita. Tampoco mide el efecto de herramientas concretas. Por eso no basta con adoptar un nombre, una plantilla o una carpeta de especificaciones.

Por eso mediría el efecto local. En familias de cambios comparables observaría tiempo hasta resultado estable, carga de revisión, defectos, retrabajo, comprensión y divergencias entre spec y código. SDD merece continuidad cuando reduce supuestos y fallos sin imponer un coste documental superior al problema que resuelve.

Un registro de deuda para IA generativa que obligue a decidir

Mantendría un registro pequeño que vincule cada deuda a un activo, una evidencia, un propietario y una decisión observable. El objetivo es retirar o controlar la dependencia que cobra interés, no acumular una lista pendiente de «mejoras».

Para sacar un piloto de RAG o de agentes a producción no intentaría implantar todo el marco a la vez. Empezaría por cinco controles, en este orden:

1. inventario y propietario de fuentes, índices, modelos, prompts, herramientas y especificaciones;
2. autorización por defecto denegada y permisos mínimos para cada consulta o acción;
3. manifiesto y traza que permitan atribuir una ejecución sin guardar secretos;
4. pruebas bloqueantes para el fallo de mayor impacto identificado, junto con una evaluación de calidad versionada. Por ejemplo: un recurso revocado sigue apareciendo en RAG, un reintento duplica una acción o esta se da por completada sin confirmación;
5. despliegue gradual, criterio de promoción y procedimiento de parada, reversión o compensación ensayado.

Este mínimo crea las condiciones para detectar y localizar un deterioro, sin certificar que el sistema sea seguro ni correcto. También reduce el riesgo de que un piloto provoque una operación irreversible sin los controles previstos.

No usaría como medida principal el coste por token, la unidad de consumo con la que se factura el uso de muchos modelos. Puede bajar mientras suben las respuestas inválidas, los reintentos y la revisión humana. Mediría coste por respuesta validada o por cambio estable. Del mismo modo, calcularía la latencia p95, el tiempo que no supera el 95 % de las peticiones. Separaría el total de esa misma medida por etapa para localizar si el interés está en la fuente, el recuperador, el reordenador, el modelo o una herramienta.

Para RAG observaría precisión y proporción de evidencias relevantes recuperadas, fidelidad, relevancia, abstención, vigencia, conflictos y autorización por segmento. Para el código generado observaría el tiempo de revisión, las rondas de cambios, las pruebas añadidas, el retrabajo, los defectos, las reversiones, el tiempo de recuperación y la comprensión necesaria para mantenerlo.

Antes de probar un cambio fijaría la intervención, la unidad de análisis, la población, la ventana y el denominador. También dejaría establecidos la línea base o el grupo de comparación, el efecto mínimo relevante y las métricas de control de seguridad, coste y latencia. Cuando sea posible usaría exposición aleatoria o gradual; en los demás casos registraría los factores que pueden confundir la lectura. Los resultados se revisan por segmento y con su incertidumbre, no como una única puntuación.

La prioridad más alta no siempre corresponde al fallo más visible. Atacaría primero la deuda que impide medir, reconstruir o revertir, porque cobra interés sobre cualquier mejora posterior. Después priorizaría por frecuencia, exposición, impacto y velocidad de crecimiento. Suele convenir retirar una dependencia marginal que falla cada semana antes que acometer una refactorización elegante sin efecto operativo.

El paper de 2015 sigue siendo útil precisamente porque no invita a idealizar modelos más simples. Ofrece un criterio que sobrevive a cada ola: el algoritmo ocupa una parte pequeña y las dependencias cobran intereses en silencio. En la IA generativa hay más piezas, más proveedores, más artefactos y más velocidad. También disponemos de mejores contratos, evaluaciones y automatización.

La diferencia no la marcará producir código o respuestas más deprisa. La marcará conservar la posibilidad de explicar qué ocurrió, comprobar si fue correcto, retirar lo que ya no aporta y cambiar una pieza sin perder el control del sistema completo.