AI-Driven Development в командах: код и процессы

Привет. 14 марта я выступал на конференции Game City Fest и не успел в выделенное для меня время рассказать всё, что хотел по теме своего выступления. Поэтому решил попробовать записать более полную, расширенную версию моего доклада и успеть рассказать всё, что хотел донести.

Меня зовут Антон Керп. Сейчас я являюсь техническим директором в компании Funds and Games. В коммерческой разработке я уже почти 10 лет. За это время был разработчиком, ледом. В какой-то степени продолжаю исполнять эти роли, занимался своими проектами, стартапами, преподаванием, менторством, проводил и продолжаю проводить консультации по вопросам, которые касаются моей профессиональной деятельности.

Последние полтора года пробую вести свой блог, пишу там про GameDev, про разработку, про всё, что касается моей профессии. Также иногда пишу про искусственный интеллект. Аудитория очень не любит посты такой направленности, если смотреть на статистику и комментарии. Однако это та тема, в которую я погружён последние несколько лет. Причём она очень динамична. Почти каждый день выходят какие-то новые обновления, новые технологии. И так как мы в компании считаем, что ИИ — это один из драйверов нашего роста, то мне просто необходимо быть в курсе всех современных веяний и тенденций для принятия более взвешенных решений, так как принятие решений — это моя основная обязанность.

В своём докладе я сосредоточусь именно на применении ИИ в разработке, так как это сейчас основная моя боль. Однажды я надеюсь полностью делегировать эту ответственность на своих разработчиков, но пока мне ещё приходится уделять этому время самостоятельно. Если менеджеров или управления не нужно долго убеждать в том, что нам стоит внедрить AI везде, куда оно внедряется, то в ситуации с линейными сотрудниками, будь то разработчики, тестировщики, художники и многие другие, мы здесь сталкиваемся до сих пор со стеной недоверия, скепсиса, инерции и иногда даже непринятия.

Если с таким подходом можно было смириться ещё год назад, то сегодня как будто бы уже нет. Нейросетевые технологии уже достигли тех мощностей, когда их игнорирование становится дороже, чем использование. И многие начинают это замечать. Это видно, в том числе, и по рынку труда, где всё больше работодателей предъявляет всё больше требований к навыкам владения ИИ-инструментами. Мы в компании также с двадцать четвёртого года уделяем внимание этим навыкам при найме, но сейчас думаю, что мы уже будем их рассматривать как обязательный критерий.

Нейросети уже реально можно рассматривать как своих младших сотрудников. Раньше это могло звучать как громкий кликбейт, но сегодня это уже реальность. По крайней мере, в разработке, написании кода точно могу судить об этом, в том числе, по себе, так как времена сейчас непростые, мы сильно ограничены в вопросах найма, и мне приходится принимать участие непосредственно в разработке всех наших проектов. Иногда таких проектов несколько, так как мы специализируемся на Мидкоре — это достаточно большие и сложные проекты, но времени заниматься разработкой, конечно же, у меня нету. Поэтому ещё с выхода первого Copilot я учился делегировать максимум разработческих обязанностей на LLM. И это привело к тому, что сейчас я практически не пишу код самостоятельно, потому что у меня наконец-то появилось больше сотрудников. Правда, не все из них живые, и в качестве зарплаты у них подписки.

При этом у этих сотрудников вполне себе человеческие проблемы и потребности. Они даже порой напоминают мне моих реальных коллег. Если рассматривать это в таком ключе, то какая вообще основная задача менеджера? Менеджер старается построить такую среду, в которой для сотрудника будут предоставлены чёткие, однозначные, понятные требования, будет предоставлен доступ ко всей необходимой информации для максимально состоятельной работы, предоставлены разнообразные чек-листы, по которым можно будет сверить полноту и корректность реализации. И будет выстроена система ограничений, в рамках которых у сотрудника просто не будет возможности поступить неправильно или сделать что-то не так. В работе с агентами ситуация точно такая же, полностью аналогичная. Единственное, что технологии, инструменты немножко другие.

Поэтому мне кажется, что для сотрудников, у которых есть какой-то опыт руководства, опыт коммуникации с другими своими коллегами, им будет сильно проще начинать разрабатывать с помощью искусственного интеллекта, потому что обычный сотрудник без такого опыта, как правило, ждёт от ИИ какого-то волшебного поведения, когда ты нажимаешь одну кнопку и получаешь клёвый результат. Конечно, такого результата ИИ не даёт. В то же время лид или руководитель постоянно ожидает, что же пойдёт не так в этот раз. Пытается все такие проблемы отследить и продумать сценарии, как в будущем их предотвратить. И именно такой формат работы с агентами позволит их использовать эффективно и правильно. Я думаю, мы однажды придём к такому инструменту, у которого будет такая возможность делать классно с первой попытки и с одной кнопки. Индустрия уже как будто бы начинает упираться в потолок и смещает свой фокус на ускорении, удешевлении, упрощении и всяческом снижении порога входа. Поэтому однажды это обязательно станет настолько дешёвым и простым, что этим начнут пользоваться все, и это станет стандартом и обыденностью. Но парадокс в том, что мы можем уже сегодня воспользоваться этим инструментом из будущего. Единственное, что обуздать его сейчас нам нужно самостоятельно, приложив некоторые усилия. И не все готовы эти усилия прилагать. Поэтому сейчас открыто небольшое окно возможностей, в рамках которого можно успеть сделать ИИ своим конкурентным преимуществом, набрать некоторого ускорения перед тем, как эта технология станет на вооружение у всех.

Здесь я заканчиваю своё лирическое вступление и далее расскажу про свои планы. Сначала мы рассмотрим теорию, необходимую для начала работы с агентами. Затем перейдём в игровой проект, попробуем решить несколько прикладных задач, в рамках которых я постараюсь рассказать про подходы и принципы, которые мы применяем внутри нашей компании и внутри наших команд. Это наша корпоративная база знаний по AI, точнее, небольшая выдержка из неё, которая касается разработки. Это QR-код, который ведёт на эту страницу. Также ссылку на документацию можно будет найти в описании к этому видео. Помимо содержания, здесь также будут ссылки и на нашу компанию, и на мои контакты, и на мой блог. В частности, несколько ссылок на темы, которые касаются этого видео. Возможно, какие-то тезисы из них я буду сегодня использовать, но точно не буду останавливаться на подробном их пояснении. Поэтому, если будут интересны мои мысли по высказанным каким-то темам, с ними можно будет ознакомиться в этих постах.

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

Далее необходимо разобраться с принципами работы этой LLM. Что важно о ней знать? Первое — это вероятностная языковая модель. Если сильно упрощать, то просто предсказывает наиболее вероятное следующее слово. То есть у неё нету как таковых возможностей думать или понимать в человеческом смысле. И так как здесь происходит именно что генерация следующего слова, то каждый ответ LLM будет уникальным, даже если вы будете подавать на вход один и тот же промт. Также каждый ответ LLM не гарантирует какой-то достоверности. LLM может галлюционировать, может врать, может вас обманывать. Поэтому никогда не нужно доверять ответам от ИИ и стараться их всегда верифицировать, проверять, чекать и всячески придавать сомнения.

В частности, именно поэтому LLM можно назвать усилителем. Причём даже в том плане, что если вы чего-то не знаете, то LLM — это незнание тоже только усилит. Поэтому крайне важно, работая с LLM в какой-то незнакомой для вас области, предварительно, хоть немного, но разобраться с ней самостоятельно, иначе вам будет очень сложно отличить вымысел от действительности и проверить качество работы вашей нейросети. В то же время, если вы работаете с LLM в какой-то знакомой для вас области в рамках ваших компетенций, это может стать действительно мощным усилителем, который позволит вам делать больше и быстрее, и вы сможете быстрее верифицировать и проверить выданный вам результат.

И ещё очень важно понимать, что эффективность работы с ИИ достигается только через практику. Это не навык, данный нам по умолчанию. Его нужно нарабатывать, его нужно вырабатывать. Здесь очень много вещей, которые полагаются на какую-то интуицию, на какую-то чуйку. И эту чуйку нужно тоже тренировать и воспитывать. И пока вы не набьёте какой-то определённый опыт, скорее всего, LLM будет вас только замедлять. Но при должном усердии, при должном упорстве это окупится.

То, как именно работает LLM, мы разбирать не будем. Вы сможете самостоятельно ознакомиться со всем содержимым всех документов. Единственное, возможно, заострю внимание на моменте с батчингом. Это возможность экономить на использовании LLM. По умолчанию батчинг включен для многих моделей, но сейчас стало популярным возможность, когда вы можете получить некоторое ускорение в скорости работы модели за счёт некоторого повышения стоимости. И многие провайдеры регулируют это как раз за счёт батчинга. Делают его либо меньше, либо отключают вовсе. Тем самым как раз у вас повышается и скорость, но при этом повышается и стоимость обработки.

Далее также важно уделить время промтингу, несмотря на то, что сейчас в соцсетях об этом не так часто уже говорят, хотя на заре появления GPT об этом писали практически везде, актуальность промтинга всё ещё не потеряна. Это всё ещё важный элемент для качественной работы ИИ. Возможно, он уже не так значим в каких-то простых и базовых задачах, но хороший промтинг — это основа качественных инструкций, качественных настроек и всей той документации, которую мы будем далее предоставлять агенту. Поэтому основными техниками для промтинга важно овладеть, важно про них знать. Это всё ещё очень важный базис для качественной эффективной работы. Здесь, возможно, приведены не все, но выше вы сможете найти ссылки на другие документы, где удастся обнаружить, возможно, то, что не вошло в этот документ.

Далее мы переходим к инструментам. Здесь, на этом этапе, важно выбрать, чем мы будем пользоваться. И инструменты разделяются на некоторые этапы или уровни по, скажем так, глубине их владения. Первый этап — это обычная работа с чатом, когда мы используем обычную веб-версию, оставляем там свои запросы, возможно, генерируем код. Этот код потом копируем к себе обратно в IDE. Это уже достаточно устаревший подход. Тем не менее, многие до сих пор продолжают именно им и пользоваться. Здесь бы я очень рекомендовал постараться посмотреть в сторону следующих этапов, которые могут сильно увеличить вашу производительность, скажем так.

Ну, если говорить именно про чаты, чатов большое количество сейчас есть на рынке разной степени доступности, как финансовой, так и территориальной. Лидеры рынка здесь, конечно, это Google, ChatGPT, Claude, то есть Anthropic, X, он же Grok, Microsoft и уже огромная россыпь разнообразных китайских моделей. На российском рынке у нас представлены GigaChat и YandexGPT. В разработке пока что они не сильно полезны, но это точно будет лучше, чем ничего. Несмотря на то, что по работе с кодом есть более эффективные и удобные инструменты, чат для разработчика всё ещё может быть полезен для работы, которая не касается непосредственно конкретного проекта или его файлов. Вы можете проводить какой-то research, поиск информации, работу с документацией, составление спецификаций, составление каких-то планов, проводить какие-нибудь верификации, ревью ваших идей, возможно, каких-то ваших сниппетов или вам, может, потребоваться подготовить какую-то, возможно, презентацию или какой-то визуальный или аудиальный контент. В общем, когда вам не нужно работать прямо с вашим проектом, вероятнее всего, вам будет удобнее перейти именно в веб-чат, потому что это и дешевле, и они предоставляют довольно много мультимедийных возможностей с удобным и понятным доступом. Поэтому какой-то из чатов лучше иметь в своём арсенале. Например, у нас в компании приобретён доступ к Gemini для всех сотрудников. И на мой взгляд, именно по работе с текстом, по работе с информацией, это сейчас лучшее, что предлагает рынок. Хотя, как ни странно, поисковые возможности Gemini, на мой взгляд, уступают другим аналогам. В плане поиска чего-то в интернете мне больше всех нравится Grok и Perplexity. И, как ни странно, Алиса тоже очень неплохо ищет по интернету.

И вот, когда мы определились с чатом, мы переходим дальше на следующий уровень. Нам нужно выбрать какой-то инструмент, с которым мы будем работать прямо в нашем проекте. И так как мы в основном разрабатываем на Unity, основной инструмент для разработки у нас — это Rider. И как будто бы понятным и очевидным решением для нас было бы использование какого-нибудь плагина, который бы позволял прямо внутри Rider работать с нейросетями. Таких плагинов очень много. Я оставил какие-то основные и актуальные. Возможности у них плюс-минус у всех одинаковые. Это либо, точнее, не либо, это и окошко с чатом, куда вы можете отправлять свои запросы вместо того, чтобы ходить в браузер. Также в этот чат сейчас интегрированы агентные возможности, которые позволяют вам работать непосредственно с файлами вашего проекта, с файловой системой и в целом автоматизированно производить какую-то работу над проектом. И также такие плагины предоставляют возможности автокомплита, дополнения вашего кода. У каких-то плагинов оно лучше, у каких-то плагинов оно хуже. Это в целом одна из первых фич, которые появились среди инструментов для разработчиков. И даже первая версия автокомплита уже сильно упрощала и ускоряла разработку. Они уже позволяли генерировать разнообразные логи, генерировать всякие подписки, отписки. И даже на базовом простом автокомплите была возможность генерировать уже юнит-тесты. Да, нужно было поработать руками чуть больше, чем сейчас, но даже уже тогда эти тесты можно было практически нашлёпать одним табом. И в целом, на мой взгляд, до сих пор сейчас основным достоинством, основной задачей таких плагинов для Rider — это автокомплит.

Здесь по своему опыту могу сказать, что самый прикольный автокомплит у Swift AI, он наиболее приближен к опыту в других IDE типа Cursor. Следующим, по возможностям бы я выделил, наверное, JetBrains AI. Они совсем недавно довели его до какого-то ума. В целом он всегда сильно отставал от своих конкурентов и как будто бы на самом деле вот в базе он всё ещё достаточно тупенький и инертный, но JetBrains добавили в свой автокомплит все современные возможности по типу автоматического перемещения курсора к месту предполагаемой следующей правки автокомплита по нескольким строкам сразу. И вот эти фишечки, они сгладили небольшое интеллектуальное отставание их модели автокомплита перед другими плагинами. Также JetBrains AI предоставляет безлимитный автокомплит бесплатно. Он будет немного урезан по возможностям, и для его активации нужно будет прикрепить банковскую карту, конечно же, зарубежную. И если у вас такая возможность есть, то как будто бы это самый доступный и удобный вариант.

Есть и другие варианты с бесплатным безлимитным автокомплитом. Это и Codeium, которые предоставляют автокомплит на базе модели. И с недавнего времени StarCoder позволяют входить в свой аккаунт по российскому номеру телефона и получать необходимый APK для VS Code. Также есть open sourceный Refact. И помимо этих решений есть отечественные представители. Это Codegpt, Gigacode, Sourcecraft, VAI. Последним я, к сожалению, до сих пор не пользовался, не смогу никак его прокомментировать, но все остальные вполне рабочие решения. У них у всех тоже безлимитный автокомплит доступен в бесплатных тарифных планах. Да и в целом они полностью бесплатные. Кроме CodeGPT, который совсем недавно публиковали свою сетку тарифов. До этого он тоже поставлялся полностью бесплатно. Поэтому даже если у вас нет возможности оплачивать зарубежные решения, можно воспользоваться отечественными аналогами. Они в целом тоже достойны внимания.

Помимо плагинов для JetBrains, есть выделенные IDE, которые ориентированы на разработку вместе с искусственным интеллектом. Это и Cursor, который считается лидером рынка и в целом основной инноватор в этой области, имею в виду в области ИИ. Это его основной конкурент — Warp, это разнообразные китайские TIDE, Coder, AntiGravity от Google и другие. Они все достаточно похожи. Плюс-минус большинство из них — это форки обычного VS Code, поэтому выглядят они очень похоже. По возможностям тоже они друг от друга стараются очень не отставать. Поэтому, если что-то появилось где-нибудь в Cursor, то вы можете в целом ожидать, что это скоро появится и у других, и наоборот. Здесь тоже есть российский аналог на всякий случай. Я пока что встретил только один, возможно, их больше, поэтому, если вам это актуально, вы можете воспользоваться им или попробовать поискать ещё другие варианты.

Также есть ещё такая диковинная штука, как Agent IDE. Это агентные среды. И по сути это то же самое, что и IDE, только здесь вы код как бы сами не правите. У вас вместо большой панели для редактирования кода — большая панель для работы с агентом. Под код выделена отдельная панель поменьше. И там, как правило, проводится просто ревью в конце работы агента. При этом в этом списке можно заметить те же решения, что мы видели и в IDE. Дело в том, что некоторые производители добавили в свои IDE переключатели режимов, где вы можете работать со инструментом в двух из этих форматов. То есть, буквально, вы выбираете, что важнее: более большая область работы с кодом или более большая область работы с агентом.

Из интересного, примерно из этих инструментов пошла такая мода по возможности запуска параллельных агентов. Причём по возможности их запуска в разных режимах. То есть вы можете запускать его непосредственно здесь, прямо сейчас локально. Можно запускать параллельного агента в отдельном Git Workflow. Также можно запускать параллельного агента в какой-то изолированной среде, в какой-нибудь Docker-контейнере. Это так называемый sandbox, изолированное окружение, внутри которого можете дать агенту все права, не боясь, что он навредит вашей основной системе.

