Los agentes de IA deben usar herramientas, no apropiarse de tu arquitectura
El modelo es un componente. Trátalo como tal y las funcionalidades de IA vuelven a ser ingeniería normal.
El modelo es un componente. Trátalo como tal y las funcionalidades de IA vuelven a ser ingeniería normal.
Hay un atajo tentador al construir funcionalidades con IA: dar al modelo acceso amplio, describir el objetivo y dejar que se organice. Queda espectacular en una demo. También convierte al componente menos predecible del sistema en el responsable de la corrección, la autorización y la integridad de los datos.
La alternativa es poco glamurosa y funciona: el modelo planifica y explica, y un conjunto pequeño de herramientas bien definidas hace el trabajo.
Cuando eso se cumple, llegan las propiedades interesantes. Puedes cambiar de modelo. Puedes probar las herramientas de forma determinista. Puedes responder a una auditoría sobre qué ocurrió. Puedes dejar que un componente no determinista participe en un sistema que sigue comportándose.
En la práctica, la calidad viene mucho más del contexto que ensamblas que de la gimnasia de prompts. Una descripción estructurada y compartida del negocio (qué hace esta empresa, quiénes son sus clientes, qué significan sus datos) mejora el resultado con más fiabilidad que cualquier cambio de modelo, y además es tuya.
Trata al modelo como un consumidor de tus APIs inusualmente capaz, pero no confiable.
Un equipo presionado para entregar IA tomará el atajo, porque el atajo es más rápido el primer día. El coste aterriza después, como incidencias que nadie reproduce y comportamientos que nadie puede explicar a un cliente.
Fijar la frontera temprano (el modelo propone, las herramientas ejecutan) es la decisión arquitectónica más barata disponible y una de las pocas que se vuelve más difícil cada semana que se retrasa.
Escrito por Jesús Ibáñez, líder de ingeniería.
Las buenas decisiones de arquitectura son aburridas de defender y fáciles de revisar. Las de moda no son ninguna de las dos.
Leer el artículoA un engineering manager no le faltan tareas. La pregunta es cuáles de esas tareas son de verdad suyas.
Leer el artículo