Enjambres de agentes y la nueva economía de los modelos
Los enjambres de agentes que generan miles de commits de código por segundo se presentan como un indicio de «fábricas de software», pero los comentaristas cuestionan si eso solo produce enormes cantidades de código de baja calidad y deuda técnica más rápido. Muchos sostienen que estos sistemas dependen en gran medida de código existente y de especificaciones detalladas (como la documentación de SQLite), por lo que todavía no demuestran que los agentes puedan diseñar o implementar software verdaderamente novedoso. Los desafíos principales identificados son la verificación, el diseño de harnesses/herramientas y el juicio humano escaso sobre la intención y el valor del producto, más que la capacidad bruta de programación.
Enjambres de agentes de alto rendimiento y VCS personalizado
- Un nuevo VCS y 1.000 commits por segundo desencadenan el debate sobre si el cuello de botella es el control de versiones o la evaluación y supervisión.
- Algunos ven un VCS personalizado como algo apropiado para flujos de trabajo autónomos; otros lo consideran un exceso de ingeniería («inventar el universo para hacer un botón»).
- El paralelismo resulta atractivo, pero muchos sostienen que llevar la cuenta de qué es bueno, malo o redundante es la verdadera restricción.
Búsqueda aleatoria frente a inteligencia guiada («monos infinitos»)
- Varios comentarios comparan los enjambres de agentes con el Teorema del mono infinito o la biblioteca de Borges: generar océanos de «slop» para encontrar gemas raras.
- Los críticos dicen que la búsqueda aleatoria es intratable a escalas del mundo real; los modelos solo funcionan porque codifican fuertes «funciones de aptitud» aprendidas de los datos de entrenamiento.
- Existe la preocupación de que aumentar el rendimiento sin una selección y verificación proporcionales solo amplifique la basura.
Experimento de SQLite en Rust y preocupaciones sobre los datos de entrenamiento
- Muchos cuestionan la afirmación de «solo a partir de la documentación», señalando que es probable que SQLite e incluso reescrituras en Rust existan en los datos de entrenamiento.
- Algunos argumentan que el sistema básicamente descomprime conocimiento memorizado y lo refina con pruebas, no que realmente construya desde cero.
- Otros replican que las diferencias de arquitectura y la refactorización en varios pasos siguen haciendo interesante el resultado de la orquestación.
- Varios señalan que esto es una demostración tipo benchmark; dice poco sobre construir sistemas novedosos o integrarlos con entornos reales y desordenados.
Especificaciones, intención y definición del producto como cuellos de botella
- La especificación de 835 páginas se considera extremadamente detallada; algunos dudan de que sea más fácil que escribir el software directamente.
- Los comentarios subrayan que las especificaciones suelen surgir al construir software, no al revés, y que son más difíciles de validar que el código.
- Muchos ven la «descripción correcta de la intención» y una buena dirección de producto como los verdaderos recursos escasos, no las líneas de código.
Economía, harnesses y orquestación de agentes
- Los modelos de frontera lo bastante fiables para la autonomía se consideran más caros que los humanos; los costos se amplifican por los diseños de enjambre y el mal caché.
- Algunos abogan por agentes jerárquicos basados en roles y modelos locales pequeños para la implementación, con modelos más grandes para la planificación.
- Otros informan mejores resultados con un único agente de larga duración y una gestión cuidadosa del contexto en lugar de grandes enjambres.
Entusiasmo frente a escepticismo
- Los entusiastas ven esto como una emocionante fase de «coche conceptual» y un atisbo de la ingeniería automatizada a gran escala.
- Los escépticos describen las visiones de «fábrica de software» y las herramientas de metaagentes como humo, procrastinación y quema de tokens, con poco retorno real probado todavía.