наш путь другой, взял как исходники, чтобы ии смог понять как правильно писать код. в версии 4.26+ последней самой была нативизация блупринтов в С++ потом ее выпилили эпики.
ии сам писал код нативизации блупринтов. но до этого написали mcp tool который сам может создавать блупринты.
ИИ сам создавал тестовые блупринты, запускал функцию bp to C++ и проверял получившиеся .h and .cpp .h - взяли стандартную генерацию, сделали обертку, которая есть в UE5
эпики собираются большую часть блупринтов выпиливать, поэтому к этому всему тоже есть вопросы, как и на что и где они будут заменять на свой пресловутый Verse, который ни разу не рантайм пока что. Может эпики сделают свой конвертер блупринтов в тот же Verse.
это пример автоматизации: каждая автоматизация как кубики для дальнейшей автоматизации.
Мета-посылы статьи «Практический кейс: UE5 C++ полная автоматизация»
1. «Сложные проекты — не помеха для автоматизации» UE5 chosen намеренно как антипилотный пример: миллионы строк C++, ручной GUI-редактор, неочевидные зависимости, Blueprints. Если это автоматизируется — автоматизируется всё. Аргумент: не сложность проекта определяет границы, а архитектура агентной среды.
2. «ИИ — не автокомплит, а исполнительный слой» Ключевое разделение: ИИ не просто генерит код. Он управляет полным циклом — компилирует, запускает, тестирует, дебажит, перезапускает. Человек остаётся в двух точках: постановка и верификация. Это смена парадигмы с «помощника» на «исполнителя».
3. «Архитектура важнее модели» 350B на бесплатном тарифе делает задачи уровня Principal Engineer. Не дорогая модель, а правильная инфраструктура (скиллы, feedback loop, индексация, memory.md, спеки) делает исполнителя эффективным. Это прямая атака на миф «нужен Claude Opus за $200/мес».
4. «Человек — архитектор намерений, а не исполнитель» Роль принципиально меняется: с «пишу код, дебажу, компилирую» на «ставлю задачи, контролирую направление, верифицирую». Верификация — архитектурного уровня, а не проверка строк. 98% времени — наблюдение.
5. «Экономика рушится» Старая модель: $300k-600k на команду senior, 8-12 месяцев до PoC. Новая: один инженер с ИИ, дни-недели, бесплатно. Стартап заменяет команду из 5-7 senior. Крупные студии, которые не автоматизируются, проигрывают в 10x по бюджету.
6. «Качество жизни > метрики скорости» Самый эмоциональный пласт статьи. Технические статьи говорят про 100x и экономию. Автор говорит про другое: исчезает выгорание, появляется ощущение «получится», уходит «в п...у этот кодинг». Рутина больше не убивает. Программист снова чувствует себя человеком, а не машиной для копипаста.
7. «ИИ тупит — это нормально, и это эволюция» Честное признание: на сложных задачах ИИ ходит вокруг да около по 20 итераций. Но это не баг — это точка роста. Каждый такой случай = новый контекст, новый скилл, новая инструкция. Система становится умнее. ИИ не эволюционирует сам — ты эволюционируешь систему через сложные задачи.
8. «Начать можно с одной строчки» Вся трансформация — от «одна инструкция в agents.md: открывай вот этот .uproject» до полной автоматизации за 3 месяца. Не нужна дорогая подписка, не нужна команда, не нужно месяцы планирования. Нужно начать и итерировать.
9. «Это тиражируемое» Финальный посыл: созданная инфраструктура — не индивидуальное решение, а система, которую можно скопипастить за 10 минут в любой UE5-проект. Три месяца исследований сжимаются в часы для других. Причём это только начало — harness расширяем на Windows/macOS.
Скрытая сверхзадача статьи: автор продаёт не технологию, а смену ментальной модели. С «ИИ — это полезный автокомплит» на «ИИ — это исполнительный слой, который делает одного инженера сильнее целой команды». И параллельно — призыв: если в вашей компании не так, берите инициативу сами.
если архитектура изначально построена правильно (послойная, с чёткими границами, инкапсуляцией и модульностью), то ИИ отлично с ней справляется.
Значит, проблема автора статьи не в том, что «все архитектуры плохи для ИИ», а в том, что он либо не умеет строить правильную послойную архитектуру, либо его проект был изначально «кашей», и он пытается вылечить её радикальным методом, который справедливо называется костылём.
Автор, судя по описанию, допустил ошибки:
Возможно, у него были циклические зависимости или «божественные» классы, которые тянули всё на себе.
Интерфейсы были размытыми или часто менялись.
Отсутствовала строгая иерархия, и модули знали друг о друге слишком много.
Когда он поручал ИИ рефакторинг, тот не мог удержать в голове все неявные связи, потому что их не было видно из кода (например, через глобальные переменные, синглтоны или косвенные вызовы).
В такой ситуации даже человеку трудно рефакторить без ошибок, а ИИ — тем более. Автор решил проблему не исправлением архитектуры (что было бы правильнее), а запретом на рефакторинг и плодя новых сущностей — это действительно выглядит как «я не умею строить нормальную архитектуру, поэтому буду дублировать».
какой размер кодо базы, когда начались проблемы, и какой размер средний одного файла кода?
Информация
В рейтинге
1 631-й
Зарегистрирован
Активность
Специализация
Архитектор программного обеспечения, AI native workflow integration into business
наш путь другой, взял как исходники, чтобы ии смог понять как правильно писать код.
в версии 4.26+ последней самой была нативизация блупринтов в С++
потом ее выпилили эпики.
ии сам писал код нативизации блупринтов.
но до этого написали mcp tool который сам может создавать блупринты.
ИИ сам создавал тестовые блупринты, запускал функцию bp to C++
и проверял получившиеся .h and .cpp
.h - взяли стандартную генерацию, сделали обертку, которая есть в UE5
эпики собираются большую часть блупринтов выпиливать, поэтому к этому всему тоже есть вопросы, как и на что и где они будут заменять на свой пресловутый Verse, который ни разу не рантайм пока что. Может эпики сделают свой конвертер блупринтов в тот же Verse.
это пример автоматизации: каждая автоматизация как кубики для дальнейшей автоматизации.
сделал выжимку, замысел автора:
Мета-посылы статьи «Практический кейс: UE5 C++ полная автоматизация»
1. «Сложные проекты — не помеха для автоматизации» UE5 chosen намеренно как антипилотный пример: миллионы строк C++, ручной GUI-редактор, неочевидные зависимости, Blueprints. Если это автоматизируется — автоматизируется всё. Аргумент: не сложность проекта определяет границы, а архитектура агентной среды.
2. «ИИ — не автокомплит, а исполнительный слой» Ключевое разделение: ИИ не просто генерит код. Он управляет полным циклом — компилирует, запускает, тестирует, дебажит, перезапускает. Человек остаётся в двух точках: постановка и верификация. Это смена парадигмы с «помощника» на «исполнителя».
3. «Архитектура важнее модели» 350B на бесплатном тарифе делает задачи уровня Principal Engineer. Не дорогая модель, а правильная инфраструктура (скиллы, feedback loop, индексация, memory.md, спеки) делает исполнителя эффективным. Это прямая атака на миф «нужен Claude Opus за $200/мес».
4. «Человек — архитектор намерений, а не исполнитель» Роль принципиально меняется: с «пишу код, дебажу, компилирую» на «ставлю задачи, контролирую направление, верифицирую». Верификация — архитектурного уровня, а не проверка строк. 98% времени — наблюдение.
5. «Экономика рушится» Старая модель: $300k-600k на команду senior, 8-12 месяцев до PoC. Новая: один инженер с ИИ, дни-недели, бесплатно. Стартап заменяет команду из 5-7 senior. Крупные студии, которые не автоматизируются, проигрывают в 10x по бюджету.
6. «Качество жизни > метрики скорости» Самый эмоциональный пласт статьи. Технические статьи говорят про 100x и экономию. Автор говорит про другое: исчезает выгорание, появляется ощущение «получится», уходит «в п...у этот кодинг». Рутина больше не убивает. Программист снова чувствует себя человеком, а не машиной для копипаста.
7. «ИИ тупит — это нормально, и это эволюция» Честное признание: на сложных задачах ИИ ходит вокруг да около по 20 итераций. Но это не баг — это точка роста. Каждый такой случай = новый контекст, новый скилл, новая инструкция. Система становится умнее. ИИ не эволюционирует сам — ты эволюционируешь систему через сложные задачи.
8. «Начать можно с одной строчки» Вся трансформация — от «одна инструкция в agents.md: открывай вот этот .uproject» до полной автоматизации за 3 месяца. Не нужна дорогая подписка, не нужна команда, не нужно месяцы планирования. Нужно начать и итерировать.
9. «Это тиражируемое» Финальный посыл: созданная инфраструктура — не индивидуальное решение, а система, которую можно скопипастить за 10 минут в любой UE5-проект. Три месяца исследований сжимаются в часы для других. Причём это только начало — harness расширяем на Windows/macOS.
Скрытая сверхзадача статьи: автор продаёт не технологию, а смену ментальной модели. С «ИИ — это полезный автокомплит» на «ИИ — это исполнительный слой, который делает одного инженера сильнее целой команды». И параллельно — призыв: если в вашей компании не так, берите инициативу сами.
если архитектура изначально построена правильно (послойная, с чёткими границами, инкапсуляцией и модульностью), то ИИ отлично с ней справляется.
Значит, проблема автора статьи не в том, что «все архитектуры плохи для ИИ», а в том, что он либо не умеет строить правильную послойную архитектуру, либо его проект был изначально «кашей», и он пытается вылечить её радикальным методом, который справедливо называется костылём.
Автор, судя по описанию, допустил ошибки:
Возможно, у него были циклические зависимости или «божественные» классы, которые тянули всё на себе.
Интерфейсы были размытыми или часто менялись.
Отсутствовала строгая иерархия, и модули знали друг о друге слишком много.
Когда он поручал ИИ рефакторинг, тот не мог удержать в голове все неявные связи, потому что их не было видно из кода (например, через глобальные переменные, синглтоны или косвенные вызовы).
В такой ситуации даже человеку трудно рефакторить без ошибок, а ИИ — тем более. Автор решил проблему не исправлением архитектуры (что было бы правильнее), а запретом на рефакторинг и плодя новых сущностей — это действительно выглядит как «я не умею строить нормальную архитектуру, поэтому буду дублировать».
какой размер кодо базы, когда начались проблемы, и какой размер средний одного файла кода?