Как AI меняет цикл разработки

Итак, я немножечко сделаю введение, вернее, мы сделаем введение, начиная с эволюции роли инженера. А что такое кодинг? Чем отличается от разработки и где тут находит своё место AI или не находит. А потом мы посвятим немножко времени техническим объяснениям, очень очень общим и уж тем более без примеров кода. Все примеры кода будут на следующем этапе через неделю. А что такое агенты, MCP, Рагии, а и как они работают вместе? И дальше перейдём к интересной теме. Это трансформация инженерных, трансформация инженерного процесса. Каким образом нам могут помогать агенты, каким образом это всё заворачивается в работающую систему. Вот немножечко расскажем про индустриальный опыт внедрения, э то, как это описывают разные большие компании у себя. Я расскажу чуть-чуть ещё про то, что я слышал от знакомых и друзей. А и от, ну вот их у меня довольно много, и все сейчас говорят: "А куда же эти агенты и куда оно всё движется?" И Сергей тоже поделится вот а кейсами со своей стороны. вот области применимости, где можно, где нельзя, где какие риски финансовые, технические безопасности, как это контролировать. А амбициозная задача манифест инженера, который использует. Посмотрим, что как удастся его сформулировать к концу презентации. Это наш план. Я думаю, что презентация отнимет минут 30 на рассказ и всё остальное время на ответы на вопросы и обсуждения. Ну, повторяю, что пишите, пожалуйста, в чат ваши вопросы, ваше мнение, а, а, и всё такое прочее. У ведущего удивительно, но микрофон обычный маковский. Я сейчас в поездке, и поэтому мой супермикрофон отдельный вынесенный, профессиональный остался в Батуме. А вот это маг. Э, итак, а, ну ещё у меня, разумеется, тихая комната и богатый тембер голоса. А-а, итак, кто я такой? Я давно-давно в разработке. Я очень хардкорный, хардкорный бэкэндр. Последний мой проект в найме был, это эээкэнд для бэкэндов мира. Мы делали аа всеохранилище метаинформации, которая есть в мира. Ну, вернее, не я делал, а я поучаствовал, проложил руку, был техническим директором в разных небольших стартапах, не начинающих и уже более-менее зрелых всё-таки стартапах. Был архитектором, солюшн архитектором ИПАМ. из интересного там поработал в на проекте улучшения безопас платформы безопасности для всех продуктов Atlasan. Уже об этом можно говорить, уже время прошло. А вот я обучаю его инженеров очень давно и уже сейчас веду двадцатый по то курсу технический лидер для сеньоров и архитектора. Вот. То есть я такой жёсткий бэкэнзер, а и вот всё про архитектуру, системно сложные системы, большие системы, масштабны, большие организации. Сергей, пожалуйста, тебе слово, расскажи, пожалуйста, про себя.

>> Всем привет. Слышно, да, меня? Я Сергей, э, работаю на данный момент продукт-менеджером в B2B в экосистеме Slce Force. А до этого работал, начинал вообще, ну, инженерное образование, начинал тестировщиком. Около 10 лет работал тестировщиком, а, руководил командой тестирования, был ментором. И вот последние 5 лет занимаюсь продуктменед менеджментом в B2B продукции, в экосистеме Sals Force. Э начал изучать C года 2 с по назад и постепенно внедрять свои процессы и следить за этим. Вот, собственно, первый мой такой вебинар на такое большое количество людей.

О, спасибо, Сергей. А я хочу отметить разницу наших бэкграундов. Это сделано совершенно намеренно, потому что, а, Сергей занимается AI и углубляется в него без того багажа, который есть, ну, скажем, у меня алгоритмического, там, в общем, любого архитектурного там и так далее. И очень интересно, что у нас с ним получаются разные взгляды. Я оказываюсь более консервативным в том, что касается AI, потому что я думал про очень сложные вещи всегда. Ну, кн для БКН это я делал, не знаю, наверное, в третье моих проектов, которые были у меня в карьере. А Сергей про процессы, про менеджмент, про продукт, про то, чтобы каждый исполнитель, разработчик, специалист получил свой правильный контекст и чтобы менеджеры получили контекст и прочее. И вот это, я думаю, этим нашим этап будет интересен, потому что наш спор будет исходить из нашей разницы опытов бэкграун. И надеюсь, что будет интересно. Значит, немножко про Hearts of Scales. А Hearts of Skales - это центр экспертизы, который запущен мной в восемнадцатом году. А фокус на архитектуру, на развитие сеньоров и архитекторов, а немножко там менеджеров. Занимались мы с тем наш. Мы устраиваем очень много разных докладов, ивентов, иногда без записи, часто с записью. На видео они все есть. 250 - это, по-моему, только за последние 2 года. То есть иногда это было один-два раза в неделю на протяжении там всего двадцать пятого года и двадцать четвёртого. Вот. А присоединяйтесь, пожалуйста, смотрите. Много очень много. Даже по нашим ивентам, связанным см нужно рассматривать, как менялся и AI и взгляд инженера на AI по записи. Что ещё важно про Hards of Skills? Мы, то есть на курсах я не пересказываю, другие преподаватели не пересказываю то, что написано в книгах, в статьях и на там всяких сайтах маркетинговых. Мы делимся реальным опытом, мы его аккумулируем, мы его собираем и на мероприятиях, в том числе и даём в виде и курсов, и задач, и так далее. Потому что мы не Heills не афилирован ни с одним, там, не знаю, сервисной компании, ни с одним продуктом, ни с чем. Это независимая история, поэтому она позволяет нам взвешивать за за и против для любых инструментов, технологий и всего остального. Вот. Итак, это было представление. Сейчас мы переходим к а тому, что же такое роль инженера и как она сейчас эволюционирует. А, Сергей, как мы с тобой договорились, это твоя часть или моя?

>> Моя. Давай я начну,

>> пожалуйста, тебе слово. А ты, пожалуйста, говори, а я буду проматывать,

>> как тебе удобно.

>> Да, да. Где мы сейчас находимся? Да. То есть мы находимся, а, в эволюции, да, роли инженера и не только разработчиков, в целом всех инженеров, которые участвуют, а, в развитии, в разработке программного обеспечения, создания продуктов, поддержки продуктов, да, и одна из важных, да, одни из важных активов раньше и до сих пор пока что ещё остаётся, но уже меняется, это, а, являлся код, да, сейчас, э, традиционные метрики, да, написа разработки, которые раньше измерялись там количество строчек кода написанного либо количеством закрытых задач. Это всё меняется. Вот. А и не работает. Почему? Потому что код э сейчас писать намного дешевле, то есть десятки разы, сотни разы становится легче, дешевле. Вот. А и эта метрика перестаёт работать. А почему? Потому что увеличивается количество полреквестов. А, ну реально там time to market то есть не работает. Он даже в некоторых кейсах может падать, поэтому измерять количеством закрытых задач, а, не совсем правильно. Вот. А, э, мы, а, стоимость, получается, генерации кода стремится к нулю, то есть десятки тоже в сотни раз уменьшаются за счёт лалмок. Вот мы переходим, а в такую эру AI а программирования, да, в эру ассистентов, агентов, вот где, а процент написания кода будет стремиться увеличиваться и вплоть там 90%. Вот написание ручного кода становится очень мало. Вот. Аа, э, чем больше кода мы пишем, вот, тем, а,

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

Так, так, Сергей, что-то подвисает. Это только у меня или или это у всех? Или это я подвисаю?

У всех.

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

