Вступление: Unreal Engine 5 — это действительно сложно.

1. UE5 — это не веб‑приложение. Это не CRUD‑сервис. Это не фронтенд на React.

2. Миллионы строк кода на C++ в самой кодовой базе движка.

3. Редактор с ручным управлением: большинство действий в UE5 делается через GUI — клики, перетаскивания, настройка параметров вручную.

4. Сложная архитектура: модули, плагины, подсистемы, зависимости между которыми не очевидны.

5. Blueprints: визуальное программирование, которое не очевидно автоматизировать.

6. Высокий порог входа: чтобы писать под UE5, нужно знать C++, архитектуру движка, систему actors, blueprints, render‑pipeline.

7. Это не тот проект, где «дал агенту задачу и он сделал». Это проект, где большинство «экспертов по внедрению AI» сказали бы: «Тут автоматизация невозможна. Слишком сложно. Слишком много ручного управления. Слишком много неявных знаний».

И тем не менее. Сейчас на этом проекте AI пишет весь код на C++ сам, дебажит, перезапускает среду выполнения и сам проверяет результат, после чего дает добро проверить человеку. Вся разработка и внедрение фич — это постановка задачи по спеке и контроль в процессе. 98% времени — просто смотрим одним глазом в мониторы. 2% думаем и исправялем что пошло не так.

Проблема: UE5 — редактор с ручным управлением

Главная сложность UE5 для автоматизации — это не отсутствие API. Python в UE5 позволяет вызывать почти всё в редакторе программно. Проблема в другом: цепочки действий очень сложные.

Одно действие в редакторе — это одна команда. Но реальная задача — это цепочка из десятков и сотен действий, которые должны быть выполнены в правильном порядке, с правильными параметрами, с обработкой ошибок на каждом шаге.

Примеры сложных цепочек:

1. Написание блюпринтов в редакторе: создать граф нод, соединить их, настроить параметры, скомпилировать, проверить. Это неочевидный процесс, который требует понимания визуального программирования UE5.

2. Создание и настройка actors: создать actor, добавить компоненты, настроить свойства, привязать к уровню, проверить рендер.

3. Настройка материалов и шейдеров: создать материал, настроить параметры, подключить текстуры, применить к мешу, проверить визуально.

4. Работа с ландшафтом и освещением: создать ландшафт, настроить слои, расставить источники света, запечь освещение.

Каждое из этих действий можно вызвать через Python или напрямую через C++ blueprinted. Но оркестрация цепочки — это нетривиальная задача. Нужны управлять последовательностью действий, обрабатывать ошибки, проверять промежуточные результаты.

Решение: агентная среда с полным циклом исполнения

Вместо того чтобы пытаться встроить AI в существующий процесс разработки UE5, мы построили агентную среду, которая закрывает полный цикл:

Постановка задачи (человек) → Анализ и планирование (AI + человек) → Написание кода на C++ (AI) → Компиляция (автоматически) → Запуск среды выполнения (AI) → Тестирование / проверка результата (AI) → Дебаг при ошибках (AI) → Итерация до успеха → Верификация результата (человек)

Ключевое отличие от стандартного подхода: агент не просто пишет код. Агент управляет всем циклом: компилирует, запускает, тестирует, дебажит, перезапускает. Человек остаётся в двух точках: постановка задачи и верификация результата.

Полный список того, что автоматизировано на проекте:

Разработка кода

1. Написание кода на C++: агент пишет код по спеке, компилирует, фиксит ошибки компиляции

2. Поиск модулей и анализ необходимого кода в движке: агент ищет нужный код в кодовой базе UE5 через индексацию (50ms на запрос)

3. Рефакторинг C++ кода проекта: агент рефакторит по заданным правилам, проверяет, что ничего не сломалось

4. Debug: агент парсит логи, находит корневую причину, фиксит

5. Compile: автоматическая компиляция с парсингом ошибок

6. Build: автоматическая сборка проекта

7. Archive project: автоматическая архивация проекта

8. New code plugin: автоматическое создание новых плагинов по шаблону

Блюпринты

1. Написание блюпринтов в редакторе: автоматизация цепочек создания графов нод

2. Запуск blueprinted function для тестирования: агент запускает блюпринт‑функции и проверяет результат

3. Blueprint to C++: написан нативный программный конвертер (не AI‑конвертация, а именно программный конвертер). Конвертирует блюпринты в C++ код. Конвертер в процессе постоянного улучшения.

Тестирование и дебаг

1. Запуск среды выполнения: агент запускает UE5 Editor или PIE для тестирования

2. Анализ логов: агент парсит логи UE5, находит ошибки, предупреждения

3. Анализ крашей UE5: агент парсит краш‑дампы, находит причину, фиксит

4. Визуальная проверка: скриншоты, захват состояния сцены для сравнения

Генерация контента (в процессе)

1. Artist генерация контента сцены из мешей: попытки автоматизировать расстановку мешей в сцене

2. Генерация материалов: попытки автоматизировать создание и настройку материалов

Scope автоматизации: запредельный для любой game studio.

Если посмотреть на список выше, становится понятно: scope автоматизации уже запредельный для любой UE5 dev studio. Это не «написание кода с автокомплитом». Это полный цикл разработки: от написания кода до компиляции, запуска, тестирования, дебага, рефакторинга, создания плагинов, конвертации blueprints в C++.

Это не «помощник разработчика». Это исполнительный слой, который закрывает 90% рутинных задач в разработке под UE5.

Для UE5 dev studio это означает:

• Разработчик не пишет код руками. Он ставит задачу по спеке.

• Разработчик не дебажит руками. Агент парсит логи и краши.

• Разработчик не компилирует руками. Агент компилирует и фиксит ошибки.

• Разработчик не создаёт плагины руками. Агент создаёт по шаблону.

• Разработчик не конвертирует blueprints в C++ руками. Нативный конвертер делает это программно.

Разработчик остаётся в двух точках: постановка задачи и верификация результата. Всё остальное — агент.

Как это устроено: компоненты

(Статья готовилась до того, как вышел UE5.8 с его нативным mcp tools, а проект и инструменты пока что на 5.7)

1. Скиллы для управления UE5 

Python в UE5 позволяет вызывать почти всё в редакторе программно. Мы написали набор скиллов + MCP tools server C++ native, которые оркестрируют цепочки действий:

1. Skill компиляции: запускает сборку проекта, парсит ошибки компиляции, возвращает агенту структурированный вывод

2. Skill запуска редактора: запускает UE5 Editor в headless режиме или с минимальным GUI

3. Skill запуска PIE: запускает Play In Editor для тестирования геймплея

4. Skill создания/настройки акторов: через MCP tools server создаёт акторы, настраивает компоненты

5. Skill написания блюпринтов: через MCP tools server оркестрирует цепочку создания графов нод

6. Skill запуска blueprinted function: через MCP tools server запускает блюпринт‑функции для тестирования

7. Skill анализа логов: sh‑scripts + ripgrep парсит логи UE5, находит ошибки, предупреждения

8. Skill анализа крашей: sh‑scripts + ripgrep парсит краш‑дампы, находит причину

9. Skill скриншота/захвата: через MCP tools server делает скриншот или захватывает состояние сцены для визуальной проверки

10. Skill создания плагина: создаёт новый плагин по шаблону

11. Skill архивации проекта: sh‑script архивирует проект

Каждый skill — это executable‑код, а не инструкция для человека. Агент вызывает skill напрямую.

2. Нативный конвертер Blueprint to C++

Это не AI‑конвертация. Это программный конвертер, который:

• Читает структуру blueprint

• Конвертирует нод‑графа в C++ код

• Сохраняет логику и связи

• Генерирует C++ код, который компилируется

Конвертер написан нативно, без AI. Это гарантирует детерминированность: один и тот же blueprint всегда конвертируется в один и тот же C++ код. Никаких галлюцинаций. Никаких «похожих, но не тех» результатов.

Конвертер в процессе постоянного улучшения: добавляются новые типы нод, улучшается обработка edge cases, оптимизируется генерируемый код.

