Последние пару лет вокруг ИИ сформировался очень удобный миф: теперь не нужно уметь программировать, не нужно разбираться в архитектуре, не нужно понимать продукт — достаточно правильно написать запрос, и через пару часов у тебя готово приложение, сервис или даже игра.
Звучит красиво. На практике всё сильно сложнее.
Я почти год делаю свой футбольный онлайн-менеджер myclub11. Серверная часть у меня на Go, интерфейс — на React, данные — в PostgreSQL. При этом Go я раньше не знал, а с фронтендом работал довольно ограниченно. ИИ в процессе использовал постоянно: для кода, рефакторинга, прототипов, интерфейсов, обсуждения механик и поиска вариантов реализации.
И за это время я понял простую вещь: ИИ действительно ускоряет разработку, но он не делает игру за вас.
Даже если у вас за плечами годы опыта, путь до живой системы всё равно занимает месяцы. Потому что игра — это не набор файлов, которые можно сгенерировать за вечер. Это архитектура, механика, баланс, дизайн, ассеты, данные, контент и десятки решений, которые жёстко завязаны друг на друга.
Почему миф про «сделал за вечер» так хорошо работает
Причина простая: ИИ очень убедителен.
Ты пишешь:
сделай backend,
сделай frontend,
добавь авторизацию,
сгенерируй сущность игрока,
сделай матчевую логику,
собери страницу состава.
И получаешь код. Много кода. Иногда вполне аккуратного. Иногда даже запускаемого.
У человека без опыта в этот момент возникает ощущение, что всё почти готово. Что осталось немного докрутить — и можно выпускать продукт.
Но ИИ отлично создаёт иллюзию готовности.
Отдельный экран есть.
Отдельный обработчик есть.
Таблица есть.
Компонент есть.
А потом выясняется, что всё это не складывается в систему.
Одна модель данных противоречит другой.
Фронтенд ждёт не ту структуру, которую удобно хранить на бэкенде.
Матч считает одно, интерфейс показывает другое.
Игроки генерируются, но ломают баланс.
Экономика вроде существует, но в неё не хочется играть.
А любое изменение в одной части начинает цеплять ещё три соседние.
И вот здесь начинается настоящая разработка. Не генерация кода, а сборка продукта.
Я не знал Go и почти не работал с фронтендом. Но это оказалось не главной проблемой
Если смотреть со стороны, можно подумать, что мой главный челлендж был в том, чтобы освоить новый стек.
Формально это правда. Go был для меня новым языком, фронтенд — не основной зоной, а проект сам по себе большой. ИИ тут действительно очень помог: ускорял вход в новый стек, помогал быстрее писать обработчики, структуры, SQL-запросы, React-компоненты, разбирать ошибки и рефакторить куски логики.
Отрицать пользу ИИ было бы просто нечестно.
Но довольно быстро стало ясно, что язык и синтаксис — это не самая сложная часть работы.
Намного сложнее было другое:
-
понять, как должна быть устроена игра как система;
-
выбрать архитектуру, которая не развалится через месяц;
-
спроектировать механику;
-
продумать логику роста, экономики и взаимодействия подсистем;
-
собрать всё это в единый продукт, а не в набор разрозненных экранов.
Go можно подтянуть. React можно дожать.
А вот проектирование игры никакой новый стек за тебя не упростит.
Главная ошибка — думать, что игра состоит из кода
Сайт, CRUD-сервис или внутренняя админка часто прощают многие ошибки. Игровой проект — гораздо реже.
Потому что игра держится не просто на страницах и API. Она держится на том, что механики должны работать вместе.
В моём случае это означало, что параллельно приходилось думать о вещах из совершенно разных слоёв:
-
как генерируются игроки;
-
как считаются рейтинг, потенциал, возраст и развитие;
-
как хранить состав команды;
-
как увязать слоты, позиции, формации и перестановки;
-
как считать силу команды;
-
как учитывать усталость и готовность;
-
как устроить матчевую логику;
-
как связать серверный расчёт с фронтенд-визуализацией;
-
как должна работать экономика;
-
как монетизация не должна ломать интерес к игре;
-
как должен выглядеть интерфейс, чтобы им вообще хотелось пользоваться.
Ни один из этих пунктов не решается фразой «сделай мне код».
Код — это уже следствие решений. А самые тяжёлые решения лежат до кода.
Что на самом деле заняло у меня почти год
Если коротко — не написание файлов, а постоянная работа над системой.
1. Механика
Самое тяжёлое — механика.
Когда делаешь футбольный менеджер, быстро выясняется, что даже «обычный игрок» — это уже не просто набор полей. У него есть возраст, рейтинг, потенциал, позиция, гражданство, стоимость, здоровье, развитие, роль в составе и место в экономике игры.
И каждый параметр тянет за собой новый вопрос.
Если игрок молод, как быстро он должен прогрессировать?
Когда развитие должно замедляться?
Как учитывать позицию?
Как сделать талантов интересными, но не сломать баланс?
Как связать генерацию игрока с национальностью, именами, визуалом и вероятностью определённого развития?
То же самое с матчем. Со стороны кажется, что матч — это просто набор событий. На практике это баланс между случайностью, силой команды, усталостью, ролями игроков, понятностью для пользователя и ощущением справедливости.
Если случайности мало — игра становится скучной.
Если случайности много — игрок чувствует хаос.
Если молодые растут слишком быстро — ломается экономика.
Если слишком медленно — пропадает интерес к развитию.
Именно на такую настройку и уходят месяцы.
2. Архитектура
Отдельная боль — архитектура.
Очень быстро стало понятно, что в игре нельзя просто хранить данные «как удобно прямо сейчас». Например, состав команды. На словах всё просто: есть старт, есть запасные, есть резерв. А дальше начинаются вопросы:
-
игрок привязан к позиции или к слоту;
-
как хранить перестановки;
-
как сделать drag-and-drop без хаоса;
-
что считать источником истины — фронт или бэк;
-
как не потерять состояние после перезагрузки;
-
как работать с разными формациями.
Такие вещи кажутся мелочами, пока не попробуешь реально построить поверх них игру. А потом выясняется, что одно неудачное решение на старте заставляет переписывать половину логики позже.
ИИ может предложить несколько вариантов. Но выбрать правильный он не может за тебя, потому что не ему жить с последствиями этого решения через три месяца.
3. Дизайн
Ещё один миф — будто дизайн в такой игре можно спокойно оставить “на потом”.
Переделать его, конечно, можно. Вопрос в цене такой переделки.
В менеджере пользователь большую часть времени смотрит не на красивый лендинг, а на рабочий интерфейс: состав, карточки, таблицы, ростеры, игроков, рынок, матчи, фильтры, вкладки. Если всё это изначально собрано без системы, продукт быстро начинает ощущаться разрозненным и дешёвым, даже если под капотом всё работает нормально.
Проблема в том, что поздняя переделка дизайна редко ограничивается “подкрутить цвета и шрифты”. Обычно приходится заново пересобирать визуальную иерархию, пересматривать компоненты, перепаковывать экраны, унифицировать отступы, карточки, акцентные элементы и часто даже трогать логику интерфейса.
Мне пришлось отдельно тратить время на то, чтобы искать стиль:
-
как должны выглядеть игроки;
-
как должны выглядеть формы;
-
как должны выглядеть карточки;
-
как оформить экраны состава, магазина, матча, генерации;
-
какие элементы должны быть акцентными;
-
как собрать единый визуальный язык.
ИИ может ускорить поиск направлений и помочь с первыми итерациями. Но консистентность он не удерживает сам по себе. Её всё равно приходится выстраивать вручную — экран за экраном, компонент за компонентом.
4. Ассеты и люди
Когда в игре появляется слоёная генерация персонажей, формы, карточки, логотипы и прочие визуальные ассеты, возникает ещё один сложный слой работы — люди, пайплайн и постоянная ручная доводка.
Здесь уже недостаточно просто «найти художника». Нужно заранее понять, какие именно ассеты нужны проекту, как они должны быть нарезаны, какие у них должны быть размеры, пропорции, якоря и зоны совмещения. Нужно продумать, как обеспечить совместимость слоёв между собой, как генератор будет их собирать, как всё это встроится в интерфейс и движок, и как написать такое ТЗ, по которому художник действительно выдаст пригодный для работы результат, а не просто красивую картинку.
Отдельная проблема в том, что ИИ здесь помогает гораздо меньше, чем может показаться со стороны. Он может подсказать направление, набросать идею, предложить стиль или вариант композиции. Но конечный продукт он не даёт. В работе с ассетами это особенно заметно: он врёт с размерами, плывёт в пропорциях, не держит стабильную форму элементов, а через каждые несколько запросов вообще начинает уезжать в другую сторону.
И это логично. ИИ — не Photoshop и не человек, который правит конкретный слой. Он не «меняет элемент» в привычном смысле. Он заново перерисовывает изображение целиком, каждый раз пересобирая его по вероятностной модели. Из-за этого даже при хорошем результате в одном запросе в следующем у тебя может съехать лицо, измениться форма волос, поплыть посадка одежды, нарушиться масштаб или пропасть нужная деталь.
Поэтому в реальной разработке ИИ здесь скорее полезен как инструмент для поиска направления, чем как поставщик финальных игровых ассетов. Всё, что касается точной нарезки, повторяемости, совместимости и качества, всё равно приходится собирать руками: через ТЗ, через художников, через правки, через проверку и через постоянную подгонку под систему.
Поиск фрилансеров, объяснение требований, переделки, уточнения, контроль качества и интеграция результата в игру — это тоже полноценная часть разработки. И по времени она часто оказывается не менее тяжёлой, чем код.
5. Разбор аналогов
Отдельно много времени ушло на анализ других продуктов.
Не в формате «посмотрел конкурентов», а в формате:
-
что у них работает;
-
что работает плохо;
-
где раздражает интерфейс;
-
где механики поверхностные;
-
где экономика ломает интерес;
-
где донат съедает игру;
-
где контента много, но системы нет.
Такой разбор нужен не для копирования, а чтобы не повторять чужие ошибки. И это тоже нельзя просто делегировать ИИ: он может помочь структурировать мысли, но оценка слабых мест продукта всё равно остаётся за тобой.
6. Данные и исследование
Ещё один кусок, который со стороны почти не виден, — сбор и структурирование данных.
В моём случае это была информация по странам, культурным особенностям, именам, визуальным особенностям, футбольным ассоциациям и контексту для генерации игроков и клубных сущностей.
Именно такие данные потом создают ощущение глубины. Но за этим ощущением стоит не магия, а долгая ручная работа.
Где ИИ реально был полезен
Важно не впасть в другую крайность и не сказать, что ИИ бесполезен. Это было бы неправдой.
Для меня он оказался полезен в нескольких точках:
-
ускорение входа в новый стек;
-
рутинный код;
-
быстрые черновики компонентов и обработчиков;
-
рефакторинг;
-
поиск альтернативных вариантов реализации;
-
быстрый разбор ошибок;
-
формализация идей в код или структуру;
-
обсуждение архитектурных компромиссов;
-
помощь с документацией.
По сути, ИИ очень хорошо работает как ускоритель мышления и ускоритель рутины.
Но именно ускоритель. Не замена разработке.
Если у тебя нет понимания системы, он поможет быстрее генерировать не решение, а хаос.
Почему опыт всё равно решает
Мой главный вывод за этот год такой: опыт нужен не только для того, чтобы писать код руками.
Опыт нужен, чтобы:
-
отбрасывать плохие решения, даже если они красиво звучат;
-
видеть архитектурные тупики заранее;
-
понимать, где механика выглядит правдоподобно, но сломается на масштабе;
-
чувствовать, какие части продукта вообще надо проектировать отдельно;
-
не влюбляться в первый работающий вариант.
ИИ очень убедителен. Он часто предлагает решения, которые выглядят логично и даже красиво. Но между «работает на демо» и «живёт в продукте» лежит огромная разница.
И вот эту разницу он сам не закрывает.
Что я понял в итоге
Если вопрос звучит так: можно ли с помощью ИИ зайти в новый стек и начать делать большой проект?
Мой ответ — да, можно.
Если вопрос звучит так: можно ли реально собрать игру в духе “за вечер”, не имея навыков разработки, просто потому что у тебя есть ИИ?
Мой ответ — нет.
Поэтому моя формулировка в итоге простая: ИИ ускоряет разработку. Но ни один проект он за вас не сделает.
ссылка на оригинал статьи https://habr.com/ru/articles/1033586/