Следующий уровень — это CLI. Это агенты, которые запускаются внутри прямо терминала. Здесь, на мой взгляд, произошла основная революция, возможно, по нескольким причинам. Первое заключается в том, что в такие инструменты наиболее легко добавлять или удалять разнообразные новые или экспериментальные функции, так как их не нужно согласовывать со сложным графическим окружением, которое должно выглядеть удобно и понятно. Отсюда вытекает вторая причина. Это простота разработки таких инструментов, поэтому себе могут их позволить не только разработчики IDE, но и поставщики самих моделей непосредственно. А значит, вы можете получить не только модель, но и созданный специально для неё, настроенный максимально эффективно под работу с этой моделью инструмент. И более того, у вас пропадают какие-либо посредники между моделью и инструментом, а, соответственно, вам не нужно этим посредником платить, что как будто бы позволяет в том числе и экономить.

Также третья причина состоит в том, что таких агентов можно запускать практически везде. Вы можете взять абсолютно любую IDE, открыть внутри неё терминал и запустить любого терминального агента. При этом этот терминал можно расположить также слева, справа, снизу, сверху. И ваш опыт работы с этим агентом будет мало чем отличаться от работы с агентом через какой-нибудь плагин или отдельную вьюшку в другой IDE. Более того, вы можете такого агента запустить где-нибудь на бэкенде. И он может вам там помогать с разнообразными задачами инфраструктуры, мониторинга, какого-то сопровождения. А ещё такие терминальные агенты, они могут работать не только в интерактивном режиме, где вы работаете с агентом в режиме обычного чата, но и также вы можете запускать их в headless режиме, то есть прямо через командную строку вы можете написать команду обращения к агенту, указать промт, и агент будет работать внутри терминала, не заходя в интерактивный режим. И когда закончит свою работу, просто выведет вам ответ также обратно в терминал. То есть как будто бы вы выполнили просто обычную команду. То есть в таком headless-режиме можно интегрировать таких агентов даже в какие-то свои рядовые обычные скрипты или даже писать своих каких-то оркестраторов, которые будут запускать разных агентов с разными промтами, с разными настройками, забирать вывод из одного, передавать в другой и так далее. Это позволяет строить очень сложные комплексные инструменты или скрипты для автоматизации или чего-то ещё, что может прийти к вам в голову. В частности, никто особо не мешает запустить такого агента в терминале на постоянку, подключиться к нему какими-нибудь сервисами и пользоваться этим агентом удалённо или же настроить подключение по SSH и также подключаться к командной строке и работать с агентом через обычный терминал. Ну то есть здесь сильно расширились возможности применения агентов, они стали сильно популярны, появилось очень много разнообразных решений. Есть как множество проприетарных от разработчиков моделей, от разработчиков разнообразных IDE, так и множество других open sourceных и открытых моделей.

Так, например, основной мой агент — это OpenCode, который я могу подключить практически любую модель, практически от любого провайдера, который имеет достаточно удобный и симпатичный интерфейс. И у него довольно любопытная архитектура. Он работает в режиме клиент-сервера, то есть это, по сути, сервер, который поднимается у вас, а терминал всего лишь клиент. И это, в частности, позволяет вам к тому же серверу подключаться удалённо, без дополнительных каких-то инструментов и костылей. Также моим вторым основным инструментом является CodeX, потому что мне очень нравятся модели от OpenAI. Для меня в целом GPT-4 стало некоторым не открытием, но, скажем, революцией. Именно с этой модели как будто бы резко вырос общий уровень качества всех моделей. То есть и сама GPT-4 была очень мощная, и конкуренты начали тоже резко подтягиваться до этого уровня. И сейчас каждой новой моделью, и модели от OpenAI, и модели все остальные тоже показывают очень крутые результаты. И появление модели CodeX тоже стало своего рода новым этапом, потому что таких моделей, ориентированных именно на код, тоже стало появляться всё больше и больше. И они действительно очень классно работают именно с кодом.

Тем не менее, несмотря на всю крутость такого вида решения для агентов, они всё равно каким-то образом связаны с терминалом. А терминал — это такая штука, которую многие очень боятся. Боятся даже многие разработчики, хотя внутри это всё равно обычный чат. Вот этот вайб терминала он не отпускает. Поэтому в этом году стало популярным движение по разработке всяких красивых GUI-шек для вот таких терминальных агентов, каких-то дополнительных обвязок. В частности, из этого появились разнообразные CoPilot решения. Первыми были Claude со своим CoPilot, который они навайп-кодили, по-моему, в январе. По сути, это тот же самый Codeium, просто обёрнутый в более красивый интерфейс. И этого стало достаточно, чтобы привлечь ещё больше аудитории. Соответственно, эту волну подхватили и другие производители, и OpenAI сделали свой графический интерфейс, и Minimk, и всякие open sourceные тоже начали решения появляться. В частности, есть вот такой ION UI, который поддерживает вообще всех агентов и работает по протоколу, про который мы позже поговорим. И это стало тоже отдельным направлением развития агентной разработки, потому что в разработке тоже их можно использовать. Но, конечно, они ориентированы на более широкий спектр задач. Это как такие агенты, которые вы устанавливаете себе на компьютере, и они в целом решают ваши позитивные задачи. Хотя, с другой стороны, вы также можете открыть любого терминального агента, делать с ним всё то же самое. Другой только вопрос, что это будет внутри терминала и готовы ли вы работать в таком интерфейсе.

Также ещё один интересный момент связан с тем, что когда вы используете IDE, который встроен какой-то AI, как правило, вместе с IDE идёт ещё множество разных побочных функций. В частности, в IDE часто встроена индексация вашей кодовой базы, когда ваша кодовая база превращается, переводится в вектора, и у вас появляется возможность производить векторный поиск. То есть искать не просто по совпадению каких-то символов, а искать именно по совпадению некоторых смыслов, так как ваш запрос превращается в вектор, кодовая база также представлена в виде векторов, и вы можете эти вектора сравнивать. Чем вектора будут ближе друг к другу, тем ближе они будут по смыслу. И, в частности, во многие IDE встроена функция по транскрибации речи. То есть вы можете что-то надиктовать в микрофон, и это переводится в текст, и этот текст уже можно отправить с запросом. В CLI такого обилия инструментов нету, но их можно очень удобно доставить со стороны, сбоку, в частности, и индексацию кодовой базы можно подключить, есть множество сторонних инструментов. И можно использовать также транскрибацию речи через сторонние инструменты. Хотя недавно Codeium прямо в терминал встроили возможность использования микрофона, что выглядит довольно диковинно. Но, как я и говорил, что мы идём к тому, что инструменты будут всё больше снижать порог входа.

Но если вы пользуетесь не Codeium, а каким-то другим терминальным агентом, вы можете воспользоваться каким-то сторонним решением, представленным здесь в таблице. Есть как и сервисы, которые предоставляют эти возможности по подписке, так и есть полностью бесплатные, которые запускают модели для транскрибации локально у вас на компьютере. Они достаточно легковесные. Для их работы не требуются даже видеокарты. Там представлен большой выбор моделей. Единственный минус такого формата, то, что у вас локально будет крутиться модель, потреблять ваши ресурсы, в частности оперативную память. Есть модели, которые занимают 100 Мб, есть модели, которые занимают 500 Мб, есть модели, которые занимают полтора, два, три и более. Соответственно, чем модель больше, тем она будет качественнее распознавать вашу речь. Там также ещё есть параметр скорости работы, но это всё настраивается, подбирается модель под свои задачи. Лично мне хватает абсолютно локальной. Она отлично понимает русский, отлично понимает английский, отлично понимает даже китайский, отлично понимает смешение языков, расставляет пунктуацию, грамматику. В общем, всё отлично, меня полностью устраивает. Но при желании можно воспользоваться подписочным сервисом. Вы просто перенесёте

все свои вычисления в облако и будете использовать по умолчанию какие-нибудь достаточно топовые модели и ни в чём себе не отказывать.

Ещё про что важно упомянуть, это про кодинг-плены. Они появились примерно в то же время, когда опился C, когда выходил клодко. Одним из его возможностей было то, что вы используете подписку от анрофиic, которая предоставляет вам не просто какое-то количество токенов, которые вы можете потратить за месяц, а она предоставляет вам некоторые окна, в рамках которых у вас есть определённое количество запросов. Как правило, это пятичасовые окна, недельные окна и месячные окна.

У разных провайдеров разное количество таких окон, разное количество запросов, которое даётся в эти окна. И как будто бы у вас всё ещё тоже какой-то тарифный план, где у вас какое-то ограниченное количество токенов. Но если вы очень часто пользуетесь агентами, и вы там буквально каждые 5 часов какие-то работы производите, то такой формат будет для вас намного выгоднее, чем покупка простого тарифного плана, где у вас определённое количество токенов на весь месяц.

Лидерами здесь, конечно, являются CLДcД и Open AI ко, но также существует большое количество тарифных планов от китайских производителей моделей. Это, Minimк, Kim и Quen и Open Code недавно тоже добавили себе отдельную подписку, которая объединяет в себе большинство китайских моделей вместе. Также Квен тоже свои подписки предоставляет не только свои модели, но и модели от Kimia, от Gel и от Minimк.

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

Например, моя любимая модель Minimк. Она сейчас, наверное, самая дешёвая вообще на рынке, хотя когда я начинал ей пользоваться, она такой ещё не была. Другие провайдеры цены подняли, они поднимать не стали, и вот теперь они получаются как самые дешёвые модели, при этом на довольно высокой скорости. Minimк у нас вообще закуплен на всю компанию. Мы раздали эту модель и разработчикам, и гейм-дизайнерам, и тестировщикам, и вообще всем поставили всем агентов. Понятно, что пользуются по итогу этим далеко не все, но это позволяет сотрудникам сначала попробовать получить информацию о проекте у агента. Если агент не может уже никак ни с чем помочь, то тогда уже обращаться к разработчикам или к другим своим коллегам. И вот всякие такие задачи по ассистированию, по какому-то консультированию, по работе, по составленной спецификации Минимакса хватает.

И здесь в целом он работает не хуже, чем те же модели от Open AI, потому что если у вас составлена подробная спецификация, подробный план, то по нему просто нет шансов сделать как-то по-другому, чем так, как написано там. Поэтому более дорогие модели как будто бы имеет смысл использовать в задачах, где нужно провести какой-то ресч, где нужно как-то глубоко что-то поисследовать, подумать или же составить помочь вам спецификацию к задаче. В общем, задача, где реально нужна какая-то большая насмотренность, какой-то глубокий уровень рассуждений. А для простого выполнения или ответов на вопросы по существующему проекту достаточно простых китайских моделей, и при этом они работают без VPN. Единственная преграда, как использованию - это оплата зарубежными картами.

И нам ещё осталось рассмотреть несколько видов агентов. Первое - это облачные. По сути, это такой же терминальный агент, просто запущенный где-то на чужой инфраструктуре, где-то в облаке. Как правило, такие агенты, они работают с копиями ваших репозиторий. То есть вы подключаете к ним свой GitHub, GitLab, какие-то другие сторонние сервисы, они себе это всё копируют и там у себя крутятся спокойненько в изолированной среде без риска нанести ущерб каким-то вашим вычислительным ресурсам.

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

Также здесь обращу внимание на Kill ЛО. У них есть и агенты в виде плагинов, и в виде терминалов, и в виде много чего ещё. Они очень активно расширяются. В частности, у них есть и облачные агенты. И из интересного, у них есть бесплатный агент для проведения кодрев. То есть, если у вас нету возможности, навыков, желания подключить какого-нибудь терминального агента к вашему CICD и проводить, например, кодрев где-нибудь там на этапе сборки или после мережа, то вы можете очень просто это подключить через облачный килокод. У них есть возможность поставить ключ от любого провайдера, то есть вам не обязательно даже оплачивать подписку от Кила. Вы берёте ключ, который у вас есть, подключаете туда свою модель. интегрируете Kill с GitHub или с GitLab, буквально нажимаете две кнопочки, и у вас теперь на каждом мер Quвест приходит от агента. То есть таким простым способом вы можете автоматизировать себе, ну, точнее, не автоматизировать, а добавить помощника к ревью на какие-то задачи. Но тут же опять вам нужно подключить свой репозиторий к какому-то удалённому облаку, и у кого-то будет доступ до вашего проекта.

Теперь погрузимся ещё глубже и рассмотрим фоновых бэкграунд агентов. Это тот самый Open Claw и его аналоги. Если вы ещё не знаете, что это такое, вы можете набрать это в поисковой строке, и вы найдёте очень много материала последнее время про него слышно из каждого утюга. По сути, это тоже мало чем отличается от обычного терминального агента. Вы также можете его запустить где-то на удалённой машине, оставить его работать постоянно включенным, подключить к нему тоже разнообразные сервисы, подключить к нему какие-то мессенджеры, настроить общение с этим агентом через тот же самый Telegram. Это всё можно было сделать и раньше.

Единственное, что OpenClow и другая шайка подобных решений, они сильно упростили этот процесс. Вам буквально дали конструктора, который вы можете очень быстро и удобно сконструировать из разных блоков под свои какие-то потребности и получить реально своего персонального и ассистента, который может решать ваши бытовые вопросы, который может проводить какие-то ресерчи в интернете, собирать данные о погоде, работать с вашими проектами. И всё. И всё это можно настроить через удобный канал связи, будто Telegram, SLК, Discord и много-много другое.

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

И так как мы занимаемся разработкой на UnЮни, я не могу пройти мимо агентов, которые созданы специально для UnЮнити. Напомню, что у UNЮ Unity есть свой AI, который сейчас находится в активной разработке, но уже доступен версии Unity 6.3, если я не ошибаюсь. И если я не ошибаюсь, он до сих пор доступен бесплатно. Однако в марте они уже планируют выпустить это в открытую бету, и возможно скоро уже появится какой-то прайсинг. Но тем не менее пока им можно пользоваться свободно. И это достаточно интересный инструмент. Его всё ещё можно назвать сыроватым, но он всё равно выглядит намного перспективнее, чем другие сторонние аналоги.

У меня здесь списки только три, но по сути они все представляют из себя примерно одно и то же. Вы можете взять любого терминального агента, например, код, подключить к нему MCP сервер от Unity, точнее, не от Unity, а для Unity, и получить в целом всё то же самое. Единственное, что эти сервисы предоставляют более красивый, симпатичный интерфейс и сильно менее привлекательные ценники, чем если бы вы просто платили кодигн от того же клода.

Также нам осталось рассмотреть всякие интересные дополнения. Это разнообразные фреймворки для ваших терминальных агентов. Это и Speek Kit, и Open SP. Достаточно известные популярные фреймворки для работы по спецификациям. Это разнообразные оркестраторы, таск-трекеры, канбандоски, чего на самом деле только вообще нету.

Также есть множество разных инструментов, которые позволяют вам работать с агентами удалённо, прямо с ваших телефонов, либо через телеграмы, какие-то мессенджеры, либо через какие-то отдельно реализованные приложения. Например, есть очень много приложений для айфонов, и они довольно красивые. Есть и open sourсное решение. Например, тот же ION UI, который мы чуть ранее рассматривали, тоже позволяет вам подключаться к этому графическому интерфейсу, либо через URL сгенерированный, либо через Telegram и другие мессенджеры. Ну, также, как я говорил, OpenCд работает как отдельный сервер. Вы тоже можете его просто поднять и подключиться к нему также удалённо. То есть в целом у нас сейчас есть все возможности работать 247, и как будто это становится уже даже нормой.

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

Предлагаю бегло посмотреть на примеры инструментов, которые мы обсудили. Например, начнём с терминальных агентов. Попробую вызвать здесь кодекс, здесь какой-нибудь клод. Вот так примерно это выглядит. То есть как бы терминал, но как бы ничего страшного. Это обычное поле для ввода текста. Сюда можно это всё писать. Здесь также по слышу открываются разнообразные команды для совершения каких-то быстрых действий или настроек. Кодекс выглядит примерно так же. Похожий набор команд, похожий интерфейс. Кажется, мы что-то ввели не то. Подробно залезать вглубь них мы не будем.

Вот. Вот так вот выглядит Open CД. Видно, что он чуть посимпатичнее. Здесь также есть всякие команды через слш. При этом здесь есть ещё контекстные команды, которые открываются по Ctrl P. При этом у него достаточно интерактивный интерфейс. На это всё можно нажимать мышкой. И, более того, можно нажимать мышкой даже на сообщение внутри внутри диалога. Вот я могу взять своё сообщение, на него нажать, откроется тоже контекстное меню, что-то с этим можно сделать. То есть здесь как будто интерфейс подружелюбнее. И самое, что любопытное, что здесь можно его вызвать отдельной командой в терминале, написать run и также hello. И всё, управление вернулось к нам обратно. То есть как будто мы просто запустили обычный скрипт.

У OpenC также есть свой отдельный GUI. Выглядит он примерно вот так. Здесь достаточно интересный интерфейс. Можно посмотреть и файлы проекта, который открыт. И здесь есть отдельное окно для проведения ревью тех правок, которые сделал агент за текущую сессию. Здесь также можно вызвать терминал, добавить разное количество проектов. При этом инструмент ещё поддерживает из коробки Gitwork 3. Это всё достаточно удобно отображается рядышком в рамках одного проекта. В общем, довольно удобный инструмент. Единственное, его недостаток. Он очень требовательный к ресурсам и иногда отъедает сильно больше, чем от него ожидаешь.

