AI Hard Fork: Обучение, найм и увольнение в эпоху ИИ-агентов — Николай Шейко

Всем

здравствуйте. Добрый день, добрый вечер.

Конференция IHard Fork выходит на

финишную прямую. У нас сегодня третий

день из наших трёх запланированных. Вот

у нас в эфире, как обычно, мы, Коля и

Саша. Коль, привет.

>> Привет. Привет,

>> привет. Привет, коллеги. Всем привет.

Рассаживайтесь поудобней. У нас

традиционно чат первые минуты эфира

заблокирован в рамках борьбы с

зумхакерами. Потом мы его включим и

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

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

которые вам будут интересны и любопытны.

Конференция Fork. Мы её задумывали для

того, чтобы поговорить про то, как и

меняет процесс разработки и в основном с

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

управления разработкой. Сегодня у нас

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

том числе про людей. Вот. потому что они

у нас как-то остались за рамками, мне

кажется, первых двух дней. Но сегодня мы

про людей точно поговорим. Ну и давайте

пару слов про организаторов, потому что,

может быть, кто-то пришёл к нам только

на третий день, ещё этого не слышал. Про

энтропию толк Коля расскажу чуть позже.

Я одуваюсь за Сратоплан. Стратоплан -

это школа менеджмента. Мы существуем 16

лет. У нас два основателя. Мой коллега

Слава Панкратов, который очень давно

когда-то был директором по технологиям

Яндексу Украина, директором киевского

Яндекса, когда Яндекс ещё был в Украине,

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

Люксоoft Украина. Вот я в это время в

Питере работал в компании Intel,

руководил одной из команд. И вот мы, это

была середина 2000ных годов, вот мы

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

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

Дорофивым, с которым дружим до сих пор.

И вот со Славой занимаемся тем, что учим

умных людей работать с другими умными

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

они про управление, про разные позиции

управленцев в IT-индустрии, от тимледов

до директоров. Поскольку занимаемся этим

16 лет, то те, кто 15 лет назад учились

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

вице-президенты и директора компании

присылают учиться своих тимледов. Вот.

Но что нужно знать про стартоплан - это

то, что мы очень заморочены на качестве

обучения. У нас есть там две основные

метрики. Первая - это практичность,

полезность программ. Она там из пяти

подметрик собирается по каждому занятию.

И мы стараемся, чтобы у нас это было не

меньше девяти по десятибалльной шкале. И

второе - это compition rate. То есть у

нас программы многомесячные.

Ну, потому что для обучения, чтобы

что-то изменилось, нужно время. Вот. И

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

ниже 90%. То есть 90% студентов доходит

до конца многомесячных программ

обучения. Их четыре, они привязаны к

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

то естьлид Тимлидов, CTO и CO. Вот про

всё про это я, наверно сегодня ещё в

конце дня поговорю. Но что важно

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

конференции есть специальная цена -10%

по промокоду AI. А если захотите прийти

учиться в Стратоплан, коллеги, я бы

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

Ну, потому что нужно убедиться, что вам

это реально поможет, что это вам реально

надо. Обучение не решает всех проблем в

жизни, но многие позволяют решить.

Поэтому почитайте описание программ,

примерьте на себя и почитайте, что пишут

очевидцы. То есть, потому что у нас

учится много ведущих разных

Telegram-каналов. Они вот периодически

получают сертификаты, как Коля Ошанин,

пишут разные, значит, посты в свои

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

посты у нас опубликованы на специальной

странице. Переходите, почитайте, можете

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

как им училось в личку. Они вам, я

думаю, с удовольствием ответят.

Наверное, какое-то количество наших

выпускников будет и сегодня на эфире.

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

разные вопросы спрашивать.

Коль, пару слов про энтропитолк.

Да, тут действительно будет всего пару

слов, потому что Talkк - это совсем

новый проект меня и Максима

Романовского, который вчера вёл нашу

панельную дискуссию. И по сути мы

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

мероприятия. Это наша третья

конференция.

А мы делаем пока что только и

конференции, но делаем их крупными и

кажется, что интересными. Вот в

ближайшее время мы будем записывать

больше эфиров с разными интересными

людьми. И у нас на канале уже можно

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

записывали с Рефатом и Валерой,

ребятами, которые занимаются реально

очень глубоким AI инженирингом.

Саш, я думаю, можешь,

>> да, коллеги, во-первых, надо, конечно,

Да, да, да. Ну, если вы ещё не подписаны

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

немедленно подписаться. Вот если вы

смотрите запись, то тоже надо пойти

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

правда, они делают крутые вещи, собирают

классных спикеров.

По-моему, вот это мероприятие у нас чуть

ли не самое популярное в онлайне про AI,

да? Вот. Ну, то есть

и во многом за счёт качественной

программы в моей оценке. Вот. Да, не

только в моей, на самом деле. Друзья,

прежде чем мы перейдём в контент

конференции и включим чат несколько

правил. Поскольку у нас всё-таки

публичная пространство, то мы вас

призываем к трём вещам. У нас в чате

будет запрещены три вещи. Это мат, это

политика в любом её проявлении и это

любой неконструктив. Ну, для того, чтобы

мы с вами могли нормально общаться,

никого это эмоционально не задевало,

давайте постараемся быть бережны друг

другу и создадим такое пространство

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

здравомыслия в нынешнем неспокойном

интернете. Поэтому, пожалуйста,

постарайтесь воздерживаться от мата

политики неконструктива. Любые вопросы,

любые комментарии по существу пишите.

Вот, можно обмениваться контактами, как

мы это делали в первые 2 дня. Вот. В

общем, будем рады любой вашей

активности. Ну что ж, давайте здесь,

наверное, включим чат, коллеги. В

качестве проверки чата я бы вам

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

работаете. Вот можете просто давайте

социуметрию соберём. Вот кто вы, вот на

какой позиции находитесь. Вот. Ну и мы

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

понять, как мы можем наш контент

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

для вас с позиционировать. Ага. Ну да,

чат у нас начал жить, да, спасибо, что

делитесь. Я вижу, что у нас есть и

инженерная аудитория, и HR, и CTO. Вот

уже несколько CTO у нас примелькнуло.

Head of QA, да, отдельный привет QA, с

которым я провёл 8 лет своей

профессиональной карьеры.

Ага. Инженеринг-менеджер на пути к сети.

Тактак. Head of department, IT-аудитор,

архитекторы. Да, ну замечательно. В

общем, очень разнообразная аудитория,

по-моему.

Все у нас плюс-минус из IT, кого я

видел, коллеги. Может быть, кого-то

пропустил, но да. Мы самое главное, у

нас чат работает. Вот что мы это

выяснили, поэтому я думаю, можем

приступать. Ну что ж, у нас первый

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

у нас выступляет выступает мой коллега

по ведению конференции, организатор

Николай Шайко. Будем мы говорить про, э,

най, обучение и увольнение. Коль,

захватывай эфир, врывайся, а я уйду за

кадром.

Так, ну что, погнали. Действительно,

будем говорить сегодня очень сильно про

людей, не только про технологии. Пару

слов про меня.

Вообще у меня нет какого-то прямо супер

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

инженеринге. У меня суммарное лет 10, но

на очень разных позициях и в очень

