Anthropic acaba de solucionar el mayor fallo de la ingeniería de grafos

AAI LABS
컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00Hay un nuevo término dando vueltas llamado ingeniería de grafos, y todo el mundo habla de ello en X.
00:00:04Antes de los grafos, todo era ingeniería de bucles, donde le dabas un objetivo al agente y este trabajaba
00:00:09por su cuenta. Pero con los grafos, el trabajo se hace más rápido y abarca mucho más terreno a la vez de lo que
00:00:14un bucle jamás podría. Sin embargo, hay un gran problema con ellos. Un solo error en una pequeña parte del
00:00:18grafo altera todo el resultado final, y es difícil de rastrear porque todo lo que obtienes
00:00:23al final es el resultado terminado. Así que Anthropic acaba de lanzar algo que resuelve exactamente ese
00:00:27problema y mantiene tus grafos funcionando sin fallar. Si eres nuevo por aquí, somos una empresa
00:00:32de software, y este es nuestro canal AI Labs, donde te mostramos cómo optimizar tu negocio con IA,
00:00:37y si no tienes uno propio, puedes usar estas habilidades para ganar dinero optimizándolo para alguien
00:00:42más. Y en este video, vamos a repasar la ingeniería de grafos para cualquiera que no la conozca
00:00:46y les daremos la solución exacta que sugirió Anthropic. Antes de explicarte la ingeniería de grafos, debes
00:00:52entender qué es realmente la ingeniería de bucles. Si ya lo sabes, puedes saltarte esta sección.
00:00:56Un bucle es básicamente un ciclo de trabajo que le entregas al agente. En lugar de estar guiándolo
00:01:02en cada paso tú mismo, le indicas el objetivo final al que debe llegar y lo logra por su cuenta,
00:01:07haciendo ajustes sobre la marcha. Los hemos usado mucho en nuestros flujos de trabajo. Ya tenemos un video completo
00:01:12sobre ingeniería de bucles, donde profundizamos en las distintas formas de configurarlos, pero los bucles
00:01:17ahora se están convirtiendo en algo llamado grafos. El problema con los bucles se reduce a cómo están construidos.
00:01:22Un bucle realiza una tarea y luego entra un paso de verificación para ver si realmente quedó como debería
00:01:27estar. Una vez que aprueba, comienza el siguiente paso. Todo se ejecuta en línea recta, por lo que cada paso se queda
00:01:32esperando al anterior, incluso cuando los dos no tienen nada que ver entre sí. La ingeniería de grafos
00:01:37soluciona exactamente eso. En lugar de ejecutarse en línea recta, un grafo divide la tarea principal en partes más
00:01:42pequeñas, y cada parte recibe su propio agente. Lo primero que obtienes de eso es velocidad, porque varios
00:01:47agentes cubren el trabajo a la vez, en lugar de un solo agente matándose con todo el proceso. Y dividir el
00:01:52trabajo de esa manera también reduce un poco los costos, porque puedes elegir qué modelo ejecuta cada
00:01:56se ejecuta. Así dejas de desperdiciar tu modelo más caro en tareas que nunca necesitaron tanta
00:02:01inteligencia en primer lugar. Pero ese es el costo por agente, no el costo general. Un grafo consume bastantes más
00:02:07tokens que un solo agente, porque tienes a un conjunto entero funcionando al mismo tiempo en lugar de a uno solo.
00:02:12Si usas grafos, es de esperar que alcances tus límites mucho antes de lo habitual, por lo que realmente
00:02:17no puedes configurar esto con los planes de $20 de ClaudeCode y Codex. Ahora, si has estado usando ClaudeCode,
00:02:22esto probablemente no sea del todo nuevo para ti, porque ya has visto un grafo, que es el flujo de trabajo
00:02:27dinámico. Un flujo de trabajo dinámico toma la tarea que le asignas y la distribuye entre un grupo de subagentes,
00:02:33que es básicamente lo que hace un grafo. Antes de entrar en las formas que puede tomar un grafo, debes
00:02:38saber de qué está compuesto en realidad. Todo grafo se construye a partir de dos cosas: nodos y aristas. Un nodo es
00:02:44básicamente un trabajo individual de la tarea más grande que entregaste, y se ejecuta por su cuenta. Es un agente
00:02:49que realiza una tarea en su propia ventana de contexto aislada y reporta los avances. Lo que une todas esas tareas
00:02:55separadas es la arista. Una arista controla cómo se mueven los datos de un nodo al siguiente, de modo que el resultado de un agente
00:03:01llegue al agente correcto en el momento adecuado. Así que cada nodo tiene que estar conectado al resto del grafo
00:03:06de alguna manera. Puedes ver eso en un conjunto de agentes que revisan el mismo trabajo. Ninguno
00:03:10espera jamás al otro. Pero todos partieron del mismo trabajo, y cada uno de sus informes se alimenta
00:03:15en el mismo lugar al final, así que de eso está hecho un grafo. Ahora, aquí están las formas en que esas piezas
00:03:20se organizan. La primera es una estructura que ya les hemos mostrado en este canal, y le dimos un nombre
00:03:25incorrecto en su momento. Lo llamamos bucle, porque esto fue antes de que la ingeniería de grafos fuera una realidad. Pero
00:03:30lo que realmente teníamos era un grafo en bucle, y su forma era un diamante. Una tarea en la
00:03:35parte superior se divide en varios subagentes que se ejecutan en paralelo, luego todos se reducen nuevamente a un solo
00:03:41agente que reúne todo lo que encontraron en una sola respuesta. Luego está el grafo de convergencia con barrera,
00:03:46y esa es la estructura que deseas cuando hay que evaluar algo desde varios ángulos a la vez. La parte de divergencia
00:03:51envía el mismo problema a un conjunto de agentes, y cada uno lo analiza a través de una perspectiva diferente.
00:03:56Nada avanza hasta que cada uno de esos agentes haya enviado su informe, y solo entonces
00:04:00se procede a ejecutar sus correcciones. Hay muchas otras estructuras también. Pero cada una de ellas se apoya en
00:04:05lo mismo: la verificación. Si no configuras esas comprobaciones correctamente, cada agente posterior
00:04:10solo se estará basando en un error. Pero antes de hablar sobre la verificación, sería genial si te
00:04:15suscribes al canal y le das al botón de me gusta. Este pequeño gesto de apoyo significa mucho para nosotros.
00:04:20Una vez que estás ejecutando toda una flota de agentes, las cosas salen mal de formas que jamás ocurren con uno solo.
00:04:25El mayor problema es simplemente la cantidad de trabajo. Todos están avanzando al mismo tiempo, así que una gran montaña
00:04:30de datos regresa de golpe, y eso es realmente difícil de revisar al final. El otro problema es que
00:04:34no puedes ver qué sucedió. Cuando algo sale mal, no tienes forma de saber qué lo causó.
00:04:39Ahora bien, todos los agentes verifican lo que escriben, se lo pidas o no. Si estás trabajando con código,
00:04:44eso solo significa que el agente ejecuta tus pruebas y detecta los errores que devuelven. Pero eso solo detecta errores
00:04:49mayores. Todavía no comprueba cómo está escrito el código, y eso es importante porque si Claude
00:04:53sigue escribiéndolo de esa manera, causará problemas en el futuro. Hay algunas herramientas
00:04:58integradas para esto en ClaudeCode también. La primera es la habilidad verify, que toma el código de principio
00:05:03a fin y confirma que realmente se comporte como se supone que debe hacerlo. La segunda es el encadenamiento de herramientas,
00:05:08que básicamente es el agente ejecutando diferentes herramientas para verificar. Claude ya sabe ejecutar las herramientas que
00:05:13revisan tu trabajo, así que lee los errores devueltos y los corrige por sí mismo. También puede descifrar los
00:05:18comandos exactos de tu proyecto por su cuenta. Pero escribirlos en tu archivo Claude.md le ahorra la molestia
00:05:24de tener que deducirlos cada vez. Y la tercera es una habilidad de revisión de código, que contrasta el código
00:05:29con un conjunto de estándares. No todos los agentes vienen con una, pero puedes pedirle a tu agente que construya
00:05:33una si el tuyo no la tiene. Pero la verificación que realmente funciona mejor es la que configuras tú mismo,
00:05:38en lugar de depender totalmente de lo que viene integrado. Así que la forma más rápida de crear una habilidad que verifique
00:05:44tu trabajo es el complemento skill creator en ClaudeCode. También puedes usar esta habilidad de ClaudeCode en
00:05:49Codex. Ejecutas el comando del complemento, buscas skill creator e instalarlo. A partir de ahí,
00:05:54tienes dos opciones. Puedes instalarlo a nivel de usuario, lo que significa que estará disponible sin importar en qué
00:05:58carpeta estés trabajando. O puedes instalarlo solo para el proyecto en el que trabajas en ese momento.
00:06:03Como esta es una habilidad que usarás constantemente, elegimos el alcance de usuario. Después de eso,
00:06:07recargas los complementos con el comando de barra diagonal y skill creator estará listo para usarse. Ahora le dices
00:06:12lo que quieres construir y esta es la parte donde describes el tipo de verificación que realmente
00:06:17buscas. Nosotros usamos principalmente una habilidad de revisión para contrastar el trabajo terminado con lo que pedimos al
00:06:22principio. Y eso importa mucho más en un grafo porque cada agente solo ve su propia parte.
00:06:28Esto es lo que le da una forma de verificar esa parte frente a los requisitos originales. Pero una habilidad solo
00:06:32es tan buena como el modelo en el que se ejecuta. Cuando estábamos construyendo el sistema de verificación para la
00:06:37interfaz de nuestro sitio web comunitario, ejecutamos el revisor en Haiku porque es económico y la tarea parecía lo suficientemente
00:06:43simple. Regresó con una larga lista de problemas. A juzgar solo por el número de hallazgos, parecía
00:06:47que había hecho un gran trabajo. Luego ejecutamos exactamente lo mismo en Opus y marcó muchísimas menos cosas.
00:06:53Eso parecía el peor resultado, hasta que leímos el razonamiento. Mucho de lo que Haiku había reportado
00:06:58era material que habíamos dejado allí a propósito. Así que la mayoría de sus hallazgos eran completamente innecesarios.
00:07:03Opus lo dedujo a partir del código circundante, algo que Haiku pasó por alto por completo. Así que la revisión
00:07:08económica no nos ahorró nada porque ahora la revisión misma necesitaba ser revisada. Ahora coloca eso dentro
00:07:13de un grafo donde todo un conjunto de nodos revisa su propio trabajo con esa misma habilidad. Tendrías
00:07:18agentes perdiendo tiempo y tokens arreglando cosas que nunca estuvieron rotas. Y como ocurre a través de
00:07:23agentes independientes al mismo tiempo, no tendrías forma de saber cuál de ellos lo comenzó.
00:07:27Así que el modelo que elijas no solo decide la calidad de la revisión, sino que decide la calidad
00:07:31de todo el grafo. El nodo que hace la evaluación es el único lugar donde ahorrar tokens te cuesta
00:07:37todo. La otra cosa que debes decidir es cómo y cuándo se invoca esa habilidad. Y eso
00:07:41las divide en tres tipos. Pero antes de profundizar en los tipos, escuchemos un mensaje de nuestro patrocinador.
00:07:46Si alguna vez has extraído datos en vivo de la web, sabes que el scraping es un dolor de cabeza, donde terminas
00:07:51luchando contra captchas y límites de velocidad, lidiar con proxies y arreglar diseños que se rompen en el
00:07:56momento en que los lanzas. Por eso recurrimos a SERP API, que resuelve todos estos problemas para que te concentres en construir.
00:08:01Es una sola llamada a la API, envías una solicitud y recibes un objeto JSON limpio con exactamente los datos que necesitas,
00:08:07con más de un 99.9% de tiempo de actividad y una respuesta de alrededor de 1.2 segundos. Cuando estás creando agentes de IA, puedes
00:08:14apuntar la API de búsqueda de Google a un agente que necesite información actualizada o usar la API de Google Scholar para
00:08:20artículos revisados por pares con metadatos completos, por lo que muchos agentes en producción confían en ella. Empieza con
00:08:25250 créditos gratuitos usando el enlace en la descripción o escanea el código QR en pantalla. Gracias a SERP API por
00:08:32patrocinar este video. El primer tipo es independiente, y es el tipo de habilidad que solo se ejecuta cuando
00:08:37tú mismo la activas. Una habilidad independiente está diseñada para profundizar en algo que ya existe, de modo que pueda
00:08:42revisar adecuadamente un resultado final. Por eso no quieres que se active tras cada ejecución. Estarías
00:08:48gastando tokens en una revisión pesada de un trabajo que ni siquiera ha terminado. Una que hemos usado antes es la
00:08:53revisión de código termonuclear de Cursor. Despliega un conjunto de agentes y envía a cada uno a revisar el código desde
00:08:59un ángulo de seguridad diferente. Cada hallazgo regresa a un solo lugar para poder abordar las correcciones
00:09:04en conjunto, y ese es exactamente el tipo de revisión que solo ejecutas cuando la app está lista. Para crear una de estas, es mejor usar
00:09:10skill creator en lugar de simplemente pedirle que lo haga, porque lo que devuelve ya está probado, y eso facilita
00:09:15confiar en el resultado. Le indicas en el prompt qué área quieres que revise y te aseguras de mencionar que la
00:09:20revisión debe ser exhaustiva para que sepa que buscas una revisión profunda y no una rápida. Pero una habilidad
00:09:26independiente no sirve para un nodo que todavía está trabajando, porque tienes que ejecutarla tú mismo. Para eso sirven las
00:09:31habilidades integradas. Una habilidad integrada se activa como parte del flujo de trabajo que ya ejecutas sin que la
00:09:36solicites. Podrías crear una que se active cada vez que alguien pida una nueva función. Verifica que
00:09:41cada componente creado siga las reglas que estableciste en la habilidad, y no permitirá que la
00:09:45implementación termine hasta que haya sido verificada contra esas reglas. Puedes crear habilidades integradas
00:09:50tú mismo, pero no puedes tomar una preinstalada y hacer que se invoque automáticamente, como la
00:09:54habilidad verify de la que hablamos antes. Las instrucciones bajo las que se ejecutan esas habilidades están dentro del producto y
00:10:00no puedes modificarlas. Para crear la tuya, dale a skill creator un prompt pidiéndole que ejecute pasos de verificación
00:10:05después de la implementación de cada función, así que indícale que pruebe la función de principio a fin para que
00:10:10detecte si el nuevo trabajo rompió algo que ya estaba funcionando. Claude genera la habilidad por
00:10:16ti, y como skill creator la generó, incluye referencias y scripts que skill creator
00:10:21estructuró y probó como parte del proceso. Ahora, para verificar una función, Claude usa pruebas de navegador por
00:10:26defecto, donde comprueba la interfaz abriendo un navegador Chrome completo, cargando la página y tomando
00:10:31capturas de pantalla. Y si has configurado Puppeteer o Playwright, que son básicamente las herramientas que
00:10:36la mayoría utiliza para controlar un navegador automáticamente, hacen lo mismo. Pero Chrome es famoso por consumir memoria
00:10:41y ser pesado, y para revisar una página una y otra vez dentro de un flujo de trabajo, es tan lento que
00:10:46empieza a costarte tiempo real. Por eso hay una forma más ligera de hacerlo, llamada Chrome Headless Shell. Es básicamente
00:10:52una versión reducida del navegador a la que se le han quitado todas las partes extra. El agente aún accede a
00:10:57la página y toma sus capturas de pantalla de la misma manera. Simplemente realiza todo mucho más rápido que un
00:11:02Chrome completo. Puedes integrar eso directamente en la habilidad de verificación que crees. Así, cada función
00:11:07que construya el agente se revisa visualmente sin que tengas que configurar nada cada vez. Aparte de eso,
00:11:12la habilidad que más usamos en nuestro propio flujo de trabajo es una llamada second opinion, y la razón es simple.
00:11:17El agente que construyó la función es el peor candidato posible para revisarla. Evalúa su propio trabajo basándose en el
00:11:23mismo contexto que usó para construirlo, así que solo revisa en función de eso. Una sesión nueva de Claude no ha visto
00:11:28nada de eso. Ofrece una revisión imparcial y te da una respuesta directa. Claude tiene un asesor
00:11:33integrado que hace algo similar, pero lee el chat en el que te encuentras actualmente, por lo que hereda
00:11:38todo ese mismo contexto. Second opinion sirve para cuando quieres la revisión sin ese contexto. Funciona iniciando
00:11:43otra sesión de Claude desde la que ya estás ejecutando, usando el parámetro -p. Ese es el
00:11:48parámetro que lanza una sesión independiente de ClaudeCode en segundo plano pasándole un prompt para
00:11:53trabajar. Sin embargo, hay un par de cosas que debes saber si vas a usar esto. Dado que
00:11:57inicia una sesión completamente independiente, toma bastante tiempo en regresar con una respuesta,
00:12:02y el modelo importa aquí más que en cualquier otro lugar, porque el objetivo es una segunda lectura más inteligente.
00:12:07Así que vale la pena decirle explícitamente a Claude que inicie esa sesión en Opus. Eso le da a cada nodo de tu
00:12:12grafo una forma de revisar su trabajo mediante algo que no intervino en su elaboración. Sin embargo, una sola habilidad no puede
00:12:18cubrirlo todo. Cuando revisas algo correctamente, lo revisas desde varios
00:12:22ángulos diferentes, y cada ángulo tiene su propia forma de medir. No puedes meter todos los tipos de revisión en
00:12:27una sola habilidad, porque de esa manera el agente tendrá demasiadas instrucciones que revisar y terminará empeorando
00:12:33en lugar de mejorar. Así que construyes una habilidad independiente para cada ángulo y las encadenas. El propio
00:12:38equipo de Anthropic también trabaja de esta manera. Encadenan la habilidad de revisión de código con la habilidad simplify y la habilidad
00:12:43verify, y las tres vienen ahora incluidas con ClaudeCode. Además de eso, ejecutan su propia habilidad de diseño,
00:12:49que contrasta la interfaz con el archivo design.md, que es básicamente el archivo que contiene cada
00:12:54decisión de diseño del producto. Así que esa es una revisión que viene desde cuatro direcciones en lugar de una. Terminarás
00:12:59en el mismo lugar, con un conjunto de habilidades que cubren cada una un ángulo diferente. Pero no puedes simplemente
00:13:04pedirle al agente que las ejecute todas a la vez. Lo que necesitas es una habilidad más por encima de las demás,
00:13:09que es básicamente una habilidad orquestadora cuyo único trabajo es ejecutar otras habilidades. Esta inicia un agente por
00:13:15cada habilidad de revisión que tienes y le entrega a cada uno su correspondiente habilidad. Todos revisan al mismo tiempo en sus
00:13:20propias ventanas de contexto independientes. Luego reúne todos los hallazgos en un solo informe a partir del cual los agentes de corrección
00:13:25pueden trabajar. Así, cuando estás construyendo un grafo, lo único que tienes que decir en el prompt es que
00:13:30debe usar esa única habilidad. Cada nodo que inicia carga esa sola habilidad y toda la revisión se despliega
00:13:35por debajo por sí sola. Ahora, hemos preparado un documento que contiene todas las formas detalladas en que puedes configurar
00:13:40verificaciones para grafos. Ese documento, junto con todas las habilidades mostradas en este video, están disponibles
00:13:45en AI Labs Pro, que es nuestra comunidad. Así que si has encontrado valor en lo que hacemos y quieres apoyar al
00:13:50canal, esta es la mejor manera de hacerlo. El enlace está en la descripción. Eso nos lleva al final de este
00:13:55video. Si te gustaría apoyar al canal y ayudarnos a seguir haciendo videos como este, puedes hacerlo
00:14:00usando el botón de Súper gracias abajo. Como siempre, gracias por ver el video y los veré en el próximo.