Также покажу ION UI, про который я несколько раз упомянул. Как видим, это тоже обычное окно с чатом. Подключить здесь можно любого доступного агента на компьютере. То есть здесь отображается ровно то, что у меня установлено. Здесь также можно выбирать модели, можно выбирать режимы. Здесь можно запускать скилы, какие-то другие возможности. При этом, как и другой Cвор, он предоставляет всякие интегрированные в него готовые инструменты, всякие навыки, всякие какие-то субагенты, какие-то роли. При этом, как я говорил, что здесь можно воспользоваться реморежимом, включить доступ по URL, даже QR-код есть. Можно подключить какие-то сторонние мессенджеры, тотже Telegram, общаться с этой штукой через бота. Единственное ограничение, что устройство, на котором запущен Iонon, должен быть включен.

Далее посмотрим на этот китайская. В целом и курсор выглядит примерно так же. В целом все они выглядят примерно одинаково. Это обычно форки VS-кода. Единственное их отличие от ВС-кода - это наличие панельки справа, хотя и VS-код тоже добавили CPIL. И также здесь можно обратить внимание на кнопочку, которая переключает режимы. Вот мы её нажимаем и переходим в режим AD. И по сути теперь справа у нас не область для работы с кодом, а область для проведения ревю. Если мы сейчас агента отправим в работу, он пойдёт править нам какие-то файлы. Здесь будет отображаться то, что он делает, а в конце работы мы сможем спокойненько это и посмотреть.

Также предлагаю взглянуть на Rider. Здесь маленько другая концепция. Это плагин Jet Brains AI. По умолчанию у них всё работает в режиме обычного чата. В качестве агента у них выступает отдельный агент J. Не самая умная и функциональная штука, на самом деле. И они тоже это прекрасно понимают. И, видимо, поэтому пытается свой плагин превратить в комбайн по подключению разнообразных агентов, потому что вы можете сюда помимо Джни подключить множество других доступных агентов. В частности, можно подключить тот же самый Open CД или Cдекс. Они даже добавили отдельный Marketплейс для таких агентов. Теперь это всё устанавливается очень просто, буквально по одному клику. Когда всё только запускалось, было сильно сложнее, была документация с неработающими примерами, и приходилось вручную подбирать нужные комбинации команд для запуска этих агентов. Так что всё очень быстро и очень сильно упрощается. Единственное, что работает, пока это не сильно стабильно. Не зря здесь горит буковка бета. Ан при этом работает тоже по такому же протоколу. То есть принцип работы у этих инструментов одинаковый.

Теперь поговорим про работу с агентами. Агент - это неросе, с которой вы можете не просто общаться, а которая имеет некоторые рычаги, воздействия на среду, внутри которой она находится. Она может что-то читать, создавать, удалять, редактировать, запускать, может взаимодействовать с другими службами, сервисами, приложениями и так далее. Это сейчас основной способ работы с и в разработке и не только. И нам сейчас важно из этой документации выцепить какие-то наиболее важные моменты.

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

Здесь также очень важно выбрать для себя подходящие модели, определиться с какими-то этапами, которые есть в вашей работе с агентом, и для каждого этапа выбрать модель, которая лучше, дешевле и быстрее решает поставленную задачу. Так как универсальные модели для всего постони существует, вы можете взять самую дорогую, самую мощную и использовать её везде, но в ряде задач это будет избыточно, дорого и медленно. А если мы говорим про какие-то топовые модели, то слово дорогое можно подчеркнуть несколько раз. Поэтому логично для планирования или каких-то задач, которые требуют большого уровня рассуждений, лучше брать действительно мощные рассуждающие модели, в том числе из числа лидеров рынка. Но для задачи попроще или, например, для кодинга стоит брать модели, которые либо заточены именно на программирование или другой вид деятельности, который вам нужен, либо которые просто способны такие задачи вообще решать за приемлемую стоимость.

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

Потому что агенты реально заставляют вас, даже вынуждают больше заниматься проектированием, больше заниматься документацией, больше заниматься обсуждением всяких неявных каких-то моментов, которые могли бы всплыть в будущем, но их очень важно описать и продумать прямо сейчас. Это приводит к тому, что вы начинаете больше работать с командой, больше коммуницировать как с друг другом внутри отдела разработки, так и больше с коллегами из других отделов. Вы начинаете более плотно работать с авторами ГД и других требований для ваших задач. Это всё выливается в появление более детализированных и продуманых технических документов, как и в целом к появлению их на проекте. Возможно, у вас их даже раньше и не было никогда.

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

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

Это, в частности, можно отнести и к некоторым минусам, к тому, что разработка может становиться сложнее. Это может требовать от вас больше концентрации, больше когнитивных каких-то ресурсов. Да и в целом, если вы неправильно подойдёте к взаимодействию с иагентом, он начнёт генерировать очень много мусора. Если это вовремя не заметить, то в какой-то момент это просто похоронит ваш проект. Поэтому это как очень полезная штука, так и очень опасная.

Если говорить про игровую разработку, большой проблемой остаётся интеграция с редактором, в частности с Unнити. Интеграции, конечно, есть, но они до сих пор оставляют желать лучшего. И многие до сих пор изобретают разнообразные велосипеды для того, чтобы более комфортно работать агентом с редактором. Ну и также стоит помнить, что если вы работаете с неростями, которые предоставляются вам какими-то облачными провайдерами, здесь есть вопросы конфиденциальности, каких-то утечек данных, вообще общей доступности и, соответственно, стоимости.

Если возвращаться к вопросам подхода к работе с агентами, то здесь есть несколько элементов для прочного фундамента. Первое, как ранее говорил - это промтинг, который обязательно нужно в каком-то видину освоить. Далее есть несколько подходов, имплементация которых поможет добиваться более качественных результатов. Также очень важно правильно работать с контекстом вашего агента, предоставлять ему возможность получать и обновлять информацию, которая касается вашего проекта, предоставить понятную и надёжную архитектуру, внутри которой агент бы мог самостоятельно работать. А для этой самостоятельности ему очень важно обеспечить фидбк-клуб, он же цикл обратной связи, то есть возможность агента получать информацию от окружающей среды о том, насколько корректно и правильно он вообще действует, чтобы он мог самостоятельно принимать решение о том, стоит ли ему что-то исправить или переделать или же нет. И имея все эти элементы, необходимо будет наладить цикл работы агента над конкретными видами задач внутри вашего проекта, зафиксировать их, описать и позволить агенту по ним автономно работать. Тот или иной шаг внутри этого фундамента так или иначе перераспределяет обязанности между инженером и и агентом в software Development Life Cycle. Подробно над каждым этапом мы останавливаться не будем. Я думаю, что перейдём к следующим документам.

И первое на очереди у нас - это подходы. Первый и самый важный - это Plan and Act, когда мы сначала занимаемся планированием работы, получением от агента описания того, что он сначала собирается сделать. И только когда нас это устраивает, мы позволяем ему идти и выполнять описанную им же работу. Это можно сказать, что сейчас уже является базой. Большинство, если не все инструменты, предоставляют несколько режимов работы, как режим планирования, так и режим непосредственного действия. У кого-то этих режимов больше, у кого-то этих режимов ровно два. Не скажу, где это появилось впервые, но у меня в памяти почему-то прочно закрепился.

Следующий подход, которому стоит уделить внимание, тест driven development - это, само собой не новый подход, но в эпоху развития и агентов он как будто получает второе дыхание. На данный момент, к сожалению, агенты всё ещё плохо справляются с задачей предварительного генерирования тестов без финальной реализации, но именно как концепция это звучит очень обнадёживающе и эффективно. И, возможно, рано или поздно мы придём к этому подходу как к стандарту. А пока что стоит учитывать, что для агента всё равно очень важно наличие тестов. Пусть он и не сгенерирует вам их перед началом работы, но он вполне способен справиться с генерацией тестов хотя бы в конце.

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

Но что бы вы не решили дальше делать со спецификациями, принцип работы он примерно одинаковый. Сначала вы эту спецификацию составляете либо генерируете и потом проверяете. Потом вы по этой спецификации утверждаете план работы агента. При необходимости проводится декомпозиция этих задач и затем отправляете агента в работу, где он это всё реализует, проверяет, валидирует, тестирует и при необходимости обновлять спецификации. Всё достаточно просто, по крайней мере, на словах. Есть даже разнообразные фреймворки для работы по спецификациям. Их сейчас очень большое количество. Сейчас новые веб-фреймворки выходят, наверное, даже чаще, чем когда-то. выходили фреймворки для джаваскрипта. И поэтому, если вы не знаете, с чего начать, вы можете воспользоваться каким-то из фреймворков, освоиться, подходить какие-то общие принципы и далее вы будете в состоянии сделать фреймворк для себя. Это, скорее всего, даст вам больше выгоды, потому что открытые фреймворки, они достаточно универсализированы, достаточно обобщены, а для эффективной работы агента очень важно давать ему максимально конкретные инструкции, нацеленные под конкретный проект, что и может стать основной мотивацией для вас сделать свой локальный фреймворк.

Есть ещё третий уровень для Spec Driven Developмента, это Specource, когда спецификация выступает некоторым первоисточником. То есть здесь мы, как разработчики, вообще никак не касаемся кода. Мы генерируем спецификацию, по ней проводим генерацию итоговой кодовой базы. И если нам нужно что-то в кодовой базе поменять, то мы сначала идём в спецификацию, редактируем её и на основе новой спецификации проводим повторную генерацию. При этом все спецификации, они продолжают храниться в самом репозитории и являться артефактами вашей работы. С текущим состоянием моделей этот поход пока что работает, возможно, не лучшим образом, но как концепция, это интересный вектор развития. Есть даже сервис, который ставит эту идею своей основной фичой. Посмотрим, что с этим будет дальше. Можно к этому пока присматриваться, можно это пробовать, но пока это точно не стандарт при работе с агентами.

Теперь перейдём к разбору контекст engниринг. Здесь нам важно разобраться с тем, что находится в контексте вашего агента. В контекст попадает, как правило, всё, что вы можете видеть в истории вашей переписки с агентом. Это и скрытый системный промт, который явно наблюдать не получится. Это и все возможные правила, все возможные инструменты, навыки и прочие настройки, подключенные к вашему агенту. Это и полная история вашего общения, это и ваши промты, это и какие-то внешние знания и файлы, которые вы явно подключили в историю или агент смог найти самостоятельно и забрать к себе это и логи ошибок и все его размышления и всё-всё-всё остальное. Это всё попадает в контекст.

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

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

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

Что здесь ещё у нас есть важного? Стоит ещё тоже, наверное, отметить, что объём текущего контекста влияет на стоимость, так как у LM нету какой-то своей памяти, она не помнит ничего из текущей истории разговора, поэтому с каждым новым промтом передаётся текущий промот и вся вот эта предыдущая история, весь это накопленный контекст. То есть он гуляет из раза в раз. И за этот объём информации, который мы передаём LLM, мы расплачиваемся токенами.

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

Я успел уже обронить такой контекст, что в контексте хранится не только те файлы, которые вы сами добавили, передали агенту, но и те, которые агент смог найти для себя сам. Для этого у агента есть тоже разнообразное количество инструментов от обычного поиска до каких-то подключаемых библиотек и сервисов, которые подгружают ему в контекст какие-то дополнительные файлы, какие-то какую-то дополнительную информацию, которая нужна ему для работы в данный момент. Об этом тоже нужно помнить.

И так как нам нужно не только следить за количеством контекста, за его качеством, нам ещё также важно этот контекст, возможно, где-то сохранять между сессиями. Здесь может помочь как раз подход Memory Bank, которую мы сейчас перейдём. Но сначала посмотрим, какие есть беспрактиса. Возможно, что-то важное нужно будет отметить.

Есть такое неочевидное замечание про русский текст. LLM обучаются преимущественно на английском языке, поэтому именно на английском они лучше воспринимают инструкции и в целом показывают как будто более качественные результаты. И также использование русского текста может потреблять больше токенов. Не обязательно, но может. Это всё зависит от модели, как качество работы с русским языком тоже сильно зависит от модели. Но вот в таком вот общем, максимально общем случае работа на английском, она и точнее, и экономичнее по токенам, где-то примерно в полтора, где-то даже в два раза.

И ещё один очень важный факт и не очень явный. Если вдруг вам модель ответила не так, как вы от неё ждали или хотели, то есть выдала неудовлетворительный результат, не нужно ей в ответ писать, как надо сделать по-другому, потому что и этот неправильный результат, и ваши лишние вопросы и уточнения, и её будущие ответы, это всё останется в истории, это всё останется в контексте навсегда, и модель будет об этом знать и помнить.

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

Вот теперь мы можем, думаю, перейти к меморибнку. Это достаточно уже старая методология, но всё ещё актуальная, и она про структурированное управление документацией внутри вашего проекта. Как правило, у вас выделяется некоторая либо отдельная директория, либо вы начинаете вести Memory Bank прямо от корня вашего проекта, но обычно всё-таки это в отдельной где-то папочке хранится. И там внутри вы собираете всё, всю метаинформацию о вашем проекте, которая агенту недоступна из кода или из других файлов, с которыми ему предназначается работать. Это и всякие соглашения проектные, это и всякие описания задач, планов, какие-то user story, это техническая документация, инфраструктура, технический стек, какие-то применяемые паттерны и подходы на проекте. Также это может быть набор некоторых workflows, то есть инструкций пошаговых, как выполнять те или иные действия. Но это уже немножечко устаревшая имплементация. Об этом мы тоже позже поговорим. В том числе, если вы работаете с агентами через задачи. В этом меморибнке могут храниться все задачи, с которыми нужно агенту работать. Там может быть свой какой-то маленький таск-трекер, где агент может отмечать прогресс выполнения и прогресс работы над задачами и многое другое.

Здесь нету жёстких каких-то правил или ограничений. Можете строить band, как вам захочется, как вам будет удобно. Здесь очень простой рабочий цикл работы с ним. Перед началом каждой сессии агент сходит в Memory Bank, прочитает какую-то основную входную информацию, обновит свой контекст, что-то поработает, что-то поделает, при необходимости обновит Memory Bank. Основная концепция Меморибнка - это не только предоставление информации для агента, но и возможность агенту эту информацию актуализировать самостоятельно тоже. В целом достаточно простая концепция, достаточно просто реализуется и тоже имеет какое-то количество готовых фреймворков, которыми можно воспользоваться.

Также ещё учитывайте, что нейросети в целом очень хорошо работают с разными диаграммами, схемами и прочими графическими представлениями информации. В частности, очень хорошо они работают с Mermate. И для красивого рендеринга понадобится в ваши IDE поставить добытные плагины, которых тоже очень много.

Отсюда движемся дальше к архитектуре. Было бы хорошо, чтобы на вашем проекте вообще была хоть какая-то архитектура, потому что если её там нету, агент сделает только хуже. Здесь можно, конечно, и начать холивар про то, какая архитектура лучше, какая архитектура хуже, но в целом внутри сообщества сложилось уже мнение и представление. Да, и в целом, даже если агентов убрать за скобки, я тоже продерживаюсь такого мнения, что самая удобная архитектура для для проектов в командной разработке - это древовидная. То есть, где все наши зависимости, они выстроены в виде дерева от какого-то корневого узла, мы потом расходимся по дочерним. И чем глубже мы по дереву перемещаемся, тем более низкоуровневые, точнее, не так, более верх верхнеуровневые фичи мы имеем. Например, здесь сам корне у нас какой-нибудь entry point, потом какая-нибудь базовая наша архитектура, какая-нибудь машина состояние для переключения стоитов нашего приложения. Потом мы можем пойти в какой-нибудь модуль авторизации. Тут у нас может быть какой-нибудь Core GameПй, тут может быть метагеймплей, тут какой-нибудь магазин, тут какие-нибудь оферы, там какие-нибудь ещё что-нибудь и так далее.

Основная идея здесь то, что каждый вот этот узел, он независимый. То есть у нас какой-нибудь модуль с оферами, он не связан напрямую с модулем каких-нибудь обычных покупок. Два этих листа, они взаимодействуют строго через родителя. Это обеспечит довольно удобную структуру, в которой довольно просто ориентироваться, с которой достаточно просто работать. Из-за того, что всё изолировано друг от друга, можно работать в каком-то узле, не боясь нарушить работу других узлов, которые напрямую не связаны с текущим. В целом, это ровно то, что нам дают обычные DI фреймворки. DI тем и занимается, что строит дерево зависимости. Поэтому, если вы на проекте используете и строите всё вокруг DIя, то как будто бы вы, ну, не автоматически, но вам сильно сложнее будет строить другую архитектуру. И вот именно в таком формате агентам тоже работать наиболее просто, в частности, из-за ограниченности и изолированности вот таких вот модулей.

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

И ещё один важный вывод из всего из всего этого - это наличие техдолга. Когда у вас техдолг находится вот в этих листьях, то есть в печах, это не особо страшно. Агент может и сам этот техдолг вполне себе устранять. Вы можете даже делать какие-то запланированные запуски агента, который будет автоматически заданное время пробегаться по проекту, пытаться устранять техдолг вот в этих вот местах. Но техдолг в вашем стволе, то есть в архитектуре, то есть в зоне ответственности разработчика, это уже штука опасная, и там тех лучше не допускать.

