Вайбкодим: Dota2 Item Efficiency Analysis
Весной 2020 года я решил сделать проект: посчитать эффективную стоимость предметов в Dota 2. Тогда всё было в ручном режиме — Excel, формулы и поиск данных по разным источникам.
В 2026 я вернулся к этой идее, но уже с AI-агентами. Оказалось, что такую задачу теперь можно реализовать на новом уровне.
Это статья скорее про опыт работы с AI, чем про Dota: что стало проще, где всё ещё сложно и как правильно организовать процесс.
Проект Dota2 Item Efficiency Analysis
Версия 0.1 — Excel
В 2020 году, на патче 7.25, я вручную вбивал цифры в Excel. Идея была простой: вывести «эффективную стоимость» предмета через набор геймдизайнерских аксиом. С базовыми статами всё считалось относительно легко. Дальше начинались ауры, пассивки, активные способности — и сложность оценки росла.
На реализацию ушёл месяц или два. В рамках одного патча PoC работал хорошо и давал осмысленные результаты. Проблемы начинались с выходом следующего обновления. Каждый патч означал ручную проверку изменений, ввод новых значений и правку формул. Excel отлично подошёл для прототипа, но масштабировать такую систему невозможно.
К тому же xls-файл сложно распространять и поддерживать. GitHub Pages тогда я не использовал. В итоге проект отправился на полку.
Результат работы показан на рисунке слева. Справа уже версия со второго подхода, о которой ниже.
Версия 1.0 — автоматизация с AI
В 2026 году я решил вернуться к проекту проектом Dota2 Item Efficiency Analysis.
На этот раз цель была другой: максимальная автоматизация. Никакого ручного ввода цифр. Только парсинг файлов игры и один раз сформулированные правила расчёта.
Пайплайн получился прямолинейным:
- Парсим items.txt из файлов игры → получаем items.json.
- Применяем правила из YAML файла → считаем эффективные стоимости → новый JSON.
- Генерируем статические веб-страницы по патчу: таблицу и график
- Строим страницу сравнение патчей между собой
Код, структуру yaml файла и все-все-все я отдал на откуп AI-агента.
Код проекта на github. На него тоже ушел месяц.
Контекст — главная проблема
Данные из старого Excel-файла по патчу 7.25 стали отправной точкой. На их основе AI смог сформировать первый черновик аксиом, даже без дополнительных источников. Но дальше всё шло со скрипом.
Проблема была в том, что items.txt содержит только численные данные. Агент не понимал игрового мира: что такое аура, как работает пассивка, что стакается, а что нет. Он видел лишь числа и короткие названия.
Чтобы дать ему контекст, я попросил написать crawler на Python, который обошёл страницы Liquipedia по всем предметам и собрал структурированный JSON с их описаниями. В последующих инструкциях добавлял: «При работе используй файл liquipedia.json для выявления игровых механик».
Эта доработка сработала отлично. Агент начал предлагать осмысленные варианты расчёта стоимостей, улучшать аксиомы стало проще. AI при наличии структурированного контекста он работает значительно лучше.
Как я организовал работу агентов
Я не писал код, а выстраивал процесс. Основная задача была в том, чтобы проверить корректность геймдизайнерских аксиом.
Цикл работы над проектом и реализацией фич выглядел так: сначала я формировал вводные, потом агент составлял план проекта, выполнял его ревью, реализовывал задачи, проверял результат и делал ревью реализации. Все эти шаги выполнял агент, включая ревью.
Больше всего времени ушло на валидацию правил расчёта стоимостей — предметов больше 150. В диалоге с ИИ я последовательно проходил по каждому предмету, оценивал предложения и корректировал аксиомы.
В этом проекте мой фокус полностью сместился с кода на предметную область.
Практические выводы
При работе с AI-агентами я выделил для себя несколько принципов.
- Цели должны быть конкретными (лучше по SMART). Чтобы получить результат, важно точно понимать, чего хочешь. Если не знаешь, как достичь цели, AI может построить детальный план — главное, чётко формулировать задачу.
- Декомпозиция — ключевой навык. Разделяя работу на этапы, проще контролировать процесс и выявлять ошибки.
- Циклом обратной связи: исправь → проверь, позволяет пустить агента в долгое автономное плаванье, что ускоряет прогресс и улучшает качество результатов.
- Контекст нужно контролировать. План сначала формируется в отдельном файле, затем исполняется с чистым контекстом. Ревью проводится аналогично. Главного агента лучше использовать как project manager, распределяя задачи между вспомогательными агентами.
- Skills имеют большой потенциал для повторяющихся задач, например, для организации процесса по предыдущему пункту. Я применял их минимально — для поэтапного анализа групп предметов.
Улучшения организации работы
Проект показал, что AI уверенно создаёт PoC с нуля и работает внутри существующей архитектуры. Но есть промежуточный этап, который я пока не доработал — переработка архитектуры после PoC. Любой PoC содержит временные решения, костыли и куски, выросшие из экспериментов.
Идея, которую хочу попробовать: после успешного PoC разобрать архитектуру как чужой проект, найти слабые места и переписать его заново. Вторая версия не должна наступить на грабли PoC.
Я также понял, что проекту не хватает лёгкой, но осмысленной бюрократии. Даже для PoC полезно составить ТЗ с ограничениями, целями и принципами. Этот документ стоит держать прямо в репозитории и обновлять по мере развития проекта. Это создаёт точку отсчёта, к которой можно всегда обратиться.
Хочу добавить простую систему задач — мини-Jira внутри проекта. Папка с todo и done, где в done остаются короткие записи о том, что сделано и почему выбран именно такой подход. Это важно ради контекста: при рефакторинге легче понять, какие части ценны, а какие устарели. История решений снижает хаос.
Одним словом, к AI-проекту стоит подходить как к корпоративному проекту: анализ, планирование, ТЗ, история решений, тестирование, добавление новых функций. Разница только в том, что теперь всё живёт в одной папке рядом с кодом. Корпорации используют такой подход не из любви к процессам, а потому что он работает.
Планы по обучению работе с AI
Похоже, мы вошли в эру лёгкой реализации любой программной идеи. Раньше мысли часто оставались в голове. Сейчас довести идею до PoC — вопрос не месяцев, а недель, а иногда и дней. Идеи можно фиксировать списком и проверять на практике. Вероятность того, что одна из них окажется бриллиантом, растёт. Не потому что идей стало больше, а потому что снизился порог входа в реализацию.
Проект по Dota в основном был про работу с данными и формализацию предметной области. Следующий шаг хочется сделать более программистским — построить процесс вокруг TDD. Агенты умеют писать тесты быстро, но действуют по-человечески: сначала код, потом тесты. Интересно проверить хваленый рост качества разработки с TDD, когда стоимость написания тестов для AI практически нулевая. Этот подход может раскрыться с новой силой.
На примете есть ремастеры пары университетских проектов. Сейчас они лежат как отчёты по курсовым и лабораторным. Хочется переписать их и выложить через GitHub Pages, чтобы они сперестали быть архивными файлами.
Отношении к ИИ
Я искренне восхищён мощностью современных инструментов. AI всё проникает в рабочие процессы, документация пишется быстрее, прототипы появляются мгновенно, технический долг исчезает. Но изменения не только в программировании. Видео-генерация, графика — всё это впечатляет. Теперь идеи не обязаны умирать в голове. Их можно быстро довести до рабочего состояния.
Лучше всего мое отношение к ИИ описывает разворот из энциклопедии Профессора Фортрана.
Еще на ум приходит роман “Луна жестко стелет” Роберта Хайнлайна, в котором главный герой - лучший промт-инженер всея луны.