разных компаниях. Поэтому мне кажется,

что у меня есть большая насмотренность

на разные процессы. И поэтому мне есть,

что тут рассказать. Вот последние 3 года

я завожу искусственный интеллект в

разные чужие бизнесы. Сначала как

сотрудник в американском HR-продукте с

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

нельзя называть. А после этого я ушёл и

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

не айтишного бизнеса, а для айтишного

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

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

интеллект в разработке, либо потому, как

строить системы с лмками под капотом.

Ну, по фану, как вы можете заметить, я

организовываю конференции и пишу про все

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

провожу в мой Telegram-канал AI играбля.

И небольшой план на сегодня. У меня есть

пэкграунд, э, небольшой

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

поэтому я сегодня буду чуть-чуть

училкой. План на урок. Сначала мы вообще

будем отталкиваться от трендов. Мне

очень нравится идея отделять хайп от

каких-то реально долгосрочных трендов.

Поэтому мы посмотрим немножко в прошлое

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

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

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

И конкретно мы будем говорить про то,

как меняются команды, да, то есть как

происходит найм новых людей, увольнение

старых, и про то, что делать с теми

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

про то, как их обучать и подготавливать

к а

революции или эволюции, которая тут у

нас происходит. И не только про то, как

делать это для своих подчинённых, если

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

для себя тоже.

И, конечно же, мы поговорим про кейсы. Я

в целом много разных штук делаю, много

ошибаюсь и с удовольствием делюсь этим,

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

обучение происходит на практике.

Понятно, что здесь вы не можете

полностью прожить все мои ошибки, но

поучиться на моих ошибках чуть-чуть,

наверное, вы можете. Но в конце, чтобы

вы вышли, да, с каким-то более-менее

понятным списком Action Items, да, я

попытаюсь сформулировать какие-то

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

стоит делать на коротком промежутке

времени, там в течение месяца, условно

говоря, как это связано с какими-то

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

год, ну, больше года сейчас уже сложно.

Вот. А самое главное, чего, как мне

кажется, делать не стоит.

Так, идём дальше. тренды. Возможно, вы

уже видели этот слайд, потому что, а,

его часто постят, его часто обновляют.

Вот тут есть ссылочка, по которой можно

посмотреть его. И важно, что здесь уже

логарифмическая шкала, да. То, что он

выглядит линейно, это ничего не значит.

На самом деле там огромная клюшка.

Просто если открывать его в

логарифмической, ну, в смысле, в

линейной шкале, то там вообще уже ничего

непонятно.

И что тут важно? Тут важно, что с

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

лет у нас сложность, именно такая

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

человека там времени бы ушло на решение

какой-то задачи. Вот сложность таких

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

сильно растёт. Если пару лет назад эта

сложность измерялась минутами, то сейчас

она измеряется уже не просто часами, да,

она уходит за 10 часов.

И что это значит? Это значит, что в

применении к разработке мы постепенно

переходили от копайлота, да, вот такого

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

парное программирование с искусственным

интеллектом. Он там где-то помогает

ошибки какие-то подсвечивать, что-то

переписывать, где-то он помогает

дописать строчку кода, да? Потом он

постепенно научился дописывать целые

функции, потом он научился менять целый

файл, потом с выходом компоузера в

курсоре мы смогли менять сразу несколько

файлов. Потом произошла вот эта вот

агентская революция, в результате

которой нас системы вот эти вотные,

которые помогают писать код, они могут

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

они могут пойти изучить а наш

репозиторий, сформулировать какую-то

спеку, сохранить её в MD-файлик, потом

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

код, запустить Linter, запустить build,

отревьють всё это, исправить какие-то

ошибки и крутиться. А вот это вот

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

следующего действия зависит от

результата предыдущих. И постепенно

благодаря вот этому агентскому переходу

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

которые вот могут работать часами.

И что тут интересно, что если раньше и

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

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

сейчас она постепенно уходит в категорию

автономного работника, который может

дать задачу, он пойдёт несколько часов

выделать. И тут интересная штука

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

включаемся в работу этой системы уже не

тогда, когда мы решаем, что ей нужно

что-то сделать, а очень часто тогда,

когда система решает, что нам нужно

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

провалидировать какую-то её гипотезу или

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

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

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

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

чтобы она это сделала. Здесь очень

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

один из инструментов в арсенале и агент

или всё-таки менеджер в каких-то

ситуациях. Здесь вопрос к вам на

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

или инструментом? Мне кажется, что я 50

на50.

И переходя дальше,

а

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

кривую роста, у вайпкодинга, да, у

кодинга СИ есть проблемы. Эти проблемы

встречаются и на новых проектах, когда

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

проектах. На новых проектах это типичная

ситуация, когда

мы очень много чего делаем с

искусственным интеллектом. У нас где-то

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

где-то костыли, где-то в целом э

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

которые мы потом пытаемся откатить и

переделать архитектуру. И в какой-то

момент просто упираемся в границу

сложности. Добавлять новую фичи,

оказывается невозможно, потому что они

приносят новые баги, и приходится

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

создаёт новые баги. Ну вот это вот всё

проклятие вайп-кодеров, это это про вот

эту штуку. И на самом деле это не что-то

новое, да? Это появилось не только с

искусственным интеллектом. Это было и

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

писать какой-то проект с нуля, ещё если

а у них будет память стираться каждый

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

чему-то похожему.

Ну и со старыми проектами тоже есть

проблема. Старые проекты, они большие и

они, скорее всего, давно существуют. А

это значит, что есть много так

называемых tas knowledge. Это какие-то

неявные знания, что-то, что хранится в

головах у разработчиков или у менеджеров

или у разработчиков, которые уже

уволились из компании.

И они на той явные, что агент не сможет

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

попросите. Да, это что-то такое на

кончиках пальцев. Часто это может быть

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

решение. Эта причина может быть и

техническая, да, связанная с какими-то

ограничениями, и бизнесовая тоже. И эту

бизнесовую причину тоже может быть

сложно найти в кодек.

И так получается, что если вот мы

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

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

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

на входе, да, в том числе вот этих вот

ted knowledge, знаний про проект, про

домен, про бизнес

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

как раз то, без чего у нас очень быстро

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

проекты. Да, нам очень важно ревьюить. И

чем качественнее мы делаем ревью, тем на

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

границу, про которую я говорю.

Получается, что ревью с одной стороны

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

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

динамическом состоянии. А с другой

стороны, оно определяет скорость

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

ревью качественно, то

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

который генерят там эти десятки и

агентов, да, вот те самые 50

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

Получается такой трейдоoф.

Тут я хочу поделиться, э,

вот этим слайдом. Это не мой слайд, это

слайд Максима, автора канала этих лит.

Очень советую этот канал всем, кто, а,

имеет серьёзный технический бэкграунд.

Один из немногих каналов, которые я

стабильно читаю. И вот этот слайд, он

как раз говорит про то, что у нас

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

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

сконцентрированы именно на самой

разработке, на том, чтобы создавать

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

это меняется. У нас всё меньше времени

уходит на то, чтобы писать код, и всё

больше времени уходит на подготовку

правильного инпута. Да, то, про что я

говорил на предыдущем слайде, на

планирование, на продумывание фичей, на

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

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

какими-то техническими требованиями и на