Например, приведу случай из своей разработки. Составил большой проработанный документ, спецификацию для агента по новой фиче. Всё было описано здорово, классно, подробно, точно и чётко. Агент эту задачу делал примерно 3 часа, выдал отличный работающий результат. Но когда я пошёл смотреть, точнее, проводить ревью, выяснилось, что во время работы агент наткнулся на некоторый технический долг, который немного мешал выполнению текущей задачи, но агент не стал его исправлять, потому что это не входит в зону его ответственности в текущий момент, то ему нужно фичу выполнить всеми правдами и неправдами. Поэтому он начал этот техдолг, этот костыль максимально огибать, максимально обходить. И это привело к тому, что он начал плодить костыли дальше вокруг. Задачу он, конечно, выполнен, но получилось это очень уродливо, и из-за этого пришлось потом всё переделывать. В частности, пришлось предварительно перед этим пойти устранять обнаруженный техдолг в архитектуре. И получилось так, что вместо быстрого и качественного результата получился, конечно, не нейрослоб, но получилось решение, которое было непригодны для интеграции и которое пришлось потом по итогу переделывать, в том числе вручную. Поэтому за тех долгом в стволе очень важно следить. Если агент во время работы напорится на такой техдолг, он будет его растаскивать дальше по всему проекту. И обеспечить такую защиту, на самом деле очень сложно. Звучит это может быть понятно и просто, но на практике вы будете непременно с этим сталкиваться. Понятно, что вы не сможете избежать тех долга полностью. Поэтому всегда держите в голове, что вот что что-то подобное может произойти в любой момент.

Здесь, думаю, мы закончим и перейдём далее к фидбек-лупу. Постараюсь удержаться и не шутить про пу. Расскажу только про цикл обратной связи. Здесь концепция тоже очень простая. У нас есть человек, у нас есть нейросеть, она же LM, он же агент в нашем понимании. И этот агент как-то взаимодействует со средой. То есть это ваша кодовая база, это ваши движки, это ваши какие-то окружения, IDE и всё остальное. Всё, до чего дотрагивается агент. И задача фидбэклупа предоставить обратную связь для агента. То есть это всякие разнообразные логи, результаты прогонов, теста, проверки, форматоры, данные из браузера, скриншоты, в общем, всё то, что может отразить результат текущей работы агента и направить его в ту или иную сторону или же подкорректировать. И это одна из основных идей, один из основных элементов, который обеспечивает автономную работу для агента. А это в целом основной драйвер вашей производительности, вашей эффективности, потому что чем больше задач может агент закрыть самостоятельно без вашего участия, тем в целом выше ваша пропускная способность как команды, как компании.

Как эту обратную связь обеспечить, э, способов большое количество. Всё это сильно зависит от проекта, от вашего контекста, от вашей специализации. И в целом это достаточно большая, серьёзная инженерная задача. Поэтому, когда вы работаете с агентом, всегда думаете о том, как же ему предоставить обратную связь, как сделать так, чтобы агент сам мог себя проверить, сам протестировать свою работу, если она неправильная, и как понять, что она неправильная, и чтобы он потом её сам исправил. Это тоже может звучать на словах достаточно просто, но на практике реализуется это довольно утомительно, сложно и итеративно. С первого раза никогда ничего не получится. Здесь нужно постоянно что-то подкручивать, постоянно искать. какие-то новые способы. Плюс у вас проект постоянно растёт, у него появляются новые потребности, новые функциональности. Ко всему этому новому нужна новая обратная связь. Поэтому процесс этот постоянный- это не разовая настройка, как и всё то, про что мы сегодня говорили и будем говорить.

Перейдём дальше. Критерии оценки агента. Так, что-то пошло не так. обновил страницу. Здесь мы задерживаться не будем. Вы можете ознакомиться с этим самостоятельно. Здесь сейчас для нас полезного ничего нету. А вот критерии для задач, которые можно было передать агенту, это момент важный. Все эти критерии были взяты из вот этого видео. Рекомендую посмотреть его полностью.

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

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

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

Нужно также ещё определить количество мест для изменения, потому что если, например, агенту нужно провести какой-нибудь там ренейминг, и он может потребоваться затронуть огромное количество файлов, и в чистом виде он с этим, скорее всего, не справится. И быстрее и надёжнее будет сделать это самостоятельно. Но сейчас уже в агенты интегрировано много дополнительных инструментов, которые позволяют вам работать с кодом на уровне структуры, на уровне связи. Это всякие LCP-сервера, всякие дополнительные MCP, анализаторы и прочее, которые в целом упрощают эту задачу для агента. И агент сегодня даже может справиться с подобной задачей. Но это просто такой пример, возможно, не самый удачный, но в целом нужно понимать, что чем больше агенту править файлов, тем больше вероятность того, что он собьётся с пути, сделает что-то не так.

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

И все эти критерии нам нужны, как уже стало понятно, для того, чтобы определить, что делать задачей. отдавать её агенту, декомпозировать, добавлять больше контекста или выполнять по итогу вручную. Чётких правил по оценке этих критериев и по принимаемым решениям, конечно же, нет. Это всё нужно нарабатывать с опытом. Это нужно вырабатывать вот какую-то чуйку, которая будет вам позволять понимать, как действовать в той или иной ситуации. Здесь всё тоже зависит от вашего опыта, от вашего стиля работы, от модели, которую вы используете, от агента, которую вы используете. Пока что эти вопросы, они довольно индивидуальны, поэтому познавать их придётся через практику самостоятельно.

Далее переходим к циклу работы над задачей. На самом деле это тот же самый цикл, который был представлен в Spec-Driven Development, только чуть более расширенный. Это в целом то, как у нас реализована в командах работа агентов над задачами, над большими крупными задачами. Понятно, что какие-то мелкие правки по такому циклу гонять абсолютно бесполезно.

Здесь в первую очередь происходит сбор требований. Это не обязательная работа агента, это не обязательно работа с агентом. Здесь ваша задача, например, вы получили ТЗ, вам нужно его проработать, провести ревью, задать уточняющие вопросы, внести необходимую информацию, которая не покрывает те или иные кейсы или случаи, то есть расширить его до того состояния, где не остаётся никаких вопросов, никаких пробелов. Возможно, здесь ещё потребуется собрать какую-то дополнительную документацию по другим механикам или по каким-то особенностям реализации вашей системы, неважно. В общем, здесь вам нужно собрать все абсолютно требования, которые касаются вашей задачи, всё, что нужно для её решения.

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

Затем, когда вы поделили вашу задачу на какие-то области для работы, мы переходим в каждую область и внутри отправляем сначала агента на изучение. Агент собирает всю доступную на данный момент в проекте информацию, как реализованы те или иные системы, которые нужны для решения поставленной задачи. Затем мы отправляем его на поиск таких решений. он может найти несколько вариантов, описать каждый из них, какие у каждого плюсы, минусы, подводные камни, риски и так далее. И в целом даже предложить какой-то из них как самый приоритетный, самый простой для реализации или какие-то ещё критерии, которые могут быть для вас важны.

Далее, на основе этой информации вы вместе с агентом составляете итоговую спецификацию. Вы решаете, как именно вы будете по итогу решать проблему. копаете в сторону выбранного решения, описываете все необходимые детали и тонкости, которые нужно учесть при разработке. И когда спецификация будет вас удовлетворять, вы переходите на этап планирования. Здесь вы эту спецификацию разделяете на конкретные задачи. Эти задачи распределяете между субагентами, даже если вы их у себя не настраивали. В целом агент может сам для себя определить какие-то роли. что, например, эта задача она на разработку, эта задача она на разработку в контексте Unity, это в контексте бэкэнда, это задача возможно написание документации и так далее. Эти задачи могут идти как последовательно, задачи какие-то могут идти параллельно. То есть здесь ваша цель создать некий такой таск-трекер, где будет указана очерёдность выполнения, назначены роли, поставлены критерии завершённости и, возможно, оставлена какая-то область для агента, где бы он мог помечать свой текущий прогресс.

И затем мы передаём эти задачи в работу. Эти задачи могут идти как параллельно, так и последовательно, в зависимости от выставленных связей. Внутри каждой задачи агент делает какую-то работу, в частности, возможно, пишет код. Вместе с этим он потом проверяет тесты текущие, которые есть на проекте, тесты текущие, которые он написал для этой задачи. Когда с тестами всё будет в порядке, он может отдать это на ревью, даже не может, должен отдать на ревью другому субагенту. Желательно с каким-то изолированным контекстом, который не знает вот об этом всём проделанном. Он это проверяет. Если нету проблем ни с тестами, ни с ревью, то агент двигается дальше. Если где-то возникает проблема, агент продолжает дорабатывать эту задачу до тех пор, пока не дойдёт её до конца.

Когда задача завершена, он обновляет текущую документацию. Это, в частности, возможно, ваш тастрекер, который был составлен при планировании. Это может быть какие-то другие связанные документы, если вдруг он поправил какие-то какую-то логику в проекте. Это могут быть новые документы, которые появились в процессе работы на задаче. и многое другое, что может быть важно для ваших вал контекста. Когда все задачи выполнены, в конце тоже желательно провести уже общее финальное ревью, общее финальный прогон тестов, общее финальное обновление там документации, сбор всего это в одну кучу. И на этом моменте эта задача может уходить уже в полноценный мерж-квест, в полноценное ревью другим разработчикам. И тут на этом моменте вы можете для себя решить, что вы по итогу делаете вот с этими артефактами, которые были получены на предыдущих шагах. Например, мы в компании спецификации не сохраняем. У нас есть отдельная директория, которая вообще не попадает в git, точнее, всё, что в её содержимое не попадает. И агенты оттуда складывают свои спецификации, свои результаты, а, ресерча, свои результаты поиска решений, результаты планирования. Они там отработали, они там это оставили. Это не попадает другим разработчикам. Мы в репозитории храним только вот эти артефакты. это техническая документация, это какие-то сопроводительные документы, которые кратко, лаконично, финально уже отображают, как реализованы те или иные вещи понятным языком, как для агента, так и для человека.

Вот такой вот у нас цикл работы над задачами. Здесь это всё описано в виде текста.

Далее, теперь мы переходим в раздел по работе с агентом в команде. Здесь, на самом деле, проблем очень много, и это может вылиться даже в отдельную лекцию. Поэтому я, наверное, заострю своё внимание на реальных проблемах, которые есть.

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

Также проблема может быть отсутствие стандартов. Мы с этим тоже работаем. Вот то, в частности, у нас есть оформлены циклы работами над задачами, разные пайплайны, разные workflow, определённые настройки. Всё это пошарено между всеми разработчиками, подключается ко всем их инструментам. Этот вопрос, возможно, самый решаемый.

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

Поэтому для внедрения и внутрь своей команды нужно начинать, во-первых, с малого, не пытаться внедрять его повсеместно и везде. Начните с каких-то маленьких, контролируемых и желательно полезных фич. Например, генерация юнит-тестов или генерация документации. Особенно, если у вас на проекте принято это всё делать. Если вы раньше этим не занимались, а теперь через агентство начинаете это генерировать, это выглядит как дополнительная работа. Это полезная работа, но она дополнительная. Раньше у вас её не было. А если вы этим и так должны были заниматься, то и здесь реально может вам помочь снять с вас какую-то часть рутины, потому что и тесты нейросети генерируют отлично, и документацию тоже генерируют прекрасно, и кодрев проводят в целом сносно, и всяческое ассистирование по проекту тоже проводят.

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

Если для компании И это что-то новое, им будет достаточно простых моделей. Текущие open-sourceные модели, они уже имеют достаточно большую мощность и способны решать достаточно сложные задачи и давать реальную пользу. Но помимо инструментов важно ещё и предоставить возможность. Как я уже говорил, для эффективного использования нужно время. И если у разработчиков раньше опыта работы с ИИ не было, то любая попытка использовать этот ИИ в своих реальных задачах будет эти задачи, точнее, длительность работ над ними только увеличивать. Если у вас нужно строго следовать таймингом выполнения, таймингом работы над задачами, и вы в задаче не закладываете время на обучение, то у сотрудников сбивается вся мотивация пытаться работать через ИИ, потому что нужно успеть закрыть задачу. Поэтому, если вы внедряете, вы хотите, чтобы сотрудники обучались, учитывайте это при планировании и предоставляйте им время на обучение. И желательно делать это на реальных задачах, даже если сейчас они замедляются. Это может в будущем окупиться, потому что если они научатся, они будущие задачи будут закрывать и быстрее, и, возможно, даже качественнее.

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

Ещё важно поработать над высотой порога входа, попытаться его снизить. В этом может помочь какая-то бесшовная интеграция в вашей текущие workflow, ваши текущие инструменты. Если разработчики не привыкли работать с агентами, будет, наверное, болезненно сразу отдавать им какой-нибудь терминал или какой-нибудь сторонний вообще другой инструмент, вместо того, чтобы внедрить что-то новое в то, с чем они уже работают, в ту же текущую IDE. плагинов сейчас большое количество, их использование, возможно.

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

Ещё полезным может быть создание какой-то единой базы знаний, например, как у нас, куда сотрудники смогут возвращаться для того, чтобы освежить свою память или, наоборот, познакомиться. Или если вдруг ваши сотрудники любят накапливать какой-то материал, просмотренный в интернете, то вы можете, в том числе, предоставить им возможность где-то складировать вот эти полезные ссылки, которые могут вам в будущем понадобиться.

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

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

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

Здесь всегда важно не обещать какую-то магию, говорить открыто о том, что этот инструмент - это не панацея, это не волшебная таблетка. У него есть как свои плюсы, так и свои минусы. Где-то он работает хорошо, где-то он работает плохо, где-то работает отвратительно, и лучше им вообще не пользоваться.

Также не забывайте подавать личный пример. Мало говорить о том, что и это классно, и здорово. Нужно не забывать показывать, почему это классно и почему это здорово. И всегда давайте право на ошибку. Если у человека, у сотрудника что-то не получается, не срастается с агентом, это не повод его как-то обвинить или обвинять или если он если ему не удалось закрыть задачу из-за агента. Из этого не нужно делать повод для какого-то порицания. Лучше вместе собраться и обсудить, что пошло не так, что было предпринято, что не предпринято, как можно улучшить процесс работы, стоит ли вообще было применять агента в этом сценарии. Расценивайте это как точку роста.

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

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

Конец.

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

Начнём мы с тулов. Тулы - это руки для вашего агента, которые позволяют работать с файловой системой, искать файлы, читать файлы, редактировать файлы, создавать. Это также возможность запускать разнообразные команды в терминале. Это возможность извлекать какой-то контент из веб-страниц. Это поиск веб-страниц, это создание всяких ту-ду списков. Агент такое делает часто, чтобы фокусировать своё внимание и не распылять его. Вы можете эти ту-дулисты видеть в вашей активной сессии. Также недавно появился инструмент для возможности агента задавать вам вопросы и предлагать варианты ответов. И также запуск скилов - это тоже отдельный тул, отдельный инструмент. Про навыки мы чуть позже тоже поговорим.

Следующий пункт - это правила, рулы. Это, возможно, самое базовое, с чего нужно начать. Это обычные markdown файлы, где вы указываете какие-то свои намерения, пожелания и ограничения для агента. То есть корректируете его его поведение. Они могут быть как глобальными, так и локальными для проекта, так и локальными для каких-то подпапок внутри проекта. Само собой, всё это вместе комбинируется. Правила могут быть как проприетарными, с конкретными правилами по наименованию и по расположению, так и мог использоваться общий стандарт Agents MD. Очень многие агенты его поддерживают, но не все. Однако обычно используется именно он.

Внутри MD и любые другие правила оформляются максимально произвольно. Вы можете их оформлять в свободном стиле. И по наполнению, как правило, это какой-то онбординг, какая-то контекстная информация по проекту, какие-то глобальные ограничения, какая-то, возможно, маржортизация, где вы указываете, где агенту искать ту или иную информацию. Этот файл не про какие-то инструкции в плане пошагового выполнения. Это не про гайды, это именно что про коррекцию поведения агента. При этом этот файл, он постоянно находится в контексте, он сразу же попадает в каждую новую сессию, поэтому его размер нужно удерживать минимально допустимым, стараться его не раздувать. Чем больше у вас файл с правилами, тем больше вероятность, что агент рано или поздно про них просто забудет и начнёт игнорировать. И в целом всё, что написано в этом файле - это не закон. Агент может это учесть, но может это полностью проигнорировать. Поэтому, если вам нужно какое-то стопроцентное следование каким-то ограничениям или каким-то установкам, это уже другого рода инструменты, например, хуки. Про них мы тоже позже поговорим.

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

Также инструкции вам нужно писать самостоятельно. Это именно ваш инструмент по настройке агента под ваши хотелки. Агент для себя сам ничего толкового не сгенерирует. У агентов есть, как правило, команда на инициализацию. какого-то начального файла, который будет учитывать доступный контекст проекта. Это можно использовать какой-то набросок и шаблон, но он, скорее всего, будет довольно большим, и там будет очень мало полезной информации. Поэтому его стоит использовать именно как какая-то отправная точка, но потом отредактировать, наполнить вручную. Вы можете начинать с абсолютно пустого файла, нет никакой необходимости сразу делать полный всеучитывающий файл с правилами. Вы можете дополнять эти правила по мере необходимого. Создали файл. Как только увидели, что агент что-то делает не так, пошли, записали. Или видите, что агент наоборот не делает то, чего бы вы хотели, пошли и записали. Если агент начал делать то, что вы от него хотите, это победа. Если не начал, пробуйте другие формулировки или пробуйте другие инструменты.

