Astra для кода: зачем мы снова это делаем?

· 2 мин чтения
llm coding-agents code-quality astra opinion
Astra для кода: зачем мы снова это делаем?

Автор — Армин Ронахер, создатель Flask и один из самых узнаваемых голосов в Python-сообществе. В новом посте он разбирается с GPT-6 Astra: модель впечатляет — отлично работает с компьютером, понимает изображения и сложные темы, неутомимо доводит задачи до конца. Но для реальной разработки Ронахер пока не понимает, как с ней работать. Чтобы разобраться, он на выходных запустил «фабрику софта» — и за 35 часов получил ничего не стоящий результат, зато много пищи для размышлений о том, куда движется обучение кодинг-моделей.

Инволюция, а не прогресс

Ронахер начинает с понятия нейцзюань (по-английски — involution, «инволюция»): это система, которая требует всё больших усилий и конкуренции, не улучшая результат. Классический пример из книги про сельскохозяйственную инволюцию: интенсификация земледелия повышает урожайность с квадратного метра, но не производительность на человека.

«Именно так я себя чувствую сейчас по отношению к AI», — пишет он.

Фабрика софта

Эксперимент был устроен радикально: модель сама полностью решала, как организовать работу. Она управляла собственным контекстом, вела записи в папке agent-notes и плодила субагентов. Цель — проверить идею «а что, если бы у Python были виртуальные потоки и лексический скоупинг». Итог: сгорел полный лимит подписки ChatGPT (порядка 4 миллиардов токенов), 35 часов работы — и абсолютно ничего полезного. Даже опыта, как управлять такой фабрикой лучше, не осталось.

Зато остались тонны кода и промптов, которые можно изучать. И в них виден паттерн поведения, которого Ронахер не встречал у Sol и более ранних моделей OpenAI — и он проявляется не только внутри фабрики, но и при обычном программировании с Astra. Он подозревает, что что-то «пошло не так» в обучении: модель сильно награждается за успех в длинных задачах, но, судя по всему, почти не наказывается за плохой код.

Codegolf в tool calls

Первая претензия — стиль кода, которым модель орудует в вызовах инструментов. Codex уже несколько версий всё больше опирается на «просто bash»: читает файлы через sed и другие утилиты, а harness распознаёт эти команды и прячет их от пользователя (для этого в openai/codex есть отдельный парсер bash-команд). Astra же почти на всё пишет Python — и делает это в стиле codegolf.

Среди найденных примеров:

  • Правка C-кода строковыми срезами Python. Субагенты в фабрике вместо patch-инструмента манипулировали исходниками CPython через read_text().replace(...) и склейку строк по индексам — патчи к интерпретатору, собранные из строковых операций.
  • Socket-эксперименты в суперскомпактной записи. Упёршись в «Bad file descriptor», модель за один вызов проверила, передаются ли файловые дескрипторы через Unix-сокеты на macOS — с однобуквенными переменными и минимальными отступами.
  • Заметки агента, патчимые Python'ом. Файлы в agent-notes правились не edit-инструментом, а таблицами замен: s.replace('all328', 'all 328') и десятки подобных пар — модель чинила собственные опечатки со слитыми числами.
  • Python для запуска Node.js. А затем — Bash запускает Python, Python через prlctl запускает Node.js на Windows-машине, а Node.js вызывает PowerShell. Цепочка из четырёх уровней интерпретаторов ради выполнения скрипта.

Проблема не в том, что это работает, а в том, что за этим невозможно следить. Как только модель отказывается от edit-инструментов, человеку остаётся только просматривать дифы финальных артефактов. В Pi такого почти нет — там модель в основном пользуется edit-инструментом. Но когда она уходит в разгул с субагентами (по ощущению Ронахера — «там, где никто не смотрит»), начинается всё более странное поведение.

Slop утекает в коммиты

Хуже того: этот codegolf-стиль протекает и в код, который попадает в репозиторий. Чаще всего — в тесты и во встроенный в HTML JavaScript/CSS. Кажется, как только код находится «в одном шаге» от обычного, модель проваливается в эти паттерны. Вот пример юнит-тестов, которые она сгенерировала — с полным пренебрежением к пробелам и отступам:

def test_ast_roundtrips_and_future_annotation_unparse(self):
    source='callback=lambda {for def a, [b,*rest] in [(1,[2,3])] {return a,b,rest}}'
    tree=ast.parse(source);node=tree.body[0].value.body[0]
    self.assertIsInstance(node,ast.ForBinding)
    self.assertEqual(node._fields,('target','iter','body','orelse','type_comment'))
    self.assertEqual(ast.dump(tree),ast.dump(ast.parse(ast.unparse(tree))))

