AI Hard Fork: Панельная дискуссия — Артём Санакоев, Данила Симонов, Глеб Михеев, Максим Романовский

А сейчас мы переходим к нашей панельной

дискуссии. Вот давайте я представлю вам

Максима. Максим Романовский, а партнёр,

с которым мы делаем энтропитолк. Он

сегодня будет вести эту панельку.

Максим, представься, пожалуйста, ровне и

вводи ребят.

>> Да, спасибо большое, Коля.

В двух словах, я почти 20 лет занимаюсь

разработкой и последние 12-13 лет в

основном руковожу этой самой

разработкой. Сейчас работаю в банке, и

мы занимаемся вместе с моими командами

внедрением AI э в технологические

процессы, в software engниринг процесс.

И основной наш KPI - это насколько мы

ускорим разработку

наших команд.

Вот поэтому мне очень было бы интересно

послушать наших спикеров Глеба, Артёма и

Данилу, потому что все трое

непосредственно тоже связаны с Ием. И

давайте мы дадим шансам представиться.

Глеб, давай начнём с тебя.

>> Да, здорово всем. Привет. Я Глеб. Я с

2003 года занимаюсь коммерческой

разработкой за деньги.

прошёл много всего в своей жизни. В том

числе у меня была команда по

компания по заказной разработке, где я

успешно 9 лет был стидол активно писать

код. То есть был таким РТМ гонялой. Вот.

А сейчас, собственно, я в Сбере. Вот. И

одна из моих ответственностей - это

внедрить агентную разработку в нашу

жизнь инженерную.

Вот большой такой интересный челлендж.

>> Спасибо, Глеб. Артём.

Всем привет. А меня зовут Артём. Я CFER

JPA стартап, который занимается

ресрчем вокруг foundation моделей. Мы

строим свои большие модели и маленькие

модели для генерации людей и тренируем

всех модели с нуля. То есть это

генерация картинок и видео с фокусом на

людей. Вот до этого я работал в мете в

отделе GNI. Я был STF Research

Scientist, который, а, команда, наша

команда была ответственна за разработку

всех GNA моделей для генерации картинок

и видео на масштабе меты. Мышипили их

продакш на десятки миллионов

пользователей, в том числе я один из

авторов Movie Gen. Это модель, которая

была вышла немного позже после Соры

Openi, которая тоже генерировала видео,

а, и делала это лучше, чем Сора по

качеству. Вот мы ускоряли её, и я лидел

команду, мы ускорили её почти в 100 раз,

чтобы зашипить этот продакшн. Вот. А

сейчас мы строим свои модели в нашем

стартапе Сурихе. А вот стартап на на

ранней стадии. Вот может быть попозже я

чуть расскажу позже про какие практики

мы используем а с помощью of нашей

разработки. Спасибо.

>> Супер. Спасибо, Данила.

>> А, всем привет. Меня зовут Данила. Я

последние 17 лет в коммерческой

разработке, последние 7 лет в основном в

силе ролях и где-то 5 лет как основатель

сооснователь компаний. Э последние пару

лет я прямо плотно ежедневно каждый день

разрабатываю Си. Мне кажется, я начал

это делать ещё в двадцать четвёртом

году, может быть, даже в середине этого

года. И в последнее время перешёл на

ежедневную стопроцентную разработку СИ.

немного в двадцать пятом году консалтил

разные компании на тему внедрения,

насмотрелся на всякие ужасы и на всякие

радости того, что там у них происходит

под капотом. Поэтому с радостью сегодня

это пообсуждаю.

>> Супер. Спасибо большое. Приятно быть в

такой компании. Давайте сразу же

перед тем, как перейти вопросам, сделаем

небольшой сюрприз для вас.

Мы вчера договорились с моими коллегами

по данной конфе, что я буду логивать все

ваши идеи. Более того, я сейчас ещё

включу гранолу параллельно и посмотрим,

что наш доблестный ай сможет выцепить из

того, что не смогу выцепить лично я.

Вот. А теперь, мне кажется, мы готовы

перейти к первому вопросу.

И первый вопрос звучит так: как

Используется в ваших

компаниях или командах, если эта

компания не ваша? Давайте начнём в

обратном порядке. Данил, давай начнём с

тебя.

>> Ох, ну а он используется для разработки

в основном. На 100% вся разработка на

данный момент перешла ПДИ. Я бы сказал,

ну, честнее будет сказать 98-99%,

потому что остаётся какой-то кусок,

связанный с самыми ключевыми контрактами

в системах, которые лучше сделать

ручками. Всё остальное, м, пишется и в

двух форматах. Это либо формат prompt to

action, то есть когда человеку просто

лень печатать, но он очень чётко знает,

что он хочет получить, вот прямо строчка

в строчку, и он, грубо говоря, просит и

добиться этого. И второе - это полное

делегирование задач. То есть, когда у

тебя уже выстроен каркас, и ты просто

там, эй, сделай коннектор к этому, и

теперь сделай ещё к пяти. То есть и по

подобию, когда тебе уже не так важно

контролировать это всё качество. Аэ, это

в принципе самая главная история. Под

это перестраивались многие процессы,

особенно в последнее время. Мне кажется,

вот этот вот, э, last mile между,

скажем, семидесятипроцентным

использованием, которое, мне кажется,

сейчас есть уже в очень большом

количестве команд, а, и там 95 + - это

принципиально большая разница в том, как

строятся процессы. Open недавно про эту

статейку выпускали, как они строили эти

процессы у себя и так далее, и так

далее.

Блин, 100% это круто. Я даже в

петпроектах не могу похвастаться таким

же результатом. Интересно послушать.

Артём, давай начнём с тебя, потому что у

тебя опыт поближе. Вы тоже стартаперы.

Расскажи, какой у вас процент пишется и

как вы используете?

>> Пишется процент, я не могу сказать, но

очень большой. А дело в том, что мы

разрабатываем AI, мы не просто соединяем

какие-то существующие эндпоинты, и у нас

много именно как бы внутреннего кода,

который там предназначен для тренировки,

распределённой тренировки там на многих

видеокартах, а сам сами архитектуры

модели, которые мы строим с нуля, там

работа с данными и, конечно же, вся наша

команда использует, э, активно курсор,

кокод.

Какие-то вещи, конечно, ну, ревьются

людьми. Какие-то вещи у нас ревьются с

помощью код Rabbit. Автоматически

засылается каждый пиар, а, ревьюется

кодребитом и какие-то вещи фиксятся

прямо им же. Ну, какие-то вещи человек

должен заправить. Вот. Так что, ну, я

честно, кстати, не могу назвать, но я

думаю, что больше половины точно пишется

у нас

с помощью AI. Но есть вещи именно вот

как бы в командах, которые занимаются

разработкой новых моделей. Некоторые

вещи модели не справляются написать. И

часто там не нужно много кода. То есть у

нас не то, что там а под base там, не

знаю, сотни тысяч строк кода. У нас,

допустим, тренировочный фреймворк, он по

размеру не такой-то и большой и он не

так часто меняется. А, допустим,

архитектура модели - это, в принципе,

один файлик, а, ну, может быть, два. И

там, чтобы поменять определённые блоки,

допустим, мы придумали там какие-то

более эффективные блоки для нашей

модели, а там не нужно тысячи строк

кода, там просто буквально, не знаю, 200

строк кода написать или даже меньше. И

если ты говоришь, э там модели: "Напиши

мне там лучше мне архитектуру этого

блока", то она как бы не знает, что ей

делать. И часто нужно самому это

сделать. А либо там сказать, что вот

есть такая имплементация, которую мы

сделали, там перепиши это на тритоне,

чтобы это быстрее было или там как-то

более lowлеvelвеel, то есть в таких

вещах. И э

модели хорошо справляются модели с

написанием кода, если этот код уже много

раз был, ну, в каком-то виде на гитхабе

или в публичной доступе. Если это

абсолютно какая-то новая штука, то там,

ну, приходится самому это писать, чтобы

полностью, ну, либо ты просто должен

промтить так настолько подробно, что, в

принципе, ты бы уже написал и сам этот

код, а, не тратя время на на промнг.

Вот,

>> смотри, а вы уже какой-то при этом себе

пишете вокруг. Ну, то есть, о'кей,

понятно. Основно какой-то модели, да,

вещь вообще, мне кажется, достаточно

редкая с точки зрения внесения

изменений. А какой-нибуд там тулинг,

чтобы какие-то коation листы правильно

собирать, что-то гонять. Там же много

работы вокруг, да?

>> Дадада, конечно.

>> Очень много работы с данными, с

обработкой данных. И там мы, конечно,

используем различные модели, не только

наши. И там очень помогает, особенно

если это скрипты какие-то однодневки или

там, которые живут максимум месяц, а ты

используешь по максимуму, говоришь: "Вот

есть такая-то модель, есть такие-то

данные в таком-то формате, пожалуйста,

напиши там pйплаine". Это всё пишется

автоматически. И только ты опровишь

пиары и самитишь их, комитишь, опровишь

и всё, они летят в продакшн. Да, так мы