3. Feedback Loop

Это критический компонент. Без него агент не может проверить результат своей работы.
Feedback loop включает:

• Компиляция: агент пишет код → запускает компиляцию → если ошибки, парсит их → фиксит → компилирует снова

• Запуск: агент компилирует → запускает среду → если краш, парсит логи → фиксит → запускает снова

• Тестирование: агент запускает PIE или blueprinted function → проверяет поведение → если не соответствует ожиданиям → фиксит → тестирует снова

• Анализ логов: агент парсит логи UE5 → находит ошибки → фиксит

• Анализ крашей: агент парсит краш‑дампы → находит причину → фиксит

• Визуальная проверка: где возможно — скриншоты или захват состояния для сравнения
  (пока что используется редко, основная разработка связана с С++)
  
  Агент не ждёт человека для проверки. Он проверяет сам. Человек подключается только для финальной верификации.

4. Поиск по кодовой базе: индексация

Кодовая база UE5 — миллионы строк. Голый grep по такой базе бесполезен: секунды на запрос, тысячи совпадений.

Мы построили индексацию кодовой базы:

• Статическая индексация: индексируем заголовки и исходники UE5 при подключении движка. Индекс содержит: заголовки, сигнатуры функций, ключевые классы

• Динамическая индексация: при изменении файлов проекта индекс пересобирается инкрементально

• Поиск по индексу: запрос занимает >50ms, вывод — сразу кусок кода с контекстом

Это не AST Search. Это grep + индексация + shell‑скрипты. Работает быстрее и проще, чем AST Search на такой кодовой базе.

Агент использует этот поиск через скилл: запрашивает функцию, класс, сигнатуру — получает релевантный кусок кода за миллисекунды. Не тратит токены на сканирование всей базы.

5. Память и контекст: memory.md

Долгие задачи в UE5 (написание нового модуля, миграция плагина) могут занимать часы работы агента в тандеме с человеком. Окно контекста переполняется. Compaction неизбежен.

Решение: memory.md.

Перед compact: запиши в memory.md текущую задачу, прогресс,
ключевые решения, ограничения и следующие шаги.
После compact: прочитай memory.md и продолжай работу.

Три строчки промпта. Агент сам скидывает критический контекст в файл перед компактизацией и подгружает обратно после. Ничего не теряется.

Для очень длинных задач добавляем decisions.md: все архитектурные решения с обоснованием. После compact агент читает оба файла и восстанавливает полный контекст.

6. Спецификация задачи

Каждая фича начинается со спеки. Не «сделай X». А структурированный документ:
не буду утомлять, как устроен AI SKILL для написания спецификаций по задачам.

Спека пишется в диалоге с AI за 20–30 минут для очень сложных задач. иногда обдумывается и пару дней, после того как AI написал предварительную спеку и его варианты решения. Как правило AI задаёт уточняющие вопросы, помогает формализовать edge cases, выявляет скрытые требования.

Это не бюрократия. Это контракт между человеком и агентом. Без контракта агент делает по‑своему. С контрактом — исполняет.

Процесс работы: как выглядит типичный день

Утро: постановка задач практически не нужна. Есть огромное число сырых спецификаций, обработанных, просто бери задачу и реализуй в зависимости от приоритета задачи и реализуемого функционала.

Формулируешь задачу по спеке. или продолжаешь реализовывать функционал в сессии вчерашнего дня, если задача не завершена. Никаких сложных планирований и убийства времени на неэффективные согласования.

День: агенты работают в тандеме с человеком. Пока что человек нужен чтобы следить, что ИИ правильно понимает общую картину, и не циклится, не уходит в пространное решение багов.
Каждая такая ошибка, это повод провести аудит сессии сразу же остановив агента.
Таким образом ошибки ИИ, сразу формализуются и задача переключается на то чтобы понять почему ии ушел не туда. в отдельной сессии корректируется AI‑harness(это отдельный вопрос централизованного AI‑harness на проекте)
и снова продолжаем решать задачу.

Сам Агент выполняет большую часть рутины без инструкций человека:

1. Читает спеку

2. Анализирует кодовую базу через индексацию

3. Пишет код на C++

4. Компилирует

5. Если ошибки компиляции — фиксит

6. Запускает среду выполнения

7. Если краш — парсит логи, дебажит, фиксит

8. Тестирует в PIE или через blueprinted function

9. Если поведение не соответствует ожиданиям — фиксит

10. Повторяет до успеха

Разработчик не сидит и не смотрит, как агент печатает код. Задача следить, что агент в общем и целом движется правильно.
Контроль: одним глазом в мониторы

98% времени — это наблюдение. Не активное вмешательство. Наблюдение.
но это пока что, потому что задачи реально сложные.
На простых задачах — когнитивная нагрузка совсем не заметна.
На сложных задачах — заметно ниже, и не вызывает ощущения «о боже завтра опять разбираться с этой задачей которую не понятно как делать».

Смотришь:

• Куда движется агент? В правильном направлении?

• Не застрял ли в цикле фиксов?

• Не нарушает ли архитектурные ограничения из спеки?

• Не делает ли лишнего?

Если агент пошёл не туда — анализ и корректировка инструкций. Не «стой, я сам сделаю». А «вот здесь ты неправильно понял ограничение. Вот тут не хватает контекста. Вот тут нужен другой подход». Корректирую инструкцию, агент продолжает.

Вечер: просто заканчиваешь работу. запуск рутины парой слов:
«Сделай рутину»
это может быть логирование в backlog и в системы контроля.

Агент уже проверил всё сам через feedback loop. Разработчик проверяет только judgment‑уровень: правильное ли решение в принципе.

Метрики: что изменилось

Скорость анализа и подготовки

Погружение в новый модуль UE5: 1–2 недели → 2–4 часа |
Анализ кодовой базы для задачи: 2–3 дня(недели) → 1–2 часа(AI сам погружается и объясняет разработчику)
Написание спеки: 1 день(дни) → 30 минут
Поиск нужного кода в базе: Минуты‑часы → 50ms по индексу

Это не +20%. Это 100x на этапе анализа и подготовки.

Скорость разработки

Написание фичи средней сложности: 1–2 недели → 1–2 дня(с тестирование и проверкой гипотез)
Дебаг: Дни → Минуты‑часы (агент сам)
Компиляция + фикс ошибок: Часы(дни) → Минуты(агент сам)
Конвертация blueprints в C++: Дни (вручную) → Минуты (нативный конвертер)
Создание нового плагина: Часы → Минуты (агент по шаблону)

Роль человека

Написание кода руками: 80% времени → 0%
Дебаг руками: 10% времени → 0%
Постановка задач: 5% времени → 1% времени
Верификация и контроль: 5% времени → 99% времени

Касательно верификации — это не та верификация, где человек проверяет каждую строчку кода, написанного AI. Верификация на более высоком уровне — архитектурном. В связи со скоростью работы AI, 99% времени — это проверка совершенно другого объема задач и сложности(сложность которая доступна только разработчикам уровня Senior Principal UE5 Developer 10+ лет опыта).

У нас человек больше не пишет код. Человек ставит задачи и верифицирует результат. Это не «менеджер». Это архитектор намерений.

Процент вмешательства

зависит исключительно от сложности задач:

• простые задачи агент закрывает полностью без вмешательства человека.требуются минимальные корректировки. все также с AI.

• средние задачи требуют корректировки инструкций в процессе (агент пошёл не туда)

• сложные задачи требует ручного вмешательства (на подумать над архитектурным решением, которое агент не может принять и корректировкой спецификации)

98% времени — наблюдение. Не активная работа. Наблюдение. И нам это очень нравится.

Грабли, которые обошли

Грабли 1: «Дай агенту задачу и он сделает»

Первая попытка: дали агенту задачу «напиши модуль X для UE5». Без спеки. Без контекста. Без ограничений.

Результат: агент написал код, который компилируется, но не работает в контексте UE5. Потому что не знал про систему акторов, про жизненный цикл компонентов, про особенности рендер‑пайплайна.

