В «Креативном деле» стартует проект профессионального развития сотрудников - наша организация стала одним из победителей конкурса «Профессиональное развитие – 2026» Фонда Потанина. Поддержка фонда позволит нашей команде пройти комплексное обучение по нашим основным направлениям.
У наших ребят уже есть собственные проекты и мы хотим понемногу раскрывать эти истории, чтобы поднять мотивацию участвовать в таких программах, как Потанин, или просто найти занятие для души.
Наш первый рассказ - о генеральном директоре Зое Романовой. В недавнем отпуске она ради интереса решила протестировать ИИ и за семь дней создала три мобильные игры!
Эта статья во многом написана как источник вдохновения для команды - и для всех, кто давно собирается «попробовать наконец эти ваши ИИ-инструменты», но откладывает, потому что кажется, что для этого нужен свободный месяц и особая подготовка.
Читать статью полностью -
У наших ребят уже есть собственные проекты и мы хотим понемногу раскрывать эти истории, чтобы поднять мотивацию участвовать в таких программах, как Потанин, или просто найти занятие для души.
Наш первый рассказ - о генеральном директоре Зое Романовой. В недавнем отпуске она ради интереса решила протестировать ИИ и за семь дней создала три мобильные игры!
Эта статья во многом написана как источник вдохновения для команды - и для всех, кто давно собирается «попробовать наконец эти ваши ИИ-инструменты», но откладывает, потому что кажется, что для этого нужен свободный месяц и особая подготовка.
Читать статью полностью -
Вместо предисловия
Попробовать разработку через ИИ я мечтала давно. Хотелось протестировать Agentic-инструмент, который сам пишет файлы, сам собирает проект, сам коммитит в git и сам ставит сборку на подключенный телефон. Звучит вдохновляюще, но каждый раз находились более важные дела или просто не хватало сил.
Отпуск длился две недели. Первую я провела с подругой, вторую — с Claude Code. За эти семь дней получила три законченные мобильные игры.
Ниже - разбор самого процесса. Главным навыком оказалось не программирование и не знание инструмента, а то, как именно ты формулируешь задачу. Одно и то же по объёму изменение может стоить сорока минут спокойной автономной работы — или полутора часов переписки с постоянными уточнениями.
С чего всё началось: один промпт на три игры
Две вещи, которые я по жизни очень люблю — это творчество и логика. Мне хотелось игру, в которой они не спорят друг с другом, а работают вместе. С этого и начался самый первый промпт — один и тот же для всех трёх игр:
Игра должна одновременно позволять и реализовывать творческий потенциал, удовлетворять желание творить, и давать возможность разгадывать головоломки, реализовывать интеллектуальный потенциал. Дизайн минималистичный, 2D. Игра не должна затягивать — я хочу в любой момент прерваться и потом легко продолжить или вспомнить, на чём остановилась. Игра однопользовательская и не требует подключения к сети. Я представляю это себе как 2 режима: конструктор головоломок и прохождение уровней. В режиме конструктора головоломок можно создавать уровни, а в режиме прохождения — проходить их, механика должна использовать генерацию случайных данных. Оба режима должны быть как-то связаны с пространственной логикой, расположением/соединением объектов. Важное пожелание: я хочу иметь возможность пройти уровень сразу, а не когда я его забуду. То есть нужно, чтобы головоломка сгенерировалась на основе моего творчества, но ответ я не знала.
Здесь нет ни слова про технологии. Ни стека, ни архитектуры, ни фреймворков. Только то, что я хочу чувствовать, играя.
Этот текст родился в обычном разговорном чате с ИИ. Я приходила с ощущением “я хочу вот такое”, ИИ помогал превратить его в формулировку, а потом мы обсуждали подходящие механики. Три коротких разговора дали три готовых файла с ТЗ:
Block Puzzle 8×8 — из моих любимых жанров, я просто дала ему развиться внутри исходной идеи.
Ссылка на RuStore: https://www.rustore.ru/catalog/app/com.blockpuzzle.rotate
Судоку с произвольными регионами — тоже, но там отдельно пришлось обсуждать саму механику: обычное судоку с квадратными блоками не давало нужной творческой части, и идея произвольных регионов появилась в подготовительном разговоре, её тоже предложил ИИ.
Ссылка на RuStore: https://www.rustore.ru/catalog/app/com.zoya.sudoku
А вот My Chain ИИ предложил целиком: он вспомнил механику Lights Out, с которой я была незнакома. По текстовому описанию я её вообще не поняла — до тех пор, пока Claude не собрал интерактивный прототип прямо в чате, и я не потыкала в него пальцем. Это был первый маленький урок: иногда быстрее попросить показать, чем ещё раз попросить объяснить. Дальше по статье этот урок будет повторяться в разных видах.
Ссылка на RuStore: https://www.rustore.ru/catalog/app/com.mychain
Во всех трёх играх сохранилась исходная двойственность: конструктор — творческая часть, прохождение уровней — логическая.
Хроника недели
Игры шли внахлёст. Судоку я начала в тот вечер, когда Block Puzzle казалась готовой (хотя дорабатывала её потом ещё четыре дня на основе своего же пользовательского опыта). My Chain стартовала в тот же вечер, когда закрылась Судоку. Последние правки в Block Puzzle и первый коммит My Chain пришлись на один и тот же день.
Вдохновение накатывало хаотично, но все три проекта доведены до работающих приложений на телефоне.
Три игры в одной таблице
Всё оффлайн, однопользовательское, без рекламы, сети, аккаунтов и аналитики.
Чем позже начиналась игра, тем быстрее она делалась. Отчасти дело в сложности задач, но главное - в первом проекте время ушло на настройку окружения, а к третьему накопилась привычка: какие вопросы закрывать до старта, а какие решать по ходу.
Главное: три способа разговаривать с ИИ
За неделю я перепробовала три стиля работы.
Способ первый: живой диалог короткими репликами
Так начался самый первый вечер. Двенадцать реплик за примерно три часа активной работы, по одной мысли за раз, в темпе разговора: «Выполни промпт», «Почему ты не видишь Android Studio?», «Где выполнить пункт 2 — на телефоне или на компьютере?».
Первые часы работы были посвящены не игре, а борьбе с окружением: Android Studio не видел телефон по USB.
Живой диалог хорош, когда вы ещё не знаете, чего хотите. В тот вечер я на ходу придумала половину игры: сначала мысль вслух — «а что вообще обозначают цвета? может, дать им смысл, например, больше баллов за ряд одинакового цвета?» — и уже через пятнадцать минут это стало отдельной механикой цветового бонуса. Потом: «получилась игра, в которую сложно проиграть, давай новые фигуры будут появляться по три» — и это стало тем самым правилом, которое и делает игру проигрываемой. Потом, следующим утром: «в цветном режиме слишком много цветов, сделай шесть вместо двенадцати».
Все эти решения пришли из практики игры. Диалоговый режим позволяет думать вслух, пока ИИ успевает за вашей мышью. Плата за это - скорость: каждая реплика требует присутствия.
Способ второй: одно плотное ТЗ и долгий автономный заход
К концу той же первой сессии мой стиль начал меняться сам собой. Сначала — развёрнутый баг-репорт из четырёх пронумерованных пунктов после первого плейтеста. Потом — всё более плотные сообщения. А через два дня три сессии подряд выглядели уже так: одна реплика — и дальше ИИ работает один.
Пример: сессия про штраф за отмену хода (когда undo давал бесплатную попытку и позволял читерить). Этот и другие подобные промпты я заранее составляла в отдельном диалоге с ИИ: я описывала проблему своими словами и просила задать мне уточняющие вопросы, а ИИ создавал полноценный промпт с указанием на точные файлы, компоненты и диапазоны строк, а также список уточняющих вопросов. Итог - 40 минут автономной работы ИИ. Следующая сессия на эту же тему - 23 минуты и 178 шагов ИИ подряд (правки, тесты, сборка, скриншоты) без единого вопроса.
Самый яркий пример - сообщение: «Выполни промпт, который лежит в папке». Через полтора часа у Судоку был готов движок и каркас приложения. ТЗ лежало в файле, собранном заранее в отдельном чате.
Самые продуктивные сессии начинались не с усилия, а с разведения жанра. Сначала разговор про «чего я хочу» — расслабленный, без кода. Потом отдельный чат, где этот разговор уже свёрнут в файл и просто выполняется. Дорого стоит не подготовка, а смешивать эти два жанра в одном окне.
Способ третий: показывать, потому что слова кончились
My Chain начиналась по схеме: подготовительный разговор, ТЗ в файле, запуск. Но после установки на телефон я уперлась в геометрию: точки в пространстве вставали не так, связи перекрывались, и стало невозможно понять, какие точки соединяет линия.
И тут выяснилось, что я не могу это объяснить. Я писала реплику за репликой, каждый раз пытаясь сформулировать иначе, получала правку, смотрела на экран и понимала, что это опять не то. Мои собственные заметки в файле проблем звучат ровно так: «работает с багами», «очень тяжело разобраться». Это был предел того, что я могла выразить текстом.
Скриншоты появились от отчаяния. «Посмотри на экран моего телефона прямо сейчас — там открыт баг с расположением точек в пространстве». Дальше — двадцать четыре кадра за семнадцать минут, примерно один раз в сорок секунд: ИИ вносил правку, пересобирал, переустанавливал приложение и отправлял новый кадр для перепроверки. За все три сессии проекта — восемьдесят один скриншот против девятнадцати текстовых сообщений.
Пример: Круги в рамку не вписываются. Рамка сильно напоминает соединяющие линии
Совет новичкам: канал общения нужно подбирать под тип проблемы. Логику и правила - текстом. Геометрию, вёрстку и визуальные баги - картинкой. Если вы третий раз переформулируете одно и то же - меняйте канал.
В первых двух играх в промптах ИИ явно поручалось проверять каждую функцию на телефоне через скриншоты, а в My Chain я запретила это делать, потому что меня раздражало, как долго Claude тестирует и кликает сам. В итоге я убрала эту «мешающую» часть, которую в первые спецификации добавил ИИ. Интересный опыт получился.
Что получилось в сумме
Соблазнительно прочитать эту таблицу так: «меньше писала — быстрее сделала». Но всё было не так.
Число реплик упало не из-за экономии слов, а потому что к третьему проекту базовые процессы (цикл сборки, стек, структура файлов, описание поведения) стали автоматическим правилом. Экономия слов без подготовки даёт обратный эффект: всё непроговоренное ИИ решит за вас.
Своя логика против делегированной
Где проходит граница между «я сама придумываю, как это должно работать» и «пусть ИИ решает»?
Когда я формулировала логику сама
- «Пусть новые фигуры появляются по три» — и это стало ключевым правилом баланса.
- «Сохранять только те игры, где набрано хотя бы одно очко» — решение бага с «пустыми» недоигранными партиями, придуманное мной вместе с самим баг-репортом.
- «Подозреваю, что уровень из домино на поле 8×8 тоже невозможно проиграть — рассчитай условия для каждого размера поля». Это была моя гипотеза, ИИ её проверил, и из этого выросла отдельная проверка уровней на заведомую непроигрываемость.
- «Добавлять в историю все игры с меткой времени последнего обновления, чтобы отличать одинаковые» — так был закрыт неприятный баг, при котором запуск случайной игры мог молча затереть уже сохранённый прогресс, если раскладка случайно совпадала.
- Даже конкретное техническое решение вёрстки: положить на текст модификатор веса, чтобы длинная подпись не выталкивала иконку за экран.
Общее у всех этих случаев одно: я формулировала желаемое поведение, а не способ его достичь. Я говорила «фигуры по три», а не «перепиши метод refill». Про миграцию базы данных я не сказала ни слова о том, как её делать — только о том, какой результат хочу видеть.
Это, кажется, и есть рабочая граница. Логику продукта стоит держать при себе. Способ её реализовать — отдавать.
Когда я делегировала
Там, где у меня не было мнения.
«Не уверена, где именно на экране разместить счёт и рекорд — предложи мне несколько вариантов». «При сборе своего узора сейчас очень легко забыть, что мы вообще собираем. Предложи несколько вариантов решения».
Второй случай мне особенно нравится. Claude предложил список вариантов — и ни один из них мне не подошёл, но зато дал рамку, внутри которой ответ придумался.
Уже под конец Судоку, когда я сдалась с алгоритмом валидации регионов:
«К сожалению, всё ещё достаточно сложно рисовать валидные регионы. Бывает, долго рисую, потом они долго проверяются, а потом оказываются невалидны. Предложи решения, как улучшить этот пользовательский опыт. Можешь использовать идеи из файла plan/sudoku_coloring_solver.py, если сочтёшь их полезными».
Я описала не баг, а собственное ощущение от игры — и отдала поиск решения целиком.
Что происходит, когда не делегируешь и не уточняешь
А теперь неприятная часть. Есть третий режим, в который легко попасть случайно: не сказать ничего. И тогда решение всё равно будет принято — просто без вас.
В My Chain ИИ изменил схему базы данных простым способом, который при обновлении приложения стёр все локальные данные и созданные уровни. Также ИИ молча понизил целевую версию SDK и сборочного плагина, так как нужный компонент не был установлен на ПК.
В Судоку при похожей ситуации меня предупредили: «переход на новую версию без миграции удалит данные». Я выбрала написание миграции, и это стало постоянным правилом проекта.
При неопределённости ИИ выбирает кратчайший путь до работающей сборки, а не самый безопасный.
Решение: перечислить классы необратимых действий один раз и потребовать спрашивать перед любым из них. У меня этот список сейчас выглядит примерно так:
- всё, что может стереть мои данные;
- изменение схемы базы;
- понижение версий зависимостей или инструментов;
- удаление файлов, которых ИИ не создавал;
- отключение или пропуск падающих тестов.
И ещё один приём, особенно полезный, если вы пока не читаете код глазами: просите объяснять, а не только делать. Одна строчка в правилах проекта — «после каждой фичи коротко напиши, какие решения ты принял за меня и почему» — заменяет собой умение самостоятельно заметить, что версия SDK вдруг стала другой.
Правила, которые стоит записать один раз
В середине работы над Судоку я записала правила проекта для всех следующих сессий:
- После реализации фичи пересобирать, коммитить и пушить результат.
- Не тестировать через скриншоты самостоятельно - присылать список для ручной проверки.
- Автоматически обновлять сборку на телефоне.
Эти правила перетекли в My Chain («Установи приложение на телефон. Тестировать не надо - я протестирую сама»).
Рядом появились файлы памяти проекта (краткое описание, правила сохранения данных). Контекст в чате - расходуемый ресурс. В двух из трёх проектов он закончился прямо посреди работы, и разговор пришлось автоматически сжимать. Лучше готовиться к этому заранее, чем обнаружить в неподходящий момент.
Что приходится выбрасывать
Вот примеры того, как на практике что-то шло не по плану.
Фича, прожившая два часа
В Block Puzzle я попросила сделать зеркальное отражение фигур настраиваемым. Появилась фича: кнопка, превью, логика. Через 2 часа 15 минут я написала: «Опыт с отображением неудачный: раздражает. Исправь везде в игре и документации». Откат снёс 5 файлов, интерфейс и 2 теста.
Цикл: своя спецификация → эксперимент против нее → откат к началу. Быстрый цикл разработки позволяет проверить гипотезу на практике на телефоне за пару часов и выбросить ее без сожалений.
Компонент, переписанный почти с нуля
В My Chain компонент, который рисует поле — точки, связи и обработку касания, — во втором коммите был переписан практически целиком: почти столько же строк удалено, сколько добавлено, при том же итоговом размере файла. Соседний модуль геометрии переписан наполовину.
Это та самая геометрическая задача, ради которой я отправила восемьдесят один скриншот.
Ошибки ИИ
ИИ ошибается не концептуально, а глупо. Бессмысленная строка в файле с цветами. Вызов метода, которого не существует в библиотеке. Конфликт имён, из-за которого сборка просто падала.
Всё это было поймано компилятором в течение минуты и исправлено там же. Именно поэтому сборка и установка на реальное устройство должны быть частью цикла, а не финальным шагом. Не «напиши мне код», а «напиши, собери, поставь на телефон». Разница огромная.
Растёт ли качество от игры к игре?
Когда я сложила три проекта рядом, разница бросилась в глаза.
В Block Puzzle и My Chain защитного кода нет вообще — ни одной обработки ошибок в основном коде. Для полностью офлайновых приложений без внешнего ввода-вывода это не катастрофа, но и не то, чем стоит гордиться.
В Судоку — другая картина. Обработка ошибок появилась там, где действительно нужна, и каждый такой участок сопровождён комментарием, объясняющим, почему сделано именно так. Есть история миграций базы данных с версии 1 до версии 5, три из них написаны вручную. И одна из этих миграций прямо описывает найденный и исправленный баг — тот самый, с молча затираемым прогрессом.
Причём — и это важная деталь — баг был найден не при код-ревью, а во время обычной игры. Я заметила, что записи из истории пропадают, сама поняла причину и сама предложила решение.
Почему в Судоку получилось строже? Думаю, задача там объективно сложнее и сама подталкивала к аккуратности.
Неприятная правда
Я ни разу не читала код целиком, проверяя только поведение на телефоне. Плейтест не показывает технического долга: приложение работает и с хардкодом, и без обработки ошибок.
Тесты, написанные ИИ, наследуют его ошибки: если требование понято неправильно, и код, и тест будут написаны под неправильную логику и останутся «зелеными». Ручной плейтест остается главным источником правды.
Чего ИИ не предложит сам
Локализация. Ни в одной из трёх игр тема строковых ресурсов не поднималась вообще. Не то чтобы её обсудили и отклонили — она просто никогда не возникла. В результате весь русский текст интерфейса зашит прямо в код, десятками отдельных вхождений.
Документация для людей. В Block Puzzle техническая документация, которую читает сам ИИ, обновлялась восемь раз. А README, который читают люди, не менялся с самого первого коммита — и до сих пор описывает механики, которых в игре уже нет: и вращение как «уникальную фичу», и зеркалирование, которое я откатила.
ИИ прекрасно делает то, о чём его попросили, и отлично поддерживает то, что видит сам. Всё остальное остаётся ровно там, где вы его оставили.
Небольшое отступление про git
В Block Puzzle я подключила git только на третий день — и в первый же коммит легли около трёх тысяч строк уже готового кода. Вся ранняя разработка попала в историю одним куском. Позже была фича, над которой я работала во вторник, а закоммитила в четверг.
В Судоку наоборот: первый коммит сделан через пять минут после окончания первой вечерней сессии. Но привычка не удержалась — через день один коммит вобрал в себя тридцать один файл и несколько разных фич за день.
В My Chain между первым и вторым коммитом почти сутки правок, которые нигде не фиксировались.
Отдельно смешное: по коммитам казалось, что большая часть моих замечаний из списка проблем так и не была исправлена. По логам переписки видно, что почти всё было исправлено в тот же день — просто до появления первого коммита. Git показывает результат сессий, а не процесс.
Когда одна ваша реплика разворачивается в полторы-две сотни автономных шагов, последний коммит — это единственная точка отката. Если посреди длинного захода что-то поехало не туда, разница будет между «вернуться на десять минут назад» и «вернуться на два дня назад».
Ссылки на репозитории:
- Block Puzzle - https://github.com/ZRomanova/block-puzzle
- Судоку - https://github.com/ZRomanova/sudoku
- My Chain - https://github.com/ZRomanova/lights-out
Что я бы сказала себе в начале той недели
1. Разведите два разговора: «чего я хочу» и «сделай».
2. Формулируйте поведение, а не реализацию.
3. Просите задавать вопросы — явно.
4. Признавайтесь, когда у вас нет мнения.
5. Меняйте канал, а не формулировку.
6. Один раз запишите правила проекта.
7. Перечислите классы необратимых действий.
8. Просите объяснять, а не только делать.
9. Ведите свой список проблем текстовым файлом.
10. Готовьте передачу контекста заранее.
11. Не обсуждайте сомнительную фичу — соберите её.
12. Собирайте и ставьте на устройство постоянно.
13. Помните, что плейтест не видит долга.
14. Не обязательно доводить одно до конца, чтобы начать следующее.
Честная рамка
Три проекта, один человек, одна неделя, один класс задач: офлайновые мобильные игры без сети, без учётных записей, без чужих пользователей и без цены ошибки. Это условия, максимально удобные для работы с ИИ: проверка мгновенная, обратная связь немедленная, последствий у ошибки никаких.
Что из этого переносится куда угодно — всё про формулировки, про правила проекта, про замыкание цикла проверки, про молчаливые решения, про разницу между поведением и реализацией. Что не переносится — темп. «Три игры за неделю» это свойство задачи, а не инструмента.
И ещё одно, что важно сказать прямо, раз уж статья адресована в том числе тем, кто только начинает. Я разработчик с образованием и опытом. Это влияет: я пишу баг-репорты в терминах компонентов, и сама вижу, что «раскладка совпала → перезаписалось по ключу».
Все принципы общения с ИИ работают и без профильного опыта. Однако у новичка не будет такой же технической страховочной сетки, как у разработчика. Но для этого есть отличный заменитель - он в нашем списке под номером восемь: просите ИИ объяснять принятые за вас решения. Это не то же самое, что уметь читать код, но это ближайшее доступное приближение.
К тому же, всё что вы делаете с таким инструментом, остаётся в логах сессий - вы получаете полную запись работы реплика за репликой. Эта статья целиком собрана из них. Провести честную ретроспективу собственной недели по этим записям - отдельное полезное упражнение, которое стоит того, чтобы его проделать.
Вместо заключения
Если из всего написанного оставить одну мысль, она будет такая.
Я думала, что учусь пользоваться инструментом. А на самом деле неделю училась внятно объяснять, чего я хочу. Три игры за неделю — это приятно.
Но по-настоящему ценным оказалось, как быстро при этом меняешься сам.