делаем.

>> Угу. А смотри, вот ещё такой, знаешь,

вопросли он больше всех он был хорошо

зацетаплен уже Кудрявцевым, а Глебом,

да, вчера. Вот что типа

как выживать, да, когда мы начинаем

разгоняться под реагента. Ну, типа, у

нас сокращается всё, мы начинаем прямо

вот так фичи стрелять,

тра-та-та-та-та-та-тата фичами, да,

самое же сложное этот код потом

заадоптить в общей репозитории, да, быть

уверенным в этом коде, да, вот прямо вот

та ситуация, которую ты сейчас записал,

когда мы такие знаешь, да, мы это кодро

выкинем, а работает он хорошо или нет,

мы быстро увидим на результатах труда,

да? То есть, грубо говоря, я его

написал, запустил, о'кей, пока применим,

потом выкинул. А вот есть ли у вас такой

код, который вы пишете в prodдакш, но

при этом тоже на большой скорости вот

этой?

>> Ну, только только это код, который идёт

на обработку данных. То есть это он не

торчит на наружу, можно сказать. То есть

потому что любая ошибка, то есть код,

который мы запускаем на кластере, там на

сотнях или тысячах видеокарт, а этот код

мы по-любому ревьюем вручную, и там цена

ошибки, но она много денег стоит. А

только если это какой-то маленький

эксперимент, тогда, да, можно

по-быстрому там на одной видеокарте

запустить. Тогда, в принципе, можно и не

ревью его. Запустил, посмотрел. А если

это какая-то большая тренировка большой

модели, то там по-любому ты должен всё

прочекать сам.

>> Угу. Угу. То, что вот именно самая

большая, ну, мне кажется, вот я хочу как

раз засетапить, да, такой некоторый

условия инсайт, да, что самая большая

проблема это как как окружающие процессы

поменять для того, чтобы шипать код,

который пишет с агентом. То есть как бы

не проблема научиться писать коды и

условиям быстро шипать фичить.

Ну, то есть, ну, нормально. Там в три

потока запустил агентов, один

заделиверил, ты ковыряешь, потом второй

ковыряешь, комментируешь, пишешь спеки,

пошёл поел, вернулся весь вечер, пишешь

спеки, потом опять позапускал, вроде

даже норм, ты ловишь этот вайб, лишь

успевай как бы контексты переключать уже

как человек. Вот. А как сделать так,

чтобы всё вокруг в достаточно серьёзной

организации, в продакшн, да,

>> докатываться? Потому что если это будет

всё лежать недели, имея, например, на

проверках, да, там человеческих,

автоматизированных, там будет множиться

неуверенность, да, то он никогда уже не

заделиверится, потому что мы настолько

будем обгонять как бы вот этот вот ээ

процесс вывода кода из, условно говоря,

мра с тампиара в прот, что мы наделим

столько кода, что он просто никогда уже

этот процесс не пройдёт. И вот это самая

большая сложность. Вот, может быть,

просто у кого-то из вас есть какое-то

вот наблюдение, где это уже случилось,

>> где уже получилось это отладить.

>> Я могу только добавить, где это ещё не

случилось. Это когда у тебя есть там

ключи от Google Клауда, АВСа или

какого-то клауда, где у тебя там куча

ресурсов и, в принципе, нету ограничений

по деньгам.

Мы, допустим, мы побавимся давать доступ

вот к таким вещам, чтобы агент сам там

деплоил, разворачивал кластеры,

кубернетисы и прочее, потому что, ну,

это непредсказуемая вещь. Очень как бы

боязно за за деньги, за за то, что он

может там натворить, и там только как бы

в полуручном режиме.

>> Блин, вот это на самом деле очень

крутой, ценный инсайт.

для меня, в принципе, близкий, но не

такой очевидный, потому что у меня под

управлением

в петпроектах, очевидно, нету большой

инфраструктуры,

а

в банке у нас всё очень чётко

менеджерится. У нас там 25 опроволов и

зашипоть что-то, что просто на

вайпкожено просто невозможно физически,

потому что там надо слишком много

галочек проставить.

>> Вот, Глеб, давай перейдём к твоему

опыту.

Слушай, ну вот у меня пока опыт как раз,

да, смотри, он у меня как раз

ограничится тем, что я его сейчас хочу

отскелить, да, и вот этот вот вопрос,

который я сейчас задаю, да, как бы это

ровно тот вопрос, который надо решить,

потому что типа в одно лицо, в два лица,

в три лица не проблема быстро кодить,

да? На в любом стартапе мы можем сесть

примерно, как тогда опять же сказал

Глеб, поделить поляну на три больших

каких-то области ответственности, да, и

бежать в параллели, а потом, если

куда-база ещё вырастет и четвёртого

пригласить. А вот как это сделать

правильно- это вопрос. Я вот сейчас вот

прямо в моменте над ним, собственно, им

задачен. Я вижу следующий набор

действий. Давайте я его сейчас сброшу и,

собственно, подискутируем. То есть типа

первое, нам нужно отказаться от э

кодревью людьми, потому что мы

когнитивно не можем справиться, да. Вот.

Но при этом мы должны взамену принести

практики кодревью агента. То есть мы

должны понять, что должно быть отривлено

в каких-то формальных критериях,

научиться этих агентов там тестировать,

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

мы можем, да, тогда мы можем это

переложить на агентов, да, само кодрев.

Вот плюс сделать практику релизов. То

есть вот вот нам нельзя накапливать

много код. Ну, это ты знаешь классика

trank based development, да, когда ты

там,

условно говоря, ты не заблокированный

может релиз по 50 раз в день, да, при

команде, там, не знаю, там в 15 команд у

тебя огромный коллектив, например, да, и

вот они вот поставляют, поставляют,

поставляют. Ты только трейны потом

делаешь, это выезжает, но взамен ты себя

обезопашиваешь. Требование к тому, как

формулировать код, требованию к покрытию

тестами, ну, типа код, который не

протестирован, лежит у тебя там в

фичевет, никогда не будет принят по

дизайну. Да, нужно очень строго

соответствовать. Мы так риски слева

направо, справа налево двигаем по

пайплайну, да? То есть базовые риски,

что что-то сломается, мы не на квее

ручного перед релизом перекладываем, а

это ответственность разработчика,

который делает вот эту ветку. Вот. И

третье, мы делаем всё покрываем

фичефлагами, делаем поэтапный роут. Ну,

то есть, например, я там сделал

несколько фич, они у меня поехали, и вот

они у меня едут, не знаю, там 5 дней до

продакшена. Сначала 5%, потом 10. Мы

примерно смотрим в каких-то там центрах,

гличпах. Э, если ассоциировано с этим

релизом, э, исключения,

опять же, либо сами смотрим, либо

натравливаем агента на них. И таким

образом мы как бы зацикливаем вот этот

вот процесс быстрой обратной связи. И

тогда как будто бы уже не так страшно,

да, что-то накодил, руками проверил,

агенты пробежали, и ты уверен, что на

самом деле какие-то базовые все проблемы

там будут решены. типа валидация

итизации по безопасности, какая-нибудь

там типа нагрузка, что не будет каких-то

шибко жадных, напри, которые набирают по

200 запросов, чтобы схранить ответ и так

далее. И такой я это отрелижу, и рядом у

меня висит, условно говоря, дашбор

свежих проблем, да, и если что-то

появляется, то либо агент

подхватывается, либо я. Как будто бы это

потенциально новая парадигма, которая

позволит мне, да, релизить продукты.

Отдельный вопрос банковский, отдельный

вопрос сверхвысокие нагрузки. Ну, сами

понимаете, да?

Вот, потому что есть много

зарегулированных процессов, типа того же

самого PCдисса в банке. Вот.

>> Слушай, ну на самом деле ты прикольную

очень тему описываешь. Я вот один из

стейков, про которые мне сегодня

хотелось вкинуть, это буквально на той

неделе кто-то скинул твит Франсуаж Олег,

где чувак говорит, что возможно, мы

сейчас приходим к той точке, что нам

нужно смотреть на современное написание

кода агентами. Так же какLречеры

последние там, я не знаю, 20 лет смотрят

на модели, которые они обучают, потому

что для них это блдбоксом было всегда. И

весь тулинг вокруг моделей, там все

попытки интерпретации, оценки Evoluation

и так далее, они все идут с той точки

зрения, что внутри BlackБоx. В случае с

кодом мы можем его открыть, посмотреть,

что-то поревьюить. Но что если

представить, что мы вообще это не можем

сделать? Вот как раз то, о чём ты

говоришь, что это типа будет просто

невозможно по капасти, по масштабам того

кода, который генерируется. И то, что ты

описываешь, мне кажется, здесь как раз

вот модель, допустим, того же плавного

рулау в ситуации, когда это не

критическая инфраструктура, вот там ты

упомянул про деньги, бла-бла-бла, это

как раз и есть в какой-то степени илы.

То есть ты видишь, у тебя какой там eror

rреate, ты видишь, как у тебя что

меняется и так далее, и так далее. И да,