Key Takeaway

La ingeniería de grafos acelera el desarrollo con agentes en paralelo, pero requiere orquestar habilidades de verificación independientes y utilizar modelos avanzados como Opus para evitar la acumulación de errores en la cadena de nodos.

Highlights

  • La ingeniería de grafos sustituye a los bucles lineales dividiendo una tarea principal entre múltiples agentes independientes que trabajan en paralelo.

  • Un grafo de agentes consume más tokens que un solo agente en bucle, superando rápidamente las cuotas de los planes estándar de $20 de ClaudeCode y Codex.

  • Ejecutar evaluaciones de código en el modelo Haiku genera una gran cantidad de falsos positivos que requieren revisión manual, a diferencia del modelo Opus que comprende el contexto del código.

  • El uso de Chrome Headless Shell reduce el consumo de memoria y acelera la verificación visual respecto al uso de una instancia completa de Chrome en Puppeteer o Playwright.

  • Lanzar una segunda sesión independiente de ClaudeCode mediante el parámetro -p con el modelo Opus permite realizar evaluaciones sin el sesgo del contexto acumulado.

  • Una habilidad orquestadora permite desplegar un agente especializado por cada tipo de revisión y consolidar los resultados en un informe único.

Timeline

Evolución de la ingeniería de bucles a la ingeniería de grafos

  • Los bucles lineales fuerzan a los agentes a esperar la aprobación de cada paso antes de iniciar el siguiente.
  • La ingeniería de grafos asigna subagentes a tareas secundarias que se ejecutan simultáneamente.
  • El uso de grafos incrementa el consumo total de tokens al mantener flujos de trabajo paralelos activos.