На этом мы переходим дальше к workflow. Это, в частности, то, на что можно ссылаться внутри а правил. Это тоже markdown файлы со свободным содержанием, где вы как раз можете описать пошаговые инструкции и гайды, как решать те или иные задачи. Эти файлы тянутся ещё из концепции memory bank. Они никак системно не поддерживаются. И для того, чтобы ими воспользоваться, вам нужно их напрямую добавить в контекст, как будто вы прикрепляете какой-то файл. Соответственно, workflow они вызываются именно вручную именно разработчикам, именно пользователям. Однако есть хитрушка. Вы можете в правилах завести какую-то табличку, где можете перечислить доступные workflow, дать им краткие описания, чтобы у агента в контексте тоже эта информация содержалась и чтобы агент мог в случае чего знать, куда обратиться за инструкциями. Но по сути сейчас за это отвечают как раз скилы. Про них мы тоже чуть позже поговорим.

А перед этим мы рассмотрим команды. Это следующий этап развития вот этих workflow. Команды - это тоже описание каких-то инструкций для агента. Он тоже вызывается именно пользователем. Единственное, что первое, он вызывается через слэш. То есть мы уже не файл прикрепляем, а вызываем прямо через слэш полноценную команду. При этом то, что будет написано после вызова этой команды, это считается аргументом или аргументами. И это можно подмешивать в описание этой команды. Дело в том, что команда тоже представляет из себя markdown файл. У этого markdown файла есть своя отдельная шапка, которая учитывается агентом. И ниже этой шапки мы в свободной форме описываем обычные markdown инструкции, внутри которых мы можем использовать вот такие обозначения. Это как раз места, куда будут интегрироваться, вставленные ваши аргументы. И когда команда будет вызвана, агент возьмёт содержимое этого файла, интегрирует его в ваш запрос. Точно прямо как будто бы промт уже готовый отправят, и внутри этого промта на нужном месте окажутся ваши инструкции. И также следующее отличие кроется в этой шапке. Вот этот description он для агента не нужен. Это скорее для вас описание краткое, когда вы будете в меню его выбирать. Но вы можете здесь указать, какую модель использовать. Ещё в некоторых агентах поддерживается возможность запуска команд в отдельных субагентах. И о субагентах мы поговорим чуточку позже. То есть команда - это чуть более удобная, чуть более интегрированная системна функция, которую вы можете использовать для каких-то повторяющихся переиспользуемых инструкций. Если вам нужно что-то часто делать, это удобнее оформить в виде отдельного markdown файла, в виде отдельной команды и вызывать её тогда, когда это необходимо.

Также в агентах есть набор предустановленных команд. Он может отличаться от агенту от агента к агенту. Здесь перечислен список наиболее часто, возможно, используемых и наиболее полезных. С ними рекомендую ознакомиться и научиться пользоваться каждой. Особенно полезные вот эти вот три. Они помогут вам работать с агентом намного эффективнее.

Следующий этап - это скилы, навыки. Возможно, самое полезное, что вам нужно освоить. Изначально они появились как альтернатива для MCP. Про него попозже, но сейчас они пытаются с собой заменить и команды, и субагентов. Вообще, по сути, это тоже некоторый markdown файл, но он не ограничивается только лишь одним файлом. Skill - это целая папка, куда входит и файл с инструкциями, и, возможно, какие-то примеры, какие-нибудь пдфки, какие-то сторонние документы, в том числе какие-нибудь скрипты, которые вы можете запускать внутри своей инструкции. Точнее, не запускать, а указывать агенту, как запускать эти эти скрипты. Скилы тоже могут быть локальными, могут быть глобальными. У скилов тоже в основном markdown файли есть своя шапка, есть своё описание. Но что очень важно, если команды вызывались строго пользователям и при запуске полностью попадали в контекст, то скилы в первую очередь рассчитаны на то, что их будет вызывать агент самостоятельно. И вот эта вот шапка, она находится всегда в контексте. А его полное описание, оно загружается только тогда, когда агент решил этот скилл использовать. В шапке указывается короткое название этого скила и его описание. Здесь рекомендуется писать именно сценарий того, когда этот скилл лучше применять. Это повышает вероятность того, что он вообще будет вызван, так как агенты, даже имея какие-то скилы у себя в контексте, могут их проигнорировать, даже когда задача, ну, максимально очевидна, что должна использовать какой-то из налогов. Это довольно известная и частая проблема, с которой борются теми или иными методами. Про них можно почитать в беспрактисах ниже. Мы до них тоже дойдём.

Помимо того, что агент может вызывать навыки, не так давно добавили возможность вызывать навыки и вручную. Они вызываются также, как и команды, через слэш работают по такому же принципу. То, что будет указано дальше, это учитывается как аргументы. Вы также в скилах можете оставлять места для интеграции этих аргументов. И по сути основное отличие между скилом и workflow - это то, что workflow агент вызвать сам не может. Но так как мы стремимся к полной автономности агента, то как будто бы и ничего не должно оставаться, ничего, чтобы агент не мог вызвать. Поэтому необходимость в отдельных командах, она постепенно отмирает.

Также некоторые агенты представляют возможность указывать в скиле модель, которую нужно использовать, и возможность запуска скилов в отдельном субагенте, что с собой тоже может заменить субагенты именно как вот формат реализации, как формат настройки. Рекомендации по скилам точно такие же, как и к правилам, и ко всему остальному. Держите их компактными, делайте их максимально чёткими, максимально конкретными. Если вы хотите, чтобы ваш скилл был вызван в определённые моменты работы агента со стопроцентной вероятностью, вам стоит посмотреть в сторону хуков. В противном случае гарантии вызова будет немного.

Теперь поговорим про субагентов. В плане структуры это тоже как бы markdown файлы, тоже могут быть глобальными и локальными. Тоже есть своя шапка, тоже есть какой-то системный промт, какое-то описание этого агента. В дескрипшене тоже лучше указывать сценарии того, когда нужно вызывать этого субагента. Но чисто технически субагенты нужны для чего? Это не какие-то файлы для того, чтобы работать по инструкциям. Это не какие-то инструкции. Это инструмент изоляции экономии вашего контекста. Дело в том, что когда агент хочет использовать субагента, он как бы внутри себя создаёт дополнительного внутреннего агента, который работает в отдельном контексте. И когда этот агент доработает, он возвращает результат своей работы обратно основному агенту. И получается, что в вашем основном контексте есть только момент запуска этого субагента и момент его завершения с результатом. А все прожуточные вычисления, они остались отдельно, и ваш контекст остался более чистым. И это основная задача субагентов.

И даже если вы себе не настраивали каких-то субагентов, не делали для них файлы, если ваш агент-оркестратор решит, что вот в этом месте он мог бы какую-то часть работы вынести отдельно, он может это сделать. Он может создать субагента. наполнить его системным промтом самостоятельно, то есть дать ему вот эти вот базовые инструкции, которые вы могли бы написать сами в файле markdown. Но если их нет, агент сам их придумает, сам отдаст, сам дождётся результата и сам его потом дальше обработает. И этот процесс, он уже как будто бы автоматизирован. И реальных полезных сценариев использования субагентов, чтобы самому их создавать, не так уж и много. И тут скорее этими файлами вы можете дать агенту какие-то свои намерения, что, например, вы бы хотели, чтобы процесс ревю проводился обязательно агент отдельно отдельным субагентом с какой-то конкретной заданной моделью, с какими-то конкретно заданными правами, потому что внутри субагента можете указать, например, что он не может редактировать файлы или что-то ещё делать или, наоборот, может. Это ваша возможность передать свои намерения по ожидаемому результату.

Ещё стоит отметить, что реализованы субагенты в разных инструментах по-разному. Где-то субагенты работают строго последовательно и блокируют основной поток, основную вашу сессию. Где-то субагенты работают параллельно, где-то они не блокируют основную сессию, можете продолжать общаться с главным агентом, где-то агент, главный оркестратор может общаться со своими субагентами во время их работы. Где-то он не может и только получает результат. где-то субагенты могут с другом даже общаться. Какого-то устоявшегося подхода здесь нет. Везде это реализовано по-разному. И везде это уже достаточно сильно автоматизировано. Поэтому, если вы переживаете, что вы для себя не делаете субагентов, ну, скорее всего, вам это и не нужно. Поэтому идти вот в это направление стоит только тогда, когда вы прямо поймёте, что вам необходимо заняться созданием какого-то субагента.

При этом в описании не нужно вставлять инструкции, не нужно вставлять гайдов. Вы сюда можете передать какой-то, ну, вот контекст, относящийся к той области работы, с которой будет взаимодействовать этот субагент. Если это какой-то агент-ревью, то тут можно указать правила по тому, как проводить ревю, на что обращать внимание. Или если это какой-то субагент для работы с Unity, вы можете там указать, например, свой стек и попросить его обращать внимание на оптимизацию и на количество локаций, что-нибудь такие, в общем, вещи. Так как эти субагенты, они довольно в широком спектре сценариев вызываются, особого смысла в каких-то конкретных прямо инструкциях нет, потому что для инструкции у вас есть скилы, у вас есть команды. Эти же скилы спокойно ваш оркестратор может впихнуть в какого-то отдельного субагента. Например, если у вас есть какой-то скилл на написание техдокументации, оркестратор может решить, что это можно сделать в отдельном субагенте. создаст субагента, передаст ему скилл. И вот, пожалуйста, у вас есть как бы субагент с готовым описанием, который вы тоже написали, но при этом markdown файл для суббагента вы не делали.

Вот на этом я, наверное, уже остановлюсь, потому что, кажется, я начал слишком далеко уходить. Основную идею надеюсь передал. Поехали дальше.

Это хуки. Хуки достаточно тоже сложная концепция, но это очень мощный инструмент и очень точный, который помогает вам сильно и жёстко ограничивать работу вашего агента. Это некие пользовательские скрипты, которые вызываются по определённым событиям. Не все агенты поддерживают хуки. Достаточно немного, я бы даже сказал. Здесь переведена таблица с событиями из clocod. Здесь видно, что можно вызвать хук на начале сессии, на завершении сессии, при попытке какой-то инструмент использовать. Что вы можете с этими хуками сделать? Например, вы можете подключить какие-то звуковые уведомления на те или иные этапы работы. Например, можете при попытке агентам что-то удалить проверить, можно ли вообще это удалять. Если это удалять нельзя, то можете резко остановить работу агента или запустить какие-нибудь линтеры, форматоры, когда агент закончит работу над кодом. Или же если вы видите, что агент закончил сессию и внутри были какие-то правки кода, то запустить отдельно скилл на проведение ревю. Вот такая вот эта штуковина.

А далее у нас есть MCP. Если тулы - это были руки агента, то это прямо целые щупальца. Это возможность подключить какие-то сторонние сервисы к вашему агенту. Можно расценить это как неки некоторый API, но если говорить про настоящий API, какие здесь есть с ним проблемы? Во-первых, он имеет свойство устаревать, и нужно следить за его версиями и его обновлениями. Также для этого API нужно описать дополнительные инструкции, чтобы пояснять агенту, как с ним взаимодействовать и когда, и, соответственно, тоже обновлять вместе с новыми версиями API. И также API часто возвращают очень много избыточной, ненужной для агента информации, которая может забить ему сильно контекст. MCP решает эти и многие другие проблемы, предоставляет единый интерфейс и за собой скрывает все эти сложности, но и приносит также с собой некоторые другие проблемы. Одна из самых животрепещущих - это занимаемый объём контекста этими MCP. Дело в том, что в контекст попадает описание всех инструментов, которые MCP предоставляет. Если этих инструментов много, если у них большие описания и если вы подключили много MCP, вы можете потерять значительное количество вашего контекстного окна. Поэтому сейчас происходят какие-то замены, поиски альтернатив. В частности, скилы в своё время выходили как альтернативы для MCP, так как у них полное описание только по востребованию загружается, а в контексте находится только короткая шапка. Также в clod разрабатываются определённые инструменты, которые позволяют подгружать полное описание для тулов внутри MCP, тоже только по востребованию. И стали популярны отдельные сила интеграции. Это когда сервис предоставляет терминальное приложение с набором команд, которые агент может довольно просто вызывать. Он может к этому инструменту обратиться по хелпу, узнать, какой у него есть текущий список команд, как их вызывать. То есть вариантов подключения сторонних сервисов довольно большое количество. Ну как довольно большое, вот три. Они сейчас все представлены на рынке. Кто-то даже представляет сразу все возможные реализации. Либо MCP сервер, либо какую-то библиотеку скилов, либо какой-то отдельный силай Tool. Можете пользоваться всем, что считаете удобным и уместным. Только помните, что когда подключаете MCP и не используете Tool search от кода, то в контекст он залетает полностью.

Далее, это LCP. Это возможность вашему агенту приобрести некоторые умения от IDE. То есть он может работать с кодом не только как с текстовыми файлами, но уже как с какими-то структурами, у которых есть свои связи и есть свои зависимости. Это улучшает качество поиска, ускоряет его, ваши правки делает более точными и корректными. И у агента есть возможность быстро проверить, насколько правильном состоянии сейчас находится ваш кодовый файл. Поддерживают LCP не все агенты. в Open CodД. Это встроено и доступно по умолчанию без каких-либо дополнительных установок. Вдкод это подключается через плагины.

И говоря про плагины, плагины - это такие бандлы ваших настроек, куда могут включаться и скилы, и их хуки, и команды, и прочее. Это такой аналог unity packджам. Это ваша возможность поделиться настройками с другими. Вы можете их шарить между командой, между сообществом. В ClкоД это сделано довольно удобно. В Open Code это чуть позамороченнее, но стоит понимать, что плагины тоже поддерживаются не всеми агентами. Какого-то общего открытого формата тоже нет. Пока что это большая проприетарная история, но это возможность, которой можно пользоваться.

Про рак я, наверное, рассказывать уже много не буду. Я немножко уже его упоминал. В целом это больше про какое-то окружение для агента, про возможность получить дополнительную информацию, про какую-то документацию, про какие-то базы знаний, в том числе про кодовую базу. Вот все эти индексации, векторизации, это всё сюда. Штука полезная, но напрямую к разработке отношения не имеет.

Также можно здесь упомянуть и structured output. Это инструмент, который гарантирует то, что агент вам вернёт ответ в каком-то фиксированном формате. Чаще всего это JSON. Это тоже не требуется напрямую в разработке, но это часто используется в разнообразных автоматизациях и, в частности, это используется внутри некоторых MCP. Поэтому, если вдруг вы окажетесь где-то вот в этой области, вы можете изучить это более подробно.

Про Sandbox я тоже уже ранее успел упомянуть. Это некоторая изолированная среда, где агент может работать с полными правами без какого-то вреда для вашей системы, для ваших файлов. Это могут быть какие-то контейнеры, это могут быть какие-то виртуальные машины, это может быть какой-то запуск в облаке. Так или иначе, стоит помнить, что Sandbox в любом его виде, он имеет накладные расходы на время, так как нужно контейнер поднять, в облако отправить и также требует дополнительных ресурсов, либо системных, либо финансовых.

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

Предлагаю воспользоваться проектом от Unity. Это sample на match 3 игру. Внутри нас встречает меню, где доступны кнопки выбора уровня. И на каждом уровне нас ждёт геймплей А3 в ряд, где мы можем, а, менять местами фишки, составлять матчи, получать бомбы, использовать бустеры. Есть кнопочка с настройками, возможность вернуться в главное меню и, собственно, всё.

Я также подготовил заранее дополнительный Work 3. Это можно расценивать как копию основного проекта, но когда вы просто копируете папку, то у вас копируется и сам проект, и ваш git репозиторий. И у вас получается, что есть локально две копии одного и того же репозитория. Эти копии могут ссылаться в целом на один и тот же удалённый, но тем не менее это два отдельных репозитория. Work 3 позволяет вам создать копию проекта, но при этом оставить репозиторий одним. То есть у вас может быть много копий одного и того же проекта, вы можете там работать параллельно над разными задачами, но это всё останется одним и тем же Git репозиторием. Вот мы можем это посмотреть, открыть оригинальный проект, это его Work 3 копия. Здесь одна и та же общая история, одни и те же ветки. Единственное, что две копии не могут использовать одну и ту же ветку. То есть, если я в основном проекте захочу переключиться на ветку work 3, мне нужно будет сначала вот в этом репозитории создать третью ветку. включиться на неё, освободить ветку Work 3, и только тогда я в этом репозитории смогу на эту ветку перепрыгнуть. В остальном можете работать внутри каждого из этих проектов с Git так, как привыкли. Обычно Work 3 создаётся на время жизни какой-то отдельной задачи. То есть мы создали Work 3, запустили там какую-то задачу, задача завершена, ветку подлили, Work 3 удалили. Вот так как мы работаем с Unity, Unity постоянно любит что-нибудь перекомпилировать, реимпортировать, загружать там и много разных других неприятных долгих вещей, то бывает полезно просто держать такие Work 3 на постоянке, не удаляя, тем более, что всё равно вы можете там свободно внутри них создавать новые ветки и переключаться.

В качестве агента мы будем использовать Open Code в таком графическом интерфейсе. Не потому, что я обычно работаю именно так, а просто для наглядности. Потому что в этом формате, я думаю, будет нам удобнее взаимодействовать. К тому же он тоже поддерживает Work 3. Вы можете открыть два этих проекта. Open CД поймёт, что они относятся к одному репозиторию и будет отображать их здесь рядышком друг под другом. Это в целом тот сценарий, который нам подходит.