ты не можешь закрыть на 100% все кейсы

там теми же AI-ревюерами. То есть нет

такого, что ты выстроишь себе такой

workflow, что вообще ни один баг не

пролезет. к сожалению, на текущий

момент, а может и к счастью, на текущий

момент это пока не так, но как раз-таки

кейс, который невозможен, допустим, в

моём случае там на масштабах стартапа,

но кейс, который возможен в крупных

компаниях, где у тебя есть просто

трафик, который статистически значим, ты

действительно можешь прогонять такие

тесты на каких-то минимальных процентов

юзеров и получать полный Blackбоx как

продукт.

>> Да. Да. Тем более ещё тоже такая штука.

Давай это чисто вброшу поржать. Ну,

типа, менеджеры, они же ровно так же

себя вели всю жизнь. Для них этот код -

это BlackБоx. Они приходят к тебе,

говорят: "Дань, вот, вот это сделай,

как-то оно не так, поправь, что-то ещё.

О, готова к ити". Да, вот тебе следующая

задача. Ну, типа,

>> главный скилл делегирования, типа, как

проверить работу, которую ты не знаешь,

как сделать. Ну, то есть у тебя нет

экспертизы, но ты должен её

заделегировать человеку, а потом

получить от него что-то и как-то, а,

типа, вот он хорошо сделал. А это это

очень важный универсальный менеджерский

скилл, который теперь превращается из

категории менеджерского в такою

категорию типа универсального софтскила

для всех. Если не умеешь ставить задачи,

оценивать там работа джептишек, ну

goodck.

>> И ещё последняю мысль вброшу и отпущу.

Ещё мысль такая: "А вот теперь смотри,

вот мы как менеджеры, да, сейчас мы в

шапке менеджеры, мы же что делаем такие,

блин, там какой-то человек сидит,

говорит, что разработчик, я ему

таскиваю, даю, вроде нормально, но как

гарантируешь она будет работать. мы ему

придумываем его соседей с другими

ролями, да, другими экспертизами там,

да, мы их как-то аттестуем, условно там

на входе либо при внутреннем обучении,

неважно, потому что мы доверяем диплому

почему-то там. Вот это всё. Дальше мы

говорим: "Ребята, вот вы тестируете, вы

там по нагрузке, вы там нтун-тесты

пишите и как будто бы на круг сама

система, не давай так, давай по-другому.

сама работа, которую мы проводим, да,

она обязывает выстроить некоторым

образом систему вокруг там, да, с

разными ролевыми вот этими всякими

штуками. То есть работа. Есть такая

шутка, что софт повторяет топологи

организации, но и насали нет. Работа по

организация повторяет топологи работы.

>> Да, это прямой и обратный закон о

конвее. Дададада. Да, именно я про на

него и намекаю. То есть, и на самом-то

деле

ну, типа,

мы можем рассчитывать на то, что мы

сможем с агентами выстроить примерно то

же самое, что мы выстроили с людьми, и

оно даст примерно тот же самый эффект.

Короче, вот. Но это очень сложно

отдать на откуп, потому что мы им не

верим.

>> Слушайте, у меня вот такой вопрос. Артём

заредил очень интересную тему по поводу

кодрев с помощью кодребита и вообще

других инструментов, отличных от

стандартных стандартного тулинга для

разработки.

Глеб, Данил, вы что-нибудь используете

или вы прямо в курсоре или кодексе

ревьюте?

Так,

>> курсор, кодекс, кдко.

>> Если у тебя команда,

они же должны как-то ревью пиары твои

или ты сразу в продакшене? А нормально,

ты можешь меншнить клода в гитхабе. Всё

о'кей.

Ну, вообще по чесноку - это прямо

отдельный большой пайплайн, который

просто так на GitHub не ложится. То есть

это прям отдельный workflow, состоящий

из большого количества шагов. Это не

совсем то же самое, что ты просто там

заменшнил ээ с каким-то промтом агента

на стороне Гитхаба. То есть ээ я

стараюсь выстраивать это прямо вообще

как отдельный кусочек пайплайна, но,

грубо говоря, как часть CCD, то есть,

>> ну, так есть. Ну вот, допустим, код

Rabit, он очень хорошо интегрирован с

Гитхабом. А, и да, он часть часть

CD он вызывается автоматически с каждым

пиаром. Он автоматически может

заблокировать какие-то пиары, если там

ты выставишь какие-то настройки. Плюс он

может сразу же тебе предложить какие-то

изменения, которые ты опять же через UI

тупо можешь кликнуть и принять. Он

сделает

их запрут, ну, закоммитит и всё.

И он отлавливает какие-то вещи, которые,

допустим, ты мог прозевать, если ты

клодкодом там навайп-кодил что-то.

>> Не, я я имел в виду не то, что я

клодкодом только вайпкожу, я имею в

виду, что клодкод выступает же и в роли

ревьюера просто в отдельном workкфлоу с

отдельными там, грубо говоря, промтами,

действиями и всем таким. Я пропускаю,

что кодбиIT сильно лучше. Я просто типа

мне же интересно в этом всём покопаться,

потюнить и так далее, и так далее.

Поэтому такой сырой пайплайн на базе

сырого агента мне в этом плане

комфортнее, интересней.

>> Ну да. Ну просто когда у тебя команда

там 5-10 человек, а ты же не можешь

проконтролировать, какие промты они

используют для ревью. А тут у тебя

централизовано всё настроено. Ты знаешь,

что любой код, независимо от того,

проревью человек его там своими вызовами

или нет, он будет проревью прямо на

гитхабе. И каждый может зайти посмотреть

и прокомментировать

там то, что кодробит тебе наделал. Плюс

код он заточен именно на ревю. И, ну,

ребята уже давно этим занимаются, и они

там всё просто настроили, подточили так,

что это максимально удобно.

>> Много раз про него слышал очень много

хорошего, на самом деле. Ну, типа, не

спорю ни в коей мере, просто сам лично

очень мало его юзал. Ну, кстати, могу,

а, вот интересно было бы послушать твоё

мнение на следующую тему. И вообще как

бы одна из тем, которых прикольно мне

было бы коснуться в этом разговоре - это

насколько у нас появляется отдельная

роль чувака, который отвечает за AI

процессы в разработке. Вот. Ээ я

сталкивался с термитом AI DevOps,

который буквально отвечает за

выстраивание Workflow, за то, что он

следит за корректными там правилами,

настройками всех агентов. Но самое

прикольное - это я видел два, ну так

полтора, если быть честным, кейса. один

прямо очень сочного внедрения, второй

такого слабенького, когда этот чувак

работал вообще в удивительной роли,

когда в конце дня они автоматизированно

собирались с компов разработчиков, э,

sessionнтрейсы того, как разработчики

работали с клод-кодом и кодексом, и

чувак просто реально сидел и

анализировал, где что пошло не так, где

какие были проблемы, и на основе этого

принимал решение о том, где нужно

подойти к Васе и объяснить ему, что вот

так не надо делать, а вот так надо. А в

90% случаев что поменять? Типа в

агентном пайплайне, где там какие

правила, где какие workкflow настроены

некорректно? И это прямо отдельная роль.

И мне вот интересно, как вы считаете,

насколько это уместно под отдельную

роль, на каком масштабе это уместно под

отдельную роль?

>> Да, я тут прокомментирую. Сейчас

называется Dev X Developer Experience

Engнир, не даже не DevOps. И да, такие

роли в некоторых компаниях появляются. И

мне кажется, что они, может быть, будут

появляться всё больше и больше, частично

закрываться

консультантами, частично внутренними

силами в зависимости от масштаба

компании и готовности к э

самостоятельному внедрению. Глеб, ты

хочешь прокомментировать? Слуша, мне

кажется, что, ну, типа, насколько это

оправдано, да, ответственда лежит в

бабках, типа, да, у нас же появились там

всякие джал коучи, скраммастера, то

есть, ну, типа, условия каже, казалось

бы, бесполезные люди, да, но почему-то

почему-то внезапно, да, команды, которая

работает со скраймастерами, например,

они лучше слажены, они лучше деливерят.

И условно говоря, не знаю, там один

скрамай коч, поставь любое название, да,

там на 20 человек, да, он выгоднее, чем

его отсутствие, потому что он по 5%

доусилит каждого. В итоге там вот как

минимум себя собирает там, да, ну именно

в плане денег или леб в плане времени,

неважно как оценивать суть. Вот эта вот

тоже касается каких-нибудь там чуваков

по какому-нибуд там Delivy процессу,

Delivy менеджера. А ты тут неправильно

делаешь, если ты вот здесь заложь

что-то, а ты не будешь тут сталкиваться

где-то не будешь отменять какие-нибуд

там приёмоздаточные испытания, говорят,

там на русском языке там и так далее,

да? Ну, то есть типа вот это наблюдение,

особенно, знаешь, когда практик ни фига

нету. Вот прикинь, ты такой сидишь и вот

просто не втыкаешь, как нормально с

этими агентами работать. Ну вот не

получается у тебя к тебе приходит