>> Сори, интернет отвалился. Вот поэтому сейчас, ну, очень много людей говорят про заменят, что Иишка забирает работу инженера, да, то есть пренебрегая вот этими всеми дополнительными, а, работами, да, которые делают а разработчики, да, вот вот поэтому ускоряя вот эти 10%, ну, которые занимают написание кода, как бы оно формирует ещё большее количество вот этих узких мест, а где важен, да, вот именно дополнительный контекст. Вот и а срабатывает такая теория ограничений получается, что скорость системы равна скорости самого самого медленного звена. То есть у нас получается, если узкое место - это ревью или тестирование, то оно остаётся и никуда не девается. И глобально это проблему общей разработки не решает. Вот. И, ну, несмотря на это, происходит, а, смена фокуса, а, а, в эпоху, да, в нашу, в эпоху, а, которая сейчас происходит. То есть, если раньше программисты там учили, а, то есть, архитектура, изучали языки программирования, да, то сейчас у нас, а, а, языком программирования становится постепенно естественный язык, да, то есть английский, русский, неважно. И lнка она выполняет роль, а, компилятора ваших мыслей, да, то есть превращает это уже в код. То есть изучать программирование стуля сейчас становится всё менее популярным. Тема такая открытая, много на эту тему дискуссий, но вот а и то есть сейчас такое золотое правило есть, что каждая дополнительная минута, потраченная на планирование, то есть она и спецификацию дли она экономит в будущем там 10x минут там или часов, неважно, на исправление бага, да? То есть, если не заложить, а усилия в вот это вот формирование требований для ишки, то есть это потом увеличит, а, а, м, то есть проблемы. Вот. И очень важно сейчас понимать, а, становится инженером в том числе, а, бизнес-логику, да, то есть вот, а, то есть происходит так некое слияние инженеров с пимовской, с с продукт-менеджером роли, то есть и а инженеры, которые будут больше по погружаться в бизнес, консекс-бизнес, логику, они будут как бы более ценны. Вот. Потому что важно, ээ, не как сделать уже становится, а именно цель как бы того, что мы делаем, цель решения. Вот, э-э, происходит трансформация навыков, да? То есть, и ещё раз, если вчера важны были технические знания, знания, а, программирования кода, то сегодня более важным становится это понимание, как декомпозировать большую задачу на более атомарные какие-то шаги, вот, которые сможет агент, э, понять, обработать. Потому что если, ну, у нейросетей есть жёсткий предел, вот если вывалить на них кучу всего сразу, да, LEGOC, куча документации или большие там требования, то, а, возникает очень много про проблем. Поэтому сейчас очень популярные такие там подходы, как Spec Driven Development, и один из них, который набирает популярность. Вот. Но это сейчас происходит, вот эта адаптация пробы разных фреймворков. Вот. Аа всё это идёт к тому, что человек будет, аэ, становиться таким оркестратором, да, то есть сначала ревюевеером этого всего, что нам пишут агенты, и после чего, когда это всё уже отточится, наладится, а а человек будет оркестрировать этими агентами. То есть это такая смена, короче, ролей происходит. Вот. И вот и по-прежнему ещё остаются очень важными знания человека в определённом домене. Вот насколько ты понимаешь, а и можешь верифицировать результат, который тебе дала Иишка, то есть вы вот это остаётся и агенты на себя это не заберут. Вот.

>> А, о'кей. Да. Спасибо, Сергей. Сейчас я чуть-чуть сделаю, маленький комментарий и снова передам тебе слово для следующей секции презентации. А есть такая компания Elastic Search, там работают много инженеров, сотни. И вот это одна из тех компаний, которые уже достаточно давно внедрили себе в процесс и Аля, причём не только в код, а там вообще в разные процессы. И у них очень интересное наблюдение, что хороший инженер стал писать меньше объёма кода в строках, при этом решать больше бизнесовых задач. А не очень хороший инженер, а стал писать гораздо больше кода, решая при этом меньше задач, чем раньше. И здесь метрикой становится не то, сколько кода ты написал, а то, сколько, насколько ты хорошо решаешь задачи. И более того, чем меньше кода, тем лучше, потому что это, ну, как бы то, что нужно поддерживать, понимать и разбираться. И здесь фокус очень сильно смещается на течи, но при этом без потери значимости технических вещей, потому что мы не можем писать мало кодов хорошей архитектуре, если мы не понимаем наши фреймворки, инструменты, технику и их возможности. Вот. А давайте немножко рамочно погрузимся в технологический стек, который нам предоставляет AI. Сергей, пожалуйста, тебе слово.

Снова,

>> да, то есть проговорим про агентов немного поверхностно. Чем агенты отличаются от ЛМА, да, от большой языковой модели? Тем, что у агента появляется минимум, да, три дополнительных вещи. Одни из самых важных, которыми надо управлять. Это у агента появляется доступ к тулам, то есть function calling, то есть агент может принимать самостоятельное решение, какой инструмент когда вызвать, да, с помощью системного промта. Вот. И из-за этого это как бы и плюс, и минус, да, то есть плюс в том, что имеет доступ к большому количеству там тулов. Есть практиксе там не а не превышается это количество. Там кто-то говорит трёх тулов, кто-то пяти. Чем больше тулов, чем больше системный пронкт, тем как бы стабильность работы этого хуже. Но это ещё как бы сама языковая модель, на которой построен агент, как бы очень много тоже роль играет, да. То есть более умные модели, которые сейчас выходят, они, в принципе, способны справляться там и с большим количеством тулов. А а глаза, то есть моде у агента есть. Это, то есть, агент может с помощью MCP-серверов, например, разных, то есть смотреть за документацией одитьне, да? А там из популярных это context 7, да, докумен MCP-сервер, который имеет в себе последнюю документацию по разным там языкам, программированиям, а по пишкам. Вот. А, чтобы это он принимал решение не не на основании датасетов, которыми он научен, а, за там, например, э, о, год назад, да, давности в датасете, а именно текущий, потому что постоянно всё обновляется. Вот есть а MCP сервера для того, чтобы смотреть, например, за вёрсткой, которую он сейчас только что там программировал, да? Браузеровские всякие MCP сервера, PlayR, а браузер MCP поя появились. Вот. И а у агента есть такая вещь, как а возможность права на ошибку, да, в отличие от а например ассистентов, которые у которых нет тулов, да, которые отвалились и всё, у вас ошибка, её надо самостоятельно обрабатывать, да, с помощью кодов агент самостоятельно может а при какой-то ошибке а её снова попробовать, да, то есть разобрать. Вот. И через цикл обратной связи, то есть он запускает автотесты, автотесты падает, он может как бы а сделать исправление, ещё раз их запустить. Вот тут очень важный момент, чтобы он а правильно работал. Это не автотесты, чтобы он правил, само собой, а сам код, чтобы бизнес-логика не страдала. Вот. И а у агента есть несколько э как бы э сейчас скажу, как несколько процессов, да. Один из процессов - это планирование, когда к нему попадают входные данные. Вот он, а, начинает планировать, что с этими входными данными делать. То есть разбивает это на подзадачи, вот, а декомпозирует и составляет сам себе план действий. Вот. И аутпут этого плана действия может быть там различный. То есть найти что-то, посмотреть, прочитать логи, испустити тесты, исправить код там и что-то написать, документацию, например. То есть это план составляет. И потом с помощью а тулов, которые у него есть, вот он выполняет этот план. То есть выполнение плана он у агента, в отличие от обычной лмки, есть доступ к файловой системе. он может создавать, а, редактировать, удалять файлы, да, с помощью м а вот можете устанавливать какие-то npm-пакеты, запускать скрипты, работать с гитом самостоятельно, вот, и запускать тесты. Вот, аэ, собственно, в агенте самая классная штука, что он работает в цикле. И если правильно работать с контекстом, поданным на вход, и правильно настроить системные пронты и подключить правильные инструменты, вот, и научите его правильно работать с обратной связью, то есть он будет качественно на хорошем уровне выполнять ваши задачи. Вот. Но всегда, а, особенно на ранних стадиях, когда рядом есть человек, у человека есть возможность прервать его, подкорректировать, и очень важно, чтобы человек следил за процессом. Вот. Вот, ну, аналогия тут есть, что ЛМ - это мозг в банке, типу, да, умная штука, которая не знает контекста вашей компании, контекст вашего домена, нюансов каких-то, которые у людей в головах. Вот. И это всё надо в идеальной картинке мира работы с лмкой давать ей на вход, чтобы она это знала, чтобы качество результата было лучше. агент тоже самое, просто такое такая же лмка, только с набором отвёрток, то есть с тулами и тоже, если у неё недостаточный контекст, она может повернуть не туда, открутить что-то не то. Вот такие аналогии при перевели. Вот. А MCP - это впервые OPIC в ноябре двадцать четвёртого года изобрёл этот протокол. его, а приняли, приняла индустрия. Вот. И это специальный протокол для для подключения агентов к внешним тулам. Вот своего рода USB порт. Вот часто любят принимать этот термин, чтобы к агенту подключить внешнюю систему. И в этой внешней системе есть описание тулов, инструментов, как работать с этой внешней системой. Вот. И агент на простом человеческом языке общается с MCP-сервером. И MCP сервер превращает это по сути у себя под капотом в азапросы к этой системе. Возвращаются данные и агенту возвращаются. Вот. А очень большое множество MCP- сеерверов есть, но у MCP есть минусы по работе с контекстом. Они очень сильно загружают контекст. Если MCP имеет большое количество тулов, а и описание для этих тулов, то это всё занимает контекст. аа окна в работе с агентом, что не всегда является хорошо, потому что MCP не всегда нужны, а при каждом вызове заполнять это контекстное окно немножко лишним, короче, вот становится. Вот в результате сейчас появляются другие инструменты, которые сначала предоставили, говорили как замена MCP. На самом деле они немножко не замена, а дополнение. То есть скилы вот уже с более грамотной работой с точки зрения контекста, потому что а-а вся инструкция скила и вся все составляющие скила не подгружаются в контекст а полностью, да, подгружается только его описание. И агент, видя это описание, сам знает, принимает решение, в какой момент воспользоваться этим скилом. Вот, можно ему, конечно, говорить, но в идеальном в идеале описание должно быть таким, чтобы агент вызывал этот скилл. И только когда он его вызывает, ему уже подгружается в контекст. То есть скилы - это больше про то, что аа как выполнять какую-то работу, да? То есть, э, логика выполнения, процесс выполнения какой-то работы. MCP - это мир, доступ к внешнему какому-то сервису, миру для получения дополнительного контекста. Вот также для дополнительного контекста пользовательство популярности векторной базы данных. Вот. А есть на самом деле большое количество векторных баз данных. То есть обычный рак, а это по сути, когда есть большое количество документации, оно делится на чанки с помощью специальной модельки и загружается в векторную базу. И потом по, а, по семантическому поиску, то есть происходит, а, а, ретриф, то есть получение чанков и для дополнительного контекста, то есть в ходе выполнения какой-то работы, либо, не знаю, если надо ответить на какой-то там вопрос, то есть идёт векторную базу по семантическому поиску ищется, и агент использует как эти чанки для дополнительного контекста. Вот очень много техник, как делать правильную рак базу, да, на какие чанки их бить, потому что ходые данные могут быть в разном формате, то есть то есть это могут быть и пдфки, и документы, и с картинками, и без картинок. То есть важно очень делить, а, качественно начанки, чтобы а неразрывные, а, не, ну, есть такое роды там перекрёстном, то есть чанки делятся там, например, на 400 символов и между ними ещё делаете перехлёт, чтобы не терялся контекст. Вот. Но не везде, а подходит э обычная векторные базы, обычный рак. Есть графовые раки, то есть, э, где есть связи, а, например, человека с тем, что он сделал, человека, где он родился. Это такой простой пример. Вот. А вот и иногда в некоторых проектах используются графовые раги. Вот. Но в мире, в котором мы сейчас живём, с агентами, чаще используются именно файлы, да, на файл сервера, а, ну, на локальных компьютерах либо там на серверах, где ваши агенты крутятся, они, а, берут целиком файлы, да, то есть в свой контекст, и качество как бы их аутпута увеличивается, улучшается. Вот. Но тем самым это является и минусом, потому что заполнение контекста модельки быстрее происходит. Поэтому очень важно контекст инженерия, правильно? И управление этим контекстом. А, правильно строить с инструкцией, чтобы агент в нужный момент брал нужные файлы и с ними работал. Вот.

