De Prompts a Orquestación: La Codificación Ahora es un Sistema

Hola a todos, emocionado de estar aquí. Mi nombre es Vladimir Novik y soy arquitecto de sistemas de IA en Scalable Cloud Platforms. Hoy quiero hablar sobre cómo hemos pasado de los prompts a la orquestación y cómo la codificación es ahora un sistema. Y quiero repasar diferentes estudios y cómo abordamos los sistemas y cómo mejoramos en ellos.

Así que todos comenzamos en el mismo lugar. La IA iba a hacer que escribiéramos menos, enviáramos más rápido, una especie de autocompletar en esteroides. Y por un tiempo, eso es exactamente lo que se sintió. Pero si intentas construir algo real a escala con más de un agente en el bucle, te sentiste como si el suelo se moviera. Y el cuello de botella dejó de ser qué tan rápido escribes líneas, se convirtió en cómo coordinas la escritura. La IA no solo aceleró la codificación, cambió silenciosamente lo que es el trabajo.

Quiero pensar en eso como tres errores y tres saltos. Y cada paso se sintió como un salto hasta que intentaste construir algo real. Así que subimos la escalera. Primero, comenzamos con los prompts. Describes, generas, luego copilotos, hojas en tu editor, completando tus pensamientos, y luego agentes, obviamente. Toman una tarea, ejecutan archivos de edición, ejecutan comandos, abren PRs. Cada peldaño en la escalera o paso en la escalera se sintió como un salto. Cada paso fue real. Cada uno tenía un precipicio justo en el borde. Y en el momento en que pasaste de ese archivo, o incluso múltiples archivos, una tarea, una sesión, las cosas colapsaron.

Así que hablemos de cómo las cosas colapsaron. Y comenzó a colapsar en la memoria, sin prompts. Sin estado, te conviertes en el bus de contexto. Los prompts no recuerdan, cada sesión comienza desde cero, básicamente un estado de copiar y pegar. Luego pasamos a agentes únicos. Un agente único colapsa el contexto y las auto-revisiones. Así que un hilo largo eventualmente pierde el hilo, y no hay nadie para verificarlo. Crea su propia tarea, en cierto sentido. Así que la solución obvia fue agregar más agentes, excepto que el colapso de múltiples agentes ingenuos es más rápido. Y lo hace en dos vías a la vez.

Encadenar pasos juntos y los errores no solo se cancelan, se acumulan, y es multiplicación. Así que no me citen en el número, pero si, digamos, comenzamos con un 95% de fiabilidad, entonces puede bajar a como 36% y cosas así. Y la forma se mide. Si miras esta línea, tenemos un enjambre, y p es la tasa de éxito, y n son los pasos que están encadenados. Y con el enjambre de agentes, básicamente llegamos al 36% de fiabilidad. Comenzando desde el 95%. Así que 95%, 77%, 36%, y luego tenemos la versión con puertas, de la cual hablaré en un momento. Cómo hacemos esto con puertas, y eso asume una ganancia fuerte. ¿De acuerdo? Ahora la puerta también puede fallar, pero este niño asume una ganancia fuerte. Y estos números provienen de un estudio masivo de Berkeley. Se anotaron a mano 200 trazas de multi-agentes, y alrededor del 79% de los fallos son estructurales. Hay un enlace al artículo para eso.

Así que estamos hablando de que esto no es un multi-agente, esto es un enjambre. Así que el problema no es el multi-agente, el enjambre lo es. El enjambre son n agentes charlando entre pares, cada uno editando lo que quiere, nadie posee la verdad, y eso es lo que realmente colapsa. La parte sorprendente, diferentes campos están de acuerdo, por ejemplo, en trópico, en empujar más agentes, cognición, argumentando por menos. Pero están de acuerdo en el hecho de que la solución no es más conversación, es orquestación. Un propietario del contexto, trabajadores que operan en aislamiento, informan de vuelta. No se hablan entre ellos, y una mirada determinista decide qué se hace. Llamémoslo orquesta.

