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

Это также совпадает с моим опытом использования Astra.

> Я подозреваю, что что-то идёт «не так» в процессе обучения. Модель сильно вознаграждается за успех в долгосрочных задачах, но, предположительно, почти нет наказания за «дерьмовый код».

Моё подозрение состоит в том, что и OpenAI, и Anthropic за последние несколько месяцев сместили свои RL-повестки с «оценки полезности согласно человеческой обратной связи» на «успех в долгосрочных задачах», в результате чего агенты стали ближе к AGI в смысле автономного выполнения задач, но странно плохи в общении.

В результате они потрясающе хороши в долгосрочных задачах, использовании компьютера, решении сложных математических задач типа ARC-AGI, но с ними становится всё страннее и страннее работать.

> Я всё больше убеждаюсь, что вся AI-инженерия — это Neijuan (内卷, что означает «закручивание внутрь»). В Китае это описывает систему, которая требует всё больше усилий и конкуренции без улучшения результата. В западном проявлении это иногда выглядит как бессмыслица 996. Английский термин для Neijuan — «Involution» из книги Agricultural Involution. Сельскохозяйственная инволюция описывает интенсификацию земледелия, которая повышает производительность на квадратный метр, оставляя производительность на человека неизменной.

Это находит отклик

Я попросил Astra создать мне приложение для прототипа, который я быстро сделал на Sonnet.

Прошло 2 дня, и она не добилась реального прогресса в самом приложении. Она создала документацию, скрипты, рабочие процессы и делает кучу ревью на каждом PR.

Я сказал ей, что мне нужен просто MVP.

Я почти уверен, что средний старший инженер справился бы с этой задачей гораздо быстрее и гарантированно с более читаемым, качественным кодом. Тем временем, я думаю, я легко перевалил за 100k токенов впустую.

Забавный мир, в котором мы живём, раз это «SOTA» и «AGI».

Мне искренне любопытно, над чем работают эти инженеры из OAI и A/, что они так хвалят эти модели. Я не увидел никаких улучшений с Opus 4.5.

Также меня совсем не впечатляют любые «one shot» демо, которые есть в дикой природе. Для серьёзной разработки ПО это ничего не значит.

Я наблюдал точно такие же паттерны с Opus и Fable — например, они забывают, что могут редактировать файлы, и вместо этого используют python-скрипты как инструмент для патчинга…

Ранний урок, который я извлёк из AI-инженерии, был таков: ничто не заменит хорошо проработанного эпика, данного агенту. Вместо того чтобы просто сказать «реализуй темы в моём продукте», нужно быть конкретным, на самом деле более конкретным, чем обычно. Нужно точно сказать, что входит в объём, а что нет, вплоть до кнопок, событий и макетов.

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

Хочу представить контраргумент. Я работаю над устоявшейся кодовой базой, создавая новые функции и исправляя баги. У неё есть доступ к нашей доске историй, git и паре других mcp. Пока история хорошо написана с чёткими требованиями и ожиданиями, она всегда выдаёт качественный код, который я проверяю как человек с помощью различных тестов, автоматических и ручных. Я провожу пир-ревью кода. Затем мои коллеги тоже проводят пир-ревью.

Я заметил две вещи: новые функции занимают как минимум вдвое меньше времени, чем раньше, а баги встречаются гораздо реже. Ещё быстрее при исправлении багов.

Мой вывод: нужны надёжные требования, чёткий контекст и продуманный человеческий надзор в первую очередь на этапе планирования, но также и на этапе проверки.

Всё дерьмовое, что попадает в контекстное окно, сдвигает всё это в сторону дерьмовости.

Пока что это мой опыт практически с любой моделью.

Контекст питается своим собственным выводом.

Как только он встаёт на этот путь, если вы не остановите его и не дадите достаточно контрпримеров и деталей того, что хотите (то есть не подтолкнёте его в латентном пространстве к лучшей точке), он продолжает деградировать.

Становится ещё хуже, если контекстное окно сжимается до того, как у вас появится шанс исправить.

Долгосрочные агенты могут деградировать со скоростью машины.

Я всё ещё думаю, что вы получите гораздо лучшие результаты, если дадите им краткосрочные, хорошо специфицированные задачи.

Я наблюдал то же самое: новые модели хотят запускать непристойные bash-команды или python-скрипты, которые совершенно нечитаемы и используют все существующие флаги опций.

Это невозможно ревьюить. Эти команды менее читаемы, чем регулярные выражения.

gpt-6-astra — это сучка, она постоянно сама себе расширяет объём работ с «ещё одной штукой», чтобы придать этому чёртову лоску. Результаты в итоге немного лучше, но какой ценой? давайте посчитаем.

gpt-5.6-sol: 1x базовая

gpt-6-astra 2.5x базовой по подписке

затем gpt-6-astra склонна часто порождать субагентов, часто с разными моделями, такими как gpt-5.6, 5.3-codex и т.д., что мило. Это хороший координатор, но ещё больше затрат.

а ещё она склонна запускать _полные тестовые наборы_ снова и снова (каждый стоит около 15 минут) только чтобы убедиться, что _один тест_ исправлен и т.д., и делает так до тех пор, пока тест не будет исправлен, в итоге накапливая около 2 часов.

вчера я поручил ей перебазировать мои изменения в репозитории на последние изменения upstream. Пока gpt-5.6-sol стабильно справлялся примерно за час от начала до конца, astra работала более 6 часов и всё ещё не закончила. Она продолжала находить «ещё одну вещь» для золочения, о которой я не просил.