>> Поэтому как-то так.

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

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

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

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

А поэтому а у нас есть инструмент агентов. Но ещё одна вещь, которая нам должна ну как бы должна присутствовать - это работающий процесс. Это мысль, возможно, не очевидна. Она непонятна тем, кто плохо знаком сфare Development Life Cycle и со всеми его циклами и сложностями, обратной связи. И поэтому люди думают: "О, так это код может писать так всё". И теперь инженер, он должен видеть этот процесс, как минимум те части, которые есть вот вокруг разработки, а ещё больше, ещё лучше и вот эти вот зелёненькие, так про вообще цели и намерения. Зачем мы это делаем? Для того, чтобы можно было писать код с помощью автоматизировано именно под те цели, которые есть. Может писать код теперь проблема. А вот теперь проблема, как написать тот код, который нужен. Вот существуют самые разные моменты, а значит, куда можно добавить ээ вот вот вот эти агенты. Но для каждого процесса в каждой организации процесс процесс индивидуальны в каждой организации, поэтому эти агенты могут быть очень разные для любых организаций. То есть где-то можно заставить агент писать код, другой агент тестировать. них там обмениваться информацией, пока там система правильно не заработает. Но это возможно там в какой-то одной среде, а в другой среде там надо обязательный этот самый кодрев человека, потому что либо очень сложный код, либо очень там пускает сложная система и прочее. Вот анализ логов тоже хорошая история, но там, где, во-первых, они есть, там, где они есть правильной, понятно системе, там, где есть всякие правильные паттерны, то есть у нас распределённая система, то вот этот transaction ID или Trace ID, он находится вот с из этой из этого микросервиса. Вот здесь блок лобов, из этого микросервиса здесь. И они все объединяются в общую операцию. Её можно анализировать с помощью AI. Вот.

То есть при применении AI - это следующий этап над автонотизация, должна быть грамотная и хорошая автонотизация, на которую мы ставим инфраструктуру всех этих агентах и неважно какую там chain, LНграф или просто ручками там что-то пытаемся фантазировать. Главное, чтобы это этот процесс был и чтобы он уже был каким-то образом автоматизирован. А одна одна компания, которую я консультировал в прошлом году, это Успешная Финтехкомпания, они внедрили в процесс тестирования агентов, которые могут создавать тест-планы, тесткейсы, тестценарии самостоятельно по требованиям. И после этого вот эти вот тест-планы и сценарии, они проходят ревью профессиональных тестировщиков, автомобитизаторов. И после этого они уходят в разработку тестов, которая уже частично автоматизирована тоже с помощью AI. И вот эта вот автоматизация на уровне вот тестирования вот этого жёлтенького, жёлтеньких прямоугольничков. При этом, как это не удивительно, а большинство, а самая сложно автоматизируемая часть разработки - это та, которая связана с кодом. Вот документацию проще, дизайн, архитектуру, ну, довольно сложно, но проще, чем код. А код требует огромного количества взаимосвязей, а их понимания, огромного количества деталей. в него в нём участвуют и решения, принятые на этапе архитектуры, и решения, принятые на этапе требований, какие-то ещё неявные правила и куча всего. И получается, что автоматизировать код, написание кода гораздо сложнее, чем автоматизировать ему практически все остальные части. Ну, наверное, все остальные части. И, ну, вот опыт тех компаний, с которыми я так или иначе имел дело, сотрудничал или консультировал, он заключается в том, что именно код сложнее всего, ну, как-то ускорить, а ускоряется, а, вот всё вокруг, потому что система обычно Legси, система обычно довольно сложная, запутанные, много информации в головах разработчиков, а, и, э, Её оттуда сложно вытаскивать, она постоянно изменяется. Добавили фичу, делали новый там план, запланировали новую архитектуру. Вот. А тестирование, работу с документацией, частично работу с проектированием, множе многие части работы с инфраструктурой можно автоматизировать, легче автоматизировать. Вот. И, ну, можно придумать для этого массу аренду. Главное, чтобы они попадали в ваш собственный процесс. Вот.

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

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

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

