Как ИИ встраивается в процессы организации. Открытая лекция

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

А краткий план сегодняшний: а немножечко предпосылок и теории, как вообще влиял, в принципе, искусственный интеллект, его появления с примерами и исследованиями. А что такое бизнескод? Как ответ на те проблемы, которые подняты? И а матри, ну, матрица, лестница зрелости, пять ступеней к зрелым процессам, которые пригодны к тому, чтобы класть на искусственный интеллект. Вот. И, а, некоторые моменты, риски, проблемы частые, которые происходят, когда мы перекладываем процессы, а, на искусственный интеллект и пытаемся улучшить, ускорить нашу организацию. Ну, в конце будет Q&A, там отчасти про мифы, отчасти про немножечко смену фокуса. На все 11 вопросов, которые были, ну, содержательных вопросов, которые были в регистрации, я развёрнуто отвечу в конце.

Итак, кто я такой? Я как это архитектор-основатель Hearts of Skills. У меня достаточно большой опыт, в том числе в больших компаниях, маленьких и так далее. Сам я не раз выстраивал различные процессы, как просто отдельные процессы в ролимда, отдельные процессы в управлении качеством, так и полностью процессы а в компании, касающейся разработки всей, а так и процессы в Hearts of Skills, в том числе. А вот, а немножечко про Hards of Skills, если вы ещё не в курсе, мы обучаем, а, очень синьорных товарищей, сеньоров, архитекторов, enterprise архитекторов и прочее, и консультируем компании по самым животрепещущим темам работы в работы IT-подразделений, что очень важно. Мы не даём голой теории, нас всё этот опыт покрытый по потом, деньгами, иногда, наверное, кровью. А вот.

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

Итак, я сегодня постараюсь дать вам системный чёткий взгляд с опорой на исследование, с опорой на практику, на прогнотизм, здравые смыслы и ценности бизнеса, то есть рои и деньги. Time to market, а в той части, которая рассказывает про которая касается искусственного интеллекта в процессах. Вот.

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

Итак, о чём а шла речь про разработку разработки касательно искусственного интеллекта. А двадцать третий год магия чат GPT помощники для кода. Всё-таки я сейчас всё вообще изменится изменится профессия. Ну, тут все будем вайpкодить и так далее, и так далее. Двадцать четвёртый год начали чего-то мерить. Строгие первые замеры. А GHub GitHub Cilot аа значит группа с искусственным интеллектом справилась в полтора раза быстрее, на 55%. Аа 11 против 2 часов 41 минута. Было большое исследование, а-а, Дора про десятки тысяч, на десятках тысяч инженеров, что на уровне отдельного человека искусственный интеллект улучшает качество, поднимает скорость ревью и так далее. Но при этом тоже исследование Дора говорит, что другое исследование аа и этой же организации, что на дивири, на доставку искусственный лектор оказывает отрицательное влияние. В двадцать четвёртом году стабильность падает на 7%, пропускная способность организации чуть-чуть падает на 1,5%. И получается, мы пишем код быстрее. А команда в целом лезет чуть-чуть реже и чуть-чуть больше багов. Вскоре лишака вся цепочка к этому оказалась не слишком готова.

Вот двадцать пятый год, год какого-то такого отрезления. Появляется слово viбкодинг. Его запускают Карпати, который со основатель Open AI, типа доверься вайбу, пиши словами не смотри код. А вот а к осени произошло отвредние от этого термина, что пулреквесты, когда мы их разбираем, показывают, что в коде написано искусственным интеллектом на 70% больше серьёзных багов. Вот и самый, значит, важный такой трезвый эксперимент, отрезляющий, это исследование метр летом двадцать пятого года. Шестнадцати опытных разработчиков дали и задачи в их проектах. Искусственным интеллектом они работали на 19% медленнее. При этом они были уверены, что искусственный интеллект их ускорил, ну, в среднем на 20%. Это разрыв между ощущениями и реальностью 40 пунктов. Вот. А и это очень важный показатель того, как искусственный интеллект влияет на наше восприятие с одной стороны, на нашу скорость. С другой стороны, и какие бы исследования и цифры вы не читали и не видели, всегда, пожалуйста, смотрите. Это по моим ощущениям или по каким-то объективным метрикам?

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