Básicamente un director, como una orquesta, y todos tocando la misma partitura. Hablemos un poco de números. Así que números rápidos. En el lado izquierdo, aquí, vemos el must, es un estudio de UC Berkeley, taxonomía de fallos de multi-agentes. Ese es el nombre del must. Y cientos sobre 200 ejecuciones reales de multi-agentes y ordenados por qué fallaron. Tanto el 79% son estructurales como mencioné antes, además de lo que también llaman desalineación entre agentes, que es básicamente pérdida de contexto o conflictos en la transferencia. Eso nos muestra que los números no son buenos, por decir lo menos. Luego en el lado derecho, está el lado positivo.

El número más limpio es este, apodado work. Y es revisado por pares y aislado exactamente lo que aquí se afirma. Mismo modelo, solo múltiples topologías de orquestación, y obtienes un 12-23% en puntos de referencia de codificación y razonamiento. Y esa estructura está dando frutos, no el modelo. Así que, dos de cada tres puntos numéricos, de la misma manera, entrópico, más del 90% en amplitud de investigación. Y luego hay una Trinidad, es del modelo de coordinador de Sakana. Hay mejora allí también.

Así que hay diferentes equipos, ¿verdad? Diferentes puntos de referencia, pero misma forma, el propietario del contexto, trabajadores aislados, puerta verificada. Así que vamos a replantearlo. Entonces, si la orquestación es la respuesta, la verdadera pregunta es ¿qué necesita el sistema? No qué herramienta, qué propiedad, sino qué propiedades, porque la herramienta cambiará cada seis meses, pero la estructura debajo de ellas no debería. Nunca se trató de escribir código línea por línea. Se trata más de diseñar un sistema que produzca, valide y evolucione el código. Y lo escribí como una especificación neutral al proveedor, lo llamé Orchestrator Coding. Está disponible en GitHub, obtendrás el enlace al final.

Y la idea es que tenemos tres fundamentos, siete disciplinas y cuatro niveles de conformidad. Así que puedes decir honestamente dónde te encuentras. Así que vamos a recorrerlo. Puedes comprobarte a ti mismo contra el sistema si estás trabajando usando este sistema, o simplemente puedes discutir conmigo que está mal o algo así. Así que comencemos con los fundamentos. Antes de cualquier lógica de orquestación, tres cosas tienen que ser verdaderas o todo está mal. En primer lugar, fuente de verdad, los agentes obedecen. Es como una ley, puede ser arquitectura, contratos, especificaciones, todo aplicado mecánicamente. Luego tenemos el fundamento número dos, contexto compartido como un protocolo. Estado duradero, todos leen antes, después de cada unidad. Y puertas deterministas, lo cual es muy importante. Puertas que deciden hecho sin alucinar. Y estas tres cosas que básicamente están resolviendo las cosas que se rompen, la memoria, la coordinación y la autoevaluación. Así que hablemos del fundamento uno. Fuente de verdad, tratada como ley. Así que los agentes se conformarán y no reinventarán.

Necesitamos arquitectura, contratos, especificaciones, versión, explícito y vinculante. Un agente nunca puede divulgar en silencio. Si las fuerzas de la realidad cambian, ese cambio es deliberado y registrado. Necesitamos escribir un ADR, registro de decisiones arquitectónicas, en el mismo conjunto de cambios. Así que también podemos revisar eso, ¿verdad? Y el código y la arquitectura nunca se dejan en desacuerdo. Y lo más importante, se aplica mecánicamente.

Así que necesitamos enlaces, tipos, conformidad de esquemas. Todo se defiende a sí mismo. Un documento que se le dice a un agente que siga es una sugerencia, y los agentes se desvían de las sugerencias. Un enlace que falla la construcción es la ley. La arquitectura se defiende a sí misma. Así que 10 agentes no pueden reinventar. Si el enlace falla, falla, ¿verdad?

