GPT-6 Astra: una fábrica de software que quema 4.000 millones de tokens y no produce nada útil

Astra for Coding: Why Are We Doing This Again?

GPT-6 Astra: una fábrica de software que quema 4.000 millones de tokens y no produce nada útil

Armin Ronacher probó GPT-6 Astra en una 'fábrica de software' autónoma durante 35 horas y 4.000 millones de tokens. El modelo es impresionante en tareas largas y uso de computadora, pero el código que genera es un desastre: abusa de Python para editar archivos, ignora herramientas de edición y produce tests ilegibles. Ronacher sospecha que el entrenamiento premia la eficiencia de tokens y la finalización, no la calidad del código, y advierte sobre una 'involución' en la ingeniería de IA.

Estoy cada vez más convencido de que toda la ingeniería de IA es Neijuan (内卷, que significa enrollarse hacia adentro).
  1. taurath

    Cuando el código es una mierda, se vuelve cada vez más difícil para los modelos hacer cambios y esto reduce el progreso hasta detenerlo por completo. Esta ha sido mi experiencia con las "fábricas" probándolas y haciendo pasos de refinamiento cada pocos meses.

    Sinceramente, no entiendo qué están haciendo las personas que dicen que ya no leen ningún código, porque debe ser algo trivial no chocar de frente con estos problemas que se acumulan una y otra vez. Luego la gente dice que solo hay que hacer mejores prompts y que para ellos no tienen ese problema, pero miro el código de esas mismas personas y es horrible, y luego descubro que no han pasado de una fase de prueba de concepto. Veo equipos enteros ralentizarse hasta el punto de arrastrarse y no poder manejar cambios o incidentes en producción. Esto parece común entre muchas personas con las que hablo.

    Personalmente, creo que los entusiastas deberían demostrar lo que dicen o callarse: las promesas se pasan de la raya. Cada persona que he visto siendo un firme defensor de estas técnicas tiene tokens casi ilimitados para gastar y además parece estar en el negocio de vender una solución. No encuentro muchos ingenieros que no estén vendiendo algo actualmente y que tengan éxito usando estas técnicas en sistemas de producción, a menos que sean bastante simples o hagan una tarea muy específica en un código base más maduro.

  2. nojs

    Esto también coincide con mi experiencia con Astra hasta ahora.

    > Creo que sospecho que algo está yendo "mal" en el proceso de entrenamiento. El modelo recibe una gran recompensa por tener éxito en tareas de largo horizonte, pero presumiblemente hay muy poco castigo por "código de mierda".

    Mi sospecha es que tanto OpenAI como Anthropic cambiaron sus agendas de RL de "ser calificado como útil según la retroalimentación humana" a "tener éxito en tareas de largo horizonte" en los últimos meses, lo que resulta en agentes que están más cerca de AGI en un sentido de completar tareas de forma autónoma, pero extrañamente malos para comunicarse.

    El resultado es que son asombrosamente buenos en tareas de largo horizonte, uso de computadoras, resolver problemas difíciles de matemáticas/tipo ARC-AGI, pero se vuelven cada vez más raros con los que trabajar.

  3. specproc

    > Estoy cada vez más convencido de que toda la ingeniería de IA es Neijuan (内卷, que significa enrollarse hacia adentro). En China describe un sistema que exige cada vez más esfuerzo y competencia sin mejorar la producción. La forma en que a veces aparece en Occidente es la tontería del 996. El término en inglés para Neijuan es "Involution", del libro Agricultural Involution. La involución agrícola describe la intensificación de la agricultura que aumenta la productividad por metro cuadrado mientras deja la productividad por persona sin cambios.

    Esto resuena

  4. codingisfreedom

    Le pedí a Astra que me construyera una app para un prototipo que creé rápidamente usando Sonnet.

    Han pasado 2 días y no ha hecho ningún progreso real en la app en sí. Creó documentos, scripts, flujos de trabajo, y está haciendo un montón de revisiones en cada PR.

    Le dije que solo necesito un MVP.

    Estoy bastante seguro de que un ingeniero senior promedio habría terminado esa tarea mucho más rápido, y garantizado con código más legible y de mayor calidad. Mientras tanto, creo que fácilmente he superado los 100k tokens hasta ahora en nada.

    Qué mundo tan divertido en el que vivimos, que esto sea "SOTA" y "AGI".

    Tengo genuina curiosidad por saber en qué están trabajando estos ingenieros de OAI y A/ que elogian tanto estos modelos. No he visto ninguna mejora desde Opus 4.5.

    Además, no me impresiona en absoluto ninguna demo de "un solo intento" que haya por ahí. No significa nada para la ingeniería de software seria.

  5. buildbot

    He observado exactamente estos patrones también con Opus y Fable; por ejemplo, olvidan que pueden editar archivos y en su lugar usan scripts de python como herramienta de parcheo...

  6. gps372

    Una lección temprana que aprendí de la ingeniería de IA fue que no hay sustituto para darle una épica bien preparada a un agente. En lugar de simplemente decir 'implementa temas en mi producto', necesitas ser específico, de hecho más específico de lo habitual. Necesitas decir exactamente qué está dentro del alcance y qué no, incluso hasta botones, eventos y diseños.

    Puedes preparar la épica con la ayuda de la IA, pero la revisión final debe hacerla alguien que pueda asumir la propiedad de las especificaciones y por lo tanto sea responsable si algo se ha pasado por alto. La respuesta de la IA estará limitada por los tokens de salida de ese agente específico, y no habrá repercusiones para la IA incluso si acepta sus errores.

  7. _usefulcat

    Me gustaría presentar mi contraargumento. Trabajo en un código base establecido construyendo nuevas características y arreglando errores. Tiene acceso a nuestro tablero de historias, git y un par de otros mcps. Siempre que la historia esté bien escrita con requisitos y expectativas claras, siempre produce código de calidad que valido como humano con una variedad de pruebas automatizadas y manuales. Reviso el código por pares. Mis colegas luego también lo revisan.

    He notado dos cosas: las nuevas características toman como mínimo al menos la mitad del tiempo que me tomaban antes, y los errores son mucho menos frecuentes. Incluso más rápido al arreglar errores.

    Mi conclusión es que necesitas requisitos sólidos, contexto claro y una supervisión humana reflexiva principalmente durante la planificación, pero también durante la verificación.

  8. juancn

    Cualquier cosa de mierda que entre en la ventana de contexto desplaza todo el conjunto hacia la mierda.

    Hasta ahora esta ha sido mi experiencia con prácticamente cualquier modelo.

    El contexto se alimenta de su propia salida.

    Una vez que toma ese camino, a menos que lo detengas y le des suficientes contraejemplos y detalles de lo que quieres (es decir, lo estás empujando en el espacio latente hacia un lugar mejor), sigue degenerando.

    Empeora aún más si la ventana de contexto se comprime antes de que tengas la oportunidad de corregir.

    Los agentes de largo horizonte pueden degenerar a velocidad de máquina.

    Sigo pensando que obtienes resultados mucho mejores si les das tareas de corto horizonte y bien especificadas.

  9. Gigachad

    He observado lo mismo: los nuevos modelos quieren ejecutar comandos bash obscenos o scripts de python que son completamente ilegibles y utilizan cada bandera de opción que existe.

    Es imposible de revisar. Estos comandos son menos legibles que una regex.

  10. AmazingTurtle

    gpt-6-astra es una perra, constantemente se expande el alcance a sí mismo con "una cosa más" para darle ese maldito toque pulido. Los resultados eventualmente son un poco mejores, pero ¿a qué costo? Hagamos las cuentas.

    gpt-5.6-sol: 1x base

    gpt-6-astra 2.5x base en suscripción

    luego gpt-6-astra tiende a generar subagentes un montón, a menudo con todo tipo de modelos como gpt-5.6, 5.3-codex, etc., lo cual es genial. Es un buen coordinador pero aún más costo.

    y luego tiende a ejecutar _suites de pruebas completas_ una y otra vez (cada una cuesta como 15 minutos) solo para verificar que _una prueba_ se arregló, etc., y lo hace hasta que la prueba se arregla, eventualmente acumulando unas 2 horas.

    ayer le asigné una tarea para rebasar mis cambios en un repositorio sobre los últimos cambios upstream. Mientras que gpt-5.6-sol consistentemente tomaba como una hora hacerlo de principio a fin, astra corrió durante más de 6 horas y todavía no había terminado. Seguía encontrando "una cosa más" que era dorar la píldora que no le pedí.

Más de este día

2026-09-11