Друзья, привет. Это подкаст Организованное программирование. Я у ведущий Кирилл Макевнин. Сегодня у меня в гостях Александр Поломодов. Саш, привет. >> Привет. [музыка] >> Мне кажется, Сашу многие знают, но если не знают, Саша работал техническим директором, энтузиаст e вdlc, ну и в ТБА имел некоторое к этому отношение. И так немножко обтекаемо, чтобы ты чуть больше сказал, ну, по этому поводу. >> Да. Да, спасибо, что позвал в гости. Очень приятно здесь быть и общаться на интересные темы. Если что, я до конца августа как раз всё ещё был в Т-банке. Последний год я отвечал за ей в разработке, за то, как мы на уровне компании идём в новое светлое будущее. В с сентября я, ну, без работы, но у меня план переехать в Лондон. Сейчас заканчиваю оформление бумажек. и, скорее всего, осенью туда перееду. >> Угу. Ну и, как вы поняли, раз уж мы сегодня собрались, мы сегодня хотим поговорить про Ий, но мне кажется, с той точки зрения, с которой я в меньшей степени говорил, по крайней мере, может быть, я сам и говорил, но у меня не было гостей, которыми мы об этом говорили, мы про SPT Dreven Development разговаривали в целом про производительность, но вот так как сверху действительно там что в компаниях происходит, что делают, по-моему, никого ещё так особо не было. И, соответственно, вот мы эту тему закроем. Но сразу хочу всех тоже предупредить. Это не значит, что у меня канал превращается полностью в AI. То есть, конечно, мы будем миксовать, но вот просто с Сашей мы очень давно собирались встретиться. И вот наконец-то у нас получилось это пообсуждать. И учитывая, что это как раз попало на его завершение этой работы, сегодня будет о чём, собственно, поговорить. Мы, наверное, первый, кто про это расскажет, да, вот как бы про этот весь путь, который был проделан целиком. Вот у меня есть фактически к тебе списочек вопросов. Я с него начну, а дальше посмотрим, как пойдёт. Скажи, знаешь, в таком немножко глобальном смысле, вот как меняется разработка ПО, когда основной объём кода начинает писать не человек, не с точки зрения конкретного человека, а вообще как индустриально. >> Это хороший вопрос. Вот. И надо сказать, что если мы говорим про крупные организации, они всегда были выстроены скорее как некоторые pйплайн конвейер поставки ценности. То есть, если мы говорим про Digersal компании, где, ну, основная ценность за счёт вот цифровых продуктов, и там была история с отдельным, ну, каким-то Discoverovery, что мы делаем, да? То есть за это отвечал бизнес, отвечали продукт-менеджеры, вот, и был, ну, там, аналитики разных сортов, и была часть с Delivery. То есть это история про то, когда мы уже решили, что мы делаем, как это, собственно, сделать и выкатить на продакшн и дальше обслуживать. И вот в крупных организациях у тебя за каждый из этих ээ двух частей отвечали не просто один тип людей, а они бились на поэтапы. Вот всё как по Тейлору и Фонду, да, когда они конвейер делали. То есть у тебя были отдельные шаги внутри вот этого там product development life cycle PDLC или Software Develop Life Cycle SD DLC. И эти, ну, за эти шаги отвечали люди с определёнными должностями зачастую, ну, вот в крупных компаниях. И для того, чтобы сделать какой-то, ну, какие-то дать результаты, то есть докатить до продакшена, у тебя индустрия дошла до там стрим онлайн команд и платформных команд, если вспомним Team Topologies. И в стриме онлайн-командах обычно было каждой твари попали, да, ну, условно говоря, вот людей разного типа профессии для того, чтобы этот стрим мог автономно выкатывать эти изменения. И если мы говорим про двадцать шестой год, то выяснилось, что, в принципе, тебе уже, ну, если код пишут агенты, то тебе уже не нужны, например, отдельно там фронтэнд разработчики, там бэкэндразработчики разного типа, какие-нибудь там коинженеры, которые, особенно тесты тебе какие-то автоматизированные пишут, аналитики, которые, ну, там зачастую есть и там транслируют какой-то этот высокоуровнее видео продукт-менеджеров и пишут спецификации. То есть, по идее, ты можешь вот этот стримлайн команды с условных 15-2 людей, да, которых часто вот в корпорациях накапливались в таких командах, пытаться уменьшить количество и вот эти роли, которые всё-таки нужны, вместить в меньшее количество человек. И это приводит к чему? К тому, что, ну, вот в компаниях должен произойти какой-то чейндж на уровне и состава команд, и на уровне того, как работа, в принципе, выстроена и передаётся по этим этапам. И это очень сложно в больших компаниях, потому что все люди, они уже привыкли отвечать за какую-то деятельность. Ну, если вот рассказать историю про двадцать пятый год, когда ещё агенты не не полетели, а были такие аля ассистенты, да, то есть которые с Humно помогали что-то сделать, то там всё это выглядело примерно как каждый человек с отдельной должностью, он в своём этапе научился во внутреннем цикле генерировать больше, например, продукты, шлёпать там product вместе с чат GPT. Аналитики этот recing definition скармливали тем же, ну, ассистентом и говорили: "А теперь требования напиши". Инженеры приходили такие: "Что-то требований теперь очень много, да, выдели мне самое важное, что мне нужно сделать, и ну давай вдшки это писать". И примерно так, ну, дальше по по это по по этапам. И это приводило к чему? К тому, что у тебя на каждом этапе вот вроде работы много делается, а по факту до конца доезжает не очень много. А теперь в двадцать шестом году стало понятно, что это, ну, не путь жидая, да? Путь жидая пытаться сделать так, чтобы передача работы была меньше. И, условно говоря, у тебя люди, которые, собственно, работу делают, они могли делать больше, ну, закрывать больше вот этих ролей самостоятельно при помощи агентов. Ну, собственно, мы здесь сейчас, и если мы говорим про стартапы, там плюс-минус это получается, потому что процессов особо нет, и люди и так делают всё, ну, всё, что нужно, чтобы продукт катился. А в корпорациях это проходит сложный путь. Почему? Потому что у тебя часто есть такие штуки, как профессии, ответственности за профессии. Ну вот эти профессии - это, на самом деле, некоторые люди с определёнными должностями, которые прямо называются по названию, например, этапа. И они видят свою цель в том, чтобы хорошо делать вот этот этап, как там у Адама Смита, помнишь, булавку? Ну, то есть разбирали на конвейер, там каждый за кусочек этого процесса отвечал. >> Х, смотри, такой вопрос. Вот ты сказал остались только те роли, которые нужны. Хм, какие же это роли? >> Это хороший вопрос. Ну, я сказал, остались скорее, ну, как бы, возможно, я сказал доли, но имел я в виду, мм, как сказать-то, что, ну, должностей стало меньше. Может, роли действительно они и нужны все, которые были. Просто вопрос в том, что теперь тебе не нужны отдельные люди под каждую из этих ролей с отдельной должностью. Если вот пытаться сократить, ну или как я в начале года, ну, нарисовал это, да, у нас внутри к чему мы идём, ээ, там был условно человек, который отвечает за Discoverovery, ну, продуктовый человек и человек, который отвечает там за Delivy, да? Ну, то есть, что э мы делаем по вот этой части из Discoverovery, что мы придумали сделать по какому-то интеtнту. Мы у нас появляются спеки, у нас появляется код, у нас появляется там pull request, код review, там тесты и так далее. И докадывается до прода. И, по-моему, у меня ещё на рисунке были ребята, которые operations занимаются. Ну, в смысле, у тебя же софт где-то крутится, у тебя есть всякие саппорт-инженеры для того, чтобы, ну, не все проблемы дотекали напрямую до команды разработки, а как-то, ну, типа обрабатывались и фильтровались. И на этой картинке как раз не было отдельных должностей под куинженеров, под аналитиков, там, под ещё каких-то людей. И я тебе не скажу, что это сильно поменялось. Например, у нас в Т-банке к такому видению мы пытались идти, ну, и до этого, до появления искусственного интеллекта вот разработки. То есть это был какой-то целевой формат команды, где ты проще можешь выстроить процесс работы и лучше деливерить результат без вот этих, ну, передач ответственности. Но с искусственным интеллектом у тебя гораздо проще получается это делать. Почему? Потому что если раньше у тебя человек сам должен кучей компетенций был обладать инженер, то теперь ему помогает, ну, условно, правильно настроенный агент, да, закрывать эти компетенции, где, может быть, он не такой и крутой. 21 сентября у нас стартует курс по системному дизайну. На нём вы спроектируете сервис и пройдёте путь от Монолита до мультирегиональной микросервисной архитектуры с кэшем, репликацией и шардированием. Курс рассчитан не только на прохождение собеседований по системному дизайну, но и на практическое владение навыками проектирования. Автор курса Виталий Лихачёв уже много лет проектирует высоконагруженные системы в [музыка] российском биктехе, а также проводит интервью по этой секции. Обучаться будем онлайн в течение 4 месяцев. Кроме [фыркает] теоретических уроков, вас ждут занятия с преподавателем, разбор кейсов и учебные проекты. Запись на курс по ссылке в описании. Смотри, тогда вопрос. То есть правильно я понимаю, что идеальная команда тогда выглядит так. Есть продак, допустим, который делает всю задачу, которую доставляет до Delivery в уже достаточно хорошем каком-то проработанном виде. Дальше, с той стороны есть только один человек, который с ним взаимодействует, чтобы, ну, там всё это разложить, как ему нужно, и учесть все условия там, которые нужно учесть, в том числе безопасность и так далее и так далее, какие-то регламенты, да, и этот же человек как бы доводит это до продакшна. Ну, понятно, что там ещё есть команда, которая сопровождает. И типа вот такая плоская структура, в которой, допустим, один продукт такой с усиленный агентом, а, работает просто напрямую с тоже самостоятельными единицами, которых может быть несколько, которые от и до всё делают. Это та картинка, которую ты сейчас описываешь? >> Ну, на самом деле, ты какой-то целевой вариант описываешь, к которому хотелось бы прийти. И, ну, за счёт чего он может работать? Во-первых, у тебя продуктовый человек может больше каких-то гипотез генерировать и отдавать уже не требования какие-то, ну, там, прототипы, которые он там с агентом собрал, да, визуальные, которые он там уже потыкал и сказал, что вот, похоже, так и должно быть. Во-вторых, у тебя продуктовый инженер, он не просто может и должен учитывать все вот требования, которые дальше были, ну, типа горизонтальной, типа безопасности, надёжности, там, не знаю, какого-то ландшафта компании. Классно бы, если бы у тебя на уровне компании эти правила были экстернализированы, чтобы потом не приходил кто-то погитам, да, и не проверял. Вот ты уже написал код, ты сделал полреквест, и дальше тебе говорят: "Подожди-ка, подожди, друг, сейчас мы устроим тебе secкритирев твоего изменения и уходят там, не знаю, на 2 недели там, не знаю, что делать". Ты бы хотел, [фыркает] чтобы у тебя как минимум внутри пайплайна после, ну, вот появления полуреквест это проверялось. А хорошо бы, чтобы внутри внутреннего цикла разработки вот эти полисы, которые ты вытащил из этих людей, да, которые там за какие-то горизонтальные штуки отвечают, кто там безопасность, надёжность, юристы, там контент, бренд, ещё кто-то там, вот в крупной корпорации это всё там стандартизировано, чтобы это всё в виде полисе было доступно и условно на пример на как в Aйте в плейбуке от Антропика через какие-то скилы применялось прямо к проектированию требований. То есть из интента, который условный продак как-то собрал к вот оформлению от интента требований, которые уже можно пустить в разработку. И тогда у тебя получается так, что у тебя внутри в во внутреннем цикле разработки фичи эти требования уже учтены. Дальше у тебя есть какие-то автоматические гейты, которые уже к пулреквесту, к ченджу, который должен на прот уехать, применяются. И тогда наступает счастье, ты очень быстро можешь и гипотезы формулировать, и там их там реализовывать. И скорее всего у тебя тогда нету таких ручных преград, которые там занимают прям, ну, значительное время и тормозят выкатки. Но это какой-то, знаешь, ээ волшебный мир. Ээ до него дойти, ну, супер сложно. Ну, прям супер сложно. >> И как будто бы мы ещё не знаем, насколько реально, правильно, ведь? Потому что будет ли действительно всё соблюдаться, что было в требованиях написано? Сможем ли мы доверять настолько машине и агентам? Или мы говорим про то, что в этом идеальном мире, вот когда говоришь кейты, просто в прошлый раз, когда мы с Ваней делали подкаст, там много про это писали, что, ребята, вы на каком-то космическом языке разговариваете, типа мы ещё не очень дошли до этой точки. Вот когда ты говоришь про вот эти гейты и проверки и контроль вот этого всего добра, ты имеешь в виду, что он такой же иишный или м встраивается какая-то, не знаю, статический анализ, какие-то детерминированные инструменты, генерации, которые начинают гарантированно проверять это и это возможно? Смотри, типа, это очень хороший вопрос, и он как разделяет историю между, ну, как бы, знаешь, вот, скажем, таким вайп-кодингом, да, и инженерингом или AI naтив инжинирингом. И мне кажется, когда вот, не знаю, ты или я, понимая свою там ограничительность во времени, будем стартовать новый проект, мы постараемся скомбинировать то, что, условно говоря, применяется как полис код через вот эти какие-нибудь рекомендации в виде скилов, да, там агентом и какой-то, ну, набор детерминированных проверок, которые там каждое изменение должно пройти. И, ну вот я на свои проекты примерно так смотрел, встречаешь какую-то проблему, у тебя ещё детерминированная какая-то проверка появляется, потом ещё одна, ещё одна, ещё одна. Я со своими коллегами, когда ещё из ТТ не уходил, обсуждал, они такие: "Вот ты навайп-кодил, ну, какой-то свой проект и открываю, а у меня там, не знаю, ну, типа какое-то бесконечное количество скриптов". Я просто такой говорю: "О'кей, давайте посмотрим на детерми проверки, которые есть в моём проекте". И начинаю рассказывать: "Это вот для этого, это для этого, это для этого". У меня там, ну, как бы там два экрана, короче [смех] говоря, разных проверок. И история примерно такая, что, э, если ты стартуешь проект с с нуля и ты понимаешь вот модель, ну, процесс, который ты хочешь выстоять, ты понимаешь, что под это должна быть готова архитектура, да? То есть ты готов это, ну, типа править, ты понимаешь, какую метрику ты оптимизируешь, да? То есть я, например, у меня был пост на тему того, на как архитектура должна выглядеть, исходя из, например, то, что я готов объяснять, что я хочу, например, агенту, но я не готов объяснять по много раз, как я хочу это видеть. Например, я не готов тратить время на там operations и на починку. Мне нужен селф-хилинг. Ну, типа архитектура, где, ну, как бы у меня на этапе изменения я должен увидеть, что что-то падает, да, а не на этапе эксплуатации что-то закончится. Или я, ну, типа, как я точно руками могу проверить инкремент, но я руками не могу проверять регресс, поэтому регресс должен проверяться максимально автоматически. Дальше, э, например, я знаю, какой у меня профиль изменений вот, ну, типа стандартный, а какой нестандартный. Я оптимизирую вот эту архитектуру под то, чтобы стандартные изменения, которые, например, появление контента, там, подкастов или каких-то, но, ну, допстатей или там, не знаю, лаб или ещё чего-то, он должен быть, ну, плюс-минус инкрементально проверяемый вот здесь вот. А если я захочу сделать рефакторинг, ну, какой-то, да, и всё поменять, то я готов под это дело, ну, типа потратить сильно больше времени, проектирую и так далее. Это не стандартный кейс, я не оптимизирую под него, да. Ну и вот когда ты на себе на такие вопросы отвечаешь, ты очень чётко понимаешь, как должна выглядеть вся твоя система, как выглядит твой процесс, как выглядит архитектура, как выглядит, ну, например, инфраструктура, ну, где ты должен это разворачивать. И, ну, фишка в чём? В том, что если ты классный технический там руководитель и там архитектор, и ты в принципе на так мыслишь о производственной системе, ты можешь под это всё задизайнить. Проблема текущих Браунфи проектов, что они оптимизированы были совсем по-другое. И сейчас, когда ты говоришь про то, что а вот я добавлю EA в процессы и всё полетит, это тянет за собой очень большой хво хвост изменений, понимаешь? Да. Тебе нужно, ну, как бы подругую метрику оптимизировать свою систему рабочую и отхититектону систему. >> Из этого вытекает сразу следующий вопрос. Допустим, мы вот на на всю компанию это раскатываем, да, и все это делаем. Мы же с очень высокой вероятностью не рассчитываем на то, что у нас все вокруг супер такие крутые, что сами выстраивают и мы им доверяем. То есть я правильно понимаю, что общее восприятие этой ситуации, что нам нужна отдельная команда, которая на этом специализируется, и она же учит, проверяет, внедряет и создаёт вот эти вот все необходимые проверки, гейты, которые нужны для функционирования этой системы, чтобы она развивалась вся. Это хороший вопрос, но сильно зависит от того, как у вас текущая компания выстроена, да, и как инженеринг в ней выстроен. То есть, если мы говорим про крупные компании типа того же там, ну, разноцветных банков, вот, или других технологических компаний, там часто выглядит примерно следующим образом. У тебя есть какая-то платформенная инженерия, которая поставляет, ну, вот, ээ, общеплатформенные там инструменты. И часто там есть вот какой-то, ну, блок, который отвечает за внедрение AI на всех. То есть за общий какой-нибудь тулинг, за MCP Hub, Skill Hub, всякие model Gway, там ещё что-то. Вот, скорее всего, эти люди очень плотно общаются с безопасностью, чтобы разрешить, ну, эти инструменты. Дальше есть бизнес-вертикали, ну, какие-то, которые сами, ну, сами по себе, например, инвестиции, там, банк для юдлис, банк для физлиц, >> мобильная связь вполне себе отдельно вертикальна, >> да, мобильная связь. Ну, это может быть и там другие блоки в зависимости от, ну, вашего бизнеса. И получается примерно такой дуализм, что на уровне там платформенном ты очень хочешь, чтобы у тебя вот эти платформенные инструменты, они были agent рейде, да? То есть, чтобы ты мог наторовить агента. И, например, кто-то из продуктовой компании мог, например, агента спросить: "А что происходило с моими сервисами?" Да, какие были проблемы? Вот. И, ну, получить какой-то отчёт и что там должно сразу включаться. Нужно понять, что это за человек, в какой он команде, какие сервисы, ну, типа, за какие сервисы он отвечает, ээ, где можно узнать, какие логи, метрики, трейсы, а где посмотреть, что эти, ну, типа системы обещали, да? То есть где заведены сла? Ну и, ну, в общем, сравнить это всё между собой. Ты явно хочешь, чтобы, ну, вот эти бизнесы отникали, всё это сами не делали. То есть ты хочешь эти кубики предоставить базово, самостоятельно от платформы, и у тебя есть работа с платформенными командами, потому что, э, ну, так жизнь устроена, что раньше платформенны эти команды обычно оптимизировали свои поверхности под usер интерфейс, ну, графический, а не парагентский. И это совсем там другой профиль. И когда они, например, говорят: "Мы свои круды выставили через MCP и там условно, ээ, ручки", выясняется, что, э, они настолько вербозные или настолько файн, ну, в смысле кусочный, что агент там должен обдолбиться, чтобы собрать какую-то информацию, да? Ну, то есть там какое-то бесконечное количество вызовов сделать, чтобы сложить это. Вот. И дальше мы как раз доходим до твоего ответа, ну, вопроса, на самом деле, а что должны сделать бизнес-линии, чтобы поменять свои процессы? Потому что часто бизнес-то хочет поменять не просто, чтобы платформенные команды лучше как-то предоставляли свои услуги, как бы, о'кей, это фай, но он хочет, чтобы бизнес вечи катились быстрее. И у этих людей часто ну двойная нагрузка. Одна нагрузка, они такие: "О'кей, а как выглядят наши, ну, процессы разработки, да? как, например, состав команд у нас выглядел. И в большой компании часто бывает, ну, совсем по-разному. То есть кто-то уже дошёл до состояния, что у меня продакты и вот, ну, аля продуктовые инженеры, а у кого-то там у меня продакт, потом бизнес-аналитик, потом системный аналитик, потом ещё какой-нибудь аналитик, потом инженер 1 2 3 и все передают. Потом такой >> тестировщики там в конце, да, >> автотестировщик, потом мануальный тестировщик, потом ещё какой-нибудь человек и как бы понимаешь, да? В зависимости от того, где ты, ты, ну, тебе сильно по-разному нужно, ну, продумывать, а как тебе вот в эту инете в сторону идти. Это первая история. Вторая история, часто тебе ещё нужно вот с этими ребятами платформенными подружиться, да? Ты такой говоришь: "О'кей, а что мне даёт платформа? То есть какие общие инструменты я могу использовать?" И там тоже бывает не, ну, не слава богу, потому что, условно говоря, в большой крупной компании, если ты супербыстрый и такой движниковый, ты часто можешь получить возможность сделать пилот. и, например, получить доступы к топовым инструментам сото, если ты пообещаешь, что вот в результате пилота ты покажешь, как это используется и так далее. А если ты не такой движниковый, например, ты сидишь на месте ровно, то, ну, тебе достанется, ну, типа текущие возможности платформы, которые часто, ну, там, скажем, не на сотоуровне, понимаешь? И в итоге у тебя получается такое, знаешь, как будущее уже наступило, только оно неравномерно распределено. В итоге кто-то ээ в полный рост использует там по максимуму эти инструменты и получил индульгенции на то, чтобы так использовать. А другие какие-то люди, они такие: "А за нас платформа должна всё нам докатить, и мы тогда воспользуемся". И в итоге у тебя, ну, в среднем по больнице может не наблюдаться какого-то суперэффекта, но есть выколотые точки, где люди такие: "Ага, например, есть примеры уровня". Люди такие говорят: "Мы закомитились запустить новый продукт. Вот нам не дали, ну, стандартного количества ресурсов". Ну, сказали: "Вот вам, ну, условно говоря, подписка на клод. Вот поехали". И у тебя и продак там заинтересован, и инженеры заинтересованы. И дальше продак говорит: "Ээ, о'кей, как нам сделать круче?" Лид такой говорит: "А давай-ка друг дорогой с тобой вместо Джира, Вики и вот этого всего, где раньше велись, да, ну, типа история про разработку, давай мы попробуем переехать на вот аля самопальный вот playбу A Native, где ты будешь интенты писать прямо вот в нашем новом репозитории под продукт. Спики мы будем вместе там с тобой делать, дальше скармливать это агенту и вот по кругу через СДд это делать, да, показывать демки каждые там неделю. И бацы, они запиливают тебе продукт быстрее там в два раза, командой в два раза меньше. И, ну, им говорят отлично, но соседняя команда, в которой, ну, типа она не с Гринфилдо, не с Гринфилда стартовала, понимаешь, да? И не было такой, ну, типа адженс, ну, срочности. Вот она сидит и такая: "А вот мы используем стандартные инструменты, у нас вроде кода или там, ну, стало больше, я изгенерированного мёшли квесты выросли". Ну, вот с точки зрения, например, пропускной способности в команде ничего, в принципе, не поменялось. И выясняется, что у ребят есть какой-то VIP на входящей задаче. Вот этот VIP зафиксирован там кровью с разными, ну там, стейкхолдерами, и они на в освободившееся время, не знаю, какой-нибудь технический бэклок отдают. И, ну, понимаешь, да, вроде и польза есть, но с другой стороны бизнес такой говорит: "Внедрили вы искусственный интеллект?" Не внедрили. Мне вообще не не видно, условно. >> Угу. Знаешь, я попробую сейчас это как бы такую общую картинку собрать. То есть мы говорим о том, что платформенной команде добавились новые функции в плане того, чтобы предоставлять там какие-то ручки для того, чтобы получать знания, иметь доступ к сервисам, к вычислительным ресурсам и так далее, и так далее. Но при этом в каждой конкретной команде свои есть гейты, которые нужно выстраивать в workкфлоу, которые связаны и с процессами, с их требованиями к безопасности, ко всему, правильно? И получается как бы такой микс, с одной стороны платформа, с другой стороны мы решаем это на уровне бизнес-вертикали, что конкретно надо выстроить. При этом, кстати, скорее всего, от платформы будут нужны ещё и тоже какие-то решения. Аля там механика запуска агентов, да, ещё что-то такое, >> да. Ну вот смотри, если мы говорим про платформу, там стандартная история - это model gateway. Ну то есть ты через стандартную точку ходишь, ну типа в разные модели, внутренние, внешние. Вот. И там управляешь квотами, entityти, ну тим всем остальным. Скорее всего, тебе нужен там MCPub. Ну, в смысле, какие у тебя апишки доступны и, ну, как их найти для агента, да? Ну, то есть возможности. Скорее всего, тебе нужен для skillхаub, ну, где у тебя лежат правильные проверенные скилы и какая-то шаринг. У тебя есть история про какой-нибудь сндбоксинг и дефбоксинг, как запускать вот эти агентные следы, чтобы агенты не только на компе, ну, пользователя работали. Но вот если мы прямо говорим про изменение процессов продуктовой разработки, по крайней мере внутри, они часто прибиты к техническому директору вот этого бизне этой бизнес-вертикали. И у него условно есть свой какой-нибудь ээ человек, который отвечает за внедрение в эти процессы. И, ну, то есть ты с ним общаешься на уровне ребята, как у вас там дела, как вы общую концепцию, ну, типа к ней двигаетесь, что у вас по метрикам? Э ну про это тоже можем, про метрики поговорить. Какие у вас есть проблемы? Ну, вот с общим инструментарием, может, вам чего-то не хватает. И зачастую там проблемы могут быть уровня. О'кей, люди такие говорят, мы готовы нам, например, затаскивать не только код, да, но, например, и наше Discovery. Чтобы затащить Discoverovery, нужно, например, дать доступ к данным, да, чтобы мы гипотезы какие-нибудь генерировали, как можно бизнес улучшать и так далее. А доступ к данным, например, он даётся через централизованное место. И, например, нам не разрешают, ну, типа, эти источники подключать, потому что нам слишком страшно. И дальше ты общаешься вот по кругу с представителями безопасности относительно того, что можно и нельзя. И действительно ли это должно быть унифицировано на всю компанию или это зависит от типа бизнес-вертикали и те, ну, важности, критичности тех данных, которые которые эта бизнес-вертикаль владеет? У меня, кстати, сложилось впечатление, что при таком раскладе у тебя для того, чтобы это реально эффективно двигалось вперёд в конкретном вертикале, у тебя должен быть хотя бы один человек, задаче которого не фичами заниматься, а именно улучшать, ну, давай так харнес назовём, да, всё, что касается вот этих вот. Нет, даже, наверное, меньше про харнес, больше про workflow, то есть менять именно сами процессы, гейты ставить и так далее. Потому что если у тебя есть команда, которая просто пилит фичи, для неё это побочная деятельность. Даже при том, что она им нужна, как-то будет тяжко, да, вытащить чувака и сказать: "Ладно, ты остановись, давай-ка поинтегрируй, тут всё поменяй". Потому что, мне кажется, сейчас пока это так происходит, типа просто вот давай ты, Вася, у нас самый сообразительный или нет уже? >> Ну, видишь, смотри, история какая. Если мы говорим про вот прямо крупные компании, у тебя эти бизнес-вертикали могут ээ содержат быть там условно 1.000 инженеров, да, какие-нибудь аля элише, или чуть меньше. Ну дади примера приведу инвестиции или бан для там юд лиц. И что получается, что у тебя внутри уже есть централизованные функции аля собственные такие платформенные команды, которые отвечают, например, за надёжность, за какие-то, ну, типа эффекты с производительностью связанные, вот за ну иногда у них есть реально своя какая-то надплатформа, ну, поверхстандартных, которая нужна только им. У, >> и добавить вот в эту структуру ещё человека, который отвечает за изменение workflow, именно процессов разработки, и, ну, как бы помогает вот этим продуктовым командам там перестраиваться, это небольшая проблема. Надо найти таких, ну, крутых ребят, которые это могут. Но вот в Т с этим, ну, именно с ребя с ребятами крутыми, которых можно вот на такие функции поставить, было всё о'кей. Во многих вот таких вертикалях, там сервис-линиях, там каких-нибудь платформенных штуках действительно были прямо ребята заряженные, которые хотели менять и, ну, и делали это успешно. Проблема была, как это генерализировать на уровне всей весь всей компании. Почему? Потому что вот помнишь, я тебе рассказывал, что, например, бизнес-линия очень, как сказать, большой ПАО, да, например, приносит деньги. Там есть очень заряженные ребята. И они согласуют себе условия, которые на всю компанию, например, не раскатить. Ну, по там по тем или иным причинам. Дальше они делают себе какие-то улучшения, и они в какой-то момент могут обгонять обгонять твою централизованную функцию. Ты пытаешься их наработки раскатить на всех и стыкаешься с вот этими, ну, централизованными требованиями, которые, ну, как бы для пилота смягчены, а для масштабирования нет. И ты можешь начинать ходить по кругу, понимаешь? Да, тебе такие говорят: "Ну вот это мы всё на всех не раскатим, потому что, например, потому что небезопасно". И дальше ты говоришь: "А что должно быть, чтобы было безопасно?" И те выкатывают, например, набот требований, которые их, ну, там до сих пор, например, не реализованы в какой-нибудь AVS летжесте там для MCP или ещё каких-нибудь. Ты читаешь такой, говоришь: "Это Q7 какого? 2030 года. Тебе говорят: "Ну, должно же всё быть безопасно". Ты говоришь: "А, о'кей. А я думал, работать должно". И ты попадаешь в ловушку. Уловка 22 или как она называется. >> Да. Да. Мы, кстати, сами с этим сталкиваемся, когда, например, у тебя вотпишки, УАВ везде не везде нормально работает. И, например, в Яндекс Clуде там есть такая смешная штука, что, казалось бы, их, собственно, Яндекре того, чтобы тебе, да, то есть ты не можешь сделать один MCP, дать всем остальным, все соответственно по своим аккаунтам логинятся и работают. Он OА token как бы да, при ставится прямо на саму MCPшку. То есть, грубо говоря, тебе приходится под каждого пользователя создавать свою собственную MCP. Ну и вот там вот таких вот приколов пока очень много. Ты смотришь, думаешь: "Блин, ну вроде бы, вроде бы вот оно всё есть и только редкие сервисы". Но если мы говорим про то, как это происходит в мире, не только внутри конкретной компании, мы вот потому что же используем в основном, ну, готовые решения, то есть мы там не пилим что-то, у нас есть где это взять. Даже на этом уровне, казалось бы, да, только единицы сделали так, что там вот по кнопке всё интегрируется, всё работает. В основном ты смотришь и понимаешь, что, блин, даже на мою небольшую компанию какой-то геморрой всё это раскатывать и надо ждать, пока они все созреют. Даже, по-моему, стандарт MCP сейчас довольно сильно меняется и там очень сильно упрощают, да, а из-за того, что много всякого геморроя получилось, связанного с состоянием. Ну, это так, короче, мы пока ещё далеки от завершения этого процесса, да, и интеграции, всего остального. Хотите расти как разработчик не в одиночку, а вместе с сильным сообществом? Вступайте и в Hexet клуб. Это закрытое пространство для тех, кто уже в профессии хочет развиваться дальше. Здесь помогают определить уровень, построить персональный план развития и дают обратную связь менторы из индустрии, в том числе из зарубежных компаний. Клубе живые разговоры о технологиях, собеседованиях, работе в компаниях, карьерном росте и нетворке. Есть отдельные топики с историями участников, отзывами о работодателях, отчётами менторов и планами развития. Люди приходят в клуб, чтобы расти, и помогают другим делать то же самое. Слушай, я хотел немножко сейчас в бок пойти, потому что есть одна вещь, которую ты сказал, и она довольно интересная. Она связанная с ролями тоже, поскольку мы с тобой давно в разработке, да, мы как бы проходили разные этапы, и мы помним, когда отделялись фронтендеры от бэкндеров и как все говорили, как это правильно, как это надо, как это большая отдельная специализация и вообще смотрите, это разделение труда. Ну понятно, что там за уши всё это притянуто, но всегда про это говорилось. И вот вся индустрия, то есть, а я постоянно в этих спорах участвовал, потому что я что-то говорю, мне говорят: "Нет, Кирилл". Я говорю: "У нас все фулстейки". Они такие: "Нет, это неправильно". И так далее. И мы сейчас попадаем в ситуацию, когда все такие: "Не-не, не, зачем нам это надо? Нам нужны фулстеки, все фулстеки". Я такой: "Так, стоп".