Fundamento número dos, contexto compartido como protocolo. Así que la respuesta a las indicaciones no recuerda. Cada contexto de unidad se ensambla a partir de resultados previos, estado actual, como fuente de verdad, no se introduce de contrabando en una sola indicación gigante que muere con una sesión. Así que eso es un poco glamoroso y la mayor causa de fracaso en Mast. Aproximadamente un tercio del rastro de contexto se pierde en la transferencia, ¿verdad? Así que leemos cosas, pasamos a la unidad de trabajo, construimos el contexto y escribimos después. ¿Verdad? Así que resultados previos, estados actuales, esa es la fuente de verdad. Y necesitamos que sea compartido y no solo una indicación gigante.

Fundamento tres, la puerta real. Así que lo hecho se decide por verificaciones que no pueden alucinar. Mecánicamente no pueden. Los tipos de prueba, lints, pasan y construyen. LM puede pesar en el gusto, pero nada hecho en el modelo dice. Así que no es como, está bien, marqué esta tarea porque el código está ahí. ¿Verdad? Tiene que pasar la prueba, tiene que pasar el linting, tiene que conformarse al esquema, ese tipo de cosas. Pero también hay como una trampa, porque si solo creas muchas pruebas que son solo verdes y nada, eso en realidad no verificó. Es peor. Y parece seguro. Así que necesitamos asegurarnos de que nuestras pruebas realmente verifiquen lo que se supone que deben verificar.

¿Verdad? Entonces, las siete disciplinas son la orquestación en sí misma. Y no son iguales. Así que tómalas, pesa las especificaciones las clasifica. Y las tres primeras son el mínimo que gana el juego. La orquestación posee el despacho, el aislamiento, las transferencias duraderas. Luego tenemos el bucle de dependencia o brecha. Tenemos revisión independiente y puerta de fusión. Y luego tenemos múltiples arneses o bucles de control, que son eventos y trolls, básicamente. Y después de eso, también viene una especie de aislamiento y múltiples arneses como una especie de mejora.

Así que hablemos de esto como banda uno. El núcleo. Así que D1 orquesta su propio despacho. Una autoridad lógica única decide qué se ejecuta cuándo. Los trabajadores informan de vuelta. No negocian entre ellos. Es un requisito de consistencia, no un único punto de error. Solo conoce dos cosas, coordinación de escritura, estado de los unos. D2 es el que más importa. Hablamos de aislamiento aquí. Ponemos cosas en una rama, en un árbol de trabajo, sandbox. Dos agentes nunca escriben en la misma superficie a la vez. Así que no tenemos estos como infiernos de fusión y cosas así. D3 transferencias como artefactos duraderos. No solo pasar estos al agente X, Y y Z, sino tener un archivo de transferencia de artefacto entregable real en disco que otro agente pueda leer. Ese tipo de cosas. Así que si alguna vez haces este árbol, te has ganado el nombre de orquestador. Orquestador, de lo contrario, no.

Luego tenemos el segundo nivel que es como gobernado. Ahora es seguro realizar cambios por sí mismo. D4 es dependencia o un bucle de brecha.

Modela dependencias. Una unidad de despacho cuyos requisitos previos no se cumplen. Así que volver a verificar continuamente liberando en el momento en que se despeja el bloqueador. Así que para eso, necesitamos que el daemon se ejecute y libere. Hablaré de esto un poco más tarde. Y el estado desconocido se trata como bloqueado. Así que cuando hay dudas, entonces falla seguro.

Luego tenemos D5 es una revisión independiente más una puerta de fusión. El revisor no es el agente que escribió el código. Es una especie de auto-revisión es cómo falló un solo agente. Es un agente diferente el que revisará el trabajo. Así que también necesitamos que solo humanos retengan algunas cosas aterradoras, ¿verdad? Como migraciones fuera, cambios disruptivos, ese tipo de cosas.