верификацию результата, чтобы отложить

вот этот вот коллапс системы как можно

как можно

позже.

Если мы продлим вот этот тренд, то

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

будет всё меньше и меньше. У нас будет

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

всё больше верификации.

Про то, как решать проблему верификации,

а вот этого бесконечного количества

кода, мы поговорим чуть позже. Здесь

важно в целом э вот этот вот поинт, что

наша специализация как разработчиков или

специализация нашей команды

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

растекается по краям. на вход и на

выход, и всё меньше остаётся в середине.

И тут интересная статья недавно вышла.

Она сейчас нормально так хайпит по

интернету, поэтому я её сегодня вставил

в презентацию. Статья про то, что

Software Development Life Circle, то

есть цикл разработки софта, умер, что

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

были отдельные этапы. И под каждый этап

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

команде, либо как минимум отдельные

инструменты и отдельные процессы. И

сейчас, мол, это всё схлапывается. Я не

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

всем бизнесам, но к достаточно большому

количеству бизнесов, ну, продуктах это

уже применимо. Схлапывается в том

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

отдельная, нам не совсем нужно делать

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

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

выложили код. Да, нам, возможно, не

нужны отдельные тестировщики и

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

мы и планирование фичи проведём, и

имплементацию. И этот же агент напишет

тесты, он же их запустит. Причём не

только там юнит-тесты, да, но и

nendтесты, откроет их в браузере,

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

сделает кодw и потом ещё и исправит

ошибки. И сам же задеплот через там

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

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

они стираются. Это сильно меняет

процесс, за исключением того, что если

мы всё-таки хотим делать человеческое

ревью, то оно всё замедляет, да, потому

что после того, как агент сгенерировал

код, он ждёт, пока человек придёт и

отревьюет, да. Вот здесь как раз мы

выступаем таким инструментом в руках

агента. Да, нужно ревью, но мы, в

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

доступный инструмент. У нас нет кучи

свободного времени, и мы можем

заниматься другими задачками, и нас

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

приходится ждать, и весь выигрыш здесь

теряется.

И это одна из самых больших проблем,

которую я вижу сейчас в внедрении яишки.

Но если суммировать все вот эти тренды,

да, то что мы видим? Во-первых, мы видим

то, что схваются этапы разработки,

и при этом мы, как разработчики,

перестаём быть разработчиками в прямом

смысле. Мы становимся либо

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

эту,

мы становимся немножко ревьюерами, а

самое главное, мы становимся менеджерами

агентов.

Мы начинаем по-другому работать, потому

что большая часть нашей работы - это

правильное формулирование задач и

правильная проверка их выполнения. Это

буквально то, чем занимаются.

И что из этого следует? Из этого

следует, что команды у нас, ну, не

просто должны, они будут меняться. И

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

точно какие-то люди, ну, будут не

приспособлены к вот этому переходу из

состояния разработчиков, состояния

инженеринг-менеджера.

Точно будет происходить обучение, потому

что какие-то люди способны, у них есть

потенциал, но у них пока что нет навыка.

И точно будет меняться структура команд

и процессов, да? Это вот то, про что

была предыдущая статья, про умерший э

цикл разработки. Скорее всего, что-то

будет работать по-другому, просто

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

в том виде, в котором они были. И

навыки, которые понадобятся людям - это

агентность

самого сотрудника должна быть выше, чем

агентность и агенты. Потому что, ну, вот

эта агентность, да, способность

выполнять какой-то большой ископ работы,

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

основе каких-то предыдущих решений,

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

которую получили. Если агент может

сделать там задачу размера X, то мне не

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

задачу размера X. Я нужен сотрудник,

который сможет сделать задачу размера

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

агенту. Поэтому, мне кажется, это самый

важный навык. Это буквально то, что

отличает сейчас человека опытного от, э,

других агентов. Второе - это архитектура

и паттерн, да, у нас всё меньше, всё

меньше именно экзекюшена остаётся, всё

меньше написания кода и всё больше

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

эту систему.

Это тоже по чуть-чуть уходит агентам, но

кажется, что это уйдёт сильно позже, чем

просто написание года. Ну и самое

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

искусственным интеллектом. Потому что

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

это фундамент, да, это буквально

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

раньше работать, то опыт работы СИ - это

мультипликатор. Если у нас появляется 10

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

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

можем делать сильно больше работы.

И проблема в том, что этот навык долго

нарабатывается. И даже там все

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

что иишка не работает, они признают, что

частично, возможно, она не работает,

потому что мы ни фига не учим людей её

использовать и что там крутая кривая

входа.

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

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

обучение, сейчас про найм.

И по сути есть только два подхода. Что

люди думают про то, как нужно строить

собеседование? Это первое. Нужно

запрещать использование искусственного

интеллекта, чтобы никто не читерил. А

второе- наоборот, требовать

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

потому что нам нужно знать, как вы с ним

работаете. Давайте тут небольшой

интерактивчик проведём. Напишите,

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

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

лучше использовать первый подход и

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

использовать второй подход.

Как много двоечек. Вы не просто так на

AI конференции.

Ну, короче, а скорее всего, вы думаете,

что я сейчас начну, а, говорить, какой

первый плохой подход плохой, но это не

так. Мне правда кажется, что это хороший

подход, и он всё ещё работает. Он точно

не будет работать на долгосроке, но

сейчас он хорошо работает. Почему?

Потому что, как я говорил на предыдущем

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

работы с и, нам важны ещё и какие-то

собственные архитектурные знания и

навыки человека.

И абсолютно о'кей проверять их без и

контекста, да? Мы хотим просто проверить

фундамент, и мы проверяем просто

фундамент.

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

там аэ просят написать код на листочке.

У меня есть большо большие вопросы к

ним, но я могу понять, почему это

происходит, да.

Вот. Но точно также и второй подход

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

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

мы требуем от людей работать с

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

не просить на собеседованиях. Но тут

есть сложности, что

задизайнить такие собеседования, которые

будут сразу использовать,

проверять и навыки человека как

разработчика, и навыки человека по

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

достаточно сложно,

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

быть и достаточно сложные, чтобы не

решаться в один промт, и при этом

достаточно простые, чтобы вообще успеть

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

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

проверить решение.

И тут я расскажу кейс. Я

провожу консультации, где помогаю э

компаниям задизайнить процесс их

собеседования. Иногда помогаю прямо

нанимать. И тут я расскажу про кейс из

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

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

удобнее. Она лид команды системных

аналитиков,

и они уже делают отдельно вот AI Native,

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

проблемами, что вот этот AI native этап,

он слишком похож на обычный этап

системного дизайна, который они

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

которая отсюда следует, что все, кто

прошёл первый этап хорошо безы, они и

второй тоже хорошо проходят, потому что

там слишком большая часть вот этого

системного дизайна.

Что я сделал? Я поспрашивал сведу. В

целом такой широкий опросник. Я часто

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

начинаю задавать вопросы и пишу этим

людей. А спросил, как уже используются,

да? Потому что это то, с чем столкнётся

сотрудник после того, как примет офи,

если он его получит. Как свет его

использовал на последней неделе? Да, я

спрашиваю про реальное прошлое, а не про

то, как она хочет его использовать. где

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

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

да, это очень важный инсайт, если есть

ответ на этот вопрос. И какие самые

гепардные задачи перестали быть такими?

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

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

из

всего пула использования.

И по итогу этих вопросов у нас

сформировалось два таких кластера задач.

Первое - это формирование вот

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

концепций. Но мы быстро поняли, что это

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

количество итераций, да, такая серьёзная

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

И до сабёсов нам это не подойдёт. А есть

ещё второй небольшой кейс, ну, который

экономит много времени. Это генерация

драфтов и пиконтрактов. Поэтому мы

решили пойти по нему, и я предложил вот

такой формат. Вместо двух больших собсов

сделать один, где 40 минут будет

systemдизайн, а последние 20 минут будет

просто генерация вот этого драфта

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

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

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

контексте. Соответственно, это будет

экономить много времени по сравнению с

отдельным этапом, где была бы какая-то

отдельная задачка.

И можно было бы на этом остановиться, но

я предложил ещё одно усложнение.

Вместо того, чтобы просить сделать драфт

с нуля, мы можем дать готовый драфт, но

в котором уже заложены какие-то

проблемы.

И попросить добавить что-то к этому

драфту, что не очень хорошо влезает вот

в существующую архитектуру.

И потом смотрим, как человек будет это

решать.

Это как бы важно, потому что вот здесь

аув цитатка такая, что хороший

специалист знает, как не косячить, а

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

другие люди накосячили. Это позволяет

как бы оценить

семёрность человека. Плюс

почему задачи на рефакторинг очень

хороши, потому что эллэмки слишком

сильно цепляются за то, что у них уже

есть в контексте, за какие-то дорожки,

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

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

чуть-чуть налево, чуть-чуть направо, но

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

уже попадается у них в контексте.

И поэтому, если мы даём человеку такую

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

она бы её решила, скорее всего,

нормально. Она бы точно сделала драфт

контракт и всё было бы хорошо. Но если

мы даём задачку, где есть какая-то

скрытая проблема, и человек просто

такой: "Лэмка, иди делай". А она пойдёт

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

джин. ты ему даёшь э-э задание такой:

"Сейчас всё будет". И идёт делать.

А реальный разработчик, если у него есть

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

задачку и такой: "А я не буду задачку

это делать. Что-то тут как-то сильно

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

Давайте мы лучше исправим вот это вот

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

будет просто.

Да, не будет делать слишком сложную

задачу, он найдёт способ, как упростить

всю систему. А разработка в целом, да,

это в каком-то смысле

борьба со сложностью.

Вот этот кейс хорошо заработал, ребята

поменяли свой процесс и были довольны.

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

обсуждались, не решились.

И в результате таких собеседований у

нас, по сути, высвечиваются несколько

типов кандидатов. Первые - это

консерваторы - это те, кто чаще всего

либо вообще не использует и либо

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

советоваться.

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

и что искусственный интеллект не

работает на крупных проектах реальных в

продакшене. Вот есть наоборот

вайп-кодеры, которые ещё не понаступали

на реальные проблемы

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

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

что он совсем разберётся сам. Вот. И

есть те люди, которых мы ищем. Это те,

кто вместе с искусством интеллекта

разберут задачу,

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

поймут, как нужно её поменять, и

объяснят её человеку, который 70 лет.

Вот это буквально то, что мы ищем.

Если суммировать вот эти советы по

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

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

обязательно закладываем в него какую-то

проблему. Мы не говорим про рефакторинг,

да, человек сам должен до этого дойти.

Но мы даём какую-то фичу, которая вот в

текущую архитектуру без костлей не

помещается. А дальше мы наблюдаем, мы

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

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

именно он общается с искусственным

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

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

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

Ну и вот это вот всё.

И ещё чуть-чуть моих спекуляций про

найм. Если честно, мне кажется, что

тестовые задания снова по чуть-чуть

станут популярными. Почему так? Потому

что раньше, э, нельзя было дать простую

задачку, потому что она просто не

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

же не можем там дать кандидату задачку с

лид-кода и вот считать, что это реально

покажет то, какой он хороший

разработчик. А дать сложную задачку мы

не можем, потому что она слишком много

времени у него займёт, и он скажет типа:

"Ребята, до свидания, я пойду в другую

компанию". Но сейчас можно давать

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

несколько часов за счёт вот этого наше

нашего и ускорителя.

И при этом ещё в целом есть рыночные

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

заметили так или иначе, и кандидаты как

будто могут сильно меньше

выпендриваться. Сейчас работодатель

может себе позволить давать тестовые

задания. И у меня в целом есть кейс,

который это подтверждает. Здесь не

совсем вот прямо точные цифры, но очень

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

стартап. Ребята делают оффлайн агентов,

которые могут работать на планшете, там,

где не ловят интернет.

И они вполне себе давали тестовые

задания, которые кандидаты делали.

Естественно, оценивались тестовые

задания сначала через AI Review.

А, ну у нас были сформулированы

критерии, которые должны были отличать

хорошее решение от плохого. И в целом

оно вполне себе точно соответствовало,

потому что там всего двух человек я

потом отл на этапе перехода в

собеседование.

И три человека получили оферы,

что в целом кажется хорошим результатом.

И он подтверждает, что среди людей,

которые действительно могут что-то

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

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

делать тестовые задания. Ну и причём там

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

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

конечно.

И неприятная такая тема, да, про

критерии для увольнения. Субъективное

мнение. Мне кажется, что чистые

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

сформулированная задачка в Джире, будет

сложно. И компаниям с ними тоже будет

сложно, потому что мы все сейчас

переходим немножко на один уровень

абстракции вверх, и становится важно

уметь самому ставить задачи и

прорабатывать требования к этим задачам.

Ну, либо самому, либо в процессе

итерации свои агент.

также людей, которые требуют контроля.

Да, все по-любому где-нибудь

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

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

но он там хорошо работал. Но вот сейчас

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

не подходит, потому что у меня и агент

тоже требует постоянного контроля и

проверки результатов, но работает он ещё

лучше, да. Соответственно, эти ребята

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

код. Это, честно, это кликбейт тут

немножко, но

кажется, что есть люди, которые

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

код, им сложно перейти вот в этот режим

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

можно не писать. Мне кажется, есть много

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

самостоятельно, либо хотя бы его вручную

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

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

вашей конкретной экспертизы, и вы это

делаете там лучше, чем

95% других разработчиков. Но делать это

всегда точно нет никакого смысла.

И вот тут важный, но противоречивый

немножко момент про то, кого мы не

ульняем.

Есть душнилы консерваторы, и я считаю,

что их точно нельзя увольнять. Их нужно

держать, потому что кто-то должен

балансировать вот этих вот

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

обшеные клокодами, кодексами, а,

антигравити и начнут переколбашивать

нашу кодовую базу. Кто-то должен следить

за этим детским садом, но кто-то должен

быть этим детским садом, чтобы двигать

компанию. Я считаю, что здесь нужно вот

играть этим балансом. Другое дело, что,

возможно, нам не хватает сейчас именно

вот вот этого детского сада, да, который

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

Вот. Но эти ребята точно тоже нужны. И

самое главное - это людей с вот этими

неявными знаниями точно нельзя уволнять,

потому что вы их потом нигде не

получите. Если вы рассчитываете на то,