Решение: Спека с архитектурным контекстом. Не «напиши модуль», а «напиши модуль X, который интегрируется с подсистемой Y через интерфейс Z, с учётом ограничений W».

Грабли 2: «Блюпринты нельзя автоматизировать»

Блюпринты — визуальное программирование. Казалось бы, их нельзя автоматизировать. Но UE5 позволяет вызывать почти всё в редакторе программно. Проблема была не в отсутствии API, а в сложности цепочек действий.

Решение: MCP tools server + SKILL.md, которые оркестрируют цепочки создания графов нод. И нативный конвертер Blueprint to C++ для тех случаев, когда нужно конвертировать блюпринты в код.

Грабли 3: «Кодовая база слишком большая для агента»

Миллионы строк. Агент не может загрузить всё в контекст.

Решение: Индексация. Поиск по индексу за 50ms. Агент не грузит всю базу. Он ищет конкретный код через скилл поиска и получает только релевантный кусок, ripgrep.

Грабли 4: «Агент теряет контекст на длинных задачах»

Compaction. Окно переполняется. Агент забывает, что делал.

Решение: memory.md + decisions.md. Три строчки промпта. Агент сам скидывает контекст перед compact и подгружает после. скилы и sh‑scripts — предварительная фильтрация перед тем как это попадет в контекст, особенно компиляция, разбор логов, дебаг, отжирающий токены.

Грабли 5: «Агент фиксирует не те ошибки»

Агент дебажит, но фиксирует симптомы, а не причину. Тратит итерации на поверхностные фиксы.

Решение: В инструкцию для дебага добавлено: «Сначала определи корневую причину. Не фиксить симптомы. Если не можешь определить причину за 3 итерации — остановись и запроси помощь человека».

Skill for AI, который уже содержит инструкции как исправлять типовые ошибки в коде и типовые ошибки при компиляции.

Грабли 6: «Агент делает лишнее»

Агент получил задачу «добавь функцию X». Добавил функцию X. И заодно отрефакторил модуль Y. И переписал тесты для Z. И обновил документацию.

Решение: В спеке явный раздел «Что НЕ делать». И в инструкции агента: «Делай только то, что в спеке. Не рефактори. Не улучшай. Не оптимизируй. Только задача из спеки».

Грабли 7: «AI‑конвертация блюпринтов нестабильна»

Первая попытка конвертировать блюпринты в C++ через AI давала нестабильные результаты: один и тот же блюпринт конвертировался по‑разному, генерируемый код не всегда компилировался.

Решение: Написан нативный программный конвертер. Детерминированный. Один и тот же blueprint всегда конвертируется в один и тот же C++ код. Никаких галлюцинаций. Конвертер в процессе улучшения: добавляются новые типы нод, улучшается обработка edge cases.

Инструменты

Агент: Выжимаем максимум из OpenCode, написание кода, дебаг, управление циклом.
Скиллы+MCP tools server: Управление UE5: компиляция, запуск, PIE, акторы, блюпринты.
Blueprint to C++: Нативный программный конвертер, детерминированная конвертация блюпринтов в C++.
Поиск: grep + индексация + shell | Поиск по кодовой базе UE5 за 50ms
Память: memory.md + decisions.md + agents.md, сохранение контекста при compaction.
Верификация: PIE + blueprinted functions + логи + краш‑дампы, автоматическая проверка результата.
Спека: Диалог с ИИ, 20–30 минут, контракт между человеком и агентом.
Логирование: Автоматический сбор сессий, Анализ паттернов, оптимизация промптов.

Пишем статью. Возможно, game studios и команды разработчиков, Product delivery managers, Team leads, возможно CEO обратят внимание

Этот кейс предлагался и продолжает предлагаться периодически game studios, UE5 projects. Реакция: даже не соизволили обратить внимание. Мы же No name. Вернее, имя то есть, но оно пока что не на слуху и не в широком инфополе.

Почему?! Предположим, что корпоративные фильтры не пропускают такую возможность.

Game studios мыслят в парадигме:

• «У нас есть разработчики, они пишут код»

• «У нас есть художники, они делают контент»

• «У нас есть QA, они тестируют»

• «Зачем нам автоматизация, если у нас есть люди?»

Возможно не видят, что:

• Разработчики тратят 80% времени на рутину, которую можно автоматизировать

• Художники тратят часы на расстановку мешей, которую можно автоматизировать

• QA тратит дни на ручное тестирование, которое можно автоматизировать

• Конвертация блюпринтов в C++ делается вручную, хотя есть нативный конвертер

Возможно не видят, что scope автоматизации уже запредельный. Что можно автоматизировать не «написание кода», а весь цикл разработки: от кода до компиляции, запуска, тестирования, дебага, рефакторинга, конвертации блюпринтов, создания плагинов.

Корпоративные фильтры — это не «мы не хотим». Это «мы не понимаем, что это возможно». И пока они не поймут, они будут продолжать делать руками то, что можно автоматизировать.

Что это значит для индустрии

Этот кейс разрушает несколько мифов:

Миф 1: «Сложные проекты нельзя автоматизировать»

UE5 — один из самых сложных проектов для автоматизации. Миллионы строк C++, редактор с ручным управлением, сложная архитектура, блюпринты. И тем не менее — полная автоматизация цикла разработки.

Если UE5 можно автоматизировать — можно автоматизировать что угодно. Вопрос не в сложности проекта. Вопрос в правильной архитектуре агентной среды.

Миф 2: «ИИ может только писать код»

ИИ не просто пишет код. ИИ управляет полным циклом: компилирует, запускает, тестирует, дебажит, перезапускает, конвертирует блюпринты, создаёт плагины, анализирует краши. Это не автокомплит. Это исполнительный слой.

Миф 3: «Блюпринты нельзя автоматизировать»

Можно. Python в UE5 позволяет вызывать почти всё в редакторе программно. Проблема не в отсутствии API, а в сложности цепочек. Скиллы оркестрируют цепочки. Нативный конвертер конвертирует блюпринты в C++ детерминированно.

Миф 4: «Нужно читать каждую строку кода»

Не нужно. Агент сам проверяет через feedback loop. Человек проверяет только judgment‑уровень: правильное ли решение в принципе. Это 5–15 минут на задачу, а не часы.

Миф 5: «Автоматизация — это для простых задач»

Наоборот. Чем сложнее задача, тем больше рутины в ней. Тем больше выигрыш от автоматизации. Простые задачи и так делаются быстро. Сложные задачи — где автоматизация даёт 100x.

Вывод

Проект поверх UE5 с огромной кодовой базой на C++. Редактор с ручным управлением. Миллионы строк кода. Блюпринты. И тем не менее:

• ИИ пишет весь код на C++ сам

• ИИ дебажит сам (парсит логи, краши)

• ИИ компилирует, билдит, архивирует сам

• ИИ перезапускает среду выполнения сам

• ИИ тестирует сам (PIE, blueprinted functions)

• Нативный конвертер Blueprint to C++ (детерминированный, не AI)

• ИИ создаёт плагины сам

• ИИ анализирует краши сам

• Человек ставит задачи по спеке и контролирует

• 98% времени — наблюдение одним глазом

Scope автоматизации — запредельный для любой game studio. Написание кода, поиск модулей, анализ кода в движке, рефакторинг, debug, compile, build, archive, new plugin, написание блюпринтов, конвертация блюпринтов в C++, запуск blueprinted functions, анализ логов, анализ крашей, artist генерация контента.

Это не будущее. Это настоящее. Август 2026. Работает. Каждый день.

Это не магия. Это инженерный подход к построению агентной среды. И он воспроизводим. Не только для UE5. Для любого проекта, где есть рутина, которую можно автоматизировать, и judgment, который остаётся человеку.

А game studios, которые не обращают внимания, потому что «корпоративные фильтры не пропускают» — они будут продолжать делать руками то, что можно автоматизировать. И через год будут удивляться, почему конкуренты, которые автоматизировали, делают в 10 раз больше контента за тот же бюджет.