А что касается отдельного разработчика, это я а знаю скорее по отзывам множество коллег и по своему опыту, то, что сильного отдельного инженера искусственный интеллект усиливает ещё больше, а слабого новичка он оставляет в пропасти Даниминга Крюгера, потому что слабый новичок не может задавать глубоких вопросов и не может понимать, на что смотреть на самом деле. А средний инженер при этом начинает постить гораздо больше, ну, постить, комитить, отправляется гораздо больше пулреквестов гораздо большего объёма, чем раньше, при этом запутывая архитектуру и снижая поддержку, ухудшая поддержку в долгосрочном режиме. А сильный инженер, усиленный ещё и стал писать, создавать меньше строк кода, чем раньше. Но каким-то магическим образом эти строки кода решают больше бизнес-задач, бизнес-проблем, чем раньше. Вот такая удивительная а штука. Вот. И то, что мы здесь сейчас видим, это не только проблемы программистов, это проблемы любого процесса. И здесь можно взять эту канареечку и обобщить на любую индустрию. Вот. А в цикле разработки по скорость отдельного человека не, ну, вовсе не обязательно ускоряет всю организацию. В любом процессе, если сотрудник быстро выполняет задачу, не значит, что а вся цепочка будет создания ценности будет работать быстрее по той простой причине, что, может быть, задачу он и до искусственного интеллекта делал один час. Зато согласование отнимает 4 дня. Сейчас он делает задачу не за 1 час, а за 4 минуты. Ускорение больше, чем в 10 раз у него на этой задаче. Но цепочка как была 4 дня утверждения, так и осталась. И по смыслу, собственно, ничего не поменялось.

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

Вот. А и я здесь привожу первую аналогию, то, что организация - это как распределённая система. её отдела - это микросервисы. Микросервисы работают в какой-то инфраструктуре в Мас продакшене, тамс или там Amazon или, в общем, что угодно. Они между собой коммуницируют синхронно, асинхронно. У нас там среди микросервисов есть eventual consistency, когда данные в одном сервисе уже изменились, до другого ещё не дошли. У нас там есть такие страшные шаблоны, как сага, когда одно одна задача должна выполниться её часть в одном микросервисе, в другом, в третьем, а потом общий результат является результатом всей задачи. Точно также в организации отдел. Подразделение, отвечающее за функцию бизнеса, это микросервис. У него есть внутренние процессы, внутренние данные, внутренние регламенты. Между собой эти подразделения тоже общаются. А есть большая цепочка создания ценности, пронизывающая все или почти все подразделения и выполнение одного кусочка цепочки, потом второго, потом третьего. И только после третьего мы имеем уже полную ценность, которую можем кому-то продавать. Вот такая аналогия. А, и если у нас в нашей продакшн системе, а, есть код, а, там конфиги, хм, скрипты, там всё, что угодно, а, инфраструктура, то в бизнесе код - это регламенты, это описанные процессы, которые люди, которым люди в идеальном мире чётко следуют. Ну, разумеется, люди следуют далеко не идеально. Процессы где-то скругляют углы, где-то какие-то процессы просто в голове у одного человека, и никто не заботится о том, чтобы оттуда влынуть и так далее, и так далее. И получается у нас, а, очень запутанная микросервисная система, аа, ну, вот этого бизнеса, в которой очень сложно разобраться и которую никто не знает, как же она на самом деле работает. Собственно говоря, те, кто поддерживал какие-нибудь LEGO системы, а, часто сталкиваются с, э- проблемой, никто не знает, как оно работает, никто. Оно как-то работает. выполняют ключевые функции бизнеса, между прочим. Но мы туда лазить не будем, менять ничего не будем, потому что это очень страшно, потому что мы можем поломать, а если делать по уму и не ломать, то нужно обкладываться тестами и выделять на это месяцы и годы. Вот. И в результате этот монолит, Legacy, монолит, запутанный, перепутанный, непонятный, так и остаётся и работает ещё следующие 10 лет. Вот. И если наш код микросервис исполняется достаточно быстро, измеряется миллисекундами и секундами, то в бизнесе код исполняется гораздо медленнее. Регламент исполняются днями, может быть неделю. И вот здесь может появиться искусственный интеллект и ускорить некоторые части этих недель. А вот это это первая аналогия.

А значит, очень важная вещь, которая касается статистики внедрения искусственного интеллекта в разные организации. Тут тоже по разным исследованиям и Макинди, и МИД, и вот Boston Consulting Group, а 95% внедрённого, ну, типа попыток внедрения искусственного интеллекта как никак не повлияли на прибыль. То есть у них был отрицательный рои. Это означает, что деньги были как-то затрачены, а, и -э от них ничего не поменялось. Вот, может быть, они что-то улучшили, может быть, ничего-то ухудшили, но как компания получала свои, а, эти деньги зарабатывала, ровно столько же она и продолжила зарабатывать. И только у 5% внедрения искусственного интеллекта оказалось какое-то влияние на прибыль. Вот, причём в долгосрочном относительно измерении. А вот а Boston Boston Consulting Group говорит примерно то же самое. У 5% есть какой-то результат, у 60 компаний нет результата. Ну, видимо, у тридцатип оставшихся отрицательный результат. Вот Маккинзи. Вот очень важная, интересная вещь, которую они вычленили из своих этих самых, а что какое-то ощутимые там возрастание получилось у 39%. Ну, видимо, важно то, как они измеряли и выбирали компанию. Вот. И вот здесь он упоминает бота, потому что бот - это классическая история внедрения. Это первый ошибочный шаг, который должны все совершить, чтобы понять, как делать не надо. Вот и Макинзи говорит о редизайне процессов, что если процессы зодизайнены по-новому под и, то тогда может получиться. Если нет, то как бы не может. Вот. А и ещё одна история про ещё ещё одного отчёта именно про встройку процесс. То, что именно встройка процесс самое главное здесь. Вот.

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