Y los otros tres son los resilientes. Entonces, ¿qué sobrevive a la producción? ¿Qué es absolutamente autónomo? Así que múltiples arneses. Imagina que alcanzas los límites de tu código. Entonces automáticamente el sistema cambiará a codex o viceversa. Puedes componer modelos. Comienzas con un modelo y compones a otro. Entre múltiples arneses, open code, codex, todos ellos. Luego también necesitamos el bucle de control. Así que PR abierto, revisión, verificación fallida, recuperación, bloqueadores, todo liberado. El bucle es un sistema de eventos. Basado en los eventos, tienes diferentes agentes desencadenados, y está trabajando constantemente, ¿verdad? Nada se deja caer. Así que la diferencia entre automatización, tú cuidas, automatización, que funciona mientras duermes. Así que el primer nivel, cómo llegamos de L0 a L3. Así que L0 es asistido, como un solo agente o piloto. Sin orquestación, derechos humanos, fusiona todo. Orchestrator es el sistema que produce trabajo de manera organizada. El humano todavía aprende cada cambio. Luego gobernado, salto real.

Es la puerta, no la persona, la que se convierte en la autoridad de fusión, revisiones independientes, más verificaciones verdes, todo se aterriza automáticamente y funciona. Y L3 es resiliente. Aterriza, recupera, pausa, pregunta, reanuda, todo es automático. Y lo último es autonomía. Así que lo haces, produce, fusionas. Se fusiona a sí mismo como L2, fusiona y recupera. Y luego la pausa, pregunta, reanuda, todo eso se hace automáticamente como L3.

Y en la celda uno, es un aspiracional tres, porque si haces bien L1, puedes entregar código muy bueno versus un L3 inestable que probablemente fallará en algún lugar y será muy aterrador en producción. Así que puedes ser el orquestador. No necesitas un demonio de algún tipo. Lo que importa son las disciplinas. Quién ejecuta el bucle, eres un demonio, es una cosa separada. Así que manual, conduces, despachas sub-agentes.

Tienes Git trabajando por tarea. Informas archivos como entrega, revisión separada o sub-agente o puerta CI. Y alcanzas un honesto L1 con esto. Luego hay automatización que te compra bucles de control impulsados por eventos y dependencia y multi-arnés y todo eso. Y así puedes usar el demonio, puedes usar sin el demonio. Entonces, ¿cómo lo harías a mano, L1 a mano? Obtén una habilidad, verifica antes de terminar. Eso es bastante suficiente.

Entonces, la habilidad básicamente dice que nada está hecho o pasa sin comandos exactos que produzcan resultados. Una ejecución exitosa que puedes citar o no está hecha. Es decir, si por ejemplo, tienes una tarea, le dices a Cloud que la finalice y la marcará como finalizada. Con verificar por hecho, necesitas tenerlo. Firmará que está verificado con este comando exacto. Este es el resultado, ese es el resultado.

Y luego tenemos una habilidad de flujo de trabajo lineal. Por ejemplo, cuando extraes cosas de Linear, lee comentarios, no solo el cuerpo, rama, árbol de trabajo. Usa superpoderes para planificar e implementar u otros, solo uso superpoderes para planificar, pero puedes usar otros. Haz la verificación e informa la evidencia y no te comprometas. Te comprometes tú mismo, eso es L1. Algunas habilidades personalizadas, algunas públicas que puedes hacer mañana.

Y luego Tomb Raider's L2, sin el demonio, empujas la puerta a una nube y básicamente niegas cosas. Niega comandos git, niega empujes, detienes publicaciones para usar quién ejecuta. Y tienes como un revisor separado en un contexto nuevo. Es decir, ya sea habilidad de revisión de PR o toma el control y llévalo. Usualmente uso ambos. Uso toma el control y también tengo una habilidad de revisión de PR separada que extraerá el PR y hará toda la revisión y lo hará por separado. Una habilidad de bucle de brecha es buena. Lo que hace, usa el objetivo y se vuelve a ejecutar hasta que encuentra todas las brechas que se supone que deben estar allí antes de corregir y luego documenta eso. Y básicamente puedes crear a partir de eso. Otras tareas y las iteras y así sucesivamente.