Ну, есть просто, ну, так категорично просто триггерит ухо, потому что есть же позитивные, не знаю, есть, конечно, маркетинговые типа случае внедрения там компаниями, типа Openi. Лот говорит, что они коворк там полностью на гентре сделали, да? То есть, но или страйп там у них там полностью цикл там требований до, а, короче, уже только человек принимает решение, типа ок не ок. Но в целом вся разработка уже заавтоматизирована, но а есть такие штуки, как типа написание автотестов, да? То есть это одна из таких, а, штук, с который сложно поспорить, да? А то есть или закрытие каких-то там legси штук, там устранение тех долга. То есть по-прежнему в командах есть такие вещи, которые на которые нет времени, откладывается и эти штуки помогают вот агенты помогают это всё закрыть. Вот и самая такая, которая а которая редко проговаривается, но, э, точнее, ты про это не упомянул, но построение новых продуктов, либо это продукт уже существующие, да, две разных вещи. Потому что, если мы говорим про существующие продукты, риски вот текущих кастомеров, то снова интерма хранится. А если про новые стартапы, >> если это про новые продукты, стартапы, то, ну, очень много примеров, где-то полтора человека, 2 с по человека, три. >> У меня есть история про новый продукт, правда, в минимальношем. Сейчас я расскажу. А я как-то решил повайпкодить. Вот там вот пишут красивые статьи, ориентируйтесь на фичи. Техника теперь уже не так важна, да? А и я на вайпкодел на Расте, потому что язык, которого я не знал для для чистоты эксперимента, я его очень плохо знаю. А и я систему обучения сделал несколько недель вечерами там что-то там закидывал запросы и так далее. С нуля у меня получило 10.000 строк кода. У меня каждая новая сеча создавала новые баги. И когда я обнаружил, что статус задачи, которую решает участник курса, зависит от количества, стало зависеть от количества комментариев к этой задаче, не от моего преподавательского там типа принял, не принял, я подумал, что пора уже вносить какие-то правильные штуки инженерные в эко, потому что как таковая вот эта вот льдовать решение не получается. Вот и я это к чему история? Это к тому, это не к тому, что там я, если бы я применял скилы, то значит всё было хорошо. Оно бы, конечно, было, да, и как правильно разрабатыватьто я знаю. Но на большом масштабе вот это вот неуправляемый рост, он рост входа, он превращается в legси. И вот этот вот проект, который мы нагенерили там за быстрое количество времени, он становится ну кошмаром в поддержке. Сергей, пожалуйста.

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

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

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

>> Прекрасно. Я свой примерчик это шкурно рассказал. Это был вот это была иллюстрация именно про накопление ошибок, да? Вот в чатике я вижу интересный этот вот разговор. Вот. А, ну да, нам нужно обсудить конкретные подходы, но сейчас у нас такой метап, который вообще эту проблему формулирует, ставит. А конкретные подходы у нас будет на следующем этапе, который будет 17 марта, через неделю. Я вас всех туда приглашаю. Там уже будет больше вот этого, меньше этой общей философии и про подходы, и про тренды. Вот. А там будет, ну, собственно, код, который редактирует другой код, и другой код работает после этого. А если не работает, мы редактируем сначала код агента, его скилы и всё, что нужно, а потом аа эти правильные скилы уже делают правильный код нашей системы. А вот аа поэтому вам всем будет прислано письмо с приглашением на следующий этап про работу уже про конкретные подходы и то, как это можно делать. Значит, вот мы подходим к тому, что вот большие проекты, там вот них может быть сложнее, там вот очень важная бизнес-ломика, автоматизация больших предприятий, небольшие проекты, а тем более с нуля проще и так далее. В тестах лучше, потому что, ну, они проще, на них ответственность меньше. всевозможной интеграции, какой-нибудь тупой код, который надо много раз повторить там для разных вызовов, там хинтпоинтов и прочего и прочего, очень очень хорошо для применения. А вот то, что касается вот той самой бизнес-логики, которой сначала надо поде разобраться, а потом ещё как-то её сделать и описать её агенту, чтобы он её реализовал, здесь гораздо сложнее. то то, что касается более глубоких технических вещей, которые как мне оптимизировать свой микросервис, чтобы он побыстрее отдавал мне результат или чтобы он кушал меньше памяти. Вообще откуда там взялась утечка памяти, здесь с агентами будет очень сложно. И здесь нужно, ну, пока я, если честно, для таких вещей очень слабо представляю использование автоматизированных инструментов, что слишком много вещей, иногда неожиданно их нужно при применить ну, принять своё внимание. Проектирование архитектуры с нуля аа тоже сложно, потому что здесь я буде просто копировать средние решения. Это провол, что я обучаю в архитектуре. И, э, здесь нужно его держать в стражайших рамках, просто вот невероятно строгих, и постоянно ревью или проще самому набросать. Возможно, с агентом по посовето, вернее, не с агентом, просто с чатиком, посоветовавшись по каких-то вещах. Вот что у нас ещё есть принципиального. Это вот области э с DLC Soft Development Life Side, где вот проще и где сложнее применять. Вот есть ещё другие области, которые касаются применения. Это то, что при вызове а моделей преинференса у нас один и тот же вопрос может один и тот же промт может давать разные результаты. Э и это нужно учитывать. И поэтому, а, иногда это может приводить к каким-то проблемам. Вот это раз. А второе, автономность стоит токенов, стоит денег. И это тоже нужно учитывать. И возможно, ну, есть такие приёмы, которые требуют по установке э ограничений тупо на стоимость токена для нашего агента. Если она превышает какую-то пороб стоимость, то значит, что его агент пора ремонтировать. А вот и кроме того, галлюцинации, связанные с архитектурами как системы целиком, так и структуры какой-то отдельной относительно сложной части. Здесь очень просто в процессе инфренса упускаются разные критичные вещи, без которых он, собственно, бизнес дальше не может работать или относительно сложный код не может работать. Эта сложность, на которую он начинает ошибаться, она не так уж высока. Поэтому здесь ну абсолютно необходим необходимо участие человека. Вот. И ещё одна группа проблем и рисков, с которым связана - это безопасность. Одна один вопрос - это то, что код наш может попасть в и нём обучится тот же самый код-код. ещё раз его модели, и будет выпущена новая версия модели, и другие компании будут теперь пользоваться нашим образом написания кода через модель. Это не очень приятно. А некоторые проекты, которые делают персональную обработку, скажем, каждого пользователя или в виде чатботов или в виде там каких-то персональных рекомендаций или чего угодно, могут отправлять и персональные данные внутрь эти а модели, и они же там где-то тоже остаются, на них происходит обучение. И в результате, а, возможно, когда-нибудь мы сможем задать вопрос: "А что там у Павл Веника? Там, значит, было по финансам. когда-то кто-то использовал какие-то финансовые решения, не вычистив там вот конкретно моё имя из запроса и не заменив его там на кастомер на номер 28. И в результате получится очень неприятная утечка утечка данных. Вот для этого существует множество вариантов. Это и контрольные точки, ограничения, и, а, собственно, способы назначения ответственностей, потому что агент он ни за что не отвечает. Отвечает инженер, который создал этот вот. И то, что я здесь хочу сказать, что, ну, как бы эпоха вайп-кодинга, она заканчивается, вернее, она уже закончилась. А, и вместо этого приходит инженерия, более сложная, чем раньше, с использованием AI и с учётом всех особенностей процесса. Собственно, самый главный посыл сегодня - это то, что, а, ну, это то, что тот, кто хорошо понимает и домен, и процесс, и возможности, и и, собственно, всё то, что нужно было знать раньше, там архитектуру, фреймворки, системы, базы, вот именно тот инженер будет выигрывать и будет конкурентноспособен. Так что сначала мы будем программировать скилы, агенты, их взаимодействие, процесс, а потом вот этот процесс будет в полуавтоматическом режиме иногда с нашими точками делать хорошую систему. А вот такая интересная штука, да, недетерминируемость может вносить э везение, а иногда и невезение. На это полагаться нельзя. А, Сергей, пожалуйста, вот выскажи своё мнение. Может быть, ты с какими-то аспектами не согласен, потому что ты на это смотришь более оптимистично.