Это их выбор. Но это не значит, что автоматизация невозможна. Это значит, что они не готовы. А тот, кто готов — уже делает.

Практический кейс: UE5 + C++ + полная автоматизация. Reverse engineering, миграция Editor UI и 350B параметров на бесплатном тарифе

Уровень задач: reverse engineering архитектуры UE5

Забудьте про «написать CRUD‑эндпоинт». Задачи на этом проекте — это reverse engineering кодовой базы UE5, чтобы понять:

• От какого класса наследоваться

• Какие модули зависят от каких

• Что можно вынести из Editor‑only в Runtime

• Какие зависимости сломают компиляцию в Shipping build

• Как перестроить архитектуру виджетов, чтобы они работали без Editor модулей

Это задачи, которые требуют высочайшего уровня знания архитектуры UE5: какие модули за что отвечают, как связаны Editor и Runtime, какие подсистемы зависят от Development модулей. И всё это делает ИИ. Человек только контролирует.

Последняя крупная задача: миграция Content Browser

(еще не завершено, но код перенесен, и компилируется в shipping build)
Что такое Content Browser

Content Browser в UE5 — это основной интерфейс редактора для управления ассетами. Это не один виджет. Это 10+ модулей зависимостей Editor и Development модулей:

• ContentBrowser

• ContentBrowserData

• ContentBrowserAssetData

• AssetTools

• AssetRegistry

• SourceControl

• EditorStyle

• Slate / SlateCore

• UnrealEd

• И другие

Ни один из этих модулей не работает в Shipping build. Более того, даже компиляция кода упадёт, если попытаться использовать их вне Editor context.

Масштаб задачи

• 100+.cpp файлов основного Content Browser

• 100+.h файлов заголовков

• 50+.cpp файлов смежных модулей, которые нужно склонировать и форкнуть

Это не «переписать пару функций». Это полная миграция архитектурного модуля из Editor‑only контекста в Runtime контекст.

Цель

Создать свою рантайм систему: in‑shipping‑build runtime editor with runtime assets. То есть:

• Редактор работает в Shipping build (не только в Editor)

• Ассеты управляются в Runtime (не только в Editor)

• Content Browser функционирует без Editor модулей

• Всё компилируется и работает в Shipping

Как это делалось

ИИ проводил reverse engineering:

1. Анализировал структуру Content Browser: какие классы, какие зависимости

2. Определял, от какого класса наследоваться для Runtime версии

3. Выявлял Editor‑only зависимости, которые нужно заменить

4. Клонировал и форкал смежные модули

5. Переписывал код, убирая Editor‑only зависимости

6. Компилировал, фиксил ошибки

7. Тестировал в Shipping build

8. Повторял до успеха

Человек только контролировал:

• Ставил задачу по спеке

• Наблюдал за прогрессом

• Корректировал инструкции, если ИИ шёл не туда

• Верифицировал финальный результат

Время

30+ часов работы ИИ. Человек не писал код. Человек не дебажил. Человек не компилировал вручную. Человек наблюдал и корректировал.

Ещё одна задача: File Dialog widget

В UEditor есть виджет File Dialog — диалог открытия/сохранения файлов. Он тоже Editor‑only.
Что сделано:

• Создан клон File Dialog

• Создан UUserWidget, который полностью работает in Shipping

• Виджет не зависит от Editor модулей

• Компилируется и работает в Shipping build

Это та же категория задач: взять Editor‑only компонент и сделать его Runtime‑совместимым, сохранив функциональность.

Уровень сложности: почему это не «просто код»

Эти задачи требуют понимания:

1. Архитектура модулей UE5

UE5 имеет чёткое разделение на модули:

• Runtime модули: работают в Shipping

• Editor модули: работают только в Editor

• Development модули: работают в Development, но не в Shipping

Content Browser зависит от Editor и Development модулей. Чтобы сделать его Runtime‑совместимым, нужно:

• Понять, какие зависимости Editor‑only

• Найти Runtime‑альтернативы

• Переписать код без Editor‑only вызовов

• Сохранить функциональность

2. Система наследования классов

UE5 использует глубокую иерархию классов. Content Browser наследуется от Slate виджетов, которые зависят от Editor контекста. Нужно:

• Понять иерархию наследования

• Определить, от какого класса можно наследоваться в Runtime

• Переписать классы, чтобы они не зависели от Editor

• Сохранить поведение

3. Система сборки UE5

UE5 имеет сложную систему сборки:

• Build.cs файлы определяют зависимости модулей

• ModuleRules определяют, какие модули доступны в каком контексте

• Shipping build исключает Editor модули

Нужно:

• Понять систему сборки

• Изменить зависимости модулей

• Убедиться, что код компилируется в Shipping

• Не сломать другие модули

4. Slate UI система

Slate — это UI фреймворк UE5. Content Browser использует Slate виджеты. Нужно:

• Понять Slate архитектуру

• Переписать виджеты без Editor‑only зависимостей

• Сохранить визуальное поведение

• Обеспечить совместимость с Runtime

Это не то, что делает автокомплит. Это архитектурная работа уровня Principal Engineer, которая обычно занимает месяцы у команды из нескольких человек.

Инструменты: UECortex — MCP Tools Server для UE5

UECortex — это плагин для UE5, который является MCP (Model Context Protocol) Tools Server. Он предоставляет агенту инструменты для управления UE5.

Skills:

• Компиляция проекта

• Запуск Editor

• Анализ логов и крашей

• Audit

• И многое другое

Как написан

UECortex написан через ИИ. Не человеком. ИИ сгенерировал код плагина, человек верифицировал.

Ключевая особенность: self‑maintaining instructions

UECortex содержит инструкции, которые позволяют ИИ:

• Всегда быстро понять, как устроен плагин

• Как исправить тул, если он сломался

• Как добавить новый тул, если нужна новая функциональность

Это не просто код. Это self‑documenting система, где ИИ может сам себя обслуживать. Если тул ломается — ИИ читает инструкции, понимает проблему, фиксит. Если нужен новый тул — ИИ читает инструкции, понимает архитектуру, добавляет.

Это эволюционирующая система. Она не статична. Она растёт вместе с проектом. И ИИ сам её растит.

Модель: 350B параметров, 200K контекст, бесплатный тариф
Всё вышеописанное сделано на модели «big pickle»:

• 350B параметров

• 200K контекст

• Бесплатный тариф

Это не Claude Opus за $200/месяц. Это не GPT-5 за корпоративный бюджет. Это бесплатная модель, которая:

• Проводит reverse engineering кодовой базы UE5

• Мигрирует Content Browser из Editor в Runtime

• Клонирует и форкает 50+ модулей

• Пишет, компилирует, дебажит, тестирует

• Управляет всем циклом разработки

И это работает. 30+ часов на задачу уровня Principal Engineer. На бесплатном тарифе.

Это разрушает миф о том, что «нужны дорогие модели для серьёзной работы». Не нужны. Нужна правильная архитектура агентной среды: скиллы, feedback loop, индексация, memory.md, спека. Модель — это исполнитель. Архитектура — это то, что делает исполнителя эффективным.

Что это значит для индустрии

Эти кейсы разрушает несколько мифов:

Миф 1: «ИИ не может делать архитектурную работу»
Миграция Content Browser из Editor в Runtime — это архитектурная работа уровня Principal Engineer. ИИ сделал это за 30+ часов. Человек только контролировал.

Миф 2: «Нужны дорогие модели»
Всё сделано на бесплатном тарифе. 350B параметров, 200K контекст. Не нужен Claude Opus за $200/месяц. Нужна правильная архитектура агентной среды.

Миф 3: «UE5 слишком сложный для автоматизации»
UE5 — один из самых сложных движков. Миллионы строк кода, сложная архитектура модулей, Editor‑only зависимости. И тем не менее — полная автоматизация. Если UE5 можно автоматизировать — можно автоматизировать что угодно.