Luego conectas MCP lineal y luego tienes una conexión de rastreador. Así que es D1, extrae problemas, lee el hilo. Además, construyo todo en un solo sistema, sistema de código abierto. Así que básicamente es como un arnés de nivel L3. Tienes un montón de problemas dentro de Linear, puedes filtrarlos y luego enlistarlos. Tienes un montón de agentes a los que puedes asignar cosas. Tienes un gráfico de dependencias donde puedes analizar las dependencias, obtener el gráfico de dependencias, notificaciones y cosas así. Pero la parte más importante, estamos hablando de automatización aquí y llegar al nivel L3. Sí, tenemos como una línea de tiempo y tengo como el inicio de sesión y eso. Pero luego están estos perfiles de agentes y cada perfil, por ejemplo, estos implementadores, tiene puertas específicas. Lo que puede hacer, ya sea comentar o publicar y tiene su alma, tiene su instrucción. Así que cada agente es diferente. Por ejemplo, tengo un agente de QA que solo puede comentar y no puede enviar el código. Y hay un montón de agentes que vienen con la instalación que puedes reutilizar, como observador de automatización o capacidad o diferentes agentes de debate, ese tipo de cosas. Y también tienes automatización. Así que, por ejemplo, quiero tener cuando tengo un problema aquí, hay este problema que está esperando una entrada. Y está esperando que yo responda aquí. Así que puedo decir, OK, quiero usar esta plantilla para ser un respondedor de entrada. Y ese es mi agente de respuesta de entrada separado. Se activará en un evento específico. Y básicamente tiene esta plantilla de instrucciones. Puedes agregar instrucciones y puedes combinar diferentes filtros para activar esta automatización. Y también hay un montón de plantillas para esto.

Entonces, ¿dónde está el problema aquí? El primero es obviamente el costo. Así que la flota puede quemar un orden de magnitud de más tokens que una sola llamada. Posibilidad de que en una gran migración, pero para el cambio de tres archivos, no lo usaré. ¿Verdad? Luego está el paralelismo que detiene las superficies compartidas. Así que si algo es compartido, necesito básicamente descomponer eso con el esfuerzo de ingeniería o realmente usar un agente diferente para descomponer historias para usarlas más adelante. Y la puerta sigue siendo un sello de goma. Alrededor del 70% de los fallos son cheques verdes que no se verificaron.

No valides la puerta y heredas el punto ciego. Así que todavía necesitas ser muy preciso con las puertas. Y lo importante sobre los números que acabo de usar. Masas de 200 trazas y correcciones de orquestación. Esa es mi experiencia de producción, más la intención del diseño del spec. Así que no es un estudio controlado. Esos son mis pensamientos de la experiencia de producción.

Así que nadie ha ejecutado estos como L3 versus L0 en el mismo backlog. Así que es un spec abierto y contribuye a él, ejecuta el estudio, comparte los datos, discute conmigo sobre eso. Ese es el sistema que funciona para mí. Así que no inventé esto. El campo sigue aterrizando en la misma forma. Así que es la misma forma una y otra vez. Un despachador, aislar trabajadores, puerta que decide hecho.

Construyo Hrevox sobre OpenAI Symphony. Es un spec de OpenAI. Rastreador, aislar espacio de trabajo por tarea, despachar, PR en verde. Luego Sakana, Trinity conductor tiene las mismas ideas. Y luego hay un montón de estudios independientes como Adapt-Org y CodeDelegator tienen las mismas ideas y todo converge en prácticamente el mismo sistema del que creé un spec. Así que no estoy diciendo que lo llamé primero o algo así. Escribí lo que ya funciona, lo que funciona para mí. La gente sigue llegando a la misma forma desde diferentes puntos de partida, lo cual es agradable.

Eso me dice que la idea vale la pena y es fundamental. Y así que iré conmigo mismo sobre si es correcto o no. Así que el cambio no es de codificación a prompting. Y es de codificación a diseñar sistemas que intenten validar y evolucionar el código. Y el modelo recorre las líneas. Y tu ventaja no son las pequeñas líneas de código. Es la orquestación y la descomposición y el contexto compartido y las puertas.