Итак, а-а, вообще знаменитый кейс Кларна, который очень сильно распиарен, там речь была про поддержку клар - это финтех. Аа в поддержке они аа в двадцать каком-то там втором, в общем, за какой-то период они уменьшили количество аа людей с 5.000 до 3.800, заменив искусственным интеллектом многих, ну, большинство из них, а искусственный интеллект сделал 2,3 млн диалогов. Э, значит, ускорил время ответа и по прогнозам или 40 млн больше в год и они стали зарабатывать. Вот. Но к двадцать пятому году они поняли, что качество этих диалогов никакое, а что их глава значит сказал, что они слишком увлеклись. И теперь они переходят на гибрид. Искусственный интеллект и люди. лучший для поддержки сценария, когда искусственный интеллект предлагает и подсказывает решение, и только человек может нажать поотправить или отредактировать что-то по-своему и отправить. И вот это вот очень яркая история того, а, ну, в общем, этого хайпа про замену людей и так далее. А вот увеличилась доля Сыи, увеличилась, качество снизилась, а потом перешли на гибрид и доля с крустным интеллектом упала. Но при этом они уже научились и наверняка обрабатывают уже не за 11 минут, а может за 4-5. Этого правда я не знаю. Это мои спекуляции. Вот.

А искусственный интеллект задевает первым менеджеров среднего звена и новичков. Про новичков я уже говорил, про Данинга Крюгера, а менеджер среднего звена, потому что их работу потыкать всех, узнать статусы, написать отчёты, всё больше можно делать и но у них, а, изменение в занятости не такое уж большое, всего лишь на 6% меньше вот стало. И есть такой термин, ну, типа великое уплощение. Вот рутинные какие-то повторяющиеся операции, которые не требуют слишком большого интеллекта. С новичками чуть похуже ситуация, а, значит, потому что простые стартовые задачи новичка можно отдать искусственному интеллекту вообще без каких-либо особых проблем, потому что новичок будет заниматься ерундой и делать плохие решения. Сквозтеллект будет делать то же самое, только быстрее, гораздо дешевле. Мне нужно его там как-то э рекрутить, анбордить и прочее. Вот. И поэтому во множестве профессий есть во множестве индустрий и разработка по снова здесь впереди всех, а а джунам крайне сложно найти работу, потому что они уже должны быть не джунами, как было там 7 лет назад в двадцать там втором, первом году и и раньше. Они уже должны быть по тогдашним меркам, ну, медлами минимум. А это означает, что им нужно учиться сначала как-то где-то как-то непонятно год минимум, а то скорее 2-3 года, чтобы быть полезными лучше больше и давать больше, чем бизнесу, больше, чем искусственный интеллект. Вот, конечно, есть и другие драйверы, влияющие на это, и общемировая это как бы рецессия, и прочее, но тем не менее мы видим вот это доля искусственного интеллекта в причинах тоже есть. Вот. А так что здесь пишут? Интересное пишут. О'кей.

И значит, мой ответ на всё это. Собственно, концепция, которая известна достаточно давно, на именно искусственным интеллектом, она может развернуться в полную силу. Раз уж есть у нас аналогия продукта бизнеса, работающего и программной системы, давайте эту аналогию расширим и доведём до абсурда. и посмотрим, будет ли это полезно. И вот появляется концепция бизнеса The CД. А применять к развитию бизнеса те же приёмы, как и к коду. А и а можно каждому элементу программной системы, каждому этапу процесса разработки ПО соотнести соответствующий этап развития бизнеса. Ну, распрёбная система в Проде - это работающая компания, код - это регламенты, процессы. И внимание, описаны. Если они не описаны, то не считаются. А в программной системе у нас есть те, кто её создают. Это вот весь IT, всё IT-подразделение в бизнесе. У нас есть сотрудники, но здесь одна оговорочка, то, что сотрудники в бизнесе продолжают выполнять свои функции и постепенно занимаются тем, что их автоматизируют всё дальше, всё лучше, всё больше и превращаются из сотрудника в сотрудника плюс разработчика процессов. Вот. Атайм, среда, инфраструктура в программной системе исполняет код. Искусственный интеллект исполняет код, наши процессы и регламенты. А у нас есть разные роли внутри разработки. Они передаются разным, ну, сотрудникам разных ролей в бизнесе. А менеджеры могут быть как продуктонерами, так и QA, ну и так далее. архитектор а программной системы, который выстраивает все взаимосвязи, понимает, что нужно бизнесу, функциональные, нефункциональные требования, ограничения и так далее, и так далее. Это SEO, который, э, понимает, что нужно бизнесу, куда мы идём на рынках, какие у него возможности, ограничения, требования и так далее, и так далее. А эту аналогию можно продлять очень глубоко. код версионируется, регламенты версионируются, а вот той версии, той версии и так далее мы можем узнать, кто изменил регламент, кто выполнил его и подписался под его результатом из людей. Имею в виду не искусственный интеллект. У нас могут быть тесты в наших регламентах, какие-то год датасеты для того, чтобы понять, что мы не ухудшили нашим изменениям процесс такой-то и так далее. А вот а в этом а в этой аналогии есть лишь одна сложность. Когда у нас бизнес является бизнесом по разработке по в первую очередь аутсорс компании, то эта аналогия усложняется очень сильно. Потому что очень сложно думать одновременно про вот это и про бизнес, про вот это. Это ломает. Ну, это нужно очень глубокую дисциплину мышления абстрактного иметь, чтобы понимать. Но в целом Outsource компания тоже может быть вот просмотрена как бизнес код. Это просто, ну, немного сложнее, концептуально сложнее.

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

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

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

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