что, ну, это людям было лень читать

документацию, это людям было лень

смотреть вход, а вот сейчас мы агента на

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

вытащит, это не сработает. Всё ещё есть

много знаний, которых нет ни в коде, ни

в документации и нигде. Они либо в

головах у людей, либо даже не в головах,

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

Вот поэтому их нужно держать до

последней и по чуть-чуть вытаскивать из

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

бесят. В смысле люди, а не знания.

Ну ещё я часто получаю вопрос, что

делать с джинами. Если честно, у меня у

меня нет хорошего ответа на этот вопрос.

Есть только плохой ответ. А плохой ответ

- это использовать этих дженов как

тренажёр менеджерских навыков. Ну там

для текущих медлов и синьоров. Но это

тоже такой спорный тейк, потому что с

одной стороны люди хорошо учатся об

людей, потому что мы быстро получаем

обратную связь, да, у нас очень много

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

по мимике что-то считываем, мы как-то

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

и много человек там отвечает,

как у него поменялся тон. Мы мы вот

считываем

где-то эффективность, неэффективность

наших решений и обучаемся, даже если мы

это не осознаём. С другой стороны,

обратная связь об людей часто бывает

долгой, потому что мы общаемся

асинхронно. Я там написал, он мне

ответил через день, я понял, что он

ответил не то, что мне нужно. Я

переформулировал, подождал ещё день, я

утрирую. Это займёт много времени. Тогда

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

получить результат, что что-то я сделал

не так. Его же спросить: "Почему ты

сделал так?" Да что в моих инструкциях

тебе не понравилось или привло к такому

результату? Он сразу нам это подсветит.

Я такой: "А, я понял". И человек очень

редко, когда скажет: "Ну, ты сказал вот

это, я подумал, что вот это, а потом вот

так". А ещё муда так. Вот тут агент

может очень много информации выдать,

которую человек не выдаст из-за каких-то

наших социальных приколов.

Поэтому это такой фи-фйк, но другого

ответа я не знаю, зачем сейчас джunны.

И теперь переходим к обучению.

Сейчас пару слов про то,

как учимся мы сами, а потом перейдём к

команде. Тут у меня ещё один соцзапрос.

Аа вот как вам кажется, вы больше

тупеете от использования Иишки или вы

скорее умнеете? Понятно, что есть и то,

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

Напишите единичку, пожалуйста, в чат,

если вы кажется, что вы скорее теряете

когнитивные способности, и двоечку, если

кажется, что приобретаете.

Во, тут уже больше единичек, чем на

прошлом вопросе.

Э-э,

ну да, это такая сложная сложная

ситуация. Я, если честно, не знаю про

себя. Вот тут у меня нет никакого

мнения, но я точно знаю, что в каких-то

областях я умнею, потому что у меня

появился персональный

препот по любой теме.

Если раньше мне нужно было, если я

чего-то, не знаю, хочу разобраться, либо

очень много читать интернет и смотреть

YouTube видосиков с индусами, либо мне

нужно было самому находить какого-то

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

него консультацию или, если это мой

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

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

сразу отвечает, то сейчас я могу прийти

и нормально сформулированные вопросами

достать очень много информации из ЛНК.

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

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

ими поделиться.

Первые: какие есть идиоматичные способы

решить какую-то задачу, с которой мы

сталкиваемся?

Тут не просто так выделено слово

идиоматичный, потому что на моём опыте

оно почему-то ну очень хорошо работает.

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

думать в ту сторону, а как не просто

решить мою задачу, а как решить мою

задачу каким-то способом, который будет

условно Best practтиce.

Второй вопрос, который я уже озвучил там

на предыдущих слайдах, это что в твоих

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

сделал X. Да, тут мы уже не просто

учимся какой-то абстрактной штуке, а тут

мы учимся взаимодействию с агентом. Мы

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

так в наших собственных действиях, чтобы

это исправить. Ну либо в каких-то

инструкциях, которые мы всегда передаём

агенту, да, там системные инструкции, и

в них тоже что-то исправить.

Ещё есть вопрос: как в твоём решении

какие могут быть переусложнения, от

которых можно избавиться? Потому что

агенты часто склонны э заниматься

овенжинирингом, да? где-то заранее

продумывать на будущее, где-то просто

делать enterprise grade solutions, вот

это вот. И не всегда они сами про это

говорят. Задавая такие вопросы, мы можем

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

действительно бере усложнение. И можно

сделать проще. И, может быть, он даже

предложит способ, как и за счёт вот

этого дифференцирования

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

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

навыков вот действительно синьорного а

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

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

решением.

И самое, наверное, полезное - это давать

ему пути отхода. говорит, что если я там

что-то не то спрашиваю или требую от

тебя, и ты понимаешь, что это бред, то

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

И тут ещё может написать, что, ну, я в

этом не очень разбираюсь. Чтобы он такой

не

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

экспертностью. Я вот так сформулирую.

Ну, короче, сказать: "Я я не шарю, скажи

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

ошибаюсь". Всё это очень хорошо

работает. Я несколько

серьёзных ошибок

не совершил чисто

благодаря вот этой фразе, потому что в

какой-то последний момент перед диплоем

сложного сервиса с большими требованиями

безопасности я там его это спросил, и он

мне объяснил, что Угу.

Ещё один момент такой микролайфхак.

Когда вы занимаетесь вот таким

самообучением об иишку,

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

вашего диалога, а откатывать диалог,

чтобы не загружать контекст. Мы много

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

модельки - это вещь ограниченная,

и вот важно им грамотно пользоваться.

Если мы получили ответ на какой-то один

вопрос и мы поняли, что о'кей, эту тему

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

шаг назад и пойти в другую ветку

разговора, то давайте мы сделаем эту

шаг, этот шаг назад и пойдём в другую

ветку разговора. Если вы общаетесь

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

отредактировать сообщение выше, да, и у

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

кстати, переключаться между ними можете.

Если вы это делаете где-нибудь в

кодексе, в клодкоде, то вот вам есть

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

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

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

А очень полезный способ, как и сохранять

все предыдущие сообщения, да, все

предыдущие разговоры и при этом, а, не

перегружать контекст этими сообщениями.

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

Вот это кейс про мой фака. Да, я знаю,

что люди любят слушать про ошибки. Я

люблю рассказывать про ошибки и люблю их

анализировать.

Вообще, обычно, когда я работаю с

командами, я делаю обучалки на каких-то

упрощённых задачах. Мне кажется, что,

аэ, ну это это нормальный способ

обучения, когда мы сначала в в

игрушечной обстановке изучаем какие-то

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

уже реальные ситуации. Да, мы все так с

детства учимся, играя в какие-то игры, в

социальные игры, в

школу, не знаю, в общение с другими

людьми на площадке и так далее. Потом

переносим это во взрослую жизнь. А в

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

что компания уже

в процессе перехода фронтенда на новый

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

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

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

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

централизованной настройки, нет best

practices. И ребята хотят как бы,

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

которая у них есть, ещё и прокачаться,

да, потому что они уже используют ей.

Давайте сейчас просто кто-то придёт,

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

советы, и мы получим навыки. В целом всё

суперлогично, мне показалось хороший

кейс, надо браться. И у меня был такой

план. Сначала общаемся с командой,