Y puedes verificar la especificación. Puedes verificar caminatas posteriores, y puedes comenzar solo sin un daemon. L1, sé el conductor, alcanza el daemon cuando necesites L3. Discute con la especificación, añade tu lista de implementación de sistemas, realiza el estudio, comparte los datos. Y hay un montón de referencias para consultar. También enlaces a especificaciones y fuentes que utilicé para diferentes estudios que usé. De dónde tomé los números. Y gracias. La codificación ahora es un sistema.

Así que adelante y sé el orquestador del sistema. Haz mejor código. Hola, hola, bienvenido de nuevo. Hola, Vladimir. Hola. ¿Cómo va todo? Va genial. Muchas gracias por tu charla y tu trabajo. Es realmente increíble. Y es necesario hoy en día obtener un conjunto completo de mejores prácticas y arquitectura, vistas de alto nivel que todos necesitamos seguir en el mundo caótico actual.

Solo quiero decirle a nuestra audiencia, por favor no olviden unirse a slido.com si quieren preguntar algo a nuestros ponentes. Si quieren preguntar a Vladimir sobre su charla, por ejemplo. Solo únanse a slido.com. Usen el número que tenemos hoy para AI Coding Summit, que es 0607. Sí, y dejen sus preguntas allí. Estoy bastante seguro de que estaremos encantados de responder eso.

Mientras tanto, ya tenemos algunas preguntas en la lista de espera. Pero solo para comenzar, tengo una pregunta sobre, digamos, arquitectura de alto nivel. Y recientemente hemos tenido muchas charlas que discuten cuáles son las mejores prácticas a seguir en el mundo actual. Y en algún momento, ves que hay algunas similitudes con las prácticas de arquitectura tradicional con las que hemos estado familiarizados durante las últimas décadas. Así que me pregunto, ¿cuál es tu opinión? ¿Cuál es la diferencia clave y las similitudes clave entre la arquitectura moderna basada en AI y la tradicional? ¿Qué piensas?

Sí, esa es una pregunta increíble. Y de hecho, se conecta mucho con una parte de mi charla sobre las puertas de verificación. Y permíteme elaborar un poco sobre esto. Así que cuando hablamos de arquitecturas aquí, quiero enfatizar en la arquitectura de codificación AI. Básicamente, nuestros hábitos de codificación correcta. Correcto. Así que, desafortunadamente, lo que está sucediendo hoy en día, a medida que todos nos inclinamos hacia el uso cada vez más de herramientas AI, siendo más productivos con herramientas AI, hay un montón de mejores prácticas que han estado ahí durante años. Como pruebas de extremo a extremo, pruebas unitarias, todo eso. Y como CI, CI CD adecuado, todo eso. Práctica adecuada de revisión de PR, ¿verdad? Desafortunadamente, hoy en día, cuando ejecutamos nuestros agentes sin verificar mecánicamente las cosas, sin tener estas puertas de verificación, cuando el esquema y los tipos se conforman, cuando el linting pasa, las pruebas unitarias pasan, las pruebas de extremo a extremo pasan, eso es algo que mecánicamente se puede imponer. LLM puede desviarse y lo vemos todo el tiempo. Los modelos evolucionan, pero luego de repente la calidad cae y LLM puede simplemente alucinar, ¿verdad? Pero LLM nunca alucinará si lo obligamos a ejecutar estas puertas de verificación. Y creo que el punto clave ahora es seguir pensando en una arquitectura adecuada y prácticas de revisión adecuadas. Puede ser difícil porque estamos recibiendo enormes PRs impulsados por AI, pero mi opinión es que todavía necesitamos intentar forzar las cosas mecánicamente. Espero que eso responda.