А следующий уровень — это инженерный менеджмент. И здесь уже, собственно, и начинается дисциплина разработки, как в разработке программного обеспечения. У нас есть версии, у нас есть кодревью, обязательно у нас есть планирование и так далее. Разумеется, не в каждой разработке эта дисциплина есть, но я имею в виду хорошую и красивую разработку. Это влияет на time to market. Он ускоряется, улучшается, уменьшается, упрощается операционка и измеряется в куче других критериев, первый из которых, собственно говоря, деньги, либо зарабатывание, либо экономия.

И самое интересное, что здесь происходит, почему я говорю именно про промты и скиллы и даже не загадываю на какие-то более сложные инструменты, потому что опыт того же Anthropic за год работы с двадцать пятого по двадцать шестой, с его количеством команд говорит, что самые успешные команды отказались от суперфреймворков в пользу простых инструментов, которые постоянно улучшаются. И зрелость здесь не в сложности и там архитектурной абстракции, а в дисциплине, дисциплинированном следовании всем правилам. Банально, занудно, вечно актуально.

Дальше. А следующий уровень — бизнес как архитектура. Ключевое изменение, что процессы становятся прозрачными. Узкие места видны из мониторинга, из логов, из журнала обновлений. Каждое действие агента, оно там остаётся в аудитлогах. Это очень хорошо помогает находить ошибки. И ошибки не у людей, которые их исполнили, а у промтов регламентов, которые можно там как-то улучшить либо с помощью более качественных промтов по best practice спромтинга, либо с помощью примеров, ну и так далее.

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

А значит, как двигаться по этим ступеням? Сначала ползти на первых, на нулевом, первом, немножечко ускоряться на втором и третьем. Ну и, собственно, бежать. Пропускать нельзя. Можно прыгнуть и попытаться. Это будет слишком дорого и не получится. Вот.

А отсюда из предыдущей статистики, которую я рассказывал, следует, что большинство компаний, буквально процентов 90 точно находится на уровне ноль и в лучшем случае на уровне один. Это же касается и большинства компаний по разработке ПО тоже.

Итак, а теперь я для каждого уровня расскажу вам, какие критерии должны удовлетворяться, чтобы мы считали, что мы на этом уровне.

Итак, уровень иллюзий. PNL вообще не меняется. Красивые слайды. Никто не потеряет ничего, если что-то не получится. Данные как были где-то разрознены, так и остаются. Вот. Ответственности за это нету.

Теневой. Значит, люди разово по случаю применяют что-то полезное. Buy your own AI паттерн. Организационный 90% использования через всякие чатики, Gemini, ChatGPT, что угодно. И руководители делают это больше всех. Находки гибнут. А вот при этом, если у вас А, ну да, двигаемся дальше.

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

Дальше. Дисциплина. Начинается выделение технической команды, которая управляет инструментами и развивает их. Это может быть бот на этом этапе, но уже понятно, как этот бот устроен за счёт предыдущих шагов опыта, накопленного на них. А мы управляем данными, метриками. И самое интересное, у нас появляется вот только здесь измеримый результат. На уровне два измеримого результата не было. Потому что, ну, вроде как субъективно улучшается, данные структурируются. Как мы меряем, непонятно. Вот только вот в уме можно представить. Раньше мы это делали востоко, теперь, ну, вот явно восток, наверное, есть улучшение. Вот только на уровне третьем мы можем сказать: "Был раньше такой промт, стал такой, ещё оброс, и поэтому у нас что-то там улучшилось". Вот. И важная мысль: простые паттерны лучше сложных.

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

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