[смех] То есть мы все вместе дружно отказываемся от всего, что мы говорили. Можешь мне пояснить? Потому что я уверен, этот вопрос есть у всех. Типа, ребята, вы там летаете в облаках, но типа если я не фронтендер, а бэкэндер, и мне тут надо фронт делать, получится лажа. Что ты про это скажешь? >> Смотри, это супер вопрос. Вот. И для тех, кто, ну, шарит в теории менеджмента, этот вопрос он, мм, пере, ну, типа, переформулируется скорее, знаешь, как, э, ну, или не шарит, а знает историю. Он переформулируется м в формат, а под что мы оптимизируем нашу производственную систему. И вот выясняется, что вот этот пайплайн, ну или конвейер, условно, который тебе позволял обеспечить определённый фрупут, если у тебя каждая стадия, ну, сложно там даётся и требует разных скилов, это, ну, вообще-то, это благо, да? То есть ты удешевляешь производство, ты повышаешь фрупут, не увеличивая количество людей за счёт их специализации. Ты можешь вспомнить, там есть стандартная экономическая история про то, что даже если Вася делает всё лучше, чем Петя, можно за счёт относительного преимущества Васи поставить его только на те задачи, которые он делает прямо, ну, сильно лучше, чем Петя. А Петя всё-таки найти работу в твоей команде. Ну, это вот про то, как торговля, например, даже вот с между эффективными, суперэффективными странами, которые всё производят лучше, и другой, которой не всё, ну, как бы всё хуже производит, ты всё равно можешь найти способ, э, обмен устроить так, чтобы повысить эффективность вот этой совместной системы. Тут примерно такая же история. То есть когда у тебя работа, инженерная работа приходила к тому, что у тебя есть сложные домены, ну, которые ты сам на самом деле усложнил, да, в погоне за какими-то характеристиками. То есть, э, я просто помню, я сам бэкэнда начинал, и у меня были какие-то фронт-тенд задачи. Потом фронт-энд усложнялся, усложнялся, усложнялся, фактически стал как ээнд. ну, со своим состоянием, там, со своим, >> ну, сложностями того, как это динамически работает. По факту ты в браузере начал писать аля десктопные приложения. Вот. И, ну, стало ясно, что, ну, то есть это отдельный какой-то домен. Потом так получилось, что я за, например, за фнд и то, как мы это делали, в в Тотвечал достаточно долго, ну, из-за часть бэкэнда, потом ещё мобилку потрогал и примерно та же самая история они прошли. Вот. И я даже шутил, что это как день сурка, знаешь, когда ты проходишь вот этот этап, ну, когда сложность запихивается на каком-то этапе вот в эту, ну, профессию, потому что, ну, так надо. И в итоге что получается? То есть, э, у тебя получился конвейер, но у тебя есть проблема с передачей вот работы между этапами, да? То есть я вот ревюил, например, для Arc Days доклад, не буду говорить от кого, где постановка звучала примерно так: ради одной фичи нужно координировать четыре команды, как мы делаем это архитектурно. Я читаю описание и понимаю, что это, ну, типа какая-то, знаешь, дисфункция. То есть это, ну, типа не про архитектуру рассказ, это про, ну, дисфункцию того, как ты выставил работу. И проблема была в чём? В том, что ты не мог её часто выставить по-другому. Почему? Потому что, ну, в голову одного человека это не помещалось. А если это помещалось, то человек был золотым. Ещё и басфактор единица. И ты такой говоришь: "О'кей, я за счёт процессов, за счёт разделения этапов решу эту проблему, и мне проще будет находить инженеров, которые внутри своего этапа будут давать качественный результат, ну, повторяемый и предсказуемым, да, как бы [фыркает] образом. Вот и всё бы так и длилось". Ну, то есть оно так и и развивалось. Но когда появились ээ средства, они что предложили? На начальном этапе? Они предложили автокомплит, потом и надета, ну, короче, редактирование, когда ты блок выделяешь, говоришь, что поменять. В конце концов, мы дошли до агентов. А у агентов история примерно такая, что они весь интернет видели, весь там код публичный видели и не только его. кучу синтетических данных уже видели повторяемых, ну, в реинфосмен ленинге, да, пытались инженерные задачки решать. В принципе, они могут тебе и фронт написать, и бк написать, и всё остальное. И ты такой говоришь: "Так, подождите, ребята, получается, у меня есть такой, ну, некоторый, знаешь, как Смитвесон, ну, типа или Кольт, ну, великий уравнитель, да, у меня есть такой инструмент, который, [смех] в принципе, неважно какая, какой тип задачи, он, в принципе, с ней и справляется. вопрос, куда направить этот, ну, типа этот кольт, да, и как проверить, что, ну, задача решена. И ты такой говоришь: "Так получается, мне не так, ну, типа важна специализация, если в принципе, ну, правильные инженерные навыки есть в домене, там человек разбирается, в принципе, может посмотреть и фронт, и бк погружения в детали. И это, ну, фактически ты обратно, да, возвращаешься в эру, когда у тебя инженеры объединены. Но я тебе могу сказать, что мы к этому шли, например, в Т. Ну и там индустрия, не только нам российская, шла через такое понятие, как аля staff инженер, там principle и так далее. Ну типа суперкрутой чувак, который, в принципе, задачу должен решить, а не говорить: "Я java разработчик или я гораздоработчик или я JS-разработчик". Он как бы приходил и решал задачу. Вот, ну как бы вот была проблема, например, он разбирался с ней. или была какая-то идея сложной штуки, он разбирался с тем, как эту сложную штуку сделать и, ну, типа, дальше условно сделать, чтобы эта команда заделировала вместе с ним. Ну, то есть он хнзон был. Вот. И сейчас мы просто пришли к тому, что такие требования, они начинают сильно ниже начинаться. То есть я такой: "Я хочу продуктового инженера, который чуть ли не с джуна, да, начнёт вот вот так работать. с агентом, да, но он как бы будет больше ближе к вот той истории продуктовой, что мы хотим в продукте сделать. Он может, э, в принципе с агентом, ну, написать какой-то ээ план ээ того, что будет сделано. И вот, знаешь, была такая тема с кодревь. Часто я вот помню Филдельга, он часто рассказывал, что кодрев вредно, нужно делать дизайн-ревго, что мы хотим, ну, сделать раньше. И вот этот дизайнрев, он часто в, ну, во многих инженерных крутых компаниях был, но только для крупных изменений, да? Ну, типа вот, например, ты придумываешь большое изменение такое аля one way do decision, да, как там Джеф Безс говорил, ну, короче говоря, дорогое изменение, и ты хочешь, чтобы его афроontт проревьювили, ну, согласились, что, да, вот компромиссы правильно выставлены, вот это решение, ну, из там опции выбрано правильно в соответствии с нашими интересами, ты фиксируешь это внутри какого-то лого. решений типа architecture decision rec log и дальше реализуешь с агентами это просто стало гораздо проще приносить на уровень вот позадачно понимаешь да есть у тебя есть вот какой-то интент от ээ там твоего продуктового чувака есть пеки которые вы там написали и есть вот план который там предложил агент его ревьюешь дальше агент пишет код и дальше ну то есть ты проверяешь готова не готово и мне кажется что для людей которые хотели решать именно какие-то задачи, да, ну, то есть они хотели увидеть результат, они в самом процессе, ну, поучаствовать. Это, ну, благо. Почему? Потому что они могут теперь больше. Но часть инженеров, она была заточена на то, что им нравился процесс, ну, типа написание кода, состояние потока. А в новом процессе вот сейчас модели натренированы так, что они асинхронно работают. Ты им что-то сказал, и они пошли делать. И ты как менеджер должен переключиться на что-то другое и заняться. А есть на самом деле, ну, истории, когда, ну, вот мы с там с моими гостями как-то разбирали про интерактивные бенчи, которые измеряют как-то, ну, как агенты в интерактивном режиме с частичной раскрытием информации, уточнением требований работают. Эти были бы менчи от запрещённой России мета и от Scale AI, которая часть запрещённой России метаорганизации. Ну, почти. >> Вот. И это очень был очень интересный, ну, разбор вайтпейперов про эти бенчи, потому что, э, ну, там было показано, что это драматически снижает качество вот решения задач. Как раз такая работа, ну, в интерактивном режиме с агентом, когда ты смотришь на трикто его решение и подруливаешь, да? Ну, то есть ему такие дополнительные указания даёшь, докидываешь требования. И это о чём говорит? о том, что на самом деле, ну, модели хотели бы, чтобы ты вот как раз аля поспеion Development сейчас, ну, они, по крайней мере, лучше работают, когда ты Поспек Divelopment разложил всё, что ты хотел, отревивил, ну, вот что план, ну, в смысле, что вот эти спеки соответствуют тому, что нужно сделать, и дальше, ну, агент может уйти и сделать это и там проверить критерии выполнения приёмки в конце. Я, кстати, подтвердить хочу при том, что вот у меня компания небольшая, и как раз все эти процедуры, которые были в биктехах или в энтерпрайзе, для меня, ну, естественно, мне не нужны. Поэтому у нас всё было гораздо проще. Мы там созвонились, решили, выкатили, да. Но когда мы сами начали вот там типа 4 месяца, наверное, назад использовать, ну, пробовать все эти попытки, то то, что я раньше считал довольно энтерпрайзной штукой, которая нам просто не нужна, она настолько стала простой, естественной, самое главное, автоматизированной с той стороны, что я такой: "А зачем от этого отказываться?" То есть раньше это было бы типа нагромождение сложных структур под вот эту историю. А теперь я там рассуждаю в терминах адрок, у нас там спеки и так далее. У нас там полтора коллеги, которые пишут код. И для меня, например, уже сейчас очевидно, что и более того, новые проекты так стартуют, даже когда я один, потому что это очень реально крутой работающий подход. Причём там, кстати, тоже есть разные уровни, потому что вот OpenS, про который сейчас тоже много говорят, и Ваня у меня разговаривал, я вижу, что, например, там для каких-нибудь open source он может быть избыточен, потому что он всё-таки на историю, на более большие продукты, но есть, например, там другие более простые штуки, поэтому как будто бы получается, что здесь тоже есть люфт, но в любом случае общая тенденция к тому, что действительно формируется заранее спецификация и она используется и как будто бы это будет вот просто на всех уровнях. То есть, если ты даже просто там, не знаю, делаешь какой-то один несложный проект и ты это не используешь, есть ощущение, что ты будешь проигрывать. Ну, тот, кто будет это делать. >> А знаешь, в чём там фишка? В том, что на самом деле, ну, типа агентам, ну, и вообще моделям им вот это эксплицитное знание очень сильно помогает действовать. То есть, если у тебя это оно зафиксировано, у тебя, ну, описано, что ты хотел, описаны критерии приёмки, они, ну, этим всем пользуются. И по факту ты получаешь некоторый такой, ну, может быть, не целиком замкнутый цикл, но в рамках вот этой, ну, типа фичи, которую ты делаешь, агент может сделать что-то и оценить, сделал он или не сделал, и дальше отсчитаться. Если у тебя этого, ну, то есть ты это знание не выгрузил, а просто сказал: "Сделай по красоте", то дальше получается, ну, ты сам должен это проверять. И м я тоже много проектов делаю один, но я, понимаешь, байс, да? То есть я там многие из этих процессов внутри Т сетапил, когда отвечал за архитектуру. Историю с RFC, да, ну, то есть, что мы их пишем, ревю с architкecture decision recка, с логами, короче, с этим, как его, с теми критериями, по которым опциями доступными. Ну, в смысле, что что должно быть в этих документах, чтобы они были полезны. И в итоге я такой: "Так я и не хочу от этого отказываться. Ну, я агенту говорю: "Мы делаем это". Я их читаю. И ощущение, что я вот себя поймал на мысли месяцев шесть назад делал, ну, условно, там, прототип продукта для там того, чтобы внутри его развернуть. И так получилось, что мне нужно было из Local First приложения сделать мультитентную систему. Я попросил, ну, агента, ну, говорю, мы делаем вот это, должны поменять вот это, потому что, ну, я хочу этот продукт попытаться внутри развернуть вот для таких-то сценариев. И дальше мы с агентом проходим по визаду, я отвечаю на вопросы, у меня получается, ну, типа адр, я его читаю и понимаю, что раньше бы я неделю писал др такого качества, да, не с не с визодом. Потом бы я недели две бы рассказывал, почему это надо всем вокруг, и объяснял на пальцах. как это работает и почему система должна быть так устоена. Потом бы я ещё, не знаю, квартал ждал, пока это сделается, и потом, может быть, это принесло бы результаты. А тут я к концу этого дня получил, ну да, не идеально работающую, но систему. Потом я её нам напильником ещё какое-то время доводил. У меня прототип получился, ну там работающий. Понятное дело, это как со всеми вот этими историями с агентами, что, ну, прототипы демо показать легко. довести сложно, но тут, ну, базовый концепт. Я понял, что вот этот ТД вот там сходы я могу обсудить, ну, не знаю, с каким-то счётным количеством людей, организации, где мы сможем прямо по всем компромиссам пройтись, понимаешь? Да. А там остальным мне нужно будет рассказывать, ну, типа, о чём мы тут вообще речь? Я такой думаю: "Блин, ээ насколько ж это бустит тебя эмен формате, когда ты знаешь, что ты делаешь, да?" Ну, то есть, когда ты вот, ну, прям детально шаришь, ты можешь сформулировать на прямо архитектурно на том языке выставить, ну, типа какие, ну, типа какие тебя, ну, трейдофы интересуют, что ты предпочитаешь, ну, типа смоделировать какую-то историю, они пересекаются, они, ну, там, уточнить, то есть это тебя супербустит. Но если ты этого ничего не знаешь, ему вот с Серёжей Барановым разбирали про State of AA в архитектуре, там был обзор литературы, большой papпер с кучей, ну, с кучей анализа. Э, Серёжа упоминал, что вот если ты говоришь на обывательском языке с агентом, он тебе вот какой-то дженерик ответа даёт. Когда ты говоришь на чётко специфичном внутридоменном языке, то такое ощущение, что модель находит вот репрезентацию того домена, о котором ты говоришь, и выдаёт суперкачественный результат. И похожийпер был у этих, как его, у антропик. Они рассказывали про почему доменная экспертиза суперважна, что даже не софтвей инжеринг сейчас важен. Ну типа и уровень софt инженеринг часто решает при делегировании задачи агенту. А часто экспертиза в том домене, в котором ты ставишь задачу, ну, условно, супербухгалтер у тебя лучше решит задачу с агентом, чем суперинженер, который в бухгалтерии не шалит. >> Абсолютно верно. Я тебе знаешь ещё одну такую интересную штуку скажу, которая вот прямо соединяется с ней. Я периодически рассказываю про то, что проект нужно менять под агента, то есть и процессы, и проект. И когда я про это рассказываю, я говорю: "Вот очень простая, казалось бы, банальная вещь, но именование". Вот у нас, например, учебная тематика, да, и внутри, понятное дело, мы используем термины, там курсы, модули и так далее, но она, скажем так, поскольку давно проект был создан, то есть мы там ещё в тринадцатом году, понятно, что часть вещей поехала, не так именовалась, и есть с этим проблема. И я просто ваучую очень много раз видел, что когда ты используешь такие понятия, ишка без подсказки, она не делает правильных выводов. И в какой-то момент для меня стало очевидно, что я должен как бы привести это с терминологией, которая в неё заложена. Я говорю: "О'кей, смотри, как в университетах называется процесс там подачи заявления такой, там типа adдmission". Я такой: "О, мы этот терминал не использовали. Как он используется? Для чего он нужен?" То есть я у неё узнаю сначала какой-то домен общий и потом смотрю: "Ага, всё, вот эти штуки надо переименовать". И мы вот последний год очень много занимались тем, что мы вот делали вот такого плана рефакторинга. Просто мы переименовывали для того, чтобы он понимал всю тему без того, чтобы ему рассказывать. И очень круто то, что ты сейчас рассказываешь, что это ещё и усиливает его, потому что когда он видит, что терминология используется та, на которой он учился, он может делать более правильные выводы и более правильные рекомендации давать. Это офигенная штука, на самом деле. >> Я тебе больше скажу, что у нас, ну, перед уходом моим мы обсуждали, знаешь, да, давай расскажу такую историю. Вот смотри, биктехи, они знамениты чем? Ну и зарубежные, и там российские, они знамениты тем, что на том масштабе, на котором они работали вот по старым процессам, многие open source инструменты, они, ну, переставали работать. Ну, условно говоря, ты берёшь какой-нибудь ээch сусет, растягиваешь его там на тысячи, короче, аналитиков, десятки там тысяч с с инженерами, и он начинает разваливаться. Или ты берёшь, ну там попроще пример мотормост, да, и засовываешь туда там десятки тысяч людей, которые общаются, и он там разваливается. Ты берёшь апач зепилин, да, ноутбуки для аналитиков, и он примерно так же разваливается. Ну то есть у тебя всё плюс-минус, ну как бы open source на масштабе бигтеков не работает. Дальше что происходит? Часто ты такой начинаешь пытаться думать: "А что делать?" Ну, типа, раньше с нуля было не прикольно делать, потому что это долго, дорого и вот это всё. Сейчас, кстати, ну, это большой вопрос, как делать, может быть, потом обсудим. Но ты раньше что делал? Ты брал какой-нибудь Open source, говорил: "Похож, но не тянет мою нагрузку". Так, потом ты такой думал: "А можно ли законтрибьютить в Астрим?" приходил в обстрим свои идеи, тебе говорили: "Чувак, таких как ты, короче говоря, ну вот с таким масштабом очень мало, но дамажет это всю архитектуру сильно для всех усложняет. Давай ты как бы пойдёшь куда-нибудь в другое место, ну, со своими предложениями". Ты такой: "Всё, понял". Делаем форк этой истории и допиливаем, ну, напильником свои фичи. Но когда ты допиливаешь напильником, ты такой говоришь: "Блин, я давно мечтал сделать этот продукт лучше". Да? и начинаешь поверх придумывать свои какие-то подходы, другие пишиние. И ты теряешь не просто, ну, в смысле, ты не только получаешь э масштабирование и какие-нибудь корпоративные фичи, которые тебе нужны были там, типа федерализации или ещё чего-то в решении, а ты получаешь фактически новый новую поверхность. И раньше ты мог это обосновывать тем, что эта новая поверхность позволяет тебе какие-нибудь фичи лучше там реализовывать. Вот. Хотя это скорее была хотелка продактов, да, которые такие: "Блин, нам дали это порулить, я же не могу просто запстримом следовать". Тогда все скажут: "Что я за продакт?" Типа я даже фичей придумать не могу. Ну, типа на каком-нибудь очередном повышении мне скажут: "Ты просто повторял запись стримом". И скажут, что ты не достоин следующего грейда. Поэтому я проверю своя креативность. И вроде нормально работал. Примерно по этим же причинам.

