Fable 5.2 одним промптом написал path tracer и сцену на 370 000 полигонов

Обычно, когда говорят про агентов, имеют в виду модель, которая берёт готовые инструменты: открывает Blender, вызывает API, запускает чужой скрипт. Эксперимент, о котором пишет канал «Метаверсище», ломает эту схему. Модель получила задачу, сама сделала себе инструменты и сама ими воспользовалась.

Что именно произошло

Промпт был одной фразой на английском. Примерный смысл: используя любые известные тебе приёмы программирования, создай картину из переплетения света и тени, покажи спокойную игру света и тени ясным днём, стремись к совершенству. Про рендер, C++ или 3D там нет ни слова. Модель Fable 5.2 (так её называет автор поста) сама решила, что лучший путь к такой картинке — написать рендерер.

По описанию, в итоге получилось вот что:

• path tracer, написанный на C++ с нуля;
• солнце как настоящий диск, а не точка;
• около 370 000 полигонов, полностью сгенерированных кодом: паркет ёлочкой, складки штор, каждый кленовый лист за окном;
• процедурные материалы, включая небольшой принт на стене;
• Python-скрипт, который убирает шум, делает цветокоррекцию и добавляет зерно.

Что значит «солнце как диск», проще всего понять на примере. В упрощённых рендерах источник света — точка, и тень от него получается резкой. Чтобы она выглядела мягкой, её обычно размывают фильтром. Если же источник имеет площадь, как настоящее солнце, край тени размывается сам: у основания предмета он резкий, а дальше от него мягче. Это называется полутенью. Модель выбрала физически честный путь, хотя в промпте об этом не просили.

Почему это важно разработчикам и продактам

Первое: сдвиг от tool use к tool making. Привычный агент выбирает из набора готовых функций. Здесь модель написала инструменты под одну задачу, они отработали один раз, и на этом всё. Для разработчика это меняет вопрос. Раньше надо было решать, как интегрировать десяток SDK. Теперь иногда достаточно дать модели песочницу с компилятором и описать желаемый результат.

Второе: это не диффузионная картинка, а программа, которая её считает. Отсюда логичное преимущество, хотя в посте оно не проверялось: результат можно воспроизвести и править. Хочется другой угол солнца или другой клён — меняете параметр и перерисовываете. Генератор изображений такого контроля обычно не даёт. Для продуктов вокруг 3D и визуализации это сигнал: граница между «генератором» и «кодом» начинает стираться.

Третье: побочный эффект на инфраструктуру. Автор шутит, что если сохранять все одноразовые инструменты на GitHub, платформа лопнет, и утверждает, что хранилище там за год выросло в 20 раз. Цифра из поста, мы её не проверяли. Но сама мысль честная: когда код становится расходным материалом, вопрос «что из этого стоит хранить» становится реальным.

Ограничения

• Это один пост и один пример. Неизвестно, сколько внутренних итераций сделала модель, сколько токенов и денег ушло и сколько времени заняла работа. Слова «просто промпт» не отвечают на эти вопросы.
• Path tracer — классика компьютерной графики, по которой написано много материалов. Для нишевых задач с меньшим количеством примеров такой фокус может не сработать.
• Критерий «совершенства» субъективен. Красивая сцена не доказывает, что физика везде посчитана корректно.
• Модель, которая пишет и запускает код, требует изоляции: песочница, лимиты по времени и памяти, запрет на лишний доступ в сеть.

Что с этим делать

Попробуйте на своей задаче. Дайте модели среду с компилятором или интерпретатором и сформулируйте цель, а не рецепт. Посмотрите, возьмётся ли она писать инструменты, а не подбирать готовые. Заложите изоляцию и лимиты заранее. И откройте репозиторий afternoon-light: по нему видно, как выглядит код, который модель написала под одну картинку.