Перед тем, как мы начнём, предлагаю подключить какой-то MCP к нашему редактору Unity. Для этого перейдём на GitHub, наберём в поиске Unity MCP. Взять здесь можно абсолютно любой, какой

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

Устанавливается он достаточно просто. Другие MCP могут устанавливаться по-другому. Здесь всё убирается в то, что мы книруем репозиторий в свой проект. Копируем ссылку, открываем package менеджер, добавляем git repositorй и клонируем. MCP успешно склонирован. Теперь мы можем открыть его в редакторе. Делается это вот здесь и вот так.

Запускать этом CP можно в разных режимах. Мы воспользуемся базовым, локальным http. Нажмём старт сервер. Сервер запущен. У нас пошли какие-то логи, да? Как будто бы всё в порядке. Эту штуку мы сворачиваем.

Далее нам нужно подключить наш MCP к клиенту. Так как мы используем Open CodД, мы можем здесь нажать кнопочку автоматической конфигурации. Единственное, что он законфигурирует мне его глобально. Я бы этого не хотел. Я хочу сконфигурировать эту штуку локально. Поэтому я склонирую название файла. Я склонирую его содержимое, точнее, скопирую, схожу самостоятельно себе его создам. Вставили, сохранили. Теперь нам нужно перезапустить нашего агента. Проверяем. Да, MCP успешно подключён. Этот этап можно считать успешно завершённым. Сделаем победный комит. Настройки я пока комитить не буду.

Следующим этапом в проект хочу перетянуть некоторый шаблон. с настройками для агента. Это пока что моя попытка универсализировать весь накопленный опыт между разными проектами. То есть это некоторая такая выжимка настроек, максимально отвязанная от контекста какого-то конкретного проекта. И задача этого шаблона предоставить какую-то начальную заготовку для того, чтобы наполнить её более конкретными инструкциями и подвязать к более конкретному проекту. Здесь раскиданы внутри файлов разнообразные теги. Здесь вот указаны вот такие блейсхолдеры. И есть файлик в виде workflow инструкций, потому как агенту это всё инициализировать автоматически первично.

Этот проект мы просто копируем и вставляем сюда. Почему это не подключить каким-нибудь субрепозиторием, плагином или чем-то другим? Потому что планируется, что вся эта история, она будет дальше динамически развиваться, абсолютно не привязано к чему-либо другому. Мы сейчас единоразово это всё проинициализируем, и дальше каждый файл, каждая инструкция, каждая настройка, она будет постоянно корректироваться конкретно теми людьми, которые будут работать на конкретном проекте, как и репозитория будет наполняться новыми какими-то документами.

Запустим агента и начнём постепенно знакомиться с содержимом того, что мы сейчас скопировали. Файлы новые у нас уже появились. Вот он даже Redmi того, что мы здесь собрали. Здесь есть некоторое короткое описание по тому, как пользоваться этим шаблоном. Перейдём к инструкции. Мы его склонировали. Теперь нам нужно запустить я и агент с инструкцией для инициализации. Скопируем просто эту инструкцию и передадим агенту. При этом использовать я буду модель Minim Max. Во-первых, потому что это будет быстрее. И во-вторых, чтобы было видно, что даже достаточно дешёвые китайские модели вполне себе могут выполнять поставленные им задачи. Предварительно я выставлю режим планирования, чтобы агент не начинал работу, пока не посвятит нас детали своих намерений. Мы агента. Тут случилась небольшая заминка. Надо было создать новую сессию. Мы каким-то образом оказались вне внесе для Openкода. Вот здесь мы запускаем агента в работу. И пока он работает, мы продолжаем знакомиться с инструкцией.

Сейчас задача агента найти вот все разбросанные теги по всему проекту, проанализировать его контекст, а задать нам какие-то уточняющие вопросы по тем деталям, которые он не сможет обнаружить самостоятельно, провести переименование затем директорий в обозначенном формате, заполнить все всякие плейсхолдеры и в конце подключить все эти настройки к нашему клиенту, к Open-коду. А дело в том, что этот шаблон ожидает вот такую структуру проекта. То есть это репозиторий. Внутри находится отдельная папка под настройки агента, отдельная папка под документацией, где хранятся всякие адрки, архитектурные документации, соглашения проектные, техдоки под геймплейные игровые фичие-нибудь гайды по тому, как делать те или иные вещи на проекте. И вот эта папочка с гайдами - это как раз потенциальная отправная точка для создания новых скилов для агенда. Также в корне лежит отдельно проект Unity. В корне может лежать какой-то проект под backend. В корне могут лежать разнообразные, ну, папка с разнообразными инструментами и сам agents MD, то есть правила для агента. Примерно такой структуры мы сейчас и придерживаемся.

Внутри папки с агентом лежат, во-первых, настроенные субагенты, лежат настроенные скилы. Есть отдельная папка под режимы работы. Это более близкая к Open-коду тема. Мы сейчас тоже посмотрим, как это выглядит. Это отдельные primary агенты, которые не вызываются актестатором автоматически, а выбирают строго пользователя в рамках сессии. Есть папочка SPEC - это отдельная папка, содержимоя которой не индексируется гитом. Сюда агент может складывать любые какие-то промежуточные документации, спецификации и прочие файлы, которые он генерирует во время своей работы. Мы их не храним в гите, они остаются только локально у разработчика. Соответственно, он сюда может приносить любые необходимые файлы, чтобы передать их агенту, не беспокоясь о том, что это случайно отправится другим разработчикам, которым это не нужно.

Уже пошли первые вопросы. Он нам предлагает выбрать название для проекта. Мы берём M3. Далее есть ещё папочка с инсталлером. Это отдельное консолье приложение, которое, по сути, вот все эти настройки подключает к какому-то из поддерживаемых агентов. И делает это таким образом, что он просто создаёт на эти папки а симлинки и перемещает их в папку для конкретного агента. У нас, например, есть папочка под Open Code уже появилась. Это папка нашего вот этого клиента. Здесь хранятся все его настройки. И, соответственно, этот скрипт создаст на каждую из этих папок SIMLink, который будет храниться вот в этой директории этого клиента. При этом эту папку можем также исключить из Gitрепозитория. Она не будет передаваться другим разработчикам, так как они могут использовать какие-то другие клиенты с другими папками. Но за счёт этого инструмента получается у нас есть единая точка хранения настроек, и дальше уже каждый разработчик по своему усмотрению может её спроецировать на нужного себе клиента.

Пошли новые вопросы. Выбираем варианты ответа. Я, кстати, не уверен, что это. Да, это всё-таки платформа пускай будет PC only. и выбираем Open CД. Пока можем посмотреть содержимое самой инструкции. Здесь указание того, какие теги ему в проекте нужно искать. У этап первый он производит сканирование репозитория, ищет теги, ищет оставленные плейсхолдеры. Далее он находит инсталлер, про который мы чуть ранее говорили. Ему там нужно тоже проставить корректные пути. Дальше он пытается определить название проекта самостоятельно, понять его тип, найти версию Unity, поискать по файлам. Если бы он не нашёл, он должен был нас спросить. Дальше он должен был проверить подключённые MCP. Если бы он ничего не нашёл сам, он должен был бы нас спросить об этом, но мы MCP уже подключили, он должен был его найти. затем провести опрос и закрыть те моменты, которые не посвечены явно. Кстати, про бкэнд он нас не спросил, но он, наверное, решил, что его нет. И далее он должен пойти в работу и вносить правки. Перед этим мы проверим, что он нам там напланировал. Такое название, такое описание, такая версия. Нашёл, да, MCP, рен пай, сцена, платформа, клиент. Такое переименование собирается сделать. Заменить плейсхолдеры, запустить installer, предложить подключить нам Open Code в Git ignore и удалить сам workflow. Ну, в целом, в общих чертах это так, это корректно. Отправляем его работать и продолжаем ознакамливаться с инструкцией.

Помимо переименования папок должен плейсхолдеры нам заменить. При этом теги с содержимым корект он не должен трогать самостоятельно. Он должен только вывести в виде списка те файлы, которые требуют внимания разработчика, чтобы он сам сходил туда и обновил своими руками информацию. В конце он должен запустить самостоятельно установщик клиентов. Он поддерживает как сила режим, так и интерактивный. Далее он должен занести в Gitignгor все директории, которые начинаются с точки, и предварительно нас об этом спросить. Но он нас, по-моему, спрашивал, я уже, если честно, забыл. В конце он удаляет файл с инструкциями. Мы ещё вручную удалим Redmi. Его тут быть на самом деле не должно, его копировать не планировалось. И есть вот такой вот коротенький чек-лист. Не то чтобы агент им воспользуется. Но лишним, как дополнительная точка фокусировки не будет. Пока он нам пытается взвать инсталлер, я думаю, что мы можем на него тоже посмотреть. У него есть свой Redmi. Здесь описано описаны детали его поведения, описана доступная API, в том числе для агента, и также перечислены доступные клиенты. Вот такой список клиентов. этот инструмент на данный момент поддерживает. И вот в эти вот, получается, диктори он проводит маппинг оригинальных файлов на семлинке. Ну вот и момент, когда он спрашивает, добавлять ли в Gitignor Directory всё-таки до этого, похоже, у нас не спрашивал. Мы отвечаем ему: "Да, пусть добавляет".

Вот агент закончил работу, вводит нам некоторый отчёт, заменил название, заменил филы. Обновил config, нашёл MCP, заполнил техпаспорт, установил настройки в агента. Вот это, кстати, данные не очень похожи на правду. Скилов там должно быть больше. Там скорее четыре подпапки. Git ignor обновил, удалил workflow. Вот такая итоговая структура получилась. Про то, что надо обратить внимание на файлы, где был тег correct, он решил мне писать. Ну, это лишь повод вернуться к этому workflлоow и его подкорректировать, так как я ещё только работал над этим шаблоном и вообще не уверен, понадобится ли он и будет ли иметь смысл. Это всё ещё в довольно тестовом формате. Можно сказать, что я вот так вот серьёзно в первый раз его использую. Так что посмотрим, насколько вообще эта корректная штука будет работать. Ну вот один момент мы уже успели обнаружить. Проверю, что всё установилось. Нужно, пожалуй, обновить. Да, вот теперь я вижу папки. Agents на месте, skills на полагаю, что на месте. Это должен быть, да, Simлин на папку. Open CД пока ещё, видимо, не научили их открывать. М, документы agent. Всё на месте. Думаю, что можно делать успешно. Комит.

Покажу ещё также, как выглядит установщик для настроек. M3 Agent Installer. Здесь нам нужно запустить, да, вот такой вот интерактивный у него режим. Он показывает нам, какие директории он будет учитывать. А мы не будем удалять предыдущие перенесённые настройки. Запустим вот список клиентов. Давайте для разнообразия подключим для клода. Вот он отчитался, что он создал симлинки. Видим, что появилась папочка с этими же настройками. И при этом в репозитории это не попадает. Ну разве что вот этот вот MD файл, но его тоже при желании можно исключить, добавив Gitignг.

Далее начнём постепенно погружаться в документацию и в сам проект. Здесь внутри есть вот такой вот Redmi. И, наверное, мы его откроем в какой-нибудь идеешке, которая поддерживает схемы. Например, такое обновление недавно вышел для Z. Наконец-то он из коробки начал это поддерживать. Здесь мы откроем вот такой Redmi файлик. И тут есть схемы с примерами работы над различными задачами. Мы начнём с мелких, вот с этой вот простой схемы. Нам здесь достаточно будет сначала что-то спланировать в режиме, а затем перейти в режим выполнения. Ну, в целом, это похоже на то, что мы сделали сейчас, когда инициализировали проект. Только мы теперь сделаем что-то более полезное в контексте Unнити.

Также перед тем, как мы продолжим, нужно агента перезапустить. Это такое неудобство, с которым нужно считаться, когда вы меняете какие-то настройки, подключаете какие-то MCP. Некоторые клиенты требуют перезапуска для того, чтобы их подхватить. Ну, теперь мы можем начать новую задачу. Создаём новую сессию. И первым делом хочется создать в проекте структуру под какие-нибудь тесты, потому что для автономной работы агента тесты не очень необходимы. Необходимо покрывать всю возможную логику разнообразными юнит-тестами, интеграционными тестами. особенно полезны разнообразно nend тесты в контексте Unity, конечно, с ними посложнее, но если вы разрабатываете ещё там backend, энend тесты с агентом делаются просто сказочную. Я предлагаю начать с простых каких-нибудь линтеров. Например, если заглянуть в сам проект, то можно обратить внимание на такую занятную деталь, что все скрипты в этом проекте имеют Namespace Match 3, независимо от того, в какой папке они находятся, на какой глубине вложенности это всё находится, у всех скриптов один и тот жеACE. И как будто бы мы, если будем создавать через агента новые файлы, хотели бы от него потребовать такого же поведения. С одной стороны, можно было бы открыть правила и дописать туда требование, что для всех файлов кода используace match 3, но это будет работать не очень гарантированно, куда надёжнее, чтобы у вас был какой-то тест, какой-то линтер, который агент в конце работы мог бы запустить, получить ошибку, получить по шапке, исправиться и вносить изменения, пока не получат все зелёные тесты. Линтеры удобнее выносить вообще отдельным отниity проектам, чтобы они быстрее, удобнее собирались и запускались. Но мы пойдём по простому пути и сделаем линтеры через обычные юнит-тесты прямо внутри Unity через runner в edit mode.

Пойдём для этого в агенты. У нас, кстати, теперь появился новый режим спек. Это для составления спецификации. Инструкции для этого режима мы посмотрим чуть позже. А пока спланируем работу для агента. Создай в Юнити проекте папку под тесты. Размести там новый ASMD для тестов. Также оригинальный код тоже нужно поместить в отдельный ASMDF, чтобы можно было писать тесты на эту логику. После подготовки папок потребуется создать первый linkнтест, который будет проверять, что все файлы со скриптами всегда и везде используется match 3. И только такой без какой-либо глубины вложенности. Здесь нужно маленечко, конечно, подправить. Здесь он может в этом сйсе придраться к регистру. Мы сразу поставим нужный и отправим печатать. При работе с транскрибаторами в целом очень полезно разминать свою дикцию, чтобы расшифровка прошла с наименьшим количеством ошибок и проблем. Для транскрибации я чаще всего использую Нy. Вот так вот он, а, очень просто выглядит. Работает довольно быстро, довольно просто. Мне используется вот такая вот модель. Не всегда стабильно он показывает работу. Временами имеет свойство просто вылетать и переставать записывать. Но в целом с этим жить можно. Делает он, к счастью, это нечасто.

Пока он пытается здесь что-то уже делать с нашим проектом, мы можем посмотреть на наш базовый Agence MD. Здесь вот такое вот куцее описание, которое, по-хорошему нужно бы, конечно, обновить и дать больше контекста для агента, что это за проект и для чего описана базовая структура и ссылки на то, куда дальше можно агенту заходить для поиска тех или иных контекстных вещей. заданы краткие обозначения для каких-то особенных директорий, которые упоминаются в инструкциях, потому что там указывается не полный путь, а вот такие короткие сокращения. Это сделано для того, чтобы можно было вот создавать такие шаблоны и отрывать от какого-то проекта. Но вообще, конечно, лучше работает, когда указан прямо конкретный путь до конкретного файла или конкретной папки. Здесь также есть какие-то базовые правила работы, что нужно следовать адааркам, нужно следовать конвенциям, учитывать код конвеншены, перед каждой задачей проверять наличие скилов и субагентов, изучать наличие имеющейся документации, обновлять её после задач, запускать, а этапы рефакторинга и проверка качества. И также требования на запуск юнит-тестов. Само собой, все эти требования, они от модели к модели выполняются с разной степенью успеха. Поэтому здесь лучшими вашими друзьями будут какие-то автоматически запускаемые юнит-тесты, какие-то всякие подключенные хуки, будь это хуки у самого агента или хуки в гите. В общем, всё, что вы можете как-то автоматизировать без участия агента, повышает надёжность всей вашей системы.

Итак, он тут что-то у нас уже начал делать, хочет что-то даже уточнить. Он нашёл папку. Адф не нашёл, само собой, его там нет. Nunit есть. Это так. Предлагает вот такую структуру. В целом меня она устраивает. Вот такой линтер он предлагает создать. Какие-нибудь вопросы есть? Уточнения? Давайте попробуем ответить на каждый вопрос. О, кстати, я ошибся. Я хотел. Кстати, в каком-то из недавних обновлений они добавили возможность откадываться к предыдущему сообщению только по команде, но и вот по таким кнопочкам снизу. Раньше такого не было. Ну, не то, чтобы я слежу за обновлениями этой гуишки, но приятно наблюдать за тем, как она трансформируется в что-то более-менее пригодное для использования. Я пока что перепроверю его домыслы. Я, кстати, не открывал эдиторные скрипты. Ну да, тут такой жеace. Нормально. Ну, как будто что-то похожее на правду. Я не буду внимательно сюда вчитываться. Но когда вы работаете с агентом на реальном проекте, где вы отвечаете за качество генерируемого кода, вам, конечно, нужно проверить каждую строчку и ещё не один раз.