человек, говорит: "Слушай, хватит на

Алибаба ленгвиче ему писать". Да ну,

типа, что за розы недорого купить

Москва? По-нормальному скажи, как своему

другу: "Слышь, ты, я тебе что сказал?

Ну-ка быстро добавь вот это, вот это,

ошибок не делай, сделай красиво, приложи

пять вариантов, говори как с людьми". И

вот ты просто так ураз переключился и у

тебя заработало. Мне кажется, это вот

да. Вопрос в другом, что кто-то может,

например, с какой-то этической строй

сказать: "Вот это моё личное отношение с

я им, что он мои там читает логи". Но

это уже так чисто посмеяться.

>> Ну, из тех кейсов, что я видел, это не

было принуждением. Это скорее, чуваки в

целом. Ну, я не знаю, может быть,

добровольно принудительно, но тем не

менее. Но меня просто впечатлило, что

вот пример со скраммастером, мне

кажется, отличный, только с тем тейком,

что, а прикинь, скраммастер бы ещё был

как бы там условно разработчиком,

который дописывает жиру под конкретные

процессы вашей команды. И вот здесь

получается примерно такая штука, что он

с одной стороны понимает, что а вот

здесь проблема в том, что Вася за неделю

один раз с агентом работал, и у Васи

просто ещё практики нет, его надо

попинать, чтобы он пострадал, как бы, и

привык

при притёрся. А вот здесь у нас реально

агент там тупит. И у нас здесь правил

нет. Здесь линтер кривой, а здесь

workflлоow, ничего не проверяет. Вообще

фигня какая-то.

>> 100% это классический продуктовый

подход, да, там типа понял, что у людей

есть проблема, предложил им какой-то

набор решения, а дальше смотрит, как они

этим пользуются, да, там типа вот так же

через логи или опрашиваешь какое-то

интервью, понимаешь, что он интересного

нашёл, интересное всем распространил,

ошибки поправил, круче, круче, круче. У

нас же условно говоря, как у нас, я имею

виду условно, представь, что есть

какой-то набор IT-организаций, которые

хотят произвести трансформацию, переехав

на агентный козинг, да? То есть у нас

есть, ну, типа некоторая цель вот этой

трансформации. Трансформация вещь

сложная. Она вся происходит, когда никто

не понимает, что происходит. В этом вся

сама суть. А если ты уже хорошо

понимаешь, что происходит, возможно, вы

опоздали лет на 10 с ней, да? Вот. Ну,

то есть типа надо же людям помогать,

поэтому всё, мне кажется, очень

рационально.

>> Вот тут у меня вопрос к Артёму. Артём, а

вот у тебя богатый машин backграund. Он

как-то помогает тебе в том, чтобы

выстраивать сейчас процессы в компании.

Не с точки зрения,

что конкретно вы делаете. Понятно, что

resarch - это продолжение твоего

предыдущего рабочего опыта. И тот

продукт, который вы делаете - это

продолжение, видимо, тех наработок,

которые у тебя были до этого, а именно с

точки зрения выстраивания процессов с AI

как инструмент.

>> Просто у меня нет барьеров. То есть мы

начали пользоваться этим, как только чат

GPT появился, да, в принципе, и раньше

какие-то были тулы, а ещё когда на

предыдущей работе работал. Поэтому, то

есть, как натурально, я вырос с тем, как

выросли эти тулы. Но недавно, конечно,

прошёл перелом, когда там код начал

гораздо более качественный код выдавать.

А, и тогда

я просто более активно стал всех

энкаджить в команде, всех вдохновлять,

что, ребята, давайте более активно

пользуемся. Ну, так в мягкой формы. То

есть у нас нет никакого коуча, потому

что у нас, в принципе, мы нанимаем

людей, которые уже готовы к этому. И мы

всегда спрашиваем: "А как бы какой у вас

опыт с различными тулами? Как, как бы,

вы следите за всеми последними вещами

или вы там до сих пор в чат GPT

копируете?" Вот. И как по такому

принципу мы уже обираем людей, которые

заведомо а там в какой-то верхушке

персентиль, которые пользуются этим

активно, и поэтому не приходится прямо

ну насаждать это. А что касается там

остальных процессов компании, то, ну, в

каких-то вещах, ну, это больше как бы на

C-leevel мы это используем, а какие-то

автоматизации, чтобы какие-то вопросы

решать, там legal вопросы, вопросы там с

написанием писем, назначение звонков и

так далее. А, ну для инженерной команды

основное - это это код, работа с кодом.

Глеб, а вы спрашиваете про интервью

умение работать с эагентами? Я уверен,

что Данила наверняка спрашивает. Я тоже

спрашиваю, потому что это часть моей

роли. Уже начал спрашивать, но не

уверен, что все команды так делают.

Точнее, уверен, что не все команды так

делают. Интересно про твой опыт

послушать в интервью.

>> Смотри, организация крайне большая,

поэтому и да, и нет, и давно, и недавно,

и только через год начнём. Ну, то есть

будущее наступает, но неравномерно. Вот.

А мы мы вот мы как раз только недавно

сейчас обсуждали от с ребятами, как как

вообще э какие вызовы перед нами стоят и

как скорее всего нам придётся поменять в

целом процесс интервьюирования, да? Что

если мы хотим работать с инженерами,

которые с глубокой внутренней мотивацией

заряжены с планкой качества, готовы вот

быть вот этими тишейпнутыми чуваками

там, да, вот, то это первое, где я

должна найти отражение. Это в каких в

каком-то нашем, условно говоря, знаешь,

мм, своде принципов, да, как вот аля

манифест. Вот мы мы про что бы, про вот

это или про это? Что для нас важно, что

менее важно, да? То есть вот что для нас

фундаментально там, да, чём ожидаем и

потом выстроить э вокруг этого уже найм

выстроить не мы ещё не выстроили, мы вот

только начали. Я буквально неделю назад

перешёл в новое подразделение заниматься

вот этим всеми вещами. Поэтому вот

через год мы сможем с вами очень

предметно об этом поговорить. Вот. Но

уже вот так вот именно масштабе.

>> Ну, кстати, удивительно, что до сих пор

это не вез Я думал, это уже база. Мы так

делаем. Я так думаю, все, наверное, так

делают.

>> Нет.

>> Ну вот

>> мне как раз, Артём, кажется, что

стартапы они здесь гораздо на фронтире,

особенно стартапы, которые работают см.

То есть они

>> первые, кто внедряют такие практики. Мне

здесь скорее удивительно, что ты сказал,

что всего лишь 50% кода пишет C. Но

потом я понял, почему. Потому что вы

пишете код, которого в принципе ещё не

существовало в природе. Вы используете

такие оптимизации, которые настолько

редки, видимо, и настолько тяжело их

вычленить, что,

э, вероятно, клодкод, ну,

>> должен тогда перейти в всёр режим,

>> да. Ну и это с потолка я сказал, что я

не знаю, сколько. Как бы человек пиар

сомитит. Я же не знаю, сколько он

написал там вручную и сколько, но может

даже и больше, чем скорее всего больше,

чем 50%.

>> На самом деле,

>> А сколько у вас человек в команде?

>> У нас техническая команда 10 человек.

Ну, включая фанудеров, что мы оба

технари.

>> Про написание кода ещё есть одна мысль

очень хорошая. Мне она понравилась. Её

там, по-моему, полгода назад один из

инженеров антропика, э, вокруг неё

сделал доклад. Ключевая мысль следующая,

что, ну, типа код коду рознь, да?

Знаешь, обычно, когда вот в разговорах

там в комментариях где-то в разговорах

где-то в баре мы всегда говорим вида, ну

вот есть код и вот с там, не знаю,

писать его агентами, писать агентами

написали код коду рознь. есть

продуктовый код, например, с в не в

с

не в банках каких-то больших

корпорациях, а вот такой вот обычный

какой-то стартаперский код, да? Вот

это одна часть. Вторая часть - это

не мм бизнес-код вид, например, там

формы обратной связи, там применение

какой-нибудь там скидки, добавление

возможности, там сразу несколько

элементов в корзине там апнуть и так

далее, да? А вот

архитектура. И вот если представить, что

код - это условно как дерево с

листиками, где листики - это вот эти вот

конечные бизнес-фичи, а архитектура -

это вот вот это основной там стволы,

ключевые ветки. Вообще, что такое

архитектура? Это вот те решения, которые

очень дорого поменять, да, типа вот. И

вот эти листики очень скоро точно будут

писаться там под 90, по 95% ээ агентами,

да. Ну, потому что там всё понятно, там

хорошо применяется. SDD, да,

specification dream development. Хорошо,

спико описал, ожидаемые тесты описал,

сценарий даже вместе с агентом сгенерил,

говоришь: "Бу, он сгенерил код,

проверил, работает. Если что, все

перегенерием". Это не и не очень

критично нам какую-то ошибку сделать.

Вот то, например, в какой-то

архитектурный код вряд ли мы вообще

захотим пускать агента. И будет ровно то

же самое, что говорит Артём. Нам

