¿Por qué los ingenieros senior encuentran dificultades al crear agentes de IA? @philschmid compartió una paradoja interesante: ¿por qué los ingenieros sénior con experiencia suelen progresar con mayor lentitud y dificultad al desarrollar agentes de IA que los ingenieros júnior? Schmid cree que la causa principal radica en que la ingeniería de software tradicional prioriza el determinismo y la desambiguación, mientras que la ingeniería de agentes es inherentemente probabilística, lo que requiere que los ingenieros aprendan a confiar en los LLM (modelos de nivel local) para gestionar procesos no lineales y la entrada de lenguaje natural. Analiza las dificultades de este cambio de mentalidad a través de cinco desafíos clave y ofrece perspectivas prácticas para ayudar a los ingenieros a adaptarse a este paradigma. Conclusiones clave: Un cambio de paradigma del determinismo al probabilismo. El desarrollo de software tradicional prioriza la previsibilidad: entradas fijas, salidas deterministas y aislamiento de errores mediante la gestión de excepciones. En cambio, los agentes inteligentes utilizan LLM como su "cerebro", tomando decisiones mediante lenguaje natural y permitiendo interacciones multi-turno, ramificación y adaptación. Sin embargo, el instinto de los ingenieros sénior es "eliminar la incertidumbre mediante código", lo que irónicamente obstaculiza el potencial de los agentes inteligentes. Schmid señala que los ingenieros júnior tienden a aceptar la incertidumbre de forma más intuitiva y pueden producir prototipos funcionales con mayor rapidez, mientras que los ingenieros sénior deben superar hábitos adquiridos durante años. Los cinco desafíos principales describen cinco puntos de conflicto entre las prácticas de ingeniería tradicionales y el desarrollo de agentes. Cada desafío se acompaña de explicaciones y ejemplos que destacan cómo adoptar un enfoque más flexible. 1. El texto es el nuevo estado Los sistemas tradicionales utilizan datos estructurados (como valores booleanos como `is_approved: true/false`) para representar estados, lo que garantiza discreción y previsibilidad. Sin embargo, las intenciones reales suelen estar ocultas en los matices del lenguaje natural, como en el comentario del usuario: «Este plan parece bueno, pero por favor, concéntrese en el mercado estadounidense». Forzar una estructura binaria en un sistema perdería estos matices, impidiendo que el agente responda dinámicamente. Perspectiva: Conservar el texto original como estado, permitiendo a los LLM interpretarlo dentro del contexto. Por ejemplo, almacenar preferencias de usuario como "Prefiero Celsius para el clima, pero uso Fahrenheit para cocinar" en lugar de simples valores booleanos. Esto requiere que los ingenieros pasen de priorizar la estructura a priorizar la flexibilidad semántica. 2. Entrega del control Las arquitecturas tradicionales, como los microservicios, se basan en rutas fijas y puntos finales de API para controlar los procesos. Sin embargo, un agente solo tiene un punto de entrada de lenguaje natural, y el LLM determina el siguiente paso según las herramientas y el contexto: potencialmente, bucles, retrocesos o redireccionamientos. Por ejemplo, una intención de "cancelación de suscripción" podría negociarse para "ofrecer un descuento para retener al agente". La codificación rígida de estos procesos limita la adaptabilidad del agente. Perspectiva: Confíe en el LLM para gestionar el flujo de control y aprovechar su comprensión del contexto completo. Los ingenieros deberían diseñar sistemas que admitan esta "navegación no lineal", en lugar de predefinir todas las ramas. 3. Los errores son sólo entradas. En el código tradicional, los errores (como la falta de variables) desencadenan excepciones, lo que provoca fallos o reintentos. Sin embargo, cada ejecución de un agente consume tiempo y recursos, lo que hace inaceptable un fallo total. Los autores enfatizan que los errores deben tratarse como una nueva entrada y retroalimentarse al agente para permitir su autorreparación. Perspectiva: Desarrollar un mecanismo resiliente que reenvíe los errores al LLM para su recuperación, en lugar de aislarlos. Esto refleja el pensamiento probabilístico: el fracaso no es el fin, sino una oportunidad para la iteración. 4. De las pruebas unitarias a las evaluaciones Las pruebas unitarias se basan en aserciones binarias (aprobado/reprobado), adecuadas para resultados deterministas. Sin embargo, el resultado de un agente es probabilístico; por ejemplo, "resumir este correo electrónico" puede producir innumerables variaciones válidas. Las pruebas que simulan LLM solo verifican los detalles de la implementación, no el comportamiento general. Perspectiva: Cambiar hacia las "evaluaciones", que incluyen la confiabilidad (tasa de éxito, como 45/50 aprobados), la calidad (utilizando el LLM como criterio para evaluar la utilidad y la precisión) y el seguimiento (verificar los pasos intermedios, como si se consultó una base de conocimientos). El objetivo no es una certeza del 100 %, sino una alta probabilidad de éxito. 5. Los agentes evolucionan, las API no. Las API se diseñan asumiendo que los usuarios humanos pueden inferir el contexto, pero los agentes inteligentes son literalistas: si "email" en get_user(id) se malinterpreta como un UUID, podría generar una respuesta incorrecta. La ambigüedad de las API amplifica las limitaciones de los LLM. Perspectiva: Diseñe APIs infalibles utilizando tipos semánticos detallados (como delete_item_by_uuid(uuid: str)) y cadenas de documentación. Los agentes inteligentes pueden adaptarse instantáneamente a los cambios de la API, lo que los hace más flexibles que el código tradicional. Soluciones e implicaciones Schmid no aboga por abandonar por completo los principios de ingeniería, sino que busca un equilibrio entre "confiar, pero verificar": construir sistemas resilientes mediante la evaluación y el seguimiento de la gestión probabilística. Al mismo tiempo, reconoce que los agentes no son omnipotentes: las tareas lineales simples se adaptan mejor a los flujos de trabajo que los agentes. Algunos ejemplos incluyen preservar el estado textual de la retroalimentación del usuario, permitir bucles de recuperación basados en errores y cuantificar el rendimiento de los agentes mediante evaluaciones (p. ej., tasa de éxito del 90 %, puntuación de calidad de 4,5/5). Dirección del blog:
