Последние три недели были одними из самых показательных в моём опыте разработки ПО с помощью ИИ.
Claude Fable снова появился на сцене, и за тот же период OpenAI выпустила GPT‑5.6 с Sol, Terra и Luna. Рыночный сигнал был очевиден: ведущие лаборатории больше не поставляют изолированные прорывы — они сжимают разрыв между возможностями, ценовыми категориями и частотой внедрения. Anthropic теперь продаёт Fable 5 как свою топовую модель с долгосрочным горизонтом примерно вдвое дороже Opus 5, а OpenAI позиционирует GPT‑5.6 как семейство, масштабируемое от флагманских возможностей до более экономичных сценариев. Тем временем xAI устанавливает цену на Grok 4.5 настолько агрессивно, что его нельзя не принимать всерьёз в любом обсуждении соотношения цены и производительности.
И всё же самое важное, что я узнал за эти недели, почти не связано с анонсами или слайдами с бенчмарками.
Настоящим прорывом в моей среде стала подготовка.
У нас были готовы сценарии. Работа была разбита на части, которые агентные системы кодирования могли реально выполнять. Как только такая очередь появилась, пропускная способность стала абсурдной. В Codex, Claude, Cursor, Grok и других инструментах рабочего процесса было написано более 2 миллионов строк кода примерно за десять дней. Эта цифра звучит как хайп, пока не увидишь, что сделало это возможным: не магия, не абстрактная автономия, а стабильный поток ограниченных задач с достаточной структурой, чтобы модели могли двигаться дальше.
Это первое, что многие всё ещё упускают. Взрыв результатов происходит не потому, что модели внезапно стали самостоятельными инженерами. Он происходит потому, что люди подготовили поле боя.
Второе, что я узнал: баги проявляются в масштабе быстрее, чем об этом говорят маркетинговые материалы.
Codex — хороший пример. Собственные материалы OpenAI о длительной работе дают понять, что устойчивые потоки сопряжены с компромиссом: преемственность полезна, но длинные потоки могут стать дороже и сложнее в управлении, чем начать заново. Функция Goals как раз предназначена для того, чтобы удерживать поток в рамках ограниченной цели, а не превращать каждую сложную задачу в бесконечно растущий промпт. На практике это совпадает с тем, что я видел. Если процесс выполняется слишком долго, лучший паттерн — часто остановить его, запросить чистую передачу, перезапустить сессию и продолжить с новой целью. Это не просто удобство. Это зачастую операционная гигиена.
Есть и более конкретная проблема Codex, которая теперь обзавелась видимым публичным следом: под‑агенты и раздувание локального состояния.
Открытый тикет #34061 описывает случай, когда возобновлённый родительский поток породил тысячи дочерних JSONL-логов и сотни гигабайт сохранённой истории сессии. Другой тикет прямо предупреждает, что fork_context=true может привести к снятию слепков большой родительской истории в дочерние агенты, увеличивая как риск ошибок, так и расход токенов. Ещё один публичный отчёт показывает, что холодный старт Codex вырождается в ожидание 1–5 минут, когда в ~/.codex накапливаются большие SQLite-логи и состояние сессии. В совокупности эти отчёты описывают режим отказа, который многие активные пользователи сразу узнают: как только локальный слой метаданных становится достаточно большим, сохраняемость сессии превращается в серьёзную часть пользовательского опыта.
Это важно, потому что многоагентное кодирование всегда выглядит в демо лучше, чем на напряжённой машине разработчика.
Обещание понятно. Документация OpenAI по мультиагентности описывает, почему параллельные под‑агенты могут ускорить независимые задачи, и это обещание реально. Но та же документация предупреждает, что под‑агенты увеличивают расход токенов и могут не подходить для задач, часто записывающих в разделяемое изменяемое состояние. Руководство по параллельным агентам в ChatGPT Learn ещё более прямо: начинайте с задач, ориентированных на чтение — исследование, тесты, триаж, суммаризация; будьте осторожнее с потоками, ориентированными на запись, потому что конфликты и накладные расходы на координацию быстро растут. Это предупреждение не теоретическое. Любой, кто видел, как флот агентов одновременно ломится к полному набору тестов, точно знает, что это значит.
В моей собственной среде это теперь одна из определяющих операционных проблем всей категории.
Проблема не в том, достаточно ли модели умны для распараллеливания. Они, безусловно, умны. Проблема в том, что им всё ещё нужны гораздо более чёткие границы оркестрации, потому что «достаточно умны, чтобы делегировать» — это не то же самое, что «достаточно умны, чтобы сохранять здоровье машины, локальный приоритет и дисциплину затрат в условиях конкуренции».
То же несоответствие проявляется в ценообразовании.
Cursor наглядно иллюстрирует проблему. Его текущее ценообразование прозрачно: есть два месячных пула использования — один для собственных моделей Cursor, другой для сторонних «Other Models». Также видно, что Auto — это не единое целое. Auto Cost использует фиксированное ценообразование на токены, а Balance и Intelligence выставляют счёт по тарифу маршрутизируемой модели, причём маршрутизатор может выбирать между моделями вроде Composer, GPT‑5.6, Claude или Grok. Для людей, выполняющих эпизодическую интерактивную работу, эта гибкость привлекательна. Для импульсных промышленных нагрузок она может стать ловушкой. Месячный премиум-бюджет может исчезнуть за несколько очень продуктивных дней.
Я протестировал этот самый режим отказа в одном сценарии с интенсивным ревью.
Один проект получил примерно 500 тысяч новых строк кода. Наша система ревью обнаружила около 1500 проблем в этом приросте, включая дубликаты и ложные срабатывания. Cursor CLI был нацелен на их проработку. Объём сырых токенов был огромен. Результат был полезен. Но экономика оказалась неподходящей для моего случая. Когда интенсивная работа по ревью и исправлениям может съесть месячный лимит за неделю, инструмент может быть всё ещё хорош, но подписка теряет смысл.
Эта напряжённость теперь повсюду.
Claude остаётся системой, с которой мне приятнее всего работать. Но она же заставляет меня больше всего думать о затратах. Codex, особенно в экосистеме GPT‑5.6, зачастую может обеспечить гораздо большую пропускную способность, чем признают критики. Grok 4.5 — не шутка; его публичное ценообразование и позиционирование делают его законным конкурентом. Собственное ценообразование Anthropic делает компромисс между Fable и Opus настолько очевидным, что почти пишет за вас редакционную статью: возможности переднего края есть, но есть и счёт.
И ещё есть самая трудная проблема из всех — та, которую не решает ни одно мероприятие по запуску.
Почти во всех передовых моделях кодирования, которые я использую, всё ещё сохраняется раздражающий разрыв между недостаточно мощным и переусложнённым.
Выбор слишком часто оказывается между моделью, которая мыслит недостаточно глубоко, и той, которая мыслит слишком глубоко для текущей задачи. Собственные рекомендации Anthropic для Fable 5 фактически это признают: больше усилий может привести к излишнему планированию, рутинная работа может выиграть от меньших усилий, а короткие инструкции часто превосходят раздутые конструкции. OpenAI говорит нечто подобное в своих рекомендациях по GPT‑5.6: при миграции с более ранних моделей начинайте с того же уровня рассуждений, а затем тестируйте на один уровень ниже, потому что новые модели часто могут сохранять или улучшать качество при меньшем количестве токенов. Это технический способ сказать то же, что многие из нас обнаруживают эмпирически: регулятор усилий всё ещё слишком легко перекрутить.
Возможно, часть этого всё ещё на нас.
Возможно, файлы инструкций слишком длинны. Возможно, некоторые конструкции теперь борются с моделями вместо того, чтобы помогать им. Эта теория хотя бы согласуется с собственными рекомендациями Anthropic по контекстной инженерии, которые гласят, что контекст должен быть информативным, но сжатым. Есть реальная вероятность, что некоторые из усложнений, которые мы приписываем моделям, усиливаются разросшейся инфраструктурой промптов.
Но даже с учётом этого общий вывод остаётся неизменным.
Модели делают меньше очевидных ошибок, чем раньше. Но ошибки, которые они всё ещё допускают, часто более опасны именно потому, что их труднее заметить. Они прячутся внутри кода, который в остальном выглядит отполированным, продуманным и профессиональным. Чем лучше реализация выглядит издалека, тем более подозрительным я научился быть.
Именно поэтому я остаюсь скептиком в отношении нынешней волны триумфализма AI-кодинга.
Я понимаю, откуда берётся хайп. Если вы не жили внутри этих систем каждый день, одна только пропускная способность может показаться чудом. И отчасти это действительно так. Но ежедневная практическая работа обнажает и другую сторону: неопределённость с оплатой, сбои оркестрации, хрупкость длинных сессий, склонность либо к поверхностному упрощению, либо к изощрённому переусложнению, а также постоянную потребность в человеческой упаковке, ревью и оценке.
Мы всё ещё очень далеки от идеального мира LLM-кодинга.
Хайп не полностью ошибочен. Но он всё ещё гораздо менее честен, чем операционная реальность.