Итого в результате. А, а у нас сначала не итого, у нас сначала риски и проблемы. У нас получается провал, когда искусственный интеллект подключен к отечественному процессу без его изменения, когда мы делаем ставку на готового агента, который мы нашли где-то на GitHub, а и который там как-то красиво описан. Вот. Когда этот агент использует разрозненные данные какие-то где-то PDF-ные, что-то учитывает, что-то ему невидимо, и поэтому принимает решения какие-то хаотичные.

Вот специально для инженеров принципы DRY и SOLID. А можно очень чётко переложить на принципы работы бизнеса в процессах. А вот одна ответственная копия правил — нельзя дублировать. Конверсионирование позволяет делать. Расследуя сбой, какие-то изменения. Паспорт и метаинформация. Значит, что будет, если его делать, и что будет, если его не делать. Ну и вот эти вот принципы SOLID: один заказчик, одного шага на ответственность. Или у нас антипаттерн — это God object, объект, который делает вообще всё, и в котором невозможно разобраться. А вот исполнитель. Вот каждое новое требование ломает работающий процесс, если этому не следовать. Взаимозаменяемость исполнителей или людей, человека на человека или человека на агента. Если мы неправильно это сделаем, то у нас получается бас-фактор очень плохой и так далее.

А вот опять-таки сквозная важная цель, которую очень сложно, вернее, важный аспект, который очень сложно делать, а, но который абсолютно необходим — это нельзя автоматизировать бардак. А вот. И самое ещё главное — это сопротивление, саботаж, изменения людей. У человека, когда ему говорят: "Ну, сейчас мы твою работу на 3/4 ускорим и заменим искусственным интеллектом, который её будет делать там в 10 раз быстрее без особых ошибок. А вот, а ты вот только там у тебя останется 1/4 и всё". Что делает нормальный человек в этом случае? Он пугается. Почему? Потому что ему нужна его работа. И это одна из причин, почему так искусственный интеллект внедряется медленно. Вот. А при этом люди, сотрудники не очень понимают, что, вообще говоря, если они ускорят свою работу в масштабе организации, то организация станет успешнее, работы станет больше, и, возможно, и денег станет больше. Вот сюда ещё добавляется обычное человеческое нежелание ничего менять. Ну и прочее. И работа с сопротивлением является самой большой проблемой при наведении порядка по самым разным причинам. Поэтому начинать внедрение искусственного интеллекта нужно с каких-то очень маленьких шажков, понятных, простых, предсказуемых, когда ошибиться не очень страшно, а и когда можно представить историю успеха для следующего чуть большего шага.

При этом вот у меня написано стоп-критерии. Когда я запускаю свой пилот, я говорю себе: "Я потрачу на него не больше там недели или там какого-то времени, или подразделение потратило на него не больше месяца". Почему? Потому что иначе он может превратиться в вечную стройку, постоянное улучшение. Ну и, в общем, точно так же не будет иметь смысла. Вот.

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

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

А поэтому из первой цитаты основателя Anthropic, вы совершенно правильно сказали, что там рай или проблема — это решает не модель, не искусственный интеллект, а те, кто правильно наводит порядок в процессах. А Итак, у нас есть of Skills несколько курсов, посвящённых переводу бизнеса на более зрелый уровень. Для сотрудников, для менеджеров, для собственников, C-level с другой стороны. Ну и краткая версия тоже. Кому интересно, пожалуйста, пишите либо в чат, либо переходите на сайт, регистрируйтесь, а там много меняющей голову информации. Вот. А кстати, вот комментарии Рената, да, обратный эффект, когда руководство пушит всех. Потом появляется ещё один интересный эффект, когда руководство думает, что у нас уже везде и внедрено, и всё классно, а сотрудники такие репу чешут и говорят: "Где?" И и нету никакого, и у нас тут какая-то ерунда, которая никому ничего не помогает. И это говорит о том, что руководство и вся организация находится на уровень ноль или максимум один по матрице зрелости. У руководства красивые презентации, отчёты, а у людей buy your own AI. Вот.

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

Прокомментирую всё, что пишут в чате. Павел, пожалуйста. >> А, Павел, спасибо за презентацию. Было интересно. Вопрос такой. Вот мы говорим про внедрение ИИ в организации, где с процессами так себе, да? Ну, на самом деле, это проблема, мне кажется, очень повсеместная. Процент, наверное, 80, особенно там ритейл. Вот. А, но тут же палка о двух концах. Ты приходишь, говоришь: "Надо, могу автоматизировать процесс, давайте опишем процесс". И тут начинается боль, да? А, но с другой стороны, пока реальный бизнес не увидит выгоды от автоматизации через процесса, да, он не будет пытаться это делать. Я к чему, что вы правильно излагаете, наверное, вот начинать с самых простых процессов. Но я к тому, что даже если всё плохо в организации с процессами, а надо разрывать этот порочный круг и начинать, наверное, может это неправильно, конечно, инициировать даже, может, со стороны IT, если вот IT при бизнесе, как вы считаете?

