Как ProgramBench помогает понять, куда движется индустрия через год-полтора. В комментариях под постом про бенчмарк получилось обсуждение, приведу пару цитат (spec / спек — спецификация продукта, описание, как и что он делает, в деталях): — Eсли бы еще у продуктов из репозиториев на гитхабе были бы исчерпывающие спеки… — Собственно кажется бинарники для того и присобачили чтобы был хоть какой-то истинный ответ, потому что никакая документация обычно таковой не является — Где ты видел документацию хоть сколько-нибудь актуальную и исчерпывающую? Я вот по жизни обратных кейсов встречал до жопы. — Даже если разработка основана на spec, надо очень постараться чтобы сама дока была консистентной и согласованной Я согласен с этими тезисами, хорошей всеобъемлющей документации фичей ПО действительно почти всегда не бывает. Но это не означает, что так должно быть в будущем — если ИИ агенты продолжат развиваться и проникать во всё большее количество компаний/команд разработки, то это вполне может повлиять на то, как эта разработка ведётся. Инструмент новый и с потенциалом изменить подход в корне. Уже сейчас есть программисты, которые перешли на spec driven development (см. философию OpenSpec) — они сначала описывают детально функциональность, которую хотят поручить разработать агенту, итерируются несколько раз, оформляют список «ДАНО — КОГДА — ПОТОМ — И...» и запускают имплементацию. То есть разработчик участвует в принятии решений по логике, продумывает валидируемые детали. Я вижу огромный потенциал для масштабирования подхода ProgramBench с двух сторон: — решение LLM-агентом задач и получение обратной связи на то, что и где сработало, что нет. Это будет прокачивать долгосрочное планирование и архитектуру у агентов, ведь нужно как-то вываливать десять тысяч строк кода и больше. Всё в контекст не влезет, модели нужно будет учиться использовать внешнюю память. — автоматическое создание спецификаций, даже при отсутствии исходного кода и бинарника для запуска. Тысячи детальных авто-сгенерированных спек. LLM-агенты могут продумывать пользовательский путь, декомпозировать фичи, проводить анализ схожей функциональности у ближайших конкурентов или аналогов. Пока что это будет на костылях, нужно какой-то системный подход продумать, уверен, над этим в компаниях работают. И если первое понятно как использовать при наличии спеки, то что по второму? А то же самое — если эта система обучается из какой-то обратной связи, то я вижу, как можно генерировать большую часть спек автоматически. Агент просто задаст несколько верхнеуровневых вопросов и сам уйдет декомпозировать. И получается, что открывается целая новая область окружений для тренировки агентов (как это было с имплементацией PR с GitHub в последние пару лет). Пойдут ли туда компании? Мне понятно, почему это желанно с экономической точки зрения. Dario Amodei на недавнем подкасте у Dwarksh говорил, что через сколько то месяцев-лет они закроют цикл Software Engineering, и уточнил, что речь и про архитектуру/планирование, а не только написание кода. Для меня описанный выше сценарий масштабирования тренировки выглядит сонаправленным с этим — модель и будет учиться продуктово мыслить, прорабатывать сценарии и тесты для них, и имплементировать спеку. Как после SWE-Bench оказалось, что модели теперь будут работать на уровне PR, так и тут может оказаться, что новый способ разработки будет «по часовому голосовому сообщению с описанием того что я хочу агенты пошли написали 100 страниц спек и начали их имплементировать. За выходные справились» — и спеки, как понятно, будут инструментом агентов, а не людей.