достаём вот эти вот t knowledge по

максимуму, насколько я могу. Понятно,

что у меня супер ограниченное время. А

смотрю на процессы разработки, которые

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

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

эти тулы, да, там вот ClodMD, Skills и

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

данных я отдельно корректирую поведение

людей, как люди общаются с агент, как

дают задачи, делают ли они планирование,

делают ли они ревью. И отдельно мы

корректируем поведение агента через

настройки этого агента, через промты,

через скилы, через настройки агентов.

которые запускаются в рамках этого села

и тула.

А потом просто тестировать и сделать

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

научатся делать эти штуки

самостоятельно. Вот план надёжный. И

сначала я перевёл ребят с курсора на

clудко.

А было суперпросто, потому что в курсоре

они пробивали ээ лимиты и и так платили

за него много денег.

А, сделал опросник для команды, да, я

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

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

отсутствующие места, да, что здесь можно

и так сделать, и так делать. Я такой:

"О'кей, скажите мне, как вы делаете". И

сделал набор вопросов. Мы там

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

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

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

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

чтобы замкнуть фидбеклуб, да? То есть

сделать так, чтобы агент мог получать

обратную связь о своей работе через

Linнter, через компиляцию типов, через

тесты и через тесты в браузере, через

playрай

и участвовал в синках, чтобы какие-то

решения команды там где-то

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

из того, что я говорю, что, ну, вот

здесь агенту будет сложнее, если вы

сделаете таким образом.

И что тут могло пойти не так? Первая

ошибка, которую я сделал - это я очень

много делал сам.

Во-первых, проблема, да, это вот notдж,

про который я говорю весь доклад,

который есть у команды и нет у меня. Я

заметил, что я делаю очень общее

решение, потому что мне не хватает вот

этого вот ощущения того, как

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

команды. А во-вторых, я делаю какой-то

магический артефакт для ребят, который

как-то в каких-то ситуациях работает, в

каких-то 100% не работает,

и они как бы не знают, что с ним делать

на самом деле, да. Это вот какой-то Коля

пришёл, сделал какую-то штуку. Мы как-то

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

чёрную коробочку. И иногда она работает.

Если не работает, ну тогда не

используем. У ребят как бы нету

нормального способа обновлять эту

систему, потому что, ну, её делал я, а

не они. Они не участвовали в процессе, и

к тому же у них не было навыков

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

получили, они не делали это. Делал это

я. Я получал какие-то навыки вместо них.

Вторая ошибка, которую я сделал - это

пытаться работать сразу там со всей

командой. И

тут две проблемы. Первое - это в целом

разная степень сопротивления, что

абсолютно нормально, да, я говорил, нам

нужны люди консерваторы, всё о'кей. Но

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

работаете с каждой, потому что вы

разделяете свой фокус,

и его не хватает тем людям, которые

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

если бы в них вложили больше как бы

фокусы времени, энергии.

А вторая проблема - это разная степень,

как я её назвал, и нативности, да.

Вот я в начале говорил про навыки

менеджмента, что

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

формулировать задачи, правильно их

делегировать. И в таком режиме очень

сложно работать многим разработчикам.

Почему? Потому что хороший разработчик -

это скорее синхронная роль, да,

блокирующая роль. Если вот мы в терминах

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

взял,

я начал делать. Прошло 2 часа, 3 часа, 8

часов, несколько дней. Я закончил её

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

другими задачами. Это вот идеальный

разработчик, да, он берёт задачку и

просто молотит её, пока она не будет

выполнена.

А в случае с иагентами мы переходим к

асинхронному режиму. Мы взяли задачку,

мы там чуть-чуть поитерировались,

закинулишки, получили от неё фидбэк,

что-то ещё и написали,

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

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

на её размышление. Мы, скорее всего,

открываем ск или открываем другого

агента, ему формулируем какую-то новую

задачку, и мы вот крутимся в разных окон

окнах, переключаясь. Это то, как

работают менеджеры. у них асинхронная

работа, и мне зачем ждать, пока

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

чтобы дать другую задачу другому

исполнителю. И для многих это очень

сложный переход. И как бы это абсолютно

нормально, потому что от разработчиков

не требовалось никогда так работать, а

теперь требуется.

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

фокусироваться на тех, у кого есть

задатки вот этой вот асинхронной работы,

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

что с ними вы просто быстрее сможете

прокачаться до нужного уровня. А я

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

разработке, да, - это навык, у которого

крутая кривая обучение, её сложно

освоить, и он требует времени. Самое

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

несколько людей, которые освоили это

хорошо внутри команды, то они же и

разнесут этот навык по остальной

команде. Во-первых, за счёт того, что

будет уже какая-то репутация, да, того,

что это действительно работает. Вот там

Петя из нашей команды, он хорошо

работает, быстрее работает, может быть,

больше отдыхает, и я тоже так хочу. Тут

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

конкретных людей.

А это, кстати, интересно будет на секции

вопросов обсудить. Ладно. А, в общем,

они смогут лучше разнести это по

команде. Во-первых, за счёт того, что

есть репутация, да, уже есть какая-то

валидация того, что это работает.

Во-вторых, за счёт того, что у них есть

эти навыки, и они будут передавать

знания

друг другу, потому что навыки

формируются в процессе экспериментов. И

в целом тут нет каких-то реально best

practices. Сейчас все best practices

нарабатываются опытом. Чем больше у вас

людей параллельно работает, тем больше

опыта они наберут. Круто, если вот у вас

будет два-три человека, которые на

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

проводить много экспериментов быстро и

делиться результатами друг с другом и с

другой командой.

И третье - это

ошибка

учить

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

во время переноса на новый стек.

Изначально мне показалось, что это

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

есть серьёзные плюсы. Мы можем, а,

граундиться на старую реализацию, мы

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

открывать старую, открывать новую,

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

это не обязательно делать нам. Это может

делать сам и агент, если мы даём доступ

к браузеру. И второе - это все-кейсы уже

известны, да? У нас там написаны тесты,

мы знаем, где оно может не работать, мы

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

реализацию. Для этого всё супер. Но

этого есть и минус. Во-первых, мы тащим

какие-то старые костли, да? Если у нас,

э, было не везде, а, как бы

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

это тоже перенесём. Но самый большой

минус - это что очень много

архитектурной работы, очень много

решений, от которых будут зависеть

другие решения. Если мы сначала вот в

режиме вот этого кайфбоя

вайпкодера

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

наш и агент примет неправильное решение,

то потом мы будем очень долго это

разгребать, и последствия вот этих э

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

будут тормозить всю разработку на

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

продукта.

И это, кажется, главная ошибка.

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

недели. А, то есть я там что-то поделал,

а, ребята слышали какие-то мои

мини-лекции во время созвонов, мы что-то

пообсуждали,

и навыков у команды от этого не

сформировалось.

Я подумал, что с этим можно сделать. Я

предложил поработать ещё и сделал

следующие вещи.

А первое, я просто записал видос, где я

беру одну из фичей в

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

начиная со сбора требований. Вот прямо

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

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

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

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

таким же тестированием вот в а браузере.

Помимо этого я сделал скрипт для

выгрузки сессии команды.

То есть изначально мы вообще просили

ребят отправлять прямо экспорты своих

сессий, чтобы я мог их посмотреть и