Миф 4: «ИИ не может делать reverse engineering»
ИИ проводит reverse engineering кодовой базы UE5: понимает иерархию классов, зависимости модулей, систему сборки. Это не «написать функцию по спеке». Это понять чужую архитектуру и перестроить её.

Миф 5: «Плагины должен писать человек»
UECortex — MCP Tools Server для UE5 — написан через ИИ. И содержит инструкции для self‑maintenance. ИИ сам написал плагин, сам его обслуживает, сам добавляет новые тулы.

Вывод

Те, кто говорит «ИИ не может делать серьёзную работу» — они просто не пробовали. Или пробовали без правильной архитектуры. И получили плохой результат. И сделали вывод, что «ИИ не работает».

Но ИИ работает. Просто нужна правильная архитектура. И тогда даже бесплатная модель на 350B параметров делает то, что раньше было невозможно.

Экономика проекта на UE5: от планов по найму senior‑команды к... от того, что ИИ материализует запредельные задачи

Как это планировалось год назад

Год назад мы не нанимали людей. Мы планировали нанять и писали технические задания. Под каждую сложную фичу — отдельное ТЗ, отдельный поиск senior‑специалиста, отдельный бюджет.

Типичный план выглядел так:

Runtime assets:

• ТЗ на 20 страниц

• Поиск senior asset programmer ($10k-15k/месяц)

• 2–3 месяца на прототип

• Бюджет: $30k-45k только на proof of concept

Runtime TTF/OTF fonts:

• ТЗ на 15 страниц с описанием парсинга, glyph rendering, font atlas generation

• Поиск senior typography/graphics engineer (редкая специализация, $12k-18k/месяц)

• 2–3 месяца на прототип

• Бюджет: $36k-54k

UI Editor Migration (Slate → UICore):

• ТЗ на 30 страниц с описанием архитектуры Editor модулей

• Поиск команды из 3–4 senior UE5 engineers

• 4–6 месяцев на миграцию

• Бюджет: $150k-300k

MIDI assets:

• ТЗ на 12 страниц

• Поиск senior audio/tools programmer

• 2 месяца на прототип

• Бюджет: $20k-30k

Runtime meshes:

• ТЗ на 18 страниц

• Поиск senior graphics programmer

• 2–3 месяца на прототип

• Бюджет: $24k-45k

Общий план:

• Бюджет на найм и прототипы: $300k-600k

• Время до proof of concept всех фич: 8–12 месяцев

• Риск: 30–50% прототипов не подтвердят концепт, деньги сгорят

Это была нормальная экономика для сложных UE5-проектов год назад. Никто не спрашивал это. Но и денег не давали, инвесторы думали. Все так делали.

Что произошло, когда мы настроилм ИИ для работы с UE5 

Мы не нанимал senior‑специалистов. Вместо этого мы потратили время на настройку агентной среды для работы с UE5:

• Скиллы для управления Editor, компиляцией, PIE, анализом логов

• UECortex (MCP Tools Server) с self‑maintaining инструкциями

• Индексацию кодовой базы UE5 (поиск за < 50ms)

• memory.md + decisions.md для сохранения контекста

• Нативный конвертер Blueprint to C++

• Feedback loop с компиляцией в Shipping build

Когда эта инфраструктура была готова, мы начали делать то, что раньше было невозможно: скармливать формализованные ТЗ, которые писали для senior‑специалистов, напрямую ИИ.

Момент...

И вот ты сидишь, скармливаешь ИИ ТЗ, которое год назад предназначалось для senior‑специалиста за $15k/месяц. ТЗ на миграцию Editor UI Slate widgets в shipping UICore module. 10+ Editor модулей, 100+ cpp файлов, Editor‑only зависимости, которые не работают в Shipping, компиляция падает.

И ты видишь, как ИИ:

1. Проводит reverse engineering архитектуры Content Browser

2. Пишет план миграции за 10–15 минут с четкой картиной, где до этого вообще было не понятно как это делать и какой будет объем работ

3. Определяет, от какого класса наследоваться для Runtime версии

4. Клонирует и форкает 50+ смежных модулей

5. Переписывает код, убирая Editor‑only зависимости

6. Компилирует, фиксит ошибки, компилирует снова

7. Запускает в Shipping build

8. И через 30 часов оно как минимум все компилируется

(на момент написания статьи, задача именно в этом состоянии, ждет проверки, переключились на другие задачи)
Ты смотришь на экран и восторгаешься(но слова которыми мы это описываем совершенно другие). Потому что это запредельный уровень сложности задач, который материализуется в рабочий прототип Proof of Concept.

«похоже на работающее». «компилируется, и скоро будет работать как надо». Это практически полностью рабочий PoC фичи, которая год назад требовала команду senior‑специалистов и бюджета.

И это не одна задача. Это все задачи из плана найма:

• Runtime assets — ИИ изучил архитектуру Asset Registry, Streaming Manager, построил runtime систему

• MIDI assets — ИИ создал кастомный UAsset type, написал парсер, интегрировал с audio subsystem

• Runtime meshes — ИИ построил полноценную систему dynamic mesh creation с LOD и collision

• Slate → UICore migration — ИИ мигрировал Content Browser за 30+ часов

• Runtime TTF/OTF fonts — ИИ построил свою систему font rendering без Editor context

Всё это материализуется в рабочие прототипы. Один за другим. Без найма. Без команды. Без бюджета $300k-600k.

А дальше — допиливание с нюансами

После того как PoC работает, начинается допиливание с нюансами:

• Оптимизация производительности

• Обработка edge cases

• Интеграция с другими системами

• UI/UX улучшения

• Документация

• Тестирование в реальных сценариях

Это тоже делает ИИ. Но теперь это не «невозможная задача уровня Principal Engineer». Это рутинная доработка рабочего прототипа. ИИ справляется с этим ещё быстрее, потому что контекст уже есть, архитектура уже работает.

Это... как быстро и невероятно «awesome»
Риск минимальный (итерации дешёвые)
Это не инкрементальное улучшение. Это смена парадигмы. Проекты, которые год назад были невозможны из‑за бюджета и сложности найма, теперь могут реализовываться одним инженером с ИИ.
Да, именно так. Большая часть работы по автоматизации проведена всего одним инженером.

Что это значит на практике

Для стартапов:

Проекты, которые требовали seed‑раунда $1M+ только на прототипирование, теперь делаются на pre‑seed или bootstrapping. Один сильный инженер + ИИ закрывают scope команды из 5–7 senior.

Для indie‑разработчиков:

Сложные UE5-проекты с runtime editor, runtime assets, кастомным UI — теперь доступны. Не нужна студия с бюджетом. Нужен один инженер, который умеет ставить задачи ИИ.

Для крупных студий:

Те, кто продолжает нанимать команды senior под каждую фичу, проигрывают. Их экономика устарела. Они тратят $500k на то, что стартап с одним инженером делает за $50k.

Почему это быстро

1. ИИ не устаёт и не выгорает
   Senior‑специалист работает 6–8 часов в день в тандеме с ИИ а задач выполняет на 100 часов+.

2. ИИ не переключается между задачами
   Senior‑специалист тратит время на контекстные переключения: созвоны, ревью, планирование, общение. ИИ фокусируется на одной задаче до завершения.

3. ИИ масштабируется
   Один senior‑специалист делает одну задачу. ИИ может работать над несколькими задачами параллельно (через несколько агентов). Ты ставишь 3 задачи — 3 агента работают параллельно.

Результат: То, что занимало месяцы у команды senior, теперь занимает дни у одного инженера с ИИ.(Мы пока что не дошли до уровня точности, где один разработчик может контролировать выполнение работы нескольких агентов, задачи пока что слишком сложные, и текущий AI‑harness не вытягивает, но это пока что)

Почему это невероятно круто
Потому что это демократизация сложной разработки. Раньше сложные UE5-проекты были доступны только крупным студиям с большими бюджетами. Теперь — любому сильному инженеру, который умеет ставить задачи AI.

