Lo que podemos aprender del experimento de Cursor con SQLite y Rust
MMaximilian Schwarzmüller
컴퓨터/소프트웨어AI/미래기술
스크립트
00:00:00Reescribieron SQLite en Rust.
00:00:02Y sé que acabamos de tener la reescritura de Bun en Rust
00:00:04y te preguntarás por qué todo el mundo está reescribiendo
00:00:06todo en Rust, pero esto no se trata de Rust.
00:00:09Esto ni siquiera se trata de SQLite.
00:00:11Soy consciente de que existe la base de datos Turso,
00:00:15que ya es una reimplementación modernizada
00:00:18de SQLite en Rust.
00:00:19Esa es la que quieres usar
00:00:21si buscas una base de datos basada en Rust y SQLite
00:00:23lista para producción.
00:00:26En cambio, este experimento, mini SQLite,
00:00:29que está enlazado abajo y puedes revisar,
00:00:32no se trata de SQLite ni de Rust.
00:00:34Es más bien un experimento del equipo de Cursor,
00:00:37que se enfoca en enjambres de agentes e ingeniería
00:00:40de un sistema de agentes de IA para descubrir qué funciona
00:00:44y qué no al construir algo
00:00:47como SQLite partiendo únicamente de su documentación,
00:00:51porque de eso trata este experimento.
00:00:53Hay un artículo de blog súper detallado y muy interesante,
00:00:56y profundizaremos en él.
00:00:57Contiene muchos aprendizajes interesantes de los que
00:00:59tenemos que hablar y que también verás enlazados abajo,
00:01:02donde explican cómo ejecutaron este experimento; el punto de partida
00:01:07y la idea del experimento era tomar la documentación de SQLite,
00:01:12que al final son 835 páginas si la pusieras toda en un solo documento,
00:01:18la cual está redactada, por supuesto, pensando en humanos.
00:01:23Digo, no es la documentación más accesible que haya visto jamás,
00:01:27pero obviamente está hecha para personas porque es mucho más antigua que los agentes de IA.
00:01:32Sin embargo, también funciona como una especificación ultra detallada,
00:01:37ya que describe minuciosamente cómo usar SQLite
00:01:43y cuál es el comportamiento o las funciones previstas.
00:01:48El equipo de Cursor tomó esa documentación
00:01:52y luego usó un conjunto de pruebas público, la prueba SQLogic,
00:01:57que consta de una serie de pruebas para evaluar el comportamiento de SQLite
00:02:02o para probar consultas específicas.
00:02:05Y usaron eso para comprobar si la implementación
00:02:09creada por sus agentes a partir de esa documentación
00:02:13realmente funcionaba con esa enorme suite de pruebas oficial.
00:02:19Ahora, un par de advertencias importantes de antemano.
00:02:23Esta suite de pruebas se enfoca en evaluar consultas y su comportamiento.
00:02:29No prueba todas las características ni todas las capacidades que tiene SQLite.
00:02:35No evalúa el rendimiento en general.
00:02:38Tampoco evalúa la concurrencia.
00:02:40Hay muchísimo en SQLite que esto no pone a prueba.
00:02:44Y este resultado del experimento, mini SQLite, es solo uno de los resultados,
00:02:49ya que de hecho reconstruyeron SQLite varias veces con distintas combinaciones de agentes.
00:02:53Y ya profundizaremos en eso; sirve verdaderamente solo como algo para explorar.
00:02:57No está listo para producción.
00:02:59No es algo que quieras usar.
00:03:01Es simplemente el resultado de un experimento cuyo objetivo era usar la documentación
00:03:06para reconstruir SQLite y lograr que esa versión reconstruida superara todas esas pruebas.
00:03:13Y el equipo de Cursor usó varias combinaciones de modelos aquí.
00:03:17¿Por qué combinaciones?
00:03:18Porque, como veremos, utilizaron un enfoque
00:03:21en el que varios agentes trabajaban juntos: planificadores, ejecutores y revisores.
00:03:28Reconstruyeron esa base de datos SQLite con distintas combinaciones y luego midieron para obtener una calidad similar.
00:03:37Todas estas combinaciones alcanzaron el mismo nivel de calidad y la misma cantidad de pruebas superadas, pero midieron cuánto costaba cada una.
00:03:45Por ejemplo, usar GPT 5.5 para todo —planificadores y ejecutores— llevó a un costo de implementación de SQLite en Rust, basado en la documentación, de unos $10,000.
00:03:59Por otro lado, combinar Opus 4.8 con Composer 2.5 (siendo Composer 2.5 ese modelo de Cursor súper rápido, muy barato y eficiente, aunque no súper inteligente), dio la misma calidad y la misma cantidad de pruebas superadas por una fracción del costo, solo $1,300.
00:04:24La idea consistía en usar Opus 4.8, que es el modelo más capaz, para la planificación y el diseño de tareas, que luego se delegaban a los agentes ejecutores con Composer 2.5.
00:04:39Y esa es una lección importante de este artículo, que no es algo novedoso, por supuesto.
00:04:44Tú también puedes aplicarlo si estás desarrollando software.
00:04:47Es buena idea dividir tu trabajo, según la complejidad, claro, en distintas tareas ejecutadas por diferentes agentes usando subagentes, donde algunos se enfoquen en la planificación,
00:05:03diseñando una parte concreta del trabajo general como una tarea individual, para luego tener una cantidad de agentes que implementen esa tarea.
00:05:14Resulta que para simplemente generar buen código no necesitas inteligencia de vanguardia si el contexto es adecuado.
00:05:24Es decir, si la tarea está claramente definida, si toda la información útil está en la descripción, y luego, claro, influyen otros factores.
00:05:33Por ejemplo, importa cómo se ve la base de código circundante o la apariencia de los ejemplos que le proporcionas a un agente.
00:05:39Todo eso influye en el resultado, pero los agentes ejecutores que solo escriben código pueden ser numerosos si la tarea está bien especificada y el contexto es bueno.
00:05:49De eso trató gran parte del experimento:
00:05:52cómo diseñar un sistema capaz de abordar una tarea de esta escala.
00:05:57Porque, como mencioné, para tus proyectos también vale la pena considerar tener agentes planificadores más ejecutores.
00:06:07Obviamente no para todas las tareas.
00:06:10Si tienes la corrección rápida de un error o una tarea muy simple, está perfecto decirle directamente a tu agente como Codex, Claude Code o el que sea:
00:06:19“Oye, tengo este problema.
00:06:20Quiero que hagas esto”.
00:06:21Le das algo de contexto extra y dejas que haga su trabajo.
00:06:24Según el entorno del agente de código, podría desplegar subagentes.
00:06:28Aun así, Claude Code podría hacerlo.
00:06:31Otros entornos como Pi quizás no lo hagan si no les das las extensiones adecuadas.
00:06:36Pero incluso sin subagentes, muchas tareas se pueden abordar con un solo agente y estará bien.
00:06:43Sin embargo, para proyectos o tareas más complejas, esa división resulta útil, incluyendo agentes revisores.
00:06:51Eso es algo que a mí personalmente me gusta hacer.
00:06:54De nuevo, según la complejidad del trabajo.
00:06:56Pero mantener esa separación funciona sumamente bien.
00:06:59Y eso, por supuesto, no es algo totalmente revolucionario.
00:07:02Lo novedoso es que para algo como reescribir SQLite, tienes múltiples procesos paralelos de planificadores, ejecutores y revisores: varios ejecutores, pero también varios planificadores y revisores.
00:07:18Y entran en conflicto todo el tiempo.
00:07:19Eso fue lo que el equipo de Cursor descubrió al final.
00:07:22Ahora, en esta publicación del blog, que es súper interesante,
00:07:26mencionan que a principios de este año hicieron un experimento con un sistema de agentes para crear un navegador web desde cero.
00:07:33Y ahora usaron ese mismo sistema de agentes para realizar la reescritura de SQLite.
00:07:40Pero también crearon un sistema nuevo como experimento basándose en lo aprendido.
00:07:47En este experimento y en el blog, comparan estos enfoques y profundizan en todos los desafíos que encontraron al intentar configurar y ejecutar ese sistema para reconstruir SQLite.
00:07:59Y uno de los primeros desafíos que enfrentaron al trabajar con un sistema donde múltiples trabajadores, cientos o miles, operan de forma simultánea, es que el control de versiones tradicional, Git, ya no da la talla.
00:08:13Como escribieron en una publicación anterior sobre el enjambre, sabemos que herramientas como Git y Cargo usan bloqueos de grano grueso para el control de concurrencia, lo que significa que el mismo dato se bloquea para evitar múltiples escritores simultáneos.
00:08:30Esto funciona para un desarrollador, pero es inviable para el volumen de trabajo generado por cientos de agentes concurrentes.
00:08:36El enjambre del navegador de principios de año alcanzó un pico cercano a los 1,000 commits por hora.
00:08:41Ese fue el enjambre que reconstruyó el navegador.
00:08:45El nuevo sistema, diseñado para este experimento, alcanza picos de unos 1,000 commits por segundo.
00:08:52El enjambre anterior registraba 1,000 commits por hora, algo más de lo que produce la mayoría de los humanos, obviamente.
00:09:02El nuevo sistema, sin embargo, genera unos 1,000 commits por segundo, una cantidad asombrosa para la cual Git claramente no fue diseñado.
00:09:14Evidentemente.
00:09:15Para facilitar semejante ritmo de actividad, construimos un nuevo sistema de control de versiones desde cero.
00:09:21El rendimiento no fue la única razón para controlar esta capa.
00:09:25Cada cambio en el sistema pasa por el sistema de control de versiones.
00:09:29Por lo tanto, es allí donde las colisiones se hacen visibles primero.
00:09:31Y varios de los mecanismos de coordinación de la siguiente sección están implementados directamente dentro de él.
00:09:37Y eso es verdaderamente interesante.
00:09:39Crearon un nuevo sistema de control de versiones para la era de los agentes de IA.
00:09:43Porque el anterior, Git, que todos usamos, no tiene nada de malo, para ser claros.
00:09:48Para que quede bien claro.
00:09:49Estamos hablando de un experimento a una escala y sobre una tarea que la mayoría no abordará jamás, al menos no pronto.
00:09:57Aun así, Git no está diseñado para tener cientos de agentes o entidades trabajando simultáneamente en el mismo código.
00:10:07Así que construyeron un nuevo sistema capaz de manejar una concurrencia altísima y de resolver conflictos mediante agentes.
00:10:19Porque los conflictos se hacen visibles en el control de versiones cuando dos cambios afectan el mismo fragmento de código.
00:10:28Ese es el primer punto relevante aquí.
00:10:30Diseñaron un sistema de control de versiones completamente nuevo para poder ejecutar eficazmente este experimento.
00:10:37Como es natural, surgieron bastantes problemas con semejante volumen y ritmo de cambios a 1,000 commits por segundo.
00:10:48Por ejemplo, resulta fascinante ver los fallos que hallaron y cómo los solucionaron, pues nos da un vistazo de cómo podría ser la ingeniería de software en el futuro.
00:11:01El problema de diseño “cerebro dividido”.
00:11:03Dos planificadores, sin saber del otro, implementan el mismo concepto de formas distintas en diferentes partes del código.
00:11:10Es decir, duplicación: el mismo concepto resuelto de formas distintas en partes diferentes de la base de código.
00:11:16Normalmente querrías extraer eso y reutilizar la lógica, ¿verdad?
00:11:21Arreglamos esto mediante instrucciones (prompting).
00:11:24Sin sistemas sofisticados nuevos; simplemente optimizando las instrucciones.
00:11:28Los propios planificadores toman las decisiones de diseño en lugar de delegarlas.
00:11:34Y les exigimos garantizar que dos subárboles delegados no decidan sobre la misma cuestión.
00:11:39Así que es una cuestión de configuración.
00:11:40Se trata de asegurar que, al dividir el sistema en planificadores y ejecutores, tus distintos planificadores tengan tareas muy claras y con muy baja probabilidad de chocar o solaparse.
00:12:02Eso comienza, por supuesto, con el diseño humano.
00:12:08Cómo estructuras la tarea y cómo redactas las instrucciones, ¿cierto?
00:12:11Arreglamos esto mediante instrucciones.
00:12:13Eso se propaga por el árbol de agentes con todos sus nodos y hojas paralelas, donde buscas que, al dividir las tareas en subtareas, los agentes reciban instrucciones para acotar trabajos con poca probabilidad de superposición.
00:12:34En última instancia, es un reto de planificación para los humanos: configurar el sistema adecuadamente desde nuestra parte.
00:12:43Así fue como resolvieron o abordaron este problema.
00:12:47Otro inconveniente que enfrentaron fue la disputa entre planificadores.
00:12:51Una forma más severa de disputa ocurre cuando dos planificadores se detectan y pelean alterando una y otra vez los mismos archivos.
00:12:59El problema son dos visiones de la realidad, y las herramientas de combinación no pueden resolver un desacuerdo.
00:13:04En su lugar, hacemos que los agentes registren sus decisiones en documentos de diseño compartidos.
00:13:08El código que depende de una decisión lleva una referencia de verificación compilada hacia su documento.
00:13:13Cuando los planificadores se contradicen sin saberlo, un reconciliador fusiona los documentos y las referencias propagan la solución hacia abajo.
00:13:21En resumen, sobre el punto anterior: al dividir el trabajo entre planificadores, es imposible evitar por completo las superposiciones o las áreas compartidas que deben ser modificadas en la base de código.
00:13:43Ahí es cuando los planificadores chocaban por una implementación, y lo solucionaron introduciendo un agente reconciliador que fusiona los documentos generados por ellos.
00:13:59Es decir, los documentos creados para luego entregarse a los ejecutores.
00:14:02Agregaron un paso intermedio con un reconciliador que une los documentos de los planificadores en conflicto para mantener un criterio unificado sobre la implementación y evitar soluciones duplicadas pero distintas en el código.
00:14:21Ambas cosas se complementan, según entiendo.
00:14:24Por supuesto, también encontraron conflictos de fusión (merge conflicts).
00:14:29Planificar y procurar que no haya solapamientos —o los menos posibles— y que los planificadores coincidan es el primer paso.
00:14:38Aun así, si varios ejecutores trabajan sobre un mismo plan, es muy probable que toquen los mismos archivos y entren en conflicto.
00:14:50Hay muchos otros ejecutores que simplemente no van a evitar trabajar en los mismos archivos.
00:14:55Por eso no van a evitar tocar los mismos archivos.
00:14:57Por eso coinciden en los mismos archivos.
00:14:58Para resolver una colisión, tendrían que detenerse, absorber el contexto del otro agente y fusionar su trabajo.
00:15:03Naturalmente, si dos agentes (o dos humanos) trabajan en el mismo archivo, para resolver el conflicto ambos deben parar para acordar una decisión,
00:15:19una implementación que resuelva la diferencia.
00:15:23Sin embargo, los agentes ejecutores son malos en esto y en la práctica sobrescriben el cambio ajeno o descartan el propio.
00:15:29Quizá también lo hayas notado.
00:15:31A mí me ha pasado.
00:15:32Si trabajas en una base de código junto a uno o más agentes de IA y haces un cambio...
00:15:38Vale, da un poco de miedo, pero aún se puede programar manualmente.
00:15:40Supongamos que haces un cambio.
00:15:42Modificas algo en el código.
00:15:44El agente simplemente lo deshace y lo sobrescribe.
00:15:48No respeta tus cambios.
00:15:50Tiene su propia instrucción.
00:15:52Si decidió editar cierto archivo, lo hará.
00:15:57Y no le importa si hiciste alguna modificación entretanto.
00:16:01Es distinto si hiciste un commit, porque estos agentes están entrenados para no deshacer fácilmente tus commits.
00:16:13Pero si es un cambio no guardado en commit, al ejecutor no le importa.
00:16:17Al agente le da igual.
00:16:19Y eso mismo presenciaron aquí.
00:16:21Para solucionar esto, creamos un sistema donde un agente tercero neutral interviene en los conflictos de fusión y los resuelve a favor de todos.
00:16:29Su único objetivo es ser imparcial y eficiente, similar a cómo funcionan las colas de fusión en los equipos de ingeniería.
00:16:35Me parece un detalle bastante interesante.
00:16:38Nuevamente, es una forma de reconciliación.
00:16:41Consiste en pausar a los agentes, igual que se hacía antes cuando debías detenerte, dar un paso atrás y resolver
00:16:49el conflicto.
00:16:51Esto demuestra que contar con un contexto limpio y adecuado es absolutamente fundamental.
00:17:03Sin importar si enfrentas una tarea masiva como Cursor o si trabajas en un proyecto pequeño,
00:17:12la gran ventaja de dividir el trabajo entre planificadores, ejecutores y revisores es operar con ventanas de contexto limpias.
00:17:24Esto no implica que el contexto esté vacío.
00:17:26Significa tener sesiones de agentes nuevas abastecidas solo con el contexto necesario para la tarea.
00:17:33Por ejemplo, un ejecutor es malo revisando su propio trabajo porque su contexto contiene todo el proceso de implementación.
00:17:41Por lo tanto, está sesgado, por así decirlo.
00:17:44Por eso el agente revisor debe empezar con un contexto nuevo, recibiendo qué se hizo, el plan y los archivos tocados, pero nada más.
00:17:55Así puede evaluar el trabajo de forma objetiva.
00:17:59Por ello las ventanas de contexto limpias con la información justa son indispensables.
00:18:04Y es exactamente lo mismo aquí: resolvieron los conflictos de fusión mediante un nuevo agente impartial con el contexto justo.
00:18:17Supongo que el sistema se configuró para informarle a los ejecutores sobre la solución sin que la sobrescriban, o se iniciaron nuevos ejecutores.
00:18:30Ese detalle no me queda del todo claro.
00:18:32Otro problema que encontraron fueron los megaarchivos.
00:18:35Algunos archivos son lugares especialmente populares para que los agentes trabajen.
00:18:39Cada agente puede añadir poco código y ninguno asume la responsabilidad de mantener el archivo pequeño.
00:18:45Estos megaarchivos lo colapsan todo.
00:18:49Son costosos de transportar, comparar y fusionar, convirtiéndose en foco de colisiones constantes.
00:18:54Esto es algo que a menor escala probablemente también hayas experimentado.
00:19:00A mí me ha ocurrido.
00:19:01Es una de las situaciones comunes.
00:19:02Especialmente para las pruebas.
00:19:03Mi experiencia es que a los agentes les encanta añadir más y más pruebas en el mismo archivo.
00:19:08Y no solo ocurre con las pruebas, pero es un área donde lo veo frecuentemente.
00:19:13Y especialmente si tienes múltiples agentes trabajando y cada uno tiene sus propios objetivos.
00:19:18A ellos no les importa, porque no son humanos.
00:19:21¿Cómo podría importarles algo?
00:19:23Solo ejecutan tareas, ¿verdad?
00:19:24No les importa el tamaño de un archivo ni la arquitectura general del sistema.
00:19:30Si solo tienes un grupo de agentes ejecutando sus tareas, tu código caerá en el caos en algún momento.
00:19:37Porque a los agentes no les importa.
00:19:39Les importa ejecutar su tarea.
00:19:42Y estos mega archivos, por supuesto, son un indicador claro de ese problema.
00:19:48Se convierten en algo habitual a medida que más agentes trabajan durante más tiempo en tu proyecto.
00:19:55No hay ningún agente encargado de dividir ese archivo o de mantener una buena arquitectura en el código.
00:20:02Simplemente no está en sus planes.
00:20:04Así que, para solucionar esto, les dimos a los agentes trabajadores una forma de marcar archivos demasiado grandes.
00:20:09Una vez marcados, bloqueamos nuevos commits y un agente dedicado descompone el archivo gigante en módulos más pequeños.
00:20:16De nuevo, entra en juego un agente nuevo.
00:20:19Es un patrón que vemos aquí.
00:20:21Para todos estos problemas, la clave fue identificar la falla y luego usar agentes nuevos con la tarea adecuada,
00:20:28con el contexto correcto, para resolver ese problema y permitir que los demás agentes continúen con su trabajo.
00:20:35Y ocurre lo mismo aquí con los mega archivos.
00:20:38La osificación es otro problema al que se enfrentaron.
00:20:40Los agentes han aprendido, al trabajar en bases de código existentes junto a humanos,
00:20:44a no tocar el código principal, incluso cuando necesita cambios.
00:20:48Así que no me refiero a lo de antes,
00:20:50de cuando haces un cambio en un archivo en el que el agente trabaja y simplemente lo descarta.
00:20:55Se trata más bien del comportamiento general.
00:20:57Un agente tiene una tarea clara basada en un plan y un prompt que le diste.
00:21:03Y eso implica, por supuesto, modificar ciertos archivos.
00:21:07Ahora bien, algo que ya sabemos o vemos a diario al trabajar con agentes es que, dependiendo del modelo,
00:21:16algunos son muy reacios a deshacerse del código existente.
00:21:21Prefieren añadir 10 alternativas, 10 validaciones 'if' y más código heredado a la base de código antes que eliminarlo y limpiarlo.
00:21:31Tienes que indicárselo explícitamente en el prompt para asegurarte de que un agente realmente borre una función o elimine un archivo.
00:21:39No lo hacen por iniciativa propia debido al ajuste fino, ya que los proveedores de estos modelos no quieren construir sistemas
00:21:47que actúen sin control y rompan el código en producción.
00:21:50Pero cuando no trabajas en un proyecto antiguo o en una base de código existente que ya está en producción,
00:21:57esa tendencia a no tocar el código y conservarlo todo para siempre puede ser muy problemática y molesta.
00:22:05También puede generar otros efectos secundarios como los que encontraron aquí, donde los agentes no mejoraban el código escrito por otros agentes,
00:22:16sino que seguían construyendo encima una y otra vez, lo que finalmente provocaba una base de código sobrecargada.
00:22:23Para solucionar esto, autorizamos cambios drásticos e intencionados.
00:22:27Un agente que considere valioso un cambio estructural puede aplicar un parche fuera de su alcance y dejar un comentario explicando el motivo.
00:22:36Y eso es, de nuevo a menor escala, algo que puedes hacer en tus proyectos o en lo que yo hago.
00:22:41Quieres autorizar explícitamente a tus agentes y decirles: “Oigan, estamos construyendo esto.
00:22:46Estamos en una etapa inicial.
00:22:48Esto aún no está en producción.
00:22:49Quiero cambios drásticos.
00:22:51Así que limpien el código sin rodeos.
00:22:54Las reestructuraciones son bienvenidas”.
00:22:56Cosas por el estilo.
00:22:58Quieres animar a los agentes y a estos modelos de IA, sobrescribiendo las instrucciones de su ajuste fino.
00:23:04Por así decirlo, modificar su conocimiento integrado para garantizar que puedan hacer evolucionar la base de código en lugar de solo añadir más y más código.
00:23:14De nuevo, es algo que vemos a pequeña escala aquí, aunque por supuesto ocurra a gran escala.
00:23:19Para la revisión, utilizaron un enfoque llamado enfoques de revisión.
00:23:24Tenemos agentes planificadores y trabajadores, pero ese trabajo debe revisarse para crear tareas de seguimiento y reiniciar el ciclo hasta corregir un error o mejorar el estado del código.
00:23:38En un sistema multiagente de larga ejecución, los errores se acumulan y el enjambre necesita corregirse antes de que los pequeños fallos se vuelvan estructurales.
00:23:47Una vez más, tiene todo el sentido.
00:23:48Todos hemos visto esto también a menor escala.
00:23:50Experimentamos con varios enfoques de revisión, como darle al agente revisor el historial completo del trabajador, solo su resultado o únicamente la base de código.
00:24:00También probamos revisores ejecutados en diferentes modelos, con distinto entrenamiento y otra personalidad.
00:24:05Ningún enfoque detecta todo, pero la combinación de enfoques logra que los sistemas alcancen una fiabilidad superior a la humana sin necesitar componentes perfectos.
00:24:16El cómputo invertido en la revisión tiene un alto rendimiento, ya que revisar es mucho más barato que el trabajo auditado.
00:24:21Sospechamos que este sistema de revisión por capas fue clave para mantener la calidad constante en las ejecuciones.
00:24:28Así que la lección principal aquí es:
00:24:30Es imposible que uno o varios agentes revisores examinen toda la base de código.
00:24:39Es demasiado contenido.
00:24:41En su lugar, probaron distintos enfoques, como darles la transcripción completa, solo el resultado o únicamente la base de código.
00:24:47Al final descubrieron que lo más útil era tener diferentes revisores con distintas personalidades y enfoques, centrados en aspectos específicos.
00:25:00Se les da la base de código, según entiendo, y tal vez algo de información sobre lo que hizo el trabajador.
00:25:06Y fue la combinación de los resultados de múltiples revisores lo que generó un análisis global que luego el planificador pudo tomar para crear un nuevo plan y pedir a los trabajadores que corrigieran el código.
00:25:23Y de nuevo, a menor escala, creo que es algo que también podemos aplicar.
00:25:28Obviamente, no estamos construyendo sistemas tan complejos.
00:25:34Pero en mi experiencia funciona muy bien tener varios agentes revisores con distintas tareas; por ejemplo, uno centrado en verificar si es código Rust idiomático.
00:25:46Otro puede enfocarse en problemas de rendimiento y seguridad si Fable 5 lo permite.
00:25:51Otro revisor puede concentrarse en las convenciones de nombres, si es algo a lo que quieres darle prioridad, y así sucesivamente.
00:25:58Así tienes diferentes enfoques y les proporcionas a esos revisores el contexto justo y necesario.
00:26:03De nuevo, algo como: “Oigan, los trabajadores estuvieron encargados de esta función”.
00:26:07Tal vez darles el plan del trabajador y algo de información sobre los pasos generales que realizó, pero nada más.
00:26:15Luego obtienes todos los resultados de los diferentes revisores y puedes combinarlos, quizás utilizando otro revisor más.
00:26:22Lo que también me gusta es tener un revisor que analice los resultados de las revisiones, ya que, dependiendo del modelo, suelen tener tendencia a buscar fallos donde sea.
00:26:36Sin importar qué código les entregues, podría ser una sola línea.
00:26:40A veces siento que encontrarían cinco problemas en ella.
00:26:43Por eso, tener un revisor que categorice los hallazgos y descarte los que no son errores reales puede funcionar de maravilla según mi experiencia.
00:26:55Y es esta combinación adecuada de revisores, esta capa de revisión, la que ayuda a generar buenos resultados para luego volver a implementarlos.
00:27:06Por supuesto, todo depende de la escala de la tarea y del software que estés construyendo.
00:27:11Obviamente, para muchos proyectos de software todo esto resulta demasiado complejo, pero es un excelente vistazo a cómo podría ser el desarrollo de software y estos sistemas en el futuro, algo que personalmente me parece muy interesante.
00:27:27Por último, otra cosa que hicieron fue permitir que los agentes diseñaran el entorno.
00:27:32La idea era dejar que los agentes redactaran una guía de campo, básicamente un documento o conjunto de documentos, sin darles más instrucciones que servir de contexto para la tarea general; así, los agentes podían construir una memoria compartida sobre aprendizajes o problemas clave identificados.
00:28:00De este modo disponían de ese sistema de memoria adicional para que los agentes tomaran notas y documentaran decisiones.
00:28:10En general, al igual que la reescritura de BUN en Rust, este experimento me parece sumamente interesante.
00:28:16También puede dar un poco de miedo.
00:28:17Lo entiendo perfectamente.
00:28:18Y creo que no debemos deducir que así se deba construir todo el software a partir de ahora.
00:28:24Para empezar, esto ni siquiera es un software listo para producción.
00:28:28Y lograr que lo esté llevaría un tiempo considerable.
00:28:33No hay que subestimarlo.
00:28:35No es algo que puedas construir en un par de horas y pensar que dejarlo listo para producción solo tomará unas cuantas horas más.
00:28:43Alcanzar el primer 80% puede ser mucho más rápido que completar el 20% final.
00:28:48Todos lo sabemos.
00:28:49Así que esa es una lección importante.
00:28:51También es clave comprender que para reescribir SQLite tal vez solo recibieron esa documentación y luego se usó la suite de pruebas.
00:29:04Sin embargo, se trata de una especificación increíblemente detallada, algo que no tienes en proyectos nuevos.
00:29:13Si estás creando un software desde cero, no tienes una especificación tan precisa como la documentación de un sistema con más de 20 años.
00:29:24Y por supuesto, aunque solo se les entregara la documentación, el código fuente de SQLite y otras reimplementaciones como la de Rust hecha por Turso muy probablemente formen parte de los datos de entrenamiento de estos modelos.
00:29:46Así que no era algo completamente nuevo para ellos.
00:29:51No es lo mismo que crear un software totalmente nuevo donde la iteración es una parte fundamental del desarrollo.
00:29:58Te resultará muy difícil, e incluso diría que es imposible, crear un nuevo software desde cero, sea lo que sea, sin que esté cambiando constantemente.
00:30:11Porque no puedes escribir una especificación perfecta desde el principio y dar el trabajo por terminado.
00:30:17Siempre descubres cosas nuevas o aspectos que quieres cambiar a medida que construyes, sin importar la escala.
00:30:26Por lo tanto, esto no representa necesariamente cómo se construirá el software en general en el futuro.
00:30:34Aun así, es un experimento fascinante.
00:30:37Es un experimento sumamente interesante que deja aprendizajes clave para todos nosotros.
00:30:43Enseña principios importantes, como dividir el trabajo y contar con ventanas de contexto limpias con la información exacta.
00:30:50Muestra ideas interesantes, como que surgirán nuevos sistemas de control de versiones necesarios en el futuro.
00:30:57Y, por supuesto, que la orquestación multiagente se convertirá en una realidad.
00:31:01Todo esto demuestra la importancia de los humanos diseñando estos sistemas de agentes y tomando decisiones sobre la arquitectura del software.
00:31:21Escribir especificaciones, diseñar arquitecturas de software y luego construir y revisar sistemas de agentes capaces de implementarlas es clave.
00:31:33Hacia allá nos dirigimos y, aunque sea muy distinto a cómo programábamos hace seis años, me parece algo verdaderamente emocionante.
00:31:45Creo que es fascinante avanzar hacia el pensamiento sistémico, tanto para construir sistemas de agentes como para diseñar la arquitectura del software.
00:31:59Y luego hacer que ambos aspectos trabajen juntos.
00:32:01Experimentos como este me resultan sumamente interesantes.
00:32:04Las lecciones que nos dejan son de gran valor.
00:32:07Y algunos de estos aprendizajes, a una escala más reducida, también pueden aplicarse al desarrollo de software cotidiano.
00:32:17Como siempre, déjame saber qué opinas y qué piensas sobre este tipo de experimentos.