AI ускорил разработку: как понять, что это правда — Александр Поломодов — https://youtu.be/KYFPAb1ZfrE

[00:00] А дальше у нас планируется, так, сейчас, замечательный доклад Александра Поломодова. Многие внедряют ИИшку, немногие умеют мерить, насколько вообще это повлияло на качество разработки, на скорость разработки, на все метрики разработки. И, собственно, Александр нам сегодня расскажет, как вообще эти вещи измерять, как понимать, что бизнес реально выигрывает от того, что вы интегрируете ИИ и от того, что что-то меняется в этих процессах. Александр, передаю тебе слово.
[00:31] >> Спасибо. Спасибо за представление. Собственно, постараюсь рассказать. Так, да, мы не в таймингах и, наверное, продолжим быть не в таймингах, поэтому ускоримся. Собственно, у меня доклад называется ИИ ускорил разработку. Как понять, что это правда? Если бы я не покинул предыдущую компанию, в которой 10 лет работал, то, наверное, я за это отвечал ну в конце этого года как раз рассказывал этот доклад в формате ну типа как действительно метрики поменялись, но я ушёл, поэтому
[01:01] расскажу вам другую сегодня историю и вспомню там три примера там разных исследований. Сначала пример исследования из двадцать пятого года нашумевшего исследования Метр про то, что там опытные разработчики, работая в своих репозиториях, им дали ИИ, они ожидали, что их работа ускорится там до на четверть сократится. Соответственно, после выполнения работы они сказали, что ну чуть-чуть меньше было ускорение, и вроде всё всё здорово, всё замечательно,
[01:32] но оказалось, что они замедлились где-то на там на 1/5 времени. И я прямо помню это исследование, потому что часть моих коллега его показывала в формате смотрите, ИИ замедляет. Но на самом деле там есть большие вопросы к самому исследованию. Там всего 16 разработчиков было, 240 с чем-то задачек, всё такое, но эта история как раз про то, что э-э ощущения требуют измерений. То нельзя на них полагаться,
[02:03] и у вас какая-то должна быть методология для того, чтобы проверить, что ваши ощущения вас не обманывают. Это был двадцать пятый год. Метод в двадцать шестом году повторял своё исследование. Там они уже намерили прирост, но давайте пойдём к другому исследованию. Вот. Э-э конкретно в этом было замедление, и это был большой э-э большой хайп вокруг этого. Соответственно, следующая история - это история про Microsoft. Они мерили уже агентов в начале
[02:34] этого года с января по апрель и увидели, что слитых пул-реквестов на инженера в день стало там на четверть больше. Соответственно, они померили, а нет ли тут какой-то там истории, что и раньше на наращивание скорости была. Оказалось, что нет. И в итоге они такие говорят, да, агенты помогают, пул-реквесты действительно увеличиваются, но вопрос типа, а что в этих пул-реквестах? То есть действительно ли они несут пользу? И третья история. Вот буквально
[03:04] хмм в середине прошлого месяца в октябре Антропик рассказывала про то, как у них поменялась работа, и там волшебные цифры были про не только про инженеров, но и про там коммиты на инженера, что они там выросли в пять раз за полгода и в девятнадцать раз времени агента больше тратится, чем времени инженера. Причём это не фоновые агенты, а те, которые тригерятся пользователями. И они вот такой интересный график по наращиванию скорости сделали, где
[03:34] вот эти пункты, которые вы видите, это ну кратный рост. То есть это логарифмическая шкала. И получается так, что после внедрения ну этой агентной разработки сотрудники внутри Антропик начали кратно там ускоряться, чтобы выйти на вот на вот такой на вот такую кривую. Соответственно, оказалось, что это не только у инженеров, но и всяких юристов, там менеджеров и так далее. Ну, не такой конкретно рост, но факт в том, что агенты,
[04:08] ну, в во второй половине, условно говоря, двадцать шестого года меняют меняют темпы деливери - это точно. Вот. Соответственно, о'кей. Теперь важно сказать, что каждый из этих результатов, он относится к своим условиям. То есть метр - это был полевой эксперимент. То есть они на самом деле взяли инженеров, просили делать конкретные задачи, ну, которые они и до этого делали, но с AI-инструментами. Хотя они не умели пользоваться AI-инструментами
[04:39] сами. То есть им купили курс, сказали - идите. Вот. Дальше. Вторая история - это Microsoft, сотрудники внутри, слитые пулл-реквесты. И третья история - это самая, наверное, интересная. Ну, то есть когда ты в разрезе компании смотришь, как меняется работа. И там можно, ну, разные разные метрики посмотреть. И коммиты, пулл-реквесты, какие-то целевые целевые задачи, которые тебя интересуют. Например, там показывали, как продавцы лучше закрывают сделки,
[05:11] да, что там рост кратный вот на сотрудника. Соответственно, и я примерно по такому же пути пройдусь. Ну, то есть покажу, как можно считать на уровне компании Discovery плюс деливери, отдельно деливери или конкретные инициативы. Собственно, кто я, да? То есть я раньше работал в Тинькофф банке, ну, техническим директором последний год отвечал за собственно, за то, как мы это делаем, как мы это измеряем, почему именно так нужно делать.
[05:42] То есть за всё это отвечал. Вот. И теперь я за это не отвечаю, но расскажу вам, как примерно мы к этому подходили, ну и как я вообще на это смотрю. Соответственно, я предпочитаю смотреть на, ну как бы на с разных сторон. То есть первая часть - это история, ну, типа если ты на уровне всей компании смотришь и тебе повезло, и у тебя компания умеет объединять Discovery Delivery.
[06:13] То есть это история про одновременно э-э фактически изменение процессов работы целиком. Не только разработчики там код пишут с агентами, а и продукты в этом участвуют, и дизайн, и все остальные, и процессы полностью перестраиваются под, ну, под новые под новые подходы. Соответственно, бывает иногда, когда тебе говорят нет, дорогой друг, Discovery это менеджмент, бизнес, какие-то продукты, они очень такие э-э артистичные персоны,
[06:43] придумают свои супер идеи, давай как кодом займёмся, пускай кода будет больше. То есть имплементации вот этих гениальных ide пускай code review побыстрее будет, operations получше. То есть там тоже кое-что можно считать. Ну и третий случай, он такой более локальный, когда вы, например, отвечаете за какую-то за какую-то инициативу. То есть не всю компанию, а вот, например, вы AI code review делаете или AI миграции. Или вы пытаетесь,
[07:14] ну, усмирить и дать вашим как раз гениальным продуктовым ребятам возможность без инженеров какие-то прототипы проверять и, может быть, катить их быстро. Соответственно, вот примерно так мы пойдём по этому по этому сценарию, вот, и дальше да дальше давайте двигаться. Вот. Начнём с измерения на уровне всей компании. Причём с такого хорошего подхода, когда у вас есть э-э как сказать-то?
[07:44] Когда у вас есть какие-то полномочия и желание бизнеса меняться, когда вы можете идти в сторону не только поставки изменений, но и генерации гипотез, вот, и можете end-to-end померить весь путь, ну, до поставки результата клиенту. То есть вот примерно так это выглядит, да. То есть есть Discovery часть, то есть какую проблему мы решаем, какую гипотезу проверяем. Собственно, деливери - это обычно то, что в командах разработки есть. То есть реализовать и выпустить какое-то изменение, проверить качество.
[08:17] И там третья история - это, собственно, результат, который поставил он клиенту, измерить это, ну, как бы эту фичу, э-э, как она отработала на клиенте. Э-э, и вот там супер желание на самом деле мерить end-to-end там метрики, да, что мы полезные вещи выпускаем быстрее, дешевле и так далее. Не всегда так получается, но если получается, то обычно ты можешь сказать, а за какой ты домен отвечаешь.
[08:47] То есть часто есть какие-то, э-э, команды внутри, которые готовы меняться. Ну вот здесь примерно, например, активации, э-э, там новых новых пользователей, да, то есть, что они, э-э, ну вот вы их привлекли и дальше они, не знаю, например, карту оформили или там кредит взяли или там ещё что-то сделали. Да, у вас есть, э-э, собственно, какая-то какая-то метрика, вот. У вас есть, э-э, ну, которую вы оптимизируете. У вас есть, э-э, контрматрика,
[09:18] защитные показатели. Например, что обращений в поддержку стало, ну, не слишком много. И дальше вы пытаетесь вот, ну, типа померить, э-э, сколько вы инициатив выкатили, в какой срок они доезжают до, ну, до клиента. И можете даже измерить, э-э, эффект, ну, который там ваша фичи принесли, да, ну то есть, э-э, там как они повлияли на эту метрику, собственно, сколько стоили переделки. Вот, сколько вы потратили на всё это добро. То есть работа команды,
[09:49] токены, вот, включая неудачные попытки. На самом деле, э-э, это супер супер возможность, если вы можете мерить так. Но обычно проблема в большой организации, что она не гомогенна. То есть у тебя разные блоки организации, э-э, по-разному принимают эти изменения. Ну, говоря, компании, где я работал до этого, были команды, которые полностью перестроили свой процесс, условно говоря, разработчики,
[10:20] они стали работать, ну, по-другому. Например, уехали с вики, сложили источник там как раз фичей а-ля в DDD формате в репозитории. Вот. Ну, от это было как бы постановка задачи, которую дальше подхватывал там разработчик, доводил, ну, при помощи до каких-то спек, которые можно было отдать агенту, ну, и дальше выкатить это изменение.
[10:51] У ребят, честно говоря, всё было хорошо. То есть видно было, как они, как они фигачат, как они получают результат. Проблема в чём? В том, что этот подход не очень хорошо, ну, не очень хорошо масштабируется. И когда он масштабируется, у вас получается такая история, как [откашливается] вот стандартная, да, тема Мы тут с Глебом Михеевым как-то разбирали, вот куда идёт индустрия, что у нас есть, фактически вот в команде появляются ощущения, что у нас есть продуктовые ребята и инженеры, которые могут
[11:23] ну, типа забрать эту проблему или задачу и довести её до конца. Вот. И они ещё про домен понимают, и про то, как с агентами работать. Всё замечательно. Правда, возникает вопрос, а куда деваются, да, другие люди из команды? То есть в больших крупных компаниях часто есть аналитики, там разработчики разных видов. Но такое ощущение, что вот если вы меняете команду так, то у вас она становится маленькой, полностью там
[11:54] у вас уменьшается как раз число передач между ролями и время ожидания в этих фазах передач. То есть вы это прямо можете померить, посмотреть на то, как выглядит сейчас, как выглядит процесс. Вот. Собственно, сколько людей в команде, сколько задач между ними Э, вы можете метрики потока посмотреть, да, от постановки задачи до эффекта у клиента прямо, ну, типа end-to-end метрики. Вы можете контрметрики посмотреть, на качество там инциденты,
[12:24] на то, как нагружена команда, всё померить. Скорее всего, в такой, ну, команде, там высоко замотивированной, у вас все красивые вот эти метрики, ну, в смысле, все метрики такого плана будут чувствовать себя хорошо. Просто проблема в том, что таких команд их, хмм, ну, на общем фоне не очень много, но многие сейчас из индустрии, по крайней мере, в России, э, рассказывают про продуктовых инженеров, про тайни тимс, про то, что вот движение должно быть в ту сторону.
[12:55] Всё хорошо, но непонятно, ну, когда это движение дойдёт, э, до, ну, до внедрения. Давайте теперь посмотрим на уровень, когда, э, вам говорят о'кей, э, ты классно рассказываешь про изменения состава команд, тайни тимс, продакт-инженеров, про сближение бизнеса и IT, но давайте, ну, типа, бизнес оставим бизнесу, а вот, э, IT пускай отвечает за свои метрики. То есть это история, когда тебе говорят, э, чувак, будь добр, ускорь нам деливери
[13:25] часть. То есть дискавери мы не трогаем, как придумываются эти суперзадачи, кто их описывает, как ставит это Хмм, давайте мерить, да, мерить, э, метрики деливери. Это интересная история. Собственно, есть, э, такая платформа DX, э, которая, которую создали ребята, которые дора метрики придумывали, книжку Accelerate написали, там кучу фреймворков про developer productivity сделали.
[13:55] В какой-то момент в двадцатом году они стартанули новую компанию, а в двадцать пятом году их выкупил Atlassian за миллиард долларов, сказав, что ребята, у нас не получилось сделать систему для оценки developer productivity, а у этой внешней компании получилось, так что нам нужно её купить. Соответственно, у этой компании, э, ну, у DX, которая ещё не была тогда частью Atlassian, был некоторый фреймворк. Фреймворк выглядел примерно так, что если мы говорим с вами про части
[14:26] давайте ориентироваться на три составляющих. То есть первая составляющая - это использование То есть это охват лицензиями, ну инструментами, какие-то количественные метрики, типа коммитов, пулл-реквестов при помощи агентов и так далее. То есть, ну какая-то штука, которая говорит тебе скорее про то, что инструментом пользуются и ну она чем-то похожа, знаете, на старую метрику например, количество коммитов или пулл-реквестов, которые там выросли при помощи ей.
[14:56] Соответственно, вторая вторая составляющая, ну как бы, которую ребята предлагали мерить - это история про то, как мы экономим время, вот, метрики потока, там качество, Ну [фыркает] и третья часть - это была история как раз про затраты и окупаемость решения, то есть какая экономическая составляющая, которую стоило мерить. Собственно, в Т мы примерно так пытались это померить. Спойлер,
[15:26] первые два ещё как-то, ну можно померить, некоторые напрямую, некоторые косвенно, но ну третья у нас не очень получалась. Вот, давайте пойдём вглубь и ну как бы о чём это речь. То есть это история, например, ну вот это внедрение, ну то есть использование инструментов. Вообще надо оценивать не, ну типа, не абстрактно в вакууме, а понимать кто, да, пользуется инструментом, где,
[15:57] ну то есть в каком контексте и насколько там часто, в каком режиме. Вот, и ну как бы это всё нужно разделять. Соответственно, если мы говорим про там про, ну там процентное соотношение, то важно понимать как мы этот процент считаем. Например, люди. То есть нужно считать не просто люди, которые использовали AI и относительно всех людей, а относительно тех, кто имели доступ. Потому что не всегда у тебя все имеют доступ, ну или там выданные нормальные лицензии людям.
[16:27] Тесты с задачами тоже не просто задачи, которые решали с помощью AI по сравнению со всеми задачами, а скорее всего у вас не все задачи, ну там по критериям подходят к этому. То есть метрику, когда выбираете, нужно понимать, что ну вот процентное соотношение, вам и числитель важен, и знаменатель для того, чтобы ну внятно посчитать эту историю. Соответственно, дальше. Скорее всего, вы хотите разделять то, как это работает. То есть, условно говоря,
[16:58] режим работы. То есть, когда у вас человек интерактивно взаимодействует с агентом в таком как бы в режиме ассистента, вот, или это полностью задача делегирована куда-то там, не знаю, выполняется, не знаю, в какой-нибудь пайплайне, шедулится или к какому-то триггеру, то есть и человек там вообще не присутствует. Соответственно, мало того, вам ещё нужно понимать, насколько параллельно ну задачи выполняются, потому что это тоже честно посчитать буквально на следующем
[17:29] графике покажу. Ну не на следующем, через несколько покажу, почему. Соответственно, в расчётах очень классно разные источники использовать. Мне в этом плане очень импонирует там подход Гугла, ну типа у Меты, запрещённой в России, тоже был, когда вы телеметрию снимаете с разных инструментов, то есть у вас есть логи, вы их можете превратить в события, дальше события объединить в сессии с привязанными артефактами и уже относительно этого считать какие-то метрики.
[18:01] И ну то есть это позволяет вам ну интересные метрики считать. Например, буквально вы хотите понять, насколько там, не знаю, агент ускоряет вас и ну вы не знаете, когда человек над какой-то задачкой стартует, что он над ней стартует. Вам нужно ну типа собрать вот такой пайплайн обработки данных, чтобы в итоге получившийся в первой сессии артефакт привязать к какой-то задаче и понять, что он сделан. Например, в внутри Т были проблемы с этой телеметрией,
[18:33] и мы часто не могли первый этап до того, как что-то попадало, ну, не знаю, в систему контроля веса, и померить. Это съедало часть, ну, типа, часть сути э-э метрики. Например, про там насколько быстрее ты мёржишь квесты, делаешь ну, по задачам с AI-инструментами. Соответственно, это пайплайн Гугла был. Дальше ребята из Гугла, ну, в своей серии очень прикольно рассказали про такой продуктовый подход к оценке
[19:05] того, а что делают твои инженеры. Они же не просто кодяру пишут, да, у них есть там некоторые задачи в рамках SDLC. То есть у ребят был там шесть этапов от сбора информации, там планирования, согласований, собственно, разработке, там эксперимента, выкатки, мониторинга и управления данными. И они сказали, что а давайте мерить в разрезе фактически джабов, которые наши инженеры выполняют. Нам не так важно в разрезе инструментов мерить, скорее типа, а как у них получается выполнять эту работу,
[19:35] закрывать свои цели. И в итоге что получилось? Что при таком подходе ты можешь, связав с тем пайплайном, понять, а насколько твои джабы действительно, ну, много времени занимают, насколько они успешны. И меняя не только, там, AI-инструменты, а там любые части твоего процесса, померить, они помогают вообще этим, ну, джабам быстрее случиться или нет. Отдельно скажу, что у нас вот такое приседание было. Проблема была в том, что пайплайна телеметрии, ну, полноценного не было, и, ну, часть данных было не собрать.
[20:10] И, ну, помните, я рассказывал про про параллельность? То есть человек часто может там что-то делать и сгенерировать кучу агентов. Вам скорее всего нужно уметь понимать, ну, оценивать время человека, сколько он там тратит в работе и сколько там агенты в фоне работают. Например, в том про который я упоминал ну, про середину октября, они показывали, что агентов, ну, их времени стало в 19 раз больше, чем инженеров.
[20:40] То есть, условно говоря, у тебя один инженер запускает такое количество этих агентов или там саб-агентов и так далее, что там, в принципе, прочитать, что они там сделали, невозможно. В том плане, ну, там ревью изменений - это большой вопросик. Вот. Соответственно, мы, ну, видели в наших процессах, что код действительно код действительно можно, ну, типа производить быстрее, но метрики там по потоку не особо росли.
[21:11] Почему? Потому что у нас, как и у всех, начали застревать задачи на ревью, на всяких согласованиях, проверках. В итоге, если ты меришь на уже там деплои, выпуски изменений, ты видишь, что, ну, типа токены сожжены, люди вроде поработали, все люди во всех ролях, на всех этапах показывают тебе рост своих количественных каких-то метрик активности, но для бизнеса изменений особо нет, а если они есть, то ты заглядываешь внутрь, и они скорее у команд, которые поменяли свои подходы к работе.
[21:43] Вот, которые объединили и стало, ну, как бы они стали работать по-другому. И, ну, это достаточно интересно. Почему? Потому что ты, помимо логов, из которых ты вытаскиваешь данные, что в системах происходило, ты ещё и опросы устраиваешь, интервью, и ты пытаешься понять, а почему так, да? То есть, например, тебе люди на опросах рассказывают про то, что согласования безумно ну, долго занимают, что, не знаю, там инфраструктура начинает от количества артефактов,
[22:14] которые у тебя внутри гоняют, работать там медленнее и так далее. И ты начинаешь понимать, что ага, то есть у вот этого количественных характеристик, которые зачастую в начале ставились как цель, а генерировать больше кода, тестов, не знаю, требований, вот, у них есть последствия, которые, ну, не позволяют увидеть. И вот, объединяя логи, что происходило с опросами, где тебе рассказывают о собственных ощущениях инженеры и с интервью,
[22:45] ну, дип дайвом, ты можешь собрать общую картину. Это прямо, ну, интересно. И отдельно стоит отметить, что эти инструменты, они очень сильно, ну, типа, меняют сам процесс на боты. Например, вспоминая мета они хотели провести похожее исследование в двадцать шестом году, как было в двадцать пятом, но им было сложно, потому что участники уже часть отказывалась работать без AI, вот, часть задач они, ну, не
[23:16] не хотели включать в этот набор, потому что, ну, сам эксперимент. И, собственно, параллельное время работы агентов, на самом деле, тоже мешало подвести итоги. В итоге эксперимент от февраля двадцать шестого года, скорее, был про то, что скорость, ну, типа, скорость всё-таки не замедляется, ускоряется с новыми агентами, но как это, ну, типа, интерпретировать, это, ну, типа, достаточно сложно. И отдельно стоит отметить, что во многих этих экспериментах
[23:48] не случайно назначаются участники, вот, и, ну, сложно сравнивать там результаты между собой. То есть у тебя нет настоящего там эксперимента с контрольной группой и всем остальным. И у вас не не чистый причинный вызов вывод получается. Соответственно, о'кей, то есть вот мы поговорили про уровень компании Discovery Delivery, потом отдельно Delivery. И теперь я хотел чуть-чуть рассказать про, ну, вот, инициативы, да, если вам
[24:19] оказалось так, что вы за какую-то инициативу отвечаете. Я когда готовился к этому, ну, как бы, выступлению, понял, что сравнивать чисто, да, вот, как типа было без AI и стало с AI, ну, уже сложно. То есть, например, тот же самый AI ревью или миграции, или вайп-кодинг, он вошёл в нашу жизнь, ну, как бы, и это уже не отменить. Поэтому интересно сравнивать скорее не чистое, ну, например, ревью с AI или без AI, а как как посчитать, ну, что ваши изменения в сам этот процесс
[24:50] приносят пользу, ну, что их нужно, например, оставить. И в условного AI ревью - это история про, ну, вы хотите на выходе какой-то проверенный пул-реквест и с высоким качеством, если его сменджат. В миграциях вы хотите, ну, типа принять изменения и так, чтобы в проде ничего не случилось. Вот. С прототипами вы хотите их, ну, позволить делать самим там продуктовым ребятам, чтобы они могли сами, э, ну, как бы без команды какие-то гипотезы проверять.
[25:22] И, ну, это тоже можно проверить, насколько это помогает. Например, да, AI ревью. Как оно обычно выглядит, э, стандартно? То есть у вас бот проверяет пул-реквест, делает замечания по коду. Автор их там разбирает, проверяет сигнал, исправляет, э, ну, как бы ревьюер, ну, как бы проверяет вам риск, остаток работы. В общем, в целом, в итоге это всё мэндится куда-то. О'кей. Типа как нам, ну, типа что нам хочется, да, померить? Вот.
[25:52] На самом деле нам хочется измерить, а вообще польза от этих находок на AI ревью, она есть или нет? То есть дальше нам хочется померить, а труд разработчиков и стоимость вот работы AI-агентов, она, в принципе, ну, как бы отбивает, то есть на как бы сходится экономически? Вот. Качество на выходе, оно как бы становится лучше? То есть, условно говоря, мы пропускаем меньше дефектов. Вот. Находим какие-то важные, ну, типа проблемы до выкатки в продакшн,
[26:22] да, то есть код качественнее получается. И, э, на самом деле, ну, если вот какой-то мысленный эксперимент, да, увидеть, э, то вот представим, что у вас там есть 100 вот. Ставка инженера, ну, какая-то, например, 60 долларов в час. Представим, что ну как бы при текущих правилах у вас 100 этих инженер обрабатывает за 8 часов, 30 долларов тратится на AI. Представим, что вы меняете процесс, да? Ну то есть вы как-то меняете правила
[26:53] и ну и у вас и человек меньше работает, и AI меньше тратится, и вы можете, ну типа, вот эту экономию записать себе. Понятное дело, что так ну редко можно посчитать напрямую, но ну как бы, например, на моменте, когда мы AI код ревью впиливали, ребята показывали много красивых метрик. До экономики они не доходили, вот, но, например, на тему того, сколько бы это стоило поревьюить людьми, да, у которых есть какой-то
[27:24] То есть они на этом уровне останавливались. И чуть раньше была история про и ревью ну типа изменений, что там ревьюить или не ревьюить - это вопрос риска. Собственно, тут примерно такая же история, что ну как бы нам нужно ревью настроить, ну типа по риску Нужно понимать, что мы меняем, вот, что мы меняем, то есть как мы сравниваем и типа когда ну типа когда оставляем вот это изменение у себя в пайплайне.
[27:57] Соответственно, другой кейс, тоже из тех, которые все внедряют и все оценивают. Вот, здесь отсылка там к гугловой статье Вот, по-моему, двадцать пятого что ли года, ну то есть не то, чтобы самая свежая, но суть в чём? В том, что с миграциями достаточно просто, то есть примерно так же. То есть вы хотите, чтобы миграция ну как бы например вы с одной версии библиотеки на другую переехали,
[28:28] с одного версии языка там на новую версию языка. Иногда вы хотите очень поменять язык с одного на другой, например, с какой-нибудь Скалы на Джаву или Котлин. И, ну, как бы вы понимаете, сколько, ну, примерно понимаете, сколько это стоит на уровне, сколько инженеров, ну, типа, потребуется часов для этого дела. И, ну, как бы вы можете посчитать, сколько стоит подготовка, настройка правил, ревью результатов, работа агента.
[28:59] И, э-э, получается так, что, э-э, ну, типа, экономику тут посчитать можно. Если у вас таких, ну, типа, таких изменений много, да, вот этих миграций, то вы понимаете, что, в принципе, это имеет смысл. И, ну, нам на какой-то там, э-э, там пятый, шестой, седьмой там типовой миграции вы это всё отобьёте. Вот. И, хмм, обычно вы, ну, как бы вот примерно берёте историю, оцениваете
[29:29] и понимаете, что там с пятой, шестой, ну, то есть какая-то партия окупается. Вы делаете скан по вашему репозиторию, ну, типа, по вашим всем репозиториям, всем системам, сколько таких мест, которые нужно мигрировать, и говорите, о'кей, брейкинг наступает вот в этот момент, а у нас этого добра бесконечно. Главное, знаете, в чём? Э-э, в том, что, э-э, вы можете легко себе записать успех миграции, когда вы сделали, например, 95% там изменений. Но есть проблемка, что,
[30:00] э-э, часто, ну, типа, миграция это такая история, которая, хмм, как сказать-то? То есть вам нужно не просто мигрировать на новый, ну, на на новое решение, вам нужно понять, что в старое вы погасили, да, что у вас не осталось, ну, хвостов каких-то, что заставляет держать, не знаю, старые системы. Дальше, э-э, проблемы, которые выяснятся, часто они всплывают постфактум, уже на проде. Вы помните, наверное, как Антропик переписывал бан, э-э, с Зига на Раст, и выяснилось, что все тесты были зелёные,
[30:32] но регресс они всё равно нашли не покрытые тестами уже на продакшне. Вот. Скорее всего, у вас тоже так будет, и тестов у вас будет сильно меньше, да, на поведение вашего приложения, чем условного э-э бана. Ну и дальше история в чём? В том, что часть вещей придётся, ну, руками инженеров закрывать. Это тоже классно бы посчитать. Потому что если мы это не считаем, то миграция выглядит как суперкейс, где можно показывать, что AI рулит,
[31:03] и мы заработаем какая-то безумное количество, ну, или сэкономим безумное количество денег. Третий последний кейс, который хочется упомянуть очень быстро, это история про там веб-кодинг, да, когда у нас продакт продакты проверяют свои гипотезы без нас, делают прототипы с AI, ну и дальше хотят их катануть на пользователя и проверить. Соответственно, здесь история обычно про стоимость проверки гипотезы. То есть вы можете померить
[31:34] время, насколько быстро вы можете это сделать, дальше насколько там сколько затрат на это идёт, и дальше, ну, типа посмотреть результат-то получилось катануть или нет. Но в этой всей схеме люди часто забывают, чтобы реальный прототип катануть на пользователей, требуется нехитрая работа какой-то платформенной команды, которая сделает так, чтобы этот, ну, типа создание прототипов, оно было достаточно продакшн-реди, чтобы этим прототип можно было катануть, ну, условно на прод хотя бы версии там
[32:07] веб-вью внутри мобильного приложения, и ничего не развалилось. То есть вот эта подготовительная часть, она обычно требует времени, и многие крупные компании делают себе аля лавабл внутри, ну или пытаются сделать как раз для продактов, которые говорят Вот если бы мы могли быстрее катить изменения, вот точно бы заработали миллиарды денег. Вот. Но так обычно не бывает. Собственно, тоже можно посчитать какой-то условный тестовый сценарий. Мы это считать не будем, но важно не забывать как раз, да, что вот эта передача в деливери какая-то должна наступать
[32:43] и что если этот прототип потом стреляет, то его нужно превратить в рабочее решение. Вот. Соответственно, часто, ну, выигрыш бывает в часах, ну, сэкономленных командой. Отдельно нужно сказать, что сэкономленные часы каких-нибудь людей, они автоматически в деньги не превращаются, ну, не конвертируются. Может оказаться история с денежным эффектом. То есть если вы катанули фичу, которая там быстрая, и она принесла деньги, и вы можете это как-то засчитать, что вот без этой, ну, типа
[33:14] AI, мы бы эту фичу не катанули в этом году точно. Вот. Но вам нужно помнить, что вы ещё затраты несёте. То есть нужно экономику считать, что она сходится. Соответственно, контрметрики - это риски, ну, и качество. То есть это история про дефекты, потому что, ну, часто можно катить очень быстро, если вас не интересует качество результата. Соответственно, у каждого, ну, из этих сценариев есть вариант, что делать после расчёта, как вы ну, свели экономику. Э-э,
[33:44] если вас заинтересовали эти темы, вы можете посмотреть мой разбор Продуктивность для людей, ну, то есть это серия Гугла про то, как они считают какие подходы используют. Я буквально там несколько примеров говорил. Есть, э-э, пример, ну, у меня гость был, где мы про AI и продуктивность чиков прямо демо-платформы смотрели, которую ребята там крупным компаниям на российском рынке показывают. И был у меня выпуск, где я про экономику AI в разработке
[34:15] говорил. И хотел добавить последнюю ложку дёгтя, э-э, примерно такую. Смотрите, часто, когда говорят про метрики там ускорения, э-э, или там, э-э, то, что мы можем, не знаю, в 10 раза больше задач делать с AI. Может быть и можем. Вопрос в чём? Представьте, что смогли. Вот. Но тогда мы сталкиваемся с историей с убывающей полезностью там конкретного ресурса. То есть, э-э, скорее всего в 10 раз больше результата не получится. То есть, если мы этими же силами работаем на тем же бэклогом, который был до этого,
[34:48] и у вас кривая, скорее всего, будет вот куда-то туда закругляться. То есть, условно, вы в 10 раз больше будете фичей катить, они дадут, не знаю, в два раза больше бизнес-эффекта. Ну, и это, ну, объективная реальность. То есть, в какой-то момент, ну, если не менять подход целиком и не снашивать их, а, условно говоря, быстрее разгребать разгребать текущий бэклог, вы начинаете всё менее важные задачи пытаться пилить, которые, ну, в бэклоге висели,
[35:19] ну, и как бы тухли. Вот, а теперь вы их можете делать быстрее, но бизнес-эффекта они не дадут. И когда я про это думаю, мне всегда кажется, что вот эти интересные рассказы про то, что сейчас мы заменим часть работы при помощи ну, то есть агентом делегируем и сможем делать больше, они забывают, что не у всех компаний есть, что делать больше. Да? То есть иногда ну, продукт не так растёт, что ему требуются там бесконечно
[35:49] бесконечные доработки. Собственно, на этом всё. Вот. Если нужны какие-то конкретика, у меня её есть. Я вам с вами могу ещё поделиться. Пишите в телегу, в LinkedIn, куда-нибудь, короче, пишите. Я вам с удовольствием на это отвечу. Вот. Всё. >> Так, Саша, спасибо тебе огромное. Было супер интересно. Мне мне особенно откликается, потому что я в том году на какую-то похожую тему делал тоже доклад, где я пытался объяснять, как считать все эти истории.
[36:24] Вот пару вопросов тебе хочу задать, которые и в чате мелькали, и просто мне в голову приходят. То есть ты ты вскользь упоминал, на самом деле, про эти вещи, просто хочется детализировать. Вот одна из проблем, когда ты пытаешься мерить разработку, особенно если у тебя там команда не 1.000 человек, а поменьше, это сильная неоднородность задач, и из этого складывается не очень качественная статзначимость конечных метрик, которые ты там посчитал. Вот, э, что об этом думаешь? То есть если пытаться всё-таки количественно оценивать эффекты,
[36:54] как можно ну, типа, сравнивать, э, слонов с помидорами и чтобы всё нормально, адекватно считалось. Ну то есть чтобы разные задачки приводились к каким-то единым классам или категориям. >> Смотри, э, на самом деле это супер, ну, типа, классный вопрос, и я бы отдельно сказал, что вот эта вся история с количественными показателями и статзначимостью, она, ну, на масштабе Гугла работает, на масштабе, например, Т-банка тоже работает. А тем людям, у которых там, не знаю, 100 инженеров, ну, им вот с, э, там статзначимостью,
[37:27] наверное, заморачиваться не стоит. Вот. Но когда ты меньше, то ты, э, в принципе можешь обозревать, а что происходит. И ты можешь вот эти кластеры задачек, например, у тебя есть кластер интеграции, да, с каким-то, ну, там, партнёрами, понимаешь, что это такой тип задачек. Другой, не знаю, ты правишь какие-то, там, фронтовые свои штуки. Вот тут вот ты, не знаю, движок какой-то свой правишь или внутренние какие-то вещи. Ты можешь их разбить на классы и внутри этих классов оценивать, как, ну, типа, что происходит с задачами. И, скорее всего, ты увидишь неравномерность, что, например, фронтовые задачи
[38:00] сильно ускорились, например, ну, потому что, там, агенты это хорошо делают. Дальше интеграции могут не сильно ускориться, но ты такой посидишь, поймёшь, что нужны правила, которых не было, которые были в голове людей, опишешь их, и они ускорятся. А какой-нибудь, не знаю, 1С, меня периодически спрашивают, а что с 1С, да, который у тебя там бухгалтерский. Да я хрен знаю, что с 1С, я не знаю. Типа, агент, ну, модели учились на нём, нет? И, может быть, он и ничего не, ну, как бы не ускоряет у тебя, да, агент, потому что ну не может он разобраться с своим чудо-1Сом.
[38:30] Короче говоря, ну, им нужно это принять или нужно его как-то поправить, да, ну, типа, сделать доступным для агента или сказать, что вот, ну, чудо-1С, у меня чудо-1Сники, короче, правят. Вот примерно такой ответ. Но он был в твоём самом вопросе. Вот так классный вопрос. >> То есть, ну, э, >> бухгалтеры вы- выходят самые защищённые. Им пророчат, что их скоро заменят, это когда Excel вышел, потом когда всякие ERP системы появились, теперь агенты, и в итоге никто их не может к ним прикоснуться. Потому что на 1С >> бухгалтерия - интересная история, что вот, ну, типа в Т была своя бухгалтерия
[39:03] в, э, банке для юрлиц. И у меня был эпизод, где мы общались с чуваком, который занимался автоматизацией. Он говорит, что там на самом деле, если не не про 1С говоришь, а, например, про какую-то веб-бухгалтерию с правилами, которые очень регламентированы и так далее, и накручиваешь, ну, типа автоматизации, что там, ну, если ты не в домене 1С, да, копаешься, а просто вот, ну, вот этой регуляторики, там очень неплохо на самом деле это всё работает. То есть просто 1С - это какая-то такая чёрная дыра, знаешь, это вроде один язык, а там каждый настраивает,
[39:35] ну, что-то своё и непонятно как. И типа транслируется ли, ну, в смысле есть ли генерализация знаний и трансфер лёнинг, что типа один 1Сный код, набравшись с ним соседний будет лучше? Не знаю. Может быть, не знаю, Сбер сделает ги- гига- гига-1С, короче, или ещё что-нибудь, чтобы наконец-то осчастливить российских 1Сников. >> Да, я тоже, к сожалению, не знаю. Я я не писал на нём, поэтому мне трудно предположить, насколько он там похож на соседние языки. Хочется верить, что похож, но тем не менее.
[40:05] Слушай, ещё один вопрос, а, про, э, парадокс качества. То есть одна из, э, вещей, которые часто прочат, когда команда начинает очень активно внедрять ишку, агентов и прочее и прочее, что качество кода невероятно упадёт. Но при этом, вот моё наблюдение в том числе часто было, что происходит зачастую обратная вещь, потому что, а, поддержание качества кода через там тесты всякие разные автоматизированные, линтеры, статические анализаторы, бла-бла-бла, оно становится супер дешёвым. Ты можешь хоть кастомные
[40:35] правила создавать с агентами и в огромном количестве. Что думаешь на этот счёт? То есть вот смещение этого бутылочного горлышка, э, переходит ли оно реально в качество и падение или нет? >> Смотри, давай я тебе отвечу так, э, в до опросе, ну, одном из них, ну, типа отчётов, была история, что она работает как усилитель текущих процессов твоих. Соответственно, если ты был крутым инженером, выстроил процессы, ну, дальше ты такой смотришь на эти все инструменты, говоришь, отлично, вот я никогда столько тестов не мог писать.
[41:05] Мне всегда говорили, ну, типа слишком дорого, давай без тестов, давай побыстрее. Типа хотел фитнес-функции на архитектуру делать, ну, блин, постоянно они ломаются, с ними нужно разбираться, там только какой-то высоколобый чувак может разобраться, что не так. Ну, короче, не получается там. Ещё что-то, понимаешь, да? Вот, ну, как бы ты хотел закрутить систему, ну, то есть работать с её энтропией, но тебе мешало то, что у тебя времени не хватало. С агентом ты приходишь и говоришь, хочу по красоте, вот вот типа вот я прямо хочу, давай. И начинаешь говорить с ней на том языке, который, ну, как бы как в этом домене, да?
[41:39] Ну, то есть и тебе начинают отвечать агент, говорит, да, давай сделаем это, то, пятое, десятое. И ты такой выходишь вообще счастливый, замечательный. Представь теперь другую команду. Она никогда тестами не занималась, вот эти всех умных слов не знает, она говорит, агент, катани мне фичу, короче. И агент катит и вторую, и третью, и пятую. И дальше получается месиво, короче. И там дальше проблема не в том, что агент не может тебе сделать, ну, типа красиво вот эти инженерные практики. Проблема в том, что ты должен знать про их наличие и примерно, ну, типа нужные слова уметь говорить
[42:10] и посмотреть, агент вообще в ту сторону идёт или нет. Соответственно, ну, как бы когда ты оказываешься вот в этом месиве, скорее всего, ты зовёшь какого-то специалиста, который знает и про инженерные практики, и про работу с агентами, и говоришь ну ему, чувак, вот не могу, короче говоря, теперь я не фичи пилю, а постоянно баги вылезают, и я их только правлю. Знаешь, вот как с каким-нибудь лепят там, когда там на трёхсотой итерации ты какую-то сложную фичу просишь сделать, и у тебя всё вокруг от отваливается, ты такой, а теперь почини 10 багов после этого.
[42:41] Вот. То есть чтобы такого не было, тебе нужны вот эти правила. И тебе нужен кто-то, кто может их, ну, то есть настроить. Ты можешь же сам обучиться, тебе просто нужно знать, что это возможно. Вот я думаю про это, что если ты знаешь, что, ну, там, условно говоря, руки нужно мыть там перед операции, да, ну, то есть нужно какие-то другие санитарные нормы выполнять, то всё будет нормально. А если ты просто как, знаешь, от хирург в средневековье такой, ну, у меня есть скальпель, я пошёл резать, но твои пациенты выживать не очень будут хорошо.
[43:13] >> Это да. Слушай, но мне, кстати, вообще ещё нравится мысль промелькнула, что не уверен, что это экспонента, но как некая форма рекурсивного улучшения, у тебя получается, что команда, которая by design настроила себе вот эти вот все культуру разработки, скажем так, её же агенты от этой же культуры выигрывают. Это вот то, про что доклад Кости там был пару часов назад, что, в принципе, агент перестаёт упираться в техдолг, и он расширяется. Так что это действительно клёво. Всем всем советуем делать хорошие кодовые базы.
[43:43] Вы выиграете, агенты выиграют, и юзеры будут счастливы. >> Там знаешь, в чём прикол? Что у тебя то, что было хорошо раньше для людей, оказывается хорошо зачастую для агентов. И как бы как будто такой усиливающий цикл получается, что если ты был молодец, то ты такой говоришь, о, агенты у меня работают. А сосед, который, ну, не не внедрил эти практики, это у меня агент какую-то херню делает. И ты такой говоришь, может быть, у тебя руки не очень прямые? >> [смех] >> Не, ну да, ну да, это правда. Ладно, спасибо тебе большое, Саш.
[44:14] Было очень интересно, было здорово. Рад был послушать, но нам надо двигаться потихонечку дальше.