увидеть, где есть какие-то

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

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

планирования вообще пропускает, он сразу

просит агента идти делать. Либо со

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

где-то есть

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

инструменты, то агент может что-то

делать неправильно. Это можно по

экспорту Сысси проверить. Естественно,

команда не отправляла экспорты, что тоже

абсолютно нормально. У ребят и так

релиз, у них нет времени. Тут ещё

какое-то поле просит каждую мою сессию

экспортировать. Ну каман.

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

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

раз в конце дня, и он все сессии за 24

часа либо за какой-то другой там

отправлял,

а на какое-то хранилище. А я мог их

потом выкачивать и анализировать.

Естественно, анализировал я их не сам, я

их анализировал вместе с и-агентом. Я

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

внимание, да?

И как бы сформулировать, чтобы агент мог

вытащить какие-то потенциально

проблемные моменты и писал фидбэк для

команды и какие-то планы, как мне

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

либо в их паттернах общения, либо в

настройках агента. Вот часть э просто

советов, которые я всем подряд раздаю,

такие базовые, повторяющиеся, я тут

вывел для вас. Первое - это,

естественно, больше планирования.

Причём, если вам кажется, что вы много

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

кажется, скорее всего,

до определённого, э, лимита, каждая

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

скорее всего, экономит вам 10 минут,

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

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

всё. Второе - это используйте диаграммы,

потому что планы, которые пишет агент, и

ревью, которые пишет агент, сложно

читать. Ну вот это простыня текста. Мы

не любим читать текст, когда её сильно

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

книжка. И визуальные диаграммы очень

сильно помогают. Рмей, для тех, кто не

знает, это просто текстовый формат,

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

красивые графы, схемы. И смотря на эти

графы, мы сильно быстрее понимаем, что

на самом деле предлагается.

Вот, соответственно, это ускоряет те

самые

краевые этапы планирования и ревью, про

которые я говорил в самом начале. Третье

- это фидбеклуб. Обязательно нужно

давать агенту возможность валидировать

своё решение. Да, мы, когда как

разработчики работаем, у нас есть дешка,

в дшке есть линтер, вдшки у нас есть

билд, тесты. Мы всё это смотрим. Мы

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

раза. Мы делаем итерации об реальность,

где вот все эти штуки являются

реальностью. Нужно дать агенту же самую

возможность.

Ещё одна часть - это повторяющиеся шаги.

Да, если у нас есть шаг один, шаг два,

шаг-три.

Мы, скорее всего, пишем его там в

какой-то промт. Часто советуют это

оформлять в скилы, да, отдельный промт,

как сделать что-нибудь. Там вот

три-четыре шага. Я советую не делать

этого, а просто оформлять это в скрипты.

Если у нас постоянно повторяется там

четыре шага, напишите ваш скрипт, в

котором будут эти четыре шаги. Если

какой-то будет ломаться, напишите в этом

скрипте вывод ээ

ошибки. Агент тогда запустит этот

скрипт, увидит, что ага, я сломался на

втором шаге. Вот у меня ошибка. Супер, я

знаю, что с этим делать. Вот тогда мы

экономим. Мы вместо четырёх вызовов

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

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

вызов, получаем результат. Вот это очень

1 2 3 Эта штука очень сильно экономит и

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

качество, потому что экономит ему

контекстное окно, да. Вместо вывода

каждого а результата он получает только

один вывод: всё ок, если всё ок. Либо он

получает ошибку на том этапе, на котором

сломалось.

И ревью. Я уже много раз сегодня говорил

про ревью, про вот эту проблему, что

скорость, с которой мы делаем ревью,

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

которой, а,

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

которое может жить продукт и

развиваться, а скорость ревью, ну,

ограничивает скорость вообще выкатки

новых фич, потому что у нас всё больше

года скапливается, и ревю оказывается

ботлнейком.

Отдавать его агенту. Мне кажется, что в

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

прям совсем не делаете новый простой

продукт. Такое делать самому тоже такое,

потому что слишком много времени будет

занимать и никакого выигрыша от

внедрения ишку в разработке мы тоже не

получим. Я предлагаю делать ревью вместе

с агентом. Опять же, если мы опытный

разработчик, у нас, скорее всего,

выработалась какая-то чуйка, где у нас

могут быть проблемы. И мы можем

проверить это просто общаясь с агентом.

Нам не обязательно смотреть в код. Нам

достаточно спрашивать агента про этот

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

тут тоже небольшой лайфхак. Я часто

спрашиваю про то, какие инварианты

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

какого-то полуреквеста. Нарушились либо

изменились, либо ещё что-нибудь. Вот

слово инварианты почему-то очень хорошо

работает. Позволяет как бы выцепить

потенциально опасную информацию, даже

если мы не знаем, где именно может быть

проблема. Ну и последнее - это тесты

можно использовать в качестве спеки.

Почему мне кажется, что тесты особенно

хороши сейчас? Потому что тесты они

всегда синхронизированы. Спека может

устареть, да, у нас агенты быстро там

что-то наколбасили, забыли обновить

текстовый файлик и всё. И никто это

никогда не заметит, если мы специально

не попросим.

Как только у нас тесты

рассинхронизируются с кодом, мы это

сразу заметим. Опять же, потому что есть

фидбеклуб, где-то есть тесты. они станут

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

что-то не то происходит, либо он

исправит э-э тесты, ну, если мы ему это

разрешаем, и обновит тем самым образом

спеку, да. У нас появляется новая как бы

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

как себя ведёт продукт. И вот тут есть

ссылочка.

Это упрощённый вариант скрипта, про

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

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

клодкода за последние часов. Вот можете

использовать. Тут нет участия именно с

анализом. С анализом придётся

поформулировать самостоятельно.

Вот. Но саму выгрузку можно делать так.

Так. И теперь рекомендации для самого

менеджмента. Да. Предыдущие рекомендации

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

которые я давал. Тут для менеджмента.

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

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

только, а, мы требуем у ребят выгружать

свои сессии, то сильно больше

ответственности появляется, да, потому

что, ну, если я вдруг почему-то не

выгружаю сессию, возможно, я не

использую их или использую как-то совсем

плохо. Вот. А, понятно, что нужно

правильно ещё коммуницировать всё, но за

счёт того, что мы видим эти сессии, мы

как бы чуть люди, которые их выгружают,

чуть более ответственно подходят к своей

работе, в том числе и к своему общению,

да, если я знаю, что мои сессии кто-то

будет ревью, то, возможно, я буду чуть

качественнее их вести.

Вторая рекомендация - это вот

сконцентрироваться на нескольких людях,

с которых вы будете прокачивать.

Третье - это отсутствие срочных релизов,

потому что срочные релизы всю вот эту

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

Четвёртое - это дать сотрудникам делать

свои изменения, потому что всё обучение

здесь строится на практике, на своих

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

этих ошибок, на изучении новых каких-то

паттерных и на том, что люди потом

делятся друг с другом.

И следствие с предыдущего пункта. Если

мы хотим дать сотрудникам возможность

ошибаться и учиться на своих ошибках,

нужно начинать с задач, у которых низкая

цена ошибки.

Это, соответственно, отсутствие

архитектурных задач и наличие задач, где

там просто какая-то бизнес-логика

