Bienvenidos a todos. Mi nombre es Sam Kmezverk. Soy ingeniero, y gracias por su tiempo. Cuando me invitaron por primera vez a dar esta charla, quería hablar sobre las diferentes iniciativas y las interfaces que estaban surgiendo para tratar con agentes, cómo se veían los nuevos procesos y qué significaba eso para nosotros como desarrolladores. En ese momento, Access y Duet UI eran las principales cosas de las que todos estaban hablando, así que construí mi charla en torno a ellas. Poco después, parecía que todo el mundo en internet estaba hablando sobre cómo las interfaces LLM generadas dinámicamente para el futuro. Así que eso hizo que la mitad de mis diapositivas quedaran obsoletas. La reescribí solo para que Antigravity se lanzara dos semanas después y dejara la otra mitad obsoleta. Así que después de esto, me di cuenta de que intentar dar una charla sobre tecnología de agentes específica probablemente no iba a ser el mejor uso de nuestro tiempo juntos. Lo que diga aquí probablemente estará desactualizado para cuando termine esta conferencia. Así que, en cambio, quiero dejarles algunos principios que como FDE y como alguien que ha trabajado en el campo por un tiempo, estoy seguro de que estos principios seguirán siendo verdaderos, sin importar cuál sea la próxima gran cosa en interfaces de agentes de UI.
El primero proviene de organizaciones humanas, y es que solo una persona, solo un agente debe ser responsable de la implementación de una tarea como máximo. En 1999, el NASA Mars Climate Orbiter se perdió, lo que costaría unos 325 millones debido a que dos equipos simultáneamente asumieron que poseían el mismo requisito. Del mismo modo, estoy seguro de que todos nosotros en esta sala hemos lidiado con el infierno de conflictos de fusión cuando dos personas están seguras de que están editando el mismo archivo con diferentes contextos. E incluso en el diseño de sistemas, si tienes dos nodos que ambos piensan que son el principal, obtendrás lo que se llama el problema de cerebro dividido. Y esto es algo que también he visto en el despliegue cuando las personas intentan aplicar agentes a organizaciones.
Un despliegue en el que estuve fue con una empresa que estaba tratando de automatizar su facturación. Así que creas dos agentes, y de manera crítica, a ambos agentes se les dijo que su objetivo es asegurarse de que no quede ninguna factura sin enviar. Así que, el primer agente generaría una, el segundo la enviaría, marcaría el estado como un poco diferente. El primer agente, asumiendo que algo erróneo había sucedido, regeneraría la factura, y luego el segundo enviaría esa también. Este bucle continuó durante un buen par de días hasta el punto en que un cliente recibió 64 facturas por el mismo cargo de 900 libras. La lección aquí es que cada tarea necesita ser delegada una vez y solo una vez a un solo agente. Ese agente tiene control completo. El siguiente principio también proviene de organizaciones humanas, y es que las decisiones y los requisitos necesitan tener un nombre específico adjunto a ellos. En Tesla y SpaceX, tienen una regla donde si hay un requisito incorporado en algún producto, algún nombre necesita estar adjunto a él, idealmente alguien dentro de la organización que puedan referenciar si algo sale mal. De manera similar, en Amazon, tienen este modelo de liderazgo de un solo hilo donde una persona es responsable de un proyecto completo, y luego su nombre está adjunto a todas las decisiones que toman. Esto es también algo que he visto en el campo.
Comments