En la ingeniería de bucles, los agentes trabajan en secuencias lineales donde cada verificación detiene el avance, incluso en tareas sin dependencia entre sí. La arquitectura de grafos divide la tarea general entre subagentes paralelos con contextos aislados, optimizando la velocidad y permitiendo asignar modelos económicos a tareas simples. Sin embargo, esta ejecución simultánea multiplica el volumen global de tokens gastados.

Anatomía y estructuras principales de un grafo de agentes

  • Los nodos representan trabajos individuales en contextos aislados y las aristas dirigen el flujo de datos entre ellos.
  • El grafo en bucle o diamante consolida en un solo agente el trabajo procesado previamente por varios subagentes paralelos.
  • El grafo de convergencia con barrera detiene la ejecución general hasta que todos los agentes de análisis emiten su informe.

Un grafo de IA se compone estructuralmente de nodos y aristas. Cada nodo funciona como un agente independiente que resuelve una subtarea, mientras que las aristas gestionan la transferencia de datos hacia el nodo correcto. Existen patrones como el de diamante, que expande el trabajo en paralelo para luego condensarlo en una única salida, y el de convergencia con barrera, que bloquea el avance del sistema hasta reunir las evaluaciones de todos los ángulos analizados.

Impacto de la selección de modelos en las habilidades de verificación

  • Los errores producidos en un nodo inicial se propagan a través de todas las aristas subsiguientes del grafo.
  • El complemento skill creator permite estructurar verificaciones personalizadas con alcance de usuario o de proyecto en ClaudeCode y Codex.
  • El modelo Haiku reporta código intencional como fallo debido a su limitada capacidad para deducir el contexto general del proyecto.