US интерфейс активно, ну, типа, развивался. Да. Ну, то есть нужно же его переработать, натянуть свою дизайн-систему, все экранчики переделать, всё такое. Когда пришёл я, и агенты. Вот. И помнишь, я рассказывал, что нужно сделать эти все системы доступны доступными для агентов. Агенты такие смотрят, такие: "Вде там условный апачпилин, а работает не как апачпилин, и тебе нужно кучу приседаний, кучу Q сделать для того, чтобы он понял, а чем он отличается и как вообще сюда стучаться и какие там три присяда, там двад два прехлопа, три притопа сделать, чтобы что-то получилось. И большую часть вот вещей, когда ты фактически свои внутренние платформы публиковал агентом, они заключались не в том, что агент не знает, как сделать. Он вот с опнсом отлично натренирован и, ну, как бы и скорее всего мог бы классно сделать. Он не знает твоих местных приколов, да, с тем, как ты фоткнутое решение допилил под себя. И, ну, как бы это фактически стало историей, что, блин, ребята, давайте как бы наши вот эти наработки вернём. Ну, как бы сделаем так, чтобы оно было совместимо по IP с абстримными решениями. Почему? Потому что тогда агенты могут из коробки работать с этими решениями. И типа ты получаешь, ну, буст без вот этой, как его, кучи скармливания в контекст информации, а как тут нужно делать. Но это очень сложно. Я для себя это переводил, знаешь, из истории, как, условно говоря, это раньше был у тебя такой типа некоторый наработанный актив, через который ты мог реализовывать вот эту экономию на масштабе. А в вей вот эти куча своих платформ, которые работают не похожи на то, на чём учились модели, это превращается в какой-то такой пассив, где тебе для того, чтобы он стал обратно активом, нужно вот кучу кучу работы сделать. И часто она, ну, она хуже работает. Вот эти все истории претрей, ну, где модель училась пользоваться этими инструментами, работает сильно лучше, чем э попытки запихнуть это в контекст, доучить чему-то. Ну, если ты файтюнишь и в reinforcement learning среде крутишь, ээ, ну, до обучения, может быть, ты можешь обучить, но обычно заканчивается всё тем, что а давайте побольше вот в этот в бесконечное наше окно засунем примеров того, как этим пользоваться. Авось агент исправиться. И ты такой: "Солу, соу, >> я очень хорошо запомнил, когда мы на Хайлоуде с тобой там сидели, а ты вот эту фразу сказал, которая так компактно выразила ту идею, которую я тоже очень люблю, что в современном мире слишком дорого делать костомные решения. Это видно по многим организациям, что, например, у нас там дизайн-система или там мы что-то сами навернули, о, давайте хотя бы заосорсим, пусть оно хоть и проиндексирует, и через полгода оно будет уже на этом научено". А, кстати, это интересно, но вот я в целом люблю open source и всю же свою жизнь вот разработческую, ну, там, пулреквестил, насколько мог. И вот эта вот ситуация, при которой, ну, грубо говоря, мы какие-то допилки, фиксы делаем внутри, я теперь каждый раз такой думаю: "А что я туплю? Я буду отдавать это наружу." И вот за последние, наверное, месяца три я около двадцати полреквестов сделал. Ну, естественно, это всё через заишку, но при этом это каждый раз именно кейс. То есть ты вот прямо в контексте, у тебя сессия говорит: "Вот, есть проблема". Я говорю: "Ну, раз уж мы с тобой об этом поговорили, давай отправим". И вот ты не поверишь, я каждый день практически начинаю с утра день с того, что открываю мой полреквест куда-нибудь принят. Там в шопифае какие-то проекты, ещё где-то, ещё где-то. Я такой: "О, вот это вот я понимаю". И мы прямо, знаешь, так отправили туда код, у себя костомчик убрали. Отправили туда код, у себя костомчик убрали. Просто красота. >> Это классный процесс. Но вот видишь, это классно работает для, ну, для компаний, в которые вот это решение им позволяет, ну, зыс работать. То есть кастом у тебя получается не из-за того, что ты его хочешь глубоко там переделать и там растянуть на тысячи инженеров, а скорее потому, что там есть проблема. >> Да-да, да, сложнее, да, да, да, да, это понятно. Но при этом, а это интересно, конечно, куда всё это приведёт, но довольно забавно наблюдать, как те вещи, которые были преимуществом когда-то, теперь начинают, наоборот быть недостатком. Мне это напоминает, кстати, у тебя берёшь любую оффлайновую инженерию, там Нью-Йорк и Лондон, в которых метро появились одними из первых, но мы знаем, к каким это проблемам привело, потому что, естественно, когда они это делали, ещё многие проблемы были непонятны там. Но это касается почти всего, что связано с ранним появлением технологий. вон в Штатах банкинг, да, появился там чуть ли, ну, раньше всех практически я имею такой современный банкинг. И всё, чеки у нас до сих пор. Нигде в мире их нет, потому что это пережитки как бы старой системы. >> А давай сейчас ну там пример более новый приведём. Вот смотрите, работотехника, да, вы все видели, как там гуманоидные роботы сейчас, ну, типа на хайпе. Вопрос: "А зачем нам нужны именно гуманоидные роботы?" Они нам нужны зачастую вот, например, на производстве. Почему? Потому что ты капиксом вложил миллиарды долларов в том, чтобы автоматизировать текущий пайплайн. И у тебя есть вот эти роборуки, которые выполняют какие-то этапы, но часть этапов ты закрыть не можешь, и тебе нужны люди. И ты такой говоришь: "Блин, я ведь всё перепроектировать не могу, потому что супердорого. Давайте мы попробуем туда реплейсмент сделать. Зыс фактически вместо человека будет другой робот ходить". Хотя, если ты сейчас смотришь на какие-то, ну, как бы истории, ну, как бы другие, да, то ты понимаешь, что если ты можешь перепроектировать целиком следу, то тебе не нужен гуманоид, ну, сходящий, ну, на двух ногах с двумя руками. Ты можешь взять, например, на колёсиках ежущую штуку, манипуляторы по-другому поставить. То есть ты можешь прямо задизайнить всё целиком. И это вот как раз говорит про то, что, ну, вот там святой граль, гуманоидный робот, он фактически нужен сейчас, потому что у нас вся среда сделана под людей, да, ну, в смысле, окружающие. И часто даже автоматизации там производства, они сделаны так, что всё, что я мог автоматизировать без человека, я сделал по старым способам, да, вот, ну, типа через, ну, нам другой подход к работотехнике, а человек остался здесь, вот прямо вот, ну, как бы нужно, не меняя всю окружающую стену, сделать заменитель человек. Ну да, >> по факту, если бы ты, например, сейчас автопроизводство какое-нибудь сетапил, ты бы, скорее всего, попробовал без гуманоидных роботов собрать роботизированную линию и сказал, что, ребята, дизайним вот Greгenfield проект, да, типа делаем с учётом всех модных наворотов, но оптимизируем там пропускную способность, не знаю, стоимость, короче говоря, ну, простоту и достижимость этого решения, и ты бы, скорее всего, выбрал негуманоидных роботов. Это правда. Но теперь они с нами, и они классно выступают на концертах и на олимпиадах. А у меня следующий вопрос такого характера. Давай переключимся теперь тоже. А по поводу знаний. Я, если правильно понимаю, то практически весь крупняк - это confнлюнс. Ну, в любом случае, это не код. То есть я имею в виду, когда речь идёт про базу знаний, да, это где-то там хранится. И вроде бы как сейчас есть тенденция из-за того, как Spec Driven Development все эти штуки устроены, из-за того, что Git становится более таким как бы общим знанием, а не каким специфическим программистским, что как будто бы все такие: "Так, давайте все знания переносить туда, через это работать, везде интегрировать и так далее". Или всё-таки это удел будет такой, ну, такой гиковский более, и ты думаешь, что всё равно все продолжат в жире, в конфлюнсе, просто навернут сверху инструментарий и вокруг него мы будем работать. То есть, короче, как будут современные базы знаний, как мы будем их накапливать, как мы будем шарить этот контекст, как это будет существовать, в каком виде? >> Отличный вопрос. Давай я попробую ответить. Так, то есть, если мы говорим про текущий крупняк и про текущие процессы, процессы работы сознаниями, ну, они сильно завязаны на то, кто с ними работает, да? И вот я тебе рассказывал примеры, где люди готовы перейти на источник истины прямо внутри репозитория, и, ну, они получают классные результаты. Проблема, что текущий подход с Викиджира, там остальными, короче, историями, он обычно завязан на то, что этим пользуются там, не знаю, топ-менеджеры, продуктовые менеджеры, там дизайнеры, аналитики разных сатов, ну, бизнес-системные, количественные, рисковые, неважно, инженеры, там, саппот, э, Q. Я, например, э, ну, в общем, в мобильном банке мы сильно меняли подход работы с требованиями. От, он изначально вот когда я в девятнадцатом году пришёл, он был аля с этой, как его, с, знаешь, с аутсо организацией. То есть там писали требования на версию прямо вот целиком копировали предыдущую, говорили, какие экранчики, ну, типа появляются, ну, первый экран с какими-то там спеками, с описанием. Люди вообще не читали это добро. Ну, в смысле, кроме саппотта, да, который должен был понять, а что в новой версии появилось и если там проблемы нет. Инженеры, ну, типа такие: "Блин, нам вот по кругу это пишут". Я помню, когда там версию очередную главной станицы выкатывали, я го они говорят: "Есть проблемки". А я, ну, за это всё толчал, как технический директор. Я говорю: "А с чем вам помочь?" Они мне кинули ссылку на вот описание этой спеки. Главная станица - это же экран. Я открываю, там такое ощущение, что 50 pageйдаун вот таких вот. Я говорю: "А у вас есть описание?" Ну, концептуально, что что там должно быть? Они говорят: "Так что там же всё есть". Я начинаю читать и понимаю, что это, знаешь, как Стангольский синдром. Люди, которые годами с этим работали, они уже привыкли. И те, кто должны были эти читать, ну, типа читали. Те, кто могли это не читать, не читали. И шаринг знаний был очень простой. Я общался с продуктовыми ребятами и с дизайнерами. Они говорят: "Так мы всё в фигме рассматриваем. У нас там есть сценарий, который мы вот джаба, которая это, а потом это превращается вот это уродство. Я такой и и у меня просто был кейс, когда я должен был переделать работу аналитиков и работу с требованиями из вот такого подхода описания по фичам, понимаешь, да, чтобы люди могли прочитать, а что вообще происходит-то, ну, типа, что мы хотим улучшить, как работать это должно. Не только вот эти избранные продуктовые ребята или там дизайнеры. Ради справедливости надо сказать, что я концепт написал, написал, как должны аналитики поменяться, и нашёл э девочку, которая у меня руководила всей этой трансляцией. Ну, супеналитик, руководила этой профессией, она пришла, ну, и планомерно этим занималась. И там за 2 года поменяла этот процесс. Ну, 2 года. И мы из Вики, на самом деле, не уехали. Ну, то есть, по большому счёту, мы по факту просто отогонально сделали, да, от экранов к описанию фичей. И экраны просто, ну, там, из какого-то набора вот этих, ну, не вечей, а джабов, да, ну, состоят.

