아스트라 코딩 에이전트, 우리는 왜 또 이 짓을 하고 있나?

Armin Ronacher 's Thoughts and Writings blog archive projects travel talks about Astra for Coding: Why Are We Doing This Again? written on September 07, 2026 I'm more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output. The way in which it sometimes shows up in the West is the 996 nonsense . The English term for Neijuan is "Involution" from the book Agricultural Involution . Agricultural involution describes the intensification of farming that raises productivity per square meter while leaving productivity per head unchanged. That's how I feel about AI right now. Which brings me to GPT 6 Astra. Astra is by all accounts an incredibly impressive model. There is really not much I can say against this. It's amazing at computer use, understands images and complex topics, and it's relentless in its pursuit of completion. It is absolutely impressive; these types of models are going to change the world in one form or another. But at least for the moment I don't know how to work with it for actual software engineering. Since that got quite a bit of attention on Twitter, I figured I might summarize my thoughts and just share what kind of code comes out of this thing. My Slop Factory "Armin, you should run a software factory!" I've heard that a few times now, so I figured I might celebrate the release of it by running a little software factory over the weekend. If everybody builds slop 3D games, then I should do something useful with it. My software factory was intentionally set up to let the model decide the how of the workflow entirely. It was free to manage its own context and could maintain its own records in an agent-notes folder. Then it spun off subagents to work on stuff. The goal? What if we had a Python with virtual threads and lexical scoping. And well, I burned a full reset's worth of ChatGPT tokens on this which appears to be around 4 billion tokens. 35 hours later, the factory has delivered absolutely nothing of value and also not taught me anything about how to operate a better one. But it produced a lot of code and input prompts, and so there is stuff I was able to study. And well, it shows behavior that I'm not used to with Sol and earlier OpenAI models 1 . I have since encountered the same issues with regular programming with Astra, so it's not a result of just the factory. I think I'm suspecting something is going "wrong" in the training process. The model is greatly rewarded for succeeding on long-horizon tasks, but presumably there is very little punishing going on for "shitty code." The apparent result is that Astra is amazing at producing 3D stuff and it can keep going for a very long time, coming up with its own work in the process. I had it do quite a bit of reverse engineering of my robot vacuum in ways that were quite impressive. So it's definitely cool! Codegolf Tool Calls The first issue I have with Astra comes from the type of code that it uses for tool calls. Codex increasingly has been relying on "just bash" to do more and more operations. For a few versions now the original Codex harness just uses sed and other tools to read files. You just usually can't see them because Codex parses the bash commands and hides them if it recognizes them. But Astra … really loves Python? That is not much of a surprise because even older OpenAI models had a tendency to sometimes use on-demand Python code to read and manipulate files at times, but Astra does it really quite excessively for me. Now here is an important disclaimer: this project is very meta here because I worked on the CPython interpreter. But I can assure you that I have seen this model do weird Python things even in TypeScript code in Pi. But I have the most evidence of odd code from when I had the thing work over the weekend with zero oversight from my slop factory. That it writes Python is not interesting; the type of Python is interesting, and I collected some outputs for you to gloss over. Python string splicing to edit C code In the Codex harness I found multiple cases where subagents resorted fully to manual string manipulation with Python instead of using the patch tool. python3 - << 'PY' from pathlib import Path p = Path ( 'Include/internal/pycore_intrinsics.h' ); s = p . read_text () . replace ( '#define MAX_INTRINSIC_1 14' , '#define INTRINSIC_RETAIN_ANNOTATION_CELLS 15 \n\n #define MAX_INTRINSIC_1 15' ); p . write_text ( s ) p = Path ( 'Python/intrinsics.c' ); s = p . read_text (); idx = s . index ( '#define INTRINSIC_FUNC_ENTRY' ); s = s [: idx ] + '''/* Hold every old cell until the compiler has published the entire site's new capture. A replaced cell's finalizer may reenter module __annotate__. */ static PyObject * retain_annotation_cells(PyThreadState *tstate, PyObject *holders) { if (!PyTuple_CheckExact(holders)) { PyErr_SetString(PyExc_TypeError, "annotation holders must be a tuple"); return NULL; } Py_ssize_t size = PyTuple_GET_SIZE(holders); PyObject *previous = PyTuple_New(size); if (previous == NULL) return NULL; for (Py_ssize_t i = 0; i < size; i++) { PyObject *holder = PyTuple_GET_ITEM(holders, i); if (!PyCell_Check(holder)) { Py_DECREF(previous); PyErr_SetString(PyExc_TypeError, "annotation holder must be a cell"); return NULL; } PyObject *cell = PyCell_Get(holder); PyTuple_SET_ITEM(previous, i, cell == NULL ? Py_NewRef(Py_None) : cell); } return previous; } ''' + s [ idx :]; s = s . replace ( ' INTRINSIC_FUNC_ENTRY(INTRINSIC_AWAIT_BLOCK, await_block)' , ' INTRINSIC_FUNC_ENTRY(INTRINSIC_AWAIT_BLOCK, await_block) \n INTRINSIC_FUNC_ENTRY(INTRINSIC_RETAIN_ANNOTATION_CELLS, retain_annotation_cells)' ); p . write_text ( s ) p = Path ( 'Python/codegen.c' ); s = p . read_text (); idx = s . index ( 'static int \n codegen_annassign(' ); s = s [: idx ] + '''static int codegen_retain_annotation_cells(compiler *c, location loc, PyObject *captures) { Py_ssize_t pos = 0; PyObject *binding, *holder; while (PyDict_Next(captures, &pos, &binding, &holder)) { ADDOP_NAME(c, loc, LOAD_CLOSURE, holder, cellvars); } ADDOP_I(c, loc, BUILD_TUPLE, PyDict_GET_SIZE(captures)); ADDOP_I(c, loc, CALL_INTRINSIC_1, INTRINSIC_RETAIN_ANNOTATION_CELLS); return SUCCESS; } ''' + s [ idx :] a = s . index ( ' if (conditional_annotation_index != NULL) {' , s . index ( 'codegen_annassign(compiler *c' )) b = s . index ( ' if (captures != NULL) {' , a ) # Move lookup before conditional registration and retain old cells before anything changes. lookupstart = s . index ( ' PyObject *captures = _PyCompile_AnnotationCaptures' , a ) lookup = s [ lookupstart : b ] . replace ( ' return ERROR;' , ' Py_XDECREF(conditional_annotation_index); return ERROR;' ) s = s [: lookupstart ] + s [ b :] setup = lookup + ''' if (captures != NULL && codegen_retain_annotation_cells(c, loc, captures) < 0) { Py_XDECREF(conditional_annotation_index); return ERROR; } ''' s = s [: a ] + setup + s [ a :] needle = ' ADDOP_NAME(c, loc, STORE_DEREF, holder, cellvars); \n } \n }' s = s . replace ( needle , ' ADDOP_NAME(c, loc, STORE_DEREF, holder, cellvars); \n } \n ADDOP(c, loc, POP_TOP); /* release old cells after full publication */ \n }' , 1 ); p . write_text ( s ) p = Path ( 'Include/internal/pycore_magic_number.h' ); s = p . read_text () . replace ( ' Python 3.16a1 3709 (Checked deferred annotation closure capture)' , ' Python 3.16a1 3709 (Checked deferred annotation closure capture) \n Python 3.16a1 3710 (Retain replaced annotation captures until publication)' ) . replace ( '#define PYC_MAGIC_NUMBER 3709' , '#define PYC_MAGIC_NUMBER 3710' ); p . write_text ( s ) p = Path ( 'Lib/test/test_block_annotation_captures.py' ); s = p . read_text (); idx = s . index ( ' def test_typing_consumers' ); s = s [: idx ] + ''' def test_replaced_cell_finalizer_sees_complete_site_publication(self): module=execute(""" \\ events=[] class V: def __init__(self,n): self.n=n def __del__(self): if self.n == 0: events.