придётся столько всего сформулировать,

что проще просто сесть, накидать самому

этот код по дизайну. Вот такая вот,

собственно, как бы мысль, да. И мне

кажется, вот так нужно это смотреть, да,

чем код более казуальный, чем код более

продуктовый, тем проще его написать,

потому что прутовая задача - это чисто

скомбинировать какую-нибуд там десистему

на основе текущей архитектуры, формально

следуя конкретному описанию там, да,

типа я как ээ как они называются, боже

мой, как как я как дистрибьютор могу

зайти в свой личный кабинет, где вижу

свою скидку. user story. Да-да, да. Я

как позе, я как дистрибьютор при там

добавлении в корзину вижу, что скидка

применилась там, да, я говорю

дистрибьютор находись в корзине,

бла-бла. Ну там всё написано там, ну как

бы нечего делать, но попробуй то же

самое прими к архитектуре.

Сидишь что-то ковыряешь, пытаешься

определить требования, да, читаешь, что

такое архитектура, везде по-разному

пишут, где-то андежарте тестированный,

где-то модульный, что-то друг другу

противоречит, ничего непонятно. И вот

только некоторый опыт и насмотренность,

да, и понимание паттернов позволяет это

начать как-то комбинировать в то

решение, которое должно быть через 2

года, да? И ты примеры прикидываешь, что

сделать сейчас, чтобы прийти в ту точку,

не разорившись на, э, сравлении хаосо,

на энтропии, да? Ну, знаете, да, что

такое энтропия кодовая базы? Условно

приходишь к разрабу, сколько стоит

добавить вот эту штуку? Ой, сколько

стоит сделать эту штуку? Ну, часов

восемь. А в эту коду базе о там 40, да?

Это вот число энтропии, да? Это вот

количество. сколько должен помножить

идеальное время на эту работу в какой-то

кодовой базе. Ну вот,

>> ну вот, кстати, у антропиков же как раз

и была история на тему того, что ээ

первый такой важный переход разработчика

в использовании и заключается в моменте,

когда у него появляется интуиция

относительно того, что ей может, что не

может. Она вырабатывается только, если

ты там, ну не знаю, часов 40 хотя бы с

ним провзаимодействовал, и у тебя

случается вот это вот волшебный аха

момент, когда ты такой: "А эту задачу я

даже не буду пытаться тратить своё время

на объяснение и потому что он всё равно

не справится. Я это точно знаю. Я её

пишу руками". И ты перестаёшь терять

время на том, на чём он не справится, а

всё остальное откидываешь на него. Но на

самом деле, я бы так сказал, второй

уровень Дзена этой истории, это вот я

упоминал этот термин prom to action,

когда ты используешь и просто как

печатную машинку, то есть ты ему голосом

очень детально объясняешь, что ты

конкретно хочешь получить, а он тебе

просто выдаёт практически там идентичный

код тому, что ты хочешь, и у тебя в

итоге всё разваливается на там условно

0,5% того, что и ну прямо вот никак не

заставить написать. Какая-нибуд там

очень сложная скуча кейсов многопоточная

архитектура. Дальше у тебя идёт условно

там 30% prompt to action, когда ты

надиктовываешь просто вот чётко, что

конкретно надо сделать вот в

архитектурных, сложных критических

местах, а всё остальное типа он так

напишет.

Но чтобы эту грань начать чувствовать,

надо зачастую заставлять и людей, и

себя, и всё вокруг просто учиться,

пробовать.

Я бы ещё добавил, что всё равно вот я

слышал подкаст Андрисона,

а и он тоже высказал такое мнение, с

которым я полностью согласен. Это что,

чтобы максимально хорошо писать код с

помощью агентов, ты должен уметь писать

код сам. Так же самое, как раньше было:

"Чтобы писать хороший код на Питоне, ты

должен знать C++, а до этого, чтобы

писать хороший код на C++, ты должен

знать C. А до этого, чтобы писать на C,

ты должен хорошо знать ассемблер. Ну,

как бы всегда хорошо, когда ты можешь

спуститься на один уровень ниже

абстракции. То есть если ты йпкодишь и

ты при этом хорошо программишь на

Питоне, а то ты, скорее всего, быстро

поймёшь, во-первых, что он накосячил

тебе. Ты сможешь его запромтить, так,

что он быстро решит проблему твою. А

если ты ничего не понимаешь, ты можешь

там 4 часа ему говорить: "Слушай,

пофикси это, пофикси это". Он там

поломал другое. И опять, ну, то есть

когда вот человек вайпкоит без особого

понимания, у него гораздо больше времени

уходит на любую задачу, чем у человека,

который умеет писать код. Который,

во-первых, может сразу же направить его

агента, а во-вторых, он может просто

открыть там и одну строчку поменять и

всё, и проблема решена. То есть ты

видишь лок вот такой километровый. Если

ты опытный чел, ты понимаешь, в чём

проблема. Ты попробовал один раз, агент

не решил, такой: "Ладно, я открою сам

просто там исправлю одну вещь. Всё."

Вот. А в этом и срабатывает магия, что

ты не можешь научиться вот этому

ощущению баланса, с чем и справляется, а

с чем нет. Если для тебя критерий

понять, что он не справился, это когда

через 2 недели ты просто потерял

возможность поддерживать свой продукт,

ничего больше не работает. То есть как

разраб ты можешь в моменте понять: "А

во, он свернул не туда, всё плохо, ну,

типа у тебя мгновенный фидбк-луб, а

здесь у тебя супер отложенный

фидбэк-луб, и ты даже не знаешь, какой

из твоих там 300 промтов за эти 2 недели

в действительности привёл вот к этой

гадости в конце."

Кстати, мне ещё одна понравилась шутка

по поводу, что если и я, и в разработке

это X1 бустер, да, это вот что ты

бустишь, то и получишь там, да, вот

какой ты разработчик, если ты плохой

разработчик, garbage out,

>> да, да, держитесь за стулье, это будет

прямо вот во все стороны, да? А если ты

как бы хорош, да, и у тебя хорошие

светлые мысли, ты чётко видишь тот образ

результата, к которому ты хочешь прийти,

и ты достаточно умеешь выража свои

мысли, чтобы провести систему в это

состояние супер. Ну, как и с людьми вот

тоже, да, вот когда мы были там

маленькими, типа, да, ещё, ну, у тебя

есть команда. Вот если ты абабабабу,

ну, то есть ты ничего не можешь сказать,

ну, всё, ну, у тебя соответствующий

результат даже с умными людьми. Ну, на

сльту то же самое.

Ребят, мы довольно много поговорили про

принципы. Давайте каждый сформулирует

вот буквально по одному совету, как

темдам инженеринг-менеджерам

эффективнее внедрять

viбbeкодинг разработку. Желательно,

чтобы они были не банальные, не из того,

что мы только что проговорили. Здесь

много интересных инсайтов. Может быть, у

вас есть ещё что-то. Вот совет для

менеджера. Одни там парочку предложений

максимум.

Пока пауза, давайте я сформулирую свой

тейк, который уже здесь был озвучен. Но

я действительно считаю, что самое важное

- это экспериментировать, учиться и

пробовать. Потому что, если у вас,

например, в рабочем окружении нет

возможности экспериментировать, учиться

и пробовать, попробуйте сделать какие-то

пд-проекты, попробуйте на своих там

домаш на домашнем компьютере

попробовать другие инструменты, которые

у вас нету доступа в корпоративной

сетке, просто чтобы понять фронтир

технологий, просто чтобы понять, а что

вот ещё и так бывает. Потому что, когда

человек из крупного корпората внезапно

сталкивается с тем, что же есть уже

доступного на рынке, у него может быть

просто шок, потому что в корпоратах всё

ещё

сайты могут делаться на Play, ну, не

Playш Mail, конечно, но там без

какого-то вайпкодинга вообще ндосы,

который сейчас реплит lavable щёлкает

только так. Вот это, наверное, мой тейк.

Давайте пойдём по вашему. Тебе надо

ткнуть в кого-то. Мы слишком вежливы и

могу вкинуть

>> недавно.

>> Пусть Артём, пусть Артём начал говорить

>> на ивенте стартаперском в Сурихе, а

организовывал АВС и YC, и там было много

пичи из последнего батча YC, ну или там

последнего года. И вот один из стартапов

они как раз делали, а типа тулу для

ускорения менеджеров. По сути, это такой

цифровой конслагерь, который мониторит

все слаки. все чаты, все имейлы, все

активности на гитхабе. И у тебя такие

дашборды по каждому чуваку. А его

активность. И если там, ну, зелёненький

график, зелёный, если он просаживается,

ты можешь типа дать ему втык, ээ,

сказать, что, чувак, что-то мало там

пишешь сообщений в слайк, наверное, ты

халтуришь, а или там у тебя мало там

активности на гитхабе. Но я посмотрел,

мне не очень это понравилось. Ээ, я

думаю, что многим людям это тоже вряд ли

понравится, но какие-то вещи, наверное,

для мониторинга какой-то статистики, ээ,