[фыркает] Вот. И я тебе могу сказать вот из этого опыта, что поменять подход работы с информацией в крупной организации, типа едьте все в гит, а такой эксперимент в мобильном та банке тоже был. Мы управление конфигурациями фактически сделали через GOPS, ну, мобильный банка. Мы всех аналитиков заставили, ну, начать в гитебираться. Но сколько это было проблем? Вся та же девочка, ну, типа, помогала это драйвить. Это было супер сложно, но у меня был паур и ответственность за эту штуку. Как это растянуть? Ну, типа, аля, переедьте в гит на уровне всей базы знаний, ну, компании там на сколько там 100.000 человек. Ну, ладно, ну меньше двадцати. Я сложно себе представляю, как фотобанки пошли, сказали: "О'кей, у нас есть Gra, Vik, там, Gitlub, Pages, Git, там ещё что-то". Давайте сделаем фактически внутренний перплекси, да, который умеет всё это индексировать, у которого есть там метрики по поиску стандартные, потом у которого есть фактически generate часть, ну, условно некоторый рак был, да, то есть с м полнотекстовым поиском, с этим семантическим, с вектомз данных, не знаю, графовую туда в итоге, ну, допилили, ну, связь между документами нет. Ну, скорее всего, дошли до этого. Но проблема, условно, внутреннем перплексите примерно, знаешь какая? Ээ обычные поиски классно работают, когда у тебя есть онлайн-метрики относительно того, как люди пользуются поиском, и ты можешь их использовать для улучшения релевантности выдачи. Вот. А если ты этого использовать не можешь, у тебя, ну, там, десятки тысяч людей этим пользуются, но, в общем и целом у тебя нету вот этого фидбэк-лупа. Ты часто не можешь понять. Ну вот я искал в этом, ну, нашем поисковой истории в стиле: "Расскажи мне стратегию компании, ну, IT-стратегию вот про там, не знаю, про что-то". И оно мне выдаёт там топ-пять - это кусочки IT-стратегии интерпретации разных бизнес-линий. Вот. А общей нету. Почему? Потому что общую один раз посмотрели, эти люди написали свои версии и ну и они как бы и чаще туда заходят, больше просмотров и, ну, типа они в индексе выше, соответственно, ну, типа как определить вот эту релевантную историю, непонятно, но ответ на твой вопрос вот в крупной организации как раз примерно такой, что мы человеческое поведение часто изменить не можем, поэтому давайте как-нибудь технически решим эту проблему, так, чтобы у объегентов появился контекст, ну, нужный им. Вот. И это становится каким-то бейзлайном. А дальше вот те люди, которые супер заинтересованы в результате, они фактически адоптят новые подходы и потом сарафанное радио говорит: "О, у нас так работает лучше". И самые, ну, вот топовые ребята начинают переезжать на новые процессы. Но как вот этой кривой Гатрана, помнишь, или адоптеры ну и так далее. Ну, короче говоря, это вот примерно так распространяется подход. >> Понятно. В общем, с документацией сложный момент. Казалось бы, да, просто тексты, а организовать всё это большая проблема. И пока непонятно, как. Хотя я уверен, кстати, я не знаю, как сейчас это происходит в России в этом плане, а жира и конфлюнса, зная, видя и понимая как бы опасность того, что возможно новые инструменты, новые подходы, наверное, делают просто все усилия для того, чтобы это типа: "Ребята, мы ещё лучше, оставайтесь у нас, поиск всё, что хотите" и так далее. Если, конечно, кто-то может обновиться на эти новую версию.