Это не «AI заменяет людей». Это AI усиливает одного сильного инженера до уровня команды. Инженер не пишет код руками. Инженер:

• Ставит задачи по спекам

• Контролирует архитектурные решения

• Верифицирует результат

• Корректирует инструкции, когда AI идёт не туда

AI — это универсальный исполнитель, который заменяет команду узких специалистов. Инженер — это постановщик и верификатор, который обеспечивает качество.

Честный взгляд: ИИ не автономен, но когнитивная нагрузка падает в сотни раз

Важное уточнение, которое часто пропускают

Когда мы рассказываем про проект на UE5, где ИИ мигрирует Content Browser из Editor в Runtime за 30+ часов, проводит reverse engineering архитектуры, клонирует 50+ модулей — у некоторых возникает образ «нажал кнопку, ушёл пить кофе, вернулся — всё готово».

Это не так. И это важно проговорить честно, без хайпа.

Человек нужен. Всё время. Присутствует. Контролирует ход выполнения задачи. Потому что задачи — запредельно сложные. ИИ не автономен в полном смысле слова.

Но вот что критически важно: когнитивная нагрузка на человека в сотни раз ниже, чем если бы он делал это без ИИ.

Что значит «контроль» на практике

Это не «сижу и смотрю, как ИИ печатает код». Это не «каждую минуту проверяю результат». Это наблюдение с возможностью вмешательства.
Конкретно на проекте UE5:
Ключевое: человек не пишет код руками. Не дебажит руками. Не компилирует руками. Не анализирует логи руками. Человек управляет направлением и принимает решения.

Почему когнитивная нагрузка падает в сотни раз

Раньше (без ИИ):
Чтобы мигрировать Content Browser из Editor в Runtime, тебе нужно:

1. Погрузиться в архитектуру UE5 (недели):
 — Прочитать исходники 10+ Editor модулей
 — Понять систему зависимостей
 — Разобраться, какие классы от чего наследуются
 — Найти Runtime‑альтернативы для Editor‑only функций
2. Планировать миграцию (дни):
 — Определить порядок действий
 — Выявить риски
 — Составить план отката
3. Писать код (недели):
 — Клонировать модули
 — Переписывать зависимости
 — Убирать Editor‑only вызовы
 — Компилировать, фиксить, компилировать снова
4. Тестировать (дни):
 — Запускать в Shipping build
 — Искать краши
 — Дебажить
 — Фиксить и повторять

Когнитивная нагрузка: Ты держишь в голове всё. Архитектуру. Зависимости. Код. Ошибки. Контекст. Ты — единственный источник истины. Твой мозг работает на пределе 8 часов в день. Через неделю — выгорание.
Итого: 2–3 месяца полноценной работы senior‑специалиста с максимальной когнитивной нагрузкой.

Сейчас (с ИИ):

Ты ставишь задачу по спеке. ИИ делает reverse engineering, пишет код, компилирует, тестирует, дебажит. Ты наблюдаешь.

Что ты держишь в голове:

• Общую цель задачи

• Критерии успеха

• Архитектурные ограничения

• Текущий прогресс (на высоком уровне)

Что ты НЕ держишь в голове:

• Конкретный код (ИИ пишет)

• Ошибки компиляции (ИИ фиксит)

• Результаты тестов (ИИ проверяет)

• Логи и краши (ИИ анализирует)

• Детали реализации (ИИ решает)

Когнитивная нагрузка: Ты держишь в голове только стратегический уровень. Тактический уровень — на ИИ. Твой мозг работает без перенапряжения. Ты можешь параллельно думать о других задачах. Ты не выгораешь.

Итого: 30+ часов работы ИИ + несколько часов контроля человеком. Когнитивная нагрузка — в сотни раз ниже.

Почему это не «полная автономия»

ИИ не автономен, потому что:

1. ИИ не принимает стратегические решения
   Когда есть два архитектурных пути, и оба технически возможны — ИИ не знает, какой выбрать. Это решение человека. Человек понимает бизнес‑контекст, долгосрочные последствия, ограничения.

2. ИИ иногда идёт не туда
   ИИ может неправильно понять задачу. Может начать делать лишнее. Может застрять на проблеме. Человек видит это и корректирует курс.

3. ИИ не знает неявных знаний
   ИИ не знает, что «три года назад мы пробовали этот подход, и он не сработал из‑за X». Человек знает. Человек добавляет этот контекст.

4. ИИ не несёт ответственности
   Если результат неправильный — ответственность на человеке. Человек верифицирует. Человек принимает решение «это готово для продакшена».

Поэтому человек нужен. Но его роль изменилась качественно.

Как изменилась роль человека

Было: Исполнитель

• Пишет код руками

• Дебажит руками

• Компилирует руками

• Тестирует руками

• Держит в голове всё: архитектуру, код, ошибки, контекст

• Работает 8 часов в день с максимальной концентрацией

• Выгорает через несколько недель интенсивной работы

Стало: Постановщик и верификатор

• Ставит задачи по спекам

• Наблюдает за прогрессом

• Корректирует курс при необходимости

• Принимает архитектурные решения

• Верифицирует финальный результат

• Держит в голове только стратегический уровень

• Работает с фоновой нагрузкой, может параллельно думать о других задачах

• Не выгорает

Ключевое отличие: человек больше не исполнитель. Человек — архитектор намерений и верификатор результатов.

Почему это всё равно революция

Даже с учётом того, что человек нужен для контроля, это революция, потому что:

1. Масштабирование
   Раньше: один senior‑специалист = одна сложная задача.
   Сейчас: один человек с ИИ = несколько сложных задач параллельно (потому что когнитивная нагрузка низкая).

2. Доступность
   Раньше: сложные задачи требовали дорогих senior‑специалистов.
   Сейчас: сложные задачи доступны любому сильному инженеру, который умеет ставить задачи ИИ.

3. Скорость
   Раньше: 2–3 месяца на сложную задачу.
   Сейчас: дни‑недели на сложную задачу.

4. Качество жизни
   Раньше: выгорание от максимальной концентрации.
   Сейчас: фоновая нагрузка, возможность думать о других вещах, отсутствие выгорания.

Честное дополнение: как изменилось отношение к работе

То, о чём не говорят в технических статьях. Последние три месяца, после того как была настроена полноценная агентная среда для UE5, я впервые за годы по‑настоящему почувствовал разницу. И это не про метрики. Не про скорость. Не про экономию бюджета.

Это про качество жизни.

Как это было раньше (полуручной режим с ИИ)
Ещё полгода назад, даже с ИИ, процесс выглядел так:

Утро:

Открываю задачу. Формулирую промпт. ИИ генерит код. Копипаст в IDE.

Компиляция:

Запускаю руками. Жду. Ошибки. Читаю. Пытаюсь понять, что ИИ имел в виду. Возвращаюсь к ИИ: делаю копипаст ошибки «Вот здесь ошибка, исправь». ИИ генерит новый код. Копипаст снова в IDE.

Дебаг:

Компилируется. Запускаю. Краш. Читаю логи. Пытаюсь понять, где проблема. Снова к ИИ копипаст из IDE: “Вот краш, вот логи, что делать?” ИИ предлагает фикс. Копипаст. Компилирую. Снова краш, но другой. Повторяю.

Вникание в код:

ИИ написал 200 строк. Мне нужно понять, что он сделал. Читаю. Пытаюсь вникнуть в логику. Нахожу проблему. Объясняю ИИ. ИИ переписывает. Снова читаю. Снова вникаю.

К концу дня:

Хорошо если сделал одну фичу. Устал. Выгорел. Ощущение: «В п...у этот кодинг. Ещё одна бесконечная проблемная задача».

И это было нормально(другие до сих пор так работают). Так работали все. Даже с ИИ. Потому что ИИ был помощником, а не исполнителем. Ты всё равно делал работу руками: копипаст, компиляция, дебаг, чтение кода.

Как это сейчас (полная агентная среда) — и я даже близко не буду связываться с ручным кодингом.

Утро:

Запускаю агента, открываю одну из сессий, где есть незавершенная задача.

День:

Агент сам пишет код. Сам компилирует. Сам фиксит ошибки компиляции. Сам запускает среду. Сам тестирует. Сам дебажит краши. Сам итерирует до успеха.

Я наблюдаю одним глазом. Пью кофе. Думаю о других задачах. Иногда корректирую курс, если агент идёт не туда. Думаю как это все сделать еще быстрее. Да, у меня есть время на это.

К концу дня:

Сделал кучу фиксов, подправил AI‑harness, нашел ошибки, что‑то успел исправить. Устал(за 8 часов все устают). Есть ощущение: «Да, получилось. Завтра сделаю ещё».

Что изменилось качественно

• Когнитивная нагрузка упала в сотни раз

• Исчезло выгорание от рутины

Сейчас появилась новая рутина. Но это не на долго.

Появилось ощущение «получится»

Раньше каждая задача была борьбой. Ты не знал, сколько времени займёт. Не знал, сколько итераций потребуется. Не знал, застрянешь ли на каком‑то баге на три дня.

Сейчас я знаю, что задача закроется. Может быть, за час. Может быть, за день. Но закроется. Потому что агент не устаёт, не выгорает, не отвлекается. Он итерирует до успеха.

Это меняет отношение к работе. Ты приходишь не с мыслью «опять бесконечная проблемная задача», а с мыслью «ок, поставлю задачу и буду наблюдать».

Исчезло ощущение «в п...у этот кодинг»
Это, наверное, самое важное.
Раньше к концу дня было ощущение: «Я устал. Я выгорел. Я ненавижу этот код. Завтра снова то же самое».
Сейчас к концу дня: «Да, получилось. Завтра сделаю ещё. Может быть, возьму задачу посложнее».

Это не про лень. Это про то, что рутина больше не убивает. Ты делаешь то, что интересно: ставишь задачи, принимаешь архитектурные решения, верифицируешь результат. А не копипастишь код и не дебажишь краши в 3000-й раз.

И это даже без сложных задач

Важно: это изменение произошло даже на обычных задачах. Не на миграции Content Browser. Не на reverse engineering архитектуры UE5. А на обычных фичах, которые я делал каждый день.

Если бы кто‑то сказал мне год назад: «Через год ты будешь работать над проектом без ощущения „в п...у этот кодинг“», я бы не поверил. и даже тогда я знал что это не нормально. Все так жили. Все уставали от рутины. Все выгорали.

Сейчас это однозначно не нормально. Сейчас нормальное состояние — это когда ты не устаёшь от рутины, потому что рутины нет. Её делает агент.

Почему это важно

Технические статьи говорят про:

• Скорость (+20%, 10x, 100x)

• Экономию бюджета (10–13x)

• Новые классы задач

Но они не говорят про качество жизни. Про то, что ты перестаёшь выгорать. Про то, что ты приходишь на работу с ощущением «получится», а не «опять борьба». Про то, что к концу дня нет ощущения «в п...у этот кодинг».

А это, возможно, самое важное. Потому что скорость и экономика — это хорошо. Но если ты выгораешь через три месяца — какая разница, насколько ты был быстр?

Сейчас, с полноценной агентной средой, ты не выгораешь. Потому что рутины почти нет. Потому что когнитивная нагрузка гораздо ниже. Потому что ты можешь состредоточиться на идее, а не на буковках кода и очередном баге в логах.

Честно и без хайпа:

Полноценная агентная среда — это не только про скорость и экономию. Это про качество жизни.
Ты приходишь не бороться, а созидать. Не выживать, а развиваться. Не выгорать, а расти.

Это, возможно, самое важное изменение — возвращение радости от работы.

Когда ИИ тупит, бесит, и почему это нормально: эволюция через сложные задачи. Честное признание

На сложных задачах ИИ тупит. Иногда бесит. Реально бесит.

Ты ставишь задачу, которая требует глубокого понимания архитектуры модуля UE5. ИИ начинает писать код. Компилирует. Ошибка. Фиксит. Снова ошибка. Фиксит. Снова ошибка. Но уже другая. И так по кругу. Пять итераций. Десять. Двадцать. ИИ ходит вокруг да около, не может найти корневую причину. Тратит токены. Тратит время. Тратит твоё терпение.

В этот момент хочется выключить компьютер и сказать: «Идет оно лесом»
А потом мысль: «Я сам все равно не сделаю быстрее».
Знаешь: это не ИИ сломался. Это задача сложная. И ИИ не хватает контекста, чтобы её решить.

Что делать, когда ИИ тупит

Когда ИИ застревает на сложной задаче, решение не в том, чтобы «дать ему больше времени». Решение в том, чтобы немного самому углубиться в задачу и понять чего не хватает и дать ИИ больше верного контекста.

Конкретно на проекте UE5, когда ИИ тупит на сложной задаче, я делаю следующее:

Шаг 1: Успокаиваюсь

Шаг 2: Переписываю архитектуру модуля с ИИ

Не «давай попробуем ещё раз». А садимся и обсуждаем архитектуру. Я объясняю ИИ:

• Как устроен мой модуль

• Какие у него зависимости

• Как он связан с UE5

• Какие ограничения

• Какие edge cases

Это не промпт на одну строку. Это диалог. 5–30 минут обсуждения архитектуры. ИИ задаёт вопросы. Я отвечаю. ИИ уточняет. Я дополняю. Очень часто не хватает, чтобы я как специалист, обратил внимание ии на некоторые нюансы.

Шаг 3: Запускаю аудит кода

Прошу ИИ провести аудит текущего кода модуля:

• Что работает

• Что не работает

• Где потенциальные проблемы

• Что не получается по плану с UE5

ИИ анализирует код. Находит проблемы. Предлагает фиксы.

Шаг 4: Заношу в контекст на постоянку

Всё, что мы обсудили — специфику модуля, его связи с UE5, ограничения, edge cases — заносится в контекст на постоянку. В собственный agents.md модуля или плагина, в memory.md, в скиллы.

Это не разовый контекст для одной сессии. Это постоянный контекст, который ИИ будет использовать каждый раз, когда работает с этим модулем.

Шаг 5: ИИ преодолевает барьер

После того как контекст загружен, ИИ преодолевает свой когнитивный барьер. Он больше не ходит вокруг да около. Он понимает архитектуру. Понимает ограничения. Понимает, что можно, а что нельзя.

И находит решение. За одну‑две итерации вместо двадцати.

Эволюция через сложные задачи

Вот что важно: именно в процессе сложных задач происходит эволюция ИИ. Не в процессе простых. Не в процессе рутины. А именно там, где ИИ тупит.

Потому что когда ИИ тупит, ты понимаешь: здесь не хватает контекста. И ты добавляешь контекст. Пишешь скилл. Обновляешь инструкции. Заносишь специфику модуля.

И в следующий раз, когда ИИ сталкивается с похожей задачей, он уже не тупит. Потому что контекст есть. Потому что скилл есть. Потому что специфика модуля задокументирована.

Это эволюция. Не ИИ сам по себе стал умнее. А система стала умнее. Потому что ты добавил контекст, который ИИ не знал.

Конкретный пример: продвинутый скилл дебага

На проекте UE5 есть повторяющиеся баги. Не уникальные. Повторяющиеся. Одни и те же паттерны ошибок, которые возникают снова и снова в разных контекстах.

Раньше ИИ дебажил их долго. Тратил 10–15 итераций на поиск корневой причины. Потому что не знал паттерн. Потому что каждый раз начинал с нуля.

Что улучшено:

Шаг 1: Проведён аудит.

Посмотрели, где ИИ тупил. Где долго дебажил. Где ходил вокруг да около. Выделил паттерны повторяющихся багов.

Шаг 2: Написан продвинутый скилл дебага.

Не просто «проанализируй логи». А скилл с мини‑скриптами парсинга логов:

• Скрипт парсит логи UE5

• Выделяет ключевые ошибки

• Классифицирует по типу