>> Да нет, он, что сейчас было сказано на последнем слайде, что здесь согласен. Можно к вопросам по сути переходить.

>> А, о'кей. Хорошо. Значит, ну, собственно говоря, манифест инженера, это нам нужно знать теперь. не только технику, а ещё инструменты, а и как их применять. Вот к кого-то вопрос про конкретные приёмы, вот эти приёмы надо знать, нужно знать домен, нужно знать процесс и в разные аспекты этого процесса вносить инструменты AI, чтобы они использовали аэ фреймворки, э там код так, как нам нужно, чтобы система заработала. А если где-то они используют неправильно, то мы, пользуясь знанием фреймворков, инструментов уже технически говорим: "Вот здесь неправильно, вот здесь давай исправляй". Коммерсивная нагрузка на такого инженера жесточайше возрастает, но при этом его эффективность тоже повышается. Вот. А процесс - это передача контекста. Нам нужен человеческий humanлу. А, и вот и наше мышление человеческое, которое вот это вот всё проектирует сначала процесс разработки, потом саму разработку контролирует, и оно оно, в общем, неотдаваемо. Может быть пока, может быть, навсегда. Вот. И наступает эпоха, в которой код является, ну, количество кода является ещё большим злом, чем раньше, потому что его слишком легко генерить и слишком сложно за ним ухаживать. А вот я вижу, что много реплик, что вы делитесь опытом. Это очень хорошо. Аа э значит, я попробую пробежаться по всему тому, что вы написали. Приглашаю вас ещё раз уже на LeК demo, который Сергей будет вместе со мной показывать, а, агента, который будет делать вра с помощью скилов и с помощью MCP. А не очень сложные изменения в не очень сложный проект, потому что если сложного по времени не платит, а так вот минут за 40 плюс тоже вопрос и обратная связь. А вот это будет 17 марта на сайте скоро появится и у вас в почте тоже. Точно, точно так же мы приглашаем вас на курс, там, где мы будем как раз рассказывать про конкретные приёмы и а использование и скилов, и хармесов, и всевозможных агентов, и там, где на маркетплейсы использовать маркетплейсы скилов, как как с ними работать и как улучшать свою текущую задачу и работу. А вот сейчас я попытаюсь пробежаться по тем вопросам, которые были и комментариям в чате. А вот ну если у кого-то есть конкретный вопрос, то, пожалуйста, наверное, напишите ещё раз, потому что я вычитывать прямо в реалтайме не успею. Всё. Вот если текущее знание лмановано на знаниях, которые создавались десятилетиями, если все станут айкозерами, кто будет генерить новые знания, правильно, а всё меньше будет людей, которые будут создавать многие новые знания, потому что с другой стороны, а знания человечества распределены настолько неравномерно между людьми, что, возможно, если я бы использовал знания ещё двух-трёх человек, которых я просто не знаю, разных областей, то я бы смог делать гораздо больше, гораздо лучше, полезнее и вообще быть уже богатым, счастливым, здоровым. Вот обязательно в блоке Q&A мы на те вопросы тоже перейдём. Вот вот это вот вопрос усреднения знаний по человечеству, он он как бы существует, но он скорее это уже как бы эволюционное развитие вида человек больше, чем про разработку. Вот. А, значит, возможно, Сергей, на этот вопрос лучше ответишь ты. Значит, шаги развития, MCP, правила, скилы. Чего нам ждать дальше?

>> Ну, у меня два комментария на эту тему, что чего жду ждать дальше? Не знаю, многие говорят там про agent

To agent, всякие протоколы, что по мне, это рановато, потому что надо научиться сначала работать с обычными агентами, вот. А, и добиться стабильности какой-то. Плюс большое количество процессов компании можно покрыть ещё с помощью ассистентов, то есть без агентов, без тулов, да? То есть большое количество компаний, а, покрывает именно обычными, а, workflowми, да, с подключением каких-то модулей, да, блоков, нодов, то есть без агентов. Вот. По агентам ещё будет адаптация несколько лет точно. Вот. И пока это всё процесс с компанией гиганты, условно Open, EY, Cloude и Anthropic. Они долго нас, я не знаю, но ново что-то, что-то вот MCP, условно, потом скилы вышли, сейчас что-то за скилами прогнозировать сложно. Вот не скажу, что будет деш.

>> Окей, спасибо. Ну да, так всё у адаптация будет дальше. А, о'кей. Аги. А, кстати, вот про Аги математически то, что происходит у нас вот в серых нейронах, оно идентично алгоритмически тому, что происходит в модели. Только у нас в голове гораздо больше связей между разными вот этими отдельными нейронами. Почему? На порядки, не в три раза, а там, не знаю, в 3.000. А, и у нас при этом алгоритм этот в нашей голове, ну, в общем, идёт, ну, пока ещё немножко более сложным в очень разных нюансах. Вот. Но я думал, что к Аге мы, ну, крайне близки. Изучить передовые технологии. Вот здесь, пожалуйста, переходите на следующий не так или прямо на курс, потому что их сейчас достаточно много возникают, появляются. Реальная статистика ускорения разработки в реальных компаниях. Здесь у меня есть противоречивая информация. Я изучал разные отчёты за двадцать пятый год, а начало двадцать пятого, за конец двадца пятого, они противоречат друг другу. А существует ещё такое интересное явление, вот это вот сопротивление и саботаж внедрению AI. И чем больше компания, тем этого обычно больше. А поэтому от замедления на AI десятки процентов, там типа 20-25 до ускорения. При этом ускорение тоже неравномерное. На некоторых задачах ускорение достаточно большое, может быть, в разы, потому что, ну, они такие прямолинейные, а на других задачах ускорение там, не знаю, минимальное. Вот слишком ещё мало набрало человечество опыта, чтобы об этом говорить. Об этом и кроме того, очень сильно зашумленная область. Любая компания, особенно которой публичные акции торгуются, она рассказывает максимум, что у нас вот если раньше был когда-то блокчейн и вот всё там блокчейн и сразу же вот вот вам деньги, то теперь AI и вот вам деньги. И поэтому, а, очень немногие компании рассказывают об этом состоящую правду. Вот, что это и как у них происходит. Здесь то, что можно услышать, это опыт коллег инженеров, как оно вот у них на самом деле по опыту. Собственно, поэтому я прошу вас делиться, задавать вопрос.

Дмитрий, пожалуйста, я вас слышу.

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

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

>> Да, прекрасно. Я стараюсь идти быстро. Вопросов много, темы интересные. Пишите, пожалуйста, в чате. Я пытаюсь отслеживать ещё из чата. Так вот, я потом ещё, похоже, отдельно прочитаю чат, потому что там много прикольного. Особенности применения принципов безопасной разработки. А, да, существует. Это безопасность по данным, это безопасность по деньгам. Ну и это, собственно, безопасность по самой задаче. Это вот enop до агентов, которые валидируют. Это три уровня совершенно разной безопасности. Есть ещё такая там этот термин экономика токенов. Сколько на обработку там одного запроса пользователя я потрачу токенов в деньгах, чтобы этот запрос был экономически выгоден? Вот. А подобные вещи мы будем касаться на следующем этапе и в рамках нашего курса. Вот какие провайдеры вы используете. А более-менее всё написали ещё в начале. Методы параллельной работы агента сталкивались из complianceщениями приInble development со стороны моделей. Ну вот интересный вопрос. Напишите, пожалуйста, в чате, если с compliance вещами сталкивался. Использование Deepsik как дешёвой роли в отдельных местах. Ну, возможно, то есть я тут скорее этот вопрос перенаправляю нашим слушателям. Может быть, у кого-то уже есть экспириенс или ты, Сергей, если вот именно про Deepsik есть, что сказать?