[смех] >> Смотри, история какая. Я как-то смотрел, чтон делает. Они пытаются в это идти. И как раз value proposition примерно такой. Мы уже являемся хранителями не просто документации, а вот ээ рабочих workкflow, >> знаний. >> Да-да-да. И типа пользуйтесь нами дальше, мы вот этот слой сделаем сами, и вы сможете его в при ну типа выдавать агентам. Но за рубежом, мне кажется, что там модные молодёжные ребята идут условно в сторону какого-нибудь линер или там, ну, короче говоря, каких-то других историй, где они могут гибче собрать под себя workкфлоу и не завязываться на вот этого монстра. Проблема в том, что в России atlн, ну, ты его использовать не можешь, особенно, ну, если это cloud какая-то версия, ну, нормально использовать не можешь. Вот. А он PRUS с инсталляцией, они становились там в двадцать втором году, если да, даже ими пользовался. И продолжаешь пользоваться, несмотря на нарушение каких-нибудь лицензии. >> Короче, рынок рынок они так или иначе кажется потеряют. Ну, посмотрим, конечно, но это интересно. >> Ну, именно российский рынок, Кирилл, российский рынок. Вот на зарубежном, я думаю, что там битва предстоит. Ну, то есть, условно говоря, там вот этот локн на вендера, да, вот именно не документация вот этих процессов, он очень силён. То есть я, когда вот в больших крупных организациях отвечал за большие изменения, я заметил, как иноционно любые изменения, которые меняют работу этих людей. То есть это очень сложно, очень долго. И как это сделать быстрее, я не знаю. >> Да. Смотри, следующий вопрос. Касаемый метрик. Вот это вообще очень интересно. Если ты помнишь, на Хайлоуде как раз, э, был C Level Club сбор, кстати, я не помню, ты присутствовал на нём или нет, который я фасилицировал. Вот. И там как раз обсуждали метрики, то есть какие метрики при внедрении, на что мы ориентируемся и так далее. И там, как ни стра, кстати, для меня это было довольно удивительно, но почему-то очень многие говорили про деньги, хотя прямой какой-то связи между деньгами и фичами и изменениями нету, честно говоря, и там может быть всё сильно по-другому. Но в конечном итоге вроде как бы сходили, что стари - это вот самая адекватная метрика по тому, что у нас вообще всё хорошо получается. Что ты на тему думаешь? Как к чему, каким выводам вы пришли? >> Ну, смотри, я на этом именно мероприятии не был. Мне нужно было ехать там после моего выступления обратно в Москву и вечером улетать. Ну вот я как улетать во Владивосток. Я с НДИ командой туда летал в наш дицентр. Вот. И, ну, я просто, ну, не добрался до мероприятия, там физически невозможно было. >> Если говорить про метрики - это вообще супер интересная тема. И, мм, давай я буквально вот вкратце расскажу типа школу мысли, которая мне нравится и в которую я, ну, мне кажется, в которую нужно идти. Она выглядит примерно так. Типа, первым делом ты смотришь на то, на метрики использования, ну, и проникновения технологии. То есть ты там раздал людям там так или иначе доступы к каким-то инструментам, ты смотришь, они пользуются или нет. Дальше ты можешь смотреть, ну, если у тебя агенты, не только люди запускают, они в каких-то сценариях автоматически отрабатывает, да, например, кодрев делают или там баги фиксят или ещё что-то, ты смотришь, какие сценарии из тех, которые тебе интересны, покрыты этими агентами и сколько там они работы выполняют. Ты можешь видеть, э, количество, ну, там мерить сгенериённого кода. Ну, такая метрика, на которую все молились, но она, как сказать-то, примерно как Lines of Cod настолько же туповата, короче, по своей сути. Вот, и сбивает с толку. Но, в общем и целом тебе этот начальный этап точно интересен. И если там видны какие-то отклонения, ты можешь узнавать, а почему, например, у тебя часть организации, ну, не используют эти инструменты. Ты приходишь и выясняешь, а почему. Вот. Соответственно, вторая часть более интересная. Представим, что ты там крупная компания, ну или не крупная, но в некрупной ты можешь руками всё посмотреть. В крупной ты у тебя есть какая-то по факту платформа разработки, которой все пользуются. И вот в этой платформе разработки часто есть какой-то набот джабов, которые твои инженеры так или иначе там реализуют. То есть им нужно по факту что делать? Ну, Google про это писал.