для менеджера, чтобы понимать, что

человек там, не знаю, что-то загрустил,

может быть, это может быть полезно, но в

меру, потому что иначе это превращается

в цифровой концлагерь.

Ну, можно же прямо очень сильно следить

за всеми, особенно с текущими

возможностями. Э, больше, чем раньше

там, знаешь, логеры на ставили на

экраны, это как бы цветочки. С текущими

возможностями можно прямо вот

не говорить,

>> да, вм,

>> да,

>> мне настолько страшен этот тейк, что я,

пожалуй, даже его записывать не буду,

чтобы не дай бог люди не решили, что мы

это пропагандируем.

>> А уже есть такой стартап.

>> А вот он не европейский наверняка,

потому что в Европе в большинстве стран

запрещено следить. Американский сказать

скорее.

>> Ну, видимо, но больше похоже на

китайский, если честно.

>> Я

>> Пайкомбинатор,

>> знаешь, думаю, что просто вот эти вот

люди, они они же стартаперы, это же

молодёжь, как правило, и как правило,

ну, не обогащённая жизненным опытом. Там

их ждёт то, что они выучат, да, что

есть, например, закон Гудхарда, да, то,

что цель, которая поставлена в Китай,

ну, начинает врать. Ну, просто, да. Ну,

то есть люди в целом стремятся

адаптировать своё поведение. Таким

образ, что соответствовать цели. В этом

идея целей, но если поставишь в цель

количество комит, у тебя их увеличится в

500 раз. Базаразиро

каждый сила могу в ковид, в комит

завернуть. Ну, типа, вот и всё. Ну то

есть

вот, да, если ты не измеряешь, ты не

управляешь, но с этим нужно быть очень

осторожно, иначе можно всё испортить, и

тогда, ну, пожалуйста, внедряйте люди в

организации вот это всё дело. Это же

прекрасно. Из них уйдут лучше, останутся

те, кто готов с этим мириться, да, и

возможно ничего слабо, что из себя

представляющей, и мы только выиграем.

Так что в этом плане, пожалуйста.

>> Ну, я могу вкинуть.

>> Давай

>> просто пока мы с той темой не закончили,

что ничто не нового под луной. Я, честно

говоря, такие проекты ещё лет сем назад

видел, но они очень красиво

упаковываются. Они это упаковывают в

форму того, что это мы предсказываем,

что сотрудник начинает двигаться в

сторону того, что хочется уволить

уволиться. И мы таким образом даём вам

observability tool, чтобы вы его

порадовали, чтобы вы вернули его

мотивацию, как бы, и веру в компанию. То

есть они это переупаковывают не как

идентификация неэффективности, а как

идентификация, ну, типа недостаточно

вовлечённого по причине личной грусти

человека, чтобы ему помочь.

предсказывают чёрный отток просто

предсказываю. Да, да, да, так и есть.

Раньше по слаку это делали, сейчас,

видимо, яишки стали сильно-сильно умнее.

>> Слушате, ну вот мы сейчас смотрим на

мониторинг отдельных сотрудников, и

давайте поговорим про метрики внедрения

в организацию. Вот я, Дань, я помню у

тебя был офигенный доклад на одной из

наших предыдущей конференций, где ты в

том числе покрывал, как же мерить

эффективность. Может быть, ты скажешь

пару тейков оттуда.

О, а это как раз на Сратоплане-то и было

в декабре. Я рассказывал, ну, один из

главных тейков, который мне больше всего

нравится, на которые я рекомендую всем

обращать внимание, это то, что очень

часто смотрят на увеличение количества

пиаров, на увеличение количества там

поставки фичей и так далее, но мало кто

нормально детектит реальный time to

market, реальный там аля количество

режектов от QA, насколько меняется,

насколько меняется конечный time to

marкеet и так далее. И мой главный

совет, который я бы здесь просто сказал,

то, что не забывать про это, да, вы

можете словить вау-эффект в первых парах

интеграции, что у вас там все фичи

залетели в пулреквесты, не знаю, за 2

дня, и у вас большая проблема теперь,

какие задачи разрабом ставить. Но в

реальности как бы всё может быть лукаво.

И отсюда же проистекает история,

связанная с тем, она как бы она даже для

не и мира очень хорошо подходит, что

если разраб пишет какой-то код, а, и QA

проверяет этот, ну, как бы эту фичу и

обнаруживает ошибку в каком-токейсе, то

не ругают никого. Все молодцы, все

обнаружили экзотический кейс, всё круто.

Но если вот есть некий

successкessс-сценарий, который

предполагается самым главным от фичи,

ну, условно, ты нажал кнопку, показался

арт. Это главный сценарий не в каком-то

экзотическом кейсе, а вот прямо так. И

когда Q это проверяет, это не

срабатывает, то за это обязательно надо

давать втык разрабу и доносить ему, что

это его полная ответственность. Проверка

первого главного successс-кейса - это

полная его ответственность. Почему это

правило важно си, я думаю, очевидно,

потому что если ты скинул промт в

cД-код, потом нажал кнопку комит, нажал

сгенерирование описание к пиару и так

далее, то, ну, в принципе, как бы зачем

ты здесь? Ты не архитектурную целость не

прочекал, не проверил, что это вообще

хоть что-то работоспособное и так далее,

и так далее. Мне кажется, это важный

момент с точки зрения распределения

ответственности. И чтобы не сталкиваться

с этим бутылочным горлышком, когда у вас

невероятно вырос time to QA, но

невероятно при этом офу, невероятно

уменьшился time to QA, но при этом QA

захлебнулись, у вас time to market вырос

там в 70 раз. Так может быть, ну как се

в 70 раз вырастет, это заметят сразу.

Но, к сожалению, иногда просто не

замечают, что вот конечный time to

marкеet может упасть на там 3-5%.

кажется, что вы летите, что у вас всё

круто, разработчики вообще плачут от

счасти, потому что они теперь код руками

не пишут, а в действительности вы там

чуть-чуточку просели, как бизнес,

поэтому

>> а не всё, мысль закончена, поэтому за

этим надо следить. Я бы ещё добавил бы

одну штуку, что, знаешь, вот под всей

метрикой я подписываюсь там, да, должен

быть некоторый баланс этих метрик там,

да, с багами, но не только багами,

которые поймались до прода, но ещё

накопленные с этим комитом, с этим

релизом, с этой фичой там за пару

месяцев, потому что, ну, весна покажет,

кто где срал, грубо говоря, да. И вот

если, например, я прямо вот плохо

работаю, на дистанции всё будет видно,

потому что там повылетают баги. Ну и как

раз, да, вот типа критичность багов там,

да, типа P0, ну а P4, ну слушай, мелочь

бывает там, да. Ээ и важно, что баги

должны быть как, то есть не должно быть

критичных, что вообще нельзя сделать ту

фичу, на которую нас у слонимают.

Привет, Jobs to beдан. Но очень важно,

чтобы э баги были, потому что если багов

совсем нет, то это значит мы тратим

очень много времени перед тем, как мы

релизимся. Вот у Амазона мне очень

понравилась, была такая типа практика,

что что-то багов мало, давайте увеличим.

Почему? Потому что мы слишком много

корпеем над кодом, нам нужно быстрее

меняться. То есть скорость изменения

должна быть. Вот. И, собственно, та уж

завершающее, Макс, то, что ты просил,

две вещи, две мысли, что первое, чтобы

это всё внедрять, я очень считаю, я я

драматически уверен в том, что надо

писать самому. Если не пишешь сам, что

ты, как ты можешь внедрять? Вот просто

как, да, вот я

>> потому что или как

>> с агентами. С агентами, да. Ну, то есть,

чтобы агент разработка, нужно быть прямо

этим петралхедом. Нужно быть просто

жёстко этим ужаленным, да, потому что

иначе для тебя всё будет сложно,

непонятно, вроде норм, мне что-то

продают и так сойдёт. Нет, ты должен в

этом разобраться, да? Ты должен быть тем

самым лидером, который сам пишет,

показывает другим, как, да, и только

своим примером, только своей энергетикой

и своим вот этим вот небезразличием ты

это заведёшь. Потому что реально людей

надо вдохновить, что они такие: "Блин, а

прикольно. Я думал, что эта фигня у меня

до сих пор там, да, типа вот я только

что сделал опрос, там каждый шестой

говорит, что типа с агентом моя жизнь

стала хуже". Я понятия не понимаю

почему, но я подразумева представляю

почему. На самом деле, да, представляю,

да, потому что не получается что-то

неправильно, какие-то практики, ой, всё,

короче, не грузите и дайте колод, да?

Это первая мысль. А вторая мысль, что

надо вспомнить все фреймворки, все

практики организации человеческой

деятельности. С одной стороны, их надо

помнить, потому что с них, ну, надо

делать выводы, надо делать аналогии.

Эти все практики будут работать, но не

так, как мы привыкли, да, поэтому от них

нужно при этом забыть там, да, но иногда

такие: "О, так тут же конбан подойдёт,

чисто поток, у нас маленькая обратная