Значит, ну, пилот на маленьком процессе, во-первых, позволяет увеличить личные скиллы, личную ценность на рынке для сотрудника, что всегда хорошо. Во-вторых, он позволяет сделать нечто, что можно продавать дальше и внедрять в организации. Да, смотрите, я сделал вот это, теперь я сделаю чуть-чуть больше, и у нас у нас будет ещё больше пользы. Но здесь я хочу указать на, ну, то, что я вот рассказывал, да? А сотрудники боятся нормально. [откашливается] Во-первых, у них изменения в работе, в жизни, во-вторых, они боятся, что их реально заменят. И с этим придётся бороться. И вопросы: "Ты что, тут самый умный?" Они будут. Это одно. И второе, что ещё более важно в рамках всей организации, то, что фаундер, CEO, который занимается текущим управлением, сумел довести компанию до этого уровня и вообще за это молодец большой, потому что не каждый может. А и его мышление вот на этом уровне мышления по только что касается порядка. Так, вот это вот инженерный подход к процессам. Это мышление уровня следующего. Пока у него в голове не вот это не переключится, он не будет воспринимать вот, ну, всё, что будет вот на этом уровне мышления, ну, предлагаться, даже в терминах там ROI, денег и прочего, он будет несознательно уничтожать, саботировать там и так далее, не предоставлять ресурсы любыми способами, потому что его мозги не приспособлены. Это точно так же, как сотрудник боится, что его уводят, не понимая, что работа, вообще-то, скорее всего, станет больше. То же самое этот же процесс, но только у фаундера. А, ну, когда-то давно я не описывал процессы, потому что, ну, ещё для моего маленького бизнеса описывать процессы. Потом у меня изменилось мышление, и я описал процессы, потому что это способ роста из маленького бизнеса в больший. Вот это вот мышление руководителя, фаундера и прочего, которое должно измениться, чтобы это всё имело успех. Вот именно оно важно. А после этого уже: "Ага, я описываю процесс. А как это делает лучше? Ага, у нас что-то искусственный интеллект-то есть. О, как я его могу и сюда применить?" Это только инструмент. Вот. И как мне там знакомые 10 лет говорили: "Ой, в бизнесе главное описывать процессы". Типа, ну, на каком-то этапе, на самом деле, на разных этапах разные главное, да? Но вот те, кто это понял, могут использовать крутой инструмент, искусственный интеллект, чтобы это там ещё больше ускорить и не только описать, а ещё сразу и наполовину автоматизировать. Те, кто не понял, будут и дальше там, ну, не знаю, там ручками передавать, там писать письма и прочее. А поэтому вот ещё такой аспект я, ну, прошу учитывать, потому что от него дальше всё будет происходить.

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

Спасибо. Именно так. Очень чётко. А, итак, перехожу к тому, что написали. Дмитрий пишет: "Ещё живой вопрос с ответственностью за косяки". Кстати, будут все вопросы, которые были заданы в регистрациях, они у меня подготовлены. Итак, Дмитрий, вопрос ответственности за косяки. Централизовать базу знаний — это хорошо, но как правильно выстроить? Очень важный вопрос. А потому что кто кто подписывает, чья ответственность, кто будет, ну, там, не знаю, наказан или кто вообще отвечает за то, что у нас происходит. А, и в значимых каких-то решениях внутри организации должен быть человек, который сделал ревью, в данном случае не кодревью, а регламент ревью, из-за которого произошла такая-то проблема. И если это совсем значимые процессы, то не только ответственность за тот промт, который он написал, но ещё и за этот человек должен просмотреть каждый результат фронта в каждом кейсе выполнения и там его скорректировать или, в общем, что-то ещё. Это вот та самая гибридная модель или Human in the Loop, когда человек обязательно верифицирует. В кейсе той же Clarна результат у них такой, что искусственный язык предлагает хороший, правильный ответ, а человек его утверждает, тем самым отвечая за него. Вот эта задача, проблема ответственности, она существует, её тоже нужно учитывать.