нормально с нормальной спекой какой-то

понятной, вот, и которая не повлияет на

какие-то другие части продукта.

И давайте сейчас подведём такой итог,

про что мы в целом сегодня успели

поговорить. Мы поговорили про тренд на

автономность, да, вот этот график в

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

интеллект, к нему проще относиться не

как к какому-то инструменту, который я

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

сотруднику, у которого высокая

автономность, высокая агентность. А сами

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

менеджеры вот этих и сотрудников.

Но важно, чтобы они были не

микроменеджерами,

да? Люди, которые только становятся

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

они склонны к тому, чтобы начать

заниматься микроменеджмент. Здесь важно,

чтобы этого не было. Вот, возможно, Саша

сегодня что-то про это ещё скажет в

своём докладе.

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

процессы устроены. Да, мы поговорили про

вот эту статью хайпующую, про то, что у

нас схлопываются этапы роли, про то, что

у нас есть переход от синхронной работы

в асинхронной и про размывание вот этой

ответственности от написания кода как

такового больше в планирование и в

ревью.

Рекомендация начинать с задачами, у

которых низкая цена ошибки, да? Это

может быть ресёч какой-то, это может

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

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

это скорее всего отловим.

Вот мы здесь не сделали ещё никаких

изменений серьёзных. Это просто

подготовка документов,

брать бизнес-логику и можно ещё какие-то

тесты тоже писать. Но здесь важно

проверить синхронизацию вот с а спекой

изначально.

А мы поговорили про то, что меняется

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

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

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

компаниях. Про то, что нормально

требовать использования и на собесах,

да, не можешь помешать возглавь. И про

то, что на собесах, нам тоже нужно

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

про которые я говорил здесь.

И ещё мы успели поговорить про то, что

люди и процессы здесь первично, да, нам

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

как мы выстроили вот этот вот процесс

итеративного а улучшения команды и

каждого конкретного человека и команды в

целом, да, через шеринг знаний и так

далее. Почему это важно? Потому что

инструмент хороший, он даёт какой-то

прирост фиксированный. Скорее всего,

процесс он даёт хорошую производную. Как

будет меняться прирост эффективности

дальше? Если у вас хороший процесс, у

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

большом промежутке времени вы сможете

обыграть тех, кто взял суперкрутые

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

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

процесс обучения в компании.

Ну и самое важное, что просто внедрить

инструменты без обучения тоже,

естественно, не работает.

А и рекомендации, которые я обещал

по найму. Задачи на 30-40 минут с

агентом. А нужно, чтобы требовалась

экспертность, то есть, скорее всего,

задача на рефакторинг какой-нибудь.

Обязательно анализ сессий,

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

агентом. Ну, это можно в реальном

времени делать, если он экран шерит. И

ещё полезно спрашивать, какие

инструменты, ну, и инструменты

использовали и для каких задач за

последний месяц, потому что сотрудники,

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

По а разработке, как обучать команду

разработки? Первое, выделить отдельную

команду, выбрать задачи с низкой ценой

ошибки, выгружать сессии и анализировать

их. Возможно, назначить одного из этих

трёх людей, чтобы он анализировал

сессии. Либо можно сделать какой-то

шеринг. что один смотрит сессии другого,

опять же, делать это вместе с е агентом,

потому что иначе это будет бесконечность

времени, и делать итерации. Причём

итерации должны как прокачивать и

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

общается с агентом, и сами настройки

агента, потому что агент по дефолту не

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

хорошо, но не супероптимально и уж точно

не заточен под а ваши позиторий, под ваш

проект.

Что точно не нужно делать? Не нужно

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

отдавать ревью агенту. И вручную делать

ревью тоже не нужно. Нужно находить

баланс между этими двумя штуками. Не

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

этих людей, которым нужны тикеты из

джиры. И не нужно нанимать тех людей, у

кого нельзя было использовать и в

компании. Они этим оправдывают то, что

они его не использовали. Их, наверное,

можно понять, но большой вопрос, нужны

ли они вам в команде.

Что можно почитать? Есть две ссылки. Вот

можно прямо так вбить в поиск. Это

крутая статья от Open Aua. А это статья,

про которую я говорил в начале

презентации.

И переходим к вопросам.

Я готов ответить на ваши вопросы. И тут

я ещё написал небольшой список вопросов,

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

самому себе. В смысле, вы можете задать

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

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

вопросов.

Так, Коль, спасибо. Мы, мне кажется,

немножко уже из тайминга такпадаем,

но давайте, может быть, один-два

вопроса, коллеги. Я я все вопросы, на

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

собрал в отдельный список. Я потом Коли

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

И, наверное, в канале у Коли всё это

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

и так далее. Да, спасибо за

аплодисменты, коллеги. Присоединяемся.

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

Вопрос.

Какие вопросы?

Топовый контент пишут, хвалят, да,

Кольте. Ага.

Так, ну, чуть-чуть мы подождём, да,

пока, может быть, надо время, чтобы

вопрос напечатать.

У нас было несколько минутки есть ещё до

доклада?

>> Да, давай я тогда задам Колю. Там было

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

строим цифровой такой Гулак. Вот когда,

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

этим всем начинаем заниматься. Что по

этому поводу думаешь?

Я не очень понимаю, где ГУК.

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

Гулак - это то, что я предлагаю смотреть

на сессии

ээ разработчиков, да, как они общаются с

агентом. Но в моём понимании это ничем

не отличается от того, что я смотрю на

код его, он как бы комитит свой код в

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

ревью.

Вот, кажется, плюс 15 то же самое. Там

есть отличия небольшие, но на этическом

уровне, мне кажется, абсолютно окей. Ну

>> да, там был ещё вопрос про

собеседование. Лайкодинг на

собеседованиях, но, по-моему, это тоже

нормальная история. То есть смотреть,

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

обращается там и так далее. То есть там

многие феномены можно просто заметить,

наблюдая за тем, как человек

демонстрирует навык.

>> Да. Да.

У меня тут ещё аналогия была с тоже вот

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

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

я смотрел прямо, как человек пишет код.

Ну, чтобы я видел его идеешку в идеале,

чтобы я ещё видел его руки, да, чтобы я

понимал, о, он умеет использовать

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

фишки идешки, он знает, как использовать

дебагер, он имеет то, то, то то, то, то,

потому что, да, это не даёт мне

понимания про фундаментальные знания, но

это даёт понимание про вот этот

мультипликатор, да, который ускоряет его

работу. А мне, как работодателю, это

важно. И кажется, что с Иишкой вот точно

такая же аналогия работает. Просто она

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

больше мультипликатор.

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

кажется, не успеем мы обсудить. Коллеги,

давайте мы здесь остановимся тогда. Я

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

сегодня в тайминге быть и всё успеть. У

нас ещё два доклада вот, включая мой,

поэтому, да, я тут ещё лицо корыстно

заинтересованное в этом. Коль, спасибо

тебе большое. Вот.

>> Да, давай. Если что, если если вопросов

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

интропелок отдельную сессию можем

сделать.

Огонь, огонь. Хорошо, коллеги, спасибо

за вопросы. Я всё постараюсь дособрать.

Вот и Коле передать. Коля, отпускаем

тебя тогда из роли докладчика в роль

ведущего обратно.