Absolutamente, absolutamente, sí. Es un gran pensamiento. Y para continuar con esta línea de pensamiento, también podemos predecir que aparecerán algunas herramientas, que resumen la revisión de alguna manera para que se puedan hacer fácilmente y más y más. Pero solo para continuar con las preguntas, y la última pregunta sobre el LLM o modelo particular. ¿Has encontrado algún modelo específico que uses como orquestador principal o alguna combinación de variantes que funcione mejor para ti? Es una pregunta difícil porque evoluciona todo el tiempo. Diría que uso Opus, pero luego la otra semana cambié a Codex, luego la otra semana cambié a Fable, luego Fable fue limitado, cambié de nuevo. Está cambiando todo el tiempo. Pero lo que sí creo, como mejor práctica, es que necesitas evaluar constantemente los resultados de tus modelos. Y puedes evaluar eso creando un arnés local que básicamente registrará tus lecciones aprendidas de interactuar con los agentes. Y basado en eso, puedes evaluar si un arnés funciona para ti frente a otro. Pero usualmente hago multi-arnés. Así que esa es la razón por la que construí IterVox, por ejemplo. Así que ocasionalmente tengo cosas escritas con el código, y luego reviso con Codex o viceversa. Y luego los dejo discutir entre ellos y encontrar la mejor solución. Y obviamente reviso todo yo mismo también.

Absolutamente, absolutamente. Creo que no eres el único que lo está haciendo ahora mismo. Esa es una técnica muy buena, de hecho. Hay otra propuesta de uno de los oyentes. Hablando de orquestadores, ¿qué piensas si tenemos capas de orquestadores? ¿Nos beneficiaría en términos de construir una mejor arquitectura, crees? ¿Has intentado algo así ya? Sí, definitivamente. La idea completa es que necesitamos el principal, pero luego obviamente podemos ramificarnos en múltiples. Por ejemplo, te daré el ejemplo general. Si creas múltiples agentes, ¿verdad? Uno de los agentes está llamando a otros, y esta hoja en el árbol es el orquestador, pero repulsa al principal. Y de esa manera, tienes una especie de árbol que informa de nuevo al primero, al original. Pero el punto completo es que toda la transferencia del orquestador hasta el árbol no puede desviarse, tanto mecánicamente como no puedes comunicarte entre sí y trabajar en la misma rama y en los mismos árboles de trabajo y así sucesivamente. Así que los pros, obviamente, separas las preocupaciones, ¿verdad? Si, digamos, tienes un agente que está a cargo de la arquitectura, puedes separar eso en backend y frontend, como una separación obvia, ¿verdad? Pero luego lo que tienes al final, si no eres consciente de cuánto pones en el contexto, entonces solo quemas tokens. Así que el costo es la desventaja obvia. Si tienes una cantidad infinita de dinero, simplemente no te importa eso. Pero ninguno de nosotros tiene una cantidad infinita de dinero, así que necesitamos ser conscientes de que a medida que introduces más y más orquestadores y agentes y así sucesivamente, eso introduce más costo de tokens. Y lo veremos al final del mes.

Sí, nadie lo tiene, excepto quizás algunos ingenieros en Amazon, y eso fue hace un par de meses atrás. La siguiente sería sobre herramientas y software concretos, tal vez que cubriste un poco. ¿Qué aporta GraphTile y CodeRabbit frente a AI CodeReview? ¿Los has probado? Básicamente, solo la conveniencia, supongo. Como GraphTile y CodeRabbit, simplemente los conectas al repositorio, simplemente los usas. Como mencioné en la charla, también uso mi propia habilidad de revisión de PR, que es porque tengo un control muy granular sobre eso. Lo uso además de esas herramientas. Lo que me gusta específicamente de GraphTile y CodeRabbit es que también tiene esto, pone el resumen en tu PR y básicamente puedes configurarlo al nivel de conformidad, diciendo, está bien, si es como cinco de cinco, entonces solo entonces pasa el PR. Pero luego no es como una varita mágica, ¿verdad? Aún necesitas hacer tus propias revisiones de PR. Usualmente, además, agrego mi propio arnés encima de eso. Pero GraphTile es muy configurable y CodeRabbit también. También es configurable.