• Сопоставляет с известными паттернами

• Предлагает фикс на основе паттерна

Шаг 3: Оптимизировал процесс.

Теперь, когда ИИ сталкивается с повторяющимся багом, он не дебажит с нуля. Он:

1. Запускает скрипт парсинга логов

2. Получает классификацию ошибки

3. Сопоставляет с известным паттерном

4. Применяет известный фикс

5. Проверяет результат

Вместо 10–15 итераций — 2–3 итерации. Вместо 5 минут — 30 секунд.

Психологическое ощущение улучшения
Вот что интересно: это улучшение ощущается психологически. Даже бессознательно.

Раньше: ИИ тратит 20 секунд на очередное действие. Ты сидишь. Ждёшь. Втыкаешь в монитор. Думаешь: «Ну давай уже. Ну что ты там копаешься?»

Сейчас: ИИ тратит 6 секунд на очередное действие. Ты не успеваешь отвлечься. ИИ уже предложил код на ревью. Ты не втыкаешь в монитор между моментами, когда ИИ думает. Потому что этих моментов почти нет.

Это реально ощущается. Не как метрика. Не как «+20% к скорости». А как качественное изменение: ИИ стал работать лучше. Стабильнее. Быстрее. Предсказуемее.

И ты меньше выгораешь. Потому что быстрее получаешь ответы. Потому что не ждёшь. Потому что не втыкаешь в монитор. Потому что ИИ не тупит на каждом шагу.

Да, одна из проблем — это ощущение что большую часть времени, тупо втыкаешь в монитор. Но пока что идет процесс улучшения AI‑harness. И надею скоро и в монитор втыкать не надо будет.

Стек больше не важен

И вот что самое важное: нам сейчас всё равно, на каком стеке писать.

Я лично пишу на:

• JavaScript

• Python

• Shell

• C++

• Lua

И мне всё равно. Потому что ИИ знает все эти стеки. Потому что ИИ может писать на любом из них. Потому что моя роль — не «знать синтаксис C++» или «знать API Python». Моя роль — ставить задачи и верифицировать результат.

Раньше, чтобы писать на UE5, ты должен был знать C++ глубоко. Знать STL. Знать шаблоны. Знать макросы UE5. Знать систему сборки. Это были годы изучения.
(Сейчас тоже знать архитектуру нужно, но задача сводится к вспоминанию, а не к воспроизведению всей документации макросов UE5)

Сейчас ИИ знает C++ лучше, чем большинство разработчиков. ИИ знает STL. Знает шаблоны. Знает макросы. Знает систему сборки. Моя задача — не знать это самому. Моя задача — поставить задачу правильно и проверить результат.

Это не значит, что знания не нужны. Они нужны. Но они нужны на уровне архитектуры и верификации, а не на уровне синтаксиса.

Эра, когда программисты могут быть людьми

И вот что это значит на самом деле:
Раньше жизнь программиста — это бесконечное изучение:

• Новая версия фреймворка — изучай

• Новый плагин — изучай

• Новый модуль — изучай

• Новый стек — изучай

• Новая библиотека — изучай

• Новый инструмент — изучай

И так бесконечно. Ты не пишешь код. Ты изучаешь. Ты не решаешь задачи. Ты читаешь документацию. Ты не создаёшь. Ты догоняешь. И все это тысячи часов остаются в прошлом мертвыми бесполезными знаниями.

И к концу дня ощущение: «Я устал. Я выгорел. Я ничего не создал. Я просто читал документацию и пытался понять, как работает очередная либа».

Сейчас это заканчивается. Потому что ИИ знает фреймворки. ИИ знает плагины. ИИ знает модули. ИИ знает стеки. ИИ знает библиотеки. ИИ знает инструменты.

Моя задача — не изучать. Моя задача — ставить задачи и верифицировать результат. Не догонять. А созидать.

Это эра, когда программисты действительно могут почувствовать себя людьми. Не машинами для изучения документации. Не роботами для копипаста кода. А людьми, которые ставят задачи, принимают решения, создают продукты.

Возвращение человечности в профессию.
Если в вашей компании не так как описано выше, берите инициативу в свои руки.

Точка отсчёта: одна инструкция в agents.md

Как всё началось

Вся автоматизация на проекте UE5 началась с одного простого шага: я написал первую инструкцию в agents.md.

Три месяца назад. Всего три месяца назад.(уже почти 4 месяца назад)

Инструкция была примитивной:

Когда я говорю «открыть проект»,
ИИ открывает конкретный.uproject файл
по такому‑то пути.

Всё. Одна инструкция. Одна привязка: команда «открыть проект» → конкретный файл.

Почему это важно

Это кажется мелочью. Но это *фундамент**.

• ИИ перестал спрашивать: «Какой проект открыть?»

• ИИ перестал гадать: «Какой.uproject файл?»

• ИИ стал *понимать контекст проекта** с первой же команды

Это был первый шаг от «ИИ как чат‑бот, которому нужно всё объяснять каждый раз» к «ИИ как исполнитель, который знает контекст».

От одной инструкции до полной автоматизации

Три месяца назад:

• Одна инструкция в agents.md

• «Открыть проект» → ИИ открывает нужный.uproject

Сейчас:

• Полная агентная среда с десятками скиллов

• UECortex (MCP Tools Server) с self‑maintaining инструкциями

• Миграция Content Browser из Editor в Runtime

• Runtime assets, MIDI assets, runtime meshes, runtime TTF/OTF fonts

• Нативный конвертер Blueprint to C++

• Reverse engineering архитектуры UE5

• Один инженер вместо команды senior‑специалистов

Вывод

Всё началось с одной строчки в agents.md. Не с покупки дорогой подписки. Не с найма команды. Не с месяцев планирования. С одной инструкции: «Когда я говорю X, ты делаешь Y».
И это было три месяца назад. Сейчас это полная автоматизация запредельных задач на UE5.
Три месяца. От одной строчки до полной трансформации.

Финальный аккорд: 10 минут копипаста вместо трёх месяцев исследований

Что сейчас есть

Текущая агентная среда (harness) для UE5 пока написана под Linux. Но архитектура такова, что её можно переписать или дописать под Windows и macOS. Это не «начинать с нуля». Это адаптировать существующие скиллы и скрипты под другую ОС. Дело техники, а не исследований.

Что это значит для любого UE5 проекта

Всё, что есть сейчас — скиллы, UECortex, индексация, feedback loop, memory.md, нативный конвертер Blueprint to C++ — можно скопипастить за 10 минут в любой UE5 проект.

Не нужно:

• Три месяца исследований на задачах

• Reverse engineering архитектуры UE5 с нуля

• Метод проб и ошибок

• Грабли, которые уже обошли

• Написание скиллов с нуля

• Настройка индексации с нуля

Всё уже готово. На текущем уровне автоматизации. Проверено на реальных задачах запредельной сложности.

Почему это круто

Год назад, чтобы дойти до этого уровня, нужно было:

• Нанять команду senior‑специалистов ($300k-600k)

• Потратить 8–12 месяцев на прототипы

• Пройти через все грабли вручную

• Выгореть несколько раз

• Молиться, что концепт подтвердится

Сейчас:

• 10 минут копипаста

• Готовая агентная среда

• Все грабли уже обойдены

• Все скиллы написаны и проверены

• Можно практически сразу приступать к задачам

Три месяца исследований, которые я прошёл, сжимаются в часы для любого другого человека с UE5 проектом.

Вывод

Это и есть настоящая ценность того, что было сделано. Не просто «я автоматизировал свой проект». А создана инфраструктура, которую можно скопипастить в любой другой проект за 10 минут.

Это не «индивидуальное решение». Это тиражируемая система. Которая устраняет три месяца исследований для любого, кто хочет работать с UE5 на уровне практически полной автоматизации.

Это круто. И это только начало. Потому что harness можно переписать под Windows и macOS. И тогда это будет работать везде. Для любого UE5 проекта. За пару часов.

Это новая реальность разработки на UE5. И она уже здесь.