связь, ТБД, но по-другому там и так

далее, да, потому что не надо ничего

придумывать с нуля. Всё уже придумано.

Мы там 30 лет там очень активно

придумали практики гибкой разработки,

да, когда у нас нету плана на на 5 лет

вперёд, да, так давайте им дальше

следовать просто, да, у нас, как опять

же Глеб Кудрявца вчера сказал, буду

много о нём говорить, что, э,

драматически сокращается цикл планирую,

там мы планируем буквально на день там,

да, нам нужно аж три каких-то синка,

если мы рядом друг с дружкой пишем один

и тот же проект и так далее. Вот. То

есть всё работает просто по-другому. Вот

такая вот, собственно, мысль.

>> Ребят, давайте, перед тем, как перейти к

вопросам из чата, на эту рубрику, у нас,

видимо, останется минут пять, поговорим

про личную эффективность

даже не так, про то, как вы видите

э развитие отрасли и то, как оставаться

востребованным в будущем. То есть, чтобы

не выпасть с рынка

как сотрудник или как стартапер, как

предприниматель, что угодно в вашем

конкретном случае, в вашем конкретном

контексте, как ир опять-таки, что вы

делаете, чтобы э быть на острие, ну или

хотя бы неуволенным?

Давайте начнём, Данил, с тебя.

>> Давай. А,

слушай, мне кажется, самый главный

перелом в том, что тебе недостаточно

просто смотреть, тебе очень важно быть

hands on. То есть, ээ, да, безумно всё

быстро меняется, да, тулов этих выходит,

ну, прямо отвратительно много. Ээ, но

способ хоть как-то немножко отсеивать

зёрна от Plav - это вот буквально брать,

тестить, смотреть, потому что, как ты

верно заметил, э- реальные вот вот до

сих пор начало 2026 встречаются люди,

которые тыкают агенты и такие: "Вау, оно

так умеет". Э, и беда в том ещё, что ты

мог потыкать клодко там год назад, а

сейчас это вообще другое. Ну, то есть

самый простой способ не устаревать. Это

как бы банально это не звучало, но тем

не менее продолжать тестить и не

забывать о том, что твоё мнение, которое

сложилось даже там 3-4 месяца назад, оно

может быть уже ужасно устарела. Ну то

есть отслеживать новости за там

условными революциями, э и при этом

продолжать использовать тулы, продолжать

использовать наработки и всякое такое,

мне кажется, это невероятно важная часть

этой работы.

О'кей, Артём,

>> нужно оставаться, то есть то я про проду

про проду про проду про продублирую

Данилина мысли Данила, а что нужно

всегда кодить самому, выделять время на

это, если ты менеджер,

пробовать новые тулы. То есть я

регулярно там тыкаюсь с этим глодкодом.

Ну, в принципе, я и впро тоже коммечу. А

кроме этого я постоянно читаю статьи

научные. чтобы оставаться в понимании,

как это работает и что нового. Ну и у

меня канал как раз про это. То есть я

постоянно трекаю, что выходит нового. Я

пытаюсь понять это хотя бы, если даже

если не запускаю какие-то вещи, просто

понять на уровне интуиции, что это может

принести. И пишу об этом посты. Это

помогает мне тоже быть в тонусе и ээ

быть в тренде и понимать, что сейчас

актуально.

Ну, кроме этого, да, самое важное - это,

конечно, пробовать руками, потому что

понадеяться на что там пишут в

интернетах не всегда можно.

>> Но нам можно.

>> Ну, нам можно. Да, мне очень нравится

следующий тек. Хочешь чему-то научиться

сам, попробуй научить этому других.

Вот примерно поэтому, наверное, все мы и

ведём свои Telegram-каналы,

по крайней мере, отчасти. А, Глеб, давай

перейдём к твоим терикам.

>> Да, я бы что сказал, что

мы только начинаем полноценно заходить

во всю эту штуку, поэтому очень много

казуального, очень много каких-то там ээ

девочек-мальчиков с Балею

восемнадцатилетних, которые

рассказывают, как писать с агентами. Да,

этого очень много в интернетах. Поэтому

действительно сейчас особо ничему там,

ну вот просто наблюдая за этим не

научишься.

Вот я максимально поддерживаю тему, что

только когда руки полокоть, да, ты

понимаешь, куда дует ветер, да, и причём

это постоянно надо сейчас держать. И вот

я, например, как я весь прошлый год

практически история жизни, моя история,

я у меня не было времени сесть покойдить

с агентами, прямо совсем. Вот. Но 30

декабря я такой: "Всё, пора". Я по часов

по 12, по 15, короче, сидел в новогодние

праздники, люто кайфую, просто люто

кайфую. Писал, писал, писал, писал.

Яварь случился. Я тоже писал, писал,

писал. Сейчас более-менее начинают

отпускать. Да. Это просто такая присада,

я вам скажу, ребят. У тебя вот этот

дофаминовый цикл, который раньше там,

да, он тебя подкармливается вечером

двумя-тремя тасками, сейчас под

кармлится 10юпцами фичами в день, да, и

это просто невероятная вещь. Вот поэтому

моё, как сказать, напустое совет

предложение, да, если хочешь в этом

разобраться, только сам. Вот сейчас

самый лучший вот день вот в жизни

вообще, да, вот чтобы этим сейчас

заняться, вот просто сесть, купить под

подписулю, там какой-нибудь кладкода,

кодекса, даже неважно чего, и просто

начать с этим кодить, потому что реально

там у тебя 5-7 дней проходит, ты такой:

"А вот что оно может? А если я,

например, начну пользоваться какими-то

фрейворками вокруг этого всего дела, да,

из со скилов ещё пять сем дней, а и вот

эти у тебя, а, постоянно происходят, да?

И вот я считаю, что в общем надо держать

тонус, даже если сейчас пока что в

компании никто не пишет. Ну а если вы

жёстко этим заразитесь, вы всегда

сможете прийти к своим руководитем,

сказать: "Ребят, а вам нужен тот, кто

конченный, кто вот прямо вот об этом

только и думает. Давайте я этим займусь,

я внедрю".

>> У фронтендеров вообще просто потому что

код, ну, раскрывается, да, перед

исполнением на клиента, но он вообще не

является тайным. С бэкнерами сложнее,

ну, попробую договориться там с

безопасностью и так далее. Вот. И мне

кажется, что это сейчас самая выгодная

стратегия поведения. Мы не знаем до

конца, что нужно будет уметь, мы не

знаем до конца, к чему это всё придёт.

Но надо просто двигаться вместе с этим,

потому что действительно можно внезапно

для самой себя случайно просто морально

устареть,

>> а потом будет реально

>> сложно будет потом.

>> У меня здесь лайфхак по

тайм-менеджменту. Сделайте себе день, ну

или хотя бы полдня без митингов, без

встреч, который будет посвящён

исключительно кодингу с инструментами,

лихтестированию и использованию. Я вот

себе полдня выделил в неделю и очень, э,

рад этому, что могу с чем-то

поэкспериментировать, что-то поделать. И

если вы это не внесёте в календарь,

скорее всего, это просто схавается

очередными вантуванами, решениями

пожаров, разгребаниями, там, не знаю,

накопившихся сообщений в почте и так

далее.

Вот. А самое главное, Макс, последняя

мысль, простите. Самое глав самое

главное, что всегда у разраба есть

кантитет. Вот сделал бы такой плагин,

который мог и так далее. Но мы все

такие: "Блин, я нужна команда из шести

человек на полтора месяца". Я вот, ну,

там пару вещей на вайбкойделпишка. Одна

из мпишек, я её оцениваю месяцев четыре

работы команды человека из

четырёх-шести. Она у меня на

навайпкодилась просто между делом на

выходных. Вот скоро её там типа выложу

уже, да, я уже запиливаю. И в этот

момент я там ещё порешал кучу разных

проблем, поэкспериментировал на реальных

кейсах. Написано 700 юни-тестов, 300

NN-тестов, разобрался, как правильно

делать так, чтобы этот тест нормально

описались автоматически, всё. Ну,

короче, вот там много всего. Ну, и ещё и

вы немного качнётесь в продуктовке,

потому что вам будет, ну, б задача вся

какую проблему решать и так далее.

Короче, одни плюсы. Вот одни плюсы для

инженеров.

>> Да, согласен. И, кстати, вот

возвращаясь к теме персональных инсайтов

и продуктовки, я считаю, что для

инженеров очень важно понимание продукта

и бизнеса и развивание

продукт-менеджерских скилов. Потому что

если раньше было достаточно просто

транслировать спеку или джиры в код,

который подготовил продукт owур, то

сейчас в какой-то момент, возможно, вот

эта прослойка уже будет так сильно не

нужна, и вам нужно будет залезать либо в

кишочке инфраструктурной настолько

глубоко и быть настолько уникальным

специалистом, который невозможно

автоматизировать клодкодом или кодексом,

либо же двигаться в сторону бизнеса и

продукта и понимать, как же и зачем. М

же самое главное, нужны эти фичиться с

пользователями и понимать, что вы вообще

