Transcription
Друзья, привет. Это подкаст "Организованное программирование". Я ведущий Кирилл Макевнин. И сегодня в эфир я выхожу один.
Последние 2 недели я очень активно выступаю на конференциях, езжу на встречи с разными интересными людьми, узнаю, что происходит в компаниях, как внедряется ИИшка, что происходит с разработчиками, какие планы у бегтехов, что происходит в аутсорсе, в аутстафе и так далее. В общем, короче, пытаюсь в себя всё это впитать для того, чтобы понять, и куда нам развиваться, куда мы все развиваемся, что делать, бежать, не бежать, чем, в общем, заниматься, в конце концов.
И поэтому у меня, на самом деле, не было особо времени записывать. Я пропустил уже, получается, два видео. И это, кстати, первый раз за всю мою жизнь, что сколько вот я записываю там по 2 годика, что я говорю "всю мою жизнь". Там буквально чуть-чуть это происходит около 2 лет. Соответственно, когда подряд я не смог записать два видео. Я не уверен, получится ли на следующей неделе. В любом случае, в какой-то момент я снова войду в нормальный режим, но вот такой месяц будет немножко сбитый.
Плюс, поскольку я очень много интересного узнаю, а, и всё это вокруг конференции, то, естественно, у меня этот продолжится сейчас небольшой тренд до точно до августа, потому что буквально сегодня я снова лечу в Питер, там ещё одна конференция. После этого в Москве мы встречаемся с ребятами из разных компаний, тоже общаемся, тоже что-то будет интересное. И потом как финалочка это в Ульяновске пройдёт campмп, в который, кстати, всех приглашаю, если вы не были никогда. Это очень прикольное место, очень прикольное мероприятие, где на берегу Волги в палатках 3 дня собираются очень разные айтишники отовсюду. Раньше было очень много международных ребят, сейчас, конечно, с этим беда, но в любом случае ивент остался. Это очень классно, и там очень приятно. Очень много знакомых лиц будет на берегу Волги.
Я в целом поучаствовал в чём. Я был на Харлоуде, я был на Teamlit Conf, там были мастер-классы, доклады. Плюс я вёл такую штуку, как C Level Club, фасилитировал. Немножко расскажу про то, что там происходило. Это будет отдельная история. Плюс Олег Бунин сделал две новые штуки. Это DEFC ков, новая конференция, не очень большая, там по порядка 500 человек было, и в которой я просто такой довольно базовый доклад читал на тему агентского кодинга. А, но приятно, что был полный зал большой такой, достаточно интересно. И я иends - это когда 2 дня без остановки были оффлайновые воркшопы, там было не очень много людей, но это такой экспериментальный новый формат, в котором вот я с утра до вечера обучал людей работать с Иишкой. И это такой плотный формат. То есть по сути вот мой курс программирования Си, который мы запустили месяца три-четыре назад. И уже, кстати, на нём два потока отучилось. Вот сейчас буквально двадцать третьего числа стартует третий поток, на который, кстати, очень рекомендую записаться, если вы этого ещё не сделали. Собственно, AI Weekends - это был была штука, где я, собственно, за 2 дня его давал.
Ну, и естественно, всё, что я прошёл, всё, что изучил, всё, что видел, оно, конечно, даёт и мне самому много новой информации и понимания, которую я, соответственно, сейчас туда воткну для того, чтобы сделать наш курс ещё более насыщенным и чуть-чуть сделать его более продвинутым, потому что время, когда люди вообще полностью ничего не знали и с нуля работают с агентами, оно постепенно начинает уходить. И поэтому мы уже как бы идём от какого-то минимального уровня и дальше погружаемся в то, как выстроить всю работу очень эффективно. И это не так легко, как может показаться на первый взгляд, потому что появляется интересная для меня тема уже антипаттернов, когда вроде бы ишку все воткнули, но использовать её эффективно получается не везде.
Соответственно, сегодня в целом я хочу рассказать, наверное, о всяких интересных инсайдах направления, куда ветер дует, потому что, ну, понятное дело, не все ходят на конференции, какую-то информацию получают от своих компаний, где-то там в чатах что-то читают, но всё равно в кулуарах от разных людей можно услышать много чего интересного, что вот так вот в публичном пространстве не всегда услышь. Поэтому не переключайтесь, погнали.
[музыка]
Давайте начнём в целом, наверное, с проникновения яишки. Можно сказать так, когда м я задавал вопрос, кто пишет код полностью с помощью агентов, в реальности поднимал руку, ну, по крайней мере, на моих мероприятиях буквально до 20% человек. Говорят, в других залах ещё меньше было, потому что, наверное, там были не только яишные ребята. То есть, например, когда в целом открывалась конференция, задавали такие вопросы, там было прямо сильно меньше людей. То есть получается, что общее проникновение в реальности сильно меньше, чем мы думаем. Ну, потому что обычно многие, кто там читают мой канал, когда мы это обсуждаем, ощущение, что все в этом уже разбираются. В реальности нет.
И одна из причин, как мне кажется, она связана с тем, что всё-таки продакш код и какие-то такие серьёзные штуки, с которыми работают ребята, большинство программистов, они сосредоточены в крупных компаниях. А в крупных компаниях очень много ограничений, там очень много правил, там боятся немножко адаптировать, разбираются с понятием владения кода. То есть я знаю, что некоторые ребята, они уже в своей компании приняли решение о том, что код ничто, и мы можем использовать какие-то внешние системы, куда в лэмку оно там утекает, потому что мы там не боимся. Там главное, чтобы туда не утекало что-то связанное с, ну, там, начиная персональных данных и какими-то вещами приватными для компании, но в основном они позволяют и начинают позволять использовать какие-то внешние лмки. Но в самых таких жёстких контурах, особенно там банки, там у них довольно жёсткие запреты, и ребята пробуют, практически все компании строят свои собственные закрытые контуры, сетапят туда к вены. Сейчас GLM 52, я думаю, пойдёт. ещё какие-то модельки. И более того, многие строят поверх этого свой харнес. То есть не только, ну, MCPшки, допустим, скилы и так далее, там всем понятно надо добавлять, но я имею в виду прямо агента базового колай утилитку, через которую все работают или, например, плагин кс-коду.
При этом, понятное дело, что уровень этих ассистентов, я бы, наверное, так сказал, чтобы правильно разделять, он ниже, чем те, которые пилятся либо крупными компаниями, какой-нибудь или кодекс, или Open CД. Ну, по очевидным причинам внутри компании пилит это очень небольшое количество людей. Туда не посадят большую команду, а внешние штуки пилятся просто гигантским количеством людей. Там всё на передовой. И, соответственно, есть тенденция к тому, чтобы если пилить что-то своё, то, например, форкать. Я знаю, что Яндекс Sourcecraft так сделал. Они форкнули OpenCд и, соответственно, его дорабатывают. А с нуля это довольно безумная затея. Но, как ребята объясняли, например, в Т-банке они такое делают, они сказали, что они просто начали довольно давно, то ли они openд не видели, то ли его ещё тогда не было, и поэтому они вот сами что-то делают.
Но глобально общее впечатление всех, кто работает со всеми этими моделями и кодит у себя внутри в компаниях, оно, конечно, пока не очень. То есть они говорят, что до уровня, который мы получаем, работая с клодом, достаточно далеко. И поэтому там, где можно использовать какие-то крутые модели с ассистентами, то, конечно, стараются их использовать. Там, где выбора нет, ну, используют внутренние штуки, да, это не позволяет писать код полностью автономно. Опять же, когда мы говорим автономно, это не означает, что мы полностью забиваем на проверку кода и на всякие разные практики и другие интересные вещи, но очень много приходится направлять агента, очень много ему рассказывать, делай то, делай сё. В общем, как правильно говорили, это если отмотать на год назад, то вот примерно на таком уровне развития это находится. Но иногда кажется, что, ну, год, ну, не так уж и много, типа через год мы догоним, но в действительности там, во-первых, нелинейное догоняние, а, во-вторых, революция в агентной разработке произошла примерно в октябре, в ноябре прошлого года. Соответственно, год назад это означает, что это был когда тот момент, когда ещё Ишка не была готова и обвязка вся эта не была готова к тому, чтобы заменить разработчика с точки зрения кодинга. То есть мы не говорим про инженерию, мы говорим чисто про кодинг. Вот поэтому говорить о том, что в корпорациях сейчас можно и все начали пилить, код сам летит только в путь сам. Ну, можно, наверное, но не во всех подразделениях, не во всех местах и, ну, не во всех компаниях, на самом деле. Вот поэтому идёт такая вот большая работа, которую пытаются решить. Я знаю, что пишут очень много мпишек, пишут скилы, пытаются собрать всю информацию там со всех подразделений и дальше выстраивать процесс вокруг этого всего добра.
В общем, короче, большая сильная история. И, наверное, главное слово, которое слышится отовсюду, то, что все без остановки говорят - это AI из DLC. То есть идея примерно такая: улучшение производительности индивидуальных контрибьюторов, оно, в общем-то, ну, уже произошло. Особенно, если люди могут пользоваться внешними какими-то лмками, хорошим харнесом, то они обложились скилами, у них есть там какие-то изменения в проекте, какие-то правила НMD и так далее, и так далее, MCPшки подключили. То есть в целом как будто бы более-менее это выстроено. Опять же, это далеко ещё не у всех. Это далеко не на том уровне, на котором могло бы быть. Я в том числе это говорю, потому что, собственно, обучают сейчас непрерывно. И вижу, что даже когда у людей есть инструменты, они действительно могут неправильно или неэффективно использовать их. Но в любом случае это уже лучше, чем то, что было раньше. То есть при любом раскладе, когда мы писали просто код руками и когда у нас есть агенты. Поэтому вот эту часть компании пытаются тоже оптимизировать, но они понимают, что так рано или поздно всё произойдёт и рано или поздно разработчики как бы дойдут до какого-то уровня. Хотя, да, тоже там пытаются с этим сейчас работать на уровне менеджмента.
Больше думают сейчас скорее даже о том, чтобы внедрить AI, собственно, в процессы разработки. И самое главное, непонятно как. То есть какая-то должна быть трансформация. Пока общая идея в том, что мы не просто ускоряем процессы или там добавляем, вот сейчас популярно слово стало, триж тикетов, там тикеты сами разбираются, как-то классифицируются, что-то там немножко добавляем в кодрев, что-то немножко добавляем в сбор требований. Идёт идея такая, что, скорее всего, что-то может поменяться вообще кардинально. Какие-то роли уйдут, какие-то роли новые появятся, соответственно, мы начнём заменять людей, люди будут укрупняться. То есть, например, то, что было раньше, вот узкий специалист будет становиться широким специалистом, выполнять больше ролей. При этом, понятное дело, что тут не особо не говорят про то, какая нагрузка на человека ложится и где этот предел, он непонятен, но в целом вот та такое вот как бы укрупнение ролей и пересборка. И когда об этом идёт разговор, там всегда встаёт вопрос о том, что наша задача - определить ещё, какие процессы мы вообще уберём и какие процессы мы сделаем по-другому. То есть, если мы просто текущие процессы будем делать быстрее и эффективней, это, конечно, хорошо, но это не и нейтив, не революция, а который все мечтают.
Ответа правильного как будто бы нет. То есть нет такого, что кто-то, даже не кто-то, то есть есть люди, которые, конечно, говорят, что у них уже всё кардинально поменялось, всё работает сильно по-другому, но это пока не очень массовая история и пока непонятно реальный выхлоп. То есть нет такого, что все согласились с тем, что а вот этот вот кейс является эталонным, раскатываем будет как у всех. Ну, примерно также было, когда внедрялся, когда Джа внедрялся, это всё проходило некоторые итерации, пока в конце концов более-менее как-то не устаканилось. Многое было отброшено, многое было трансформировано, появилось реально много новых ролей. Если мы посмотрим на Devops в Аджали, если вы помните, много новых ролей, которые появились, они так и ушли. То есть там в конечном итоге, несмотря на определённые плюсы, изменения, которые произошли, и трансформацию, которая тоже была довольно дорогой, долгой, всё-таки многие вещи, они либо ушли, либо откатились, либо, ну, стали не такими актуальными. Ну, а много действительно осталось и в конечном итоге как-то трансформировалось. А вот Divops действительно как направление привёл к тому, что изначально хотели всё сделать проще и легче, но появилось много новых сложных систем, много новых ролей, новые прокладки, прослойки, но в целом это позволило делать гораздо более сложные системы и всем вырасти. И вот непонятно пока пишки, то есть к чему она приведёт. Она реально произведёт такую трансформацию или всё улучшение останется на уровне? Просто делаем то, что мы делали чуть-чуть быстрее и, может быть, где-то немножко сокращаем, упрощаем.
Всё-таки большинству хочется, наверное, верить в то, что я Иишко может трансформировать компании просто кардинально. Я, наверное, скорее отношусь к людям, которые просто наблюдают, чтобы понять, куда ветер дует, потому что Иишка уже за последние пару лет, ну, меняла много раз сознание. То есть я, например, там считал, что вот будет так, потом оказалось: "Ага, нет, не так". Или там я пишу код руками, Ишка мне помогает. Ага. Сам переключился в то, что кот пишет полностью Ишка. То есть я понимаю, что граница ещё до конца вроде бы не познаны, и пока ещё скорость изменений такая высокая, что, возможно, те вещи, которые я думаю сейчас, они поменяются. Но в целом я скорее более скептичен, чем позитивен на тему того, что глобально изменятся процессы. То есть то, что они ускорятся, то, что где-то будет происходить оптимизация и так далее. Я верю, возможно, что-то будет связанное с документацией, потому что она гораздо легче теперь пишется, обновляется самостоятельно и так далее. Это я тоже заметил. И далее, более того, я об этом скажу. Потом мы это стали сами активно использовать. Но что мы получим какой-то кардинальный прирост производительности по всему этому добру, я не очень верю, потому что узкие горлышки вообще обычно не там. Узкое горлышко часто не в написании кода. Узкое горлышко часто не в том, что разобраться с какой-то докой, а в том, что некоторый процесс, то есть чем более крупная компания, тем более сложный процесс с точки зрения внедрения, потому что там обучить людей, раскатать новые инструкции и так далее, и так далее, это всегда настолько долго, сложно и самое главное, ну, как бы довольно рукопашно, потому что там реальные люди и с ними надо работать, что это всё равно самый длинный процесс, самый долгий по сравнению со всем остальным.
С 2013 года я создаю курсы Hexlet. Сейчас мы активно двигаемся в сторону искусственного интеллекта. агентное программирование, автоматизация и лоукодинг, ll программирование. Всё это становится ключевыми направлениями в ближайшем будущем. Если вы хотите повысить собственную продуктивность, внедрить решение на базе и в работе или стартовать собственные проекты, то вы попали в правильное место. Посмотреть на конкретные программы обучения можно по ссылке в описании.
Скорее, ну, по крайне мере, как мне кажется, будет автоматизация, там, где можно автоматизировать. Мы это уже видим. Там какой-нибудь Сбер, который тебе сам звонит, с тобой разговаривает на очень крутом уровне. робот обзвоны вместо кол-центров, которые роботы делают. Причём речь не идёт обязательно о каком-то спаме, да, всякое разное бывает. И и я замечаю, что уровень этих роботов, ну, достаточно высок, что у меня нету ощущения, как будто я работаю с системой, где мне хочется как можно быстрее позвать человека. То есть вот голосовые помощники, текстовые какие-то штуки, как пример, вот2. Мне надо было паспортные данные обновить. Я зашёл в чат на сайте и думал, что сейчас как бы это какое-то время займёт. И он реально мне сказал, что мы можем это сделать прямо в чате. Я с ним поговорил, дал ему нужные данные, и он мне сказал, что он всё обновил. То есть для меня это какой-то новый опыт был. Я ещё с таким не сталкивался. Обычно это было чуть сложнее. Причём, чтобы вы понимали, в личном кабинете этого сделать было нельзя.
И вот если мы смотрим так, то да, я думаю, что с точки зрения бизнес-процессов очень много упростится, уйдут какие-то роли, уйдут какие-то направления, станет сильно меньше людей, например, там саппорт, где-то уходят ещё разные ребята разного типа. Но если говорить про AI из DLC, именно процесс разработки, то вот здесь вот пока сложно говорить. Мне не очень в это верится, что там произойдут какие-то очень кардинальные изменения, но я скорее отношусь к этому так, что не против того, что говорят другие, а скорей, и мне интересно посмотреть, потому что конкретно Хекслет это касается в меньшей степени. Мы всё-таки маленькая компания, там, да, там нам даже до среднего бизнеса далеко не то что до Бегтеха, и поэтому мы со стороны смотрим. Но, естественно, с точки зрения контекст сбора контекста знаний и так далее, у нас много чего меняется. То есть там и клод, который в слаг добавленный автоматически там может тикеты-то создавать сбор контекста МCшки, общее взаимодействие. То есть вот эта штука, она нарастает, но она, скажем, опять же, не меняет прямо кардинально текущие процессы, она скорее их делает просто гораздо более простыми и эффективными.
Что будет дальше, мы, конечно, посмотрим, потому что туда надо вовлекать больше людей, потому что компании не ограничиваются только разработкой, правильно? У нас там есть маркетологи, у нас есть дизайнеры, у нас есть много кого ещё. Они тоже во всё это должны быть вовлечены. И в каком-то смысле это позволяет делать м очень много кросс каких-то вещей, да, упрощая коммуникацию. В общем, постепенно постепенно движемся в эту сторону.
Из интересного все компании практически заявили такую вещь, что повышение производительности они хотят сократить до 30% персонала. Я, кстати, сейчас, наверное, не очень помню, речь шла вообще о персонале или конкретно о технической его части. Что-то я подзабыл этот вопрос. Но я понимаю, что это звучит и страшно, и мы как бы попадаем в такую ситуацию, когда сначала к остановке найма и вообще к проблемам начало приводить экономические проблемы, а после этого подключилась иишка. То есть, если кто думает, что раньше увольняли изишки, это было неправда. Вот изишки начинают увольнять сейчас. И действительно, этот процесс происходит, потому что очень многие понимают, что они могут сделать и делают внутри. Плюс становится понятно, что, ну, не нужно пока расти. То есть мы как минимум можем закрывать огромное количество вещей без найма дополнительных разработчиков. Нет, правда, Хекс, кстати, тоже в это попал. У нас был момент, когда мы уменьшались, так же, как и все, сушились для того, чтобы продолжать жить. И когда мы понимали, что вот по определённым направлениям нам нужны люди, в этот момент развивалась ишка, и стало понятно, что мы можем это закрывать, по крайней мере, сейчас без необходимости найма.
Потом, а как это всегда и происходит в таких ситуациях, если производительность труда в целом выросла, то количество, во-первых, компаний растёт, которые которым легче войти и начать заниматься тем, чем они раньше не могли заниматься, то есть увеличится общее количество. А во-вторых, произойдёт унификация. То есть все, когда дойдут до точки, что они все повысили свою производительность, получается, что вы как бы не быстрее остальных, да, конкретно вы работаете эффективнее, делаете быстрее. Но то же самое произошло у соседей. И получается, что мы все снова оказались на одном уровне. И это, знаете, на что похоже? Когда там появились компиляторы, мы с Ассемлера на языки высокого уровня перешли, когда появились вообще в целом персональные компьютеры, когда Excel появился. Можно там бесконечно говорить, когда интернет появился. И вот всё в целом м в какой-то момент всех уравнивало и нужен был новый толчок. А когда все становятся в позицию, что они находятся на одном уровне, то единственный способ как бы расти в иишной среде, вот в смысле нашей технической среде - это, собственно, найм. И опять начнётся найм. Ну, конечно, это должно совпасть ещё и с экономическим ростом. А понятное дело, есть много критериев, из-за которых это пока невозможно. Там очень много зависит от того, когда всё успокоится, все помирятся и начнётся какое-то движение вперёд. Но наблюдаем и смотрим. А без этого, конечно, все будут, э, сидеть в режиме, смотрим, что произойдёт. Боятся найма, никого не брать и смотреть на происходящее.
Вот отдельно был смешной разговор у меня с девопсами. Мы стояли в AI GTI Деконф, и Divпс, значит, говорит, что начал злиться и ругаться на разработчиков, потому что подключили МCшки к разным инфраструктурным сервисам. То есть, например, ко всем облакам есть МCPшка, через которую можно делать всё, что угодно. Кубу есть МCшка, которая тоже позволяет делать всё, что угодно. Короче, ко всей инфраструктуре появилась МCшка, которая позволяет сделать всё, что угодно. И угадайте, что началось? разработчики там, где им дали этот доступ, там, где он появился, начали вместо того, чтобы работать правильно через тероформы, через хлмчарты, ну и так далее, то есть всё, что описывается кодом, они вместо этого начали давать команды напрямую из серии сделай раз, сделай два, сделай три, и девопсира схватились за голову, потому что это приведёт к катастрофе. Это мало чем отличается от того, чтобы пойти просто там в интерфейсе это потыкать. Ну, то есть тыкать теперь не надо, можно просто говорить словами, но это очень невоспроизводимая штука. То есть на выходе, если так сделать, мы можем, во-первых, легко убить систему, мы можем получить неконсистентность, и в конечном итоге это не отражается нигде. То есть как потом это повторить и что из этого сделать? То есть можно, конечно, там придумать потом концепт, что то, что проходит через МCпишку, оно как-то оставляет артефакты и так далее, но как будто бы всё равно это какой-то хаос получается. И девопсы из этого немножко напрягаются, говорят: "Не, ребят, ничего такого делать не будем". Ну, посмотрим. И в этом смысле скорее эти средства, они позволяют больше вытаскивать какую-то информацию. То есть для того, чтобы посмотреть, что там происходит, поанализировать, не знаю, логи, просто увидеть общее состояние, но не для того, чтобы производить какие-то действия. Возможно, как-то это будет изменено, но мне в это, честно говоря, пока сильно не верится. Плюс вот этот риск просто одной неверной командой всё сломать, это довольно страшная штука. И я так понимаю, никто ещё ничего с этим не придумал. Поэтому, скорее всего, всё это закончится тем, что у всех подбирают эти доступы. Ну а те, кто у себя локально сами всё это делают, наткнутся на то, что в какой-то момент Ишка просто грохнет продакшн-базу или что-нибудь в этом духе, и люди скажут: "Нет, всё хорош, начинаем работать по старинке".
На одной из конференций там выступал Кирилл Миньшов, вице-президент в Сбере, и он как раз отвечает за многие такие трансформации и всё, что связано с Ишкой и с командами. И он, мм, рассказывал довольно прикольно, как они собираются там трансформироваться, кем они собираются стать и какие у них там препятствия на пути. И вот он рассказал такую историю, что у них есть некоторые команды, которые стали 10X по производительности, но их единицы, и куча команд, которые такими не стали. И они, соответственно, думают о том, что надо сделать, как это изменить, для того чтобы как можно больше команд уходило в эту часть, чтобы они становились гораздо более эффективными и производительными.
Хотите расти как разработчик не в одиночку, а вместе с сильным сообществом? Вступайте и в Hexet Клуб. Это закрытое пространство для тех, кто уже в профессии хочет развиваться дальше. Здесь помогают определить уровень, построить персональный план развития и дают обратную связь менторы из индустрии, в том [музыка] числе из зарубежных компаний. В клубе живые разговоры о технологиях, собеседованиях, работе в компаниях, карьерном росте и нетворке. Есть отдельные топики с историями участников, отзывами о работодателях, отчётами менторов и планами развития. Люди приходят в клуб, чтобы расти, и помогают другим делать то же самое.
Отдельное мероприятие, которое я делал нам Конфе, называлось Ca Level Club. Что-то там, по-моему, внедрение яишки. Это, короче, такая штука, когда собираются ребята из силового клуба, это Вонтика, концепт некий людей уровня ледов, которые вместе решают совместно какие-то вырабатывают идеи и решают какие-то задачи. Вот меня пригласили там поучаствовать, соответственно, и провести некое групповое мероприятие. Ну, это довольно прикольный формат, то есть там все делятся, строят какие-то тезисы, потом, собственно, докладываются каждый на какую-то тему, которую он выбрал. И тематика была, соответственно, внедрение Ишки. Ну, это как бы моя задача была придумать некие направления, которые ребята будут обсуждать, где будут сложности, там, начиная от того, что надо использовать локальные модели, это раскатка на всю компанию, это критерии приёмки, это сложности при стандартизации, что дать разработчикам, что использовать самим. Spec Driven Development и другие разные страшные слова, которые сейчас всё чаще звучат. И, соответственно, ребята делились на группы. Там было, по-моему, по пять-смь, иногда даже девять человек, которые стояли около флипчартов и, соответственно, спорили о
какой-то проблеме, как вот которую они выбрали, потому что из всех этих направлений там каждый разбирал только свою часть, примерно 40-45 минут это продолжалось. И споры были довольно жаркими. То есть это прикольно, когда ты людей разводишь и в принципе особо участвовать не надо, потому что они там друг с другом прямо там сцепляются только в путь, что менять, что хорошо, что плохо.
И у нас даже был такой прикол, что одна команда в процессе расщепилась на две, потому что они слишком сильно нашли много противоречий, и им было комфортнее, если они будут работать ещё в более мелких командах, в которых там люди примерно, ну, может, и не одного взгляда, но когда нет какого-то такого сильного сопротивления.
И дальше мы как бы слушали то, что они говорят на каждый вопрос. Значит, что там было? Первое, по поводу приёмки, по поводу того, чтобы даже не приёмки, а оценки результатов, да, какой критерий использовать. Вот немало команд выбрала критерий деньги в духе, что вот мы что-то разрабатываем и, соответственно, это как как-то влияет на деньги. Я честно скажу, что прямо сильно не согласен с таким форматом, несмотря на то, что всем хочется думать, что разработка сильно влияет на деньги, что ты что-то меняешь, и от этого зависят деньги. Более того, я вам скажу так, руководители и владельцы бизнесов с большим удовольствием разработчиков посадили на такие KPI, когда есть деньги, но разработчики сразу же первые сольются и скажут: "Идите-ка вы". Потому что нет такой связи. То есть вот у продавцов есть такая связь, у маркетологов есть такая связь. И там действительно KPI денежные, они работают вот в этой системе координат. У разработчиков всё по-другому, потому что продажи почти всегда зависят не от фич. Более того, они по времени могут сильно не совпадать с фичами, с релизом и с другими вещами. И нет никакой прямой корреляции между тем, что мы лучше поработали, сделали больше фич и пропорционально этому компания больше заработала. Компания может заработать на том, что финансовый директор что-то там сократил или оптимизировал, и это будут такие деньги, с которыми ни одна фича сравнится. Компания может заработать, потому что фаундер заключил какой-то мегаконтракт на миллионы долларов, десятки миллионов долларов там с какой-то компанией, да, и это прямо сильно поменяло всю экономику. Внешние обстоятельства, растущий, падающий рынок. То есть, если, например, мы делаем классной фичи в продукте, который умирает на умирающем рынке, ну, представьте, вот до сих пор был бы DVD, да, DVD рынок падает, мы набрали классную команду, делаем лучший сервис по сдаче DVD в аренду. И какие бы тут были деньги от того, что мы делаем фичи? Ну, честно говоря, никаких. Поэтому денежная история, она, ну, не очень катит на то, чтобы говорить о внедрении. И, наверное, для кого-то внутри компании с точки зрения сокращения фото это будет действительно так. Но это всё-таки будет не прерогатива разработчика в первую очередь. То есть какие-то лиды уже, наверное, будут об этом думать. Ну, в общем-то, Фот в эту сторону, да. Но радует ли это девелоперов? Ну, не очень, потому что в конечном итоге это приводит к сокращению персонала.
Другая идея, которую предложил Сбер, ну, понятно, что Сбер не единственный, просто вот они вот на сцене про это говорили, это стористос, то есть когда есть какая-то задачка разного рода и, собственно, сколько мы их выкатываем в продакшн, уже вот всё вот прямо выкатили и сделали изменения. И объём вот этих старей они хотят считать. Мне кажется, это наиболее правдоподобная вещь, потому что в конечном итоге за экономические вещи отвечают продакты и там ребята выше, а всё-таки от технических команд ждут релизов с той скоростью, с которой нужно. И чем быстрее, тем лучше. А причём здесь очень важно именно вот полный пайплайн, потому что мы говорим про time to market, а не про количество кода, которое генерит конкретный один разработчик. А то вот эти все разговоры на тему того, что мы стали делать больше кода в больше 10 раз, допустим, да, это вот Миньшов тоже про это говорил. Некоторые команды делают кодо в 10x раз больше. Не надо поддаваться м соблазну, экстраполировать это на эффективность компании. Почему? Потому что ну а что они делают в 10 раз больше кода? О'кей. Но если в принципе уже и до этого ревью тормозило и на ревью невозможно было как бы протащить дальше, потому что и раньше, помните, была история, что да, и сейчас есть, когда куча полуреквестов, соответственно, скорость, которую мы их проверяем, она конечная. И в принципе все и так уже упирались в то, что, ну, не успевают вовремя и быстро как бы всё это проверять, а сейчас стало ещё хуже. Поэтому получается, кода-то может в 10 раз больше, только нагрузки ещё потом больше. А потом это всё не просто нагрузки больше, ещё хуже становится, потому что люди, которые это непрерывно проверяют, они выключаются как бы из своей работы. Ну, короче, там получается такая засада, что бутылочное горлышко переместилось. Да, действительно, кодинг в этом плане становится менее большой проблемой, да, он и в принципе всегда был, на самом деле, не самой большой проблемой. И дальше возникает проблема, а что делать дальше? Поэтому, собственно, возникают идеи, что, может быть, ревью как процесс надо вообще кардинально смотреть на него по-другому и вообще всё перестраивать, потому что если мы просто будем пытаться оптимизировать, ну, ничего хорошего не получится, да? Есть какие-то попытки делать ревью полуавтоматическим, но опять же, кто проверит, что пошло всё правильно. Поэтому, как правило, ревю даже находит какие-то, ну, скажем так, типовые ошибки. Но проверить соответствие правилам тому, как будет вести себя система, что будет происходить в корнеркейсах различных, это такая штука, которая даже если Ишка что-то подскажет, всё равно это надо руками посмотреть и убедиться то, что после диплоя ничего страшного не произойдёт. По этому поводу, кстати, сказали некоторые платформенные команды. Там были ребята, которые делают там видео для ВК, например, да, у них там они говорят: "У нас там экзобайты просто данных, и там всё очень аккуратненько". То есть они, конечно, Ишку как-то используют, но такого, что он там за них код пишет, нет, потому что там ошибки очень дорого стоят и просто так фигарить никто не позволяет. Короче, вот эта вот история с проверкой производительности и эффективности довольно сложная. Я думаю, что сейчас многие будут пытаться вводить какие-то критерии, которые могут на самом деле сделать хуже, начиная там от потребления количества токенов. Там и такие, кстати, идеи были, но слава богу, в основном все от этого отказывались. Более того, мы сошлись на такой мысли и её высказывали в разных местах, о том, что потребление большое токенов конкретными людьми - это, ну, не то, что антипатор, но это, как правило, говорит о том, что человек неэффективно использует ишку. И, в принципе, многие отмечают, что это так и есть, и с этим надо что-то делать. Но с другой стороны, одновременно с этим ребята из Бера сказали интерес мысли, которую я почему-то заранее не думал. Это довольно даленовидно. Они сказали: "Мы действительно знаем, что очень многие используют неэффективно, но на этапе обучения мы так и хотим". То есть мы не хотим ставить ограничения до того, как они научатся. Поэтому мы сейчас всех провоцируем на то, чтобы использовали хоть как-то, просто лишь бы вкатывались в это быстрее. А потом со временем начнём пытаться тех, кто там больше всего тратит, конкретно с ними работать, обучать для того, чтобы они эффективнее работали и, соответственно, такого не происходило. И по мне, это довольно умная стратегия, потому что действительно зачем заранее говорить человеку, что вообще ничего тратить не надо, когда он только-только с этим столкнулся и ещё пытается вообще разобраться. Так что вот такое вот токино потребительство даже приветствуется пока, но не как KPI эффективности, а как скорее механика и метод обучения для того, чтобы люди не боялись, не стеснялись и больше экспериментировали. Это правда. Действительно, если ставить начать ограничения, будет беда.
Большая часть была посвящена новым ролям и уровням зрелости. Соответственно, есть уже попытки разложить компании на уровне зрелости интеграции и в свой пайплайн, и вообще изации как бы глобально. Пока мне честно кажется, что это достаточно сложно сказать, насколько это будет так или не так. То есть понятно, что такие попытки нужны, они важны. Можно увидеть примерно, что туда ребята любят включать, хотят включать и что считается хорошим, что считается плохим. Но пока это на уровне типа вот мы используем просто агентов, мы используем просто чат, мы, значит, подключили там какие-то МCшки, у нас там работают общий какой-то контекст, знания, перестроенные процессы, ну, и где-то там на вершине, что мы всё делаем через Spect Driven Development, у нас всё очень классно там вместе собирается, генерируются документы, перепроверяются. Вот такой вот какой-то некий эпичный пайплайн, в котором вплоть до того, что участвует не только вот техническая часть, а, например, мы туда и дизайнеров включили, и те включили, они тоже спеки пишут и так далее. [откашливается] Ну и ребята как бы отчитываются, что у них это уже всё работает. При этом одновременно с этим говорят, что это невероятно, естественно, сложно всех научить, всех заставить идти по этому пути и перестать вот как-то по-колхозному что-то делать. Будет интересно посмотреть, насколько это действительно сработает. Но мне кажется, всё равно это будет ещё трансформироваться. Слишком рано говорить о том, что мы вот считаем, что вот это только правильный путь. То есть вполне возможно сейчас в течение ещё месяца-двух всё поменяется.
А вот и там пытаются найти решение такого уровня, на что мы завязываемся с точки зрения скилов, каких-то подходов или способов описания проектов и задач. Например, там есть Open Spec, который определяет то, как мы фактически храним MD-файлы, да, в которых чейнджи, в которых контекст, там домен, адрки какие-нибудь, пидишки и так далее. Вот это вот всё вместе формируют некую и базу знаний, и базу изменений, и требования, которые предъявляются к проекту, и инварианты различные, бизнес-логика и всё остальное. Я в этом плане сейчас скажу так, когда на на это я смотрел ещё буквально пару-тройку месяцев назад, мне казалось, что это слишком сложно. Ну то есть это прямо вообще мы опять возвращаемся в мир, в котором вот это долго пишется документация, она всегда отстаёт. Там очень много правил. Читать это почти нереально. И так далее, и так далее. Пока я не начал использовать скилы мата, который сделал Грилm. Я думаю, многие из вас знают. Если не знают, обязательно посмотрите. Это очень, очень крутая штука, которая, кстати, во многом похожа на Open SPC и подходы, которые пытаются использовать у себя в компаниях ребята. И более того, они пытаются их как бы оптимизировать. То, что сделал мат - это набор таких скилов, которые позволяют это делать уже фактически оперируя, точнее, опираясь на международный очень крутой опыт, потому что там скилы, которым над которыми работают какие-то безумное количество людей, у него в репозитории, по-моему, 160 уже тысяч старов, видно, сколько тамрквестов, форков, и он достаточно активно сейчас там идёт во всех подкастах, участвует, про всё рассказывает. Короче, видно, что у чувака попёрло, люди это используют. И если посмотреть там список компаний, где они применяются, он, конечно, уже достаточно большой и там серьёзный компании. И вот я какой-то время назад, это буквально месяц назад, я начал использовать у себя, причём не просто там грилми какой-нибудь и ещё скилы прикольные, которые позволяют эффективнее работать. Я начал использовать те скилы, которые по сути формируют документацию и описание проекта, которое потом уже используется при разработке. И мне очень понравилось то, что фактически система, которую он построил и как она работает, там вникать особо в это не нужно. Точнее, даже так. Фактически всё идёт на том, что система постоянно вас опрашивает и на базе этого делает какие-то изменения. То есть вникать не нужно с точки зрения того, что вот мы сидим и пишем эти спеки или сидим, их перепроверяем. То есть эта фигня постоянно сама их перепроверяет на основе того, что мы обсуждаем, на основе того, что уточняется в каждой сессии, во время каждой сессии, после каждой сессии это всё записывается. И в итоге проект начинает обрастать не только какими-то вещами, которые в самом коде есть, там типы или спеки, ну, я имею в виду Open API, например, спека по опишке, а начинает уже обрастать прямо хорошими правилами того, как работает сама система. Причём не там просто один какой-то мдшник и файл, а такая прикольная структура с кучей разных файлов по разным значениям. То есть, например, я никогда раньше не писал о дрки, которые во многих биктехах считаются вообще стандартом, и он мне их начал сейчас генерировать активно, и мы начали активно их пополнять. И это оказалось довольно прикольно, когда это происходит в автоматическом режиме. И не надо никого заставлять, соответственно, этим заниматься. Поэтому, несмотря на то, что у меня достаточно микроскопическая команда и проект по меркам вот этих вот больших ребят, вот эти процессы, которые раньше были слишком сложными для нас и слишком замудрёнными, и мы бы просто утонули, нам проще пообщаться, проще как-то самим что-то порешать, мы начали это использовать. У нас стала пополняться вот эта база знаний, я бы сказал, а, требований, и Иишка стала её автоматически использовать. И получается, мы в каком-то смысле практически на халяву это получили, потому что один фиг, когда мы в любой сессии с агентом обсуждаем разные задачики, то почему бы не использовать то, что мы там говорим? Потому что мы из раза в раз там повторяем, как надо делать, да, понятно, что-то приезжает в AgenceMD, а как-то меняется сам проект, то есть в конечном итоге оно постепенно постепенно улучшается. Но если включить вот такой режим, а там этот режим прямо в скилы зашит, то мы ещё и на халяву получаем, в общем-то, гораздо больше выхлопа, чем если бы работали в обычном режиме. Так что я от скептика Spect Driven Development постепенно двигаюсь в сторону adepta Spect Driven Development, но в определённом подходе, да, то, что как минимум все эти доки получаются из автоматических разговоров, из сессий, которые у нас происходят, а не потому, что мы сидим там, их вычитываем, потому что читать это всё, это будет слишком сложно, тяжело и долго. Я думаю, любой человек после того, как один-два экрана текста такого почитает, ему будет очень плохо. Слишком размываться начинает всё в глазах, когда ты это видишь. Вот. Так что это очень прикольная история. Я уверен, что здесь ещё много будет трансформации происходить. И пока я понимаю, что мы ещё сами очень мало описали. Будет видно, когда больше разных доменов, поддоменов нашего проекта туда войдёт. Будет ли проблема от объёма, как часто оно будет сбоить, будет лишка тупить. В общем, это большой вопрос, пока без ответа. А мы, кстати, это используем ещё и в открытых проектах, так что я могу потом приложить ссылочку, можно посмотреть, как это выглядит. Но пока мне очень нравится. Короче, эта система работает прикольно. Ну и тем более понятно, что если я это загомитил, это получают мои коллеги. И в свою очередь то же самое наоборот. Работает классно.
YouTube не единственное место, где можно получить пользу от организованного программирования. Также я пишу про обучение, разработку и технологическое предпринимательство у [музыка] себя в Telegram-канале и ВКонтакте. Там я публикую бережно написанные руками посты пару раз в неделю. Только мой личный опыт без новостей, без кликбейта и нейрослопа. Будьте организованы, подпишитесь, [музыка] ссылка в описании.
Ну и, наверное, последнюю штуку, которую я скажу. Вот проводя мастер-классы, воркшопы, работая с ребятами, я постоянно сам как бы обогащаюсь и постоянно рассказываю не только про свой опыт, но и то, что мы там вот изучаем мы в процессе. И каждый раз, когда это всё заканчивается, ко мне подходят люди потом, а, и говорят, что там они уже знают, что там было новое, интересное, то в целом выкристаллизовывается такая картинка. Значит, какие вещи люди узнают? Помимо того, что понятно, что про MCP там и про агентов уже в целом более-менее все знают и про скилы, но всё-таки какие вещи они узнают. Первая, наверное, история - это то, что сейчас вот в 2026 году началось. Это называется skillх help, то есть создаётся гигантское количество скилов внутри компании, какие-то свои скилы. И по большому счёту никто это не переиспользует, потому что проверять, что там написано, насколько оно подходит под твой проект - это ещё целый геморрой. И получается, что большинство скилов, которые люди пишут с целью, чтобы остальные в компании начали их использовать, это практически не прокатывает. И происходит проблема, что каждый что-то там делает своё, все это выкатывают. Дальше вы начинаете искать скилы общие или, допустим, у вас в компании получается, что на одну и ту же проблему там какое-то безумное количество. И вы такие: "Блин, во всём этом разбираться проще поставить что-то себе". И мы обсуждали, я всем рассказывал, объяснял, что крутой проект, правильно сделанный подишку и настроенный вот в этот агентное программирование, он не развивается по принципу, что мы его весь облепили скилами, какими-то описаниями, а мы как бы понимаем, что умеет и знает Лэмка, и на что её учили, в чём она лучше разбирается, и смотрим, а можно ли поменять сам проект таким образом, чтобы не нужно было описывать, а как бы для лмки было нативно делать какие-то действия, которые она знает, как делать, и проект этому соответствует. И вот эта идея, как оказалось, не очень очевидно и понятная была всем. И ко мне как бы люди потом подходили, говорили: "Спасибо за неё". То есть я там рассказывал даже о нескольких паттернах того, как выявлять, что Лэлмка вообще хочет увидеть, как она хочет работать, что в проекте не так и что нам нужно менять. И ребята многие отмечали такую прикольную штуку. Они говорили, что в современном мире разрабатывать кастомные решения слишком дорого. То есть это как раз мы возвращаемся к тому, что Ишка практически их не понимает, не умеет ими пользоваться и, соответственно, надо прилагать гораздо больше усилий. Кто-то, конечно, скажет, что, ну, а если мы это всё опишем, даже если мы всё это опишем, она на этом не училась, она всё равно не выдаст хороший результат. Поэтому, если мы можем выкинуть какой-то костом, используя стандартное решение, будет гораздо лучше. Это, кстати, немного противоречит идее многих программистов, что раз Ишка может написать вообще любой код, значит, мы просто можем выкинуть все библиотеки, абстракции, фреймворки и так далее и фигачить [откашливается] всё сами. Можем, иногда надо, иногда это удобней, но в целом, если есть какие-то стандартные решения, крупные, продуманные и так далее, написать своё такое же будет, во-первых, дороже, во-вторых, потом это поддерживать всё равно. И яишки гораздо больше нужно будет знать, чтобы принимать какие-то правильные решения, потому что ей недостаточно будет пользоваться только интерфейсом. Плюс опять же нужна дока и так далее, и так далее. То есть, несмотря на то, что всё это можно делать, это сильно увеличивает засорение контекста и постоянное отвлечение от того, что нужно перерабатывать очень много кода, которые мы понаписали сами. То есть как бы происходит такой практически экспоненциальный рост кодовой базы, с которым, честно говоря, в какой-то момент ишки станет просто тупо сложнее работать. Поэтому всё-таки, несмотря на все её возможности, желательно не доводить проект до такого, что он будет просто гигантский по размерам, потому что мы понаписали всё сами. к этому нету нормальной доки или есть, но, естественно, там какие-то баги, которые надо потом долго, довольно выгребать. Так что такая проблема существует. И в общем, мы говорили о том, как разговаривать с Ишкой для того, чтобы понять, правильно вы всё делаете, как менять проект так, чтобы Иишка лучше его понимала. И в конечном итоге хороший проект. Во-первых, его нельзя описать сразу, как некоторые думают, что можно сесть, потратить 2-3 дня, мы сделали офигенное описание и потом работаем. Это, во-первых, долгий процесс. Он как раз строится на том, что мы, работая с ишкой, пытаемся понять, где она постоянно тупит и почему она делает какие-то вещи неправильно. И вместо того, чтобы сразу ей говорить, надо вот в AgenceMD, допустим, или ещё в каком-то скиле где-то написать ей, как надо поступать, смотрим, а может быть проблема в том, что у нас в проекте используются неправильно какие-то понятия, что-то устарело, есть какие-то неточности, например, какие-то понятия используются в совершенно разных контекстах. Как вот пример. У Хекслета есть такая проблема. У нас то, что называлось раньше словом курс, теперь называется другим словом. Курсом называется ещё что-то третье. Причём в UI это отличается в админке и в интерфейсе для пользователей. Соответственно, Ишка, конечно, от этого и крышу сносит. Она не очень понимает, что происходит. И в данном случае мы, к сожалению, там где-то, где можно поменять, мы меняем это, к счастью, а где не можем поменять, нам приходится прямо это описывать. Но, по крайней мере, после этого он начинает понимать, о чём идёт речь. Потому что один разработчик может использовать иногда плюс-минус свой смещённый панетийный аппарат, другой другой. Только из-за того, что вот произошло такой legacси трансформация, через которую мы прошли. Ну а в тех местах, где понятие правильное, не соответствуют общим названиям и признакам, это очень хорошо. У нас тоже вот такой пример могу привести на уровне понятий. У нас есть такое понятие, как курсме, что означает на самом деле не человека, а именно участника курса. И с точки зрения английского языка более правильное слово является enrollment. И пока мы не закрепили в нашем словаре терминов и понятий то, что это является на самом деле вступлением в курс, он периодически тупил и спрашивал: "Это такой: "А это не человек". То есть мембр - это не человек, это вот эта штука. И было видно, что надо это менять. То есть, конечно, по-хорошему бы переименовать даже модельку и сделать так, чтобы он очевидным образом это понимал. Но это не всегда возможно. Хотя некоторые вещи действительно мы стараемся переименовывать. И вот за этот год, например, мы сделали огромное количество рефакторингов, которые как раз привели к тому, что мы синхронизировались с ишкой по панетийному аппарату, по каким-то техникам, по вещам, используемым внутри, для того, чтобы она лучше понимала, с чем она работает, и у неё как бы не вызывало лишних вопросов. Поэтому, например, когда мы говорим про там Хекселет, он не обвешен миллиардами скилов, и наоборот мы стараемся как бы их количество, в общем-то, сильно минимизировать. Вот такая вот штука. И буквально, кстати, это уже вот было недавно. Я написал пост в телегу, и мне кто-то в комментариях сказал, что уже есть такая прикольная фигня с библиотечка, которая делает следующее. Она смотрит зависимости в ваших исходниках и по этим зависимостям смотрит, а есть ли в исходниках библиотек скилы, которые она может использовать, потому что сейчас мир уже так устроен, что практически все производители разных тулов, фреймворков добавляют скилы, чтобы разработчикам легче было писать код. И, естественно, это требует как бы времени, чтобы всё это найти, с этим разобраться. Представьте, что теперь это можно автоматизировать и, соответственно, собирать это всё у себя и таким образом сразу как бы улучшать проект, чтобы он знал, как, например, пользоваться той или иной библиотечкой. Конкретно та штука, которую мне показали, она только Python умеет и ноду. И то, честно говоря, не всё, потому что не всегда скилы хранятся внутри. То есть я вижу, что здесь ещё большой потенциал, и это будет улучшать. То есть ли надо всё это унифицировать, то ли надо постоянно это опрашивать, но, короче, будет какая-то штука, которая позволит всё это собирать и эффективно использовать. И таким образом, по крайней мере, часть скилов нам не придётся писать, потому что они будут идти от производителей тех инструментов, которыми мы пользуемся. Хотя есть, конечно, тоже нюанс, потому что, например, у нас есть некоторые подходы, которые, ну, скажем так, могут расходиться с официальной линии партии какого-то фреймворка. Просто потому что вот есть причины, почему бывает люди пишут код по-разному, там, в зависимости от многих факторов. И мы как бы с одной стороны видим, что у них есть вот эти рекомендации, а с другой стороны понимаем, что только часть из них нам подходит, другие не подходят. И поэтому в данном случае, конечно, бывает такое, что нам приходится отказываться от официальных скилов и использовать что-то кастомное. Но опять же повторюсь, в целом у нас их не очень много, потому что мы стараемся писать код, который, скажем, соответствует тому, как Лэмка думает, и в действительности использовать много генерации. Потому что, несмотря на то, что Лэмка может написать всё сама, но ничего лучше генераторов не придумывали для тех вещей, которые являются, ну, плюс-минус автоматическими. Например, какой-нибудь Open API генератор может вам сделать не только дтошки, но и целые хендлеры фактически подготовить, в которых только останется там написать вызовы. И таким образом вы просто тонны кода генерируете всегда предсказуемым образом. И не надо про это, в общем-то, особо думать и поручать ишки. Единственное, чему ишку надо научить, это, соответственно, что та часть кода, которая у вас генерируется, её не надо мм править ручками. Это реально может делать, и такое иногда бывает. Поэтому это одна из задач как бы при описании GSFD объяснить ей, что вот этот код мы правим. Есть такая-то цепочка генераторов, когда исходник поправили, на базе этого сгенерили, потом, соответственно, уже дописали необходимый код. Это тоже часть обучения ишки, того, как пользоваться вашим проектом, которые вот со временем как-то выкристаллизовывается и через какое-то время при правильном подходе станет видно, что проект можно править практически без необходимости править и направлять яишку. И скорее, даже если она где-то будет тупить, это будет уже выглядеть скорее как а исключение из правил, а не стандартное поведение, как до сих пор пока ещё есть, потому что не все эффективно умеют ей пользоваться. Но в целом, наверное, радостная лично для меня новость. Несмотря на то, что я столько лет как бы здесь не был, с людьми не общался и жил в немножко в собственном соку. Мне было чуть-чуть страшно, что где-то я там сильно отстал, что-то забыл и, может быть, вообще всё не так, как я себе представлял. К счастью, оказалось, что с точки зрения, как внедрять яишку в именно непосредственно в разработку, я достаточно неплохо разбираюсь. очень многим ребятам помог, очень многие говорили: "Потом спасибо". И даже у меня есть уже несколько предложений попасть, сходить к внутрь компании уже поработать с их командами, чему-то их обучить, потому что скепсис есть, и у многих ребят есть ощущение, что, в общем-то, это неэффективно. Ну, опять же, в том числе, потому что многие, когда начинали или пробовали что-то, они это делали достаточно давно, ещё со слабыми моделями, и как бы у них остались какие-то паттерны поведения или впечатления, что вот оно примерно так же сейчас работает. И действительно нужно не только там просто обновлять модели, но и, соответственно, менять свой подход. Вот, наверное, самый такой яркий был случай, когда мы работали в группе и, э, соответственно, несколько ребят сделали следующее. Они модельки вместо того, чтобы с ней разговаривать открытым вопросом, задавать вопросы, они начали писать прямо сразу, какие сущности, как надо связать и как сделать. И я объяснял, что в чем более современной модели, тем меньше этим надо заниматься. как бы вы к этому всё равно придёте, но через взаимодействие с Иишкой, через разговоры с ней, потому что скорее ей надо объяснить как бы суть задачи, но не говорить, как её решать, потому что очень вероятно она предложит вам лучшее решение, опишет плюсы, минусы и, по крайней мере, вы останетесь открыты к каким-то новым возможностям. Если вы будете говорить ей, что и как делать, вы никогда не сделаете лучше, чем есть ваше личное понимание проекта. А, мягко говоря, мы не эксперты во всём. Мир движется вперёд. Очень легко может быть такое, что когда мы думаем о какой-то штуке, уже есть гораздо более лучшее, эффективное, стандартное решение в том стеке, который мы выбрали, и Ишка сможет его предложить. Поэтому лучше работать в этом плане в открытом режиме. На этом, пожалуй, всё. Жду вас в ноукэмпе. Приходите ко мне на программирование с Иишкой. И до новых встреч на канале в ближайшее время пока всё ещё я, видимо, буду записывать сам, но через какое-то время уже снова начну приглашать гостей, и мы вернёмся в стандартный и привычный режим. Всем пока. [музыка] เฮ [музыка]