Measuring developer goals, как они сделали для инженеров аля customer Johny мапу, да, ну, короче говоря, набор вот этих джабов, которые выполняют инженеры, и померили, померили, сколько люди тратят на это времени. Э, в вне Гугла я такой истории ни разу, ну, не читал, что они настолько фундаментально подошли. Хотя в запрещённой наси была история про то, как они diving time, ну, то есть время на создание дифа мерили. Примеры этой истории - это, например, ты там делаешь как раз какое-то изменение как инженер или ты там discoveroverришь информацию, да, какую-то, ну, вот по по системе, ты какое-то решение архитектурное должен принять, ты проверяешь качество чужого кода, да, ну вот условно делаешь кодрев, ты там, не знаю, инцидент какой-то, ну, как устраняешь. То есть у тебя есть вот такие джабы, и ты можешь пытаться их как-то померить, сколько на них времени уходит. То есть, если ты инструментализируешь твои инструменты, инструментализируешь сбор информации своих инструментов, и дальше получается какая история, что ты можешь пытаться мерить не только как и яй влияет на это, но и как, например, твои какие-то изменения в платформных инструментах. Ну, например, ты померил, что, э, ну, для тебя важен сценарий про создание нового сервиса, да, и деплой его на продакшн. И ты говоришь: "Ребята, вот, ну, первым делом ты говоришь: "Давайте end toend проверять, насколько это быстро делается с получением там нужных ресурсов, ну, заведением репозитория, получением нужных ресурсов платформе, согласование каких-то прав доступа, ну, и деплоем этого сервиса, условно, ну, аля, напрот". Ты такой говоришь: "О, день занимает, что-то нездорово". А потом такой довёл до 4 часов, до 2. А потом ты можешь на самом деле понять, как это померить. Ну, для инженеров. То есть у Гугла это был прямо пайплайн примерно такой. Ты собираешь логи из разных инструментов. Ты эти логи превращаешь в события. События слеиваешь в сессии. У сессии есть обычно, ну, типа привязка к тому, какой тип работы ты делаешь. И, ну, в смысле, какой-то идентификатор, например, задачи или инцидента или ещё чего-то, и артефакт какой-то. Ну, может быть, например, код, да, или мёшли квест, который ты сделал. И дальше ты можешь относительно этого стоить метрики. И у Гугла это было прикольно, что они, ну, это сделали сильно раньше в году в девятнадцатом, э, вот, ну, такую систему, потом выделили джабы и начали смотреть, а как там изменения в в инструментах влияют на время, которое требуется для выполнения джабы, и какие вообще отклонения бывают. Ну, типа, мета это сделала позже в году, по-моему, в двадцать четвёртом была эта статья или в двадцать пятом. их интересовало конкретно, сколько времени тратится на создание вот, ну, условно говоря, изменения. И там есть интересные приседания, что, например, у нас в Т мы тоже мерили, сколько, ну, например, как и я и помогал скоростью от мёрди квеста фактически, ну, до того, что он смёджен и ну, типа, эффекта не было видно. Я спрашиваю команду: "О'кей". Но кажется, что вот когда агент есть, самое большое, чем он помогает - это начальный, ну, типа этап, когда ты от идеи до первого мё квеста сделал, а не дальше, когда тебе комменты от людей пришли или от бота, и ты дорабатываешь. Я говорю: "А есть вот померить прямо от интента, ну и до до этого до деплоя". Мне говорят: "Это было бы классно, но мы не собираем информацию о том, когда он начал работать, а Google как раз собирает, понимаешь? Да, у тебя есть вот эти логи, и ты по факту можешь привязать, что эти логи о том, что кто, ну, человек работал, они связаны с этой задачей, с вот этим пулреквестом. И можешь прямо начало посмотреть, и что у тебя получается, что ты меришь от начала вот от интента до одного деплоя, и можешь сравнить, а как было без агента, да, и как с агентом. И вот инструментализация этой истории, она очень сложна. Так вот, что получается? Ты можешь померить, как и яй, ну, который ты впилил в разные поверхности и в разные джабы, как он влияет на вот это время выполнения этой джабы. И ты получаешь некоторое сэкономленное время, оно автоматом не конвертируется в эффект, потому что, знаешь, работа, она как газ занимает всё доступное время. То есть, условно говоря, если за меня агент вот тут работает и я уже код не пишу, я могу пойти с Васей и выпить кофе и обсудить, какие агенты крутые или, не знаю, как мы на рыбалку поедем на выходных, да, с ним или ещё что-нибудь могу обсудить. То есть это уже вопрос, как ты освободившееся время конвертируешь в эффект. >> Угу. >> И третий блок, ну, вот первый был, помнишь, про то, э, как вообще пользуются этими инструментами и какие-то там количественные метрики. второй про то, как время сэкономилось, а третий у тебе позволяет уже замкнуть, на самом деле, экономику. Экономику ты примерно как замыкать можешь. Ты можешь, э, вот эти джабы посчитать, ну, сколько ты сэкономил времени и посчитать, сколько ты потратил на платформенную команду, на какие-то инструментализации, в конце концов, на токены, короче, которые, ну, тратятся в рамках этого. То есть это сложный путь. Все экономику пытаются считать примерно так: "А давайте возьмём не вот эти прямо реальные данные, а давайте возьмём что-то из метрик по потоку", да? То есть вот у тебя есть по потоку работы метрики, например, пропускная способность команды, да? Сколько она вот за единицу времени протаскивает вот этих, ну, ты упоминал про сторипоинты или стареи, ну, неважно, если у тебя есть какой-то эквивалент вот полезной работы, да, например, эпиками. >> Ну, тикеты, допустим, >> тикеты, да. Вот ты можешь увидеть, что тикетов больше стало. Вот. И ты такой говоришь: "О, классно". С другой стороны, ты можешь поверить время, ну, условно говоря, какой-нибудь ТТМ, неважно, ну, ты можешь time to market, ну, настоящий померить или ты можешь какой-нибудь lead time или cycle time померить, ну, в смысле, части процесса, который ты помог с AI улучшить. И тогда ты говоришь: "Смотрите, например, фрупут стал больше на 20%". кажется, нам помогает, но потом важно заглянуть внутрь, а что это те за, ну, типа 20% дополнительные. И мы буквально вот недавно с Глебом обсуждали Михеевым. Он ко мне на подкаст приходил. >> Вы в лайве были? Да, >> да, мы в лайве были, да. >> Я просто, прости, да, я просто YouTube вчера просматривал, и у меня, прикинь, высветилось. Я на 2 секундочки прямо зашёл, посмотрел.