делаете за продукт, кому он нужен и как

он будет использоваться.

Давайте всё-таки потратим хотя бы 3-5

минут на разгреба накопившегося

количества вопросов.

Расскажите ваши мысли про техдолг в

контексте стопроцентной разработки.

Давайте я спрошу этот вопрос Глеба,

потому что у него, возможно, самый

большой, может быть, техдолг, так он в

компании крупной работает.

>> Я пока за компанию ещё ничего не скажу.

А, прости, пожалуйста, я отвлёкся тоже

начать с вопросами. Да. Какой был

вопрос? Как разгребать тер долг?

>> Да, при стопроцентной разработке.

>> Знаешь, мне кажется, разгребать его

очень легко. Это легче, чем всегда было.

Вот, например, вот я сейчас за в финале

вот эту MVPшку уже там в рабочий

продукт, да, и мне нужно было,

собственно, пройтись, её причесать, да,

покрыть всё критические пути энтуэндами,

покрыть корнеркейсами, юнитами,

прошерстить всеуреализацию на предмет

каких-то там недостатков и там

производительности безопасности. Слушай,

прекрасно. Надел себе вот этих аля

агентов сшскилов там, да, по очереди

понатравливал на куски базы. Например,

вот, например, да, у меня был в какой-то

момент списка 170

НТНте, которые нужно сделать там, да?

Вот. Ну и я запузырил агента, он его там

писал, 3 часа пописал, устал, ты его

снова толкнул, опять пишет и так далее.

Раньше такое, да, я делал. То есть

расписывая все эти задачи просто днями,

да, привлекая там тестировщиков, да, всё

расписывая на ребят. Ребята это всё

неделями делали, а сейчас я просто сижу

и как бы, ну, просто менеджерю процесс,

да. Вот. То есть сейчас с техми работать

сильно проще. И это касается тех внутри

проекта. Если мы говорим совсем о legсе,

legacсе, которая досталась все

классические практики, напиши юнитеста

на это LEX как на чёрную коробку и

начинай поэтапно переписывать там, да?

с агентами просто как никогда, да,

потому что никто не устаёт, никто не

носит, что это какой-нибудь там Ангуляр

первый, там знает, что это Jquри, всё

нормально. Вот в отличие от

переписывания такого проекта с людьми,

всё вообще нормально. Вот реально. Так

что не вижу проблем.

>> Круто. Спасибо, ребят. У нас, на самом

деле, уже подошло время к концу.

Давайте, может быть, каждый скажет по

самому главному ключевому тезису,

который хотел бы поделиться с

аудиторией. Пока я пытаюсь из гранолы

сделать mindap, чтобы показать, что же

получилось по сравнению с моим ручным

ассистированием во время встречи и что

могут делать другие инструменты. Да,

кстати, я ни в коем случае не пиарю

конкретно данный инструмент. Мне просто

самому лично было интересно

потестировать, вывезет ли он из такого

полубraйнстор формата что-нибудь

полезное. Я немножко сомневаюсь. Данил,

давай с твоих с твоего самого главного

тейка.

>> Самого главного тейка. Много таких

хороших было. Слушай, а

пробуйте, пробуйте и тестируйте руками.

Если в середине двадцать пятого я видел

увольнение программистов за

неиспользование и, то в этом году, я

думаю, мы увидим увольнение тимледов за

то, что они не выстроили внедрение и в

своей команды, потому что, э, идея

сверхэффективности дошла уже до

си-левелов, и они этой эффективности

ждут. Вот scriptable, если у вас iOS,

если вы хотите персональную

эффективность, хотите что-нибудь с

агентами кодить под телефон, то

невероятно удобная штука.

Блин, прикольно. Вот про увольнение

тимледов или руководителя разработки,

это прям

довольно сильное утверждение.

>> Идея для отдельной конференции,

>> да, и кажется идея для отдельная как

минимум встреча, но, пожалуй, в каких-то

компаниях это точно будет происходить.

Не во всех, конечно, но в каких-то

точно. Артём, твой главный тейк?

>> Не знаю, не хочет повторяться. Я вот

сейчас сидел, думал, что бы сказать

такого, что кроме пробуйте.

Наверное, я посоветовал бы, ну, это не

для каждого, мне кажется, разобраться,

как это работает.

Если не просто пробовать, то

разобраться, понять, почему это

работает, как это работает под капотом,

чтобы была ментальная модель и интуиция,

что ага, а как код ищет по моей папке с

кодом. Ну, наверное, он проиндексировал

все, а, все мои файлики разбил на части.

И когда он ищет, он просто достаёт из

векторной базы, подкидывает это в

контекст. А из контекста вот в итоге

выводит что-то там резание, цепочку

вызывает, а, агентов разных смотрит на

вывод и решает, что ему делать дальше.

Ну вот как бы хотя бы на таком уровне

можно чуть лучше копнуть. Вот как

работают эти модели. Это, ну, мне

кажется, это полезно для понимания тоже

каких-то узких мест. И если вдруг вы

строите что-то сами с помощью там API

колов или с помощью там openсорсов

моделей, то это особенно поможет вам в

эффективной разработке, э чтобы

построить какие-то свои решения на этом.

>> Круто. Спасибо.

>> Не обязательно прямо научные статьи, я

думаю, читать для этого. Можно, на самом

деле, даже початиться с тем же чат GPT

или Gй, и он раскидает он за интуицию,

как это работает.

Так, ну закущ, значит,

а давайте я сегодня буду, значит, за

главного мотиватора, да, я у меня нету

культа личности Стива Джобсо, но я его

процитирую. Он как-то выступал перед

какими студентами и сказал, мне кажется,

суперважную мысль, да, на английском она

звучала так, что hungry, stay fлиh, да,

ну, типа будьте вовлечёнными,

безрассудными, не безразличными, вот это

вот всё, да, это, мне кажется, очень

важно, потому что вот, э, как это, я

честно не верю, что какие-то хорошие и

вышие сверх, да, результаты могут быть

достигнуты безразличными людьми.

различные люди могут только там вот

снизу где-то пройтись под приборами там,

да, вот на уровне там травы под

деревьями. Ну вроде прокатило, знаете,

что-то сделал, вот это вот всё, да,

поэтому такого я врагу даже не пожелаю,

да, быть безразличным к своей работе.

Вот я считаю следующе, что крайне важно,

да, быть по-настоящему внутренне

замотивированны. Вот это внешнее. Ну

давай, ну Макс, мы сейчас тут накры ты

такой: "Э-й", ну да, типа, ладно, да? И

вот человек идёт что-то делать. Даже

мотивация внутри, да? Это вот, кстати,

вопрос нас там к смыслу жизни вашему

личному, вот этому всему там, да, но вы

нафига делаете то, что вы делаете? Вот

должен быть внутренний стимул и

внутренняя высокая планка качества,

потому что тогда вы будете не безразличи

к тому, что вы делаете плохо и вы не

будете согласны делать плохо, и вы

будете стремиться вперёд. Вот это вот,

мне кажется, самое важное. Поэтому вот

быть жадным и кайфовать от этого. Если

вы не кайфуете, возможно, не надо себя

заставлять этим заниматься, потому что

полно неизвестного, ничего непонятно,

постоянно всё меняется и непонятные

ожидания, но очень высокие там, да,

бежать надо быстрее всех зачем-то, да,

опять как это этот Алис Родес, да, чтобы

остаться на месте, нужно очень быстро

бежать. Вот поэтому по любви и с кайфом.

Вот

>> круто. Спасибо большое.

Вот я попросил построить тем временем

майнap нашей беседы.

В целом,

как Mindmap выглядит неплохо, наверное,

лучше будет попросить потом сделать,

накидать конкретные тезисы.

Вот. А, кажется, я зря всё это

конспектировал.

Вот. Но лично для себя самому мне

гораздо удобнее что-то записывать, чтобы

запоминать. Вот поэтому один из важных

моих тейков контринтуитивных, иногда

что-то полезно для личной эффективности

делать по старинки, как вы считаете,

делать максимально эффективно, лично для

себя и не пытаться внедрить

технологии там, где вы считаете, что вы

и так уже достигли максимума

персональной эффективности.

Иди, наверное, нецелесообразен.

Вот.

>> Да. Ещё самое важное. И Боже упаси.

влюбиться в этот микроскоп и пытаться им

забивать гвозди. Есть вещи, которые вы

умеете делать эффективнее, быстрее и

дешевле, да, предыдущими инструментами.

Пусть так и остаётся. Вот.

Вот. Спасибо большое вам, ребята. Мы

немножко вылезли за тайминг, но мы,

наверное, с самого начала были слишком

оптимистичными, что можно за час уложить

настолько плотную, интересную тему. Я бы

с удовольствием продолжил бы ещё беседую

пару часов. У меня где-то треть

вопросов, с которых я заранее

подготовил, были покрыты. Вот. Так что

передаю слово Коле и нашему следующему

спикеру. Всем спасибо. До скорых встреч.

>> Всем пока. Пока-пока.

>> Спасибо. Пока.