Вот что по поводу харднесов. Всё движется туда. Оно, конечно, всё туда движется, но у нас сейчас фокус разговора про организацию и про процессы. А здесь сам Anthropic говорит, что чем проще инструменты, тем лучше. Какой бы харднес не был, главное, чтобы он был понятным всем участникам. А вот а харднесов бывает дофига. Полный GitHub, много статей про это и прочее. Нужно выбрать тот, который для вашего процесса удобнее всего. Кто запушил код, да? А ещё кто повил это. Ну вот Сергей ответил Роман. Если персональный буст, допустим, 20%, а на уровне to pro, наоборот, потери. Это возможно. Как это возможно? И где разрыв? Первый разрыв, который виден, то, что генерится гигантское количество кодов, в котором на 70% больше серьёзных багов, которые нужно ревьюить, и в результате вот эти багфиксы и прочее удлиняют всю эту историю. Так происходит чаще всего. Вот. То есть вроде как задачу решили, а на самом деле мы решили хреново. О, а вот так вот. То есть кто-нибудь не самый умный пишет кучу кода, там, не знаю, 300 3.000, не дай бог, строк в пулреквест, и нам теперь с этим разбираться, анализировать его и смотреть нарушение каких-то архитектурных правил и прочее. Поддерживать это всё становится всё сложнее и сложнее. Если раньше у нас код становился legacy там, не знаю, за сколько, за 3-5 лет, а то сейчас он может стать legacy за полгода, потому что вот это вот всё так потери контроля за кодом.

Дмитрий пишет: "Если пишешь руками код, чувствуешь, когда пишешь, то видишь его там как". Совершенно верно. Кто кто на низком уровне будет понимать код? А это очень важно.

Александр, есть комментарий? Не, ну я просто камеру. А Кася пишет: "А очень интересно посмотреть на бизнес как на проект по написанию кодов. Слушайте, зрелость компании на спиральную динамику похоже". А значит, ждём ссылку на программу обучения. А, Кася, напишите мне, пожалуйста, прямо в Telegram. У нас с вами есть контакт. Hearts of Skill сейчас находится на начальном третьем уровне этой матрицы. Я сознательно уже тащу туда весь проект и отлаживаю на нём всякие способы внедрения. Вот та же самая презентация — это, ну, в общем, первая попытка автоматизировать написание презентации, перейти из мира, которое надо было ручками, ручками, ручками, а, что-то, что можно делать с помощью ИИ. И ещё множество работы там предстоит. И вообще множество работы, но какое-то ускорение мы абсолютно чётко испытываем. Вот сотрудники постоянно приходится им изучать и пробовать новое, но вот это это происходит. Вот а полтора года, возможно, для большого бизнеса это будет гораздо больше. Ну, в общем, Кася, напишите, пожалуйста, в телеге или на худой конец Ленки Дыни. Вот. А, да, кстати, почему-то так получается, что из неайтишных компаний ко мне чаще всего вот обращаются именно маркетологи, SEO. Вот. А из айтишных SEO. Вот. А, о'кей.

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

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

Следующий вопрос. А, кстати, вы, пожалуйста, там поднимаете руки, а вот если это ваш вопрос и есть какие-то дополнения или вот где процессы внедрять и где во вред? А, тоже прикольный вопрос. Э, значит, э есть такое понятие зубчатый фронтир, когда искусственный интеллект может сильно ускорить какие-то вещи, а другие не может сильно ускорить. А вот и есть вот тут даётся фильтр из трёх вопросов: Процесс можно перепроектировать и описать? Можно ли создать единый источник контекста, то есть и данных, и процесса, и всего? И можно ли проверить результат дёшево? Если мы пытаемся делать юридические большие документы какого-нибудь M&A и компании, да, через искусственный интеллект, а то может быть оно всё и описуемо контрактом, и, может быть, можно сделать источник контекста, но проверка будет недешёвой, потому что там будут такие дома, скорее всего, ну, в общем, большие объёмы и сложно. А ну и вот, значит, то, что обсуждалось, там поддержки, документооборот, кодинг под чётким спеками. Ну вот мне как инженеру сложно, но тем не менее можно ходить по воде и писать по спекам, если они заморожены. А вот примерно так. Вред там, где процесс хаотичен или там, где слишком большая цена ошибки. А вот, ну, вот такой ответ. Может быть, есть ещё какие-то комментарии? Да, RAG Skills хорошо помогают со они вот когда контекст модели увеличился, то это очень очень хорошо.

Так, какие программы для HR? Рекрутинг, вообще говоря, сейчас, ну, всё это переживает не лучшие времена. Сотрудники говорят: "Где работодатели? Всё, всё, фигня какая-то". А работодатели говорят: "Где сотрудники? Никого не можем нанять". А вот, я пытаюсь дать ответ на этот вопрос с помощью интеллекта, разумеется, а вот, но, а-а, не так уж хорошо мне знакомы нача процессы в большом масштабе процесса рекрутинга. Вот. Кроме того, рекрутинг очень как-то, а, ему очень сложно, потому что на входе у рекрутёра, с одной стороны хреново написанное CV, с другой стороны хреново написанная постановка задачи. Рекрутёр обычно не понимает ни того, ни другого. И у нас получается чаще всего классическая ситуация там garbage in, garbage out. А и добавляй сюда искусственный интеллект, не добавляй, вряд ли получится чего-то толковое. Ну, будет больше гэч на выходе, если добавить и ускорить. Вот. Потому что я думаю, что там на, ну, все читали для NGIN, сколько там стонов с одной, со стороны рекрутёров свои, со стороны сотрудников свои поводу того, как как как сложно всем живётся, сложно найти работу, сложно найти сотрудников. Отчасти это результат внедрения вот этих всех ATS, когда бачи и бачаут вообще с обеих сторон и замачится очень очень очень сложно. Есть только нереальное количество ребят, которые не умеют красиво описать, а есть столько, значит, менеджеров, которые не могут нормально описать, кто им нужен, ну, и как тут вообще найтись. Поэтому про проблему HR я вижу в другом. Это вот всё можно делать, но пока не будут решены эти две проблемы, а как их решить, я не знаю, да, будет продолжаться хаос. Э, так. Так. О'кей.