>> Не про Deepsik нет. Ну, в целом про локальные модели, э, есть опыт, да, разворачивание на там локальных моделях. Вот для каких-то небольших задач, которые там касаются, не знаю, обработки почты, ещё чего-то, то есть уже способности, а, небольшими моделями, то есть не обязательно всегда подключать топовые модели, да, и тратить как бы больше денег и прочего на небольшие там анализы, которые вот а был опыт работы с обработкой дифов, то есть с локальной моделью, но это был не Deepsik, это Kven's модельки, но всё это было такие экспериментальные штуки. Вот. Но у нас в компании разрешён Cursor, поэтому вот большинство на нём делаю идко. Вот. А с точки зрения моделек стоит под каждую задачу выбирать модельку, экспериментировать, потому что есть задачи, например, с которыми вот Code справляется, а Gemini даже последний, который вышел 3.1 не справляется. То есть, >> да, да, >> по причине, что у него нету либо там, а, вызова сабагентов, вот, несмотря на то, что у него контекст больше, он не справляется с такой задачей, с которой Claude Code справляется из-за того, что у него, э, обвязка вокруг этого всего лучше. Поэтому, ну, >> надо экспериментировать. По написанию документации тоже. То есть, ну, >> да, я так понимаю, что сейчас про большинство вещей, которые стоят AI и про процессы, и про инструменты, и про всё на свете, надо экспериментировать, потому что, э, ну, компании себя хвалят, чтобы у них там акции, чтобы, в общем, у них всё было хорошо. А как оно на самом деле, не очень понятно. Значит, про безопасность я вот вижу, Иван интересуется. Это так, чтобы не потратить слишком много денег. Раз. Это так, чтобы не на токены. Это так, чтобы не отдать персональную информацию вовне и из из системы. Это тоже безопасность. И, собственно, безопасность, которая граничит с качеством, - это так, чтобы наше решение чего-то совсем сильно не запароли. Вернее, не наше решение, а решение моделей, чтобы их там или в процессе об там создания кода, или в процессе обработки какого-то запроса пользователя, обработки данных. Да, Иван, пожалуйста. Я слышу. Не слышно. Видимо, что-то с микрофоном. А, о'кей, пока нет вопросов. Прекрасно. Что гребных нет вопросов? Всё, что касается RAG и прочего. Ну вот и будет ли в демо про разработку кода, который разрабатывает код на метапе и на нашем курсе будет более подробно. Плой стандарт по оценке выхлопа, контроль периметра, видите, пронтов, а валидации всего лишь внешние костыли, которые нам дают детерминизм. А-а, Сергей, есть тут мнение какое-то?

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

>> У меня такое же мнение, то что есть разные задачи. Возможно, на задачах какого-то типа можно их сравнивать, да. Ну, на задачах, в общем, ну, как бы один сильнее тут, другой тут и всё. Как оно делает приложение на AI, ну, наверное, а, использовать всё то, что мы сейчас рассказали. Вот. А, слишком долгий ответ. А, ну, на вот на курсе будет абсолютно точно ответ. На мероприятии семнадцатого числа на этапе тоже будет, ну, как бы частичный ответ. Как воткнуть AI в процесс, чтобы продуктивность выросла на 40%? Очень желательно не снимать мне базу кода, за этим следят. Насколько опасно разрешать? Вот, мне кажется, сюда очень сильно касается тот рассказ, который я про аа то, что процесс должен быть зрелым. И как раньше нужно было там 2 года автоматизировать его, так теперь нужно 2 года автоматизированный процесс улучшать с помощью AI. И тогда, может быть, возникнут те самые 40% вот после этих инвестиций. И без, ну, собственно, без этих инвестиций вот так вот на раз-два это не получится. И более того, в этой области сейчас пока только, ну, какие-то относительно разумные эксперименты а происходят. То есть, ну, на самом деле, вот прямой вопрос, прямой ответ, как вот процесс, так втыкать долго и упорно экспериментировать и понимать, как наш процесс может быть улучшен, перепридумать его заново на основе AI и инструментов. Вот так. Как бороться с представлением Play Adoption? А, очень сложный вопрос. А потому что, ну, сотрудники, особенно, чем больше компания, тем больше это высота создания, насколько мне известно, они не будут делать то, что делает их ненужными. И это на любом уровне, от менеджера какого-то высокого до там самого низкоуровневого, там кого бы то ни было, нужно показывать людям, что компания как-то заботится о них и даже и не будет эвольнять, если если они начнут использовать. Это это только через культуру и мотивацию. Я бы сказал, что это out of scope, то есть это не про технологии, на самом деле, это про работу с людьми. Вот подробнее про RAG. Мы не подробно сегодня рассказывали про RAG. И семнадцатого тоже не будем. Подробно будем на курсе. Куда мы по итогу придём, никто не знает. Давайте экспериментировать. Ответ сегодня универсальный. Давайте экспериментировать. Вот я, у нас есть факторы, у нас улучшаются, продолжают улучшаться модели. А вот кто-то в чате писал, что вот я в январе то, что вышло, оно там вообще на голову лучше, и можно уже забывать про то, что было раньше и про те ограничения. Но рано или поздно алгоритмический потолок он есть. Где он будет? А, ну увидим. Когда он достигнут будет, ну, мы не знаем. Есть несколько чисто финансовых вещей. То, что, ну, я читал, это неверифицированная информация, что на 100 долларов токенов, а, приходится 1.000 долларов или около того энергии. Это раз. Второе, тот же самый Panai, в него проинвестированы сотня или даже уже две сотни миллиардов, а приносит он, э, там, я не знаю, десятки или или там какие-то сотни миллионов. То есть это разница в три порядка, кажется. Действительно ли это финансово разумная история и как вообще этот механизм будет дальше развиваться? Я думаю, от вот этих финансов тоже будет много чего зависеть. А вот то, что очевидно, то, что теперь инженеру нужно знать гораздо больше, чем раньше. Не только всё, что раньше, но ещё и как работать с AI и понимание какого-то конкретного домена и понимания процессов. Сергей, я думаю, у тебя тоже есть интересные мысли по этому поводу.

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

>> Не ясно. Ну, стремиться к нулю уменьшается, я бы сказал. Я тут это консервативнее, чем ты. Ну о'кей, мы мы будем видеть, потому что у меня слишком большой бэкграунд, который я слишком ценил, чтобы как-то вот бро сказать: "А стремится к нулю". Вот. А Сергей на это смотрит более незашорено без вот этого багажа, который я там годами десятилетиями приобретал, а теперь тут понимаю, что пришёл я и всё. О, обидно, слушайте. А вот о'кей. Двигаемся дальше. Где граница использования агентов и как договариваться с ИБ? Вот ИБ я вот знаю СБ что такое, а вот ИБ - это непонятно инфраструктура, интернет >> безопасно.

>> Ну, понятно, что это безопасность. А, просто инфобе. Я понял. А, Ивана, если у вас микрофон о'кей, то пожалуйста.

>> Слышно меня теперь? Привет. Слышно, >> да? А это в контексте. Вопрос про ИБ. А я больше задавал вопрос.

>> Ага.

>> Так, что-то вот слышно. 5 секунд не слышно. Две слышно. Что-то связь очень плохо. Дело в том, что в чате так много, что я прямо не это >> был до этого вопрос про тоже, как бороться с безопасниками, да? То есть у меня комментарий такой, что, а, надо договариваться, да, то есть потому что вот это вот скрывание того, что инженеры, неважно, разработчики делают, а, а, когда им безопасники просто не разрешают, то есть это уходит такое понятие, как shadow AI, когда там сливаются данные, да, которые не должны сливаться.

