Transcription
Всем привет. Меня зовут Лев Бондаренко, и я iOS-разработчик в Яндексде. Последние несколько месяцев я активно погружаюсь в обходинг инеering, самостоятельно изучаю эт вопрос. И мне оказалось мало того опыта и той информации, которую я получаю. Мне захотелось услышать тех, кто вот в реальной практике делает какие-то настоящие задачи с дедлайнами, с реальными проектами Legy, ну, в такой большой корпоративной разработке в кровавом энтерпрайзе, как это говорится.
Поэтому сегодня у меня в гостях мой коллега Максим. Он евангелист Аитул китов, знает прямо очень много всего. Первый день мой рабочий, когда я пришёл, а там был discше, и Максим рассказывал, как он применял аилкиты в работе. И я уже думал: "Блин, круто, никогда не знал. Я скептически сильно относился к атулкитам, а тут мне прямо показали, как на практике это всё можно делать, как это всё быстро решается". И в тот момент я погрузился в этот большой мир, изучал, а особенно в Яндексе, да, тут прямо у нас очень сильно пропагандирует использование всяких тулкитов. Но тут есть и вторая сторона медали. Ты скептически можешь относиться к этому опыту. Не все, да, к нему относятся хорошо. До сих пор есть какие-то сомнения. И не всегда понятно, э, тупиковый путь ли это развитие для инженеров, либо это и правда хороший бустер, который помогает нам лучше ускорять свою работу. И вот Максим, э, он является одним из лидеров АИТрима, да, по-моему, если я не ошибаюсь, по интеграции и обкатыванию пиллигримам китов. Очень много знает, очень много интегрирует инструментов сюда. Я его и пригласил. Давай, Максим, расскажи, пожалуйста, о себе немножко, о чём мы будем здесь говорить.
Привет, Лев. Спасибо за э столь э обширное и интересное э да вступление. Ты, в принципе, обо мне уже всё рассказал, э о моей роли, в частности, в продвижении АИ инструментов. Да, действительно, я, э, много уже на практике попробовал, пощупал. Сегодня два базовых инструмента мы будем использовать. Это, э, курсор и клод-код. О них в основном пойдёт речь, потому что они самые нужные, самые важные рабочие наши лошадки, скажем так. Будем говорить так.
Сейчас никого не удивить контентом о применении АИ в реальном кодинге, потому что сейчас очень много роликов, очень много материала, все могут посмотреть и про настройки, и про всё, что угодно, в принципе, за исключением одного. Вот в большом докладе, там сейчас маленькое маленькое лирическое вступление, в большом докладе Google Клауда перечислены важнейшие элементы там работы инженера и роль АИ в этой работе. И среди пунктов есть один из, не самый первый, понимание кодовой базы. И на восьмом месте написание кода. Вот только на восьмом месте. То есть >> только на восьмо понимание кодовой базы - это ты имеешь в виду ментальная модель, выстраивание. Ну и чуть позже об этом поговорим, да, получается, >> да, в логика, выстраивание деревозависимости и так далее. И на восьмом месте написание кода. То есть, э, по факту мы имеем дело с помощниками, которые позволяют нам избавиться от некоторой рутины, то есть вкалывают роботы, а не человека, как пелось в старой детской песне.
Так, в чём уникальность нашей подачи? В чём уникальность того, что мы сегодня хотим, о чём мы сегодня хотим поговорить? Мы немножко приоткроем завесу тайны над работой, как раз в большой кодовой базе на живом материале, то есть на реальном коде. Это то, что вы редко где-то увидите на самом деле. Сейчас о чём поговорим? О чём хочется поговорить? Настройки немножко поговорим чуть-чуть о контекст метаменеджмент, о том, как в архитектуре помогают LLM и, соответственно, курсор. Курсор не совсем да, а курсор - это о безопасности поговорим, потому что эта тема постоянно поднимается. Про нетвор поговорим, потому что это модели, это вечная тема наша. А мы постоянно говорим про какую-то автогенерацию в контексте нетворка. Вот про Ui, конечно, поговорим, потому что перекрашивание кнопок и там всякие динамические вещи для нас, там коллекции, таблицы и так далее, всякие реюзы. Это постоянная постоянная тема актуальная вне зависимости от того, какими там частями iOS SDК мы пользуемся. Вот. А про MCP, да, про MCP тоже будет разговор, потому что MCP - это часть всей большой экосистемы АИ. Ну и дальше там немножко философии тоже, я надеюсь, мы затронем с тобой, да?
Давайте немножко о конкретике тогда, да? >> Угу. Да, давай. Ээ, получается, мы начнём с настроек, и ты хочешь пошарить или пока просто погрузиться в общую информацию?
Да, получается, >> мы обещали, что мы всё будем делать на живом материале, поэтому сразу стартуем с нашего кода, сразу стартуем с наших настроек. >> Угу.
Так, а получается, да, да, видно. Ээ, код - это у нас прямо боевой реального проекта, да, нашего не какого-то не какого-то ПДП-проекта, а прямо рабочий, как >> используется в реальной жизни. Ну, сразу дисклеймер, мы это согласовали, и никто это не сливает, [смех] да, чтобы кто-нибудь в комментариях или где-нибудь не указал, что, >> да, мы скажем об этом обязательно в своё время. Да, да, когда мы будем говорить о безопасности, мы тоже об этом упомянём, конечно, естественно. >> Ага.
Давайте с базовой, с базовых там пары базовых слов, пара вот просто про настройки. Смотрите, значит, что сейчас происходит в мире большого энтерпрайза. В мире большого энтерпрайза, там где мы движемся к максимальному максимальной эффективности, всё, что вы видите сейчас в левой колонке - это какие-то правила, которые могут быть применимы, могут быть неприменимы. там, скажем, какие-то у нас могут быть общие Project Rules, которые должны применяться всегда. Здесь там, э, они каждый раз у нас добавляются, дополняются, когда мы встречаем какие-то недоработки со стороны LLM, например, что-то нужно подсветить, скажем, использование линтера или ещё какие-то специфичные наши там правила форматирования и так далее, и так далее. Вот эти правила, это мы сейчас с вами немножко про настройки говорим. Вот эти правила сейчас принято упаковывать в скрипты. Их принято бачить просто потому, что они разбиваются тоже тематически. Вы можете посмотреть, что и там есть правилаter, есть правила UI генерации и так далее. Мы же не всегда работаем там, например, с кнопками, да? Мы часто работаем с логикой. Для логики у нас своё правило, для UI своё, для, э, там, например, специфичные какие-то могут быть правила, связанные с генерацией методов или ещё с чем-нибудь, там, например, там аб-тесты, эксперименты, это тоже отдельная тема. Ну и не всегда генерируем эксперимент, не всегда мы засовываем под эту логику какой-то какой-то продакшн. Поэтому эти правила у нас существуют там, например, отдельно. А есть какие-то common-правила, которые можно батчить. И благодаря тому, что курсор, например, как, э, продолжение VS-код, всё это хорошо съедает в виде баш сскриптов, например, мы оформляем это башскриптами. При установке курсора, там, при обновлении курсора можем, э, дёргать этот скрипт, и он нам обновляет автоматически всё, что есть. Для iOS могут быть свои правила, для бэкэнда свои и так далее. Вот у нас вот это так работает, так настроено. >> А, да, это получается рулсы. Давай вкратце такой ликбес, это правила, которые помогают и проекту, и тебе, и команде шарить какие-то шаблоны и механики или ограничения для проекта и промтов, да, или как это работает, или для всей этой шки, >> да, это общий контекст. То есть, если ты будешь сравнивать, например, работу совсем без рулсов по проекту и с чётко заданными рамками, с чётко заданным контекстом, в первом случае ты получишь базовую историю, которая на которую все всегда жаловались с самого начала работы с АИ. Ай, АИ глючит, ай, АИ галлюцинирует, она там уходит не туда, что-то мне лишнее выдаёт и так далее. Ну, это ответственность разработчика, это ответственность не ЛМ. Мы задаём контекст, мы его ограничиваем. Всё. Вот это наши рулзы. И мы пользуемся экосистемой. Мы пользуемся возможностями курсора для того, чтобы их прописать. А сразу скажу, поскольку я работаю и с курсором, и склод-код, вы видите, что в курсоре это в, ну, в клоде это решается очень просто, потому что в клоде есть такая команда, как. Вот. А она тут не будет работать, потому что мы уже в де находимся. Это просто из терминала запустим потом. Ну, можно запустить, можно, можно, не надо. >> Что она делает? Получается, >> у clД есть встроенный набор команд. И одна из команд - это, она автоматически под подтягивает. При том, что мы установили, вот здесь, кстати, важно понимать, что у нас есть установленный плагин для клод-кода в курсоре. И когда мы его установили, это нативный плагин, когда мы его установили, клод понимает команду сIDE, то есть сIDE, и clot выдаёт нам те, в которых она может работать, соответственно. >> А получается какие-то IP функции, ну, если так обобщать, которые помогает cloud коду лучше работать в курсоре, да, получается, >> интегрируется, а, интегрируется, он такой в режим новый приходит. Ты видишь, да, что отдельное просто окно в курсоре присутствует с клодкодом. То есть справа эдитор, обычный редактор курсора присутствует агента. По центру у меня присутствует окно с клодом. И можно можно чередовать, можно там какие-то задачи тут решать, какие-то задачи тут решать. Тут я больше, наверное, э в качестве иллюстрации это привёл, потому что а вот так вот прямо одновременно, наверное, редко так происходит, просто разные задачи какие-то, наверное, решаются там решаются тут. Это про настройки. Немножко про настройки, про общие скажу. Есть, э, так, такие философские, так скажем, настройки, да. Вот есть там скрипт такой, он по сети гуляет, я его немножко там под подредактировал. Это общие настройки про то, какую идеологию, скажем так, какую философию в работе LLM должна исповедовать, так скажем, посредством курсора, когда отвечает. То есть излишнего контента, максимально чёткие респонзы, а максимальна логика та, которая нужна. То есть тут для того, чтобы не замусоривать наши конкретные рулзы какими-то общими философскими вещами, тут мы это прописываем. Всё. Больше не хочу на этом останавливаться, на самом деле. Пойдём дальше. А пойдём конкретики.
>> Конкретика у нас получается, ты говорил про безопасность. Главный вопрос, который задают большинство разработчиков, и я когда вижу, что они какой-то барьер использования аишек, один из главных барьеров, помимо того, что они думают, что ручной труд убивает твоё творчество, а точнее наоборот, если ты не пишешь код руками, то значит творчество в тебе меньше, детализации меньше, развития меньше и всего остального тоже меньше. А второй блокер, который происходит в головах и инженерах, и в моих тоже в нескольких, это желание использовать дэшки в коммерческих проектах, потому что у нас есть безопасники, которые по факту могут запретить тебе использовать, потому что ты можешь слить информацию. Мсколько вот курсор он куда-то её передаёт или отдаёт, лез здесь какие-то настройки, может быть, или нет.
Да, во-первых, есть такое понятие, как индексирование. Ты зришь в корень. Это вопрос, конечно же, базовый. Это вопрос старта, потому что понятно, что есть коммерческие всякие тайны. Особенно об этом беспокоятся разные финансовые компании, банки, понятное дело, потому что они постоянно имеют дело с платежами, там, с финансовыми потоками. Вот для нас это в меньшей степени актуально. Я имею в виду для нас, как для екомы, да, для нас это в меньшей степени актуально, потому что наш набор функциональности, по большому счёту по бизнесу секретов не представляет, да, там вот курьер побежал по карте, вот у нас нам надо там корзину собрать, вот нам надо там дальше куда-то там эти данные прокинуть, и платежами мы фактически сами не занимаемся, как ты знаешь. Мы отдаём это на как будто бы на аутсорс, на самом деле. Вот. И внутри приложения мы не храним никаких ни токенов, ни секретов, ничего такого. То есть скучно мы с тобой живём. У нас с тобой нет никаких секретов в приложении. Мы никуда их не не храним, не сохраняем, там ни не в usю usердефолсы мы их не пихаем, ну, в общем, всё по технике, всё как надо, всё, как Apple научил, да, как говорится. Вот. Возвращаюсь к курсорум для того, чтобы понимать, как работает индексация, поиск, работа курсора с кодовой базой после индексации, рекомендуемые термины для изучения, дерево меркла, эмбединги, ну, и, наверное, всё. Вот стоит вот эти вещи изучить для того, чтобы посмотреть, как работает курсор с кодовой базой, потому что, ну, не секрет понятно, что курсор в облако отправляет какую-то информацию. При этом для курсора, что важно ещё про настройки мы не сказали одну вещь, но это очень важная вещь для э курсора. Важно, что мы вот здесь в у нас есть настройкаркпейса, и желательно с самого начала работы вот этот Workspace ограничить. Это особенно актуально там, где присутствуют, как у нас, например, да, монорепы, например, присутствуют, да, и для того, чтобы курсор там не искал везде и всюду, да, потому что это действительно вопрос безопасности. Это вопрос не только безопасности, это вопрос ещё и нагрузки на инфраструктуру. Для того, чтобы такого не было, мы ограничиваем наше рабочее пространство. Все, кто не может, они как-то по-другому выходят из этого положения, потому что есть инструменты поиска и так далее, но это уже выходит за рамки курсора. Просто про индексирование, базовые правила безопасности работы с мобильным приложением. Вот там недавно мы проходили тренинги по PCSS, сдавали, да, это то, что касается карточных платежей в мобильном приложении. Вот базовые правила безопасности никто не отменял. Это зависит не от курсора, это зависит от нас. Мы не храним секреты, мы не передаём там номера карт, мы там не храним сенситивные данные, персональные данные пользователей и так далее. То есть это базовые правила безопасности. Они к курсору не имеют никакого отношения, по большому счёту. Курсор - это просто инструмент, который там индексирует нашу базу, а, кодовую, буквально её шифрует и сам для себя какие-то куски только, э, скажем так, дешифрует для того, чтобы какую-то логику анализировать. Поэтому всё начинается с разработчика, всё начинается с нас. Не храним секреты в приложении, следуем правилам, рулм, гайдам и так далее.
>> Угу. Тогда, правильно понимаю, здесь курсор никуда ничего не сливает. У него локальная индексация, и если даже есть какая-то облачная, это всё можно ограничить, какие-то сенсивданные, просто говорить курсору, чтобы он их не трогал, либо их желательно вообще убрать из проекта.
>> Вот у нас есть файл такой же по аналогии. Курсор работает с системами контроля версий по аналогии с гитом, поэтому есть файл курсор игнор, и в него мы можем прописать все конфиги, всё, что у нас там какие-нибудь какие-нибудь апи ключи могут, естественно, где-то там лежать. Вот всё это мы прописываем там в курсор игнор и и всё, все эти папки, где это всё лежит. При этом, естественно, мы там нигде не светим. >> Угу. Хорошо. >> И сегодня не будем светить.
Это, да, это важная вещь получается. Ээ, если это всё безопасно, это прямо сильно нам развязывает руки, и тут мы можем спокойно уже, а, делать какие-то классные вещи. Вот я опрос проводил в канале и почти что более 70% опрошенных, э, там, по-моему, из 600 человек считают полезным использование аишек. Когда ты занимаешься какими-то археологическими задачами, да, как ты выразился, очень классно, рефакторингом и архитектурой. Вот как ты думаешь, это правда или всё же аишка здесь не очень хорошо справляется?
>> Да, я тут ээ перехожу вот в конкретно в, например, А, кстати, я могу показать ещё одну команду полезную, пока мы далеко не ушли от этой темы. >> Давай, давай. А >> полезную команду в клоде, которая с клодом ещё проще, чем с курсором, потому что курсор, если там надо настраивать Workspace, то в клоде есть команда Инит. CLД, как известно, мы запускаем код мы запускаем из папки проекта, то есть непосредственно находясь уже на нашей кодовой базе адресно. А вот поэтому энициализируя, мы формируем файл такой базовый. Есть у клода есть файл clдmd, который мы можем дальше редактировать, э, там все правила дописывать, какие-то условия наши дописывать и так далее. То есть для клода это делается одной командой. Если для курсора там надо пасы отдельные прописывать, то здесь, э, всё это происходит таким образом. Да.
Возвращаясь к археологии, конечно, для большой кодовой базы это очень важная история, потому что когда мы вливаемся в проект, когда нам нужно, а, что-то найти, сориентироваться, то есть, например, там фича, которая затрагивает там корзину, меню, логистику, всё на свете, там какие-нибудь адреса, нотификации и всё прочее, мы можем просто попросить, ну, например, например, например, вот видите, у меня там история всякая разная. есть интересная. Вот, ну, скажем, вот у нас был была задачка, когда я, например, там первый раз, по-моему, я проник в корзину. Вот я пошёл смотреть, мм, как у нас строится взаимодействие с, а, между сценариями, между а большими модулями приложения, разбросанными ещё в разные места. Вот. А тут мы, э, что-то что-то у нас тут было много всего. А, но самое главное, что со старта, когда был, а, когда мне нужно было построить, а, большою, там, скажем, представление, я имею в виду высокоуровневое представление составить о том, как работает апии там корзины, да, то я попросил вот, в частности, сейчас остановился я, да, я попросил LLM дать мне представление о том, как устроена мутация корзины, да, потому что это сложная история, потому что она синхронизируется, потому что там есть ответ бэкэнды, есть хранимые там сущности и так далее и тому подобное. И в итоге для того, чтобы реализовать свою логику, а встроить э там элемент определённого вида в корзину, я попросил ЛМ дать мне представление. И после, ну, там, буквально там минуты, да, у меня была картинка перед глазами после минуты размышлениям, естественно, ты понимаешь, исходя из опыта, что в ручном режиме я бы это раскапывал гораздо дольше. Вот. А сейчас благодаря I инструментам у меня есть возможность там за минуту получить этот результат и дальше сидеть только это читать как книгу, что у нас происходит, какие мутации, где я могу что встроить, э, какие параметры передаются и так далее. То есть я вижу весь АИ, я вижу все интерфейсы сразу и понимаю, что да, вот сюда я могу, а вот сюда я не могу. Здесь что-то надо придумывать. Таким образом, решение вырабатывается в голове довольно быстро. И я там сращиваю условно там два сценария, ну, то есть работаю как архитектор фактически, да? То есть я так высокоуровнево вижу это всё, что происходит, как происходит, куда, что, с чем дружит и не дружит и так далее. Вот это, говоря об археологии. Могу ещё что-то показать.
>> Да. А есть, может быть, какие-то советы, как использовать грамотно аишку, чтобы она лишнее что-то тебе не говорила. Может быть, как промт писать или как-то задать и, ну, или, может, базовые какие-то советы? Стоит ли вообще это делать? Заморачиваться или аишку уже нормально просто в двух предложениях, если ты ей напишешь, как объясни мне, как работает корзина. Корзина там дисклеймер - это погрузился в корзину. А Максим сказал, это корзина в проекте, да, экран корзины получается. И ты получается просто написал промт, и он тебе всё выдал. Здесь никаких проблем нет. И тебе прямо этого было достаточно, я правильно понимаю?
>> Вот. Да, хороший ты вопрос задал. очень важный, на самом деле, потому что есть сейчас раньше было четыре пункта в инструкции по работе с, и сейчас их осталось три, потому что план первый пункт был Explore. Так вот, э, сейчас, в принципе, Explorer ушёл, потому что есть такой режим работы с курсором и такой же точно, кстати, режим работы с клоуд-кодом, как план для курсора. Можно явно отметить это просто вот нажать и Shift табом, например, переключить. И будет план. Если говорить про клодкод, там всё просто. Клоду можно просто сказать, э, пока мы составляем план. Просто словами, ничего больше. И клод рисует план. То есть сказать там, сделай план по фазам там исполнения. И в этот план можно дальше дорабатывать, анализировать его. Вот. Ну, как пример прампта, да, учитывая, что у нас вся индексация настроена, все рулзы проекта настроены, прописаны условия, все, что нужно общие. Я иногда пишу по-английски, иногда по-русски. В принципе, разницы большой нет, потому что нормально интерпретируют сейчас и русский, и английский. Всё, всё, всё хорошо. Не заметил я, честно говоря, разницы в качестве ответов. Ну я там обращаюсь, я говорю: "Вот там есть апии, посмотри на этот апии, расскажи мне, что происходит. У нас так-то так-то формируется запрос, ээ, вот там, расскажимне, расскажи мне дальше". Дальше э мне нужно погрузиться, то есть когда у меня есть высокоуровневый ответ общий, дальше мне надо погрузиться в какие-то там детали реализации. Я говорю: "Давай, давай про mutation мне расскажи, что там внутри этого mutation процесса происходит". Ну и, соответственно, я вижу, что вот что происходит внутри mutation процесса. И дальше я для себя понимаю, что вот на этом этапе там мне нужно будет вот это, вот это, вот это и так далее. То есть итерации важный вопрос. Это это вот ты задал очень важный вопрос, потому что итерации решают а потому что не всегда мы получаем с первого раза прямо идеальный ответ. Для этого существует план мод. Сейчас можно итерации проходить через план мод. То есть мы план составили, посмотрели, нам он понравился или не понравился, подправили его, сказали: "Измени план, доработай его". И после этого там у курсора есть кнопка build. Просто >> значит по-хорошему лучше не писать огромный большой план сразу, а итерациями в диалоге с аишкой стараться уточнять и тюнить его в процессе. Правильно я понимаю?
Да. Вот пример, >> да. Вот смотри, вот он я вот пример плана привожу здесь. Сейчас лок мне немножко мешается. в принципе могу закрыть. Ну, например, там там на что-то надо поддержать в методе, там это древняя апии, в который там годами никто не лазил, там код какой-то двадцать первого года, в общем, тоже, думаю, уже не секретный давно. И самое главное, что у нас есть, у нас есть кнопочка build. Обрати внимание, вот здесь, да? А, то есть когда мы вот здесь в с агентом поработали и доработали план, агент нам выдал выдал план, сказал: "Вот делаем так". Вот проверили сценарии. Я просмотрел сценарии, значит, там провёл кодревью изменений. Я вижу, что, ну, ничего критичного быть не должно. Мы там используем, например, базовые сущности, базовые типы для того, чтобы работать. Выносим нашу логику сепарированно, то есть separation of concerns, соответственно, применяем, да, принцип. И если мне это нравится, то я это просто запускаю в работу, и это происходит уже там автоматически. Также точно, кстати, а можно там не не условно там не нажимать кнопку. Може можно нажимать кнопку, когда у тебя там три изменения, да, условно, когда у тебя шесть фаз, шесть стадий в плане, в реализации, то можно сказать: "Давай фазировано, первая фаза: раз сбилдили проект, посмотрели, ничего не упало, всё работает, логика вроде бы не отваливается". О'кей, поехали дальше. То есть это такой, ээ, нормальный ступенчатый процесс по постадиный.
>> Круто. >> А значит, ты выступаешь в роли такого оператора, которого валидирует предложение нейросети, аишки, да, смотришь на её адекватность, плюс ещё и ээ рулсами, промтами уменьшаешь степень галлюцинации и всяких температур. Правильно я понимаю?
>> Да. Я бы сказал так. На текущем, если это было актуально, вот знаешь, всё очень динамично. Вот ты знаешь, да, что сейчас всё очень быстро развивается в мире АИ. В мире АИ применительно к кодингу. >> И если на предыдущей, например, версии той же модели, вот вы увидите здесь вот в истории, у меня Zо 4 модели используется. Сейчас мы уже используем модель Zо 4.5, которая вышла осенью. И я бы сказал, это был качественный скачок. Просто вот модели от антропика, которую мы используем, у них с каждой итерацией, с каждым релизом происходит, в общем, качественный улучшающий скачок, я бы сказал, в работе с кодом. Первое время меня это даже слегка, э, так поражало, ну, приятно поражало. Я так думаю, ну, раз там написал промт короткий довольно, а модель мне говорит: "А, ну, это вот те изменения, которые ты сделал там вот в этом последнем комите". Так что вот должно по идее быть вот так. И меня это несколько так, я думаю, ну всё, наверное, дальше, завтра уже я буду не нужен. То есть [смех] всё, робот заменил человека. Вот. Ну нет, это шутка, конечно, потому что в большой кодовой базе мы должны контролировать. За человеком остаётся целеполагание и контроль. Две очень важные функции всегда. Это важно помнить. Мы не отдаём на откуп ЛМ решение и ответственность никогда, потому что в конечном счёте это наши задачи, в конечном счёте мы будем нести ответственность за то, как это будет работать. Да и не там спишет ли приложение вместо 100 руб. 1ты000 у кого-то, да, за бутерброд. Вот поэтому здесь важно понимать баланс. Баланс всегда баланс. То есть, да, мы можем сказать: "Сделай красиво" и получить план на 10.000 строк. Но потом, ты сам понимаешь, тяжело ревьюить это, тяжело
разбираться с этим, тяжело. Поэтому контроль вот в этих чанках у нас всё равно должен оставаться. Мы всё равно базовогу >> ориентируемся на какой-то удобоваримый размер там комита для того, чтобы самим чётко понимать, где где там может быть ошибка, да.
>> Угу. Да. Тогда сейчас подсушу. Получается, в вопросах археологии мы должны не слепо верить даже аишке, даже какая бы она умная ни была, она всё равно может где-то загаллюцинировать, затупить или что-нибудьши ошибиться. Мы просто, э, свой э рутинный труд делегируем ей, но при этом не уменьшаем качество внимания и следим за всем, что она написала. Не нужно ей доверять и не нужно не всегда верить, да, я правильно понимаю вот в этом вопросе?
>> Да. И тут решает опыт, конечно, потому что иногда я отлавливаю ошибки условно на уровне интуиции. То есть это иногда бывает просто так. Вот ты сидишь, думаешь: "Так, стоп, вот здесь не пришло, не ушло, не отдалось". Но ведь это должна быть какая-то совершенно банальная ошибка. Это должно быть что-то такое, что даже промпта не стоит. И там идёшь в эту точку кода и понимаешь, что да, вот здесь там должен быть опционал по-хорошему, а мы там пустое значение прокидываем. И вот, да, ты понимаешь, что и, конечно, да, пишет код, но, э, вот эту логику какой-то в мелочах в каких-то там в деталях, да, потому что, ну, мы знаем, где ломается, да, логические построение наши, там флоу наши сценарии, да, мы это отлавливаем, да, конечно, мы это ревьюем, естественно.
>> О'кей, спасибо. Так, давай дальше пойдём. Археологии поговорили, про архитектуру мы затронули. Пойдём дальше, получается, >> да?
Ну, я считаю, что мы с тобой много уже поговорили про про специфику, да, я бы ещё показал вот, например, вот такую задачу я бы показал. Э, это была большая задача, связанная с тем, что мы там интегрируемся, там приложение Яндекса интегрируются друг с другом. У нас вот это вот вот постоянное движение присутствует. Мы постоянно там в этих технологиях, мы ещё поговорим с тобой про BDUI, да, там немножко позже, но вот в части технологий, там связанных с SDK и так далее, мы, >> да, сейчас контекста добавлю.
Получается, ну, SDK для наших слушателей. Те, кто не в общей доменной области, не в общем контексте, это такие штуки, которые в Яндексе мы не просто пишем свой код и нигде не используем, да. Все команды, условно музыка, Кинопоиск, Яндекседа, Яндекс GO, они шарят и делят друг другу свою логику и живут не в одном месте, а во многих местах. Из-за этого логика и переплетения, и зависимости очень сложные. И интеграция тоже довольно-таки непростая. Продолжу, пожалуйста, Максим.
>> Да, тут я просто добавлю. Мы с тобой говорили как раз про архитектуру. Это очень важная история, потому что всё-таки кодовая база, что не говори, когда у нас кодовая база - это сотни тысяч строк, э, мы больше работаем с и часто, скажем так, не то что больше, часто мы работаем именно с какими-то верхнеуровневыми историями, там сборка проекта, большие какие-то задачи, связанные с интеграцией модуля, как это завязать. Особенно, если модуль должен работать и взаимодействовать. Там у нас есть такие модули типа там, не знаю, там корзина, например, которая всем отдаёт цены, которые там единый источник правды там для количества там товаров, да, которыми оперирует пользователь и так далее. А блюд. Вот также точно там адреса и и так далее, и так далее. Реклама, в частности, да. Ну и аналитика, естественно.
Вот, в частности, вот в аналитике там задачи, связанные с перемещением больших крупных модулей, которые прорастают везде, потому что аналитика у нас же везде присутствует. Очень удобно с ЛЛМ, очень удобно с АИ работать в части как раз вот таких вот такого планирования, когда мы можем любой э крупный проект пойти с самого начала, там от самого там корня дерева и выстраивать его также точно разбивать на фазы, также точно планировать итерации, смотреть, отслеживать моменты, например, связанные. Вот, кстати, очень важный момент, который у нас для большого проекта. Вот я тоже про специфику скажу. А, DI, да, есть, например, в любом большом проекте все бьются за DI, что использовать. Там те библиотеки, эти самописные, несамописные, как этот DI у нас устроен, какие-то там вложенные контейнеры или не вложенные или единый DI, единый какой-нибудь об object, который за всё там отвечает и знает про все зависимости в проекте. Так вот, а в зависимости от того, что нам нужно, мы на большом проекте формулируем эту задачу и идём дальше смотреть, скажем, какие-то базовые вещи, там, например, перемещение, там перемещение разделение там консёрнов, имплементеation и appi каких-нибудь создания прокси и и фабрик. Это о'кей у LM, да? А ну, например, DI lm видит не очень хорошо с первого раза, да? Вот я-то уже с этим столкнулся, и я понимаю, что, ну да, надо, значит, вот в этой точке больше усилий, приложения усилий для того, чтобы там объяснить, да, что-то там конкретизировать, там, скажем, раскрыть эту тему больше, дать больше контекста. Э-э, тут я уже сейчас, наверное, не найду это, потому что у нас довольно довольно большая была работа по этому м по по этому вопросу, по этой теме там, по формированию, вот, в частности, да.
>> Угу. Это SDK, это получается наши dependenнcy, зависимости, >> да? Обозначение обозначение зависимости. Тут всё о'кей, тут всё всё всё нормально, да? Ну, там были моменты, связанные с DI, потому что нам надо понимать, что мы там в контейнере правильно прописываем свои зависимости. И это было там, я помню, что вот в контексте этой задачи это был там момент, который надо было прояснить, да, с лм там чётко обозначить и скажи: "Ага, подожди, вот здесь вот у нас контейнеры с ассоциированным значением, там надо нам вот использовать вот это и вот это. Давай посмотрим, как это устроено". Вот. И вот здесь у меня прямо в этой задаче, на самом деле, поверьте на слово, есть прямо красивая схема, которую в итоге мне LLM рисует по эму, как наши зависимости работают. В части этого, кстати, я добавлю и вот и закончу на этом сейчас про вот эту тему, наверное, закруглим про документацию. ЛМ очень хорошо пишет документацию, поэтому вот такие большие задачи, когда нужно зафиксировать результаты, описания, схемы, всё это дело оформить. LM очень хорошо, а е инструменты очень хорошо справляются с этим, >> кстати.
Да, ну тоже зафиналю. Не в Яндексе и не в еде я этим, э, пока не не глубоко копал, как работают другие проекты. Вот это очень важная вещь, да, что мы можем архитектуру или археологию изучить не просто взяв э- проект ээ тягущий и в него погрузиться, а можно по сути в любой и переиспользование чужого функционала или погружение в этот чужой функционал очень хорошо работает. У меня это было с телеграмом проекта, когда мне нужно было несколько лет назад изучить, как работают там, получается, звонки в Телеграме. Я тогда помню руками это всё делал, сидел, смотрел, сидел, смотрел, изучал. Очень всё сложно было. И просто уже на контрасте недавно я тоже опять что-то туда полез. Хотел посмотреть, как работают коллекции. Скролл быстрый, перформанс, оптимизация, потому что, ну, Telegram довольно-таки, всем мы почти, наверное, пользуемся, и у меня там канал, что бы я без него делал. И вот, ээ, я хотел посмотреть, как, ээ, Telegram отрисовывают их, все нюансы изучить, и просто скормил его в проект курсору. написал ему промт: "Опиши мне, как работает Telegram с коллекциями, и выведи документацию, чтобы я это всё понял". Да, он мне это всё сгенерировал, я это всё прочитал и легко сделал, вдохновился, взял референс и сделал в нашем проекте там фит. Ну, потом когда-нибудь он, наверное, зарелизится. И вот к чему я говорю, да, правда, на самом деле на контрасте я вспоминаю, как я залезал, а когда даже участвовали мы в Telegram-конкурсе, одна из самых сложных задач - это погружение в текущую кодовую базу Телеграма. Там почти что 50% разрабов на этапе конкурса отсеивалось только из-за того, что они не могли прочитать код Telegram, потому что, ну, кто видел его исходники, там довольно-таки всё сложно и, ну, а понятно, аккуратно, но довольно-таки сложновато и нагружено. И здесь вот, мне кажется, сейчас те же конкурсы Телеграмма на изучение интеграции в существующий проект с помощью в разы легче.
Да, вот тоже подытожу, >> да, тулинг - это важная вещь в нашей работе. А становится прямо полноценным даже не просто инструментом, да, а тут мы с тобой тоже хотели поговорить про >> Да, да, мы хотели поговорить про генерацию моделей. Я помню, ты делал даже на работе классную штуку, связанную с вагером, да, и ты его починил, можно так сказать, в какой-то степени даже улучшил. А можешь поделиться вот этим опытом?
>> Да. >> Да, я надеюсь, сейчас вот мой экран тоже видно. Спеки для кого-то они, наверное, не представляют проблемам, потому что я там работал в таких местах, где были системные аналитики, которые рисовали очень красивые спеки, вставляли туда экраны и так далее. Да, не все нас так балуют. Иногда спеки просто оформляются, там какие-то старые спеки могут вообще не содержать актуальных данных. Иногда спеки оформляются просто там, а, аямликами. Ну, в общем, я не очень люблю аямлики. Я люблю всякую красивую визуализацию. Поэтому в определённый момент я подумал: "А почему бы не попробовать, собственно говоря, с помощью lлм написать такой тул, который там из наших этих ээ разрозненных аямликов сгенерит что-то более-менее красивое, да? И вот в итоге у меня получилось такое, ну, это там локальная история, можно, конечно, этот инструмент дальше там дорабатывать и в продакшн запускать. Ну, у меня получился такой Свагер лучше, чем Свагер в итоге, потому что мы знаем, как выглядит отображение с помощью Свагера, да, Open Да, это к вопросу документации прямо очень важная вещь, потому что контракты и коммуникация с БКОМ - это одна из важнейших. Туда понимает, как если даже в одном поле ошибёшься, у тебя может там крашнуться всё приложение или сломаться полностью. Это прямо про документацию, да, получается. А на насколько эта документация помогла тебе вот сгенерировать опислой? Я вот слышал, некоторые ребята уже прямо полностью автоматизировали свою работу, что они почти что не пишут ни нетворки, ни запросы, ни модели, ни дтошки. Насколько реалистично вот с этой моделью и насколько точно Аишка справляется тоже для генерации
>> с точки зрения, да, сейчас вот пару слов про тулинг и про документацию. С точки зрения документации, я бы сказал, это просто идеальный вариант, потому что он лучше, чем Свагр, потому что там, ну, есть моменты, связанные, скажем, с инамами, которые Свагер не распознаёт, да. Вот можно попросить и достроить что-нибудь там из серии, что у нас будет там какой-нибудь в респонсе, например. Вот скажи вот вот здесь, например, кейсы и намы, да? Я говорю: "А, а сделай так, чтобы вот у меня модели всё-таки отображались описание апи, чтобы у меня ручка отображались все эти типы там в отдельных каких-нибудь местах. Вот, чтобы я не ручками это искал". и совершенно спокойно мне там достраивает по аямликам э всё, что нужно. LM то есть в этом смысле АИ очень помогает. То есть даже на локальном уровне можно сделать себе там пайтоновский скрипт и всё. И в общем сидеть спокойно. И я даже там пользуюсь иногда, что я там коллегам это перекидываю, чтобы, ну, удобнее было смотреть. Ну, кому-то, конечно, аямлики нравится.
>> Ну да, тут здесь более такой человеческий язык, скажем так. О'кей.
>> С точки зрения генерации нетворка, сейчас я ещё раз вернусь к курсорум. Да, с курсором у нас такая история, что, в принципе, мы ка-нибуд там какие-нибудь ДТОшки, да, мы их запросто генерим. Вот видите, насколько короткий скрипт здесь. То есть просто вот я отдал а адрес, где надо взять спецификацию. подключена конкретная папка с нашими там спецификациями в воркпейсе курсоры и дальше просто там короткий скрипт, что сделай по спецификации модельку сетевую. Вот мы их там ДТО, да, мы их традиционно называем. Всё, в общем, в общем и целом. Обратите внимание, что там с нашими, со всеми форматированием, с документацией, со всеми пирогами, в общем, э нормальная, подробная модель, в принципе, генерируется, да. Что касается тут, наверное, это выйдет за рамки нашего обсуждения. Что касается всякой автогенерации сетевых моделей, для бэкэнда это работает у нас. Да, для iOS и для там Андроида, для мобильных платформ мы по-прежнему пока не смогли договориться, потому что спеки у нас довольно разбросанные и довольно сложные. И в общем, можно когда,
>> ну, в целом реалистично, да, получается, да,
>> в целом реалистично. Я я знаю вот в предыдущем моём месте Авито. Я передаю привет. А там ещё долэмки договорились. Ну там попроще. Там весь БК стандартизировался на единый формат. Там меньше такого, конечно, хаоса из зоопарка, но там тоже почти что вся работа ещё долэмок была на основе, а нового там АИК, которой вышло в прошлом или позапрошлом году, когда Apple помогло через Open AP генерировать модельки. И там вроде бы прямо отдельный проект тоже. Но мне кажется, с аишками сейчас это всё стало гораздо проще. Тут единственный момент, да, наверное, организации, договорённости на уровне всей системы бэкэнда. А так всё очень реалистично получается. Есть ли что-то ещё может добавить
>> про networkк, про генерацию? Здесь всё, как видите, довольно просто, потому что когда LLM видит вашу кодовую базу, она сразу подхватывает аналоги, она сразу видит, как это у вас организовано. Я всех призываю пользоваться. Это очень быстро, очень эффективно. Никаких проблем вообще.
>> Это да. Вот я тоже считаю, что рутину на описание контракта и сетевого слоя это сильно ускоряет. И чаще всего, ну, мне кажется, написание логики для вызова IP сервиса, ну, не составляет очень много творчества. И здесь очень можно очень много эту рутину сократить. А вот ещё давай вопрос про следующий. Тогда, если мы закончили про network рутину, это UI.
[смех] >> А, довольно-таки кальварная вещь, да, многие по фронт мобильные разработчики считают, что очень много творчества в юае и нейронки, аишки никогда не смогут заменить разрабов. Это всё, ну, довольно-таки сложная вещь. В какой-то степени я, может быть, с ними соглашусь, если это какая-то тоже сложная, да, layout система. Тот же BDUI, возможно, если которая написана разных технологий. Ну, тоже это, наверное, спорно. Вот как ты думаешь, насколько хорошо аишки справляются с Юаем? И что здесь можешь рассказать?
>> Да это же наша базовая тема, мы же, как говорится, что >> кратим кнопки. Да, да, да, да, да. Мы даже у нас даже доклады есть и очень хорошие, кстати, доклады есть на конференциях про перекрашивание кнопок и что за этим стоит. Пользователь часто не подозревает, что за нажатием или не нажатием, да, на кнопку там может происходить там целый целая цепочка вызовов, там как-то сложная логика и так далее, в зависимости от того, в каком месте мы находимся. Вот так вот. Что касается юая, я бы сказал, что тут есть два подхода. Вот, во-первых, мы сейчас ещё с тобой не говорили про MCP, а MCP - это важная составляющая работы над Uем. для нас, в частности, в том, что касается Давай откроем экран с MCP и посмотрим, а что у нас тут есть, да? Вот у нас есть такой Figma MCP. Мы его можем подключить, он у нас даже подключится. И мы можем видеть, что тут два метода мы можем использовать, да, Download Figma Images и Get Figma Data. Так вот, базовый метод вот этот вот Get Figma Data. Там на токен не обращайте внимания, он протух уже давно, его надо обновлять постоянно, поэтому тут никакого секрета нет. Да, кстати, имейте в виду, что когда работаете с MCP Фигмо, токи надо обновлять довольно часто. Смысл в том, что, ну, это редоунли методы, которые позволяют вытаскивать из Фигмы данные. Наши коллеги по Яндексу обратили внимание на то, что когда начали работать с U, собственно, там нам всё равно, да, UI Kids, Swift UI, э, кстати, lm со Свиф Uм, наверное, немножко лучше справляется, чем с UI китом, что, наверное, связано с тем, что АI всё-таки новый инструмент и обучали его уже на новых технологиях, хотя и UI Kit тоже ему, в общем и целом покоряется, я бы сказал.
>> Расскажу, >> да. А вот я слышал, что лмки именно Cloud Code лучше работают. Swift UI и Vertide Cд, например, лучше того же курсора. то, может быть, тоже эту тему затронешь и если есть что-то рассказать, ну, потом или сейчас, потому что я слышал, что тот же Cloud код, он из-за того, что не ограничен, ну, миф это или нет, я не знаю, не ограничен дэшкой и его другими там какими-то лишними штуками, он вот в вёрстке гораздо лучше справляется, чем тот же, если его использовать из курсора, например, те же модели.
>> Знаешь, я думаю, это зависит всё-таки от размера контекста. И вот я продолжу свой рассказ, потому что он как раз про это.
>> Давай, давай. Спасибо.
>> Вот наши коллеги ээ из Яндекса обратили внимание, что Фигма отдаёт огромные простыни кода. Вот когда мы запрашиваем через MCP, да, то есть если мы заходим в условную Фигму, сейчас там не буду ничего шарить из Фигмы. Но все видели Фигму, все видели экраны в Фигме, да, и сколько там может быть разных элементов динамических, в том числе там коллекции и так далее, и так далее. какие-нибудь там сложные переходы и, в общем-то, всё, что там дизайнеры придумывают, включая цвета, шрифты, вот всю типографику, всю вот это вот всё, да, мелочи, э мелочи, там всякие отступы. Так вот, Фигма отдаёт очень много данных, то есть они фактически иногда и часто даже не влезают в контекст по факту. Поэтому что курсор, что клодко, наверное, тут будут страдать одинаково с точки зрения переваривания этого контекста. Так вот, наши ребята, коллеги придумали DSL, да? То есть domain specific language, отдельный язык такой, протоязык, метаязык, который позволяет перерабатывать сначала. Ну, потому что это Open AP для Фигмы, да, они дёргают условно ручку Фигмы и всё, что вот эту простыню, которая Фигма отдаёт, они её просто на чанке, например, бьют, да, дальше оборачивают вот этот DSL понятный lm, потому что lm хорошо работает с любым языком, символьным. Дальше это позволяет обозначе, ну, то есть там, если понимает, как устроена история внутри э там этого DSL, да, что мы обозначаем чем, а то дальше, э, LLM проще работать с этим объёмом контекста, и LLM фактически отдаёт тебе, ну, ближе, гораздо ближе результат отдаёт, чем если бы мы скармливали туда сырой контекст и ЛМ путалась бы в этом контексте, потому что всё-таки размер контекста решает. Вот для того, чтобы в clд-код посмотреть размер контекста, есть команда сшконтекст. И вы можете увидеть, что когда у вас контекст начинает забиваться, когда вы начинаете там близко к лимиту уже работать, то там начинаются какие-то оптимизации и может там не совсем быть уверена в ответе.
Значит, я правильно понимаю, что лучше привёрстки не копировать или скриншотить макет а из Фигмы и отдавать курсору как файл, да? А подключайте фиг MCP и так намного точнее и лучше будет вёрстка, я правильно понял?
>> Да. >> А нет, >> а вот нет. Да. А я бы сказал, что LLM примерно одинаково понимает скриншоты, анализирует. И даже в руководстве, например, по клодкоду там так написано, что если вы берёте через MCP данные для юая, то дальше, когда вы что-то сделали, когда у вас есть результат вёрстки, отдайте скриншот LLM, чтобы она могла проанализировать его. Я таким образом экспериментировал с экраном. Не знаю, найду я сейчас или нет, постараюсь потом.
>> Ага, да, ну, может, ставим потом. Ага, >> да, именно скриншоты. А, но я бы сказал, что удобнее работать с юам именно по кусочкам. То есть вот, например, баги в юае легко вообще. То есть там, где я понимаю, где это, да, но, скажем, это какие-то инсеты, это какие-то там сочетания каких-то э разных модулей, сочетание разных контроллеров, элементов и так далее. И особенно, если это впрямую там не касается, например, да, там рабочего процесса, да, какие-то баги, которые надо починить просто походе, да. можно дать это ll это спокойно анализирует по скриншотам и там, например, даже скриншотом дебаггера, то есть тоже вот наш баг, наш viwдебагр lm тоже анализирует очень хорошо. Я с этим экспериментировал. Могу сказать, что да, тоже классно работает. То есть
>> получается всё же. Ну а зачем нам Фигма MCPшка? Она больше сдаёт какого-то контекста, но финальный уже финальное решение за скриншотом, и он хорошо ест, я так понял, курсор, скриншоты, разбирается в них. Вот почему-то мне всегда казалось, что если я отправлю тот же скриншот, ну, он какую-нибудь хрень мне выдаст. Извиняюсь за выражение. Но всё же ты говоришь: "Нет" и неплохо даже, да, справляется.
Ну вот смотри, например, да, был у меня там недавно вопрос связанный с скриншотами, связанный с как раз работой с Фигмой. Я выгрузил для лмки образцы дизайн макета и быстро получил ответ тот, который мне нужно для того, чтобы, а, для того, чтобы поправить там какое-то там визуальное несоответствие. Вот. Ну, это было в качестве, конечно, больше в качестве эксперимента сделано. чем реальная работа, потому что там, ну, не настолько там требовалось интеллектуальное напряжение вот для того, чтобы это поправить, вот падинги. Но мне было интересно просто само по себе, сам по себе был интересен процесс с научной, так сказать, точки зрения, э, насколько чётко отступы всё всё это проанализирует, поймёт. То есть я могу сказать так. Если вы хотите верстать какие-то элементы именно в там какой-то у вас есть сложный экран, да, вы как архитектор к этому подходите, там сплитуете этот экран на какие-то понятные блоки, а то какие-то более сложные блоки можно доверить вёрстку LLM, и она, в общем, с этим справится. Просто делать это поблоково, не не целиком, там весь контекст в неё вгружать, а делать это по частям.
>> Угу. А ты ещё вот я когда только первый раз пришёл, рассказывал про анимации, да, и говорил, что можно кормить туда гивки. И она неплохо даже или плохо, я вот точно не помню итог, насколько она хорошо ест анимации
>> гифы, да, тоже ест, да.
>> А почему не видео, а почему именно гифки?
>> Ну вот ограничения есть.
>> Ага. Ограничения.
>> Вот аппаратное ограничение пока. Да. А, всё понял. Лучше, значит, отдавать гифками. Хорошо. Тему UI можно дальше продолжать и рассказывать про BDUI. как это работает с BDU и всё остальное. Сложные перфомансы. Вот мне конкретно даже иногда помогает накинуть идеи, не написать, конечно, вот сложный UI, он всё-таки ошибается и с теми же отступами, я тоже согласен. И если сложные вычисления у тебя, сложная лента и ещё у тебя там видео, аудио, он здесь может прямо какую-нибудь иногда хрень выдать. Но чаще всего 70-80% рутинной вёрстки он прямо уже задаёт. И очень легко на этом каркасе и на этом прототипе сделать какую-то хорошее, готовое решение.
>> Да. Да, всё так, всё так.
>> Так, ну, если у тебя по теме, а, UI ничего нету, давай пойдём к MHCPшке, как ты уже сказал. И здесь вот ты выделил, что это важная тема.
>> Да, MCP важная тема. И важная она тут мы это про проиллюстрируем, естественно, с тобой, как вообще, что такое MCP, как он участвует, да, в в какой на какой стадии подключается MCP для того, чтобы мы как архитекторы всего процесса разработки могли использовать MCP как источник, один из источников данных. То есть MCP - это один из источников данных. Не надо говорить о том, что никто не говорит уже, наверное, да. Вот. Ну, не думать не надо про MCP, как что это что-то такое прямо универсальное, что оно прямо всем нужно. Нет, вообще нет. MCP - это просто вот один из источников данных. Для чего он нужен? Ну, например, я покажу очень такой живой пример. Вот у нас, например, есть задачи, связанные с, а-э, пулреквестами, сwe review, естественно, друг друга любим на кодw. Вот там всяко разно это э комментировать. В чём смысл MCP в данном случае? Вот в Яндексе у нас там много всяких разных инструментов. Вот ээ я тут немножко это, да, тут всё немножко резиновое, да. Вот так вы можете там вот вот посмотреть. У нас тут есть разные наши внутренние МCшки индексовые, которые позволяют делать всё подряд: читать документацию, читать полреквесты, создавать разные тикеты, изучать эти тикеты. В общем, масса всего, на самом деле, умеют делать уже наши МCшки внутренние, потому что сервисов внутренних много, ориентироваться в них просто по документации тяжело, а LLM с помощью MCP это делает вот так. Что можно делать, например, на на там со своим код review, да? То есть я думаю, ну
Там захожу, например, вижу, что проглядываю там те все замечания. Думаю, ну, они, по большому счёту, эти замечания относятся к форматированию, к тому, что я там ифы, гарды где-то отступы эти забыл, как всегда про эти отступы, да, что надо отформатировать вот так, как и так далее, и так далее. Короче говоря, там марки какие-то забыл, там комментарии и всё, и ещё чего-нибудь.
Вот поэтому базово, да, вот промт выглядит вот таким издевательским образом в одну строчку. Вообще там пять слов, да. Просто вот: "Посмотри в full request, используй вот такой MCP". На всякий случай напоминаю, да, и всё. И дальше мне там LLM смотрит, что да, там вот ты забыл вот это, вот это, вот это. Мы сейчас это поправим. Всё.
То есть по факту MCP для меня такая подспорье получается в работе с LLM, и я могу там условно там расслабиться. Я на обед могу пойти, да, там я скажу: "Вот полреквесты посмотри мои, вот такие такие такие замечания такие, да, там вот посмотри и исправь всё благополучно". Вот. И там я пообедал, пришёл, и у меня полреквест красивый, все замечания поправлены, комментарии коллег и всё. Там даже есть там, где-то я даже видел приколы, что мне там LLM пишет, что какой-то там ревьюер будет доволен. То есть у меня даже такие вот были интересные истории.
>> Ага. Я правильно понимаю, что ты используешь, ну, у нас есть вот Арканум, это наш аналог гита, если вот кто не знал. И подключаясь через Арканум, ты смотришь айдишник реквеста своего. Ты можешь как с помощью Арканума туда добавить свои какие-то комментарии. Ты можешь поправить на основе комментариев чужих разработчиков, исправления добавить какие-то. В целом, не заходя никуда и ничего не делая, сразу же из курсора можешь весь процесс кодрев провести у себя, грубо говоря, в одном экране. В одном.
>> Да. Причём как чужого реквеста полу могу провести ревью, так и в собственном реквесте попросить поправить те комментарии, которые мне оставили коллеги.
>> Угу. Ну, мне бы, наверное, жалко токенов было, но я бы попробовал вот эту штуку. Я ещё не...
>> Э, тут, да, Лев, это это баланс. То есть, если мне жалко времени, если я работаю над какой-то там фичой серьёзной, да, например, и я не хочу отвлекаться на это, да, там условно у тебя там висит там четыре-пять там полреквестов в работе, да,
>> если, да, они не мажорные какие-то, а такие...
>> и у тебя там, да, да, они не какие-то там критичные истории про то, что ты там от архитектуры там отбился, например, да? А если это, как правило, там 95% - это комментарии из серии, что: "Давай по котстайлу сделаем" или "Давай там вот вот вот здесь ты там забыл опять, что там надо поставить условия в цикле, потому что мы это в Линтере предусмотрели, да?" То есть, если в принципе хочется, можно зайти в рулзы. Это я вот ещё не сделал. Вот вот там ту-ду, да, можно зайти в условия, можно зайти в рулзым и прописать отдельно, что а вот учитывай вот это условие там обязательно, что вот если у нас такое встречается, ну, оно там один раз там на 100 раз встречается там, что в цикле надо вот так делать, потому что условия там не надо двумя ифами оформлять, например. Всё, там, наверное, будет этому следовать, наверное, этому рулзу.
Вот ещё, кстати, тоже интересный момент. Покажу, как работает. В этом смысле у нас есть дежурство. А покажу.
>> Дежурство - это когда ты следишь за инцидентами, багами и всем остальным.
>> Угу.
>> Да. У нас у каждого там есть своя область ответственности, и мы меняемся, у нас ротация, да. Вот. И что-то там прилетают, какие-то баги, какие-то недоработки визуальные, логические, там что-то падает, что-то надо поправить по тому же самому дежурству, особенно когда это какой-то большой блок э ответственности. Можно попросить MCP, который связан с нашим таск-трекером. У таск-трекеров сейчас, наверное, у всех. У сорсных таск-трекеров тоже MCP сейчас есть. Естественно, это такая тоже вполне себе базовая часть функционала, которая позволяет тебе быстро проанализировать, что у тебя на повестке дня, распределить ответственность. Если ещё докинуть в контекст, например, распределения ответственности, кто за что, то LLM может даже рекомендовать, кому там отдать эту задачу, на кого эту задачу перевесить и так далее. То есть это тоже такой важный момент. То есть у меня в данном случае было там всего три, да, дьютика, как мы их называем, там три тикета, да, а у кого-то их может быть там 23. Это такой...
>> Ошибки, ошибки БКА, например, постоянно, которые там про происходят с там с ресторанами или ещё с чем-то, да, это прямо бесконечный поток. То есть это действительно подспорье. Это можно там отдавать это на откуп LLM, чтобы она там раз там в полдня анализировала накопившиеся и там говорила: "Ага, вот это, вот это, вот это там относится туда или там вот это мы можем сразу починить и так далее". То есть тут фантазия безгранична, зависит от того, что ты хочешь, собственно говоря, на выходе иметь. Значит, это уже такой рабочий способ, так скажем, джиромменеджмента и балансировки между своим вниманием. Да, иногда оно, конечно, важно, особенно если так критически, наверное, дьюти какой-нибудь приходит или баг, но какие-нибудь стандартные вещи, что там что-то проходят слашки, да, там время заканчивается, здесь можно очень легко это сделать.
Тут ещё про кодрев вот, да, вот классная штука, что ты сказал. Я, наверное, вернусь ещё в архитектурны тему архитектур. Сейчас очень сильно развивается тема разделения, да, вот оценок и ревью своего труда на кодрев и на архревь. Вот, мне кажется, архревь сейчас тоже хорошо бы залетело с аишками, да, ну, наверное, так как вообще в целом, потом, может, это ещё обсудим, роль мобильного разработчика чуть меняется в сторону такого архитектора и дирижёра разных инструментов. Тут и у него ещё и качается такая архитектурное мышление. И, наверное, вchрев, наверное, тоже можно вот как раз, ну, вот так. И процессы эти тоже сильно развиваются, а из-за того, что очень много зависимости, очень сильно увеличивается производительность кода, очень сильно переплетение и границы тоже размываются. Здесь можно и настроить для архреw своих, если там не знаете. Я, может, ссылку на свою статью когда-нибудь здесь прикреплю. Тут можно почитать, что разные архитектурные или mobile systemдизаign темы, они сильно развиваются. Про MCP у нас всё получается, >> да?
Ну, тут ещё у нас с тобой была темка тестов, э, которая все страшно любят писать, да, потому что ты хотел рассказать как раз как мпишки работают с тестами и вот вся эта остальная тема. И как раз, >> да, и тема тестов тоже интересная, потому что я тоже много раз слышал, что тесты очень сильно работают не просто как уже автоматизация и фиксация изменений, но и как документация и как промпт. Даже некоторые ребята берут тесты и добавляют из Андроида, условно в iOS проект, если Android первым это написал и прошёл тестирование, просто берут те же юнит-тесты, копируют в элмку и говорят: "А вот сделай". Ну, описывают всю систему архитектуру и добавляют ещё тесты. И качество ответов, говорят, очень сильно увеличивается.
>> М, ну, я скажу так, это была одна из первых задач, на самом деле, которые я реализовал с помощью LLM. А это вот можно увидеть по, на самом деле, вот на скринах это можно увидеть по ээ номеру модели, которую я использовал.
>> А я с я скажу так, что юни-тесты пишутся и, кстати, UI-тесты у нас коллеги по еде создали уже там, по-моему, мультиагентное решение для того, чтобы целиком и полностью покрывать UI-тестами наши флоу экраны, элементы и сnпшот тестирование тоже. Ну, снапшот-тестирование, оно, наверное, там, по большому счёту, даже не стоит токенов, потому что просто картинки и картинки, в принципе. А вот то, что касается юнит-тестов, то, что касается работы с там, в частности, вот мы работаем там с XC-тестом, да, традиционно, но сейчас появился новый фреймворк-тестинг. И, а, последние юнит-тесты, которые я писал на там последнюю фичу, я попробовал уже тестинг. Мне понравилось, я скажу, потому что там есть свои приятные моменты, связанные с, в частности, с описанием методов. Можно нормальным человеко человекопонятным языком описывать тестовые методы, что в в XC тест немножечко вот урезанный вариант, да, поэтому что XC-тест, что тестинг с юнитестами LLM справляется очень хорошо, надо дорабатывать, не с первого раза там получается какие-то там асинхронщину какую-то, там ещё какие-то тест-кейсы, да, ну тесткейсы мы знаем, да, мы же погружены в контекст продуктовый, в частности, да, в принципе сейчас можно даже, я бы сказал, там дальше уже экспериментировать с какими-то там БДD подходами, там behavior driven, то, что называется, да, development это там как продолжение, да, или там разновидность, да, тест driven development. Я всех призываю, пишите юниттест, начинайте с этого. Если вы думаете, с чего войти в работу с LLM, пишите тесты на непокрытые модули, потому что там я пришёл в свой там в своё подразделение, и я понял, что там юнит тестов, там конь не валялся и в общем никто их, естественно, все их страшно любят писать в кавычках, да, считают, что это бесполезное занятие. Ну нет, это не бесполезное занятие, потому что часто они спасают, особенно когда речь идёт о сложной логике. Поэтому стартуйте с юнит-тестов LLM, как говорится. Вот, пожалуйста, это для идеальная задача. Можно за день довольно большой объём перелопатить логики, который потом вам будет служить верой и правдой там, месяцами, потому что вашу логику никто без вас не порушит просто случайно, как это бывает.
>> Кстати, да, я вот часто видел, что сейчас QA специалисты начинают очень много писать тестов. Вообще пачками, так, как я говорю, так, производственная мощь чуть увеличивается, при этом стабильнее продукты становятся. И причём я ещё замечал, что QAспециалисты очень легко могут с помощью как раз сетки паутины этой тестирования понимать, где у них что сломалось. И очень легко находить даже с помощью курсора. Я даже недавно видел, что там QA специалист, который вообще далёк от iOS разработки, нашёл баг с помощью курсора, где это всё сломалось и как это починить, в какой там версии, с помощью юниттестов, по-моему. Это вообще очень очень здорово. Ну, конечно, unните должен показывать это всё на C, но при этом даже если unните там флакану или пло плохой результат неправильный выдал, то это можно ещё и дополнительно провалидировать с помощью экспертов.
>> Да. Да, всё так.
>> А по UI тестам как вообще вся эта история? Я вот встречаю, что те же снапшот-тесты очень часто ребята быстро пишут. Сейчас даже любой разработчик очень легко покрывает. Особенно у нас в Яндексе есть минимальная тема, минимальная граница, где ты должен написать автотесты, и ты не можешь выгрузиться в стор, пока там не покроешь там, по-моему, 80% тесткейсов автотестами. И сейчас даже один разраб может покрывать несколько платформ, по-моему. Это очень здорово и очень удобно. Вот как ээ...
>> Да, LLM расширила возможности тестировщиков очень здорово. И у нас у нас некоторые тестировщики уже в разработку переходят.
>> Да, я тоже такое слышал. Заменил ли их? Ну, наверное, в какой-то степени, да. [смех]
>> О'кей. А так у тебя всё получается по теме тестов?
>> Да, я считаю, я выступаю этим не то, что евангелистом, пропагандистом юнит-тестов я выступаю, да.
>> Угу. Ну, я тоже всегда, да.
>> Я считаю, что это одно из самых недооценённых вещей в мобильной разработке, потому что юнит-тесты, UI-тесты там компонентные ещё как-то можно писать легко, а вот юнит-тесты у нас, да, все забывают. У нас не пирамида тестирования, а чаще всего ромб. О'кей, спасибо. Э, Максим, очень всё было познавательно. Если вот нечего добавить, давай перейдём, наверное, к какому-то общему выводу. Много ты рассказал всяких кейсов, где можно элмки применить. Я даже видел в Яндексе уже, ну, Яндекс - это сильно развивает ваш стрим пилигрима аишки. И даже видел всякие вакансии уже у того же Райтеха с а специалистами, которые внедряют есть такое, >> да, инструменты в разработку обычных работяг, да, вот как бы платформенные разрабы писали раньше какие-нибудь селки, фреймворки, UA киты или другие либы для того, чтобы помогать, а сейчас они думают, как внедрять аи тулкиты для того, чтобы улучшать качество и скорость разработки обычных работ.
Да, для нас использование вот лучших LLM. Тут, да, пара пара добрых слов в сторону наших коллег и в сторону большого Яндекса, потому что для нас использование лучших LLM, топовых мировых, прямо скажем, да, помимо того, что в Яндексе есть свои разработки, так вот для нас использование вообще всего пула доступных передовых LLM - это часть рабочего процесса. То есть, если ты не используешь их, на тебя, не то, что смотрят косо, но так типа: "До сих пор не используешь?" Ну, это как будто как, не знаю, как кофе по утрам. То есть вот примерно то же самое. Вот поэтому в этом смысле Яндекс, наверное, >> да, ещё Яндекс >> передовая у нас, да, как бы >> мало того, что он разрешает, да, он ещё и как бы даёт лицензии. Ээ вот это очень круто, что ты можешь не за свой счёт, >> да. Да. >> А с помощью квоты получить лицензию на аишки и там и на cloud код, и на курсор спокойно и всё остальное. И вот давай тогда зафиналим. Если, э, iOS разработчик уже применяет настолько масштабно, где бизнес ему инвестирует и подталкивает всеми средствами, и тут, наверное, уже даже сложно без этого как-то обходиться, потому что, ну, довольно-таки в другом темпе совершенно будешь работать по сравнению со своими коллегами, да, и уже немножко даже чего-то будешь отставать и не понимать, почему так происходит или зачем так вообще было сделано. И как роль именно iOS разработчика, на твой взгляд меняется или не меняется ли она вообще? Можно ли обойтись без этого всего или стоит уже начинать погружаться, изучать это всё? И стоило бы, наверное, ещё раньше. Может быть,
>> Мы говорим часто есть такое популярное популярная формулировка, да, как T-sAPE для разработчика, то есть когда мы начинаем расширять свою компетенцию. И вот LLM, а и инструменты, я бы сказал, это такое прямо естественное подспорье в том, чтобы тишейпиться, да, так скажем. Э можно для себя выбрать там любое направление. Я бы сказал, что сейчас вот всё, что касается скриптов там, ну, у нас же вокруг больших проектов, как правило, много разного, разной нагрузки, да, там как собрать, как ускорить, как оптимизировать, как там профилировать и так далее, и так далее, да. И у нас, как правило, вокруг проекта масса всяких скриптов. там баш Ruby, Python задействованный, там какие-нибудь пребилд скрипты, там какие-нибудь кодыгенерация, моки, эксперименты там всякие имиджи, картиночки, там с строки и так далее, там масса переводов, потому что мультиязычные приложения это тоже вынесена инфраструктура вся, то есть вся обвязка, так скажем, проекта, она довольно большая. Кто-то этим должен заниматься. И, как правило, этим, конечно, занимаются самые опытные iOS разработчики. Так вот, LLM очень сильно помогает в этом, потому что, ну, скажем, я там не силён, например, в баш скриптах, но разобраться в том, что происходит внутри, в логике, в настройках, в построениях каких-то, использовании каких-томент переменных и так далее, с помощью LLM для меня, в общем, не составляет труда. Я довольно быстро могу это, да, там что-то запилить такое, что там поправит где-то, например, сборку на C или решит вопрос там с какой-нибудь с там прибилдом каким-нибудь, там что-нибудь там сгенерировать. Вот. То есть то, что касается Tsape LLM - это прямо то, что надо. То есть если вы хотите развиваться в этом, прямо это вот вперёд, идите в это. Да.
>> Да. И тут, наверное, ещё подытожим какие-то основные навыки или советы, как использовать аишку вообще. эффективно, потому что по-разному называют операторов АИ агентов, да, там от какого-нибудь оскорбительного вайб-кодинга до довольно уже такого про вайб-кодера, до довольно-таки уже профессионального аи инженера и уже такого более экспертного, где человек уже с хорошей базой, знанием таких крупных систем экспертизы, уникальные опытом большим, он уже умеет использовать аишку в гораздо более, ну, он не относится к этому как какой-то такой ээ игрушки. Он уже понимает всю её мощь. И тут, наверное, можно дать какие-то основные советы, да. Вот кто-то говорит: "Есть промнжениринг", кто-то говорит контекст инжиниринг. Вот что важно качать умение промтить, умение разбираться в контексте, умение вообще базу, нужно ли её качать. Как ты вот думаешь?
Знаешь, я надеюсь из нашего с тобой обстоятельного разговора, я очень надеюсь, что один из выводов будет, что промт как таковой, ээ, не играет сейчас настолько большой роли, как вот там раньше как-то уделяли этому внимание, да, потому что мы с тобой показали, что настройки правильные, что инфраструктура, которую мы создаём как архитекторы процесса разработки с помощью LLM, с помощью инструментов, там будь то курсор или клодкод, кому как больше нравится, да, кто больше нравится, там кому в терминале работает, тот с клодко код, наверное, будет ему больше понравится. Вот. Но смысл в том, что когда мы настроили эту инфраструктуру, когда мы скормили в буквальном смысле, АИ инструменту, АИ-агенту нужные правила, нужные настройки, линтер наш, там всёвсёвсёвсёвсё, что мы хотим, да, то дальше вопрос промпта, он такой как бы второстепенный по большому счёту. Нам надо просто мы для себя сами определяем, там вот расписать там - это чуть более подробно. Если мы хотим более предсказуемый результат, конечно, лучше точнее это делать, да.
Вот с точки зрения с того, с чего хорошо начинать, вот мы с тобой закончили и там на тестах, да, а я бы сказал, что начинать как раз с тестов в работе с агентами это естественная история. То есть придите в ваш большой проект, придите в вашу большую кодовую базу, посмотрите, где там слабые места, посмотрите, что не покрыто тестами, где какая логика не закрыта и так далее. Начните с этого, и это прямо естественным образом дальше повлечёт за собой всю остальную работу. По большому счёту, так я думаю. И при этом вот важно не ээ терять контекста, понимать углубленно, как работает система, э-э стараться всё равно слишком сильно надеяться на аишку, а выстраивать в голове ментальные модели работы проекта, не забывать об этом, делать какие-то речейки, перепроверки здесь. Ну, я бы, наверное, даже не сказал, что вот после даже того того, что ты рассказал, что здесь работа инженера уменьшается где-то, а нагрузка когнитивная, наверное, ещё больше увеличивается, потому что ты отдаёшь много рутины, а производство увеличивается твоего кода, и при этом тебе в голове ещё очень много чего нужно держать. Так ещё ты уже перестаёшь замыкаться в одной платформе. Ты вот, как сказал, ты можешь там и на котлине уже сейчас написать, и на баше, и там в BDUI зайти. Тут у тебя уже объём твоих знаний увеличивается, и тебе их ещё и нужно удерживать целостность и незамыленность в процессе выработки каких-то решений и команд своей LLMки. Не давать ошибочные инструкции и не принимать эти ошибочные инструкции. Вот.
>> Ты становишься, да, это полноценная инженерная работа, то есть ты уже себя кодером назвать не можешь. Это полноценная инженерная, архитектурная работа. Это уже то, что ты сказал вот просистдизаign, да, ээ становится необходимостью изучать уже такие дисциплины. Да, да.
>> Угу.
>> Так, >> спасибо. Может, у тебя ещё какое-нибудь последнее слово, да, зрителям или кому-нибудь ещё там советами. Какую модель использовать, можно [смех] для начала, для старта?
Ээ, это каждый выбирает для себя. Просто сейчас уже сложилось в экосистеме такая такое мнение и, ну, подходы, да, сложились. Люди пробуют разные вариации. Вот там, скажем, для нас, для нативных разработчиков iOS, я считаю, что антропик модели всё-таки топ. Вот. Ну да, так считается. Сейчас вот есть такое там, я тоже согласен. Мне тоже больше вопрос мнения. Вот. Ну, а, соответственно, там с какими-то другими языками может быть результативность. Надо пробовать. Надо пробовать. Просто пробовать, да.
>> Угу.
>> Спасибо большое, Максим. Очень крутой доклад, мне понравился. Давай, может быть, как-нибудь ещё потом посмотрим, запишем большую секцию про UI.
>> Обязательно. Да, давай посмотрим на обратную связь и, может быть, что-то более подробно раскроем. Может быть, мы какие-то темы затронули, о которых хотелось бы кого-то больше послушать.
>> Спасибо большое.
>> Спасибо, Лев, что позвал.
>> Да. Пожалуйста. Спасибо, что пришёл.