Э, курс на почти полную автоматизацию разработки. Ну, давайте вот тут, э, не будем быть слишком оптимистичными. А-а, за двадцатый шестой год это точно не произойдёт. Хотя были кто там Anthropic, там кто-то оттуда обещал, что вообще там диск будет генериться и legacy будет работать красиво и так далее, и так далее. А пока что мы имеем в виду, имеем это самое, что вообще-то синьоры там в какой-то момент стали работать медленнее на 19%, а сами думали, что быстрее, что вайпкодинг у нас дал на 70% багов больше, а что и усилитель усиливает хаос, если он у нас есть. А вот поэтому полная автоматизация или почти полная автоматизация для меня выглядит как миф. Хотя туда мы куда-то идём. А вот при этом ещё же вокруг этого куча хайпа продаж, как внутренних, так и внешних, которые не подтверждены. А поэтому нужно аккуратно, системно, занудно подходить к процессам и это всё выполнять. А вот пройти матрицу хотя бы до второго уровня за год, ну, можно где-то как-то более-менее в большинстве, наверное, проектов. Выше сложно.

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

А так, а вот Алекс пишет: "Проблемы с рекрутингом были абсолютно. Так тихая ненависть HR-холдинга". Да. Вот как настраивать субагентов? А субагент — узкая ответственность. А, наверное, это самое главное. Субагенты. Хорошо, когда у нас, ну, много параллельных задач, тогда удобно. Вот. Но каждому из них отдай его контекст, продублируй его, может оказаться дороже. В общем, чем проще субагент, тем лучше. А вот, вообще говоря, у меня вот такая идея в голове о том, что, ну, наверное, не только у меня, а что чем меньше проще задачи, тем более дешёвым инструментам их можно отдавать. Этим более чёткий результат. Но для начала нужно эти задачи сформулировать, а это отдельная работа, которую никто не хочет делать. Вот customer support, граф или LM function calling и RAG. А, значит, сначала нужно делать просто, потом смотреть. Может быть, этого уже достаточно, а может быть, есть элементы для улучшения. Тогда искать, как сделать лучше. Примерно вот это описано в моём этом самом, вот на на чём будет работа, ну, как будет информация RAG, ну, как бы изменяться, кто её будет поддерживать и вообще какой у неё будет объём. Это это здесь будет очень важно. А если она будет хаотичной, то вся эта история абсолютно ломается. А вот, ну, надеюсь, я ответил. Так, может быть, есть ещё комментарии? Пока нет.

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

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

Вот как считать эффект пилота, если ускорение на есть, а end-to-end не это самое, а end-to-end delivery не ускоряется. А, ну, во-первых, ускорение, кроме ускорения, есть ещё метрика удешевления. Если один и тот же человек делал, ну, как бы одну задачу, теперь делают полторы. Ну, типа уже лучше, хотя delivery быстрее не стало, потому что, в общем, весь процесс не приспособлен к этому. А вот оптимизировать нужны узкие места, а не то, что удобнее оптимизировать. А поэтому эффект пилота, если его метрика в end delivery в TTM, он отрицательный. Мы потратили деньги, ничего не ускорили. Нам нужно сначала понять, какой процесс, опять я занудно повторяю, и после этого понять, какие там узкие места, и потом, может быть, их можно автоматизировать, а может быть, нельзя. А вот, причём эффект нужно считать, ну, минимум на полугодие, а не вот по демо одной из задач. Вот. Э-э, но а-а этот эффект же можно считать ещё и по другим метрикам, а которые могут оказаться, ну, как-то лучше, чем Delivery. Вот. А там шизна, например. О'кей.

А был ещё один вопрос, который только-только перед самой лекцией был задан. Я сейчас попробую его обнаружить. Так. Так вот, какие есть примеры успешного внедрения мультиагентных систем, пишущих код? Какие там показатели улучшения? Аа мультиагентные системы, которые пишут код. Это этот вопрос на вскидку я не скажу. Для меня это показывающий как фантастика. Это вот как, ну, второй вопрос, а про вот заменить команду на агентов. Ещё рановато для этого. А вот, но как раз эту тему, как именно это можно сделать, я буду обсуждать через 3 недели на лекции по AI SDLC. M.