Envío de productos de IA: Lecciones prácticas de una startup fallida
En el panorama de rápida evolución de la inteligencia artificial, donde el bombo a menudo supera la aplicación práctica, Phil Calçado ofrece un análisis post-mortem sobrio y perspicaz de su fallida startup de IA, Outropy. Hablando en una reciente conferencia de InfoQ, Calçado, un ingeniero de software veterano conocido por ser pionero en microservicios en SoundCloud, compartió lecciones sinceras sobre las realidades de enviar productos de IA generativa más allá del “buzz”. Su mensaje central: las claves para un desarrollo exitoso de la IA no residen en perseguir visiones futuristas, sino en aplicar rigurosamente los principios establecidos de la ingeniería de software.
Calçado comenzó reconociendo su propio sesgo: tres décadas de experiencia construyendo software, particularmente sistemas distribuidos y microservicios, con una fuerte inclinación hacia el desarrollo ágil iterativo y de “hacer las cosas”. Esta perspectiva, admite, moldea sus puntos de vista sobre la IA, que cree que no debería estar exenta de estas prácticas fundamentales.
Outropy, la empresa de Calçado, tenía como objetivo automatizar aspectos de los flujos de trabajo gerenciales y de ingeniería utilizando IA generativa, comenzando como un chatbot de Slack y evolucionando a una extensión de Chrome. A pesar de ser un participante temprano en el espacio de la IA generativa, atraer a miles de usuarios e incluso superar en calidad a productos de gigantes tecnológicos como Salesforce (según sus propios puntos de referencia), la startup finalmente fracasó. La sorprendente revelación de los comentarios de los usuarios fue que muchos estaban menos interesados en la herramienta en sí y más en la ingeniería inversa de cómo Outropy, construida por “dos tipos y un perro”, logró crear un sistema con un “comportamiento agéntico” tan efectivo —capacidades autónomas de toma de decisiones— mientras que las empresas más grandes luchaban. Esta paradoja impulsó a Calçado a analizar profundamente por qué la mayoría de los productos de IA, especialmente en el sector de la productividad, se quedan cortos.
Calçado identifica tres enfoques predominantes para construir IA hoy, cada uno con sus propias trampas. El primero es el “desarrollo impulsado por Twitter”, caracterizado por una obsesión con modelos futuros aún no lanzados y un desprecio por las limitaciones tecnológicas actuales, lo que a menudo lleva a demostraciones llamativas que aseguran financiación pero no logran entregar valor en el mundo real. El segundo trata el desarrollo de IA como un “proyecto de ciencia de datos” puro, típicamente visto en empresas más grandes. Este método, a menudo lento y centrado en la investigación, puede tardar años en producir mejoras marginales, un lujo no disponible cuando la IA está en el camino crítico de un producto. El tercero, y el enfoque preferido de Calçado, es tratar el desarrollo de IA como un “proyecto de ingeniería” tradicional, adoptando el desarrollo iterativo desde el principio.
Luego profundizó en los bloques de construcción fundamentales de los sistemas de IA generativa: flujos de trabajo y agentes. Los flujos de trabajo, a los que prefiere llamar “pipelines de inferencia”, representan secuencias predefinidas de pasos para lograr un objetivo de IA, como resumir un correo electrónico. Los agentes, por otro lado, son componentes de software semiautónomos donde los grandes modelos de lenguaje (LLM) dirigen dinámicamente sus propios procesos, usan herramientas y colaboran, ejecutando tareas para lograr un objetivo dado.
Para los flujos de trabajo, Calçado advierte contra la trampa común de depender únicamente de los proveedores de Generación Aumentada por Recuperación (RAG), que prometen alimentar el contexto directamente a los LLM. Descubrió que los LLM a menudo no son lo suficientemente inteligentes para este enfoque simplista, lo que requiere pasos adicionales para agregar estructura y significado semántico. El éxito de Outropy en los informes diarios, por ejemplo, provino de desglosar tareas complejas en transformaciones más pequeñas y estructuradas, muy parecido a los pipelines de datos. Esto permite la aplicación de herramientas y metodologías de pipeline de datos existentes, lo que fundamenta el desarrollo de la IA en un terreno de ingeniería familiar.
Cuando se trata de agentes, Calçado hace una afirmación provocativa: “Los agentes se parecen mucho a los objetos en la programación orientada a objetos”. Si bien reconoce que los microservicios tradicionales son un mal ajuste para los agentes debido a su estado, comportamiento no determinista y naturaleza intensiva en datos, argumenta que el paradigma orientado a objetos —con conceptos como memoria (estado), orientación a objetivos (encapsulación), dinamismo (polimorfismo) y colaboración (paso de mensajes)— proporciona un modelo mental útil para los ingenieros.
Arquitectónicamente, Calçado desaconseja la colaboración de agentes punto a punto, lo que puede conducir a un acoplamiento estrecho y a la reinvención de complejas pilas de servicios web de hace dos décadas. En su lugar, aboga por “eventos semánticos” en un bus de mensajes, como Redis o Kafka, donde los agentes registran interés en eventos específicos y bien definidos, promoviendo un acoplamiento flexible y escalabilidad. También advierte contra la adopción de estándares emergentes como el Protocolo de Contexto de Modelo (MCP) de Anthropic para productos internos, viéndolos como un recordatorio de protocolos tempranos y sobre-diseñados como SOAP. Para sistemas internos, sugiere apegarse a métodos empíricamente probados como arquitecturas RESTful o gRPC.
En cuanto a la “memoria agéntica”, el desafío de que un agente retenga conocimiento sobre un usuario, Calçado descarta el enfoque común de almacenar toda la información en un documento de texto largo dentro de una base de datos vectorial. Argumenta que una memoria defectuosa es peor que ninguna memoria. Su solución recomendada es el “event sourcing” (abastecimiento de eventos), donde un flujo de eventos semánticos sobre un usuario se compacta en una representación estructurada, a menudo almacenada en una base de datos de grafos como Neo4j, lo que permite una comprensión más robusta y evolutiva.
Finalmente, Calçado desafía el enfoque prevaleciente de “pipeline monolítico” en proyectos de ciencia de datos, donde todo un proceso, desde la ingesta de datos hasta la salida, se construye como una unidad única y altamente acoplada. Él defiende la división de estos flujos de trabajo en componentes más pequeños e independientes con interfaces bien definidas, lo que permite la flexibilidad y la reutilización, un concepto familiar del diseño basado en el dominio y los microservicios.
Concluye observando que, a pesar del atractivo de los “objetos distribuidos”, los principios fundamentales del manifiesto de la “Aplicación de Doce Factores”, que sustentan la infraestructura moderna de la nube, a menudo se rompen por los sistemas de IA agéntica debido a su estado inherente y su naturaleza no determinista. Esto requiere un cambio hacia “flujos de trabajo duraderos” (como los que ofrece Temporal), que manejan la resiliencia, los reintentos y los puntos de control, evitando que los ingenieros reinventen constantemente estos componentes críticos de la infraestructura.
La conclusión final de Calçado es poderosa: la complejidad vista en las arquitecturas de productos de IA actuales, como la de Outropy, a menudo es “demasiado complicada” para el número de usuarios atendidos, lo que destaca una necesidad significativa de mejores plataformas. Sin embargo, afirma que construir productos de IA exitosos se reduce fundamentalmente a aplicar la sabiduría de la ingeniería de software probada en el tiempo. Los ingenieros deben aprovechar sus conocimientos existentes y resistir la tentación de creer que la IA, a pesar de su bombo, es fundamentalmente diferente de los desafíos que han abordado antes.