youtube-transcript-apiКоллеги, слушайте, ну что, у нас настолько разные сегодня доклады, я с большим интересом жду, что будет дальше. Вот мы идём по нашей программе. Следующий у нас Самат Галимов. Самат, ты очень рад тебя снова видеть. Вот потому что, да, уже уже второй раз, по-моему, в нашем эфире. И здорово, с большой благодарностью, что нашёл снова время к нам заглянуть. А-э, давай про то, нужен ли на самом деле технический директор в нашу текущую эпоху или нет. Э-э, передаю тебе слово, врывайся. >> Спасибо большое, Саша. Спасибо, что пригласили. И я хотел бы, э, во-первых, вопросы вы можете сразу писать в процессе, но я, к сожалению, вряд ли смогу следить за чатом. Зато после того, как я расскажу, я по этому чату пройдусь. Или можете их придержать и написать после. Тогда мы их будем в реальном времени все вместе видеть и и отвеча и я попробую ответить сначала, как-то закинуть начало диалога, но я вообще очень надеюсь, что получится не монолог, а какой-то какая-то минимальная дискуссия хотя бы в комментариях. У меня, наверное, доклад будет гораздо более простой, чем предыдущий. Я вот, если сравнивать с предыдущим докладчиком, вообще типа полный нуб. А, но 2026 год на дворе, я технический директор, мне типа приходится с этим работать. никуда не денешься. А меня зовут Самат Галимов. А я бывший технический директор медузы, букмейта, Яндексник, Пюра и довольно популярный подкастер. Мы недавно на на Ютубе, кстати, запустились. Называется Запуск завтра. А ещё я владелец бутикового аутсорса. У меня 25 примерно 25 человек в команде. Мы уже 7 лет этим занимаемся. И у нас не только новые проекты, но ещё аудиты. То есть я вижу не только там новые типа сделай нам X, но и у нас там проект, вот прямо сейчас мы делаем аудит там 30 лет там в девяносто третьем году проект начался, э, куча хранимок,
миллиард каких-то сервисов, которых друг с другом. И вот мы пытаемся им там в этом помочь разобраться и навести порядок, ускорить разработку, чтобы она стала быстренькой. И это я к тому, откуда типа на какие примеры я смотрю, когда опираясь на что, я как бы делаю выводы, насколько полезен искусственный интеллект и, э, в каких задачах. У меня просто ответ простой, на самом деле. Простые штуки типа эндосов,пишек и вот этого всего офигенно делать с помощью э AIя. очень круто вайп-кодить, а прямо буквально ваншотить. Типа, если у продукта есть какая-то безумная идея, ты, особенно нового продукта, ты можешь её прямо там за час ему принести какой-то прототип, который будет кликаться и, может быть, даже минимально работать. Это, безусловно, очень круто. А то, что раньше требовало работы дизайнера, потом како фронтендера, чтобы это собрать, теперь это просто типа вот так вот. А, ну да, очень круто. А при этом, если вы хотите этим пользоваться, вот именно для генерации новых маленьких продуктов, большие, старые, мы сейчас поговорим обязательно. Вот типа если вы маленькое, новенькое делаете, то я опираюсь типа на три э базовые вещи. Первое - это то, что можно взять любую сотомодель. Типа, неважно, типа, cloudкод многим кажется самым крутым, но openйный кодекс Openные модели нормальные, у Гугла хорошая модель, все они нормальные. Главное, чтобы не была упряж. Опять же, если не хотите погружаться, вот берёте cloudкод, как бы всё работает. Берёте кодекс, всё работает. Берёте антиграфити от Гугла, тоже всё работает. Если хочется сэкономить, можно взять open код, и в нём можно будет подключать более дешёвые билинги. А есть, э, важно
использовать фреймворки, не типа не запрещать модели использовать фреймворки, которые удобно использовать. А такой смешной факт, что вGS мы на фронте очень любим VUGS. Он типа плохо миросити плохо работат с UGS. Я не знаю почему, но если ты ей скажешь типа используй React или она там по умолчанию сама возьмёт React, то результат будет гораздо качественнее. И есть стартер-паки. Некоторые уже популярные фреймворки говорят, что они типа AI friendendly. Это классно. Там, значит, уже написано нормальный агент MD и модели будет модели будет с этим попроще. А как я этим пользуюсь? Я тут как бы прикол в том, что я вам сейчас это расскажу, но я думаю, что там через месяц, через два это всё будет встроено автоматически в эти модели. А поэтому а ну вот прямо сегодня, короче, вместо того, чтобы говорить: "Сделай хорошо", ты можешь там сказать и: "Задай мне исчерпывающие уточняющие вопросы". Вот тут как бы каждое слово важно, типа исчерпывающий уточняющий вопрос, типа, пока тебе точно будет понятно, а что я от тебя хочу. Потому что часто они просто идут делать, пока ещё не поняли или поняли неправильно. Можно ещё попросить подробно опиши, как ты понял задачу и что будет в результате. Это очень кайфовый заклинание. Если ты его скажешь, то он тебе выдаёт как бы своё внутреннее понимание того, что ты сказал, и там можно с этим как-то работать. И кайфово ещё то, что это дёшево и быстро, потому что, мм, потому что вот он тебе текстом написал короткий список, ты в нём прямо можешь исправить ошибки, словить их не на этапе, когда уже дохерищ кода нагенерировано и каждое исправление рискует вообще всё разломать, как часто бывает в айподинге, а ты прямо на этапе такого детального плана можешь это поймать и всё, хороший результат получается. Но я думаю, что все, кто занимается разработкой, а я наде и надеюсь даже те, кто не занимается разработкой, там заказчики
понимают, что это, типа, не знаю, 152% разработки софта. Самое важное - это не то, как быстро ты можешь запустить прототип, а то, насколько долго ты можешь качественно доставлять результаты. А вот я просто много проектов повидал, ко мне часто приходят, когда что-то идёт не так, и история всегда одна и та же. Типа в начале всё замечательно, такой медовый месяц любого любой разработки. А новый проект, программистам что-то спрашивают, просят что-нибудь сделать. Они такие хрена, типа готово, хренак готово. Просто вообще все счастливы. И если это какой-то заранее знаете, что большой проект, там 80% они, скорее всего, сделают за несколько недель, даже без искусственного интеллекта, а сейчас, наверное, ещё быстрее. А вот потом типа через полгода, через год начинаются проблемы. Вплоть до того, ну, типа то, что раньше занимало вот вот именно такая формулировка, это то, что раньше занимало там несколько часов, сейчас занимают неделю. Они ещё как бы говорят, очень часто программист, типа бизнес говорит, очень часто программисты отвечают, что мы не знаем, сколько это займёт. Или говорят: "Ну, тут надо типа оценить сначала". Раньше они говорят: "Раньше они просто делали задачи, а теперь им нужно оценить. Они ещё не попадают в свои оценки". Ну, в общем, все недовольны. И если в начале это вот конфетно-букетный период, то дальше вот эти какашки, они здесь неспроста. А почему так происходит? Ну, потому что со временем копятся legacси и никто не понимает, как эта система работает. Из-за этого происходит так, что ты в одном месте что-то добавляешь или там чинишь, а в другом месте оно отваливается. Это очень часто происходит, потому что нет тестов. А тесты - это маленькие кусочки кода, которые сами себя проверяют для тех нехнарей, если тут есть. Кстати, очень буду будет интересно, если вы напишите в чатике типа, есть ли здесь не технарий.
Поставьте, пожалуйста, плюсик. А, а так вот. А технические проблеческие проблемы, но есть ещё и такие чисто процессные, что ли, человеческие, культурные проблемы. Это то, что бизнес говорит там, сделай мне офигенно или там, сделай мне кнопку. А зачем эта кнопка нужна? Как она должна работать? Программисту приходится всё это вытаскивать там клещами. И если ты на запуске проекта программист там типа хорошо понимает, что от него нужно, например, да, иногда так бывает, то там через полгода, год там уже люди, которые что-то понимали, их уже в проекте не осталось или они уже устали, выгорели. И в результате оказывается очень часто, что вот те вещи, которые работали на старте просто за счёт энтузиазма, дальше они требуют довольно хорошо выстроенных систем. Например, система постановки задач. То есть там чётко должно быть описано, зачем ты это делаешь. Потому что, не зная контекста, зачем э поставить задачу просто процедурно, типа добавьте мне кнопку, ну, стопудово какую-нибудь хрень сделают программисты, потому что а не зная зачем ты наверняка что-то, ну не типа это важный для меня тезис, что э программа исходный код - это на самом деле просто детально описанная задача, типа, что что мы хотим получить. И вы тут можете заметить, что часто говорят: "Сделани типа ТЗ", в котором подробно написано, что нужно получить. Вот если бы я типа мог написать настолько подробно, чтобы всё было хорошо, то программист был бы не нужен. Вся идея в том, что тебе дают какой-то общий набросок того, что нужно получать. Дальше ты должен сам додумать все эти корнеркейсы. И чтобы их качественно додумать, тебе нужно понимать, зачем. А плюс очень частая техническая проблема. Я подозреваю, что все, кто ходит на такие конференции, типа самые продвинутые чуваки. Но я вам сейчас
немножечко в реальный мир вброшу. Типа 90% бизнесов не имеют нормального CCD. К сожалению, а то есть между тем, что ты что-то напрогал и тем, что оно появилось на продакшене, проходит там дни. Хорошо. Если дни, а то и недели, и месяцы. Нет стейджингов. Вообще хороший, на самом деле, супер сложная задача, потому что тебе нужно, чтобы он там был примерно актуальная база из прода подсасывалась регулярно, чтобы ты мог там делать там изменения в базе. Ну, в общем, это прямо серьёзная качественная работа. Опять же там на самом старте, когда ты только запускаешь проект, то тебе, в принципе, stage даже не нуж. Ты можешь на прот всё делать, потому что там пользователей пока нет, вы ещё не задеплоились, ну, в смысле пользователи не привели. А чем дальше, тем сложнее будет становиться стей. В случае нейросетей происходит удивительная штука. Можно, короче, вот этот, помните, я сказал то, что за там конфетный-букетный период в начале, а дальше там через полгода, год становится очень плохо. Так вот, в случае искусственного интеллекта можно, короче, вот это всё пробежать за там типа 2 дня или за несколько часов. А я называю спидран. Если вы совсем не не гомаете, то я вам прямо сейчас покажу пример, чтобы вы поняли, о чём идёт речь. А это очень любимая мной игра The Breath of the Wild. И там, короче, очень долгое, на самом деле, очень долгая игра. Там типа сотни часов можно в неё втопить, а ты там рождаешься в одном месте и дальше нужно попасть в замок, где ты нужно типа убить чудище и спасти принцессу. А так вот вы сейчас увидите, как быстро главный герой попадёт в этот замок и как типа сколько у него времени займёт. Чтобы вы понимали, у меня эта дорога заняла типа 300 часов. Там пол полгода я играл или там несколько месяцев. А он сделать это гораздо быстрее. И вот обратите внимание, чтобы вот это сделать, тут как бы на экране типа мало что происходит.
На самом деле нужно попасть типа в отдельный фрейм 12/двать четвёртую секунды, чтобы она игра загличила. >> И вот, короче, игра глючит, глючит. И он летит. >> Видите, там типа снизу какие-то поля. который ты обычно там проходишь миллион монстров. Вот с ияем то же самое. Обычно тебе для того, чтобы запрогать, нужно типа дофигище работы вложить, а с ияемям ничего этого не нужно. Мгновенно попадаешь в замок. Тут то же самое. Мы, а, мгновенно попадаем в legy. А, но есть не только как бы ты повторяешь путь долгой разработки за 2 часа, на самом деле ещё есть бонусы. А, например, во всех этих AI проектов 0% безопасности. Типа очень обычно всё плохо. Конечно, это становится лучше с каждой версией модели. И, наверное, там через полгода, год большинство этих консерв уже будут сняты. Но прямо сейчас типа надо очень внимательно посмотреть на то, что плош перед тем, как это делать. А там всякие глупые ошибки, типа SQR инвекции, входы без авторизации. Он типа сделал сервис, а про авторизацию просто не подумал. Ну, искусственный директор решил, что это не нужно, типа, и так пускай все заходят. А как как типа что спасает от этих проблем? А то, что, собственно, спасало от LEG, от больших сложных проектов всю жизнь все там 30 там 40 лет, сколько мы занимаемся разработкой. Нормальная модульная архитектура, то есть когда у тебя los coule вещи, то есть ты можешь там спокойно поменять какую-то часть системы, не сломав другую. Нормальный девайс. нормальны сеd стейджинги, то что такая девопс работа. А ещё вот это вот типа технические штуки, а ещё, ну, про отношения, это, например, навык давать и выполнять обещания. Мне кажется, он очень редкий,
к сожалению. Большинство программистов, которые я знаю, очень хорошо пишет код. Но у меня есть такая твёрдая убеждённость, что код можно там, если помните этот анекдот, что обезьян можно научить курить. Вот мне кажется, можно примерно любого человека научить писать код, но вот подумать, что от тебя потребуется, дать обещание и выполнить его в конце недели там или в конце месяца. Чем больше срок, тем сложнее. и выполнить это обещание. То есть там попытаться разобраться максимально быстро, собаводные камни, вернуться с фидбеком, сказать, что ой, кажется, я пообещал слишком много или там я успею больше. Это очень тонкая работа про отношения, про менеджмент ожиданий. Очень невидимая, на самом деле, работа, но и мне кажется, именно она отличает хорошего программиста, ну, такого полезного бизнеса программиста от чувака, который просто пишет код. И мне кажется, все мы хотим быть полезными программистами, а не просто кодописцами. Ну и вот это то, что я сейчас описал, это типа я как будто говорю про личные качества человека, но мне кажется, что я не научился за там 15 лет в разработке я не научился прививать людям эти качества, там типа делать из необязательного человека человека, который будет выполнять обещание. Я типа не умею этого делать. Я мы пробовали с Федей, не получилось. Зато мы научились выбирать таких людей. И вот дальше там проблема в том, что даже если чувак супер обязательный, его очень легко демотивировать. То есть типа сделать из немотивированных чуваков мотивированных нельзя, но вот сломать это довольно легко. Поэтому, мне кажется, работа технического директора и вообще руководителя, я сейчас немножко спойлерю продолжение презентации, но мне кажется, работа руководителя - это как раз создавать среду, в которой в которой поощряется
ответственность. Ну и, наконец, может быть, самое важное - это умение пушить бизнес, чтобы фичи красиво ложились в код. Что я имею в виду? Очень часто бизнес хочет вещей, которые не ложатся в ту архитектуру, которую вы придумали. Конечно, хочется сказать, что мы умеем делать такую архитектуру, в которую типа положится любая бизнес певича. Но давайте смотреть правде в глаза. Всегда есть ка есть вещи, которые проще запрогать, есть вещи, которые сильно сложнее запрогать. А по смыслу они могут быть очень близки. условно там не очень красивый пример, но тем не менее сейчас мы с этим сталкиваемся, там хотим брать деньги, а хотим сделать ну с банковской карты подписку брать, при этом мы хотим сделать скидку на первый там хотим сделать скидку при годовой оплате. Типа как это можно сделать? Самый простой способ - это сделать другой тарифный план, чуть дешевле, э, за месяц и про А нет, плохая плохой пример. А, м, ну, я думаю, что все, кто занимался разработкой, сталкивались с таким, что, а, там, типа, можно сделать почти то же самое, что ты хочешь, но практически бесплатно. Типа просто параметров конфиге поменять и всё заработает. А конкретно твой то, что ты просишь, там, то, что бизнес просит, типа, надо всё нафиг переделать, потому что оно не ложится в наш код. И так вот, мне кажется, что ответственность программиста - это вот когда бизнес просит что-то, что не ложится в архитектуру, с ним про это разговаривать и предлагать варианты, потому что только ты как программист знаешь, какие варианты будут дешёвыми для разработки. Вот. И, к сожалению, неросети пока не умеют этого делать. Мне кажется, это самое такой большой их недостаток и то, что пока даёт нам кожаным мешкам как бы возможность хоть хоть что-то значить. А вот это умение говорить нет. А, ну и умение держать обещания. Потому что когда нерать тебе говорит: "Ой, я не
смогла". Как бы, ну что ты и скажешь, не смогла и не смогла. А всё-таки у с людьми обычно есть какая-то ответственность. А что можно всё-таки делать с нерастями, кроме того, чтобы делатьпишечки? Что можно делать в больших проектах? А, ну самое, мне кажется, кайфовое то, что вот совсем недавно появилось, в смысле, совсем недавно, мне кажется, стало промышленно полезным для обычных людей это возможность генерировать код. А это супер сложно, на самом деле, потому что читать код чужой примерно так же сложно, как и писать, а может даже сложнее, потому что тебе надо типа разобраться, что он имел в виду. А с неростями не всегда вообще они что-то имеют в виду. Они просто пишут и пишут, как бы генерируют этот слоп. А, но это особый навык, и его, мне кажется, надо качать отдельно. Он не у всех людей хорошо развит. С другой стороны, если вы когда-нибудь читали полреквест плохих программистов, то вот как бы у вас была такая была такая подготовка. Только здесь, в отличие от плохого программиста, вы очень быстрый цикл обратной связи. То есть вы видите какую-то хрень, вы сразу, можете сказать, не расти, она сразу же это сделает, не забудет, не надо будет повторять два раза, и ответ обычно довольно быстрый. Ещё одна очень важная вещь - это возможность использовать иишечку для того, чтобы разобраться в старых больших кодовых базах. Мы прямо сейчас вот разбирались с этим огромным старым проектом, там типа десятки репозиториев, сотни тысяч строк кода на всяких ста странных старых языках. И реально то, что раньше занимало бы там 2-3 месяца просто чтобы разобраться вообще, что там происходит, а у нас уже за там недели три-четыре получилось сделать документ мордановский, э, то есть папочку репозитории, в котором лежали мордановские документы. первый документ типа описывает, что и как мы должны делать, чём что мы хотим достичь в результате этого аудита. А дальше не Россия сама наполняла с небольшим нашим гайденсом. То есть мы говорили там куда пойти, куда не ходить или там вот это нравится, это не
нравится, но она составила архитектурную схему того, как устроен этот проект. А и дальше уже используя это репозитории, можно задавать сети вопросы про то, как устроен, а как устроен этот бизнес. технически, а-э, что будет, если там что-нибудь поменять, что заафектится, что не будет афектиться. Это супер крутая штука, которой раньше не было. Это прямо, мне кажется, gгameчейджер для больших старых компаний. А, ну обратите внимание, что типа нельзя просто взять, загрузить, типа закинуть папку там в 10 ГБ со всеми репозиториями за всё время и сказать там, типа, ответь мне на вопрос. Нет, так нельзя. Тебе всё равно нужно типа подготовить основу. Тебе нужно сказать про сначала сделать вот этот этап типа подготовки какого-то, дистилляции того, что у тебя из репозиториев какого-то смысла, чтобы потом уже не Росси могла с них работать. Но это стало возможно, раньше этого не было. Ещё большое место, где важное место, вот я сказал, что можно генерировать код. Ещё несколько месяцев назад я читал ту же самую презентацию, и я про генерировать код не говорил, потому что мне каза, ну, то есть мы тогда, по нашему опыту, это было не супер полезно. Сейчас генерация кода, безусловно, самая полезное. Но вот писать тесты можно уже несколько месяцев, уже там полгода, год, и они довольно хорошие. А тесты особенно важны, потому что и прошлый докладчик, мне кажется, про это говорил. Тесты - это то, что уберегает от плохих комитов, от плохого слопа. Чем больше у вас качественных тестов, тем более вы AI ready. Вот прикольно, что вещь, которую придумали типа 40 лет назад, внезапно оказалась суперполезна. И м к счастью, Иишечка довольно хорошо пишет тест. Опять же, их надо очень внимательно смотреть глазами, но их можно уже не писать руками. Он почти всегда хорошо и генерирует, в отличие от сложного кода, с которым пока ещё иногда есть проблемы. А
так, ну да, при этом, конечно же, он не понимает, что происходит пока что, поэтому он может типа сделать красиво выглядящий тест, который не проверяет, собственно, сути происходящей. Поэтому их всё равно нужно читать. Это всё равно, а, работа программиста. А просто вайп-кодеру это не дашь. То есть не дашь, но будет ещё хуже. А какие-то мелкие советы, я думаю, что они на самом деле уже не такие, может быть, важные. Мне кажется, это уже совсем общее место, но я всё-таки проговорю их. А очень важно на Да, да, объяснять нейросети, как у нас тут устроено. Представьте, что у Неросети - это чувак, который первый день в компании. Он типа ничего не знает, никак у вас принято писать, э, там стиль стиль стиль гайдов не знает ваших. Про про это опять же типа уже много лет люди, нормальные люди пользуются линтерами. Настройте себе линтер, если вы этого ещё не сделали. И благодаря этому можно будет не объяснять неросити каждый раз, типа ты некрасиво написала, а у тебя есть формальное место, в которое она пойдёт, проверит, запустит линтер, проверит, и код будет такой же, как у вас. А все договорённости можно формализовать, записать на бумагу, запихнуть wagen D. Это супер полезно. А до сих пор, мне кажется, полезно делить на план и билд. А то есть сначала типа запланируй, и это может быть более дорогая, более сложная модель, а потом ты говоришь, типа, давай исполняй по плану. Ну, в смысле, проверяешь этот план, чекаешь его и дальше исполняй по плану. Это могут могут делать более быстрые, более дешёвые модели. Ещё очень важная штука удивительным образом. Я не знаю, как у вас в компании, у меня ребята какое-то время типа стеснялись, пытались экономить. Надо перевернуть эту стратегию, как бы ты наоборот говоришь чувакам, типа, максимально жгите токен. Если ты типа мало их жжёшь, то что-то не так. А потому что мм потому что время программистов дороже, чем токены. С последним
изменениям в кладкоде. Иногда я начинаю в этом сомневаться, но если сесть, посчитать, у нас пока получается, что время людей всё равно дороже и имеет смысл очень агрессивно использовать яишечку для ускорения своей работы. Это не не значит, что людям станет проще. На самом деле так мне кажется, ещё сложнее работать, а, но всё равно быстрее. Можно больше сделать. А значит, в результате мы получаем штуку, которая не то, что отправил и она сама всё сделала то, что only once, как бы когда accept all, но это джун, за которым ты внимательно следишь. Как бы опять же, мне кажется, все, кто давно работал в индустрии, знает, что такое заряженный и с горящими глазами чувак, у которого ещё представьте, что типа плохо со страхом, типа пришёл, всё сломал. Ну, как бы извинился, как бы такой немножко придруковатость, знаете, такая типа: "А, ну, сломала, сломала, ничего страшного". А вот представь, что это такой чувак. А, как я и сказал, это работа управлять этимиями - это работа для программистов. Просто немножечко другая. Если раньше нам нужно было писать код руками, теперь нам нужно пинать модель, чтобы она писала код так, как мы как так, как нам нужно. Это, на самом деле, мне кажется, очень похоже на э то, как раньше люди писали на ассемблере, а потом придумали C и другие. высокого уровня языки. Теперь мы пишем на этих языках, а аслерный код нам генерирует, машинный код нам генерирует компилятор. Вот. Мне кажется, что это очень похоже. Только если раньше компилятор был такой гарантированный, то есть типа точно знал, что ты получишь, а там в случае си ты можешь прямо даже если хорошо в этом разбираешься, ты можешь как бы предугадать, какой именно асверный код там будет, машинный код там будет. то здесь эта штука такая ещё с добавлением э с добавлением вероятности. И я вот так дёргаю, знаете, есть такая машина однорукий бандит, типа ты дёргаешь и там появляются эти цифры, крутятся, и если всё там три семёрки, то тебе банки падают. Вот это очень похожая
штука. А сидим, дёргаем, как бы, эти автоматы, надеемся, что всё получится. Я не хочу как бы ругаться на предыдущего докладчика. И я это люди, как бы люди, которые настолько в это всё погружены, мне кажется, двигают индустрию вперёд. А, и это очень важно и нужно. При этом я человек простой. Э, мы делаем там типа проекты для бизнеса, и у нас пока для нас пока вот этотarch, например, это очень известная история, идея про то, что если ты можешь обложить какую-то задачу чёткими метриками, то ты дальше можешь запустить туда модель, чтобы она автоматически пред ставила гипотезы и проверяла их относительно того тех тестов, которые у тебя есть автоматизированных, например, а с такой для меня мне Кажется, для меня самый близкий пример - это, э, один руководитель Shopifая. Это с типа самый кру крупная платформа для интернет-магазинов. У них есть мм иate язык для создания для вёрстки этих страниц этого магазина. Проект, над которым там 10-15 лет работали очень крутые программисты. Там всё заоптимизировано, просто про самые помидоры. И там очень много тестов, чтобы ничего не сломалось. Так вот, он натравил тониросеть и сказал, типа, повысь мне скорость ответа страницы тестовой. И дальше не росеть такая типа о смотрит, что там в гите есть, как как там исторически люди пытались повышать разные метрики. Э и там придума формулирует гипотезы, проверяет их и там за несколько дней нейросет там в много потоков на многих видеокартах начинают это делать. и добивается ускорений там типа в два раза в некоторых случаях. А это удивительная штука. То есть умным дорогим программистам платили за то,
чтобы эта штука была хорошей, а тут внезапно ты сажаешь тупую машинку, и она тебе в ответ выдаёт прямо смысловое улучшение. Там не все типа то, что предлагала Неросеть, э, прямо реально применимым, потому что понятно, что она под этот конкретный тест может подстроиться, но там иногда есть идеи, используя которые ты дальше можешь делать очень крутые вещи. Так вот, если есть что-то, что можно прямо чётко замерить, то это можно уже потенциально прямо в автоматизированном режиме улучшить. А это вот авторесarch, очень вещь, на которую я надеюсь, что она скоро станет такой живой и применимой. Другое - это, а, господи, я неправильно написал. Агентик программинг - это когда ты, ох, когда вот всё, что я сейчас описал про то, что ты гайдишь неросеть, потому что она что-то делала, когда всё это неросети делают с неросетями. То есть типа есть неросети, которые ставят задачи, есть, которые проходят там, делает тесты, придумывает тесты, есть, который принимает результаты. Вот это всё это очень интересно. И я вижу, что очень многие компании этим, ну, ведущие компании этим занимаются. Мне кажется, что это вот немножечко похоже вот в это прыгать мне лично не очень интересно. Мне кажется, что это мм очень немножко похоже на то, что вот там все пытаются сделать, не знаю, микросервисную архитектуру и там типа супертказоустойчивые там 100.000 серверов, но это реально нужно там типа пятнадцати компаний в мире. Всем остальным это нужно, потому что все хотят как бы научиться пользоваться Кубернетисом. Ну как бы хорошо. Чем это выгоднее бизнесу? Ну скорее всего, не выгоднее, наоборот, хуже. Но типа всё равно мы этим учимся. Я знаю, что я сейчас соберу кучу хейта, и я как бы тоже техналь. Мне тоже иногда интересно разобраться во всяких интересных штуках. Но мне кажется, что это нужно делать в личное время, а не не за счёт бизнеса. Хотя, если бизнес не просит, то почему бы и нет. В общем, мне кажется, что вот эти две вещи, они очень интересные. А это какое-то остриё прогресса. А, но по
моему опыту они пока не дают практического эффекта для небольших команд и небольших небольших проектов. Небольших, я имею в виду. Все, кто вот минус Tier One, то есть там типа Сбербанк, Яндекс, Google, Facebook, очевидно это делают. И там потенциально можно что-то много всего сэкономить. Для небольших команд, мне кажется, а мне кажется, у нас хватает головника без этого. Вот я так подробно рассказываю про работу программиста, потому что мне кажется ответить на вопрос: "А что типа с техническим директором нельзя пока?" Ну, то есть мой ответ, он опирается, вот я смотрю на всю эту движуху с искусственным интеллектом, вот с этой с этого угла, вот с так я её понимаю. И дальше ответ, что стигдиром становится очевидным. А первый типа в чём моя роль, в чём она поменялась относительно того, как было раньше. У нас сейчас есть довольно много программистов, которые умеют хорошо писать код и, может даже разговаривать с бизнесом, вот это всё, но не умеют ставить задачи другим людям. А работа с неросеть - это во многом умение ставить задачи, типа формулировать задачу так, чтобы она была чёткой, понятной и недвусмысленной. Отчасти, то есть типа на самом низком уровне может быть. Я говорил, что программирование оно типа, по программирование с помощью И оно типа не сильно отличается от обычного программирования, но как бо как только ты поднимаешься на уровне выше и выше, это всё больше похоже на управление людьми и программисты этого не очень хорошо умеют делать. А, но мне кажется, что это похожий навык на то, что вот помните, раньше были ребята, которые не умели делать какой-то ревью. Типа они такие: "Мы кот пишем, типа, что я буду там чужой код смотреть, а типа будут комментарии давать, что это такое или там токсично это делали". Но сейчас, мне кажется, почти все научились. Я думаю, что мы вот на таком коротком сейчас мы сейчас в уникальной ситуации, когда есть много людей, которые программисты, но пока ещё не умеют работать с яишечкой на
высоком уровне. В смысле вот ставить задачи и принимать задачи. И этому, мне кажется, роль технического директора - это помочь таким чувакам научиться этому, сделать, ну или давайте по-другому немножко, не так потерналистски, создать среду, в которой обучение этому будет поощряться. А отказ от обучения будет не будет пащриться. А ещё такое наблюдение, что все мы немножечко фронтендеры извините, господа фронтендеры и и девушки фронтендеры. Мы, я имею в виду, что тулинг очень быстро меняется, библиотеки очень быстро меняются. Вообще, что происходит? Типа вчера, а там вчера cloud код был самая модная штукой, а сегодня уже надо пользоватьсякодом. Короче, вот это постоянное, это уже было 2 недели назад, это уже устарело, а в бэкэнде так не было раньше. А сейчас у нас вот именно с AI-тулингом это происходит. Мне кажется, надо дать немножечко уложиться, а, устаканиться. Я думаю, что через 2 года у нас будет уже более-менее нормальная экосистема. А пока что можно пользоваться. Типа, если интересно, может сидеть в Твиттере и всё это узнавать. А если не хочется на это время тратить, то можно просто пользоваться самыми последними продуктами от Antropic, Open AI и кто там ещё, Google. Google немножко сейчас отстаёт. Пользоваться самыми версиями этих продуктов, самыми последними версиями. Это будет типа на полтора поколения более старые инструменты, менее развитые инструменты, чем самый крутой Open source, но будет работать с этого. А ещё одна работа программиста, которая, то есть работа технического директора, которая, мне кажется, сильно изменилась, это строить системы и правила, чтобы это, чтобы вот этот мм яй всё ускоряет. Помните, был вот этот про спидран, где линк перелетел там 200 часов за 30 секунд. Ну представьте, что у вас в компании, не знаю, 100 или 200
программистов, которые вот так начинают летать во все стороны. Раньше их можно было хоть как-то собрать. Помните, тут ужасно, мне кажется, пословица, но всё-таки типа пости котов, да? А теперь они типа, блин, все куда-то улетели. Вот нам нужно придумывать правила, чтобы это не происходило, чтобы эта система не разносила. А это интересная задача. А мне кажется, что тут много очень от сисадминов, потому что, ну, такая сидминская задача, типа придумать жёсткие правила для кода уж точно жёсткие, чтобы я чисто технически не мог там вам что-то сломать, чтобы у вас типа всё было ограничено, например, в стойкоговом контуре, чтобы в прот оно не имело прямого доступа и так далее, и так далее, и так далее. Например, очень интересная задача, мне кажется, до сих пор нормальная, системно нерешённая. Это удивительно. Просто я пример приведу, чтобы вы понимали, насколько сырые все эти инструменты. А вы наверняка раньше, ну, типа вы наверня вам наверняка нужно иногда залезть в продакшн-базу и что-то там посмотреть, не записать, а посмотреть. И раньше мы как это делали? Типа ты заходишь там select там сдерипt, ну, короче, пишешь запросы. Сейчас как кайфово делает. Ты говоришь сити, вот типа конеctionст базе зайди, посмотри, сколько там пользователей там скажи мне, какие инсайты за последние 2 недели произошли. Работает магически совершенно. Но есть проблема. Неросить в принципе может сделать всё, что ты даёшь. Она ничего ей не мешает сказать dropйбл, как бы, и дропнуть всю твою базу. И то, что это не произошло до сих пор, это просто тебе типа везёт. Это все вероятностные истории. Даже если ты скажешь: "Никогда не запускай никаких деструктивных команд", нет гарантии, что она этого не сделает. И тут как бы у нас вообще-то дофига харнеса под это. Точно можно создать отдельного пользователя, который будет только. Точно можно сделать стриминговую копию базы, но это всё сложная админская работа. А де пользуются система обычно программисты. И мне кажется, вот это умение делать какие-то админские штучки или очень хорошо слаженно работающая
команда программистов из админов, то, что называется devopсов. И это, мне кажется, будет такой мультипликатор для всех, кто хочет внедрять AI качественно. А очень интересно, что вы, а, что думают коллеги из других департаментов, другие там финдиры, а, HR-директоры, потому что, мне кажется, у нас некоторые вещи должны быть очень похожи. Вот если кто-то есть, то, пожалуйста, напишите, задайте вопросы. Вообще в целом на этом всё. Спасибо вам большое. А я уложился в 36 минут. А у нас мы начали чуть позже, поэтому у нас есть целых 17 минут на вопросы. >> Супер, Самат, спасибо, коллеги, задавайте вопрос. Я видел, что они появлялись в чате по ходу рассказа. Давайте мы их повторим, потому что чат отследить невозможно на большом количестве участников. >> Я сейчас листаю. Аа мне как, как, как, как поступим, с ваше, мне читать сверху вниз или пролетать в самый низ и попросить коллег написать ещё раз? >> Я думаю, что лучше снизу вверх читать. Вот >> снизу вверх, но это самое нечестное, >> да? Не, ну вот вопрос от Дамира, я видел, появился. Вот мне кажется, от него можно и ниже. Коллеги, повторите ваши вопросы, если они есть. Вот и мы сама-то вот так вот самый низ. Готов. Читаю. Да. Username Redonly. несложно, это база, я абсолютно согласен. Но для этого нужно как бы совершить действие. У тебя должен быть кто-то, кто умеет делать пользователюдоли, и у тебя должны быть права на это то, чтобы это сделать админов. То есть обычно это какая-то админская работа. И вот в том-то и дело очень простые вещи, но ощущение, что многие о них не знают даже иногда. Я уверен, что есть куча народа, которые типа делают эти ограничения в коде, вместо того, чтобы в базе сделать. Так, а у нас в бизнесе впихивается весь хайп. Например, увидели Openкло и срочно всем внедрить его. Через неделю увидели
у роборос и его тоже срочно нам надо. Как вежливо уважаемым людям доносить, что это не нужно и нужно изучать всё это на предмет безопасности и удобства? Про бе, ну, можно, конечно, пугать безопасностью. А недавно я видел. Давайте я вам сначала шутку расскажу, а потом попробую серьёзно ответить. А я в Твиттере читал этот анекдот, что типа мы сделали для нашего CEO отдельный репозиторий, который типа никуда не пушится или там типа пушится в отдельный стейджинг, ну типа на отдельный стейнг окружения, и завернули ему его туда в прот. Он и он типа ходит и всем рассказывает, как он пушит в продакшн. На самом деле он, помните эту историю про то, что для диктатора Салазара, мне кажется, и или Пина, по-моему, для Салазара печатали газету в единственном экземпляре, чтобы ему казалось, что он до сих пор типа диктатор. И и вот это всё >> 100% Салазар, потому что это Португалия, а мы в Португалии. Это да, это это мы знаем. >> Вот. А тут сделали то же самое для CEO, чтобы он думал, что он пушпрот. Это, конечно, шутка, но мне кажется, в этом есть доля правды. Людям, конечно, хочется поиграть. А и мне кажется, надо давать площадку для игр, а, делать стейджинги, делать окружения, в которых они могут экспериментировать, тестировать, не трогая продакшн. Ну, такое. И типа хочешь быть взрослым, надо как бы и и надо создавать среду детям, чтобы они играли. Это нормально, мне кажется, совершенно в этой вот сфере, конкретно в этой области, мне кажется, мы взрослые, а не дети, надо им помогать. А при этом иногда я допускаю, что они реально что-то классное принесут, но пускай покажут на тестах. И вот это опять же вот это же адская админская работа. Обычно нам и так как бы её достаточно ещё там типа отдельный стейджинг для этого поднимать. И тут я задаю вопрос типа: "А почему так сложно поднимать стейджинг? А как это вообще у вас устроено?" В общем, это огромный вот это, как называется, кроличи на равне начинаешь закапываться и столько неоптимальных вещей. То есть мы просто начинаем требовать от нашей команды разработки из из яишечки вещей, к которым она не привыкла. И это очень
сильно показывает, насколько мы м насколько мы гибкие, качественные. Мне кажется, это такая метрика на самом деле качества внутреннего качества. Типа хрупкий у тебя внутри процесс или не очень. Так. А, о'кей. Банку тоже нужен токен. Банку тоже нужен токен. А вы, наверное, про банковский, ну, не знаю, уточните вопрос. Так, AI пишет хорошо терофом, поэтому админиски штуки хорошо работают тоже. Слушай, вот, а, а, согласен, б жутко страшно, типа ошибка в коде ещё обычно может ставить на стейжинге, а, а средств, в которых у тебя нормальный есть тестирование терама, я видел довольно мало. И тут как бы и и делать их кажется сильно сложнее и сильно дороже. И тут возникает вопрос: "Ты что, готов типа вот с этим так играть? Или ты будешь перепроверять каждый раз очень внимательно?" А если будешь перепроверять, то сильно ли это дешевле? Это вот, кстати, вопрос, который многие AIптики мне задают. И мне кажется, что в целом, да, типа, если у тебя скилл нормально развит, то читать код всё-таки дешевле, чем его писать. Но а вот, да, типа, удали всё, сделай заново, это нормально. Как относиться к фреймворкам, подобным Open Spec spec kit BMAT Method? Мне кажется, что это типа не обязательно. Пока можно без этого. Если ты хочешь с этим разбираться, то очень круто. Я в них совсем не разбираюсь, поэтому даже боюсь сказать, боюсь сморозить глупости. А как насчёт разрабатывать всё ваншот? Каждый раз собирать проект с нуля. Это очень крутая идея, которая, мне кажется, в принципе, может получиться когда-нибудь в будущем, так же как и всё остальное. А я тут вспоминаю Oraacл. А это знаменитый кейс с тем, что у них вот этот база данных Oraac же типа ей
там 40 лет, её там писали сотни тысяч, наверное, миллионы людей уже типа за всю историю. Сейчас там работают десятки тысяч программист, которые 100% нихера не понимают, как целиком работать. Наверное, есть там типа два-три человека в компании, которые что-то понимают, но вот чтобы целиком и чтобы даже какие-то большие части, нет. Но это всё, тем не менее работает удивительным образом. И там все банки на нём сидят. сидели до постгроса, го постг, потому что у них очень много тестов. У них миллионы тестов. А и вот может быть, если взять миллионы тестов и нормальный тулинг поверх того, что сохранение промптов, это тоже, кстати, нерешённая проблема. Вот насколько всё сырое. Это же супер очевидно, что когда у тебя есть один комит и есть второй комит, который сделали с помощью несети, ты точно хочешь видеть конкретный промпт. который сделал этот комит, чтобы его можно было повторить, изменить виды. Ну, короче, ты не хочешь просто с кодом работать, хочешь с промтами работать. И совсем недавно запустился проект основателя гита, создателя гита и бывшего генерального директора гита гитхаба как раз про это. Но это всё суперсырое. Я думаю, что вот год-два как бы всё настоится, всё будет классно пока что. Ну, идея очень здравая. Мне кажется, что это прикольно. Насчёт ваншотинга ещё смешно. Я вот говорю типа про Legacy Legси, Legacy, но есть такое ощущение, что может быть ты имеешь право копить этот Legacy, потому что через там 2-3 месяца, когда у тебя Legy накопился, модели стали настолько лучше, что ты можешь сказать: "Перепиши, возьми этот проект, прочитай его и перепиши нормально с нуля". И она тебе типа очистит всё LEGO и сделает хорошо. Это совершенно безумие какая-то. Ну типа, если об этом подумать, а, ну, в смысле так для типа здравым смыслом говое. Но в то же время для небольших проектов, кажется, это сейчас работает. Ну, есть у тебя токенов много. А с контекстами, да, там, короче, много вопросов
возникает, но его можно менеджить, типа ты можешь разбивать на части, там есть подходы. Так, мм, э, внутренний маленький инженер почувствовал свою важность. Это, наверное, про этих, да, про руководителей, которые хотят у ваншотить всё. Как вы на практике понимаете, что А уже начал ускорять именно доставку ценности, а не просто быстрее производить новые legy? А какие две-три метрики или сигналы вы бы смотрели в команде? Мне кажется, я бы смотрел на скорость доставки фечей. Она не должна падать, она должна расти. Ну, в смысле, ускоряться должно. Доставка фичей должна ускоряться. А количество инцидентов это очень хорошая метрика, мне кажется. А, и вы видите, типа, у Китхаба инциденты постоянно, у Амазона инциденты, типа, никто это нерешённая задача, и туда стоит фокусировать внимание. И в отличие от Гитхаба и и Амазона, мне кажется, что здесь для маленьких компаний, на самом деле, у нас есть преимущество, потому что мы можем просто собраться там 15 человек и сказать: "Так, пацаны, вот так делаем, вот так не делаем". В Амазоне, конечно, с этим гораздо сложнее и ответственности личной гораздо меньше. А я бы смотрел вот на такие внешние бизнесовые метрики, потому что количество кода ещё что-нибуд такое, мне кажется, бессмысленно. О, я бы смотрел на количество удалённого кода, потому что мм такие большие сложные рефакторинг штуки теперь, в принципе, можно делать с помощью яишечки лучше. И если ты там ужал код, код basй, типа, там убрал там убил 20.000 строк, типа, молодец, премия. Вот, мне кажется, вот в эту сторону я бы смотрел. И это штука, которую невозможно обмануть, мне кажется. И типа для того, чтобы добавить мусор, можно типа без это, а вот убрать так, чтобы она продолжала работать, это реально, значит, значит, ты реально что-то понял, что-то упростил. А упрощение, мне кажется, это ценная, очень большая ценность. Завёл себя аишечку, подишешку отдельной учётки с правами ро. Да, вот это очень круто. А там правда есть, как бы, если
ты почитае, если вы почитаете про эти последние модели, они для достижения цели. Если ты им поставишь цель, типа, они могут обманывать, могут пытаться взломать и получить. То есть, если у тебя токен рядом лежат в другом файле и ты ему сказал, типа, эти токены не бери, он вполне может пойти и взять. Скажи спасибо, что он типа не взломал твой не нашёл э уязвимость и из из виртуальной, типа не не вышел в хаста и оттуда ничего не стырил. Такое тоже бывало во время обучения. Там, конечно, гораздо больше ранов, это редко происходит, но даже такое бы даже такое бывает. Так. самым ярким факапом, случившися в результате внедрения искусственного интеллекта. Так, дайте я подумаю, потом, скорее всего, она всплывёт и расскажу. А так стейджинги, да, ну, вообще, по-хорошему, мне кажется, это должно быть автоматизировано. То есть ты не должен каждый отдельный стейнг с типа кнопочку, это должно по кнопочке случаться автоматизировано. И пока вот этого нет, большие вопросики. Так, менеджерскиймене менеджер менеджмент Стейта БД, файловый системы и так далее. Ну да, да, потому что это вещь, которую сложно откатывать. Это, в принципе, типа миграции, вот это всё. Это опять же сложности с админская задача, типа, как сделать нормальной миграции. А что мешает вести журнал проекте, фиксируем все промты, все изменения? Да, ничего не мешает, только ты не будешь это делать, если это надо руками делать. Это должно быть встроено в твой тулинг, очевидно. А в этом проблема, что это сейчас не встроено. Поэтому в каком-то смысле мы с вами просто типа в каменном веке, вот как люди в начале на ассемблере писали, как бы вот мы примерно там же. Мя пишут хорошо терофор. И и в этом плане мне кажется, просто представьте себе, вот эффективность производительности ребят, которые писали бумажкой на ассемблере, и
эффективность нашей команды сегодня, типа, что мы можем сделать даже без яишечки. Теперь представьте, что вот мы сейчас типа с яишечкой что-то на коленке корябаем, а когда у нас будет нормальный тулинг, а так я и пишет хорошо тероформы. Ну да. Ой, я усложнять просто упрощать сложно. Да, вот это моя идея. Поэтому вот этим надо пытаться заниматься с помощью неросетяй, мне кажется. Аа люди делятся факапами. Спасибо, Ренат. Агент удалил забыть все метрики для сквер, когда что-то добавил. Да. Да. У нас очень часто вещи, которые сложно проверить тестами. Типа ты на лендинге, типа, условно дела мы делаем лендинг, а и он просто не добавляет туда там тарифные планы. Типа почему так произошло? Нихера непонятно. И проверить это тестами нельзя. Надо глазами просто увидеть, что типа что-то что-то не так. А тут, конечно, вот ребята про агентскую разработку, агентную разработку мне скажут, что надо было просто агента, который будет проверять. Но опять же, я пока не научился этот линг настраивать. Наверно, надо побольше послушать ребят, которые в этом поднаторели. А Дамир пишет: "Вы уже ранее сказали, что нельзя научить людей давать обещания, выполнять их." Основной причиной посвящению неумения оценить свою будущую работу. Э-э, не уверен, что, ну, мне кажется, это всё-таки свойство, а не просто неумение оценить. О'кей. Если, а, ну, и следом говорит, что будете учить прост работать по-другому, то есть уметь проектировать и планировать, э, нет ли тут противоречия. А, с хорошее замечание. Мне кажется, что, конечно, умение самому выполнять обещания, давайте выполнять обещания, и умение контролировать другого - это разные вещи. Ну, разные и умение ставить задачи - это типа разный скилсет. Я вот про это говорил. А проверять в смысле типа ходить и пинать, чтобы он что-то
сделал, ну, с неростями, слава богу, это не нужно. Хотя очень, честно говоря, у меня недавно вот как раз было, что я говорю: "Типаa сделай что-то". Она такая: "Половину сделала, бросила". Я говорю: "Ты доделала?" Она такая: "Нет, я не доделал, пошла дальше делать". Что это было, я не знаю. Это, видимо, такой деморежим, а когда типа, точнее не деморежим, а это такой симуляция плохого программиста. А, но вот про то, что нельзя людей заставить, э, то, что называется care, типа, чтобы им было не пофиг на твою работу, на на проект, потому что нельзя вот вот это нельзя типа заставить. Либо есть, либо нет. А в этом я уверен. У меня много данных про это. А вот про то, что человек не сможет научиться ставить ишечки задачи, у меня пока мало информации. Я хочу верить в лучшее. Я хочу верить, что типа ребята в этом разберутся. И по опыту мои ребята, которые умеют вот типа за себя отвечать, у них в принципе нет проблем. Там основная проблема в особенно у, извините, что я так стереотипирую, но у программистов девушек, а они часто не верят в свои силы, что типа у них получится. То есть ты им говоришь: "Да на вайподь фронтенд, как бы ты же нормальный бэкэндер, как бы что-то в реакте делал, сделай просто на вайпопе она нормально будет работать, не сомневайся". А они хотят, чтобы было идеально, чтобы было кру. Ну, то есть это вот такая чисто даже гендерная штука, я замечаю, есть разница. То есть наглость э немножечко такая типа, а сейчас попробуем, там посмотрим. Это очень важное свойство, мне кажется, в этом в этой эре вайп-кодинга. Так, время у нас 2 минуты, на самом деле. Ну, уже почти все вопросы ответили. >> Да, да, Самат, спасибо. Давай будем тебя отпускать. Нано потихонечку. Спасибо, что ты к нам заглянул. Вот. И и поделился и опытом, и на вопросы очень подробно ответил. Мне кажется, было здорово. Будем, я думаю, рады тебя видеть и дальше. Вот. Спасибо.
>> Да, коллеги, спасибо. Давайте скажем Самату. >> У нас почему-то сегодня отключилась функция апплодировать и вообще ставить какие-то значки. Наша команда поддержки сегодня закрутила гайки. Ничего не можем, вот только говорить и слушать. >> Я чувствовал поддержку стопроцентно. Вопросы очень чёткие по делу и интересные. Спасибо вам большое. И то, что делились своими историями. Спасибо вам большое. Прямо очень классно. >> Класс, класс. Самат, спасибо тебе большое, коллеги. Ну что, мы с вами будем завершать официально наш третий день. А у нас как-то незаметно три доклада пролетели. Впереди у нас, я напоминаю, автопати. Вот у меня даже под него заготовлены специальные слайды. Э у нас час со славой Панкратовым для того, чтобы ответить на ваши вопросы. Но прежде чем мы туда перейдём, я хотел бы коротко напомнить, пока мы ещё не разошлись после сегодняшнего дня, что у вас, коллеги, есть специальные условия на участие программы стратоплана. Вот мы все наши открытые ивенты проводим в преддверии запуска наших программ обучения. Мы образовательные учреждения. Э, причём у нас мало курсов, то есть мы несколько раз пытались стать платформой, и у нас плохо получается, потому что как только курсов становится много, мы проседаем по качеству. А мы не любим проседать по качеству. Мы расстраиваемся, людям. Ну, в общем, мы поэтому делаем курсов мало, но зато максимально качественно. Вот они не очень дешёвые, но зато они вот, будьте уверены, очень хорошие. И, э, курсов у нас, правда, несколько и для директоров Advanced Management Program пилотный запуск в конце июня, и для тех, кто хочет свою экспертизу переупаковать и попробовать себя в роли эксперта, получа, тренера или консультанта. и не уходя из найма такой безопасный shift карьеры сделать или даже карьеры сделать, да, используя нашу любимую терминологию. И, естественно, классический специализация стратоплана - это, это руководитель отдела, это сеть и CO, то, что неизменно набирает аудиторию. В июне мы делаем стартерпек по каждой специализации, то есть один месяц интенсива для того, чтобы понять базовые вещи, такой сделать фундамент
себя в этой профессии. Приходите, будем рады вас видеть. Скидка 300 евро по промокоду 300 действует до конца 26 апреля. Ну что, Вячеслав Фрович, у нас третий день конференции. Э значит пролетел незаметно. Да. Дада. >> Нако, >> да. Внезапно, да. Остался один день. Коллеги, спасибо вам за участие. Завтра, пожалуйста, не опаздывайте тоже на доклады. Вот, особенно на третий доклад, потому что я его буду докладывать. Я лицо заинтересован. Очень хочется, чтобы там были слушатели. Вот. Да, будем мы говорить, на самом деле, про психологию. Я такой спойлер закину, потому что, ну, мы её упоминали иногда, но мы прямо в неё копнём, потому что, мне кажется, от того, как устроена наша голова, зависит очень много и то, какие выборы мы делаем, и куда мы бежим, поддаёмся паники, не поддаёмся панике. Поэтому мы туда заглянем и вспомним тест, который вы, скорее всего, ещё не проходили. Вот. Ну и заодно я на него сошлюсь. เฮ