Пока агент работает, мы можем медленно просматривать имеющийся наш багаж настроек. Они достаточно долго создавались. Мы начинали обустраивать агента ещё с момента, когда были доступны только правила, пользовались только этими правилами, интегрировали потом Memory Bank, там всякие Wordflow создавали. И по мере появления тех или иных инструментов здесь этот контекст, вся эта информация, она растекалась по другим файлам, по другим настройкам. А когда-то их было больше, когда-то их было меньше. Мы пробовали такие подходы, сякие подходы. То, что приживается, оно остаётся. то, что не приживается, оно уходит или заменяется другим. Поэтому последство очень итеративное. Это тоже далеко не финальная версия, не финальный вид того, чем мы пользуемся сейчас и то, чем будем пользоваться дальше.

Начнём, наверное с папочки Modes, как самой малочисленной. Здесь вот сидит такой агент для создания спецификаций. По правам он не сильно-то и ограничен. Он может как читать, так писать, так и создавать. Единственное, что здесь где-то должно быть написано, что он не должен редактировать код. Да, вот здесь он должен заниматься только генерацией спецификации, только генерацией документов. Вот только вот в такой вот директории. Здесь у него описаны задачи по тому, как он должен работать. Он работает у нас в цикле. Сначала он получает заброс от пользователя. После того, как он его получил, он его обрабатывает, пытается проанализировать текущую предметную область, запускает скилы по эксплорингу, по какому-то RНD для задачи или для бага, в зависимости от того, какого типа запрос отправил пользователей. Анализирует это всё, пытается заполнить какие-то пробелы в понимании. Если есть какие-то моменты, на которые агент не может найти ответ самостоятельно, он задаёт вопросы у пользователя. И в таком вот цикле вопросы, ответы, уточнения, запись, он работает до тех пор, пока ему не станет понятно всё, что необходимо для решения задачи. Когда все моменты прояснены, этот агент, он создаёт финальную спецификацию, сохраняет в папочке SPEX и далее пользователю предлагает перейти на следующий этап этого большого workкфлоу, который мы далее посмотрим. И этот следующий этап начинается с вызова скила на построение плана. То есть даже когда пользователь не знает сам нужной последовательности, ему достаточно выбрать нужный для него режим. И далее агент будет сам подсказывать каждый следующий шаг. Ниже есть всякие ограничения по выдаваемому формату, что он должен учитывать, что он должен не учитывать, какие есть критерии для оценки качества его работы, какие элементы должны содержаться в итоговой спецификации, как файл должен называться, где должен находиться и примеры работы вот с таким вот агентом. Хотя в формате Онкода вот этот кейс вызова через собаку не очень актуален, так как этот, а, этот агент в опенкоде вызывается как отдельный режим.

Агент тут чего-то успел уже наделать и составить каких-то отчётов. Нам по-хорошему бы здесь, конечно, прочитать и ознакомиться совсем более внимательно. Но так чисто верхний уровень у него выглядит как будто бы ок. Здесь даже какой-то есть режим дифов. Вот review тут насоздавал папок. Вот смдфки наши. Вот он. Ну выглядит как что-то похожее на правду. Больше никаких тут скриптов нету. В редакторе тоже всё как будто бы ок. А вот он нашлинтер, даже уже запущенный. Он там где-то, видимо, MCP ходит. А, ну да, да, вот даже MCP смог сам вызвать. Всё, тут понапроверял. Пробуем запустить самостоятельно. Да, выполняется, работает. Ага, вот он эдитор. Вот он Bus Game Editor. Вот они скрипты. О, Editor. А это что за Эдитор? Перенёс, что ли? А, ну да, вот смотрите-ка, он отсюда выдернул и перенёс на уровень выше. Ну, пускай, в целом, не страшно, не против. Возможно, так было лучше. И вот Амдеф. Всё ок, всё на месте. Что ж, ну, задача похожа уже решена. Это это кто такой? Это что-то, видимо, я случайно где-то когда-то успел тыкнуть. На это мы отсюда убираем. Вносим, вносим, вносим, вносим. А вот это всё вносим. Зафиксировали.

Теперь мы обновим наш work 3, сделаем rebase на мастер и попробуем поработать параллельно. Создаём новую сессию в основном проекте и создаём новую сессию в Work 3. Тут два момента, которые бы хотелось проработать. Момент первый. Я уже отметил, что сейчас в коргеймплее перемещать фишки можно только по свайпам. Но вообще обычный сценарий управления также включает в себя кейс, когда мы нажимаем сначала на фишку, потом нажимаем на соседнюю, и происходит перемещение. хотелось бы тоже такой сценарий работы добавить в эту игру. И момент второй, я забыл отметить, что в этом проекте используется UI Tool Kit. И это довольно любопытная возможность продемонстрировать, что агент в целом неплохо работает с Uйкой именно в Тулките. Ну, потому что UI Tool Kit - это такой код ориентированный способ верстать интерфейсы. А с кодом LLM работает сильно лучше, чем с абстрактными префабами внутри проекта. Понятно, что прифаба - это тоже ялы, это тоже как бы текстовые файлы, но в этих ямлах очень много всяких неявных ссылок, много всяких гуидов, много всяких циферок и которые не имеют какого-то логического значения, если просто смотреть в этот файл. В такой структуре агент, конечно, путается. Там чем больше ваш файл, тем больше шансов, что он его просто сломает. Можно с другой стороны работать через MCP, но опять же в таком формате агент не сверстает там какой-то сложный интерфейс, где много уровней выложенности и есть какие-то связи и ссылки. Что-то элементарно, возможно, у состряпает, но какие-то прямо реально продуктовые вещи сделать он не способен. Поэтому один из основных подходов, если у вас обычные UI построены на гем обжектах, это подготовить некоторые конструктор для агента, то есть подготовить какие-то заранее созданные прифабы с уже готовыми свёрстными элементами. И вот из таких вот блоков, из такого конструктора агент вполне способен собрать какой-то UI. И здесь, чем крупнее вот эти ваши блоки конструктора будут, тем выше вероятность на успех. что чем они будут меньше, тем больше будет и глубина вложности, тем больше будет всяких связей, тем больше риск того, что агент наделает каких-то ошибок. Ну и MCP сами по себе они очень стабильно работают, они имеют смысла свойства тоже отваливаться, перестать отвечать. В то время как UI Tool Kit намного проще в плане использования агентом. Они не очень хорошо пока умеют с ним работать, но если вы предоставите им необходимый контекст, какие-то инструкции, создадите свои какие-то навыки, опишите основные тонкости и нюансы работы с UI Тулкитом, то они могут в таком режиме, с таким инструментом давать намного более значимый и весомый и сложный результат. Но возможность возможности использования UI Толкита в продуктовой разработке в реальных проектах, конечно, они ещё местами под вопросом, не везде его можно применить.

Итак, вернёмся теперь к нашим задачам. Сейчас мы находимся в Work 3. Здесь, я думаю, что мы попросим агента добавить на главный экран кнопку с настройками, такую же, как в меню Core GameПе. Переключимся сначала в режим спецификации. А его у нас здесь нет. Нам сначала нужно в work 3 вызвать наш установщик. Установили. Нам потребуется опять перезапустить. Теперь должен быть доступен режим спек. Да, отлично. В меню основной игры внутри уровня есть кнопка открытия меню настроек, где отображаются ползунки громкостей, а также кнопка возвращения в главное меню. Необходимо в главном меню добавить аналогичную кнопку нажатия на которую приводит к открытию меню настроек, но с той лишь разницей, что если это меню открывается на главном экране, то там отсутствует кнопка возвращения в главное меню. Остальные все элементы и ползунки остаются на месте. При этом окно настроек внутри самой игры непосредственно оно меняться не должно. Кажется, что всё корректно.

Пока он думает, мы переходим в основной проект и здесь просим его поработать над фичой, связанной с перемещением фишек. Сейчас в основной игре внутри уровня перемещение фишек происходит только свайпами. Нужно добавить новый способ управления, при этом оставить свайпы, как они были, но добавить возможность перемещать фишки кликами. То есть мы нажимаем, кликаем на какую-то фишку, она выделяется каким-то визуальным образом, каким-то индикатором. Если мы кликаем снова на эту же фишку, ничего не происходит. Индикатор также продолжает гореть. Если мы нажимаем на соседнюю фишку, а соседняя - это либо слева, либо справа, либо сверху, либо снизу, то происходит обмен местами этих фишек. Если же мы кликаем на какую-то фишку по диагонали, то такие фишки соседними не являются, обмен не происходит. Либо же, если мы кликаем на какие-то дальние удалённые фишки, также обмена не происходит, но при этом происходит смена. фокуса. Теперь активной выбранной фишкой становится другая, ту, на которую мы кликнули. При этом, если мы кликаем где-то вне игрового поля, вне фишек, не по фишкам, то выделение снимается со всех текущих фишек. Для визуального выделения можешь использовать любой доступный тебе элемент внутри игры. Это, возможно, не самые корректные запросы. Я не то, чтобы успел уделить время на проработку своей идеи, своих мыслей, поэтому отправим как есть. Посмотрим, что из этого получится. Пока что я продемонстрирую а то

Чем мы сейчас займёмся? Мы сейчас пойдём по большому циклу работы над задачей. Это вот эта вот большая схема. Мы сейчас находимся на этапе спек. Здесь агент может опционально провести какой-то эксплоринг, какой-то R&D. На этапе эксплоринга он соберёт информацию по контексту, на R&D посмотрит, поищет возможные пути решения. Это то, что мы обсуждали, а, когда смотрели на документацию.

В результате всего этого он выдаст нам некий спекdфайл, который мы затем через навык построения плана разобьём на отдельные задачи. Этот план запишется в отдельный marкдау документ. И этот уже Markдаун документ мы передадим далее в работу, где агент внутри по каждой задаче пройдётся и выполнит цикл имплементации, документации, тестирования, ревью до тех пор, пока все задачи не будут выполнены.

У нас уже успел отработать один из агентов. А который из них? Вот этот, с кнопкой настроек. Он здесь что-то, возможно, хочет нас спросить. Будем отвечать ему на вопросы, как будто бы могли ему ответить на всё, делая на своё усмотрение. Но агенты такое поведение тоже не сильно любят и, как правило, могут выбрать вариант, который, ну, просто физически может быть не реализуем, и узнают об этом, когда упрутся в какую-то определённую стену. Поэтому здесь поможем толкнуть его в какую-то определённую сторону.

Давайте, мне кажется, пойдём по пути наменьшего сопротивления. В первом вопросе мы ответим А. Надеюсь, он поймёт, что я хотел сказать. Во втором вопросе: где именно? В верхнем правом углу. Внизу пусть будет. А внизу. Третий, да, точно так же. Четыре компонент. М, тут я не знаю, пусть изучит.

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

Вот работают оба агента. Пока они работают, мы можем заняться изучением дальнейших документов. Мы успели рассмотреть режим specifire. Теперь перейдём к конкретным скилам. Здесь они выделены на отдельные от контексты. То, что касается Project - это папка, где хранятся скилы, которые относятся к конкретному проекту и который, ну, вообще никак не имеет смысла куда-то переносить и выделять какой-то универсальный шаблон. Здесь оставлено три в качестве примера, что здесь можно настроить скилл по тому, как запускать тесты в Юнити, как запускать тесты у вас на бэкэнде, как можно подготавливать всякие отчёты для версии и многое-многое другое. Как правило, это самая многочисленная папка. Здесь хранится больше всего разнообразных скилов.

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

Во-первых, агент сам определяет, а контекст того, что нужно проревьювить, текущую ветку, какой-то указанный комит, диапазон комитов или не комичные изменения. А на основе этих данных он запускает определённые скрипты, которые выдают список файлов для реv. А там зашита логика по фильтрации. То есть он фильтровывает всякие пройты, всякие текстуры, всякие атлас, вот этот всё то, что смотреть вообще не нужно, оставляет только файлы кода и настроек. Метафайлы тоже игнорирует. Всё равно там агент с ними работает не самым лучшим образом.

А следующим этапом он извлекает дополнительную информацию по комитам, извлекает из них какие-то комментарии, какую-то метаинформацию, которая тоже может быть для агента полезна. И далее он со всем этим, а, работает, а, запускает в отдельных субагентах какие-то блоки, какие-то отдельные скоупы логики, сверяется с нашими конвеншенами, сверяется существующей документацией, существующими адарками. Здесь есть всякие пункты, которые фокусируют его на особо важные детали, которые мы сюда закидываем по мере необходимого, по мере косяков агента. И в конце выдаёт отчёт в указанном формате.

Также в суммаризации и в написании тех доков есть, а такая хитрушка. И мы добавляем вот такие вот пометки в файлы кода. Таким образом, мы связываем конкретные файлы кода с конкретными документациями. Здесь указывается просто название документа, не полный путь до него, потому что файлы могут перемещаться как файл документации, так и файлы с кодом. А агент в целом умеет хорошо грепать по названию этих файлов. И когда агент забегает в какой-то из из классов и если видит здесь такую пометку, при необходимости он может очень быстро найти нужную документацию и расширить свой контекст по знанию этой предметной области.

Тем временем оба агента уже закончили анализ. Этот агент у нас занимается перемещением. Он уже создал нам спецификацию. Ну, в общем, в чертах тут примерно всё верно. По-хорошему, нам здесь нужно ещё проанализировать спецификацию, которую он создал. Она достаточно объёмная в каком-то смысле получилась. Вот тут даже какая-то диаграмма есть. Её, наверное, лучше удобнее будет смотреть вот в этом месте. Угу. Угу. Угу.

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

Здесь что происходит? Тут у нас прошёл обрыв. Пусть продолжает выполнение. Теперь начинает задавать вопросы, на которых у меня нет ответа, так как я вообще не погружён в контекст проекта абсолютно, поэтому так честно ему отвечу. Вечу ему антипадарными ответами. Конечно, возможно, в третьем вопросе он имел в виду вот те слайдеры с настройками, но мне кажется, так бы он и про них и написал явно. Тут какой-то, возможно, нюанс в самой вёрстке.

Тем временем другой агент тоже уже поработал, создал разбиение и создал даже какой-то план. Какие тут задачи? Добавить поле логика swipe, prifп тесты refфакторинг верификация. Этот этап тоже нужно провалидировать самостоятельно. Открыть файл с планом. Это даже, наверное, будет проще открыть тоже в редакторе. Тут наверняка будут какие-то интересные схемы. Вот он первую задачу отдал разработчику Unнити. И вторую, и третью, и четвёртую, что логично, и пятую, и шестую. Её только 10 придал кулашнику. Такой вот граф зависимостей. Очень, кстати, интересно. А, возможно, это, конечно, как косяк самой мермой схемы, так и косяк Зеда, так как веча это у них прендерингу мермейда довольно свежая. И как рисуютмейсхемы другие редакторы, мне пока нравятся больше. Так, проверю вообще, насколько тут это корректно нарисовано. Ну, вообще, кстати, здесь схемка-то довольно чистенькая, как будто всё-таки проблема в рендеринге. Поверим ему, что всё здесь нормально. Перед тем, как мы отправим его экзекю, переключимся на билд, чтобы у него было чуть больше прав. Отвечаем: "Да". И пусть идёт работать.

Пока другой агент у нас продолжает раздумие, мы можем продолжить знакомиться с этим проектом. Мы посмотрели в целом на скилы база, как они устроены, как они раскиданы. Вот здесь в этой папочке workflow описаны основные скилы, которые участвуют в той схеме, которую мы рассмотрели. Эторинг, это поиск решений для багали для задачи. Это довольно похожие, на самом деле, навыки, но всё-таки у них есть некоторые отличительные детали. Есть построение плана и выполнение плана. Допустим, перейдём сюда. Здесь тоже есть какие-то ограничения, есть тоже указания, что нужно сохранять все документации только вот в эту папку. Есть вот такой вот а плейсхолдер для подстановки нашего аргумента, то есть того, что мы напишем после вызова скила вручную. Этот навык ожидает, что у нас уже будет какой-то составленный план вот в этой директории. Далее он его изучает, определяет зависимости, кто за кем следует, запускает субагентов для каждой отдельной задачи. Внутри идёт вот по такому вот а циклу. Есть также указание, на какие скилы нужно обращать внимание при работе по тем или иным этапам, чтобы у агента была выше вероятность их вызова. Также есть описание того, как обрабатывать проблемы, как обрабатывать завершения, как репортить по текущему прогрессу. То есть там в составленном плане у нас был маленький тасктрекер в конце, он там отчитается по текущим задачам. По скилам я думаю, что примерно здесь всё. Детально каждый рассматривать особо смысла нету.

У нас там уже отработал какой-то из агентов. Я слышал по звукам. Готово. Спецификация сохранена и готова к исполнению. Здесь тоже нужно бы с ней, по-хорошему ознакомиться, но мы проверим, что она вообще хотя бы есть, и она действительно есть. Так. Так. Меню settings return button туда-сюда. Вот функциональные требования указал. Визуально совпадать. Размер изображение внизу экрана справа. Button settings. Второе функционое требование. Есть открытие настроек, закрытие. Да. Так, да, даже есть какие-то нефункциональные требования, да, как будто бы. Да, логично. Здесь даже какая-то мейд схема. Я думаю, что рано или поздно в Open Cod строят рендеринг и такого. Кстати, из удобного в этой игуишке есть возможность оставлять комментарии. Например, нам что-то не понравилось. Мы написали вот так, нажали комен, он сюда это подцепил. И здесь можно накопить вот таких вот, а, более точечных указаний к документу и отправить их следующим запросом. Мы ничего из этого делать не будем, а мы только лишь подтвердим, что в целом выглядит как будто бы похоже что-то на правду. Да, пусть создаёт дальше план работы над задачей. Надеюсь, там не будет ошибок.

