Nueve hábitos de ingeniería para lanzar tu primer agente de IA
Nueve hábitos que impiden que los agentes fracasen en la producción: evaluar primero, un presupuesto de contexto, límites de autonomía, seguimiento, versionado de comandos, estimaciones de costos y triaje de fallos.
Fuentes: *9 AI Engineering Rules I Wish I Knew Before Shipping My First Agent*
En los círculos de ingeniería de agentes circula una historia sobre una factura de 47,000 dólares. Se relata sin muchos detalles, así que considérela como una ilustración y no como un caso verificado. Un agente se comportó impecablemente en todas las demostraciones. Luego se lo aplicó a un flujo de trabajo real de un cliente, lo que lo llevó a un bucle de reembolsos, ejecutando la misma acción una y otra vez durante seis horas sin que nadie lo supervisara. El modelo no era demasiado deficiente. Las personas que desarrollaron el sistema omitieron todo lo relacionado con el modelo que indica cuándo debe detenerse.
Esa es la incómoda realidad de trabajar en ingeniería para sistemas de IA. Puedes conocer Python, RAG, agentes, bases de datos vectoriales, técnicas de prompt engineering y cada nueva versión de modelo, y aún así no estar listo para su uso en producción. Las habilidades que te salvan cuando falla una demostración rara vez se incluyen en los tutoriales. Son aburridas y fáciles de pasar por alto, pero son las que diferencian a un sistema con aspecto impresionante de uno en el que se pueda confiar. A continuación, se presentan nueve hábitos de trabajo útiles que deberías adoptar antes de lanzar cualquier sistema autónomo.
Por qué saber más no te convierte en experto
Algunas cifras muestran con qué frecuencia los proyectos se estancan entre la demostración y el despliegue. Son datos de segunda mano y los métodos varían, así que considéralos una visión general aproximada:
- La previsión de Gartner a mediados de 2025 indica que más del 40% de los proyectos de IA basados en agentes serán cancelados antes de finales de 2027, debido al aumento de costos, a la falta de claridad en su valor y a controles de riesgo deficientes.
Ningún modelo empeoró de repente un 40% en su capacidad de razonamiento. Algo falla entre la demostración y el lanzamiento real. La teoría actual es que los fallos en la producción suelen ser causados o agravados por el sistema que rodea al modelo, y no únicamente por la salida del propio modelo: ausencia de medidas de seguridad, datos de mala calidad, validación deficiente, escasa capacidad de observabilidad y gastos descontrolados.
Un punto de referencia indica lo mismo sin demostrar la causa. En tau-bench, que prueba a agentes que utilizan herramientas en tareas como reservar vuelos y resolver tickets de soporte, un resumen señaló que incluso los modelos más avanzados completaron menos de la mitad de ellas, y que al repetir una tarea la consistencia disminuyó a aproximadamente una cuarta parte. Eso mide la capacidad pero no diagnostica nada. Indica que los agentes son poco fiables, pero no por qué.
Recuerde una distinción importante, ya que se aplica a todos los hábitos mencionados a continuación: el bucle anterior no fue una respuesta incorrecta. Nada lo detuvo. La brecha entre la salida de un modelo y lo que el sistema permite lograr con esa salida es donde residen la mayoría de estos hábitos.
1. Escriba la evaluación antes de la funcionalidad
Los principiantes escriben una instrucción, la prueban un par de veces, deciden si les gusta lo que ven y la lanzan. Los ingenieros con más experiencia primero definen qué significa “correcto” mediante un conjunto de casos de prueba, y solo luego trabajan en la función.
Una evaluación puede ser sencilla: reúna de 20 a 30 ejemplos reales del uso real, cada uno con su resultado esperado, y pruebe su instrucción con todos ellos cada vez que haya algún cambio. Si no puede determinar si un cambio fue útil sin examinar los resultados y adivinar, solo tiene una intuición y no una evaluación real. Este hábito es la forma más rápida de evitar lanzar versiones con regresiones que no se pueden detectar.
2. Trate el contexto como si fuera dinero
La costumbre de los principiantes es incluirlo todo: el documento completo, toda la conversación, cinco ejemplos “por si acaso”. Más contexto parece más seguro, pero generalmente no lo es. Cada token adicional compite por la atención del modelo y le proporciona un detalle incorrecto más en el que concentrarse. Trata la ventana como un presupuesto:
- Reduce los documentos recuperados a las partes relevantes.
- Resume las conversaciones anteriores y no las reproduzcas en su totalidad.
- Elimina los ejemplos que no aportan valor real.
Si no sabes qué está ocupando la ventana, imprime todo el mensaje que envías y léelo. Muchas personas se sorprenden al ver cuánto de ello es irrelevante.
3. Controla la autonomía antes del lanzamiento
Este es el hábito que podría haber detenido el ciclo de reembolsos. Un análisis de los costosos fallos de los agentes, realizado por un grupo llamado Operator Collective, clasificó los casos en cinco categorías: ausencia de límites en las acciones autónomas, datos obsoletos o defectuosos, confianza en los resultados sin verificación, la seguridad como consideración posterior, y fallos que nadie detectó porque no había supervisión alguna. Ninguna de estas cinco categorías se refiere a “el modelo razonó incorrectamente”. Se trata de un único análisis y no de una ley natural, pero indica algo real. Un resultado erróneo rara vez causa daño por sí solo; el daño surge cuando nada posterior lo detecta, lo limita o impide que se repita.
Las cálculos matemáticos demuestran que esto es innegociable. Si cada paso de un flujo de trabajo de agente tiene un 95% de éxito y la tarea consta de 20 pasos, el proceso completo no se completará correctamente en un 95% de los casos, ya que las probabilidades se acumulan. Con un 90% de éxito por paso, una secuencia de 20 pasos solo tendrá éxito en aproximadamente un 12% de las ocasiones. Una demostración que ejecuta tres pasos sin problemas casi no dice nada sobre un flujo de producción con veinte pasos.
Antes de poner en marcha cualquier sistema autónomo, establezca un límite de pasos, un tope de costos, un tiempo de espera y una forma en que pueda detenerse por sí mismo. La razón no es que no se pueda confiar en el modelo, sino porque la probabilidad nunca pierde.
4. Registre todo como si tuviera que depurar a ciegas a las 2 a.m.
La falla más peligrosa no ocurre de forma ruidosa. El agente toma la acción incorrecta, informa que todo funcionó bien, el panel de control sigue mostrando un estado positivo, y un cliente pierde dinero o recibe malos consejos antes de que alguien se dé cuenta.
Los principiantes añaden registros después de que algo falla. Los ingenieros experimentados crean un seguimiento estructurado desde el primer día: cada entrada, llamada a herramientas y paso de razonamiento intermedio están fechados y son buscables. Tres semanas después, se desea reproducir exactamente lo que vio y decidió el agente en lugar de reconstruirlo a partir de la memoria. Si su configuración actual le obliga a adivinar en las primeras horas de la madrugada, cierre primero esa brecha.
5. Subir la escalera: prompt, recuperación y luego ajuste fino
Cuando la precisión falla, los principiantes suelen recurrir directamente al ajuste fino porque parecen ser una forma de ingeniería “real”. Por lo general, es el primer paso equivocado, y un caso bien conocido ilustra por qué. Los investigadores de Microsoft tomaron GPT-4, le añadieron un conjunto de técnicas de inducción llamado Medprompt y lo compararon con Med-PaLM 2, el especialista médico de Google, ajustado con datos clínicos y combinado con indicaciones escritas por expertos. Medido mediante MedQA, el Med-PaLM 2 ajustado alcanzó un 86.5%, mientras que el GPT-4 con solo técnicas de inducción y Medprompt obtuvo un 90.2%. Eso representa una reducción del 27% en la tasa de errores, además de necesitar muchas menos llamadas al modelo que el método de ajuste fino.
El orden lógico va desde lo económico y reversible hasta lo costoso y lento:
Prompting Retrieval (RAG) Fine-tuning
(cheap, fast, → (add missing → (expensive, slow,
reversible) knowledge) last resort)
Primero corrige el prompt y métralo. Si al modelo le faltan datos, añade una función de recuperación. Solo realiza el ajuste fino cuando dispongas de un conjunto de datos grande y limpio, además de un comportamiento específico que realmente no pueda lograrse con el prompt. La mayoría de los equipos nunca lo necesitan, ya que los pasos anteriores resuelven el problema.
6. Separa la planificación de la ejecución
Un agente para principiantes suele ser un único prompt enorme que planifica, toma decisiones y ejecuta todo de una sola vez. Cuando falla, no hay nada que separe la idea de “el modelo pensó mal” de la de “el código hizo algo incorrecto”, porque todo está mezclado entre sí.
Los desarrolladores experimentados dividen el sistema en dos partes. Una parte, el modelo, funciona como el cerebro y decide el siguiente paso a seguir. Otra parte, código determinista que actúa como el mecanismo de ejecución, lo lleva a cabo: llama a la API, verifica la respuesta, vuelve a intentarlo dentro de los límites establecidos y aplica las restricciones del tercer hábito. Esa división es lo que hace que un sistema sea depurable. Se puede determinar de inmediato si el modelo eligió la acción incorrecta o si el código de ejecución falló al realizar una correcta, ya que se trata de errores diferentes con soluciones distintas.
7. Trate los prompts como código y véalos como versiones
Un prompt que requirió cuatro reescrituras es el de la lógica de producción. Trátalo como papel en blanco y perderás la versión funcional en el momento en que alguien lo “mejore”. Mantén los prompts bajo control de versiones como cualquier otro archivo, ejecuta tu conjunto de evaluación desde el paso uno contra cada cambio antes de que se fusione, y registra un breve historial de cambios que indique qué se modificó y por qué. Suena demasiado básico como para mencionarlo, y esa es precisamente la razón por la que la mayoría de los equipos lo omiten, hasta que una regresión en un prompt llega a la producción y nadie puede decir qué cambió.
8. Estima primero el precio de la función
Aquí hay un ejemplo concreto. Un agente sin restricciones que realizaba una sola tarea de software gastó entre 5 y 8 dólares en tarifas de API, mientras que sesiones completas de producción, intentos de reintentar y llamadas a herramientas sumaron un costo entre 10 y 100 dólares. Las cifras varían según el modelo, la tarea y los métodos de optimización, pero la tendencia se mantiene. Un costo que parece trivial por tarea deja de serlo cuando hay un volumen elevado, y un proyecto piloto que parecía económico en las pruebas puede convertirse silenciosamente en la razón por la que un proyecto se descarta.
Los principiantes primero desarrollan y luego revisan la factura. Los ingenieros experimentados estiman el costo por tarea antes de escribir cualquier código: número aproximado de tokens de entrada, número aproximado de tokens de salida, llamadas esperadas por tarea y volumen diario previsto. Si la cifra ya parece alta con diez usuarios, no mejorará significativamente con diez mil. El costo no es un asunto financiero que se aborda después del lanzamiento; es una decisión de arquitectura que ya se ha tomado, independientemente de si uno se dio cuenta o no.
9. Diagnostique antes de adivinar
Cuando algo se rompe, el reflejo de los principiantes es señalar al modelo, sustituirlo por uno más potente o escribir una instrucción más larga. No lo haga. Los fallos mencionados en la revisión bajo el tercer hábito se debieron a la falta de medidas de seguridad, datos defectuosos, confianza no verificada, seguridad deficiente o fallos que nadie estaba vigilando, y no a errores del modelo por sí mismo. Esa es una observación basada en un conjunto de casos y no constituye una garantía para el suyo, pero es una verificación sencilla que realizar antes de una más costosa. Antes de tocar la instrucción, pregúntese si los datos obtenidos estaban desactualizados o erróneos, si una llamada a la herramienta falló silenciosamente y si existía algún límite en las repeticiones. A menudo, la solución se encuentra en el sistema circundante, y verificarlo lleva cinco minutos en comparación con tener que reescribir todo.
Cuándo omitir la mitad de esto
Ninguno de los nueve hábitos es gratuito. La creación de evaluaciones lleva tiempo, las medidas de control añaden código y el modelado de costos consume una tarde que preferirías dedicar a la creación. Si estás haciendo prototipos durante un fin de semana y eres el único usuario, omite la mayor parte de estos pasos. Introduce el conjunto de evaluaciones, las medidas de control y los prompts versionados cuando otras personas comiencen a depender de lo que has creado, y no antes. Realizar un experimento individual con procedimientos propios de producción desperdicia tiempo que sería mejor usar para descubrir qué funciona. La disciplina rinde frutos en aquellos ámbitos donde hay necesidad de reembolsos: sistemas que involucran a usuarios reales, dinero real o decisiones reales.
El cambio en una sola oración
Según ese relato, ningún modelo más inteligente solucionó el bucle. Lo que lo resolvió fue un conjunto de reglas escritas: límites en la autonomía, verificaciones antes de cada acción y una persona que revisaba los registros. Gobernanza, no inteligencia. Los principiantes intentan superar el fracaso con un modelo mejor. Los ingenieros experimentados construyen un sistema que falla de forma segura cuando el modelo está equivocado, porque tarde o temprano lo estará.