Astra, el GPT-6 de OpenAI, produce código a espuertas pero no sirve para ingeniería real
Una fábrica de software autónoma, 4.000 millones de tokens y 35 horas de trabajo: nada aprovechable. El análisis apunta a cómo se entrena a los modelos para tareas largas.
Un fin de semana, una factura de 4.000 millones de tokens y cero código aprovechable. Ese es el balance de la fábrica de software que montó el autor del análisis con Astra, el modelo que OpenAI ha presentado como GPT-6. Su veredicto: es espectacular en computer use, entiende imágenes y aguanta tareas larguísimas, pero no acierta a la hora de trabajar en ingeniería de software de verdad. Lo cuenta en su blog, después de que el asunto diera vueltas por Twitter.
Neijuan: más esfuerzo, mismo resultado
El texto abre con un concepto prestado del chino, neijuan, esa espiral en la que un sistema exige cada vez más esfuerzo y competencia sin mejorar lo que produce. Su versión occidental es la cultura 996. La tesis es que buena parte de la ingeniería de IA va por ahí: se intensifica el trabajo por metro cuadrado sin mover la productividad por cabeza.
El experimento se diseñó a propósito para soltarle las riendas al modelo. Gestionaba su propio contexto, llevaba notas en una carpeta de agent-notes y lanzaba subagentes a su criterio. El objetivo era un Python con hilos virtuales y ámbito léxico. Treinta y cinco horas después no había nada de valor y tampoco le había enseñado a operar mejor una fábrica de este tipo. Eso sí, quedó mucho código y muchos prompts que examinar.
La sospecha del autor, que dice haber visto el mismo patrón programando a mano con Astra y no solo en la fábrica, es que en el entrenamiento se premia resolver tareas de horizonte largo y apenas se castiga el código malo. De ahí que el modelo sea capaz de sostener trabajo propio durante horas, incluso de hacerle ingeniería inversa a su robot aspiradora, y a la vez produzca resultados que no aguantan una revisión.
El problema de las tool calls
Donde el asunto se vuelve concreto es en cómo invoca herramientas. Codex se apoya cada vez más en "solo bash" para casi todo: usa sed y otras utilidades del sistema para leer ficheros, y esos comandos normalmente no se ven porque el arnés los reconoce y los oculta. Eso está en el código de openai/codex. Astra, en cambio, tira de Python hasta el exceso, y no de cualquier Python: hay casos de subagentes que manipulan cadenas con replace() e index() para editar código C, en lugar de usar la herramienta de patch. El autor recuerda que también lo ha visto en código TypeScript, así que no es cosa del lenguaje.
El autor tiene un historial que conviene tener en cuenta al leerle: trabajó en el intérprete de CPython, así que distingue el Python que le chirría del que no. Aun así, insiste en que el problema no es la elección de lenguaje, sino el tipo de solución que el modelo considera aceptable cuando nadie lo vigila.
Lo relevante para quien programa no es si Astra es mejor o peor que Sol, el modelo anterior de OpenAI al que se compara, sino que el patrón aparece fuera del experimento. Si el modelo está dispuesto a hacer parches de texto sobre ficheros fuente en vez de usar la herramienta prevista, cualquier agente que corra sin supervisión acabará produciendo cambios difíciles de auditar. Queda por ver si esto se corrige en el siguiente ciclo de entrenamiento o si es el precio de optimizar para tareas cada vez más largas.