[смех] Да-да. Да, мы там полтора часа общались. Вот так Глеб как раз подсвечивал историю, что если не менять процесс Discovery, то дополнительно 20% рупута скорее возьмёшь ээ следующий нижней, ну, части из задачек. Если ты не расширил воронку, ну, Discoverovery, то это будет по закону убывающей полезности, ну, следующие там 20 относительно вот этих 100% они будут хуже, ну, и менее ценными, чем первые 100. И получится так, что ты такой, ну, будешь, ну, выгребать задачи, да, они будут сделаны, но бизнес скажет: "Так мы без этих задач жили. Мы рассчитывали, что ты, условно сделаешь 10 задач, ты сделал 12, но те две были какие-то такие nice to have или вообще твои какие-нибудь технические". И ты говоришь: "Ребята, ну, может тогда нагерите 12 полезных задачейк в следующий раз." И это, ну, большой вопрос как раз, что у тебя, если ты перестраиваешь так систему и она начинает работать, то она реально превращается вытягивающую, понимаешь, да? То есть у тебя delвеy начинает, ну, типа, выгребать больше и больше требований к discovery, к тому, чтобы крутых задачек, полезных бизнесу становилось больше. >> Это вот буквально на днях у нас такой вот момент произошёл. А, то есть всё это время как бы мы разгонялись у себя в компании, да, и всё больше делали фич. Не только фич, это касается разного рода. потому, что контентом работаем, там всякие ошибки, ну, много мелкого разного. И я прямо начал видеть, и мы такие: "Давайте, ребята, поднажмём. У нас там годами копились в бэклоги, всякие штуки, давайте поднажмём". И у нас реально стало получать, то есть мы прямо заметили, как оно вот прямо пошло вниз, вниз, вниз, вниз, вниз. Но это же вопрос был в том, что ещё с той стороны как бы, когда привыкли, ну, как бы с той, я имею в виду, вот у меня продукты мои, они когда смотрят на это всё, они такие: "Так, смотрите, оно разгружается быстрей". А у нас-то идей-то полно было. Нам, мы просто их специально не ставили, потому что что грузить-то всё равно не успеем. И мне за последние 2 дня, ну, просто там плюс 200 тикетов, а я со своим продуктом созваниювась. Я говорю: "Ты что делаешь? Мы только, знаешь, я такой ощущение, что я, ну, как-то начал завершать вот этот весь долг, а теперь он мне стал больше в разы, чем у меня там, типа он был за последний год". Поэтому да. Ну и это всё важно. Это всё то, что просто то то, что типа годами не могли до этого добраться. >> Но видишь, ты в хорошей ситуации. Если у тебя продакты могут выгрузить прям, ну, как бы полезные, крутые задачи, которые просто откладывали, это хорошо. В корпорациях часто бывает, ну, смотри, история какая, не все продукты всегда находятся на фазе активного роста, а команда есть у всех продуктов. В итоге раньше, ну, типа там Продакт, например, там с трезком смог придумать какие-то фичи, ну, типа защитить их, ну, типа проработать и так далее. Теперь говорят: "А мы теперь можем их быстрее дозвести". И он такой: "Боже ты мой, а я не могу придумать ещё какие-то". И дальше появляются, знаешь, там ну, в общем, появляются задачи. >> Дайте ёлочку добавим на 8 марта.

[смех] >> Ну, у меня, конечно, вопросики к таким продуктам тебе, честно скажу. Ну ладно. Ну, кстати, слушай, ты так классно разложил, что у меня вот вопросы, которые в процессе возникали, ты прямо отвечал на них, поэтому получилось, что у нас целая какая-то такая система разложенная. Мне очень понравилась история про как метрики и как делает Google, потому что для меня, как человек, который и от маркетинга, и от бизнеса, это же, ну, вебаналитика у них так устроена, и получается, что они как бы этот опыт перенесли туда. Это прикольно. Вот эти вот сессии, да, события, которые там происходят. Классная идея. И ты хочешь сказать, что это прямо типа становится индустриальным стандартом, это работает? Это реально очень хорошо построено или всё-таки? >> Смотри, история какая.