Los fallos en un grafo son difíciles de rastrear si no se implementa una capa de comprobación en cada nodo. Al evaluar código con el complemento skill creator, la elección del modelo subyacente resulta determinante. En pruebas de rendimiento, el modelo Haiku marcó como errores fragmentos de código dejados a propósito, mientras que el modelo Opus interpretó correctamente el contexto circundante, evitando reparaciones innecesarias que malgastan tiempo y tokens.

Tipos de habilidades: independientes e integradas

  • Las habilidades independientes se ejecutan por activación manual al concluir el trabajo para no malgastar tokens durante el desarrollo.
  • Las habilidades integradas comprueban automáticamente que cada nueva función cumpla con las reglas antes de dar por terminada la tarea.
  • El motor Chrome Headless Shell reduce el uso de memoria en las pruebas de interfaz frente a navegadores Chrome completos.

Las habilidades de verificación se dividen según su momento de invocación. Las independientes se reservan para revisiones profundas al final de un proceso, como las auditorías de seguridad sobre código terminado. Las habilidades integradas se disparan automáticamente tras implementar una función, utilizando entornos ligeros como Chrome Headless Shell para capturar imágenes de la interfaz sin la carga de memoria de un navegador convencional.

Evaluación imparcial con second opinion y arquitectura orquestadora

  • El parámetro -p permite iniciar una sesión paralela en ClaudeCode para evaluar el trabajo sin la interferencia del historial previo.
  • Acatar múltiples criterios de revisión dentro de una sola habilidad degrada la precisión del agente.
  • Una habilidad orquestadora lanza un agente por cada tipo de revisión para ejecutar la evaluación en paralelo.

El agente que crea una función no debe ser el mismo que la evalúe, ya que conserva los sesgos de su ventana de contexto. La función second opinion resuelve esto abriendo una sesión independiente en segundo plano mediante la bandera -p, preferiblemente sobre el modelo Opus. Para evitar saturar a los agentes con instrucciones excesivas, el diseño óptimo utiliza una habilidad orquestadora superior que invoca subagentes especializados en diseño, simplificación y pruebas antes de generar un reporte final.

Community Posts

View all posts