Genial. Sí, el siguiente es muy interesante. Tengo algunas preguntas adicionales sobre eso. ¿Has considerado conectar herramientas de observabilidad en tu patrón de orquestación? Algunos agentes específicos para clasificar o incluso solicitar intervención humana para cualquier cosa que se haya hecho durante el ciclo. Mi pregunta adicional a eso sería qué se usa realmente bajo el capó. ¿Qué protocolo, quiero decir, para que los agentes se comuniquen entre sí? Así que sí, buenas preguntas. Aquí, quiero profundizar un poco más en EtherVox que presenté. Así que EtherVox bajo el capó, y también a tu pregunta, bajo el capó, está escrito en Go. Utiliza un bucle de eventos que básicamente construye los prompts de codex con prompts de construcción adecuados de diferentes agentes y lo que sea que traiga al contexto. Y específicamente para herramientas de observabilidad y agentes allí, así que mostré las automatizaciones allí y un montón de agentes. Así que uno realmente interesante que tengo, y de hecho un caso de uso en producción que vi, como algunos comentarios que recibí. Digamos que si creas un montón de problemas lineales y simplemente los creas, no como un gerente de producto, sino simplemente diciendo, oh, arregla eso. Algo muy vago. Obviamente, requerirá entrada adicional de un humano. Así que tengo automatizaciones y agentes específicos, vienen con la plantilla cada vez que instalas el EtherVox. Luego, de hecho, hay un cron que se ejecuta y extrae problemas lineales. Y cuando hay nuevos problemas, básicamente evaluará con otros codex, tienes como una configuración completa para eso. Evaluará si el problema tiene suficientes datos y también puede verificar las dependencias dentro del mismo espacio de trabajo si tiene dependencia de otros problemas. Basado en eso, te hará preguntas y tendrá como un patrón de humano en el ciclo aquí. Y también, en términos de observabilidad, también hay agentes adicionales que pueden clasificar cosas, ponerlas en tareas pendientes, luego las tareas pendientes son recogidas por el bucle de eventos, va a la cola.

Hay como todo un sistema alrededor de eso. La base de código que comparto, el EtherVox, también tiene un sitio web con un montón de guías que detallan cómo hacer eso. Y doy la bienvenida a todos a abrir issues, también para la especificación que comparto, compartan sus pensamientos sobre eso, discutan conmigo, estoy totalmente abierto a discutirlo más.

Eso es increíble. Sí, el último que tenemos hasta ahora en la cola es, ¿cómo se hace para imponer mecánicamente la arquitectura? Bueno, comencemos con los tipos obvios, eso es como lo obvio, ¿verdad? Pero eso no es solo arquitectura, ¿verdad? Pero la arquitectura tiene múltiples capas, cada capa tiene algún tipo de imposición. Si estamos hablando de, digamos, bases de datos, entonces tenemos como, podemos escribir pruebas para bases de datos, ¿verdad? Y si tenemos cierta arquitectura dentro de la nube, podemos usar infraestructura como código, como Terraform o CDK, y luego podemos probar eso e imponerlo también.

Podemos tomar instantáneas de las decisiones, ¿verdad? Y podemos hacer diferencias entre ellas, ese es otro patrón. Otra cosa que es realmente útil es, a medida que avanzas en tu proceso de codificación, o hablando con agentes hoy en día, ¿verdad? Siempre les pides que generen una salida visual dentro de la sintaxis de mermaid, luego tienes diagramas que puedes evaluar más fácilmente, y también puedes hacer diferencias entre estos diagramas y ver si algo se ha desviado. Tienes información sobre eso. También hay un montón de herramientas para verificar, un montón de cosas de copiar y pegar como Knip, por ejemplo, o un montón de bibliotecas de Rust que son más de bajo nivel, pero en lugar de pedirle a un agente que encuentre, copie y pegue el código y espere lo mejor, puedes realmente ejecutar estas herramientas.