// SOFTWARE
Instrucciones en el código: una nueva deuda técnica
6 min de lecturanijitech
Cuando las instrucciones del modelo se dispersan por el código fuente, cada cambio de texto se convierte en una publicación. Es lo mismo que pasó con el SQL.
Artículo completo
En una aplicación que gana una función de IA, las instrucciones van al sitio más práctico: dentro de la función que hace la llamada. En la primera semana esa es la decisión correcta: es rápida y funciona. Al sexto mes esa misma decisión ha producido la parte del producto que más tarda en cambiar.
Una historia conocida. Hace diez años las consultas SQL también iban incrustadas en el código de la aplicación, y cada cambio de consulta exigía un despliegue. El resultado es el mismo: un cambio de texto se convierte en una tarea de ingeniería.
Cuatro costes de una instrucción incrustada
Lo que pasa de verdad
- Corregir una palabra exige sacar una versión
- La misma instrucción se copia en varios ficheros; uno se actualiza y el otro se olvida
- No se ve qué instrucción cambió y cuándo: la causa de un cambio de comportamiento no se encuentra
- La persona que debería escribir el texto (el experto del dominio) no puede llegar al fichero
El cuarto es el más insidioso. Una instrucción es en realidad texto de producto: su tono, su alcance y sus límites piden conocimiento del dominio. Enterrada en el código, se le ha quitado el derecho de escribir ese texto a quien debería escribirlo.
Una instrucción es configuración
El arreglo no es complicado: las instrucciones viven aparte del código, bajo control de versiones, y la aplicación las llama por un identificador. A partir de ahí, cambiar una instrucción es una tarea de configuración y no un despliegue.
El versionado hace reversible un cambio
Cuando una instrucción cambia, el comportamiento cambia, y a veces empeora. Sin versiones no hay adónde volver; solo le queda la observación de que ayer estaba mejor.
Aquí aparece el vínculo con el conjunto de evaluación. Con una instrucción versionada y un conjunto de evaluación ejecutable juntos, puede medir en cada cambio qué categoría empeoró. Si falta cualquiera de los dos, la medición queda incompleta.
Qué pasa cuando cambia el modelo
Los modelos envejecen, y cuando sale una versión más barata o más potente uno quiere moverse. Si las instrucciones están repartidas por el código, la migración se vuelve una operación de buscar y reemplazar y hay que probar cada instrucción por separado contra el nuevo modelo.
Con las instrucciones en un solo sitio, esa misma migración es un cambio de configuración y una pasada del conjunto de evaluación. La diferencia es de horas frente a días.
Por dónde empezar
Los tres primeros pasos
- Reúna en un solo sitio todas las instrucciones del repositorio: solo muévalas, nada más
- Dé a cada instrucción un identificador y un número de versión
- Escriba el siguiente cambio como una versión nueva; no borre la anterior
Ninguno de los tres exige un cambio de arquitectura. El beneficio llega el primer día en que necesite volver atrás.
Del glosario: Orquestación de modelos · Conjunto de evaluación (eval)