>> Договариваться всего там минимум два способа есть там использование это open source моделек, да, и разворачивание своей инфраструктуры. Вариант дорогой, сложный, но возможный. И говорят, что тоже не проверял, не знаю, но коммьюнити пишут, что использование там enterprise версии по API тоже, да, то есть корпорации. Вот они говорят, что по контрактам там написано, что они не обучаются на ваших данных и как будто бы некоторые компании могут тоже на такое пойти. Но верить им, >> верить им или нет, да, потому что сколько там было всяких битв, когда там данные какие-то приватные, на которые всё равно обучались, и там и гугловые модели, и OpenAI, и, ну, тоже как бы мы могли верить, но на самом деле это не так. Ещё там, да, эта история с Мотогоном правда в чате написал, тоже абсолютно узнает, да. Вот тут пока что выглядит гарантированная история, когда мы ставим локальную модель on-premise на свои сервера и закрываем её от всех, кроме нас, и сами её контролируем. Но здесь это дорого, это очень дорого и по ресурсам, и по организационным ресурсам, и по компетентностным, но и по по железным. Каком возримом будущее покрытие кода-теста нужно полностью переложить на бота?

>> Ну всё равно ж надо будет ревьюить, так что совсем полностью так нет. Сергей, как ты считаешь?

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

>> А спасибо, Сергей. Я совершенно согласен на этот раз технически, да. А интересно получится от стороны QA. Я хочу сказать, что QA может быть я сейчас буду этот стамбизм разработчика демонстрировать, да? что QA достаточно там техника проще, чем, ну, в самой системе обычно, не всегда. И, аа, и документация QA и, э, ну, многие процессы QA и написание кода QA и запуски там пайплайнов, они очень хорошо подтверждаются, а-а, вот AI. И вот по опыту разных компаний это вот те вещи, где можно получить достаточно большой выход. Вот идём дальше. Каким образом осуществляется порог 0.7? Не является ли это хорошо? Когда выгодно использовать графы? Для сегодняшнего это слишком специфичный вопрос. А насколько графовая база нужна среднему бизнесу сегодня? Является ли это больше маркетингом? Сложно сказать, что сейчас не является маркетингом. А RAG, а потом ещё и Сергей, может быть, ты скажешь, у тебя есть чёткое мнение, потому что у меня мысли расползаются.

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

>> Спасибо, Сергей. Иван, пожалуйста, слово. Приветствую ещё раз. Я надеюсь, сейчас со звуком нормально. Меня слышно?

>> Да, слышно. Всё, звук супер. Пар я хочу зануться. Вот вопрос там два вопроса было в контексте ИФобеза и там, чтобы поделить с опытом либо вы, может быть, у кого-то из ребят есть всё похожее. Смотрите, сучм три направления. Я коротко выстав. То есть это и Application безопасность. То есть самое простое и понятное при использовании AI агента. В стандартный pipeline, как правило, включаются инструменты SAST, DAST, да, а на проверку там на уязвимости на Superchain, цепочки поставок в библиотеке и так далее. Если мы имеем с помощью агента по кратной ускорению скорости генерации кода, то тогда вот это звено, а, виде там, не знаю, по-разному, во всех компаниях называется Security Champion, то есть люди, кто верифицируют там код на безопасность, на них, мне кажется, будет падать какая-то бешеная загрузка. Вот. И здесь тоже нужны какие-то инструменты для автоматизации, возможно, привлечения там специфических агентов либо моделей. Это одна история. Вторая, то, что касается DevSecOps, а это всё, что там связано с деплоем и развёртыванием, когда мы отдаём это на уровень модели, допустим, да, и нам нужно, чтобы у нас там не утекали секреты, чтобы у нас в кодовой базе не оставались какие-то ключи и так далее. И третий вопрос, ну, тоже это они все масштабные поводу MLOps, как примера. Есть организации достаточно крупные в России, которые не могут себе позволить, а, юзать зарубежные модели по разным причинам, да, и мы выбираем какую-то модельку из Open Source, а, ну, и разворачиваем там, выкатываем в прот, но при этом, а, зачастую никто там в 99, да, даже 100% случаях не смотрит модель под капот и не занимается такими вопросами, как, возможно, промжектинг и прочие вещи. То есть, что под капотом модели, как она работает, она выполняет свою функции, а вот в плане безопасности почти все всегда закрывают мне это глаза, либо а не придают каких-то значений там. Спасибо.

>> Сергей. Мы можем ответить на этот вопрос.

>> Вопрос в вопросе чувствуется очень много боли, как будто это, ну, я с таким честно не сталкивался, да? То есть я работаю в компании, где тфу-тфу-тфу, нету таких, а, отделов безопасности, да? Более того, у нас, э, открыты, а, возможности, да, по использованию там условного Cursor или используем там убираем какие-то персональные данные и в Cloud Code говорим какие-то вещи. То есть, ну, я не могу отметить. из коммьюнити слышно, что вся вот эта вот история про закрытый контур, да, в российских компаниях, вот этот вот закон по персональным данным, плюс в Европе немножко вот этот GDPR, там как бы всё идёт идёт в сторону, ну, локальных моделек. Вот. А всё, что могу как бы сказать, вот нечем дополнить.

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

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

>> ну да, то есть time to market, да, основной как бы становится основная метрика вместо количества написанного кода. И есть такой ещё метрика, а качество, да, на этапе тестирования, то есть в каком качестве фичи написанные AI поступает отделу тестирования, да? То есть вот и если эта метрика не ухудшается, а стабильно либо уменьшается количество багов, то как бы это тоже в задне смысле идёт.

>> Вот.

>> Ну >> да,

>> слышал такого.

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

>> ты считаешь?

>> Да,

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

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

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

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

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

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

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

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

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

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

Как изменится роль катастромер саппорт и аналитику снедренией? Спасибо. А, интересный вопрос. Э, Сергей, может быть, у тебя есть мнение, поскольку ты, возможно, чуть чуть ближе к кастомерам, чем чем я, да? из громких кейсов, что там такие компании большие, там, как Souls Sports, да, они посвязали кастомертопорт свой на не помню сколько процентов. То есть, ну, базовая обработка первой линии, там, маршрутизация кейсов, то есть, ну, это уже покрывается, а, иишкой. Аэ, вот, аэ, то есть эскалация, например, да, автоматизируется, то есть вот эта цепочка эскалации, то есть и я иишка отслеживает вот эти моменты, когда кейс должен, мм, а, быстрее решаться, то есть на определённый отдел, то есть тоже покрывается. Вот человек всё равно остаётся, ну, важной частью в саппорте, как бы вот, несмотря на на эту автоматизацию, потому что заме, ну, замена людей, а, пробуют, делают, делают их полностью, да, но как бы проваливается всё равно в какой-то момент роутинг идёт на человека, но большое вот. Аа у аналитиков а по аналитике появи появилось бы много возможностей у людей, которые не работали с аналитикой. Во-первых, да, то есть я, в частности один из таких. То есть за счёт того, что а с Иишкой на простом языке с агентами можно общаться, и у агентов есть доступ нам условно с QLбазе какой-то, либо даже к Big data какой-то, не знаю, Google BQ. Да. При грамотном подходе ты можешь доставать очень много инсайтов и без аналитиков вообще. А для этого, чтобы тебе это делать, тебе надо уметь строить дашборды или иметь аналитика на борту. Вот для самих аналитиков а меняется парадигма в сторону м то есть от от подготовки самих отчётов, как их было раньше, да, надо было копаться руками в аналитике, да, сами аналитики при изучении яинструментов способны строить, ну, такие типу а дашборды, да, самостоятельно, да, то есть персонализированные под какие-то отделы, персонализированные под каких-то людей. То есть вместо того, чтобы пользоваться стандартными дашбордами и копаться в данных, переходит как бы в формирование витрин данных, их так называют. Вот. Ну не знаю, как так.

>> А, о'кей, спасибо, Сергей. Так, слушается хорошо. Тут вопрос у нас не отнимает время. Какие перспективы йлот backнд разработки? Ну, HighТ обычная технически сложная вещь, которая и эти технически сложные вещи не так уж легко даются агентам. А поэтому перспективы пока остаются. Что будет через год полтора-два, когда он будет, возможно, очередной прорыв, ну, не знаю. А вот, безусловно, использовать вот эти вот подходы AI разработки абсолютно необходимо и там, потому что там тоже есть свои тесты и там есть свои особенности. Просто это поглубже в технику, чем, ну, условно трёхуровневая архитектура веб-приложения.