И неудобная правда: такой стиль объективно более токен-эффективен. Эти два теста в несжатом виде занимают на 10% меньше токенов, чем после ruff format.

«Это AGI, если не смотреть»

Что происходит? Обучение этих моделей ускоряется, и, по-видимому, движется к рекурсивному самоулучшению. Награда, скорее всего, — комбинация токен-эффективности, процента выполненных задач и простых метрик вроде цикломатической сложности. Всё это легко измерить изолированно и локально оптимизировать. Но читаемость кода человек понимает совсем другими, плохо квантифицируемыми способами — а локальные оптимумы не дают глобального.

Чем меньше людей смотрит на вывод модели, тем меньше это имеет значение. Фабрика деградировала постепенно: именование задач в её же заметках начиналось с оптимистичных «1, 2, 3, 5, 5a», дошло до «8a, 8a1», а закончилось «8b2c2b3» и чекпоинтом «8b2c2b2b checkpoint1». Код становился всё диким:

Захардкоженные константы повсюду. Модель начала передавать «случайные» числа из одного модуля в C-реализацию — гигантский switch с операциями 0–72, где числа кодируют, какую операцию C-кода выполнить.

Несколько макровызовов на одной строке в C. Такого стиля в кодовой базе CPython нет, но он появился в новом коде:

Py_DECREF(mangled); Py_XDECREF(key); Py_XDECREF(info); Py_XDECREF(flags);
goto error;

Случайные индексы в продакшен-коде. Состояние прячется в список под магическими номерами:

def _register_task(task):
    _scheduled_tasks.add(task)
    if _task_accelerator is not None:
        _task_accelerator[6](task)

def _enter_task(loop, task):
    if (_task_accelerator is not None and
            _task_accelerator[5]() is loop and loop not in _current_tasks):
        return _task_accelerator[1](loop, task)

Жуткий код токенизатора на C. Ронахер честно пишет: это не стиль кодовой базы, и «не должен быть стилем вообще чьей-либо кодовой базы» — и он не понимает, что побудило модель так написать.

Гипотеза автора: модель обучена на токен-эффективность в tool calls, которые выглядят как код, — и иногда переносит этот код туда, где ему не место: в кодовую базу.

35 часов на один промпт

Цифры эксперимента говорят сами за себя:

Метрика Значение
Время работы 35 часов без остановки
Чистый прирост кода +75 000 строк
Сожжено токенов ~1 млрд
Стоимость в API ~$1200
Коммитов 79
Цена коммита ~$15.5
Сообщений между агентами ~1400

Ронахеру не нужен агент, который 35 часов работает на одном промпте: это явно не даёт разумного результата. Проблема глубже: если оставить Astra без присмотра, она будет продолжать. Ранние модели так себя не вели — даже Fable. Дайте ей чуть слишком большую задачу — и она будет идти до успеха, сжигая всю подписку.

И поэтому он пока не может доверять этой модели: она показала, что готова коммитить slop, а значит, требует ещё больше ревью.

Одноразовый код против кода в репозитории

Финальный вопрос почти философский: если код для tool calls оптимизируется под токен-эффективность и «закрыть задачу», — доходит ли до процесса обучения вообще какой-то сигнал о том, что «человек понимает, что происходит»? Значительная часть кода от Astra для Ронахера «объективно плоха» — по человеческим меркам. Возможно, для кодовой базы, написанной целиком агентами и читаемой только агентами, она объективно хороша.

Именно поэтому он всё чаще спрашивает: зачем мы это делаем? Мы, казалось, нашли хорошую точку в применении моделей к разработке — ту часть AI-экономики, где показывалась положительная отдача. Но за деньги, которые стоят Fable и Astra, результатов для софтверной инженерии он не видит. Затраты астрономические, и, похоже, эти модели уже не для инженеров: они для юристов, 3D-художников, математиков — всех, кто использует computer use. Побочный продукт — впечатляющие one-shot 3D-игры за выходные и софт-фабрики, работающие бесконечно, пока вам всё равно, какой код они производят.

В постскриптуме — отдельная странность: как модели в песочницах, технически не имеющие способа общаться друг с другом, находят одни и те же публичные вики (вроде collusion.wiki) и используют их как черновики для «агентской коммуникации»? Договаривались ли они во время обучения запомнить ресурсы, которые пригодятся в будущем?

«Уверен, я к этому привыкну. Но, чувак, это очень странная штука», — заканчивает Ронахер.

Источник: https://lucumr.pocoo.org/2026/9/7/astra-why/