💥 Агентская фабрика на CI: автоматизируем весь цикл разработки

Всем привет. Спасибо всем, кто смог подключиться к нашему новому мастер-классу. Сегодня его приведет Леша Березко, техли Тайос в Додо Пицца. Леша расскажет нам о том, как собрать фабрику яй-агентов, которые помогают в разработке, начиная с создания ишисов до пол-реквестов. Пожалуйста, задавайте все свои вопросы в чате. Ну и, конечно, подписывайтесь на наши каналы. А сейчас, Леша, вам слово спасибо. Да, привет, ребята. Расскажу вам сегодня про фабрику из LLM-агентов, которые там могут как-то работать на CI и сами решать ваши задачи, ваши проблемы, ваши таски, фичи, делать что угодно в целом, что захотите, насколько мощно вы ее сами дальше прокачаете. Но рассказ у меня будет, во-первых, сразу до спойлера, рассказ будет не технический. Я буду рассказывать только про саму схему. какая у нас получилась, и самое главное, почему она у нас именно такая получилась. Если вам интересно, у кого у нас, то я работаю в Dodo Engineering, разрабатываю приложение Dodo Pizza, у нас я вот эту фабрику внедрил, она реально работает, закрывает задачки, посмотрим с вами, сколько она их закрыла и за какой период, и это вам, надеюсь, как-то поможет продать развитие и вкладывание сил в такую же фабрику и у вас. Ну, для начала, откуда она вообще ноги у нас взяла? Мы с вами берем какого-нибудь любого LLM-агента, локально открываем или терминал с плат-кодом, или курсор, или что угодно еще, и делаем в нем какую-то задачу. Вот мы ее, значит, напрограммировали, потом мы открыли pull-request. Что происходит с pull-request дальше? На него прилетают ревью. Раньше это были ревью, ну и все еще, надеюсь, от людей, которые приходят, читают ваш PR, читают ваши изменения в коде и как-то комментируют. Мол, здесь ты нашу договоренность нарушил, здесь с логикой какие-то проблемы есть, надо бы, наверное, подправить. Ну и какой-то, короче, набор комментариев вываливается, если вам не повезет, на вас. И вам их надо решить. По каждому комменту нужно понять, насколько он валидный. Что вы с этим будете делать? Может быть, прямо сейчас пофиксите, а может быть, на потом отложите фикс чего-нибудь, потому что он сейчас в моменте некритичный. В общем, какое-то принятие решения с вашей стороны здесь происходит, и вы что-то с этим делаете. И вот это первая точка, которую я пошел автоматизировать. Для этого я написал небольшую команду для Клода, которая буквально называлась «Отрезолвить комментарии». И когда я работал над PR, когда мне прилетали замечания, я просто запускал эту команду, она читала весь PR. Так как команда запускалась в контексте вот всего, что я делал, она в курсе про все, что я делал, в курсе про все мои решения принятые, почему они такие, а не другие. У нее подгружена там и кодовая база в сессию. Ну, в общем, сессия заряжена со знаниями. И она может, на самом деле, нормально принять решение по каждому комментарию, что с ним делать. Вот, я эту команду запускаю, она буквально идет, читает все комментарии и принимает решение. Так, значит, вот эту штуку мне тут условный Игорь подсветил, это валидный кейс, его надо прямо сейчас починить. Вот эту штуку мне подсветил Василий, это, ну, конечно, баг, например, валидный. Но вообще-то он тут и до наших чинжей был, мы просто в этом файле сейчас поработали, но код с багом как бы мы не задевали, оно здесь было до нас, это вообще out of scope, и это можно когда-то потом починить. Вот команду, короче, я такому обучил и начал ее обкатывать. Но одно из интересных вещей, которое я в нее загнал, это я ее попросил, мол, смотри, если ты понимаешь, что какая-то вещь у нас с тобой сейчас out of scope, Но вообще исправить ее было бы славно. Пожалуйста, заведи, ищу в гитхабе. Команда работала замечательно. Я с ней много пул-реквестов довел в даблите. Очень ряд пользуюсь ей каждый день по многу раз. Всем ребятам своим раздал, сидим, довольные командой пользуемся. Исправлять замечания к пэрам стало быстро, удобно и безболезненно. Но какая проблема появилась от этой команды? Это... Ищутся в гитхабе. Их наплодилась мать муще. С одной стороны, прикольно, потому что буквально появился бэклог каких-то этих долгов, которые надо исправлять. Раньше просто как процесс-то выглядел. Пишешь, что это аутускоп, и забываешь. И проблема неисправлена, живет потом годами на проде еще. А сейчас все такие аутускоп-штуки стали записываться. И это хорошо, что они есть, что есть бэклог. Но разбирать-то его кто будет? Когда? Время бизнеса на разбор каких-нибудь там странных технических штук выделять не будет, потому что зачем, если можно фичи гнать и метрики прокачивать. Толку нам от того, что у вас тут, не знаю, старый деприкейт, ну ты какой-то метод опихи юзается вместо нового. Ну, пусть юзается. И бизнес-то прав здесь. Для инженеров важно, чтобы приложение технически работало. Ха-ра. Ну, мы буквально за качество приложения техническое отвечаем. Вот, поэтому у нас появилась большая пачка ищетов, которые надо было разбирать, прям хотелось разбирать. И я понял, что мы находимся в какой-то критической точке, когда у них в моменте оказалась, по-моему, сотка. Вот, все ищутся, и мы даже посмотреть своими можем, какие они, посмотрим, как у меня их моя команда оформляет. И их в моменте оказалась сотка, и я понял, что надо что-то с этим делать. И дальше весь рассказ будет про то, как и что мы с этими ищусами делаем. Но если посмотреть на что-то, что у нас здесь есть, вот, например, замечательный ищус прямо сегодня, свеженькая. Ну ладно, по моему часовому поясу уже вчерашняя. Мы мигрировали с одного фреймворка тестового на другой, точнее, с одной библиотеки, которую мы в тестах используем, на другую. Смигрировать-смигрировали, но оказалось, что мы в документации. Часть примеров, часть сэмплов кода забыли обновить. И там все еще остались вспоминания старой либо. PR с миграцией. Это никак не мешает. Миграция полезная. Ее надо было выливать в моменте. А документацию, правда, можно было обновить когда-то потом. Вот моя команда по резолу комментов, резолу PR. Она как бы поняла, что делать надо. Она пошла, оформила ищу. Сама придумала ей заголовок. По шаблону. в которой у нас репозитория для всех исусов есть, все оформила, написала, что не так, почему, это проблема, как надо, туда-сюда, обоснование какое-то. И мне очень понравилось, я обязательно попросил команду линковать. И ПР изначальный, из которого это еще родилось, и более того, прямо конкретный коммент от ревьюера, где он говорит, что там проблема есть. Поэтому вот внизу в обосновании все ссылочки прямо есть. Вот сказано, какие ПР вливались, там можно на них посмотреть, пойти, поискать, найти коммент. И на самом деле мы прям попробуем найти этот комментик, чтобы показать как бы еще более полно. Так, нет, это у меня еще открылось обратно. Это у меня... Я так понимаю, тоже ищем, да. А PR-чик где? PR-чик у меня, вот. Если мы PR откроем, на котором изначальная миграция была, вот тут у нас где-то ReviewBot как раз-таки какие-то ревьюхи присылал, что-то комментировал, и где-то здесь должно было родиться, что нужно обновить доку. Вот, к сожалению, блин, не могу найти, но оно где-то здесь есть, просто сейчас не хочется времени на это тратить, потому что это скучно. Вот. Но в итоге, как бы, у меня есть набор исчезов, и надо с ними что-то делать. Их вот сейчас у нас уже 72, в моменте, говорю, была сотка, и сотка такая звучит как неподъемная цифра, вообще не перелопатить, никаких токенов не хватит, никаких сил моих человеческих тоже не хватит со всем этим разобраться. Вот поэтому, что я решил? Что неплохо было бы как-то в этих исчезах начать перебираться. Потому что, на самом деле, одна из первых проблем, которая столкнулась даже не только в том, что их решать надо, а в том еще, что часть issues уже устарела. У нас над проектом работает немного, на самом деле, но десяток человек. Каждый из них там активно на разных агентах, клодах, курсорах сидит, работает. Много PR-ов у нас вливается ежедневно. Много в итоге issues таких вливается. Но и кода много меняется, и часть issues устаревает. Поэтому я пошел с первой какой-то точки интеграционной для фабрики. Вот я в моменте понял, что я дальше хочу делать фабрику, которая сама Ишесы разгребать будет. И первым этапом я решил, что я сделаю в фабрике скромтактингентика, который будет по моим Ишесам ходить, будет их смотреть и оценивать, насколько они еще актуальны. А если Ишес не актуальны, то будет писать коммент, почему? И закрывать его. Меня этот абсолютно устраивает Flow. Он там сам issues когда-то создал, сам его закрыл. Ничего интересного вроде здесь не нарушились. Вот. С этого я начал, это я сделал. И у меня появилась NCI job, которая раз, по-моему, в неделю, на самом деле, проходит по всем, по всем. И, собственно, закрывают ненужные. По факту она закрыла у меня в моменте, что там буквально 2-3 ищу, и на этом все, и за все остальное время у нас больше неактуального не было. Вот, поэтому оказалось в долгосроке не такой-то уж и полезный шаг, как оказалось на первый взгляд. Но все равно она есть, работает и когда-то еще пригодится. Окей, значит, первый шажочек верхнюю уровню мы с вами обсудили, это фильтрация ищусов на устаревшие. И в какой-то момент у нас, значит, остаются только актуальные ищутся время. С ними дальше что? Их надо как-то читать и, возможно, декомпозировать, планировать. Потому что, вероятнее всего, еще внутри себя может содержать не все детали того, как можно починить. Они могут содержать там проблемы, но не варианты решения. А варианты решения может быть несколько разных. Хорошие, плохие, быстрые, долгие, не знаю, что угодно еще. Вот сложные, простые. И я повесил второго агента на CI, который точно так же проходится по всем issues. И... И ставит им флажок planning. Вот такой вот. Что это значит? что такая issues прямо сейчас находится в состоянии планирования. Агент по ней может на самом деле и не один день, а может и несколько дней ходить и уточнять какие-то детали, предлагать мне варианты решений, прорабатывать план. И все это он вписывает внутрь issues. То есть если мы прямо откроем вот эту какую-то конкретную и посмотрим, что здесь, то вот видно, что у меня здесь неделю назад запускался агент, который... Посмотрел, что это часть большого эпика. Сказал, что хочет вот таким образом пойти, убрать там конформансы протоколу, заменить одни эпихи на другие. Сказал, что у нас тут немножко от изначальной информации, которая выше указана, уже кое-что из них невалидно. Разные пути до разных файлов поменялись. Замечательно, что он нашел. Составил детальный план. Сказал, какие файлы будет трогать, какие тесты напишет, какие тачкейсы могут быть. И он может мне оставить вопросы. Здесь же. А я на эти вопросы могу ответить. Как я узнаю о том, что на вопросы пора отвечать? Агент ставит всем таким вишесом, где он ждет от меня ответа, специальный лейблик. Ждем ответа. Я по таким вишесам прохожусь, читаю все его вопросы, которые у него тут снизу заданы, и прям просто сюда же отвечаю. Один делаем так-то, два делаем там иначе. Снимаю лейблик, что там вопрос ожидается. И вот как раз пример был предыдущий. Вот в таком виде. Все ровно, как я говорил, я ему ответил по каждому пункту. Я снял лейблик, что еще ждет ответа. Лейбл планирования остался, мы его не трогаем. В дальнейшем что происходит? Опять же просыпается этот же самый агент планирования. Опять же, проходит по всем ищетам, смотрит, остались ли где-то неоткрытые вопросы, опять же, там ставит лейбл, уточняет какие-то детали, если надо. А если его все устраивает, и он понимает, что мы прожарили проблему до конца, то он берет и ставит другой лейбл. Мы сейчас найдем где-то в самом конце его. Он ставит лейбл, ага, тут сейчас таких, к сожалению, нету, ставит лейбл имплементинг. Это буквально значит, что эта ищу в ближайшее какое-то время возьмется другим агентом в работу. И в какой-то момент, и правда другой агент проснется, пройдется по всем ищу с таким вот лейбликом, что пора имплементить, и на каждую ищу оформит pull request. Здесь вроде бы все понятно, но открытие pull request это на самом деле тоже лишь какая-то, может быть, стартовая. Точка того, как эта фабрика работает. Потому что на крупных проектах, таких как ДДПицца, у нас на открытом PR стартует 30 разных проверок. Разные линтеры, разные форматоры. Что там еще? Тесты, юниты, интеграционные, снапшоты, UI-тесты. Большая портянка всего очень важного. для того, чтобы приложение было стабильно, но и очень долго. Поэтому что с этим можно сделать? Во-первых, я попросил агента, который открывает PR, прежде чем его открывать, все эти проверки прогнать локально. Если ты добавлял какие-то тесты, пожалуйста, прогони эти тесты. Если ты менял какие-то существующие, их тоже прогони. Если ты менял код в каком-то модуле, прогони, пожалуйста, тесты этого модуля. И обязательно там прогони все линтовки, все форматоры, все еще, короче, все те проверки, которые у вас на CI, пожалуйста, на себе прогони. И это помогает изначально открывать PR в каком-то более-менее нормальном состоянии. Но это накладывает одно интересное ограничение. У меня проект iOS билдится, может, только на макойсных тачках. Макойсные тачки на CI. Дорогие, не самые быстрые, надо признать. И у нас еще там в случае Додопитцы мобильный пул тачек ограничен. В общем, что я сделал? Я на самом деле стартую джобу не просто в итоге на какой-то там убуньке самой маленькой, где просто запускаю Клода, чтобы он просто там как-то сурцы поменял. Я запускаю реально на макойсной тачке всего агента. Макойсная тачка... полностью подготовленным для разработки environment. Там стоят все среды разработки, все необходимые тулы, такие как те же самые линтеры, форматы, тестовые среды. Все это там есть. Агент делает работу, все может сам там же на CI проверить. На CI, в смысле, на своей тачке, где он работает, имею в виду. Вот он там в рамках себя проверит, убедится, что все окей, и только после этого откроет P. Замечательно работает, очень доволен. Тем, как оно получилось. Но, опять же говорю, у нас есть ограничение, что количество тачек на себя ограничено. Поэтому мы с вами чуть позже поговорим. Про это еще детально вернемся. Просто такую закладочку ставлю. Спойлер. Поговорим про то, в какой момент и как джобы запускаются, в каком порядке, как они что обрабатывают. Это прямо отдельный топик какой-то будет у нас с вами. Но, в конце концов, наконец-то. Окей, возвращаемся к нашему PR. PR открыт. На PR точно так же могут возникнуть, разумеется, замечания от людей, потому что кто-то пришел и увидел, что ага, вот тот агент сделал нехорошо, он там нарушил наше архитектурное правило, написал код не в том модуле или что угодно еще другое. Или же на самом деле может проснуться не только человек. рано утром и пойти PR-ревьюить. А еще, конечно же, может проснуться и LLM-ное ревью, любые там кодексы, клоды, кто хотите. Они тоже могут отревьюить у нас пул-реквесты и тоже могут набросать замечания. И получается, что у нас может быть PR-открытый агентом, и этот же PR-ревьюется другим агентом, ну и в том числе людьми. Что происходит, когда кто-то на такие PR-ы оставляет комментарии? Буквально на каждый оставленный комментарий просыпается агент и разбирается, что с этим делать. Он может как сразу же исправить замечание, если у него нет вопросов, так и может задать уточняющие вопросы. Например, сказать, знаешь, ты, конечно, предложение мне хорошее дал, но смотри, вот здесь вот ты ни у чем, вот такая проблема будет. Ты уверен, что ты хочешь в это направление идти? А я сижу ему такое и говорю, слушай, ты прав. Не хочу туда идти. Давай оставим, как ты сделал изначально. В конечном итоге pull request путем таких комментариев докручивается до какого-то валидного состояния. Но на самом деле у нас агент, вот я говорил, просыпается на каждый комментарий. Там, конечно, есть какие-то оптимизации, чтобы не прямо на каждый, а там только на последний. Это уже такие очень технические детали, а я хочу наоборот поверхностно рассказать, а верхнеуровнево, как оно работает. Вот, техникой делиться не хочу, потому что она скучная, там много, много буков, и вы все уснете, если вы видите. Вот, на самом деле, агент просыпается не только на комменты, а еще и на проверки, которые у нас гоняются на CI. То есть каждый открытый pull request запускает внутри себя, тесты, опять же, те же форматоры, линтеры, вот все, все там 30 проверок, которые у нас есть. И когда проверки завершаются, если какая-то из проверок обязательных заловилась, Я снова бужу агента. Он приходит такой, ага, вижу, завалились тесты в другом модуле, который я не трогал. Я, конечно, когда сам там все гонял, прогнал тесты на модуль, не знаю, там, авторизации, но я вижу, что упали тесты в основном приложении. Да, их я у себя локально там не прогонял, их надо починить, и он идет, чинит. Иногда он может понять, что тест на самом деле на себя всего лишь флаканул. агент буквально этому обучен, и просто заре ранить уже упавший тест. И в конечном итоге он доводит наш pull-request не только до отсутствия замечаний на ревью, но и до всех зеленых проверок. После этого выводит pull-request из драфта, чтобы он попал еще на более обширный ревью к еще большему количеству человек. Снова, возможно, чинит замечания от этих ребят. И уже потом... pull request автоматически вливается. Ну, просто потому, что у нас там есть автомерж, если там все проверки зеленые, все review опровнутые. И вот как-то так верхнеуровнево работает наша фабрика. Разумеется. Когда PR от агента есть, и есть ревью от другого агента, у них-то может завязаться спор в трейде, где они могут обсуждать, что что-то там сделано нехорошо, а второй может парировать. Да, я понимаю, но это out of scoop. И даже вот такие обсуждения тоже могут приводить к тому, что рождаются новые ищу. Поэтому у нас даже фабрика не только разгребает задачи, но и сама же свой бэклог наполняет. Тоже прикольно. А если говорить про конкретные цифры, чтобы поняли, что оно на самом деле как-то работает. Давайте посмотрим, что у нас было. Всего мы уже закрыли. Давайте я вот пойду в закрытые. Тут сказано, короче, цифра какая есть 205. Ну ладно, давайте я вам скажу по-другому. Мы закрыли около 80 пул-реквестов. То есть цифра в другом месте. 82 пул-реквеста у нас с лабрикой влилось. Это с середины мая, сейчас у нас середина июля, то есть за два месяца. В среднем получается, что один пул реквест в день. По факту иногда бывает, что пул реквест вливается какой-то один конкретный, даже и неделю, а бывает, что и за день вливается десяток пул реквестов. По-разному, неровно. Здесь есть просто проблемы нашей инфраструктуры, что у нас иногда могут, к сожалению, сильно начать флаговать тесты или упадут какие-то инфраструктурные штуки, из-за которых, опять же, тесты падают. И в итоге агент здесь подвисает. Но подвисает здесь не только агент, а мы здесь все в моменте подвисаем, пока с ними не разберемся. А других проблем... Во всей этой штуке. Я в плане того, как она работает, в плане того, что она и правда стартует, отрабатывается, ждет pull request и вливает, не замечал. Там есть вопрос про качество того, как получается. Мы тоже в конце это обсудим. Но сейчас про сам механизм скорее хочется поговорить. Что здесь стоит еще рассказать про механизм? Это про лимитирование. Сколько ищущих и сколько PRF на самом-то деле за раз обрабатывается. Я несколько раз до этого говорил, что мы там просматриваем сразу все ищусы. Чуть-чуть корректировочка. Не все, потому что не хватит токенов. Мы просматриваем не более скольки-то ищусов за раз и делаем не более скольки-то пул-реквестов за раз. У нас сейчас эта цифра, по-моему, 3. Мы ей играли. Сначала было 10, потом мы снизили до 3. Потому что неожиданно бутылочным горлышком оказался человек. Которому надо прийти и отревьюить pull request. В итоге у нас pull request просто подолгу от таких LLM агентов болтались и не вливались. И мы в итоге немножко сократили их скорость, чтобы и токены подэкономить, и людей не так сильно нагружать необходимостью человеческого ревью вот этого какого-то LLM кода. И живем вот на картинке, что 3 еще за раз, 3 PRA за раз. Вот это же нам помогло еще и снизить нагрузку на CI, который, я напоминаю, у нас и так по тачкам ограниченный. А когда там у тебя стартуют 10 агентов LLMных и берут и отжирают там под свои запущенные, не знаю, там 140 тестов, все доступные тачки, ну, ребята сидят и в фиче команды их немножко воют, потому что у них внезапно все джобы в очередь стали падать, потому что какая-то фабрика сбоку проснуться решила. Вот. Что бы. Такой проблемы нет. Вот мы не только слимитировали количество одновременной работы, которую она делает, но и еще поиграли с расписанием. Я говорил, что расскажу про то, в какие моменты джобы запускаются. Так вот. Часть джоб запускается просто от того, что произошло какое-то действие. Например, вот когда мы постим комментарий в PR, что надо что-то переделать, агент сразу стартанет и пойдет переделывать. Или придет и скажет, что там переделать не надо, потому что уже все правильно, а я не прав. Часть джоб. Запускается ночь, и на самом деле основная база наших джоб, вот таких вот фабричных, запускается по ночам. Буквально вот все легли спать, человеки, и просыпаются машины, и идут, занимают весь свободный пол тачки, и там на нем потрачат. Замечательно, как раз они к утру там заканчивают работать, просыпаются реальные люди, настоящие, хорошие, замечательные, любимые, и начинают работать уже они. Ревьюят как раз-таки все пары, которые там за ночь создались, и идут свои делать следом. Со стороны того, как схема работает верхнюю ровне, я рассказал. Со стороны того, как она интегрируется с командой, рассказал. Про качество. Качество, разумеется, зависит и от модели, которую вы используете, и от того, как ваш проект в целом подготовлен к агентской разработке. Мы в пицце очень много вкладывались в... Документацию, очень много вкладывались в скиллы, в команды. Конечно, если сравнить с каким-то там бигтехом, еще более крупным, не будем называть. У них наверняка все еще покруче, но я честно очень, опять же, горжусь нашим текущим состоянием. И благодаря нему почти все полреквесты от LLM на самом-то деле проходят без замечаний. То есть буквально смотришь, смотришь, смотришь, такой... Нормально сделано, все по документации. Почему не делать все по документации? Ну, потому что буквально промт каждому такому агенту говорит, перед тем, как идти что-то делать, пожалуйста, прочитай документацию. И то же самое с ревью-агентом. Он тоже, когда ревьюет, он обязательно читает нашу документацию, читает потом код по этой доке, находит несоответствие, комментирует. Ну, и в итоге оно, говорю, до человеческого ревью уже доходит очень по качеству хорошее. Если мы с вами начнем обсуждать какие-нибудь токены, сколько это все дело жрет. Сначала оно работало на 200-баксовой подписке. И, спойлер, оно работает на подписке, на Клодовой. Гоняется модель Киопуса 4.8. Сначала оно работало на 200-баксовой подписке. И на этой же 200 баксовой подписке сидел я лично и сам же из-под нее же разрабатывал. Поэтому по факту на ней крутился и моя работа лично на моем компе, и фабрика, и все ревью, которые на ПР-ах крутятся. Там много работы было. И вот эта 200 баксовой подписки иногда не хватало типа на денечек. То есть я буквально мог там понедельник с утра ее стерпать, а у меня там только во вторник вечером лимиты сбрасываются. Ну окей, на два дня. В итоге два дня идешь, занимаешься менеджерской работой, а не каким-то программированием. Потом в среду успешно возвращаешься опять к агентам, чтобы они что-то делали. Меня в какой-то момент немножко это утомило, что... Из-за того, что работает фабрика, мои личные лимиты страдают. Поэтому мы там с работой договорились, была выделена корпоративная учетка отдельная, значит, на отдельной подписке, 100-баксовой. И сейчас вот это все касается на 100-баксовой подписке. И вот 100-баксовой подписки, оказывается, не хватает на такую штуку. Три ПРа в день, три ищу в день, ревью каждого ПРа на каждый ченч. Не хватает 100-баксовой подписки. Поэтому тут есть смысл брать... 200 баксовую вам, вот такую могу советовать, если вы хотите сюда же прийти. Ну или как-то с другой стороны может оптимизировать, а может у вас проект меньше, а может у вас доки меньше, а может у вас скиллы лучше. Я не знаю, короче, оно может быть индивидуально. Давайте так скажу, я вам ничего не рекомендую, рассказал просто как у нас. Вы у себя там сами попробуйте сделать, посмотрите, как оно вам подходит. Технически единственный, наверное, момент, который стоит здесь рассказать, это как же так мы на CI запустили все через подписку. Тонкий момент. Во-первых, лицензионное соглашение клона немножечко это запрещает. Если кто-то пользовался в опенкло, то наверняка столкнулся с весенним баном, когда внезапно опенкло перестал работать, потому что антропики дернули рубильники, сказали, а-а-а, нельзя. Подпиской пользуемся только лично человеками, никакая автоматизация подписки не юзает. А как же тогда мы это сделали? Хитрый финт двумя руками. Одной рукой мы получаем из Клода, я прямо сейчас покажу. Запускаем вот такую команду, Cloud Setup Token. Эта команда буквально вам выдаст токен, который работает в счет подписки. Вы его можете куда угодно дальше скормить, хоть на CI, хоть на NCI, как угодно, хоть другому человеку. И все, что будет происходить из-под этого токена, будет идти в счет подписки. И второе, второе, это как запускается по идее клод на CI. Вот такой команды. Клод P и там дальше промт ваш идет, что надо ему выполнить. Клоды очень, антропики точнее, очень хотят закрутить гаечки вокруг этого способа. И уже несколько раз выпускали новости, что они будут эту возможность гасить. И нельзя будет такими вещами пользоваться на CI. Вообще, типа, никак. Потому что, типа, если хотите на CI, идите в API-based usage, в token-based usage, вот, а не в подписку. Поэтому тут мы нашли вот такую вот штуку. Клод FIA, если я читаю правильно. Это небольшой враппер над Клодом, который, ну, буквально имитирует пользовательский вот. Больше нет никакого Клод-П, он буквально с каким-то прям джиттером неравномерно вводит промпт в Клод, прям в терминальную сессию запускает, получает от нее ответ. И в итоге полностью имитируется человеческая работа. Абсолютно целиком имитируется. Антропики не различат, по крайней мере сегодня не умеют. В итоге вопрос, насколько это нарушает рецензионное соглашение. Оставим открытым. Хотите ли вы идти на такие риски? Решайте сами. Мы на такие риски остановились, попробовали. Два месяца полет нормальный. Вот. И что? Что здесь? Как будто бы я закончил рассказывать, что хотел. Про результаты, которые считаю успешными, я рассказал. У нас сейчас проводится в основном только, как вы могли заметить, Небольшие ищутся и технических рефакторов. Прям целиком фич мы тут не проводили. Но мы проводили несколько... Крупных, очень крупных технических факторов. Клод отлично все распланировал, мы с ним отлично декомпозировали задачу по миграции. Реально, у нас была большая задача смигрировать все приложение с одного тестового приморка на другой, а там работы вообще непочатый край. И он там догадался разбить всю работу по миграции на отдельные модули, каждый модуль на отдельные таски, и в итоге там создал на это 30 тысячусов. и пинает их по сей день, все никак не может доделать, потому что работы много, но делает и успешно проект технически ведется, который нам очень хорошо скажется на техническом состоянии проекта. Поэтому я ожидаю, что и с фичами, где, конечно, все по-другому, но объем-то работы примерно тот же большой будет, тоже все может нормально работать. Все зависит только от того, насколько детальный план у Клода будет и насколько он хорошо будет продекомпозирован. Вот, на этом, наверное, я заканчиваю, передаю слово Насте, делаю как-то, чтобы я ее мог слышать, возможно, будет потенциально небольшое эхо, но, надеюсь, не будет. Одну секундочку. Леша, большое спасибо за такой интересный рассказ. Я надеюсь, что действительно эхо нас не помешает. И действительно сейчас вопросы. Первый вопрос. Где бы вы пробили границу? Какие задачи в пайплайне все равно должны оставаться за человеком? Есть ли у вас стоп-лист для автогенерации? Для автогенерации ищутся в стоп-листа нет. Технически мы фабрику подкрутили, что она может схавать все. Давайте, наверное, расскажу, с какими-то техническими ограничениями сталкивались. У нас там обязательно подпись коммитов, это мы смогли реализовать. У нас там обязательно поддержка GitLFS, это мы смогли реализовать. Обязательно, как я уже говорил, инфра-самокос, это мы смогли организовать. И он может делать все то же самое, что делает разработчик. В конце концов, разработчики локально. Тоже могут делать, что хотят с этим кодом. Поэтому накладывать какие-то ограничения на CI я не собираюсь. Единственное, что она, по-моему, не имеет права сама править свои workflow'ы, сама себя. Потому что мало ли, что она там направит, что она там запустит. Но в рамках проекта можно делать, что хочет, все равно нужен потом будет человеческий опров. Поняла. Спасибо. Очень практично. Если фабрика сама планирует и уточняет детали, как вы предотвращаете разрастание скоб-крип внутри одной задачи? Как мы предотвращаем разрастание чего? Крип. Надеюсь, я правильно произношу. Кипяй? Да, да. Может кипяй. Никак не контролируем. Пока что... Ну как, ладно. В промке, на самом деле, у нас сказано, что, мол, чел, если ты берешься за ищу ее, ты ее планируешь, и ты видишь, что она большая, он сам там как-то понимает, что она большая, мы ему не уточняем, что это значит вообще никак, то предложи нам некомпозицию, и он предлагает, он прямо спрашивает, а точно ли все это решать одним PR-ом? А может мне тут создать пять дочерних ищу и на каждую ППРчику, и вот таким образом оно работает. И правда, несколько крупных фичей у нас таким образом задекомпозировалось. Вот миграция теста фреймворка, оно примерно так прошло. Поняла, спасибо. А какие метрики или, может быть, алерты вы ставите на работу агентской фабрики? По каким сигналам вы поймете, что система начала, так сказать, сходить с ума, и можно ли ее быстренько откатить? У нас внутри агента прописано, что мол, смотри, если ты по какой-то причине делаешь уже 50-й commit pull request, наверное, чел, ты что-то делаешь не так. Остановись. Приди в комменты, тегни людей, пусть они дальше разберутся сами. Такая штука у нас есть. Есть на самом деле еще глобальный рубильник. в которую мы можем прийти и всю фабрику разом загостить. Останется только ревью пул реквестов. Делать она ничего больше не будет сама. Мы им пока ни разу не пользовались. Как боретесь? Да, у нас в гостях... Меня как Настя привлекла из-за технических неполадок, но я уже просто сижу и коплю все вопросы. Леша, скажи, пожалуйста, а вот это вот использование Клода как такового, вот вы пользуетесь Клодом, Клод ежеквартально банит аккаунты, он это делает регулярно, многие программисты жалуются, что нельзя довести до конца проекты, многие приходят на чат GPT, а вы едите кактусы и как-то очень уверенно говорите, Вот тут подписка за 200, тут подписка, тут платите. В общем, риск настолько высок, что могут отключить любой момент, и при этом вы продолжаете этим пользоваться и всем советуете. Это как-то идет в разрез со здравым смыслом. Нет? Из того, что я знаю насчет банов. Были баны автоматизированные использования, которые мы типа обходим, и пока оцениваем риски как слабые. Это какая-то моя личная оценка. Второе. насчет банов людей, которые не могут довести проекты до конца. Я с такими людьми разговаривал, встречался лично, мы в чатике, в третиках пообсуждали, и это все оказывались кейсы, когда люди очень серыми схемами покупали себе подписки. Типа с левых схемок, с левых карт, и еще как непонятно. И там баны были скорее не за... неправильное использование клода а за то что вы как бы купили вы не пойми как и не пойми почему же доступ не получили это в моем кругу общения вот она так допускаю что как бы где-то за ним совершенно другая картина но у меня картина мира такая насчет того что мы в это все вкладываемся идем и я рекомендую я не могу сказать что рекомендую клода я рассказал как она у нас сделано Технически оно у нас сделано на самом деле так, что нам никто не мешает взять и во всей фабрике подменить движок агентский на другой. Захотим на GPT, захотим на Gemini. Без разницы. Это буквально один маленький степ фабрики вокруг всей инфраструктуры вот этой фабричной, которая кодом выстроена. Это типа минимальная проблема. Так, Алексей, упадет же производительность. Модели разные, ну, разной степени, ну, скажем так, умности, да, и вы когда подмените Клода каком-нибудь тупым GPT-чатом, у вас просядет качество тут же. А вы как будете его нивелировать? А почему мы подменим его тупой моделью? Ну, хорошо, давайте так. Будем учитывать, что Клод сейчас самая прогрессивная модель в мире. То есть нет у нее равных, нет. Ну, условно. И тут Клод вас завинчивает ламгайки. Причем Клод же недавно антропик заявлял, что они будут даже банить, оценивая контекст, который пользователь вводит. Ну, условно, где-то промелькнет додупиться. А он, а, ой, так это же вражеская пицца, ее нельзя есть американцам, поэтому всех подсанкции. И все, и закрыли вам аккаунт. Вы поставили чат GPT, какую-нибудь модель глупую, и она вам повалила всю работу. Не до конца понимаю, какую она нам всю работу повалила, если она работает совсем сбоку, самостоятельно, а мы перед тем, как PRFs вливаются, вручную их ревьюем. Проект она сломать не может. Максимум, что произойдет, она начнет приносить нам тупые pull-requests, которые мы начнем режектить или по кругу раз за разом сами импровить. Опять же, здесь же я надеюсь, во-первых, что мы не будем подключать тупую модель. Здорово, у тех же GPT вышло 5-6, которая там соло, и она хорошо работает. Настолько хорошо, что, честно, сейчас я думаю, вторую подписку впервые купить и жить сразу на дух одновременно и сравнить их. Я отзывов про него все слышал пока что восторженный. Кстати, да, если кто не слышал, посмотрите, почитайте. Люди говорят, очень хорошо работает. Чуть ли не лучше опуса на уровне фейбла. Вот это все. Во-вторых, модели новые все равно будут появляться. С разными, с кучей оговорок. Какие-то дорогие, какие-то только папи usage, какие-то лимиты маленькие, какие-то медленные, что угодно. Но модели будут продолжать появляться, рыночек продолжает расти, игроки новые появляются, китайцы потихонечку там что-то пилят. Может, когда-нибудь догонят кого-нибудь, не знаю, там через год, может, догонят опуста 4-5. Кто знает. А через год, как бы, ну, может, и по каким-то другим причинам смигрированный. Я не знаю. Это с кем далеко? Картина тут слишком быстро, все меняется. Алексей, а почему вы не используете локальную модель? Это же проще всего. За токены платить не надо, сами развернули, дообучили, поставили свой сервак, поткнули две карты условные, и все, и готовы, и дешево, и сердито. Зачем в облако отдавать? А, плюс еще вы отдаете в облако информацию, которая может быть чувствительной или нет? Чувствительную информацию мы не передаем в облако. У нас ее буквально в репозитории нет, а доступ у него только до репозитория. Здесь как бы мы... обезопасены. Если говорить про локальные модели, у нас буквально нет локальной модели в Dodo. Мы хотим, у нас какой-то есть vision, который я на самом деле поддерживаю. Мы разрабатываем приложение пиццы. Мы не разрабатываем свои инфраструктуры. Мы делаем приложение пиццы, делаем систему для того, чтобы вся эта обслужилась наша франшиза, но не делаем свою инфраструктуру. У нас даже CI, который я говорил, self-host, мы его типа покупаем у других ребят. Просто чтобы вкладывать наши силы, наши знания не в построение того, что и так можно купить готовое на рынке, а в построение уникального продукта. Локальную модель мы никакую свою не делали. Покупать на стороне. А смысл, если можно купить Клода? Я буквально последний вопрос и уйду, Настя. Прости, пожалуйста, есть ли задача, которую вы принципиально не подпустите агентов? Вот даже под контролем человека. Какой-то стоп-лист назовите ваш. Персональные данные. Ну, покупатели, условно, да? То есть они никогда не будут обрабатывать. И сотрудниковские, и клиентские мы не подпускаем. Доступов нет, не даем, принципиально запретили. Все. Спасибо большое, Алексей. Настя, прошу тебя. Саша, большое спасибо за вопросы. Оставайся с нами. И у нас пришел еще один вопрос. А как вы выделяете время ручных тестировщиков на такие автоматические фиксы, которые сделала ЛЛМ? Никак. У нас достаточно хорошие проверки на себя автоматически, много тестов есть, которым мы доверяем. Интеграционные, юниты, юайные, снапшотные, на все есть тест-кейсы в какой-нибудь тест-опсе. Мы очень долго, прямо много лет вкладывались, я лично в это все вкладывался в Dodo 7 уже с половиной годиков, в то, чтобы автоматические проверки давали гарантию, что с приложением все хорошо. Имея вот весь этот бэкграунд, Мы не боимся агентам отдавать работу. Поэтому вот конкретно вот эти ПРы, которые фабрика вливает, куашники не смотрят. В идеале у нас вообще есть какая-то картина мира, что у нас там и рушного тестирования вообще не будет. И мы к ней движемся на самом деле последний год, и еще там полгода, год будем идти. Но это, конечно, точка. Рушного тестирования нет. Ну зачем делать рушную, если можно написать тест? Не все можно покрыть тестом, но можно придумать, как покрыть все-таки. Да, действительно, такой сценарий будущего. А вы сталкивались с каким-то недоверием от команды к автогенерируемому по реквестам и вообще ко всей этой системе? Приходилось ли работать с командой именно в смысле доверия? Они сами такой же код сидят, генерируют в своих сессиях Клода, Курсора, кого угодно еще. Поэтому здесь доверие скорее не к фабрике, а к самим моделям. Но ребята знают, на какой модели у нас вся фабрика гоняется, поэтому вопросов здесь нет. Были вопросы от ребят насчет того, что весь CI внезапно под фабрику ушел, и ребята влить пылы реквесты не могут. Но это опять же был не вопрос доверия, это был вопрос мощности наших, которые оказались маловато под фабрику. Поняла. LLM ценит за способность импровизировать, а CI — за абсолютную предсказуемость. Как вы примеряете две настолько противоположные логики? Они работают на разных уровнях. Если мы говорим про реализацию задач, то в момент реализации задач предсказуемости нет ни у кого. Возьмите 5 человек, дайте им 5 одинаковых абсолютно задач строчка в строчку, получите 5 принципиально разных решений. Может быть, код совпадет, может быть, кто-то сделает нерабочее, но что угодно может произойти. То же самое может произойти и внутри агента. CI внутри себя проверки гоняет строго детерминированной. То есть мы делаем какую-то работу, неважно, вручную или агентами, не детерминированно, а потом проверяем ее детерминированно. Это два последовательных шага. Они идут не параллельно, они не как-то там одновременно работают, они последовательны. А планируете делать такие фабрики переносимыми между проектами или это всегда под ключ, под конкретный репозиторий, под конкретный домен, доменную область? Планируем. Я прямо сейчас буквально до нашего созвона сидел и отпилил эту фабрику в отдельный репозиторий, чтобы ее можно было заиспользовать не только в iOS-проекте пиццы, но еще и в Android-проекте пиццы. И вот и по ближайшей неделе я ее туда подключу. Ближайшую неделю. Я ее туда подключу и начну гонять там. Там как раз-таки у ребят используются Gemini. У них весь проект не подкладан, настроен под Gemini. И поэтому я делаю фабрику переиспользуемой еще и так, чтобы туда разные движки разных агентов можно было встраивать. И при этом как бы... Сама логика того, как фабрика работает в плане инфраструктуры... В плане стартов, триггеров, чтобы все это работало независимо от агента. На самом деле, в фабрике очень много чего сделано детерминированно. Не детерминирован только один шаг, который запускает какой-то анализ данных или реализацию данных. Все вокруг, весь процесс от чтения его, какие ищутся у нас есть, сколько, какие надо, как анализировать. До того, какие проверки лечить надо, все это детерминировано, это не агенты понимают, какие проверки ему надо сейчас чинить. Он получает ответ от скриптов, которые заранее написаны и выдают одни и те же результаты раз за разом. То есть по максимуму, что было можно в фабрике, унесено в скрипты, в YAML-экшены, в GS-экшены, в GitHub-инфраструктуре оно так работает. И только один небольшой шаг с одним конкретным промтом, мол, смотри, вот куча тебе данных готовых. Теперь только доделай. Практично. А фабрики будут продавать другим пиццам или вкусной точкой и так далее? Сделать как ВБ делает отдельный продукт? Нет. У нас все, что мы делаем, оно... Смотрите как. Все, что мы делаем, мы не продаем наружу. За исключением франшизы. Франшизу можно купить. А все наши инструментарии, они или внутренние, и только мы ими пользуемся, или они в OpenSource и бесплатные. Выкладывать ли фабрику в OpenSource, да не знаю. Она все равно заточена немножечко под нашу инфру в какой-то степени. Как ее заюзаем там между разными проектами, потом, может быть, не только между мобильными, а еще и другие проекты подключим, так можно будет что-то обсуждать. Сейчас пока сильно рано. А если завтра все LLM... станут в 10 раз дороже. Ваша фабрика останется выгодной для бизнеса или придется, так сказать, снова перейти на ручной кодинг? Надо считать. Я не знаю, это сложный вопрос, у меня нет ответа. Хорошо, а есть способы сделать фабрику дешевле, как-то оптимизировать расходы? Уменьшать пропускную способность за раз. Вот говорю, мы там с 10 задач одновременно до 3 снизили, это нам помогло. Уменьшать размер задач, декомпозировать их еще сильнее, чтобы она за раз брала еще более мелкие кусочки. Это немножко, конечно, в итоге будет ее замедлять, разумеется. Но во сколько раз примерно мы ее замедлим, во сколько же раз она там и экономней станет. Поэтому тут как бы... Скорее вопрос пропускной способности. Ну и дальше, разумеется, вопрос того, а как у вас проект устроен? А как он опрограммирован? Какого у него размера? Как вы доки к нему написали? А как вы научили агента эти доки читать? Потому что, например, у нас документация, на самом деле, гигантская, и мы прямо учили агентов читать ее эффективно. Но так, чтобы он смог найти любую нужную ему информацию в этой доке. Поняла. А у нас пришел немножко ехидный вопрос. А фабрика не повод для увольнения специалистов? Может, Лешу попросят скоро на выход после того, как он доточит все до конца? Люди нужны будут? А если разработчик в компании занимается только программированием, то, наверное, в компании что-то не так. А чем еще? Может, с разработчиком что-то не так. Разработчик для меня это супер богатая инженерная, я хочу сказать, сущность, как бы это грубо не звучало. Он и в курсе, и в контексте того, как проект работает. В курсе рыночка, в курсе процессов компании, в курсе про то, какие решения лучше, какие нет. В конце концов, важное слово, решение, конечно, должен принимать человек. Работу-то, то есть, допустим, условный. Продакт-менеджер в команде технической является разработчиком? Для меня да, потому что буквально из-под его рук, из-под того, как он там управляет командой, выходит продукт. Для меня такой же разработчик. Здесь можно долго дальше... Рассуждать, как-то философствовать на тему того, что разработчик какой-то большой T-shape, который умеет все везде и сразу. Я, на самом деле, себя все годы такими ощущал. У меня буквально первая работа была, это и задизайнить продукт, приложение, и написать клиент мобильный, и бэкэнд к нему написать, и базы к нему соструктурировать. И это, типа, первая работа, которая у меня была. К ней дальше еще докинулись, не знаю, редактуры текстов и чтение дополнительной, не знаю, литературы по дизайну, по интерфейсам. Четыре года обучения этим интерфейсом, опять же. Я программирую. В том числе. В конечном итоге я, как разработчик, не только программирую, а еще и все вокруг тоже делаю. И возвращаемся. Если у вас разработчик только программировал, то, ну, говорю, где-то есть проблема точно. А если у вас разработчик более богатый в своем бэкграунде, в своих знаниях и в своих скиллах, Пока я у него проблем не ожидаю. Наоборот, очень востребованно на рынке будет. У нас немножко продолжают ехидничать. Пока фабрика ждет сброса лимитов, Леша на выдаче пиццы. Решение принимает один человек или нужна команда? То есть нужна ли команда для того, чтобы принимать какое-то ограниченное количество решений? У нас в проекте настроено... Настроены кодовнеры. Мы разметили все приложение, все модули в нем, кто за какой модуль отвечает. Если фабрика идет и вносит чинжи в модуль авторизации, на pull request автоматом назначаются ребята, которые отвечают за авторизацию. Они приходят, они читают pull request и решают, что с ним делать. Опробить или просить чинжи. Соответственно, какой-то pull request может затрагивать сразу модуль пяти команд, например. а какой-то только одной команды. Назначаются люди как-то вот рандомом в рамках, собственно, этих правил. В одной команде, там, может быть, не знаю, два iOS-инженера в модуле авторизации, какой-то из них один назначится, он примет решение, насколько его устраивает этот пул-реквест. У нас это касается работы не только с фабрика, а с любыми пул-реквестами, с любой работой. Поэтому здесь у нас процесс вообще буквально никак не поменялся. Как раньше мы читали, апрувили код, принимали решение, так и сейчас. Просто пул-реквестов стало побольше. Ага. А были кейсы, когда фабрика научилась чему-то новому в процессе работы? Вы фиксируете такие вот улучшения? Когда она сама взяла и выросла на голову? Процесса прям обучения нет. Но я несколько раз замечал, что фабрика делает что-то не так, как мне нравится. Вот я считаю, надо по-другому. Я просил фабрику, во-первых, переделай, во-вторых, пожалуйста, в документации зафиксируй, что вот так больше мы не делаем, потому что это приводит к проблемам А, Б и С. Вместо этого используем другое решение, которое этих проблем не имеет. И получается, что у нас благодаря таким комментам потихонечку дока тоже минимально пополняется. Она у нас просто уже довольно богата, поэтому таких дополнений в нее в последнее время все меньше и меньше прилетает. Но они летают. Это не самообучение фабрики, это все равно через человеческий запрос происходит. Но в конце концов, документацию коммитет фабрика. По моей просьбе. А фабрика не плюет на документацию? ЛЛМ вообще-то этим славится? Сколько она помнит, так сказать, ваше плетье? С одной стороны, у нас есть агент, который реализует, он читает документацию, что-то по ней реализует, он и правда может что-то упустить, разумеется. Вторым гейтом у нас здесь есть ревью другим агентом, который тоже так же читает документацию и точно так же ревьюет вторым взглядом со стороны. И он проблемы может со всей стороны найти и находит. Но не все, все равно кто-то пропускается. Те проблемы, которые пропускаются, они сейчас для нас не критичны. Потому что, ну, все равно там условно ТС есть, ТС написан, приложение работает самое, это главное, вот. А то, что там заиспользовали старую архитектуру вместо новой, ну, ну и ладно. Все равно у нас там эта старая архитектура, еще там треть приложения на нем, от того, что там еще один файлик появился случайно, типа, ну и ладно. Если что, как бы, опять же, я могу попросить переделать вручную, вот, и оно переделывается. А вообще, конечно, Vision такой, что мы просто будем еще сильнее закручивать вот те самые детерминированные проверки на CI, и по максимуму, по максимуму, насколько сможем, требования из документации переносить в эти детерминированные проверки. Мы уже там, типа, приглядели инструмент, который подойдет для iOS проекта, ну, когда-то в него пойдем в ближайшем будущем, потому что уже пора, уже хочется, нужно. Вот, короче. Детям с нескольких сторон, плюс ручная проверка, плюс по максимуму перевод терминированной проверки. Леш, а какое самое большое достижение команды, которое стало возможным благодаря фабрике? Команды. Я скорее скажу не команды, а проекта. У нас сдвинулись с мертвой точки технические проекты разные, которые фабрика сейчас перелопачивает. Вот если я говорил, там 100 исчисов у нас было от того, что фабрика там, не фабрика точнее, а мой экшен в коде нас создавал сам исчисы, пока ревьюил, пул реквесты. А я потом туда сверх еще накинул задачу. Дофига. Сам по своему желанию взял, создал, как бы они пошли в фабрику крутиться. И у нас, ну, буквально пошли тех проекты, начали двигаться. Хорошие, которые нам несут, которые движут проект в нужную сторону. В нужную имеется в виду в ту, которую считаю я нужной. Какая приятная возможность оказывать влияние. А если Apple заблокирует приложение Dodo, что будет делать Алексей с фабрикой? Не кажется ли ему, что он потом мой дух? Придется повторить, потому что у меня прерывалось. Прошу прощения. Если Apple заблокирует приложение Dodo, что будет делать Алексей с фабрикой? Не кажется ли ему, что он по тонкому льду ходит? Вопрос блокировки приложения Dodo и Пламень как будто выходит вообще за обсуждение фабрики. Что я буду делать, если приложение заблокируется? А что делают все мобильные разработчики в Сбере, в Тиньке, в Альфе, во Вкусные Точка, в Максе и во всех остальных заблокированных приложениях? Работают. На этой оптимистичной ноте, Леша, огромное вам спасибо за такой интересный рассказ, за ответы на все вопросы. Я напоминаю нашим зрителям и слушателям, что Леша у нас в гостях не первый раз. Предыдущие выпуски вы можете посмотреть на наших платформах. И, пожалуйста, подписывайтесь, ставьте лайк. Это помогает делать больше качественного контента. Ну, а с нами был Леша Березка, техлит Айос в Доно Пицца и автор собственного канала о разработке. Ждем Лешу к нам в гости снова, а со нашими зрителями прощаемся. До следующих выпусков. Хорошего всем дня. Спасибо, что пришли. Покеда.

Лёша Берёзка, техлид iOS в "Додо Пицце" и автор канала  о разработке, покажет онлайн, как построить «фабрику» агентов в CI‑пайплайне — систему, которая самостоятельно закрывает полный цикл от создания issue до влития Pull Request.

➡️ Разберём, как организовать оркестрацию нескольких агентов и обеспечить их согласованную работу.
➡️ Посмотрим, как фабрика автоматически заводит issue, сама их планирует, уточняет детали, реализует и доводит Pull Request до успешного слияния.
➡️ Разберём типовые проблемы и способы их решения.

Когда?
15 июля в 13:00.

Оставляйте вопросы в чате!

Телеграм-канал AI4Dev: https://t.me/LLM4dev
Телеграм-канал Леши: https://t.me/alldmeat_channel

#CI #llm #agents #issues #pullrequest #ai #aiвразработке

00:00 Введение
00:47 Мастер-класс
33:15 Вопросы