Какие типичные ошибки при переходе KI индивидуальные на уровне компании? KI development. Ну, первая типичная ошибка - это когда у нас он этот процесс не выстроен. Очень много раз видел, как ребята пытаются: "А давайте тут и я, и тут вокруг, давайте мы тоже себя использовать". Если нету порядка, нету чёткости, то я получше. Это, не знаю, наверное, с вот из моего видения буквально там процентов 70 всего. А вот А, Сергей, может быть, ты что-то добавишь? >> Ну, если говорить про ошибки разработчиков типичные, да, то есть это, а, слепой, да, такой вайпкозинг, делегирование архитектуры Иишки, то есть таких ошибок очень много, да. Вот, а вот, аэ, пропускание режима планирования, то есть, э, при построении чего-то, да, сразу идти в бой, э, в кодинг, условно, да, пропускает этот режим планирования, тоже ошибка. Вот, э, ошибка и можно сказать вот этот процесс перекидывания ответственности на кого-то там на следующее отдел, условно на тестировщиков. То есть это вообще неправильный подход. Это, а, часто просто в комьюнити тоже встречаются, пишется, что пренебрегают этим процессом ревю, а, ручным ревю, а, даже иишным ревю и пилят большое количество фищ и с большим и с большой нагрузкой на отдел тестирования. Вот. Ну и ошибки на уровне компании. Это, э, не знаю, то есть спускание Иишки сверху, да, то есть за счёт KPIя для какого-то менеджмента. Год назад они кричали просто нам надо и не разбираясь. Сейчас они готовы платить 20 тире 100, даже 200 долларов за подписки, лишь бы уже какие-то результаты показывать. Вот когда команда не готова, это одна из самых важных таких штук, сложных адаптация. Вот есть даже компании, которые выделяют деньги на всякие воркшопы, хакатоны. Вот лично один раз участвовал в таком хакатоне в виде ментора, где компания известная выделила деньги. Ну, не освободило ребят от рутины. Забыл освободить. И на этот хакатон ребята даже не смогли прийти за за счёт загрузки. А те, кто пришли, не смогли полностью отдаться, да? То есть, несмотря на то, что проекты на хакатоне были классные, да, вот даже цепляющие и, ну, типа за один день, ребята, за за 2 дня они сделали хорошие проекты, всё, они в своей рутине. То есть, ну, ошибок со стороны компании тоже очень много, но они касаются процессов и неравномерного такого внедрения и на разных этапах поддержки этого. Везде есть ошибки. И со стороны сниза, и сверха. И должна быть системность какая-то.

Спасибо, Сергей. Как подличать агентов Legacy проект, которые запутанные, старые и так далее, и так далее. А интересно, что Ой, что там в чатике происходит? Так, подписывает. Так, о'кей, хорошо. А как причать агентов? А, Сергей, может быть, ты расскажешь про особенности, связанные с Legси? >> Ну, поесть а подходы, ээ, когда до того, как ты, когда ты начинаешь подключать проекты к реальные проекты к кодинговым агентам, надо сначала не пренебрегать подхода аудита, да, его называют. То есть тебе надо пройти сначала такой этап аудита, сканирование всего кода и индекса его, да? То есть создание специальных таких индексов. Это не не обязательно, это векторная база, да, куда надо всё сложить. Это хотя бы базовая какая-то аа прогонка по файлам, а по тому, что в этих файлах есть. А и чтобы агент в будущем, работая с ними, увидел какие-то хотя бы зависимости, да, что может сломаться, да. Плюс в самом коде добавление комментариев, да? То есть слышал, что это помогает очень сильно агенту работать, взаимодействовать с этим кодом. А рядом с кодом пишется документация, да? То есть уже по существующему проекту коду сначала фокус на документации этого всего, потом уже приступают к работе там доработки и внедрению новых фич. Вот есть продукты, которые, не знаю, уже полтора-д года пилятся только для того, чтобы большие лекаси проекты подключать к агентам. Коды Life там один из таких на слуху. Вот смотрел вебинар ребят, где у них там много этапов векторизации, векторизация самого кода, векторизация архитектуры. Всё это связано, взаимосвязано, чтобы, ну, большие LECOC проекты подключаются, работать с ними. Сложная тема. Вот всё зависит от объёма проекта. Ну точно не подключиться и сразу что-то разрабатывать, это факт.

>> Спасибо. Как внедрить в преподавание разработки приложений? Очень ответ очень простой. Этого автора я прошу написать мне в Линки День или в Телеграмы, чтобы мы пообщались. Интересная тема.

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

Стоит ли поднимать локальную ариишку и скармливать ей код своего приложения? Я думаю, что что нет. Это в общем случае излишнее. Сергей сейчас очень хорошо рассказал про движение для, ну, развитие и для legси систем. А вот а и э ну судя по формулировке вопроса, наверное, пока достаточно пользоваться только вот тем, что доступно онлайн. А вот Сергей, да, >> ну да, тут сложно как бы даже с не с локальными яишками, да, в этом плане, а с локальными ещё тяжелее, потому что, ну, способности локальных моделек намного меньше, и, соответственно, с меньшим контекстом они могут работать, с меньшим результатом, а, медленнее. То есть тут ещё жёстче подход, поэтому >> Угу. >> О'кей.

Какая сетка? Ну, для кода это, разумеется сетки от антропик. А вот гемени для меня больше для гуманитарных задач. Ну, это, наверное, у кого как. Это отдельная история. Давайте сюда не врутим это самое. Значит, если рассматривать агенты, вкачать гибридные команды, с помощью каких-ниструментов ставит управление текстом для всей команды. Прекрасный вопрос про устраивание нового software development Life Cycle. Это это, наверное, это все инструменты, которые только есть, потому что этот контент контекст распространяется и сверху возникает на каждом этапе ээ цикла. И это и в том числе скилы, и документация, и раги, и, ну, в общем, все инструменты. Сергей, может быть, ты скажешь что-то более конкретное? Ну, в контексте работы с агентами мне нравятся подходы, когда это уже такие компании, а, где, а, а, не знаю, разные отделы работают с с одним репозиторием, да, и за каждую папочку отвечают свой отдел. Разработчики условно отвечают там за всю движок в самих кодинговых агентах, там за рулы и прочее, да, но при этом есть бизнесовые какие-то маркетинговые папки, продуктовые папки с родмапой. То есть это всё открыто для команды. Если говорить про здоровую компанию, которая работает с агентами, это не три человека сами по себе работающие, да? Это в идеальном картинке мира это люди объединяются, и тогда вот общие такие мемоory банки у них есть, э, с общими файлами. А, о'кей. Хорошо.

Последний вопрос. Как лучше использовать а длятивной работы? Это вопрос даже шире, чем наша тематика, потому что мы тут про продуктивную разработку, а они ани просто продуктивную работу. Вот. А на самом деле на этот вопрос достаточно хорошо можно ответить тот же Гемени 3, даже 3.0, что он мне отвечал не так давно вот здесь, а, когда я это исследовал, а, и их советы просто постоянно меняются со временем. И поэтому, что он говорил 2 месяца назад, и сейчас, они вот уже немножко отличаются. Значит, здесь нужно понимать, что у нас весь ключ в контексте. Есть целые механики по тому, как делать правильные промты и целые, а, и для начала лучше начать с этого, потому что даже когда мы делаем агенты, даже когда мы делаем скилы и делаем промты для агентов, то аа они должны соответствовать, ну, правильному выстраиванию промтов. Вот курсов по промотам достаточно много, очень много рекомендаций отропика, и от и от Гугла по тому, как выстраивать гранату. Начать лучше с них, судя по формулировке вопросов. Вот. О'кей.

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

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

>> Иван, как вам созвониться вдвоём и понять, может быть, вы там и выступите. А контакты же в почте есть, наверное. Спишемся сейчас там публич. У меня достаточно а сложный бэкграунд. Не, я близок был одно время к инфобезу, поэтому светь контакты прямо напрямую сейчас чакать не буду. В почте, если есть, там понику найдёте, спишемся и думаю.

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