0: Снова всем привет.
1: 1 доклад. На самом деле, такое воскресенье все-таки, да, не хочется делать слишком сложным и не хочется погружаться вот в какую-то отдельную специфику. А хочется посмотреть на картину в целом, посмотреть, какой путь мы прошли и что нас ждёт в будущем, и поговорить вот про такие 2
2: Вещи это я даже так назвал процесс перехода к ai ферст разработке, и, собственно, как это все должно эффективно работать и приносить пользу, буду рассказывать на опыте, который я наблюдал в яндексе в своей
3: Команде, как мы все это настраивали и где мы сейчас? Я думаю, многим картина отзовётся кому-то, может быть уже весь этот путь прошёл кому-то ещё. Это впереди, и можно будет что-то почерпнуть для начала вот такая фраза от сократа, что
4: Нет ни единой причины не использовать лм. Каждый день вопрос в зал есть ли у кого, то, есть ли кто-то, у кого эта фраза вызывает категорическое отторжение.
5: Ладно, 2 человека не считаются. Я беру это за базу и, собственно, объяснять не хочу. Собственно, мы поверили в эту штуку и поверили, что действительно, эй, может сильно забустить разработку, где-то, не знаю.
6: Полгода, 9 месяцев назад до этого было просто понимание, что, ну, это вроде хорошо. И после этого мы побежали, что вот надо, надо, надо всех заставлять, использовать, рассказывать, менять подходы и так далее. И, собственно, я поговорю про 4
7: Это самое важное, как всегда, везде это люди, их подходы, как они со всем этим работают, это окружение. И после этого поговорим про то, как добиться какого-то значимого ускорения от иишки и, собственно,
8: Зачем это все? Зачем нам за токены платить? Грубо говоря. Давайте начнём с 1 части.
9: Соответственно, что такое подход и опыт людей, да, если мы хотим перейти к first разработке, нужно отучить людей писать код руками очень такая нетривиальная на самом деле задача и хочется, чтобы люди использовали активно агентов.
10: И агентский сценарий писали код лэмками, но нельзя, к сожалению, просто прийти к ним и сказать, ребята, смотрите, там лмки выпустили, давайте вы будете работать в 2 раза быстрее, но можно, но, к сожалению, не очень эффективно.
11: Потому что на самом деле агентская разработка это вообще такие новые подходы, новые инструменты, большое количество непонятных вопросов. Че со всем этим делать, как со всем этим работать. И поэтому именно поэтому на самом деле я вот эти 4 части выделяю то, что нужно.
12: Не сразу сказать, ребята, все лмки вышли, вы красавчики, давайте икс 3 задачи. С каждого нужно постепенно все это делать и есть слона по частям. Поэтому вот, собственно, самая 1 часть и 1 шаг это некоторая среда для экспериментов и поощрение, что
13: Ребята молодцы, пользуйтесь. И мы все видели эти прекрасные статьи, что там вот люди говорят, что они ускоряются, а на самом деле замедляются от агентов. И это, это очевидно, это нормально, потому что ты начинаешь использовать что-то новое, и ты такой, а как че?
14: Ещё не написала, как бы, и это абсолютно нормально, что люди в начале будут замедляться, поэтому не надо ждать сразу, что чуваки вот, вот я вам дал квоты, тратьте деньги, получайте профит просто хотя бы
15: Начните использовать, а мы, а мы смотрим, как вы пользуетесь. И 1 наша задача это, собственно, смотреть. А как люди используют агентские сценарии? Ну, как всегда, тут на слайде, естественно. А, ну, вам, возможно, и видно все-таки, но смысл в том, что мы
16: Хотим вот как сказал сократ, чтобы люди каждый день использовали иишку для рабочих задач. И вот такой прекрасный график. Мы сначала считали вао, потом дао, сейчас вот считаем процент средних дней по команде с агентами.
17: Он как бы, то есть, грубо говоря, если все люди используют каждый день в команде агентов, получается 100%. Вот графичек близок. И прекрасно мы не говорим. Ребята, давайте, где, где, почему вы так медленно работаете? Нам так дизайнеры постоянно
18: Говорят, и менеджеры типа, там же лмки вышли. А почему вы все ещё не сделали мою фичу? Мы так людям не говорим, а мы понимаем и следим за вот этим адопшен внедрением и помогаем, помогаем людям со всем этим работать. Вот.
19: Есть менеджер, я, есть проблема, которую надо решить. Есть график, который надо улучшить, что делает любой менеджер в такой ситуации в начале. Ну, давайте.
20: Плохо слышно, видимо. Но я надеюсь, что там был такой ответ. Естественно, создаёт новый чатик. Смех смехом. Но вообще это абсолютная база. Если у вас нет отдельного чатика по работе, с по внедрению лмок по работе с ними. Вы зря так делаете.
21: Чаты обычной разработки плохо для этого подходят, потому что здесь есть такой эффект. Люди вот привыкли сидеть и писать код в своей среде, че то делать, решать задачи, они молодцы, они такие, ну ладно, нормально. А там где то какой-то ii. И они такой, а я вообще
22: Вообще нормально сейчас себя чувствую или нет? Я, я как, может быть, там люди уже мультиагентные системы запускают и все задачи решают вот так вообще на изи, а я до сих пор че то руками код пишу, иногда в чатике агента спрашиваю, это нормально или нет, и
23: Вот здесь такое командное чувство, что вот ты понимаешь, где сейчас как бы правильно бежать, в каком месте ты находишься, в каком месте находится команда. И ты не 1. И в хорошем смысле. Вот такой ещё фома, этот fear of missing out. То есть страх что-то пропустить, типа
24: О, ребята в команде че то делают, в этом чатике, постоянно пишут, как они используют иишку, а я нет, что-то со мной не так надо пробовать использовать. То есть такая поддержка. И, естественно, это помощь с инструментами, это шаринг разных знаний, кейсов, типа
25: Вот смотрите, получилось круто. Или вот смотрите, я потратил 15 $, а он ничего не сделал. Ну это как бы у всех было, поэтому все хотят знать, что работает, что нет.
26: Другая тема это то, что понятно. Ко всему этому нужны демки, типа рассказывать, как все круто и так далее. Нужны амбассадоры в командах, которые все это попробовали, знают и будут рассказывать людям это все понятно, но что намного важнее, кроме
27: Этого, это роль руководителей. Особенно я, собственно, сейчас обращаюсь к тем, кто руководит командами или какие-то решения, влияющие на процессы команды, принимает. Вот это абсолютно важная вещь, когда опять-таки у меня
28: Задача вырастить график или дать людям использовать. Я могу сказать, что я могу прийти к своим лидам и сказать, ребята, там, заставьте, короче, у себя использовать, ну и, соответственно, они тоже могут прийти и сказать, давайте все используйте. Там начальник сказал, что нужно ме
29: Растить. Вот и так не надо делать. И на самом деле, поскольку это новый подход, это много непоняток, много сложных вещей. Роль руководителя здесь невероятно критична, потому что нужно
30: Помогать людям поддерживать, нужно искать какие-то сценарии, выбивать время на эти эксперименты. И что ещё более важно это то, что нужно начинать с себя. Мы вот тоже на всем яндексе видели очень много разных
31: Разделение команд у кого-то там внедрение чуть ли не 100%, у кого-то 20. И всегда, абсолютно всегда это коррелировало с отношением руководителя этой команды. Если он такой, да че этот ваш ии, как бы я руками нормально писал и буду писать деды, так.
32: Делали, и я так буду делать. И, естественно, команда такая, ну, ну ладно, нормально. И это работает абсолютно на любом уровне вообще. То есть даже если вы ситио, даже если вы там, ну, я беру в 1 очередь технических
33: Руководителей нужно начать самому поверить самому, действовать самому и после этого убеждать других, потому что иначе будет шляпа. Это что касается внедрения. Напомню, да, вот эта история только про то, чтобы замы
34: Мотивировать людей, всем этим пользоваться. Дальше идёт 2 важная часть это окружение, окружение. Он же, этот харнесс. Любимое слово, звучащее часто. Здесь есть 2 момента, это инфраструктура и для человека
35: Того, чтобы нормально использовать иишку и чтобы агент мог работать, собственно, хорошо в вашем проекте.
36: Здесь есть 3 такие штуки, я сильно погружаться в эту историю не буду, так скорее по верхам пробегусь ну понятно, какой-то эдженси правило проекта и так далее это mcp, это скилы вот 3 такие.
37: Наверное, столпа, на которые, в которые нужно инвестировать и которые нужно делать для каждого проекта. И тоже важно понимание, почему это нужно и важно, как бы можно спокойно пойти и скопировать тело тикета, файлы и так далее в чат и сказать, ну, почини, а можно
38: Как бы сказать, вот тикет, иди почини. Да, потому он через эмсипи сходит. Можно каждый раз один и тот же пром писать руками, а можно потюнить 1 общий скилл, который все это будет делать хорошо будет решать вашу задачу. Но чтобы это было нужно, чтобы важность этого процесса
39: Понимали, как люди, которые это будут пользоваться, так и руководители, которые внедряют этот, ну, это все.
40: Про скиллы у нас будет отличный следующий доклад от егора, поэтому я про них. Это самая важная часть во всей инфраструктуре окружения это скилы, но я про них говорить не буду, поскольку вот следующий доклад прекрасно есть пару моментов, только скажу, опять-таки с точки зрения процесса.
41: Мы когда поверили, опять-таки, что это важно, надо и все такое написали пяток Скилов и такие, ну вроде нормально, но потом оно не росло и очень клёвая тема, не вглядывайтесь сильно там так, для фона картинка, но суть в том, что мы взяли всю
42: Команды сказали, ребята, давайте, давайте обсудим, какие есть задачи рутинные боли, которые можно получить иишки. Давайте накидаем пример. Скилов накидали огромную борду мирра, естественно, потом просто взяли её и скормили агенту и сказали, заведи задачи.
43: На скиллы и сделай. Ну, не сделал. Сделаю, конечно, люди потом, но так у нас как бы появилось достаточно большое количество разных интересных Скилов, которые помогают всем. Вот чисто несколько примеров, это, ну, там, не знаю,
44: Самый классный, который скилл мне нравится, это эвал скилл, который проверяет другой скил, что типа все нормально написано, или там пр. Статус, например, который просто забирает все проблемы, сборки, ошибки и так далее, падающие тесты и говорит, ну вот проблема.
45: В этом хочешь, починю? Ой, извини, я починил неправильно. Ты, ты совершенно прав, да. Ну и какие-то другие разные вещи. То есть это такое очень, очень, очень полезная штука. И вот если такой мини итог провести
46: Здесь то получится то, что
47: Это где-то, где мы сейчас или мы там где-то были несколько месяцев назад пришли в эту точку, что все более менее понимают, как использовать, все умеют использовать и есть какая-то хорошая инфраструктура для того, чтобы со всем этим работать. Но дальше возникает такая проблема.
48: Вот мы считали очень много разных, очень многими разными способами. И по там по тикетам, по количеству строк кода, по пулл реквестам, по коммитам, по людям, по оценкам, по всему Такому и получается, что
49: Вот ускорение, которое разработчики делают, оно какие-то десятки процентов, то есть там 10, 20, ну у кого-то, может 30, и это как бы хорошо, но все ещё не какой-то такой game changer, который было бы круто.
50: Показывает. Смотрите как круто это я в 1 очередь говорю конечно про какие-то большие устоявшиеся сложные проекты. Понятно, что если вы пилите какой-то новый стартапчик внутри, там ускорение будет сильно больше, но это другой вопрос. И вот здесь возни
51: Возникает такой вопрос, а у нас есть хорошая база по людям, по инфраструктуре. Как нам получить вот это самое значительное ускорение? Как нам ускориться в работе с ишкой? Как получить больше профит? Здесь есть 2 таких ответа. Это то, куда, опять-таки, на мой взгляд,
52: Надо идти в ближайшем будущем. Вот 2 таких направления. 1 это автоматизация каких-то больших рутинных кусочков в проекте. И 2, это автономная работа агентов. 1 попроще, понятнее, 2 сложнее.
53: Ну вот, собственно, мы их сейчас последовательно, аккуратно разберём, что такое автоматизация больших рутинных частей. Мы берём у каждой команды, по любому есть в каждом проекте какая-то, ну какой-то большой процесс, который надо. Постоянн.
54: Делать, тратить на него время, рефакторинг не знаю, там и так далее. Вот сейчас несколько примеров посмотрим и он либо автоматизируется с помощью иай, либо автоматизируется через иай. Это разные вещи. Автоматизируется с помощью i я.
55: Назвал это историю, когда процесс можно было бы автоматизировать, но это столько времени на то, чтобы написать эти скрипты, что тратить на него не хочется. К счастью, с. Я можно такое делать, ну или как раз-таки агент, ну, ленки позволяют эти задачи решать, наконец.
56: Которые нельзя было решать раньше детерминированным способом. И находим такие проекты, автоматизируем, освобождаем людей от рутины. Да, тут нету вот этого ускорения непосредственно людей конкретных, но есть ускорение команды, потому что мы, ну, освобождаем людей, и
57: Перенаправляем их на другие интересные проекты. Ну вот чисто несколько примеров таких проектов, которые тоже мы в команде делали. Вот в браузере. Есть очень такой понятный пример, называется Мерш, когда мы
58: Подтягиваем изменения из ядра хромиума в яндекс браузеры. И вот там, соответственно, мы у хромиума, где-то 15, 20000000 строк кода у нас поверх этого своего ещё где-то 2 3000000 и каждые 2 месяца хром релизит
59: Новый релиз. И, естественно, все это подтягивается к нам, и там получаются абсолютно 1000 и 1000 конфликтов, 1000 ошибок, компиляции падающих Тестов и прочих развлечений. И туда реально постоянно занимается большое количество людей. Собственно, тем, что чинят эту, всю эту
60: Не очень приятно, но лмкой тоже нельзя просто так взять, сказать ну вот вот конфликт почини, вот ошибка компиляции почини, она починит, но не так. Это как это как история, когда на вайбо или браузер на расте, который олмост воркс.
61: Там тоже будет примерно так. Поэтому мы здесь сделали более такие сложные штуки с пайплайном, все это описано вот в статье на хабре, тут есть QR-код, но тоже как бы классная история, которая вот как раз позволяет людей освободить от этой рутины или тоже очень понятная история про
62: Мы это назвали, называли проект свифти ация, когда есть, ну, изначально браузер писали на джекси, когда свифта ещё не было, потом начали писать на свифте, а код на джекси остался. И каждый раз, когда к нам приходили новые.
63: Мы им 2 недели давали задачу переписывать код джек тиси на swift и полезно нам, и познакомились с проектами, процессами, но мучить стажёров нам надоело, и поэтому следующему стажёру мы сказали вот тебе, лмка.
64: Сделай так, чтобы, короче, сделай. Вот. И тоже получился очень хороший наборчик, который позволяет в целом делать, ну, весь такой процесс. Это много, я думаю, у кого болит, можно из джавы на Котлин переписывать тоже. Тут есть Татьяна хабр и ссылка потом на
65: Ну или тоже ещё 1 пример. Вот есть как бы каждую неделю какие-то релизы, приложении, таже. Каждый раз какой-то человек на это все следит, смотрит приборы, чинит крыши, баги, разбирается в проблемах бедный страдалец.
66: И, кажется, с лмкой тоже все очень хорошо решается. Мы вот как бы часть пути в этом месте прошли, но уверенно идём до конца. Ну то есть там опять-таки, если брать какие-то возникающие крыши, баги, очень легко сказать, вот между
67: Мы знаем, что бак или cash появился в новом релизе, мы говорим вот дифф между этими 2 релизами, вот такой крэш или вот такой баг ну, иди почини, как бы, да, ну и это главное сделать нормально на сиайке и погнали. И ну и тоже самое опять-таки, лмка может делать какие-то анализы.
68: Выводы и так далее. Это 1 часть. Что касается именно вот автоматизации, где можно освободить людей от таких рутинных вещей. Дальше есть более сложная часть. Это автономная работа агентов, я бы её так назвал.
69: Но для начала тут как бы ребус, вот есть человек, который пишет код руками, есть там какой-то продвинутый чел, который пишет код агентам и какой-то супер продвинутый чел, который запускает уже систему агентов, что дальнейший шаг
70: А не работает, ну почти, потому что на предыдущем шаге вы поработаете полгодика и вы отъедете, потому что это очень на самом деле.
71: Тяжело, поскольку агентами управляют люди и принимаю, проверяют их работу. Люди управляют результатом люди. Весь этот буст перформанса съедается оо возможность параллельности оо возможно.
72: Оператора этого агента, параллелить работу, а это очень, очень, очень тяжело для этого бедного мозга человека. И типа, если ты дал агенту 1 задачу на проекте, потом переключился, дал 2 задачу. Тебе вернулся 1 агент, сказал, проверь.
73: И вот, короче, во первых, можно работать над 2, ну, максимум 3 задачами параллельно таким образом, если вот просто говорить про задачки в чате, которые даём
74: Дальше, как бы, это, в принципе, само по себе очень тяжело. Ну, то есть очень тяжело такой контекст переключать по сравнению с тем, как раньше там я писал код, думал, писал код, че то ревьюил. Ну, такой последовательный процесс, когда писал код, мозг отдыхал, а сейчас некогда отдыхать. И, естественно, если
75: Там 2 раза агентом собирать параллельно браузер на 1 компе компу тоже будет не легче, чем мозгу, поэтому здесь есть такой
76: Ну, куда надо стремиться? Надо стремиться, чтобы агенты работали максимально долго, сами, максимально автономно и не дёргали наш прекрасный мозг. Это очень важно. Здесь несколько частей. Во первых, ну как к этому можно подойти, да, с точки зрения каких-то подходо.
77: Ну, допустим, да, агенты умеют сейчас менять код, собирать его и, ну, прогонять тест, ну, короче, нормальный какой-то командлайн, умеют запускать браузер, да, там, фронтам в этом плане попроще. Ну, например, классная тема была бы, если бы агент
78: Умел нормально сам взаимодействовать с устройством и проверять, а че он там, собственно, кодил и работает ли оно или нет, чем как бы он сам такой запустил, проверил кнопку, которую он перекрасил, не перекрасилась. И такой, ой, извините, я не прав. И на самом деле было бы лучше, если бы это был
79: Если бы он сделал сам, а не человек пошёл это проверять. И вот это то, что я назвал скорее такой мультиагентной системой оркестрации, это опять-таки история в каком-то смысле про подход, когда мы говорим человек, ой, не человек, друг.
80: Модель ты не просто какой-то, не знаю, программист, который выполняет задачу. Ты сложная система. Ты оркестратор, который запускает 10 других человек. Ситио архитектора, писателя кода ревьюера кода.
81: Тестировщика и так далее. И чтобы он это все пытался максимально в цикле довести до конечного результата. И это все дело молотил вот такими системами надо как-то научиться их, во первых, применять в повседневных задачах, во вторых, научиться их строить обраб.
82: И так далее.
83: Ну и в каком-то смысле похожий, но немножко другой способ. Это так называемый auto ресерч, когда мы говорим, есть какая-то задача, например, ну относительно понятная метрика, например, время сборки, скорость старта, там, не знаю, размер приложения и так далее. И мы говорим, вот
84: Есть такая метрика, её так можно мерить. Вот есть код, который примерный район кода, где нам все это, который, от которого эта метрика зависит. Вот возьми и меняй этот код, пока не улучшишь эту метрику. А я пошёл пить кофе.
85: И этот подход в принципе, тоже неплохо работает, но нужно опять-таки искать. Тут проблема в том, что такие задачи нужно искать и нельзя буквально к любой задаче такой подход применить. Вот 2 таких
86: Как сказать, направление работы в этом месте. И здесь есть тоже пара важных моментов. Во первых, нужно учиться такое делать на ci, потому что локально железо тоже, ну, ограничено для количества параллельных задач. И тут есть проблема.
87: То, что если в предыдущем подходе, когда мы автоматизируем какие-то процессы, там можно легко посчитать экономику, типа вот этим процессом занималось 3 человека, теперь на него тратится условно, там 100, там, 1 000 $ в месяц.
88: Мы такие, ну отлично, кайф. А вот здесь, скорее всего, будет не очень экономически выгодно, поэтому такие вещи надо применять как бы уже осознанно, в каких-то прямо Нужных местах, ну, критичных местах, скорее, где
89: Результат важнее денег.
90: Ну, вы поняли, кстати, про деньги. Не зря ли нам дают токены? Да и не зря ли все это бизнес разрешает нам таким развлекаться? И, соответственно, типа, разработка ускорилась в 2 раза. Мы ж теперь в 2 раза
91: Delivery. Ну и что говорят здесь разработчики? Естественно, это тоже так понятно, да, почему так происходит, почему разработка ускоряется, а все как бы особо вот прям значимого буст.
92: По скорости доставки печей нет, потому что разработчики такие хитрые товарищи, они классно ускоряют всякие не очень нужные вещи. Тесты там. Ладно, шучу, шучу, не задачи не влияющие.
93: Непосредственно на скорость доставки продуктовых изменений пользователю рефакторинги, тесты и прочие вещи, которые как раз хорошо реализируются, но не то что влияют на непосредственно на вот какие-то критичные, большие продуктовые
94: Мне ещё очень понравилось такое вот обсуждение из нашего чатика, когда человек сказал, говорит, ну вот лмки очень легко позволяют делать любые задачи. Я поэтому пошёл, потратил время на задачу, которую вообще делать не надо было, ну, тоже, как бы, да, есть такая проблема.
95: И это 1 часть, 2 часть, то, что тоже, которую мы вот активно наблюдаем, то, что разработка, понятно, всего лишь часть вот этого бизнес конвейера, поставки фичей и ускоряется в 1 очередь вот эта часть, но остальные части
96: Этого конвейера, там менеджеры, дизайнеры, эксперименты, тестировщики и так далее. Не то чтобы как-то вот, ну возможно у кого-то так, но лично вот как бы в моей окрестности не то чтобы менеджеры как-то сильно продвинулись с лмками, а
97: Могли бы, а могли бы и вот эта история, которая тоже надо пытаться как-то ускорять другие части, помогать ребятам со всеми этими процессами. И, собственно, там, не знаю, прораба, писать задачи не где-то там у себя в локальном документе.
98: И потом в разработку в тикет заводить. А прямо в коде, например, да, писать спеки, по которым дальше может агент что-то делать. Там дизайнеры, понятно, прототипы, дизайнеры, кстати, молодцы, они прям активно прототипы делают. Мой, ну и тоже самое, тикеты тестировать тоже хотелось бы.
99: Поменьше, руками, побольше эмкой. Ну и другие части нужно ускорять. Ну и единственное то, что я уже говорил, то, что на новых классных проектах каких-то, где нету никакого опять-таки нету сильного влияния менеджеров, где большая часть проблемы заключается
100: В том, что надо, собственно, написать код, который будет работать для этого проекта, таких проблем нет. И ускорение там действительно уже можно наблюдать в разы. Это как бы такое позитивное.
101: Ну и пара финальных мыслей. Во первых, мне понравился такой таймлайн, который я нарисовал. Мне понравился таймлайн, который я нарисовал, в принципе, неплохо, да, вот где-то там во 2 половине прошлого года мы как-то начали активно
102: Внедрять иишку. После этого уже появилось понимание, че хорошо, че плохо, как должно все это работать. Начали настраивать окружение, инфраструктуру, начали все это эффективно использовать цель, которую, по крайней мере, я там ставлю себе своей команде. Вот как раз на
103: Точки роста, где можно прям ускориться значимо и ну или опять-таки сэкономить время на рутинные задачи. Ну и заодно будем думать как заставить остальные части конвейера работать быстрее на благо, на благо общества.
104: Примерно так. Если попробовать сделать суммаризация короткую, не очень короткую, но суммаризации. В общем, я топчик, безусловно, но вы все здесь сидите, поэтому знаете, и надо максимально его растить.
105: Нужно прям, чтобы все каждый день его использовали. Нужно развивать среду для собственно, этого иая. И чтобы эффективно все это делать, нужно искать какие-то сложные процессы, которые нужно оптимизировать, учиться работать с
106: Агентскими системами немножко по другому, чтобы они работали как можно дольше, самостоятельно, ну и ускорять другие части конвейера. И это себе, людям вокруг, людям наверх, людям вниз, везде. Короче, это говорим, ну и как я говорил,
107: Да, что тяжело, мы тоже обсуждали с ребятами, что вроде как яйчик позволяет делать все задачи проще, но че то как-то жизнь проще не стала. И и задач как-то больше, как будто и сложности.
108: У них выше теперь, поэтому надо не забывать беречь свой мозг. Он у нас 1. Ну, у каждого в смысле 1, поэтому, да, его надо беречь и примерно на этом все, спасибо.
109: Спасибо, Артур, твоя очередь. Твоя очередь выдавать кики.
110: Да, да, да, сейчас очередь то моя, но вопросы задавать они будут. У нас уже есть вопросы в чате, в трансляции, но мы начнём с зала, и я думаю, будем чередовать. Давайте начнём с кого-нибудь, я не знаю. Давайте вот с ребят здесь в начале и потом.
111: Постепенно двинемся туда.
112: Подключён. Так, отлично. Спасибо за лайт доклад. Хотелось задать вопрос, а как вы боретесь с ленью программистов? Потому что чем больше мы используем инструменты, тем мы становимся
113: Более ленивыми пропускаем какие-то вещи, которые раньше бы прям вот точно не пропустили. И, ну то есть мы перекладываем, по сути, ответственность на агентов, а потом, ой, что-то случилось давай тут 2, наверное, части то что
114: Мы не перекладываем ответственность на агентов. Ответственность всегда лежит на человеке, который делает. Мы. У нас были, например, примеры, когда мы билли, людей, ну, не буквально, но человек приносит пулреквест, ему пишут комментарии про типа, вот это неправильно. Он отвечает, он берет этот
115: Вопрос задаёт лмки, отвечает и копирует просто так, не понимая, в чем суть. Это важно просто скопировать, если ты понимаешь, в чем суть, и ты согласен нормально. А вот не понимая суть, ну блин, ну короче, потом разговоры какие-то, да, с людьми проводим, и поэтому именно
116: Контроль качества и все вот это оно, конечно, на людях все ещё, но мы тоже стремимся как бы, ну типа кодревью на самом деле все вот это становится немножко узким горлышком и мы стремимся как-то вот повышать качество, чтобы агенты тоже могли хорошо ревьюить
117: И, ну, искать такие проблемы. А с ленью, ну, лень здесь есть всегда, но естественный отбор в каком-то смысле будет работать. Но как, во первых, понятно, что мы пытаемся людей, понятно, мотивировать застав.
118: И так далее. Но опять-таки, да, если люди начинают лениться и не работать, ну, тогда очевидно, че с ними происходит. По этому спасибо. У меня короткий вопрос из чата, который похож на предыдущий. Как вы работаете?
119: Разработчиками, которые сопротивляются эй ай. Или, наоборот, слишком сильно на него полагаются. Ну вот эта часть похожа. Были ли случаи выгорания или демотивации из за ощущения, что машина делает мою работу лучше? Явных случаев выгорания пока ещё не было.
120: Я, как бы, знаешь, сам по себе иногда ловлю это чувство, поэтому допускаю 1. Нет. Допускаю, что как бы какие-то страхи есть у всех. Это опять-таки тоже нормально, но меня успокаивает Вера, то, что пока мы думаем и отвечаем за результаты и понимаем.
121: Надо делать и, ну, короче, хорошие, умные люди не пропадут. Вот, типа, поэтому выгорание, ну, я не наблюдал пока таких случаев. Вот остальную часть вопроса, кажется, я все-таки ответил примерно в прошлый раз. Поэтому, да, я поэтому решил дополнить.
122: Хорошо, давайте дальше задавать вопрос. Давайте. Ага. Вижу. Сейчас тут, Артур, спасибо большое. Пожалуйста, доклад, чтоб тебя видно было. Ага. Спасибо большое за доклад. А у меня вопрос. Планируете ли вы как-нибудь трансформировать подход к собеседованиям, если учесть, что
123: То, когда программист часто не пишет код руками, он забывает, как писать. Может быть, стоит на собеседованиях больше перейти к способности там делать код ревью, уметь использовать лмки. И вот подобного у нас на самом деле
124: Будет такое обсуждение даже в дискуссию вечером во 2 зале. Но если кратко мы смотрим активно в эту сторону, как, собственно, поменять процесс собеседования. Тут есть проблема, то, что поскольку люди все ещё отвечают за результат, нам хочется проверять знания людей, их навыки и
125: Вот найти хорошую грань, чтобы отличать работу человека от работы иишки. Ну вот это за ограниченное время собеседования. Это сложный вопрос, но мы такие эксперименты уже проводим, но вот прям вот сразу
126: Так перестроить не получается.
127: Спасибо. Следующий вопрос, Артур, спасибо за доклад. У меня такой вопрос. Меня тоже интересует направление долгой работы с агентами и тот же авторсерова. Можете поделиться какими-то кейсами. Ну что, удалось автоматизировать, чтобы долго работали? Аген.
128: Или, может быть, какую-то метрику с авто ресерчем оптимизировать. Ну, смотри, с. Авторесенин был классный пример. Не у меня в команде, когда у нас человек переписывал целиком систему сборки внутреннюю, которая там была написана на нескольких языках, и поэтому долго стартовала, и он переписал её аген.
129: Типа в автономном режиме. Вот как раз мультиагентной системой у меня в практике был как раз история со скоростью старта, где как бы получилось, ну, по крайней мере, попробовать такой подход сделать, к сожалению, там
130: Как бы по нашим тестам реальная моделька смогла и по метрике оптимизировать, но по эксперименту там в итоге оказалось, что все не так просто, но какой-то такой кейс был, да. А вот эта система сборки, она в итоге в прод пошла. Ну пока ещё нет. Понял, спасибо.
131: Вот там сзади руку тянут, можно туда ещё потом? А, вот, да, вопрос. Да, Артур, привет. Бизнес. Всегда важно считать экономический эффект на все эти токены. Расскажи, как вы мерили его с-ка.
132: Какими проблемами столкнулись, какой общий опыт? Проблема здесь всегда 1. То, что никто, мне кажется, нормально не умеет оценивать условно, эффективность разработки, да, типа, ну че то пишет код и ладно, ну,
133: Реально так, типа нету прям какого-то хорошего, то есть line of code условно это не метрика, да, объективная профита, поэтому тут хорошего решения тоже нет. Вот мы сейчас скорее на таком этапе, где мы понимаем, что это важно.
134: И нужно и мы готовы инвестировать туда как бы без непосредственно вот в моменте получения профита, но мы уже как бы вот смотрим на разные такие, в том числе какие-то бизнесовые метрики, общие по, ну все-таки
135: Сейчас по количеству там задач объёму и так далее по сложности и пытаемся смотреть в сторону как вот типа скорость выкатки задач в прод, типа того, примерно такую метрику какую-то построить и ну потом
136: Её накладывать, смотреть. Ну естественно, это тоже тяжёлый процесс.
137: Да, спасибо, воспользуюсь своим правом ведущего и задам вопросик из чатика. Да и прости пожалуйста, как вы модерируете свой внутренний чат про ai, чтобы он не превращался в редит?
138: А пусть превращается не к счастью мы ну для кого-то не к счастью, но лично для меня к счастью что мы живём в мессенджере яндексовском и там есть треды и типа если там пошло сообщение и flame на 100 сообщений в треде ну ладно мне.
139: Не страшно, как бы, а так наоборот, это в каком-то смысле поддерживает жизнь. Ну и не было такого, что там, не знаю, начался какой-то совсем буллшит всегда. Обычно по теме получается ответ. Пользуйтесь мессенджером, там есть треды и можно разводить реддит. Отлично.
140: Отлично. Да, давайте, да, Артур, спасибо за доклад. В общем, такой вопрос. Можете рассказать, как у вас устроено то, что у вас названо окружением. То есть это отдельная репа или репа вме.
141: С кодом. Есть ли какой-то там отдельный лейбл на внесение изменений. Сейчас попробую. Ну во первых, есть общая у нас внутри яндекса общая структура как раз
142: Store эмсипи серверов, мы его так называем. То есть это, грубо говоря, ко всем внутренним системам есть какие-то эмсипи и чтобы, ну, собственно, агенты могли работать с ними, их можно дальше легко подключать через, ну, систему сборки просто можно указать типа вот, вот это, вот это, вот это мне надо
143: И, ну, с точки зрения там работы со скиллами, ну, какого-то достаточно болезненная тема, потому что, как бы, ну, вот мы, как бы, скилы пишем, поддерживаем, складываем, ну, типа, раскладываем их в 1 понятное место и дальше скриптом при сборк.
144: Перекладываем в соответствующие во все папочки агентов, потому что у каждого агента своя отдельная папочка и типа, ну и понятно, что мы их как-то ревьюер, но здесь, конечно в идеальном мире хотелось бы уметь мерить как-то качество скила, типа, что он реально решает свою задач.
145: Ну, такого вот мы пока ещё просветления не достигли. Вот, а понятно, что в каких-то сложных проектах автоматизации мы уже строим бичмарк, чтобы смотреть, как агент решает задачи. Ну, потому что их вот надо жёстко оптимизировать. А если так всех заставить делать со скиллами, то люди скажут, нафиг я это буду.
146: Это все делать. Спасибо.
147: Артур, спасибо за доклад. Я хотел задать вопрос про ускорение. Мне кажется, во многих командах, которые используют я и ускорение на уровне разработки произошло, да, но как у тебя было в докладе, что
148: Это не весь процесс деливери, есть ещё команда кьюэй, они тоже много чего делают, например, там пишут e2e тесты, автоматизируют тест, кейсы, критерии, приёмки, но как будто бы этого мало, как будто бы несмотря.
149: Смотря на это, прям кардинального ускорения не происходит. Есть ли у тебя какие-то гипотезы? Как можно это ускорить? Может быть есть какие-то идеи? Мог бы ты поделиться ими? Оо, да, направле.
150: Я бы сказал 2. Ну, тут основная такая проблема в этом конвейере. То, что есть взаимодействие вот этих людей. То есть ты сделал задачу, ты её там реализовывал, и через 3 дня к тебе пришёл тестировщик, сказал, ты какую-то хрен.
151: Сделал или потом менеджер пришёл, сказал, это вообще не то, что мне надо было, ну, условно, да, и вообще, как бы идеальное решение в каком-то месте, чтобы разработчик каждый и каждый менеджер, и каждый тестировщик и так далее. Сами могли, ну, как бы, отвечать за полный цикл, да, типа,
152: Вот 1 из направлений, которое мы сейчас тестируем, это чтобы разработчики неожиданно тестировали то, что они сделали, потому что они это не очень любят. Ну, типа, тоже там можно погенерить, кейсы какие-то, да, чтобы, ну, по задаче, по коду и сказать, вот проверь вот это вот это, что ты молодец и
153: Таким образом, как бы снизить процент, когда там, ну ты сделал какую-то фигню и не проверил нормально. И это просто тоже как бы сам по себе ускорит этот цикл доставки. Другая тема. Это вот то, что мы сейчас тоже пытаемся сделать, это заставить менеджеров работать в репозито.
154: Истории с доками. Ну то есть, типа, не писать там где-то у себя какие-то доки или в чатике, а просто сразу делать это непосредственно как бы с пёками в мд файлах, в репозитории. Ну мы тоже чатики тоже по чатикам тоже мы строим как бы систему, чтобы за
155: Сообщения, все обсуждения и типа тоже из этого какие-то решения вытаскивать и обновлять пеки. Ну вот примерно такие вещи. Спасибо. Маленькую добивку сделаю как заставить разработчиков, когда у тебя их много.
156: Проходить через критерии приёмки. Ну, чтобы как раз уменьшить количество и сбросить нагрузку с кьюэй. Спасибо. У нас осталось тяжело 2 минуты на вопрос. К сожалению, хорошего ответа здесь нет, да.
157: 2 минутки на вопросы. Давайте 2 вопроса ещё возьмём какие-нибудь, вот кому сейчас микрофон достанется. Те, значит победили.
158: Здравствуйте. Спасибо за доклад. Спасибо, что поделились о своём пути и о том, что влияние не такое, как будто сильное при разработке по скорости. И вот хотелось бы, чтобы вы поделились мнением по поводу того, чтобы при развитии
159: И как раз инфраструктуры проекта заходить через код ревьювера. То есть это как будто жирное влияние на time to market, потому что задача может висеть очень долго, до 1 какого-то фидбэка со стороны других разработчиков и быстро придёт
160: Накинет какие-то идеи, мелкие исправления, может быть там замену, там, токенов, дизайн системы, ещё что-то. И вот этот rebuilding сборки, который может занимать часы на больших проектах, как будто очень сильно ускоряет поставку.
161: Кода до теста. Вот как вы считаете у вас есть какие-то метрики? Вот наподобие у нас точно есть про код ревью метрики мы как бы там всегда стараемся ребят пушить максимально быстро отсматривать код ну там есть прям ну типа если мы видим, что человек за там
162: Сутки. Ну, за рабочий день, грубо говоря, не ответил. Мы как бы, идём бить, ну, примерно стараемся в это идти. Вот, но с точки зрения как бы, сборок и всего такого, ну, это необходимость, пока что не научились. Ну, мы, мы идём в сторону того, чтобы
163: Сейчас тоже есть проблемы со сборами, потому что Пури стало больше, там фермы не вывозят уже сборочные, как бы какие-то идеи в эту сторону идём, но ничего такого радикального прям нет. Ну да, кодревью. И все. Вот это большая нагрузка, которая становится основной, и с ней надо че то придумывать.
164: Нет, скорее нет.
165: Спасибо. Простите, я вас обманул насчёт 2 вопросов. Это был последний вопрос, но Артур здесь будет. Да, можно меня поймать в любой момент, можно поймать меня в любой момент. Да, вы можете его поймать, и он поотвечает на ваши вопросы, а тебе нужно выбрать лучший вопрос у тебя.
166: Было 7 вопросов. Значит, смотри, про лень программистов, про то, как изменять собесы, про то, что оптимизировали. Давай про, давай про ресерч. Вопрос мне понравился.
167: Это который, что оптимизировали, где долго работало? Да, да. И человек, правда, ушёл, я так понимаю, да, по моему, это задавал. Ну, тогда, возможно, другой, как мерили эффект, как устроен харнесс про ускорение, как ускорять остальной
168: И про ревью последний вопрос давай про собес.