Нам осталось рассмотреть субагентов. Их здесь немного. Здесь буквально их, ну, не буквально, их прямо точно здесь четыре штучки. Это отдельный разработчик подюнити. Здесь есть краткий список того, какие скилы этот субагент может использовать. точнее, не может. А на какие скилы ему имеет смысл обращать более пристальное внимание? Есть перечисление каких-то основных моментов, на которые агенту нужно обращать внимание при работе. Здесь нет каких-то конкретных инструкций, каких-то указаний. Это именно что, какие-то такие теги, какие-то точки фокусировки. Укэнд девелопера похожая история. Есть какой-то набор навыков, на которые нужно обращать внимание. Есть какие-то целевые моменты, связанные со стеком и контекстом работы.

Технический писатель занимается тем, что создаёт документацию и всякие пометки к коду. Здесь у него основное ограничение, что он не может редактировать код. Если бы техписатель не умел добавлять вот такие вот краткие описания к самому коду, то здесь бы имело смысл также тул для редактирования поставить в флс, чтобы он вообще в целом не мог пойти и редактировать файлы кода, а мог только создавать новые документации. Но так как здесь немножко чуть шире зона ответственности, то здесь стоит также переключатель в true. И это повышает риск того, что он может в какой-то момент пойти и начать править ваш код. Вероятность не прямо высокая, но она тем не менее всё равно есть. Если для вас это важно, можно поделить их на два или вообще убрать у него такую ответственность, связанную с добавлением пометок к коду непосредственно. Испециалист. Тут тоже довольно общие инструкции, что ему нужно делать, что ему делать не нужно, на что обращать внимание. А более конкретные какие-то положения у него описаны в соответствующих скилах. Опять же, это всё корректируется точно под ваш проект. Вы можете сюда запихать более детальный, более точный контекст, какие-то важные моменты, на которые нужно обращать внимание, возможно, какие-то папки, куда нужно ходить и дополнительно получать какую-нибудь информацию, например, какие-нибудь сводки, репорты и так далее. Это всё настраивается и дополняется.

Тем временем у нас закончили работу агенты. Этот у нас чем занимается? Он занимается кнопкой меню. Он составил нам план. Он здесь пока не отображается. Нужно обновить. Да, вот он наш план. Действительно есть. А задача раз, задача два, задача 3, 4, он разошёлся. Кстати, странно, что он рефакторинг назначил специалисту. Проверить код. Бла-бла-бла, бла-бла. А это только проверка. Это не рефакторинг. Это он терминологию перепутал. Вот этот момент тоже как будто можно через инструкции подтюнить. Юниттесты, документация. О, документация даже появится какая-то. Ну, типа похоже на правду. Тоже доверимся, не будем растрачивать время. Выставляем build и отправляем его работать.

Другой агент работать ещё не закончил. Мы видим, что он запустил здесь параллельно первую и четвёртую задачи, пото что, видимо, там по зависимостям это было позволительно. Тогда тогда вторая зависит от первой, третья тоже зависит от первой. Вот они параллельно и работают. Причём они уже отработали. Мы можем сюда зайти, кликнуть, посмотреть, что тут происходит. И теперь запускает вторую и третью. Да, да, да. Ну, процесс, процесс идёт, работа кипит. Мы пока смотрим на проект дальше. И здесь как будто бы мы уже основные все моменты рассмотрели. Осталась только что папочка docs. У нас здесь есть техпаспорт. Его желательно бы тоже заполнить. Здесь он указал то, что мы передали агенту при инициализации. Это версия движка. это MCP используемый Render Pipeline, стартовая сцена и всякое остальное. Ну, и, наверное, всё. В общих чертах это примерно выглядит так.

В целом вы можете начинать работу в каких-то новых проектах, используя готовые фреймворки по типу Open Spec или Spec Kit. Они устанавливаются, ну, примерно похожим образом. Вы открываете терминал, устанавливаете какие-то зависимости указанные там или клонируете или клонируете репозиторий, запускаете, выбираете клиент, которым вы собираетесь пользоваться, и эти фреймворки открывают или создают папку для этого клиента, складывают туда какие-то презаготовленные навыки, субагенты и прочее. И вы также можете заходить в ваши ваш клиент, выбирать нужные и запуская соответствующие пайплайны, которые тоже описаны на странице репозитория. Примерный смысл работы у них такой же. У них очень похожий цикл. То, что было продемонстрировано у нас здесь, в этой документации, это не что-то уникальное. Большинство фреймворков работают очень похожим образом. Единственное, что до такого формата работы мы дошли самостоятельно, проходя и итерациями по всем вот этим веяниям и идеям, проблемам, накопленным беспрактисом. И так получилось, что не мы одни шли в эту сторону. И вот мы, ну, если не все, то многие оказались в этой точке, где процессы построены примерно вот по такой схеме. И теперь вот эта схема, она будет постепенно автоматизироваться. Всё большее количество шагов будет выполняться агентами автоматизировано, предоставляться сразу же из коробки.

Например, кто пользуется кодексом, могли заметить появление отдельного режима для планирования, где агент как будто бы в целом как раз забирает на себя вот эти вот первые фазы в левой части. Он тоже проводит итеративный опрос пользователя и пытается закрыть пробелы в понимании и затем строит более подробную спецификацию. Далее он тоже её в тихаря где-то внутри разбивает на задаче и распределяет по своим субагентам, которые создаёт самостоятельно. Пользователь процесс этот вообще не контролирует, тоже как-то там выполняет, они как-то работают, они внутри проводят тоже итерации ревью, итерации тестирова тестирования. Всё это в этих циклах параллельных крутится, потом собирается, проводится также общее ревью, общее тестирование, но только всё это реализовано не вот таким вот ручным набором настроек, а вшито прямо в сам клиент, в сам агент и доступно прямо из коробки.

И как будто бы сейчас самая большая проблема - это подружить агента с Unнити, чтобы он мог оперативнее и удобнее вызывать всякие проверки, всякие тесты, получать удобнее логи, чтобы MCP работало стабильнее, чтобы рефреш проекта происходил быстрее. Юнити как будто бы тоже сами это понимают. Они там и то свой MCV пытались делать, то вроде как сейчас собираются делать свой C подключения. Также они тут нацелились на то, чтобы пересадить Unity на Core Cillar. Это в теории должно сильно упростить этап компиляции проекта. Ну вот как будто бы всё идёт к тому, что юнити нацелены на то, чтобы сделать свой движок более AI friendendly.

Тем временем агенты у нас всё ещё работают. Бывает также полезно поглядывать за работой агентов. Вот, например, здесь один из этапов работы. Написание юнит-тестов. Вот здесь агент создал файлик, пробует запустить через скил. Там, кстати, скилл на самом деле мёртвый. Он как пример просто оставлен. Там описания-то как такового нету. А, но тем не менее вот он запустил обновление refrh Unity через MCP, запустил тесты через MCP, понял, что что-то пошло не так. прочитал консоль, нашёл две ошибки. И если открыть Юнити, там правда эти ошибки есть. А он тут что-то запускает, я уже не покажу. А нет, покажу. Вот они, эти две ошибки. Он их сам прочитал, сам пошёл их исправлять. И судя по тому, что здесь идёт фреш, он уже их исправил. И это всё без моего участия. Вот поэтому очень важно обустраиватьб, чтобы агент мог сам себя корректировать, сам получать какую-то информацию по тому, что происходит в другом агенте. Тоже какие-то интересности происходят. Да, вот он проводит ревью. А перед этим, да, вот он провёл разочек ревью, сам нашёл у себя какие-то проблемы. И, судя по описанию, действительно, они достаточно важные. Пошёл их, исправил. Проводит теперь повторное ревью.

Ну, из-за того, что это у нас отдельный work 3, там, во-первых, не запущен instance Unity, а, во-вторых, даже если я его запущу, то, скорее всего, наш запущенный MCP сойдёт с ума из-за двух открытых редакторов одновременно. Поэтому рисковать не будем и будем жать в голове, что вот в этой ветке агент не сможет проверить себя на выполнение тестов, на вообще компилируемость своего кода. Это тоже один из неприятных недостатков Unнити. Поэтому, если что-то можно вынести за пределы контекста unнити, какие-то отдельные проекты, то как будто бы имеет смысл этим заняться, потому что тогда агенты могут быть сильно более автономными, совершать быстрее итерации, не быть привязанными к каким-то сторонним MCP, и вы можете иметь большое количество параллельно реальных полноценно работающих Work 3.

Позволю себе ещё короткий комментарий по поводу MCP и разных Work 3. Это, конечно, сильно зависит от конкретного MCP сервера, который вы используете, но довольно часто поднятый MCP сервер, он закреплён за конкретным инстансом редактора Unity. И здесь, в конфигурации, вы можете встретить адрес и порт, на котором запущен MCP-сервер. И ровно этот же адрес и порт указан в конфигурации для AI-клиента. И, соответственно, если вы хотите одновременно поднять несколько инстансов редактора Unity, для каждого запустить свой MCP-сервер и дать возможность разным инстансам AI клиента работать независимо с разными редакторами Unнити, то вы можете конфигурации задать разные порты для каждого редактора, для каждого клиента конфигурации также этот порт учесть, и тогда у вас будет возможность параллельно работать с разными редакторами. не мешает друг другу.

Так, ну что ж, оба агента закончили свою работу. А первый агент, который занимался управлением, он задачей со своей справился. Единственное, что у него отвалилось управление свайпами. Об этом я ему сообщил. И так как у нас не было возможности, не было настроенных инструментов, которые позволили бы агенту самому запустить Юнити и там пытаться с ней как-то провзаимодействовать, то этим пришлось заняться мне. Но если бы такой инструмент был, агент бы сам пошёл бы и проверил и столкнулся бы с этой проблемой. И после того, как я ему это написал, он быстренько нашёл проблему, внёс необходимые корректировки. И на этом задача полностью завершена. Он даже написал, а, юнит-тесты на логику. Они даже выглядят довольно аккуратно. Здесь внутри он внёс такие вот правки. Он добавил прифаб для индикатора выделения. И вот тут ещё внёс вот такие корректировки. Я подсмотрел в историю, он нашёл код конвеншены, сложенные у нас, и из-за этого начал править формат, потому что там написано, что мы всегда явно указываем модификатор доступа. Вот у нас модификатор доступа пошёл добавлять в этот файл. Здесь он добавил недостающую логику. сюда добавил, сюда немножко добавил, сюда тоже добавил вот такие вот а ифы довольно обширные, но стоит понимать, обратите внимание на нумерацию строк. Это в целом здесь файл такой довольно спагетвидный, поэтому таким большим ифом удивляться не стоит. Это в целом выдержано в стиле этого документа. Вот такая получилась свеча. Она теперь полноценно работает. Вот так вот. Видим, что здесь никаких кнопок со настройками нет. Это отдельная ветка. Здесь мы занимались только корректировкой управления. А вот наши свайпы, они в целом работают. Тут можно ещё доколупаться до него, что когда начинается свайп, у нас появляется вот этот эффект выделения. Ну, это уже мелочи. Свайпы на месте. Клики также вот работают. Можно кликать, можно кликать за пределы, чтобы выделение снимать. Выделение по другим переносится, а если рядом кликаем, то они меняются местами. То есть здесь задача выполнена корректно. Можно что-то допольшить, можно оставить как есть. Код в целом достаточно, ну, скажем, чистенький. А тесты тоже на месте. Всё выполняется, всё работает. Он сам всё проверил. Так что здесь ему можно выставить, ну, допустим, девять баллов. Этот косячок за выявляющийся при свайпе подсветку мы снимем. Но с другой стороны, мы от него явно такого требования и не ожидали. У нас спецификации ничего этого не было написано, поэтому, что вы просили, то он и сделал.

А вот вторая задача. Здесь всё сильно сложнее. Он её довёл до конца, как смог. Но у него не получилось. Здесь есть такие проблемы, то, что он работал отдельно. Он работал без редактора, он работал без MCP, он работал вообще максимально оторвано от какой-либо возможности получить обратную связь. Я здесь ему понадоправлял ошибок, которые мне выдавала Unнити. А ничего пока не получается. И в целом он пошёл ещё в ту сторону, что ему необходимо здесь, а, было что-то добавить на сцену. Вот он здесь повесил компонент отдельный. Нужно было ему ещё добавить корректно ссылки, связи, то есть какие-то элементы со сцены протянуть в нужные поля этого компонента. Само собой, сам сам он в ямол не смог, так как тут вот такие вот гуиды для него малопонятные. MCP у него был отключен, ничего он сделать сам из-за этого не смог. Здесь достаточно тоже такой не очень симпатичный код. А, поэтому я не стал с этим разбираться. Здесь задача сказать, что он не справился, но, но я здесь попробовал параллельно пойти по другой ветке. Мы там, когда с ним обсуждали эту задачу, там была возможность или переиспользовать то, что есть, или создать какую-то новую копию, новую реализацию. И вот если его пустить по ветке, где он создаёт просто копию того, что есть в свободном формате, то получается вот такие вот правки. Всего два файла. Всего два файла. Вот сюда он внёс корректировки. Вот такие вот здесь корректировки. И вот сюда в разметку он тоже внёс такие изменения. И всё. И действительно, на главное меню добавляется вот эта кнопка. Всё работает. Я сейчас даже пробую эти правки применить и показать. Единственное, что я отмечу, что вот в этой в этом неудачном прогоне помимо основной работы он ещё сгенерировал нам документацию самостоятельно, то есть описал всё, что было необходимо, воспользовался навыком написания техдока, выполнил требования, которые там были указаны, поддержал структуру, которую мы придерживаемся, оставил даже диаграмму состояний и обновил Redmiфайл, добавил в табличку. То есть здесь, с этой точки зрения, он отработал классно. Возможно, где-то в спецификации было написано, что нужна документация. Так как мы её не читали подробно, я не знаю, но вот именно задачи он, конечно, не смог. Поэтому давайте мы это дело отменим и применим то, что я сложил в СТШ. И вот он наш редактор. Единственное, что я генерировал эту итерацию без той спецификации, где были другие требования. мимо всего этого пайплайна довольно быстро, коротким запросом. Поэтому кнопочка у нас не внизу, как мы до этого договаривались, а вот здесь вот наверху он решил её поставить. Тем не менее, вот эта кнопочка, вот она вот здесь эти ползунки, как видим, это отдельное совершенно меню. Оно по-другому даже выглядит немножко. Сейчас мы в этом убедимся. Тут подвигали, потрогали. Давайте вот сюда. Это вот так. М. Зайдём в игру. Открываем меню настроек. Здесь есть вот кнопочка. Ползунки все тоже на своих местах. Как мы это там поставили, так они здесь и есть. Давайте это уберём сюда. Вернёмся в главное меню. Нажимаем. Да, вот они здесь. И, собственно, всё, да? То есть мы пошли совсем, ну, не совсем, пошли по другой ветке исполнения, по другому пути, приняли другой выбор, и реализация стала сильно проще, чем вот получилось в первый раз. Ну и также в этот раз уже генерация происходила с запущенным Юнити, с поднятым MCP. То есть у агента была возможность себя каким-то образом проверить, но судя по тому коду, который он оставил, не то чтобы это сильно ему было нужно.

Что ж, ну вот мы успели параллельно поработать над двумя задачами сразу. Мы, конечно, сильно схалтурили, сильно срезали углы, не читали ни спецификации, ни планы, не пытались даже в проекте разобраться. И многие решения делали либо на бум, либо отдавали на откуп агенту. И в целом, вот к какому результату этот нас привело. Одна задача в целом в рабочем состоянии получилась, а другая не получилась совсем. И только лишь потому, что мы не были в контексте проекта и не смогли направить агента в нужную сторону. Тем не менее, агент нам дал возможность проверить несколько вариантов решения, несколько гипотез. То есть мы сгенерировали на одну задачу два разных варианта решения, а проверили каждый из них, поняли, что один - это тупиковый путь, а второй вполне себе рабочий и оставили его себе. И в том числе это как раз та возможность, которую может там дать агент - это проверить сразу же много разнообразных вариантов решения, а, так скажем, заглянуть маленько в будущее, что будет вас ждать, если вы пойдёте по тому или иному пути, и лишние пути отбросить, оставив наиболее подходящий и тот, который удовлетворяет каким-то вашим требованиям и вашему видению ситуации.

Здесь, я думаю, мы наконец-то можем закончить. Это была большая, долгая, длительная теоретическая часть. Вот мы маленько даже поработали с проектом, подключили MCP. И в целом это достаточно достаточная база для того, чтобы дальше как-то работать над тем, чтобы агент мог самостоятельно взаимодействовать с редактором, самостоятельно выполнять какие-то определённые виды работ. Вот я уже показывал, что есть папочка со скилами чисто проектными. Её можно наполнять дальше. и любые какие-то моменты в работе, которые вам приходится делать по многу раз. То есть, если вы что-то выполняете повторно, как будто имеет смысл попробовать оформить отдельный навык, чтобы в следующий раз за вас эту работу сделал уже агент. Например, вам нужно подключать постоянно как-то монотонно какие-то конфиги или какие-то иконки. Как будто бы можно оформить отдельный навык и отдавать эту рутину вашему агенту. предоставив ему возможности проверить то, насколько корректно он проделал ту или иную работу.

На этом всё. Благодарю за просмотр и желаю удачи в освоении AI Driven Developмента. M.