Transcription
Нас, и мы в лайве. Вот мы, э, про этих у нас небольшой смолток, да, про этих ботов. Вот. Но наш бот, правда, довольно-таки очень интересный. Вот, короче, довольно-таки очень прикольно, что сделали на основе клода бота, который может отвечать на вопросы в паблике, вот в нашем публичном канале команды. И это очень удобно. Вот. Только единственное, надо, короче, уметь эту махину контролировать. Вот.
>> Да.
>> Давай буквально одну-д минутки подождём. Вот. А расскажи, а в чём отличие? Вот. Да, у нас там он локально гоняется этот бот, а у вас как бот он?
>> А, ну слушай, это скопировали, ну не скопировали, взяли за основу бот, который сделал, сделала другая команда, другие люди. И на основе этого сделали тоже боты. Единственное, что он имеет только доступ к кодовой базе. Он пока не имеет доступа ни в кибану, не в базу данных, никуда, потому что вопросы безопасности есть. И как вот эти штуки всё порешаем, аа мы хотим это порешать, чтобы саппорт мог идти в этот бот, задать ему вопрос и не тревожить нас. Ну, то есть, во-первых, они быстрее получат ответ. То же самое, чтобы сделали мы. Не всегда это порешает, допустим, 90% вопросов от саппорта. Ну чем он отличается? Но у него нету доступа в базу и всё остальное, только к кодовой базе. Вот это самое главное отличие. И работает это всё на серверах где-то.
>> Ну, меня пока беспокоит там в общем, это невероятно крутая штука. Он и правда отлично, вообще клёво помогает разбираться во всех проблемах и так далее. Единственное меня беспокоит вот этот, как этот цикл того, что IT-саппорт, они, короче, могут начать с этим потом. Ну, то есть аишка, она очень быстро соглашается. Вот. И если ты, как сказать, не имеешь должного контекста, ты можешь этого бата с этим ботом, короче, уйти куда-то далеко и ещё не понимать, потому что он такой: "Да, да, ты точно, ты прав. Там типа не загружается, потому что там на бэкэнде ошибка." Хотя там ничего нету, просто типа это IT suппорт ему написал, что типа вот, ну, а там же, по-моему, докнди ошибка, но IT support ошибся. Вот. И, короче, он быстро очень соглашается и начинает уводить. Там спустя, знаешь, там типа партянка из 100 сообщений, там IT-саппорт пишет: "Блин, ребята, мы уже без вас не разберёмся. [смех] Вот, подключаемся". Но вообще, конечно, очень круто.
>> Ну да, ну таких, возможно, меньше случая будет, потому что очень часто же очень типовые задачи, ну там сравнить ордер или депозит, и тебе надо просто проверить, что, в каком состоянии у тебя депозит, в каком состоянии в Паго перевод, ну вот всё это смчить и всё. И ну это достаточно тривиальная задача. Тут не сильно разработчик-то нужен, он просто.
>> Да, и вот такие хотя бы задачи, чтобы снять с нас, ну, это вообще уже согласен. Вот. А всем, кто подключился, я на самом деле предлагаю начинать вот, да, там с первой чашкой вас кофе. Вот сегодня у нас такая интересная тема. Мы будем обсуждать AI вообще разработку. Вот напомню, я Гариша Скобв, Java Go, engнирингменеджер. У нас компании активно вообще развиваются и инструменты мы их активно внедряем, как и в разработку, и в архитектуруменеджмент, в помощь IT-саппорту и много-много где ещё. И с нами сегодня Федя. Вот. И Федя расскажет вообще интересный доклад о том, как в Unнити Ивеста как раз-таки тоже используется и I и CLE. Но Федя сейчас поподробнее расскажет. Федь, передаю тебе слово.
>> Да, спасибо всем. Привет. А, во-первых, расскажу немного про себя. Меня зовут Фёдор Догов. Я являюсь техледом в Unity Ивеest компании Плата Card. А, продвигаю EА инструменты внутри нашего юнита, также во всей разработке компании. А в компании с самого начала, с 1 сентября два второго года изначально был в Unни Processing Finance, тоже техледом. Это кредитные карты, это нсы, это кэшбэки и всё остальное. И с самого начала это делали. А дальше я перешёл в Unниве, и там тоже всё с самого начала делалось. А, и сразу скажу, что я очень люблю писать юнит-тест изоляционные, всё это покрывать, чтобы это всё было супернадёжно. И, наверное, забегая вперёд, это и помогло нам хорошо внедрить AI, потому что у нас были надёжный юнит, надёжные изоляционные тесты. И если что-то писалось не так и это было видно. Чуть забежал вперёд. Теперь о компании. Компания PLКАР. Это крупнейший стартап в Латинской Америке. А на текущий момент мы работаем в Мексике. А недавно получили оценку 5 млрд долларов. И кто захочет, присоединяйтесь. У нас, я думаю, скоро ещё больше будет вакансий открыто. Вот. А теперь перейдём, о чём мы сегодня поговорим непосредственно. Зачем нам вообще это нужно? А что такое код-код? Я покажу, а расскажу, как работать с контекстом. Несколько примеров с продакшена покажу, как мы что используем, и небольшое демо. А проблема, зачем нам вообще нужен AI? Мы хотим, а писать код быстрее, доставлять фичи как можно быстрее на продакшн, чтобы было меньше багов, а чтобы нам хватало токенов как можно дольше. И тут важно понимать, что AI - это напарник, это инструмент, с которым надо уметь работать. Ну и да, сейчас я сейчас мы поговорим о том, как непосредственно в Unнити Инвеest мы используем код-код. А что такое код-код? Он может читать коман читать код, выполнять команды, делать комиты. У него есть план мод. Для кого он нужен? Он нужен для разработчиков, аналитиков, тестировщиков, девопсов. Аа, конечно, его могут использовать продукт-менеджеры, бизнес-аналитики, все те, у кого есть рутина. Это изначально делался инструмент для разработчиков, потому что это был самый, наверное, простой внедрить. А, но потом компания поняла, что это просто хороший агент, и им могут пользоваться не только разработчики, а все остальные также. Ну и просто люди использовали код-код, а не для разработки. И затем появился cowork, который можно использовать, м более удобно. То есть код-код классический - это Ci. Давайте на следующую.
Классический кодкод - это CLI, а а Cork имеет GUI. Ну, удобнее работать не через командную строку. У нас есть план мод, у нас есть MCP-серверы у код-кода и топовая модель OPUS 4,7. Давайте перейдём, посмотрим непосредственно, как это выглядит. Вот как раз этот коворк. И тут, [фыркает] а-а, продукт-менеджеры или бизнес-аналитики могут что-то делать. У нас есть, э, гуи для код-кода. Мы можем выбрать директорию и что-то делать, но обычно мы это не используем. Мы предпочитаем сей как-то удобнее. Также есть просто обычный чат. А, и давайте посмотрим, как C выглядит именно внутри. Вот у нас тут у нас сейчас стоит автомоif мы можем менять, выбирать а нужный нам мод. Вот у нас выбираем просто применять изменения без нашего вопроса и план мод. Через план мод мы, в принципе, всегда и делаем задачи. А одна из важных фич, потому что если просто попросить его сделать и AI поймёт нас не так, он что-то сделает, и это займёт много итераций. Поэтому крайне большая рекомендация все задачи начинать с планмода. Тут можно будет, во-первых, это субагент, который будет собирать всю необходимую информацию, строить план. Это мы можем крутить несколько раз и отераций. И когда мы поняли, что мы пришли к нужному плану, и мы видим, что я нам вывел именно то, что мы хотим реализовать, а нажимаем окей, план сохраняется, контекст очищается, и мы начинаем с чистым контекстом уже выполнять этот план, что помогает нам экономить контекстное окно, меньше делать компактов, меньше делать клир. Об этом чуть по попозже мы поговорим. Теперь поговорим про MCP-серверы. А MCP-серверы - это расширение возможностей нашего AI, а разнообразные, можно писать MCP-серверы. М это расширение, где наш AI может общаться с каким-то любым другим программой и всем, чем угодно. Допустим, а мы очень много используем жира MCP, Gloupab MCP, можно там с Пасгрёй работать, можно с Фигмой и так далее. А, например, мы создаём задачи через жиру внутри C. Мы говорим: "Создай задачу". У нас описаны правила, где сразу создавать, в каком проекте, то, что надо создавать на английском и там вывести. Всё это описано у нас. И не надо каждый раз это делать, переходить в браузер и там что-то менять. А Gitlab MCP мы подтягиваем, можем создать Р, закоммитить что-то, подтянуть комментарии, поправить эти комментарии. Не надо ходить там или делать скриншоты, или копировать, что очень удобно. А MCP бывает либо локально запускается, либо сейчас очень модно, как там у жира есть, утуаба есть MCP и много кто сейчас делает. Мы внутри компании плюс-минус то же самое уже делаем. Вот код MD. Давайте посмотрим, как он выглядит. Код MD в самом проекте. Э, а сейчас давайте код [откашливается][кашель] это такой файл, который мы создаём через это как agents.m. Или вот у кода свой своё видение. Мы его создаём через функцию init. Он создаёт этот файл, где мы описываем всё основное. Он сначала сам создаст, потом можно просить его либо кода туда что-то добавлять, либо самим добавлять. Вот, допустим, а то, как общаться с нами, писать код, а и комментарии на английском, со мной общаться на русском, а соблюдать профессиональный способ общения, м описать, что у нас вот есть агенты. Используй агентов для написания тестов всегда. Это тоже мы здесь описываем. Это что? И тут всякие разные про то, что что за проект, что он вообще делает. И всё мы можем здесь описывать, чтобы у код-кода было как можно больше важного, полезного контекста, который ему необходим для реализации фич. А теперь поговорим про скилы. А скилы - это инструкции, которые позволяют нам экономить контекст, также м гораздо больше давать всякой информации. Это инструкции, а, повторяющиеся, а, для типовых задач. Плюс их то, что можно писать промты каждый раз, а можно добавить скил. Ключевое, что это он версионируется. И не только вы будете использовать этот скилл. Также этот скилл будут использовать другие члены вашей команды. Аа а скилы могут лежать непосредственно в директории проекта. А, допустим, вот обновление зависимостей. Тут всё у нас есть. Или то, как писать, а, JPC handler или же, а, вот у нас скил, э, написание изоляционных тестов. И тут мы всё описываем, как писать эти изоляционные тесты. Также юниты. И тут у нас есть референсы. мы кладём то, как должен выглядеть, э, прямо хороший тест изоляционный. Также мы делаем с юнит-тестами то же самое. У нас вот есть те же референсы, аа, JPCры, мы описываем, как вот писать JPC handler. У нас есть референс. А и ключевое, что в общий контекст у нас подгружается только название этого скила и вот этот короткийпtion, а о том, как писать, про что делает этот скил, как писать через PCлеры и так далее. Плюс вот этот параметр, он позволяет из из командной строки запускать. Э, вот он у нас демо, вот этот хенр, это скил. То есть можно отсюда запускать скилл. А скилл у нас будет подгружен полностью, когда AI понимает, что нам нужно использовать этот скил, или мы явно укажем, что используя этот скилл для выполнения, для написания этого юнит-теста, для написания JRPC хендлера. А также хорошим примером скила, наверное, будет скилл для работы с S3, который нам очень редко требуется, но когда требуется, нужно собрать много информации, как мы работаем с S3. У нас есть этот скилл, и мы очень легко можем реализовать быстренько работу с S3. А также, да, там всякие работы с партицирование, с миграциями и всем остальным, а мы можем описывать в скилах. И всё это не сразу подгрузится. Экономия контекста. Субагенты. А а субагенты тоже нам помогают экономить контекст. У нас есть главный агент. У нас есть агент. Плюс, скорее всего, мы будем там можно использовать, а можно не использовать скилы. Мы используем скилы и получаем результат. А зачем их вообще делать? У нас есть главный агент, и у него есть одно, у него есть контекстное окно, которое в процессе работы расширяется, и нам нужно будет сделать либо компакт, либо clearр. А когда мы запустим субагента, мы передадим ему небольшое небольшую информацию, которая ему нужна для выполнения конкретной задачи. Мы передали ему небольшой контекст. А этот субагент подгрузил ещё скилы, какие ему нужно, или ничего не подгружал. И результат его работы, скажем, будет а 2к результат 2к токенов, а контекстное окно 50к. И вот это контекстное окно уничтожится, а результат 2к перейдёт в главный агент. И за счёт этого мы не будем раздувать э наши контекстные кнопки. Как я говорил, планмод - это, а, хороший пример субагента. Ну и давайте посмотрим непосредственно в коде, как выглядят эти субагенты. Как я ранее говорил, мы можем либо писать э субагентов, они могут у нас находиться в плагинах либо прямо в самом проекте. Вот здесь мы можем их описывать, либо в самом проекте. Давайте посмотрим в плагинах. И вот тут также у нас есть, а, тест, короткое описание этого субагента, модель, которую он будет использовать, либо OPUS, либо Sonet, ну или хайпу, какую хотите. И здесь мы указываем, какие скилы а использовать. Это вот написание изоляционных тестов. Это написание может быть наш координатор. И тут мы указываем несколько можем скиов. Это уже зависит от нас. А то, как использовать в юните, мы указываем, что вот использую модельку Opus скилы Unitest, которые вот здесь у нас есть. И он будет использовать их, эти скилы. А, а, плагины, как мы сейчас видели, это способ дистрибьюции очень удобный, потому что большинство, как я сказал, допустим, S3, работа с жирой, а, написание юни-тестов изоляционных и много чего ещё, это повторяющиеся знания, которые не нужно копировать из проекта в проект, но хотелось чтобы иметь версионирование. И как раз плагины очень хорошо версионируются. Ну, то есть это конкретный какой-то гитрепозиторий, куда мы все эти знания складываем. Давайте посмотрим вот это демо. А потом ссылке на всё это мы покажем. А у нас есть Marketplace, который надо будет добавить. Сейчас я покажу, как это всё добавляется. А внутри есть такая команда плагин Marketplйд. Здесь мы добавляем вот так. И так у нас success. Он просто выкачивает через Git этот репозиторий. И так добавляется у нас этот плагин. И конкретный, чтобы плагин установить, их может быть много внутри нашего маркетплейса. Мы можем нажать и всё. У нас он устанавливается. Здесь что-то не то, но поправлю. А, clearр. Так вот, а, а, в самом Marketplй. JSON мы указываем, а, какие у нас есть плагины. Вот, допустим, у нас плагин демы и где он у нас находится. Вот здесь. Мы указали внутри самого плагина, а [фыркает] внутри самого плагина у нас версия есть. И когда мы что-то внутряем меняем внутри, допустим, мы добавляем новый MCP сервер, скилы, также тут могут быть хуки и всё остальное. Мы увеличиваем версию и коммитим. И потом просто через плагины идём, как кто-то из нашей команды обновил. Вот тут у нас есть либо мы можем искать плагины, а тут у нас есть установленные плагины и marketplace. Как раз вот наш Marketplace - это вот demo codт вот наш этот демо. Тут он мне пишет просто у меня конфликтует с моим уже установленным плагином инвестом. Это неважно. А когда нам нужно обновить, мы просто делаем апдейт и всё. И плагин у нас обновляется. За счёт этого очень удобно. А, и тут у нас, да, вот лежат как раз агенты, у нас есть скилы, MCP и всё остальное. очень удобная для дистрибьюции, когда много проектов или большая команда. И вы можете использовать либо на конкретный проект этот плагин ставить, либо для всех проектов, что создаёт удобство. А давайте поговорим про контекст. Ну, плохой контекст, плохой результат. И чтобы контекст был хороший, мы создаём cod.md, AMD, где описана структура проекта, а всё, как мы делаем. И сейчас ещё и кleр также выполняем. А, а для чего всё это нужно? А чем больше у нас контекст накапливается, тем хуже начинает работать. И вот как раз появляется галлюционирование. хуже, э, работает с инструкциями, что-то забывает, что-то теряет. И вот поэтому как раз агенты хороши тем, то, что у них всегда чистый контекст, и они пошли писать юниты с чистым контекстом именно, что конкретно нужно. Вот этим они хороши. И вот конкретно в нашем случае, а как мы делаем? Мы сначала делаем задачу, реализуем её. Comitar новые задачи. не накапливаем мусор. Меньше токино, быстрее результат и меньше галлюционирует. Но даже е не обязательно во всей задаче, может даже чуть меньше. Допустим, наша задача написать JPC handler. И вначале мы хотим написать изоляционные тесты. Мы написали, поговорили с AI через планмод, написали изоляционные тесты, очистили контекст и далее, что вот у нас есть эти изоляционные тесты. Мы реализуем эту задачу и пошли реализовывать. То есть как можно чаще очищать, не копить вот этот мусор, и тогда будет более чётко следовать инструкциям. А, ну и комиты нам помогают, э, чаще комититься, чтобы, если AI всё-таки сделал что-то не то, мы просто сделали reset минус минуха и всё очистили. Теперь непосредственно то, как мы используем в продакшене пару кейсов. А у нас пришёл тикет от саппорта. Клиенту упали дивиденды 90 долларов, но в CRM не отображаются. И я нашёл, что Альпака отменила дивиденды через 7 минут. Как это было раньше? Раньше надо было погрузиться в что там требуется, искать руками, читать влоги. На расследование уходили часы. И это очень утомляла работа, разбор таких тикетов. Как это сейчас? Мы даём вопрос плюслоги и находит э код, смотрит, строит SQL запросы, либо через MCP сама выполняет, либо мы идём, выполняем, и всё это заменяет там 30 минут примерно а разбор тикета. А конкретно в этом случае мы увидели, что клиенту дивиденды упали. Потом наш провайдер сам отменил эти дивиденды, но начислил его просто акциями, а сервис просто только executed cancel он не обрабатывал, и поэтому это было не видно. Так что с клиентом всё о'кей, просто чуть не так отображалось. И всё это потом порешали. Второй кейс - это починка багов. Мы с скармливаем, видим, что у нас в продакшене какие-то ошибки, какие-то проблемы. Мы берём эти логи, скармливаем код коду. Он находит место, понимает, почему, объясняет нам, ээ, предлагает фикс, делает тесты. и заводит также задачку. То есть сначала он заводит, объясняет, мы смотрим, понимаем, что да, это всё именно поэтому. Просим его также завести задачу жира. Смотрим, что именно это то. И в рамках этой задачи он делает этот фикс, что намного быстрее. А раньше у нас занимало, ну, часы самые, причём самые простые баги. Сейчас это занимает сильно меньше по времени. А, ну и давайте посмотрим, устроим небольшое демо, и я покажу, как мы используем. У нас есть три э у нас есть три репозитория: контракты, order, gateway. А мы хотим добавить, э, и что у нас тут есть? У нас есть с создание ордеров, а поучение ордеров. Давайте посмотрим по у нас есть создание. Получить конкретный ос ордер, список ордеров и проверить, что этот конкретный ордер принадлежит э этому юзеру. И мы хотим добавить удаление этого ордера. Я чуть пораньше запустил план мод, чтобы это не занимало у нас так много времени. Ну и вот такой у нас был промт. Нужно добавить ручку cancel order для обмена заказа. Изменения затрагивает три репозитории: Order и gateway. То есть у нас, э, лежит контракт в есть контракт, а у нас есть gateway, который на который приходят запросы. И через этот gateway уже идёт непосредственно вордер. Тут мы запустили план, он успешно отработал. Аа, и вот он нам пишет, да, создать первое contс, а, создать контракты, ээ, запустить buff generate, то, что нам надо. Потом в самом ордере сделать бизнес-логику, добавить статус cancel, сделать в стори сделать именно cancel, не update status. Угу. Создать хендлер. Юни-тесты, изоляционные тесты. в гйвее. Да, нас всё это устраивает. Мы запускаем, чтобы он реализовал. И сейчас постепенно будем смотреть. А пока мы ждём, у меня есть пару вопросиков. Федя, а считаешь [откашливается] таккенчики?
>> Какие таке, сколько таккенчиков сгорает? Расскажи, какая вообще экономика у всего этого?
>> А, а, честно сказать, мне не сильно приходится читать такены. Ну, у нас подписка Мак план. Аэ, Teams, где 150 и чтобы я упёрся в токены, но такое очень редко бывает. Ну вот за счёт тех практик, которые мы используем, мы не используем бесконечно один и тот же разговор, ну, одну и ту же сессию. Мы часто клир делаем, используем субагенты, скилы и всё остальное. Сколько сжигается? Ну, я так смотрю, там сотни к вон вон сейчас 6,6 кнов. Но вот именно смотреть непосредственно сколько, но такого, наверное, нету.
>> Ну мы у себя в команде считали, то есть, ну, у нас тоже подписка, то есть, на самом деле, у нас, да, внутри компании подписки. И это такое, короче, немножко геморная тема в том плане, что там антропик, они как-то следят за всей этой историей, и они как-то там пытаются менеджерить, и мы какими-то слегка немножко обходными путями, короче, эту подписку себе получаем. Но суть в том, что вот правда 150 баксов там на человека и правда не упираешься в лимиты, но мы так считали, что там типа примерно баксов 50-60 в неделю типа сгорает на одного человека, >> еслить подписки. Но это даже это хороший результат. Это если там 50-60 в неделю, потому что это правда было давно, очень давно, когда он появлялся только код-код, и я через API начинал его использовать. Он меня очень быстро тратил и без подписки просто по API, ну, там вообще будет у меня сжигать, не знаю, там сотни или тысячи, наверное, евро я бы тратил, если бы не подписка. Вот так, скорее всего, у меня.
>> Фезия. А пока мы вот ждём, что он там применяет изменения и думает, такая: "Что в этот момент делать? Что ты, что ты обычно делаешь в этот момент?" [смех]
>> Слушайте, ну обычно так-то или запускается другая в параллели, но у тебя несколько терминалов запущено, или ты сидишь на звонке или у тебя в терминале запущено. Ну, если тебе прямо нечего делать, ну, можно пойти сделать небольшую зарядочку такую, кофе налить. А так обычно ты всё равно в каких-то ты запустил, ну, провернул этот планмод, запустил и пошёл с каким-то вопросом куда-то что-то смотреть. Обычно это выглядит так.
>> В общем, превращаешься в 10X инженеры.
>> Ну, кстати, да, но прямо честно скажу, я как-то пытался, когда много запустить проектов, и тут вот уже сложнее опять вот это держать в голове зависимости, что тут у тебя запущено это, это, это, это ещё сложнее, я уже понял. И там немного ты.
>> твоё контекстное окно раздувается, да?
>> Да, да. И тут Да, и тут сложно становится, особенно всё зависит от задачи простая. это сделать JPC хендлер или всё-таки это прямо, если это требует полного погружения, наверное, ты так не сможешь запустить, если ну всё зависит от сложности задачи. Ручка cancel, но она суперпростая, и это обычный баг. Вот так что тут зависит от Ну давай посмотрим, что он нам сделал. Уже можно, потому что контракт он сделал, ордер сделал, он гвеем занимается. Так, и самое простое для меня смотреть это так, что здесь у нас сделано. А он добавил cancel order request response. Добавил сюда. Отлично, он сбилдил, выполнил всё это, всё, что нам требовалось. Да. Теперь посмотрим вордер, что он сделал. Он добавил у нас два файла handler hand хлер сам и тест unitтест. Я его добавил сразу, чтобы было проще смотреть. И да, я обычно смотрю так, мне так удобнее через git, что было сделано. Ревюю его. И вот он написал handler handle. Вот он функция validate у нас есть. Потом order cancel вызывает internal. Да validate. Ну, плюс-минус так. А написал юниты. Так, как мы пишем, мы пишем юниты через given when the NGVT. Да, всё о'кей. Он добавил его в сервер. Вот у нас cancel order. А в entти он добавил новый статус cancel. Так, чтобы проще было смотреть. Давай посмотрим его стори. Он сделал метод. Ну вот он добавил cancel метод. Угу. Да. И написал нам изоляционные тесты. Да, да, и сам гейтвей. Давай посмотрим. Вот он у нас.
>> А у меня небольшой тут вопросик. Прости, что переваю. А вот смотри, вот ты сейчас смотришь его изменения. А как лучше всего, когда ты увидел, что что-то, на твой взгляд, некорректно? Вот, ну, ты как бы и правда вот мы больше превращаемся не из тех разработчиков, которые что-то пишут, да, а те, кто там стараются больше читать, осознать, прокодревьюить. И вот это кодревью, когда ты делаешь, как ты его просишь вносить изменения, если он где-то тебя не так понял?
>> Угу. Так, ну, допустим, здесь так store domain. А я непосредственно, всё зависит от, ну, если у нас он не написал, допустим, usеer ID, можем, да, кинуть. Он нам просто здесь не требуется. Мы проверку делаем ввеер ID.
Ну, допустим, если нам здесь он по каким-то причинам нужен user ID, э, скорее всего, возможно, я сам напишу. Вот просто тут маленькая. Ну, а если там проверь дополнительно статус, э, я бы скопировал. И я всё-таки непосредственно здесь запускаю, но здесь. Давай посмотрим. Так. Что? Статус терминальный. И здесь я тоже сделаю через планмод. Вот это бы скорее всего сделал я так, потому что тут он не сделал проверку. Вот сейчас обычно он делает это, что, ну, я и не указал, что всё-таки статус надо делать только, если он терминальный. Если он фиништый или какой-то другой, то уже нет смысла. Вот.
Ну, это вот когда что-то посложнее, скорее всего, да, я попрошу его. Ну и вот он добавляет мне терминальный статус. Как-то такое. Ну, в общем, всё зависит от если маленький фикс, то я сам руками, скорее всего, поправлю. А если что-то посерьёзнее, попрошу его написать и изменить. Ну и вот он тесты просто уже >> Угу. >> Да, тесты он уже накидывает просто под это дело. Вот. И Gateway у нас Gateway тоже он реализовал всё это. Уже есть ручка. И тут вот главное, что он делает проверку до того, как изменения. Мы сначала проверяем, что этот заказ принадлежит этому пользователю. И дальше уже вызываем canceler. И здесь у нас вот как раз есть эти проверки user ID. То есть там он правильно, что не стал валидировать user ID, потому что там он не нужен. Он написал тесты. Тесты написал тоже given when then [фыркает] сервер. Сейчас я проще так посмотрю изоляции. А вот мы проверяем, что Да, он это всё сделал и мог написал. Да, всё отлично.
Ну и как понимать, что он вообще может может наши скилы и не требуются? Просто добавлю немного. У них появилась такая функция EVS, где мы пишем наши файлы и, допустим, написать это у нас JPC handler или вот unit-тесты и аа тут есть промт написания. И что мы ожидаем? Мы запускаем эти евалсы и должны получить примерно такой же unниitст. Это к тому, что возможно, когда модели станут умнее, эти скилы и не потребуются работа с S3 или написание юнит-тестов. Так что через евалсы можно проверять, нужны ли эти скилы или нет. Может, без скилов он даже лучше сделает. Вот. А, ну и перейдём, финализируем. У нас есть четыре фазы: Формируем, описываем задачу истроит планы, реализует. Э, а дальше тестирование, ну или тестирование изоляторов. Вы можете на первое место наоборот написать сначала изоляты, а потом перейти к реализации. Это уже на ваше усмотрение, потому что если раньше это было сложнее и дольше, то сейчас я и позволяет как раз написать сначала изолятор, а потом уже реализацию. Финализируем комиты, мержреквесты. Всё.
А сразу скажу, что AI, если делать её без планмода, она может сделать фигню, потому что она просто может не понять вас или вы ввели и вам понятен ваш промт по одному, а я и поняла по-другому. Дальше нету недостаточно контекста. Она может сделать что-то не так. Иногда делает совсем не то или делает по старым. Аэ, по старым шаблонам, скажем, протецирование. У меня просто хорошо, я помню это, когда он мне делал по старому способу через наследование, партицирование, а не как сейчас через прикрепление отчи и всё такое. Вот. Поэтому надо внимательно смотреть, ревьюить, да, очень важно, наверное, писать тесты. Если написано хорошие тесты, то легко будет внедрять, видеть. Как минимум, вы сможете ревьюить тесты, то, что написала AI, и понимать, нормально или ненормально. Ну и выводы. [фыркает] Ускоряет, но не занеменяет. Помогает делать качественное, освобождает от рутины. И в это время, я не знаю, вы сможете зарядку сделать или ещё что-то. Аа, в общем, всё. И также у нас вот QR-коды на эти сервисы, пуагины, чтобы посмотреть, как и что делается.
>> Круто, круто, ребятки, не стесняйтесь закидывать вопросики. Вот, спасибо тебе большое за доклад. Я предлагаю сейчас ещё провести небольшой Q&A. >> Тут есть вопросик от Евгения по поводу того вообще, как настраивается MCP. Вот есть ли какие-то донастройки и как, условно говоря, соблюдать секюрити безопасности. Ну и в целом, как вообще вот эти агентские системы там как the best way их использования в Кровавом эндерпрайзе.
>> Да. Привет, Евгений, спасибо за вопрос. А как мы используем MCP жира? У нас MCP, мы просто подключаемся. Также есть плаже, по-моему, мы сейчас используем, ну, в плагине, через него мы получаем авторизацию и работаем. Донастраивали мы через skill, мы написали как раз в плагине у нас есть для инвеста skill, где написан именно наш проект э нашей команды. И когда мы просим завести задачу или поменять, он уже знает, что, скорее всего, речь идёт именно про наш проект. Или мы можем явно указать какую-то другую задачу, и он явно идёт туда. Там описано, куда ходить, что забирать. А и там написано именно русскими словами, как создать задачу, скинуть и всё это. Это в дескрипшене описано, и он сразу понимает, о чём мы ведём речь. Через скил. Я могу ещё от себя сказать, что вот эти все агенты, э, ну, как сказать, там есть очень ключевое различие, заключающееся в том, что если вы используете какой-то свой личный аккаунт, да, публичный или даже тот, за который вы платите подписку, а, ну вот, например, у Open Ai, там так и сделано, что в любом случае он может дообучаться на ваших данных, но в случае, когда вы покупаете enterprise прайс подписку, вот, то это означает, что нет, что он вот эти данные, которые вы используете, они там считаются sensтив, корпоративной там тайной. Вот. И он никак на них не дообучается. Вот мне кажется, встал у них там они же сейчас все активно готовятся к AP. Они, по-моему, в каком там в тридцатом году собираются выйти, поэтому они, мне кажется, >> антропик вот уже уже собирается >> уже уже. Ну, вот они поэтому, мне кажется, так и сейчас все очень следят за безопасностью вот и стараются, да, чтобы не было никаких скандалов. Ну, то есть в целом это и правда выглядит довольно-таки безопасно. И то, что вот ещё Федя показывал, ну, там базовые правила, когда вы настраиваете какое-то MCP, ну как это, не рискуйте, не давайте ему, например, право на запись.
>> В той же самой аудитории. >> У нас у нас скелетом, >> да, у нас скеле написано, что сначала выведи мне текст задачи на русском и на английском и спроси, заводить или не заводить. Ну, то есть да, у нас в скеле это описано, и он сначала нам показывает, мы соглашаемся с этим и говорим: "Да, заведи задачу". А вот тут всё Евгений про Джиру спрашивает, что получается агент помоу ходит по голому апиджиру или в Джире есть свой агент, и он просто ей делегирует задачи. А у жира есть MCP, а где мы даём какие-то доступы. И вот этот, а, MCP, да, он ходит прямо в жиру. Это MCP официальный, а, от самой жиры. Ну я вот как менеджер, я активно использую, а там, чтобы создавать задачки, чтобы там какую-то статистику смотреть, чтобы там я уже, как это перестал в заходить в джиру, чтобы там этот в олворке построить всякие запросики, а я просто говорю там Клоду, там давай найдём типа задачи, у которых deт протухает там в ближайшие 2 недели и всякое такое. Ну то есть очень много всего. Вот, я думаю, мы сделаем отдельно об этом роли, как менеджеры используют. Вот. Но я вообще замечал, что он очень по-разному использует. То есть иногда он использует и правда голую опишку вот какую-то берёт. Иногда он правда по MCP именно ходит. Вот. Но в целом это классно. Феть, а у меня ещё такой вопрос. Хочу вернуться к теме того. Смотри, и правда есть такое, что как будто вообще AI прям может так сильно разогнать, прям вообще мчаться вперёд и, э, быть, короче, слишком слишком быстрыми, да. И тут вопрос заключается в том, что а как вообще от этого не выгореть? Ну, то есть как будущее станови, как сказать, бизнес внедряет AI для того, чтобы быстрее все делали свою работу, да? Вот. Но на самом деле такая ловушка, которую мы тоже можем поговорить.
>> Ну тут про это много кто говорил, но тут ключевое. Он ускоряет и помогает тем командам, у которых и до этого всё было хорошо. То есть, если у вас культура и процессы до этого были выстроены хорошо, он вас ускорит. А если у вас до этого было не очень и культура, и процессы, что я подразумеваю, вот, допустим, книга ускоряйся Acceleration, там всё это очень хорошо описано. То есть trank based development, а, CICD, в котором он не просто CICD, а у вас там реально есть тесты и которые реально проверяют. Это не просто фигня, а это тесты, которые проверяют работоспособность сервиса. То есть, что ваша фича работает и после этого она не разломает ничего другого. У вас это всё есть, и вы легко быстро мержетесь. То есть ваша ветка живёт там часы, максимум, там день, сколько это максимально быстро. И тогда всё это нормально. А если процессы были до этого, тут скорее, в общем, выгорает, скорее всего, когда плохие процессы. И тут надо это чинить. Не из AI выгорает.
>> Это Это правда. Согласен. Ну я бы ещё сказал, да, что тут очень важно бизнесу позиционировать, что это неправда. Типа, как это, как - мм такой, не знаю, как это, реактивный ранец или ещё что-то или нитро, которое подрубает и всё. Не, скорее про то, что инженеры могут сместить свой фокус с того, что они делали сперва там типа думали: "А как же мне красиво написать код, да? А как же там мне монаду написать или как мне там функциональну использовать". сместилось больше на системное мышление, как это встраивается в архитектуру, как это будет использоваться дальше, как это можно будет масштабировать переспользовать в других сервисах и так далее.
>> Там вот недавно просто скажу, я недавно смотрел доклад у Яндекса, у них классные доклады совсем недавно были. И а там они как раз Я тут. Нет, >> ты тут, >> да? А рассказывали про доклады, то, что в принципе мы кодим 35% от своего времени. Ну, плюс-минус вот так. Остальное - это звонки, это кодревью, это что-то там инфра. Ну, в общем, код - это 35%. И даже если мы в принципе ко входи ко ходим на 50% быстрее, что навряд ли. Ну и там тебя ускоряет, ну на 30-50%. Я не спорю, что если это прямо конвейерь задачи, ты просто делаешь продуктовые задачи, ну там круды какие-то клепаешь, то да, возможно тебя сильно быстрее ускоряет. Но если у тебя постоянно какие-то задачи, ты делаешь новое партицирование, ты делаешь какое-то новое логирование, ты шардируешь систему, ещё что-то, ну тебе надо быть внимательным. Ну, то есть ускорение у тебя на 30 на 50% там будет, а ты кодил 35%, и получается, что, ну, ты на 17,5% примерно стал более продуктивным.
>> Согласен. Согласен. Ещё есть такой этот, как это на самом деле вот я у себя в команде замечаю, ты тоже тут расскажи в том плане, что есть такие некоторые типовые, как сказать, проблемы, которые сейчас приносят AI, с которыми по-разному борются. Ну, то есть, например, из-за того, что есть, правда, буст ускорения разработки, есть проблемы в кодрев начинается, что типа больше эмров появляется и люди просто перестают, либо качество ревью очень сильно падает, либо не успевают просто ревью идти, и из-за этого задачи долго висят. Ну и то же самое касается, что дальнейших шагов, что, ну, и потом и тестирование тоже точно так же, что на них могут иногда лавинообразно как-то задачи падать. Вот я сейчас у себя в команде справляюсь с этим добавлением VIP-лимитов, что типа ребятки как бы они там делают разработку сосредоточенно смотрят там на конкретные, если там разработчик, инженер закончил там со своими тасочками, он может там пойти аналитику помочь, он может пойти помочь тестировщику, ещё что-нибудь, может там какие-нибудь ещё вещи там поизучать, идрки написать, ещё что-нибудь.
>> А, да, всё так. И тут как раз я обращусь к этой книге Ускоряйся, то, что [вздыхает][тяжело вздыхает] важно, чтобы Тут я не говорю, что на тестировщиков не полагаться, они супер важны и нужны, они также остаются, но просто разработчики ещё больше должны, то есть юниттест, изоляты должны прямо чётко проверять. И если, ну, вы понимаете, в какой-то момент, да, такое может случиться, что тесты либо слишком плакают, либо ненадёжны. Надо сесть, остановиться, подумать и, возможно, переписать эти тесты. Но ключевое, чтобы в пайплайне эти тесты были не фигня. Они прямо проверяли, что ваш функционал работает, и меньше, ну, то есть какие-то задачи не передавать на тестирование, а должно провериться всё этим. Ну, допустим, у вас был депозит, и депозиты внутри сам самого сервиса поменялась логика какая-то, но она поменялась только внутри. То есть внешние контракты, они как и были, так и остались. Мы ни с провайдером, ни с другими командами ничего не меняли. Даже внутри нашей юнита мы ничего не меняли. То есть поменялась логика внутри нашего сервиса. И, скорее всего, тут можно проверить эту логику этими тестами. Юнитов побольше написать, побольше написать изолятов и как бы разгрузить QA. И, ну, мы как-то стараемся в эту сторону двигаться.
>> Согласен. Да, это хорошая история. Ещё ещё вот последнюю боль, которую я хочу с тобой проговорить, это история про вот этот ээ ээ синдром Матфея. Вот в том плане, что вот это, ну, очень заметен, ну, как сказать, те, кто уже были сильные в команде, вот они на самом деле от этого стали только сильнее. [смех] Вот. А те, кто не аутсайдеры, ну, в смысле такие нормисы были в команде, они как бы не получили какого-то буста. И вот нужно очень активно работать над тем, чтобы они начинали использовать инструменты, то есть проказывать примеры, там приходить им рассказывать и так далее. Вот, то есть как это, типа, богатые богатеют, бедные беднеют. Вот.
>> Да. Да. Это вот как раз и то, что у кого до этого всё было отлично, они стали ещё сильнее, а у кого до этого было плохо, ну, как бы тут не поможет это. Ну, вот вот такая, но вот как раз и на этом >> вывесте с этим боретесь. Ну, у нас старый костяк, никто не меняется, и мы уже у нас все, в принципе, сильные. Есть есть отдельные люди, которые там как-то со скепсисом могут относиться к И, да, есть такие. Но мы рассказываем, показываем. А так у нас большинство все активно используют AI, все внедряют. До этого это были какие-то воркшопы, мы устраивали, ещё что-то. Но как внедрять в компании? Как раз на той конфе Яндекса? Они очень хорошо говорили, что надо больше писать MCP для инфры, которые вы сами пишите, вы понимаете, как они работают, и показывать воркшопы, потому что это не зависит от уровня, но некоторые разработчики со скепсисом до сих пор относятся к ИАю. Не знаю, такие остались, нет. Ну, наверное, остались, которые не признают. И вот больше воркшопов устраивать, показывать, как использовать внутри компании, учить, брять, брать прямо его задачку вместе с ним садиться и делать эту задачку с помощью яй, чтобы он увидел, что действительно она сделала хорошо, очень быстро, и он и сам так может. Вот, наверное, так.
>> Согласен, согласен. Вот, слушай, наверное, последний философский вопрос в том плане, [фыркает] что там и правда всё так быстро меняется ещё из APО, они там всякие эти, не знаю, мемные ситуации создают. Ну, то есть те же самые антропик такие: "Мы создали мифас". И мы, короче, настолько мощная модель, что мы боимся её выпускать. Поэтому, короче, пока думаем, она может вообще там просто [смех] все уязвимости найти на свете. Ну, то есть, короче, вот я, например, на работе тоже сейчас использую cloudкод. Дома я использую кодекс. >> Вот. >> Угу. >> А, и меня на самом деле там и там устраивает. Вот. Но в целом ты как думаешь, что нас ждёт, например, через месяц? Вот что нас ждёт через 2 месяца? Что нас ждёт к концу года? Кто займёт вообще рынок ИI? Или AI - это пузырь, который схлопнется? Это не пузырь, это уже то, с чем мы живём. То есть это она реально помогает, она убирает рутину. А не пузырь пока в текущий момент, ну, все так и будут развиваться. Как ты и сказал, и кд код, и кодекс. Я просто давно пользуюсь код-кодом, и меня всё устраивало. Это исторически так сложилось. Про кодекс я тоже слышал достаточно сильно всё хорошо у них, и я думаю, они будут подтягиваться. То есть был момент, когда они пошли по-другому пути. Антропик вот именно с Кодом хорошо работал. Я так и думаю, будет развиваться. Надеюсь, Грок ещё подтянется в этот Gй супер слышал. Ну вот мне нравится код-код. Что будет в будущем? Да мы так и будем нужны. То есть люди, которые используют AI, они так и будут делать какую-то работу. Потому что, ну, топы из нашей компании не будут ставить задачи код-коду, чтобы он что-то сделал, сделал и выкатил на продакшн. Для этого нужен человек, который скажет, проконтролирует и выкатит на продакшн. Так что мы так и останемся. Ну, лет 5-10, я думаю, у нас ещё есть, а дальше да кто его знает. И то, я не знаю. Это я так думаю, а как оно будет, я не знаю. Это мои мысли.
>> Здорово. Нуро, что у нас есть лет 5-10. Вот. Ну я думал тут, а какую же профессию ещё получить? Да может быть плохи. >> Да они там и роботы, да, роботы вон у Ауса классные роботы, они сделали Hyundai вместе с Гуглом. Ну то есть Hyundai делает классное железо, а Google делает Deep Mind. И вот они уже сейчас делают на за своих заводах используют. И к тридцатому году планируют выйти уже, ну, вот больше так на какие-то заводы, всё это там. То есть пока это будет в Hyundai, пока это будет в Гугле, но они развивают и делают это суперкруто. Ну, то есть пока человеческий труд просто дешевле, его никто и трогать не будет. Просто пока он дешевле.
>> Это правда. Это правда. Там пишут про то, что Да, что типа пузырь есть. Вот сейчас пока типа антропик. Open и всякие другие компании пытаются нас подсадить токены. Вот. Но скоро >> это же это же как работает, это классическая, как его называется, венчурная история. Ну то есть а компания она как бы берёт займ у себя через 5 лет. Ну то есть они исходят из того, что через 5 лет железо станет сильно дешевле. то, что модели ставле, кризис, Steam машины отложили. Блин, я её и так ждал. >> Ну да, но через 5 лет, ну сейчас же как раз вот эти все производители оперативной памяти, они новые заводы строят, чтобы выпускать эту оперативную память. И они исходят из того, что, во-первых, модели, ну, сами ики станут более продуктивны. Ну, то есть они на ват энергии станут, а, выдавать больше качества. Ну, то есть, во-первых, станет само по себе, сами таккены станут дешевле, они станут умнее. И, в общем, это они как бы у себя через 5 лет занимают деньги с условием того, что они станут очень прибыльными. И вот эта компания через 5 лет занимает э деньги для вот этой дешёвой компании. Поэтому тут исходя из того, что через 5 лет всё это будет дешевле. Поэтому, ну, это обычная венчурная, по-моему, история. Так же, как вот многие работают в убыток первое время, чтобы развиваться.
>> Согласен. Короче, мы, кожаные мешки, всегда будем нужны для чего-нибудь. Не попадём. >> Ну вот для чего-то мы будем нужны. На такой позитивной ноте, Федя, хочется сказать тебе большое спасибо, что ты пришёл и провёл это с нами сегодня, это утро. Вот. Надеюсь, ребятки, было продуктивно. Пишите комментарии. Вот. Вам тоже огромное спасибо, что пришли. Вот. А на этом ещё услышимся. Всем пока-пока. >> Спасибо, Гриш. А