Как я проверял, работает ли no-code после 28 лет full-code
В позапрошлом месяце я решил провести эксперимент: собрать небольшой арена-шутер на Rust, не написав ни одной строки кода вручную. Работал в Cursor Ultra с его встроенными моделями (Sonnet, GPT), иногда подключал Antigravity. Я писал только текст, всё остальное делал ассистент в редакторе.
Rust я до этого не знал, геймдевом не занимался, поэтому это был чистый эксперимент: что получится, если опираться только на промпты и общий инженерный опыт.
Старт: 10 параллельных версий
Сначала я сделал то, что обычно делать дорого, но с ИИ это как раз удобно. Я открыл 10 отдельных рабочих экземпляров в Cursor и дал всем один большой промпт: описал движение, оружие, карты, сетевую часть, хотсит-режим, референсы вроде Q3 и NFK (добавил репы в workspace)
В итоге получил 10 разных каркасов проекта. Ни один нельзя было взять и сразу запускать как игру, но из них можно было выбрать основу: тот, где структура проекта была более-менее чистой, понятной и вменяемой по архитектуре. Его я оставил как основной, остальные просто закрыл.
Очень быстро вылезла ещё одна особенность: модели постоянно ошибаются в одних и тех же местах, независимо от того, какую из них использовать. Типичные зоны проблем:
- движение и физика
- тайминги анимаций и оружия
- логика ботов
- сетевой код
Чтобы не нарушать правило «не пишу код руками», приходилось строить у себя в голове нормальную ментальную модель игры и просить ассистента аккуратно подсветить проблемные места.
Я делал так:
- просил добавить логи и простые счётчики в нужные функции
- запускал игру, смотрел, где значения «уползают» или ведут себя странно
- описывал проблему словами и по логам, без правки кода
- просил модель переписать конкретный кусок с учётом этого поведения
Получалось что-то вроде удалённого ревью: я вижу, как игра ведёт себя не так, как задумано, и через логи объясняю это модели.
Самое неприятное в эксперименте было другое. Иногда я проводил с проектом 4–6 часов: добавлял фичи, уточнял механику, несколько раз просил переписать части рендера или логики. На каком-то этапе всё выглядело «нормально», пока я не смотрел на FPS.
Был момент, когда после примерно 30 итераций я увидел вместо 120 кадров в секунду 11 FPS. Проект всё ещё работал, но играть было невозможно.
Приходилось просто откатываться назад: возвращаться к более ранней версии, где всё летало, и идти другим путём. Это происходило как раз из-за того, что я не геймдев-разработчик и раньше не работал с графикой, GPU и связанными ограничениями. Иногда я слишком поздно замечал, что механика или эффект реализованы «в лоб» и начинают душить производительность.
Ноль ручного кода. Но мне нравится то, что получилось.