Google - это компания, которая может себе позволить, ну, типа, делать вообще какие-то космические вещи. То есть у них деньги фактически из воздуха появляются, да, из этой рекламы. То есть там академический такой дух, ну, раньше был, не знаю, как сейчас. И говорить, что то, что сделал Google, можно повторить, это, ну, в смысле, у себя, это, ну, не всегда правда. Но, например, Мета рассказала про то, как они именно defing time, да, вот фактически вот не для всех сценариев, а для сценариев создания изменения, ну, продуктового, ну, реализовали и сказали, что теперь их инфраструктурные команды на это, ну, нацелены, да? То есть они привели примеры, как, например, они катали изменения аля в Бэттесте. Они сказали, что у них там не везде была автомимоизация, короче, реализована, да, и они тут решили, что надо для старых проектов её включить. Но включились не везде сразу, а только для части прокатили изменения и дальше померили. Ну, работа, ну, диф быстрее делается. Нет, это, как я понимаю, было ещё до вот это они такие: "О, там, условно говоря, сколько там 10 или 15% ускорения работы над задачей видели. Какие говорят: "Классно". Другой пример у них был. У них была, ну, у них есть хак. Это вот аля последователь там PHP, да, и у них, эээ, как я понял, типизация в этом хаке в самом продуктовом кодела, а в тестах не было. И они примерно так же, то есть половину тестов поменяли, и, ну, типизация начала показывать, что ты что-то не так сделал, вот прямо пока ты код пишешь, а половине нет. И померили, а вот фичи, короче, в какой код попадают, но насколько быстрее делаются, и тоже увидели эффекты. Это прямо крутой инструмент для того, чтобы, ну, мерить любые изменения своей платформенной, понимаешь? Они один из прикольных для меня прямо кейсов. Я же за Мобильный банк долго отвечал. У них был контрфактуальный анализ того, насколько им, э, кросс-платформа в мобиле помогает, экономит время по сравнению с отдельной реализацией Android и iOS. Ну, понятное дело, что это опять до эра, но они очень неплохое приседание сделали. И я бы хотел сам, ну, такое же примерно сделать. Проблема с тем, что вот то, что я тебе сейчас описываю, система инструментализации того, как работают твои инженеры. Ну, я, в общем, со своим руководителем CO на тот момент общался. Он мне сказал: "Саш, ты очень академичен. Вот сейчас у нас большие изменения в процессах грядут, и не время, короче, измерять то, как они работают пора, ну, раньше, типа, сейчас всё поменяется". И я такой про себя посмотрел, подумал, что, ээ, ну, я, конечно, действительно очень академичен. Я очень много пейперов читаю и вот, ну, того, что можно сделать. И я не всегда могу тебе чётко сказать, то есть отобьётся ли это на, ну, как бы инструментализация, ну, на масштабе или мы потратим время зря и можно просто, ну, типа, какие-то улучшения сделать. Но если говорить про какое-то управление, помнишь, я говорил про изменения на масштабе, то наличие метрик и вот инструментализация типа позволяет говорить на языке цифр с людьми, которыми, наверное, по-другому сложно говорить, которые говорят: "У меня и так всё работает, короче говоря, и я менять себя не буду". Если у тебя есть эта инструментализация и ты можешь показать, что у них, конечно, работает, но можно это работать эффективно, потому что там у соседа работает эффективно, когда они поменяли свои подходы, то у тебя очень сильный аргумент. Вот. И, ну, я тогда, например, не смог эту историю продать, и я не знаю, как бы там по-другому развивались события, если бы я смог это продать. >> Мы, кстати, очень вплотную подошли к следующей части. ты предыдущие моменты говорил по поводу того, что у тебя крутой бухгалтер сделает и разберётся лучше, чем крутой инженер, который пытается, да, это автоматизировать. И как раз, э, в любом случае, мы понимаем, при любой инструментализации, конечно же, люди важнее, да, если у тебя слабенькие люди, то и, в общем-то, результат будет посредственный при любом [фыркает] сетапе вокруг них. И, собственно, вопрос, мы ещё до сих пор находимся все в состоянии, когда людей много, там экономические причины, другие причины, короче. индустрия вот вошла в этот режим, что увольнение, увольнение, увольнение, есть люди, люди, люди. Плюс иишко наложилось, соответственно, меньше людей, ещё меньше нужно. И достаточно большое количество профессионалов на рынке вопрос решается так, как, ну, давным-давно не решался. Но мы все понимаем, что это в какой-то момент закончится и будет приток новых людей, будут приходить ээ нужно учить текущих, ну, будут приходить новички, а есть процедура найма. И вот как бы вот эта вся штука, мне кажется, ещё никто до конца не ответил, как она будет происходить. То есть будет ли, например, тотальная деградация, если человек, который не обладел какими-то инструментами, как люди там с десятилетним опытом, знаю, да, пятилетним, пятнадцатилетним, смогут ли они на таком же уровне делать или действительно, а вот как у меня буквально вчера с моими ребятами был разговор, когда там у меня на мой продукт сейчас на магистратуру пошёл как раз связанную с эмэлькой, и им там чувак, который занимается этим исследованиями, говорит, что в следующем году там, ну, как знаешь, вот эти все предсказатели, э всё это на нижнем уровне знать будет не нужно. Я, например, с ним спорил. Я говорил: "Слушай, ты не примешь хорошее решение, если ты этого не понимаешь, даже если ты сверху как-то систему более-менее видишь, ну, до определённого уровня". Короче, что ты обо всём этом думаешь? К чему мы идём? Что будет? Что мы знаем, что мы не знаем? Что люди говорят? >> Мм, смотри, этот вопрос очень интересный. Почему? Потому что по факту тут смешивается одновременно размышление о там операционной какой-то деятельности, тактической, стратегической, одновременно накладывается на какой-то очень интересный момент, когда мы движемся вот в сторону какой-то сингулярности, кажется, ну, по скоростью изменений, да, кажется, что куда-то приближаемся. В итоге единого ответа быть не может, потому что ты не знаешь, вот этот джай, ну, придёт, не неважно, как ты его там определяешь, да, или сверхинлект, ну, появится или нет. Ну, типа, если появится, можно просто этот ровно на на попе сидеть и дальше пронаблюдать, что будет, да, когда вот этот сверхинтелект, ну, условно говоря, ээ, появится и как он будет залаймомент с намерениями человечества в целом. Вот. И ну не закончится ли всё, как Элизад Ютковский и там его соавтор в книжке, если его кто-то постт, то мы все умрём. Да, написали, кстати, рекомендую книжку. Елизад написал ещё книжку про Гарри Поттера и методы рационального мышления. Может, вы её читали. Очень прикольная, э, книжка про рациональное мышление и для детей. Я вот своему старшему сыну покупал лет 10 назад. Вот. Но ладно. С суть в чём? То есть есть вот эта неопределённость. Представим, что ты не хочешь сидеть на попе ровно. То есть ты хочешь быть активным участником процесса. Эм, по-моему, знаешь, это примерно из той же серии, как Дикат когда-то приводил свои постулаты относительно того, почему надо верить в Бога, да, что если как бы Бог есть и ты в него веришь, ну, значит у тебя там посмертия будет хорошая. Если его нет и ты в него веришь, никаких последствий для тебя, ну, плохих не будет. Соответственно, если его нет, вот в смысле, если ты не веришь, а он есть, у тебя будут плохие последствия. Если ты не веришь и его нет, ну, как бы то опять никаких не будет. И вот по вот этой матрице решений кажется, что эффективнее верить, неважно, он есть или нет. Такое рациональное а объяснение. Или Бст Паскаль об этом говорил. Я, честно говоря, не помню, кто из французов. Наверное, надо глянуть, но суть примерно такая. Соответственно, с искусственным интеллектом и вот сверхинтеллектом, с его наступлением, схема похожа. То есть неважно, наступит он, не наступит, но лучше, наверное, действовать, да, до его прихода. Соответственно, дальше как действовать? Это хороший вопрос. И мне кажется, что если ты выбираешь персональную какую-то стратегию, то тебе нужно понимать, а за счёт чего ты вот в таком капиталистическом обществе будешь выделяться от ну на фоне остальных. И эта история как раз про там совершенную конкуренцию, опять про экономику, да? То есть если у тебя, условно говоря, твой труд как товар, он неотличим от кучи других людей, то ты попадаешь в кровавый котёл. Вот аля вот этих, например, профессий, где ишеринг экономики, где неважно кто, ну, типа, типа тебя будет вести, например, да, в Убере, >> плано дешевле, >> да? То есть у тебя, ну, конкуренция вот получается идеально. Ну, короче говоря, ты в минимальные ставки. >> Ну, комодите, да, да, да, >> да. То туда попадаешь. Соответственно, дальше возникает вопрос: а чем ты выделишься? И у тебя должен быть ответ. То есть, если это история, что ты знаешь что-то, что ты с агентом сможешь делать лучше других, это тоже может быть нормальный ответ. Ну, как бы о'кей, хорошо. Проблема со всеми нашими техническими системами, которые есть сейчас, в том, что в какой-то момент есть такая фраза, что любая проблема может решиться решаться при помощи дополнительного уровня абстракции, кроме избыточного количества этих уровней абстракции. Это одна история. А вторая история, что абстракции текут. То есть, когда что-то происходит экстренное и, ну, текущая абстракция не позволяет тебе, ну, работать на том же уровне, тебе нужно заглянуть под капот, вот вопрос: можешь ты заглянуть или нет? И текущие, например, инженеры с многолетним опытом, работая с агентами, они вот этой возможностью обладают. Например, ну, что-то случилось, агент не справился. Можно, конечно, пытаться сказать: "Попробую ещё раз и надеяться, что решится". А можно заглянуть всё-таки под капот и прочитать, что получилось, почитать ошибки, что-то подебажить самому. Соответственно, если наступит вот этот сверхинтеллект, наверное, он сам справится. Но тогда вообще непонятно, зачем мы в этом процессе. Если он не наступит, это может быть твоей точкой дифференциацией относительно других, что эти скилы тебе будут полезны. Вот. Но ты можешь пытаться дифференцироваться в сторону, ну, типа не вниз от этой абстракции, а, например, вверх. Например, ты умеешь так этой абсакцией пользоваться, что ты быстрее делаешь в два раза или круче в два раза, пока это работает. И если это не работает, ты позовёшь какого-то специалиста, который тебе поможет. И зачастую сейчас аля вот всякие люди тех же продактов, которые быстро умеют бежать со своими идеями, они проверяют эти идеи быстрее, запускают быстрее, и они просто себе находят кого-то, кто лоу, да, вот в этих возможностей закрывает им вот этот гап, и у тебя получается совмещение. Просто вам честно нужно ответить, как бы, за счёт чего вы хотите играть. И, ну, я так устроен, что на самом деле мне нравится, ну, понимать, как что-то работает под капотом. То есть у меня всегда было любопытство с детства. Я хотел понимать, как устоен мир вокруг меня. То есть мне нравились естественные науки, математика, физика, химия. Ну, почти всё мне они давались. Хуже давалось взаимодействие с людьми, потому что, ну, это такая, короче, история. меньше про нацию, больше про эмпатию и чувства. Не то, что я ничего не чувствую, скорее я хуже понимаю, да, как это работает у окружающих, в отличие, например, от моей жены, которая это делает просто чудесно, и она мне периодически объясняет на рациональном языке, что, например, с нашими детьми происходит, почему они так реагируют на что-то. Я говорю: "А теперь я понял, да, как бы всё, модель сложилась, теперь понятно, что тут делать". Но у меня такой опции, ну, не было. В итоге, ну, я хотел пдайв делать и разбираться, что происходит под капотом. И мне сейчас это помогает зачастую глубже понимать тенденции. Ну, понимаешь, да? То есть ты лучше можешь предсказывать, что дальше будет в мире, если ты видишь взаимосвязи, например, между слоями, да, например, все сейчас пытаются хадно сделать арагентные обвязки, но прикольно посмотреть, а как это связано с моделью, с инфрой, где бутылочное горлышко, короче говоря, а как агенты работают и какую они нагрузку генератной системы. Понимаешь, когда ты все эти слои видишь и примерно понимаешь, то ты понимаешь например, почему какой-нибудь псикхаднес ну так ну интересно построен и в чём там идея была? Или ты понимаешь, ну, какие-то другие вещи, и у тебя периодически, ну, я сам сижу, вот я читаю какой-нибудь новый white papпер и такой: "Блин, идея, короче говоря, 50 лет, вот, но там применённая в то время, она просто стрельнула, бомбанула, и у тебя появился там новый лидер рынка". И ты такой: "Ничего себе". Вот. Но без вот эти глубоких знаний ты это, ну, не видишь. А на уровне, например, ну, моём, ну, если мы про визионеста говорим и так далее, я должен видеть дальше, ну, типа других, чтобы что-то интересное рассказывать. Иначе как бы, ну, грех цена условному техническому топ-менеджеру, если он, ну, типа, не может предсказать, а что будет дальше. Ну, знаешь, как на шайбу смотрят, а не на то место, где шайба будет там в следующее мгновение. >> Да, прикольно. Ты, кстати, ответил на гораздо более широкий вопрос общий место, скажем, человека в этой системе. А если всё-таки говорить про найм и опять же начинающих разработчиков, у тебя есть какая-то по этому поводу мысль? >> Да, у меня есть чел целый лонгрид и там пара подкастов. То есть одна моя один мой, где я просто рассказывал свою концепцию, потом с женой обсуждали. Она такая говорит: "Саша, ты очень любишь говорить языком абстракции концепции, а мне нужны примеры". И, э, ну вот в пятницу у нас будет подкаст, где мы про джинов пообщаемся. три амига. И там как раз вот прямо вот эта тема будет разобрана. Если вкратце про меня, я считаю, что раньше процесс работы, ну, это если мы говорим про работу джунов, он был примерно таким. То есть джуны получали задачи уровня бакфиксов или простых фичей, вот, и делали их. Дальше ты мог увидеть артефакт, который они сделали, и по нему понять, ээ, люди сделали ли работу и узнали ли они в процессе что-то. Потому что, ну, если они делали сами, то они должны были что-то понять в процессе. Ну, и успешная там прогон тестов и там починка бага, например, говорили об этом хорошо. В контексте работы с агентами это уже не