Speaker A
Итак, спект дривен дизайн. Честно, кто-нибудь вообще пользовался этой штукой когда-нибудь? О, 1, 2, 3, 4. Ну, уже пошло, пошло, пошло. Значит, уже не такая уж и нишевая тема, как модно говорить.
Обзор спецификационного подхода в разработке, влияние AI на продуктивность и практические кейсы из Авито.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- AI увеличивает скорость разработки, но не всегда повышает ценность продукта.
- Спек-дривен подход помогает уменьшить фрустрацию и повысить качество разработки.
- Необходим баланс между автоматизацией и человеческим ревью для предотвращения технического долга.
- Внедрение новых методологий требует времени и адаптации в командах.
- Важно измерять не только скорость, но и реальную продуктивность и пользу от AI.
What the video covers
- Введение в спецификационное (spec-driven) развитие и его актуальность в индустрии.
- Обсуждение медленного внедрения AI и современных методологий в компаниях на примере Авито.
- Анализ исследований продуктивности и фрустраций разработчиков при работе с AI.
- Различие между скоростью разработки и реальной пользой продукта при использовании AI.
- Проблема накопления технического долга из-за недостаточного ревью AI-сгенерированного кода.
- Примеры, как AI помогает выполнять задачи, которые раньше были сложны или занимали много времени.
- Важность оценки не только скорости, но и ценности, которую приносит AI в процесс разработки.
- Описание внутренней инфраструктуры Авито для поддержки spec-driven разработки и AI-инструментов.
- Обсуждение проблем отсутствия единого стандарта для спецификационных фреймворков.
- Ответы на вопросы аудитории о роли специалистов и изменениях в командах при внедрении SD.
Chapters
- 00:00Введение в спект дривен дизайн и актуальность темы
- 02:26Исследования продуктивности и фрустраций при работе с AI
- 05:28Различия между скоростью и пользой AI в разработке
- 07:48Примеры влияния AI на выполнение нетипичных задач
- 10:34Проблемы потери контекста и спецификаций в AI-процессах
- 13:26Внутренние инструменты Авито для поддержки spec-driven разработки
- 21:05Проблемы отсутствия единого стандарта для спецификаций
- 28:37Вопросы и ответы: роль специалистов и изменения в командах
Full Transcript — Download SRT & Markdown
Speaker A
Итак, кто я такой? Я Шиповалов Александр. Руковожу, э, технической частью нашего HRха в Авито. Являюсь кластерлидом. Вижу, как медленно внедряется AI даже в нашей компании, хотя уже столько лет внедряется, не то что современные методологии. И я пытаюсь это ускорить.
Speaker A
Так, сегодня я расскажу вам про некоторый такой путь от просто я к SD и как его можно оптимизировать.
Speaker A
Немножко начну с цифр. Не хочется сразу переходить непосредственно к методологии, говорить про неё. Хочется посмотреть, в какой точке мы находимся, где мы были и какие перспективы вообще по скорости, по продуктивности. Дальше поговорим про спектривен и обсудим,
Speaker A
почему это не всё так радужно. Новые методологии, парадигмы появлялись всегда, но они умирали и никогда не показывали тот самый десятикратный, стократный прирост, которого все ожидают.
Speaker A
Итак, реальный эффект от AI. Посмотрим немножко про фрустрации разработчиков при работе с AI и поизмеряем скорость и ценность.
Speaker A
Так, кто-нибудь видел этот слайдик? Это Stack Overflow, конец прошлого года, их последнее исследование. Очень классный вопрос: что заставляет разработчика фрустрировать чаще всего при взаимодействии с агентом?
Speaker A
Итак, самый-самый самый топ ответ — решения AI почти верные, но не совсем. Кто-нибудь сталкивался с таким?
Speaker A
[смех] Да, я думаю, все. Я буквально даже, когда готовился к этой презентации, фрустрировал бесконечно много, фрустрировал. И вот, на самом деле, много сил направлено. Я думаю, все знаете вы и про контекст инжениринг, который про который говорили вместо
Speaker A
вайп-кодинга, и сейчас очень модное слово харнес. Всё-всё-всё, что мы делаем C, на мой взгляд, и вот в моём кластере, оно направлено на то, чтобы как раз эту фрустрацию уменьшать, потому что есть ощущение кучи потраченного времени даже с новыми моделями, кучу взаимодействия.
Speaker A
И вот скдривен на самом деле тоже один из способов, как это сделать. Давайте дальше посмотрим ещё немножко цифр про то, про какие-то такие мысленные искажения. А есть такая организация, назову её по-русски метр.
Speaker A
Наверное, она называется иначе, европейская. Она проводит много исследований на территории Евросоюза, ну, и вообще в мире, на самом деле, связаны с AI. О чём говорит нам на самом деле этот график с распределениями?
Speaker A
Здесь, э, несколько типов исследований: реальные исследования с выборкой, опросы и квазиэксперименты, где они пытаются более-менее совместить. И если даже посмотреть на эти исследования, то начиная с двадцать второго года, когда они стартовали, очень большой разброс. И на самом деле самые высокие показатели
Speaker A
по продуктивности показывают именно опросы. Если мы смотрим на квазиэксперименты и на реальные полевые испытания, то они около единицы и чуть выше. Из всех исследований, которые проводятся. На самом деле сейчас, ну вот то, что есть у метра, есть только одно
Speaker A
исследование, где провели полевой эксперимент и опрос. И полевой эксперимент показал вообще, а, отрицательную продуктивность, хотя опросы показывают положительные. Правда, правда, чуть позже с выходом моделей опуса, новых опусов, э, Cloud MIFOS, Fable, Рос пошёл. И всё-таки даже уже уже начинают и полевые эксперименты
Speaker A
показывать, что всё-таки мы выходим по продуктивности в реальный плюс. Но посмотрите разрыв просто гигантский.
Speaker A
Это к тому, что не надо себя обманывать. Вот. А интересное смещение. Интересное смещение. А до недавнего времени, о чём этот график? Этот график он такой ретроспективное в будущее. В марте люди говорили, что их продуктивность от использования агента в среднем,
Speaker A
смотрим по линии, где-то полтора. Сейчас люди отвечают от одного иче до двух. Почему разные цифры? Потому что разные вопросы. И они немножко сместились. Если раньше спрашивали прямо про скорость, сейчас задают довольно интересные вопросы. Если вашего, если ваша команда
Speaker A
придётся заменить вас человеком, который обладает теми же самыми навыками, но без работы, ээ, а сколько придётся человек нанять для выполнения той же самой работы, которую вы делаете CI, с теми же скилами, но без доступа к и инструментам. И вот люди говорят, что
Speaker A
нужно двух человек будет нанять, если забрать я и с такими же навыками. Другой вопрос про другое, но в среднем 1,42 показывает и уже измеряется не скорость, а именно польза.
Speaker A
Этот график — это продолжение. Тут как раз показывают, что это сейчас будет интересный момент. Этот график как раз показывает, что когда пытаются измерить скорость, тут прямо 3x, 4x, но когда пытаются измерить ценность, то она падает до 1,4.
Speaker A
Как думаете, почему рос пользой скорости не одно и то же? Давай просто сместился. Если раньше разработка занимала время, сейчас занимает время ревью, соответственно, выпусска про она не смещается. Мы не можем заменить полностью агентами.
Speaker A
Соответственно, ревью и дальше флоу он, в принципе, сейчас не заменился. Это один из моментов. Ну, кстати, кто ещё есть, кто-то ещё желающий пофантазировать, почему польза и скорость не одно и то же? Давай.
Speaker A
Ну, на самом деле, тут ещё какой вариант. Вот мы можем получить много кода, должен кто-то отревью. И вопрос в том, что, ну, это скорее относилось к вопросу, который я бы хотел задать потом.
Speaker A
Да, просто у нас получается большое количество кода, получается его достаточно много, но его кто-то должен отревьювать, и мы будем честны, как бы иногда это делается не на 100%, ну, как бы все люди, внимание и так далее, да.
Speaker A
Вот и это может получиться как большой отложенный, отложенная накопленная ошибка. И вроде всё работает, работает, но чуть-чуть деградирует по цифрам. Можете, да, простите, настать на вот, ну, то есть мы всё откладываем, откладываем какой-то получается большой тепдог, и в какой-то момент с этим
Speaker A
придётся что-то делать. А там может быть уже такая или другая шесть, но может получиться.
Speaker A
Ну, это часть правды. На самом деле, есть ещё один момент. Не знаю, ээ, надеюсь, вы сейчас узнаете себя либо своих инженеров в этой истории. Э, AI стал помогать делать задачи, которые инженер раньше не мог делать. Например, э, нужно было собрать в Редаше какой-то
Speaker A
аналитический дашборд. Там есть в Редаше, например, история, где ты на джаваскрипте можешь дашборд написать кодом, и вряд ли какой-то инженер этим навыком обладал, потому что это не его рутинная работа. Но сейчас он такой: "А что не сделать?" На, навайп-кодил
Speaker A
быстро, сделал в скорости. Если бы он без этих знаний, он бы пошёл читать документацию, разбирать, пробовать на Stack Overflow искать примеры, причины и потратил бы на это неделю. С использованием агента он сделал это за 10 минут. Скорость выросла. Выросла. А
Speaker A
польза для продукта какая-то есть? Ноль. Вот на самом деле вот такие моменты, их надо в работе с AI отслеживать, потому что инженеры могут уйти в такую лёгкую прокрастинацию, где нелёгкий дофамин за счёт задач, не связанных с ценностью продукта, делают. Они ощущают себя
Speaker A
суперпродуктивными. Во всех опросах говорят, что вау, мы там 5x прирост, столько вещей успел сделать. На самом деле, если посмотреть на продукт, он там не сделал ничего. А ничего он не сделал, потому что инженер, цель инженера не код вообще-то писать. Нужно со
Speaker A
стейкхолдером пойти, поговорить с продуктом, что-то почелленджить, что-то подумать, покопать и так далее, и так далее, и так далее. И на самом деле, э-э, инструменты AI, инструменты вот в этом месте, они не сильно помогают, они помогают вот вокруг. Есть одно из
Speaker A
исследований, возможно, это кстати оно же, там ссылка останется, что AI помогает делать те вещи быстро, на которые раньше времени не хватало, погружаться, разбираться и делать. Вот поэтому сейчас такой тренд в исследованиях везде, я думаю, вы скоро заметите, что начинают мерить
Speaker A
продуктивность, а не скорость. Скоро сейчас вообще ни о чём не говорит, только об СДВГ скорее. Так, [смех] на самом деле. Так, давайте теперь всё, это была затравка. Затравка о том, что есть искажение, есть ощущение, что мы делаем много и быстро, но мало полезного, что
Speaker A
показывае
Speaker A
Так. Давайте ещё маленький вопросик. Давайте здесь попробуем малень помаленьку отвечать. Мы в конце ещё поговорим. Как вот представьте, у вас есть техническая команда, вот вы собрались, ээ, только собрались. Как вот как можно повысить качество написания кода в такой команде? Предположим, даже
Speaker A
Иая нету. Вот просто собралась команда человек, как повысить качество кода написания? Нтер, супер. Ещё что? Стандартизация, да? То есть мы внедряем какие-то подходы договариваемся парадигму языки, стандартизация. проверки, линтеры. Мы так таким образом создаём некоторый фрейм, который помогает нам единообразно
Speaker A
писать. Я тут оставил слово vipкодинг, но давайте подумаем, а как повысить качество вайп-кодинга? Та же те же 10 человек тоже встретились.
Speaker A
Один пишетзации. Ага. Ещё что? Не использовать. Не использовать. [смех] Хорошо. На самом деле ответ такой же. Тоже какие-то стандарты внедрять. То есть агент, он на самом деле его также надо фреймить, также его надо проверять, также надо в виде скилов или чего-то ещё добавлять
Speaker A
ему, э, ограничивать его действия, ограничивать его информацию и контекст. Смотрите, я и здесь я хочу переключиться в методологии. Методология - это немножко сложнее, чем мы сейчас обсуждили договорённости на уровне команды, потому что методология, в отличие от парадигмы - это то, как
Speaker A
организация подходит там к процессу создания там какой-то ценности с использованием кода. То есть она обычно затрагивает там и Discovery, и проектный офис, и написание кода, и дальнейшие части. И вот я в своей организации в технической, мы уже дошли до того, что
Speaker A
просто агента фреймить уже как бы это неинтересно, скилы написаны, код пишется одинаково. Мы пошли дальше. Мы пошли дальше. Как можно использовать, как можно более стандартизировать написание кода с помощью агентов, чтобы охватывало весь процесс от Discovery до Delivery.
Speaker A
Потому что что было до этого, когда нет методологии? Там, не знаю, Prodct написал какую-то какое-то исследование, бизнес-аналитик собрал требования, что-то в чатике какую-то идею закинули, может быть, в джира, может конфлюенси.
Speaker A
Человек прочитал, пошёл с агентом о чём-то поговорил, половина артефактов генерации потерялась, написал код, передал другому человеку, он это смотрит, не знает, как это было сгенерено, используют те же агенты, но что-то уже не сходится между изначальными требованиями и тем, что
Speaker A
написано в коде. Оно осталось в чате у в чате у разработчика. И вот, ну, короче, теряется много чего теряется. С методологией у нас появляется такой цельный workкflow, задача, контец, контец [смех] контекст, спецификация, план. Мы ревьюем план, прогоняем тесты, всё работает, код
Speaker A
работает. Дальше, если нужно, правим спецификацию и опять по кругу. То есть уже ничего не теряется, остаётся в проекте, остаётся в виде артефактов.
Speaker A
Так вот, что такое SDD? Это методология, в которой спецификация является основным источником правды. И на самом деле мы немножко смещаем, э, работу инженеров и лидеров там продуктовых в сторону работы со спецификацией.
Speaker A
И весь процесс дальнейшей разработки, выкадки, он идёт от неё. Мы не меняем код, мы меняем спецификацию.
Speaker A
Спецификация перегенерирует код. Так, [вздыхает][тяжело вздыхает] а это можно пропустить. [смех] Потому что я всё, в принципе, рассказал на предыдущем слайде. Здесь я просто хотел подчеркнуть, что мы на самом деле идём таким интересным эволюционным языком. Эта пирамида про Natural
Speaker A
Language не совсем может быть о том, но мы начинали с бинарного машинного кода, дошли до первых уровней абстракций в виде ассемблера, появились у нас языки общие Java, C, Паскаль. Потом мы пришли к языкам, ну, я мне их нравится больше
Speaker A
назвать функциональным, типа, э-э, не не функциональным, короче, как как декларативным. Всё, спасибо, что подсказали, да, и сейчас мы выходим в реальное, на самом деле, программирование с помощью натурального языка. Там изначально пирамида про другой натуральный язык говори, но неважно. Суть в том, что мы на самом
Speaker A
деле все команды передаём агентам. Агенты что-то пишут. Ну вот честно, э, есть сейчас люди, которые, например, больше половины времени руками пишут код. Вот кто-нибудь руку поднимет. Вот 50% времени руками пишет код. 40.
Speaker A
Так. Так. 30. Вот. Вот. Но я к тому, что на самом деле мы уже потихоньку вот туда подходим. Я уверен, что у нас появится какая-то ещё спиранта раз, ну, такая разговорная с э агентами. Она и вот оно станет этим
Speaker A
языком. Так. С приходом спектрин девелопмента, там где я, там, где мои команды это применяют, становится очевидно, что архитектура больше, так сказать, не помощник, не она становится исполняемой. То есть, что мы на архитектуре, что мы в спецификации отразили, именно то агенты сгенерировали
Speaker A
в рамках этой спецификации. Выглядит это примерно следующим уровнем, о, следующим видом. У нас есть уровень спецификации, уровень генерации, уровень артефактов и runнтай. И каждый из этих уровней, на самом деле, он валидируется. То есть написали спецификацию, провалидировали.
Speaker A
Можно автоматически, можно через кодрев, сгенерировали код, провалидировали тесты, вся наша любимая пирамида и так далее. Получили конечные артефакты, тоже посмотрели. В рантайме тоже посмотрели.
Speaker A
Если всё ок, всё, цикл закрылся, пишем новую спецификацию, прогоняем заново по не по нему.
Speaker A
А раньше, а как раньше было? Раньше у нас были требования, мы писали какую-то архитектуру, на архитектуре строили дизайн. В дизайне уже архитектура, может быть, местами где-то и терялась. И вот я думаю, многие кто-нибудь пишет одирки, диарки в своих компаниях. Ну, я буду
Speaker A
прав, если скажу, что они становятся неактуальные буквально после того, как функционал зарелизен. Да. Вот. И архитектура не переписывалась. У нас этот артефакт, который показывает некую фантазию прошлого, как это должно было быть в нашей голове. На самом деле в
Speaker A
коде и в рантайме у нас вообще другая история. Спецификация здесь нам помогает, потому что вся генерация через неё. То есть у нас никогда нет протукшего артефакта. Мы спецификацию правим перегенерируем правим перегенерируем. У нас всегда есть актуальный артефакт и актуальное
Speaker A
состояние в рантайме. Это один из самых больших плюсов. Давайте здесь остановимся. Если всё понятно, я пойду дальше. В принципе, так. Ну, о'кей.
Speaker A
Смотрите, это базовый такой лей-аут SDD. Сейчас очень много разных фреймворков. Нету какого-то единого языка, который бы говорил: "Делайте так, и всё будет хорошо". Поэтому, на самом деле, я думаю, что я думаю, что вот даже сейчас задам вопрос. Вы в своих
Speaker A
проектах, которые пишете C, есть ли у вас что-то типа Меory банка? Кто-нибудь использует? Да, вижу, вижу, вижу.
Speaker A
И скорее всего вы, наверное, перед тем, как писать код, какие-то планы составляете, боже, может быть, более мощным агентом и потом может быть более немощным исполняете. Это на самом деле уже почти SD. Ну, зародыш SD он так и выглядит. У нас есть ADН ENTMD, где
Speaker A
лежат основные [вздыхает] а договорённости по работе с агентом и фреймы его. У нас есть какой-то ProjectMD, есть какой-то архитек MGD. Project - это скорее такое продуктово-проектное описание, архитектура построена на основе него. Ну и всё. И у нас есть спеки. Спеки - это в
Speaker A
зависимости от user story, от эпика, как у вас принято, вы их раскладываете и там на фичи дальше. Всё. И агент просто вот работает в этом контексте, постоянно их обновляет и так далее.
Speaker A
А я сегодня покажу два примера работы со с со спецификациями. Амазоновский Кира. И на нём я постараюсь вам показать быстро демо, потому что он очень наглядный. И если кто-то не сталкивался, я думаю, вы быстро уловите суть.
Speaker A
У него есть свой меory банк, он называется РНГ. В принципе, ничем от того, что я показал, до этого не отличается. И он также генерирует фичи, спеки. У него внутри построены флоу.
Speaker A
Очень удобная штука. Всем поле, ну, советую просто вот для ознакомления попробовать. Там есть бесплатные 500 кредитов у Амазона.
Speaker A
Вы не успеете их потратить, вас скорее быстрее забанят. Так и скиIT. Спикит вот мы прямо используем в кластере. Не могу всем посоветовать. Мы сейчас ээ в таком в пилотном режиме из-за того, что такая история трендовая, но пока не
Speaker A
отработанная, кажется, что надо попробовать разные фреймворки. И в конце вам покажу метрики, насколько эффективно удалось их в кластере применить. Он точно также работает. Есть память, есть у него свои, э, особые скилы, темплейты, которыми он идёт по флоу. Работаем с ним
Speaker A
внутри терминала. О, демы. Так, а сколько у меня времени осталось? И ещё успеем. У меня ещё есть. Сколько времени у меня?
Speaker A
Так, ну всё, я тогда попытаюсь быстро демо показать. К сожалению, придётся уйти. Сейчас я вам покажу. Кира, да? Да. Вот смотрите, это Кира, как я и говорил. Видите, я тут утром хотел прогнатьм с ним, показал, что всё, я на
Speaker A
выступлении. Выведи на всякий случай список команд нужных. И мне пришло сообщение, что меня забанили, поэтому поэтому не успел. Но я всё предусмотрел. Мы не будем прямо сейчас генерировать с этом код и всё остальное, потому что я сделал 10 комитов, и мы просто по ним
Speaker A
пройдёмся, я покажу, как [фыркает] как меняется состояние файлов. Мне кажется, так будет нагляднее и быстрее.
Speaker A
Итак, смотрите, важный момент. Я говорил, что методология она, э, не просто про процесс разработки, она затрагивает и discoverovery, и Delivery.
Speaker A
У нас сейчас в Авито очень сильно развит внутренний MCPHub, который позволяет нам получить доступ к различным частям. Но меня сейчас в данный момент интересует Confluence. И, например, наш, э, Discoverovery, он готовит для нас BD.
Speaker A
Это пирдишки, на самом деле. Тут есть описание сервиса. Калькулятор компенсации за работу в выходные.
Speaker A
Насущная история. Вот я сегодня в выходные с вами тут разговариваю и, ну, плюс это близко ко мне часть Чартеховская, поэтому я решил демо собрать на ней. И видите, для спецификации на самом деле инпутом уже является некоторая продуктовая документация. Если мы посмотрим её в
Speaker A
превью-режиме, у нас тут будет сейчас куча красоты. У нас здесь есть информа так, тактак. Проблема, для чего мы его разрабатываем. Uюерсту. как сотрудник, отработавший выходной или праздничный день, я хочу вести даты работы и сразу видеть прозрачный расчёт своей надбавки, функциональные
Speaker A
требования, бизнес-логика и так далее, и так далее. Всё. Делаем вид, что мы скормили скормили э агенту, и он сделал нам первый шаг. Поче видите, почему мне нравится Кира? У него прямо сверху, если вы посмотрите, есть прямо flow, а requirements, design и task. И сейчас
Speaker A
мы по этому флоу как вас как раз с вами и пройдём. Всё, он сделал требования, он посмотрел на входной документ Discovery продуктовый. А мы можем в превью режиме посмотреть глосарий, чтобы мы выровнялись на и разговаривали на одном бизнес-языке. Требования один,
Speaker A
требования два, требования три, требования четыре. Это, естественно, надо глазами проверять вместе с продуктовыми лидерами, там, с бизнес-аналитиками, потому что всё равно агент может нагерить ерунды. Пойдёмте дальше к следующему комиту.
Speaker A
Всё, бах, у нас появился дизайн. Дизайн - это более технический документ. То есть, видите, на следующем этапе он уже сгенерил нам прямо техническую постановку. Кто наш клиент, какой у нас хендлер, что он будет обрабатывать, какие запросы, калькулятор внутри
Speaker A
ресурсы, всё-всё, что нужно. Здесь у нас есть прямо уже и на э структуры нужные функции, которые будут, э, правила валидации. Всё-всё-всё. Дальше мы просим его сгенерировать таски. Идём дальше.
Speaker A
Хоп. И у нас появились с вами задачи. Taskлиist. Видите, чем мне нравится Кира, он прямо круто мапит аэ отдельные части дизайна. Ну, в смысле, в дизайне и в реквайрменсах прямо на задаче. Их можно выполнять параллельно или последовательно. То есть, видите, первая
Speaker A
задача, структура проекта, доменные типы. Можно её запустить, и он её выполнит под капотом. Только её можно почитать. Остальные, если они вам кажутся лишние, не нужные, их прямо можно поудалять из этого документа или пойти перегенерировать предыдущие шаги, если вы поняли, что каких-то задач нету.
Speaker A
И по итогу, на самом деле, в следующем комите у нас хоп, и предположим, что был очень быстрый агент. Он все эти задачи выполнил. Всё. какую-то он не выполнил, но на самом деле это багара, и я проверял, выполнил. Мы даже можем теперь
Speaker A
проверить работоспособность нашего сервиса. Так, давайте попробуем, если не получится. Это не я. Makйк def. Что-то пошло. Ага, Рор. Супер. Ну, ну, давайте проверим, вдруг пошло.
Speaker A
Так, у меня тут ещё подсказка одна есть. Так как меня забанили, я воспользовался клодом.
Speaker A
[смех] Так, я что-то сбросил, да? Так, ну, поверьте мне, оно сработало. Короче, всё, оно работает. И А, ой, можем вернуться сейчас. 2 секунды.
Speaker A
Просто одной рукой держать микрофона, а другой печатать не очень удобно. Да не, не, сейчас. Так, демо, демо, демо демо демо.
Speaker A
Я просто забыл мей команды. Там вот make run. Ту-ту-ту-ту-ту-ту. А вон йк-тест есть. О'кей.
Speaker A
[вздыхает][тяжело вздыхает] Ну, сейчас проверим. Так. Кe. Не, а, ну ладно, поверьте мне, всё должно было работать. На самом деле, э, основной мой посыл был показать вам, как как, э, какой флоу. Наглядно.
Speaker A
Вот. Остальные фреймворки так, к сожалению, не умеют. Если вы воспользуетесь Open спеком либо спеккитом, а есть какие-то плагины для ВС-кода, но не но оно не так наглядно.
Speaker A
Это прямо очень круто работает, очень удобно, очень наглядно, очень структурно. Всегда можно пойти посмотреть, где какая задача решалась и так далее. Вот. Э, но это не конец. Есть новое, мм, новое новое продолжение этого тренда. Оно пока в альфа-версии бывшие
Speaker A
разработчики ДТБА делают историю, называется CДS. Предлагаю вам записать, запомните, если интересно. Там ещё интереснее. Они хотят, они научились уже в своих альфа-версиях мапить вот конкретные таски прямо на части спецификации. И когда вы переписываете спецификацию, она регенерит код только
Speaker A
одной маленькой части. Это очень большое ускорение работы со спецификациями, потому что сейчас приходится перегенерировать всё. Вот я думаю, это будущее. И, скорее всего, мы в своих командах пойдём туда, потому что экономия время бесконечная. Так, а вот теперь маленькие цифры реально в
Speaker A
кластере. У нас, честно скажу, из-за того, что мы пока в пилоте, у нас прямо не очень такое, ну, [откашливается] скажем, большое количество данных, чтобы их точно считать подтверждёнными, но какую-то закономерность мы уже видим.
Speaker A
Что показывает этот график? Он реальный на реальных командах, которые есть в моём кластере. Это отношение по времени на решение задачи со со спецификацией в методологии SD и без неё. И пока разброс большой. Но на самом деле вот AVWOR Core, я вот её хочу показать.
Speaker A
Команды вот это команды, которые больше всего адоптят. И мы вот заметили, что реально в больших задачах восемь сторипоинтах это что-то типа на спринт, на часть спринта, на недельку, может быть, дней на на семь. Реально есть прирост в больших задачах. В маленьких
Speaker A
задачах, там 0,5 стории, один стопоит, вообще улетаем в бесконечность. То есть багу чинить таким способом точно не нужно. И это одна из проблем, это одно из наставлений. э, SDD не заменяет весь флоow разработки, им интересно и полезно решать большие задачи.
Speaker A
Вот такой охват. То есть вот AVWC corore, она пока у нас одобнет этот подход больше всего на свежих данных я смотрел вчера, было процентов 12, то есть 12% задач всех технических команда решает уже с помощью спеккита. И ну и
Speaker A
100% из этих двенадцати задач - это задачи там на восемь стори поинтов там в районе спринта двухнедель двухнедельного.
Speaker A
Вот эту команду наказывать буду. [смех] Так, ну не всё так радужно. Я уже начал про это говорить, что не всё так радужно. А я тут некоторые цитатки из интернета про повыдёргивал, что вот человек на итеративном промтинге маленькую задачу решил за 8 минут и
Speaker A
примерно 1.000 строк кода, ну, кода там, каких-нибудь комментариев и спеккит. 2600.000 строк маркдауна плюс 700 строк кода и 33 минуты. Точно. Не буду здесь никого обманывать. Маленькие задачи не надо решать с помощью SD. Это больно.
Speaker A
Возможно, когда выйдет код код спик, который кусочки регенерирует, будет супер. Пока точно нет. Так, э-э, немножко как будто бы возвращаемся в тефол, когда работаем со спек дривеном. Всё так очень последовательно. Нам надо прямо точно дождаться требований от бизнеса,
Speaker A
проанализированы, чтобы они были продук продуктом. Пришли к нам и посмотрели, может быть, вернули. Такая петля немножко замедленная. Но если на поток поставлено в Авито довольно сильные продуктовые специалисты, то это не замеча незаметно. Ну и при том, что процент задач он там в районе 15-20 не
Speaker A
афектит только большие задачи. Там, возможно, это и полезно, но проблема такая есть реально. Петля не такая.
Speaker A
Третья проблема большая, нету единого подхода. Вот сколько вы найдёте спек фреймворков на гитхабе или где, все по-своему делают. Все по-своему. Все по-своему решают костыли.
Speaker A
Вот Кира, например, болеет тем, что он генерирует кучу задач. Вот я вам показывал, там было столько, хотя требование там было одно: посчитать, сколько денег заплатить выход выходной.
Speaker A
Какие-то другие могут у некоторых спикета, которые я показывал, у него слишком много шагов, четыре или пять или шесть шагов в пайплайне, а у Кира три всего. Единого подхода нет никакого.
Speaker A
Надо ждать и либо на риск пользоваться. Так, это всё пропустим. С чего начать? Смотрите, я всем предлагаю попробовать, потому что это реально как минимум расширяет ваш инженерный контекст и показывает, куда тренды уходят по работе. И вот если есть интерес
Speaker A
попробовать, пробовать надо точно, не на маленькой задаче. Заведите одну задачу, которая будет решаться именно с SD.
Speaker A
Пусть она будет среднего размера. Идеально, если она будет включать в себя и backк, и фронт. То есть вот SDD один из больших приростов показал нам в местах тишейпинга, мультистека. То есть задачи, которые требуют части на фронте и на беке, тоже попадает вот на том
Speaker A
графике в очень эффективную часть, потому что общий контекст, общие кусочки быстро решаются, и не надо привлекать стыковать двух инженеров. Поизмеряйте метрики, посмотрите на одна из важных метрик посмотрите насколько качественный код. Если он некачественный, допишите скил, чтобы внутри этого подхода код проверялся по
Speaker A
каким-то вашим внутренним правилам. Ну и всё, проверяйте, дополняйте спеку. Главное, главное, соблюдайте это правило, что если не сгенериролось с первого раза то, что вы хотели, нужно править спеку, не нужно править конечный код. Если вы так сделаете, всё, можно
Speaker A
сказать, сломалось. Это, кстати, одна из проблем, которую нужно, ну, привить, приявить инженерам подход правиц пеки.
Speaker A
Так, ну всё, вот QR-кодчик для того, чтобы нам пообсуждать что-нибуд в калуарах. Так, ну время на вопросы осталось да?
Speaker A
Да, у нас есть минут 10 на вопросы, и их очень много. Блин, даже не знаю, с кого начать. У тебя есть предпочтение?
Speaker A
Ну вот зад микрофон. Спасибо за доклад. Я хотел спросить, а что из себя представляет Emory BН?
Speaker A
Потому что спецификацию нужно шарить между членами команды. Потом есть несколько спецификаций, у которых есть, например, у одной один артефакт, у другой другой артефакт. Один может быть противоречи второму. И как это всё резолвится?
Speaker A
Вот хороший вопрос, кстати, реально. А на примере спикета расскажу, с которым мы много работаем. В спикете там есть команда, ну, грубо говоря, Инит, э, или New Speciification, не помню, как она правильно называется. И он создаёт, грубо говоря, в структуре, в лайауте
Speaker A
отдельную папочку, в которой пишет название спецификации. Эта папка нелокальная, то есть она в гитходит. Она в гитходит. И Спики, например, сам как фреймворк, он автоматом создаёт от текущей мастер ветки ветку с этой спецификацией. То есть мы в ней
Speaker A
работаем, сохраняем все артефакты, сохраняем код, а мёрджим всё в общие ветки, в какие-то релизные, ну, смотря какой у вас флоу используется. И для всей команды становится доступна эта спецификация со всеми её артефактами, изменением кода. И когда человек будет
Speaker A
от уже дальнейшего кусочка э создавать ветку, там у специфи в разных феремоворках по-разному, но у спиккета такое есть. Есть шаг, когда он проверяет как раз-таки, как сказать, на не на отсутствие противоречий, и он прямо там смотрит, то есть вот что было сделано,
Speaker A
что было сделано и так далее. как, но на самом деле, так как новая спецификация почти всегда от свежего кода делается, таких проблем, ну, редко возникает. Вот.
Speaker A
То есть она всегда от свежего кусочка кода либо от того общего. Ну, а м эthше.
Speaker A
То есть инженеры садятся и смотрят, что они сделали. Да. Да. Ну вот смотри, я показывал пример на демо с конфлюенсом. Например, у нас, э, пидишки хранятся в конфлюенсе, и через MCP прямо в сессии с агентом мы оттуда забираем это как первый шаг в
Speaker A
среду разработки. Да, да. Ну, мы на самом деле потихоньку хотим вообще всё в среду с разработки привести, но продуктовые специалисты всё-таки немножко дальше от разработки и, ну, не сложно через MCP забирать из конфлюенса. Им легче там править, легче
Speaker A
онлайнком комментарии отвечать и так далее. Ага. Так, кто ещё? Вот. Да, спасибо. Было очень интересно. У меня вопрос и просьба.
Speaker A
Ага. Вопрос. Собственно, я хотел бы уцепиться [откашливается] по поводу, сколько мы кода пишем руками.
Speaker A
Вот мне доводится часто в некоторых задачах ядро самой задачи писать, ну, там больше 50%. Почему? Вот с коллегами в процессе обсуждения часто получается так, что, ну, видимо, в силу каких-то человеческих, может, наших особенностей, когда ты пишешь, вот ты сделал
Speaker A
архитектуру, ты по ней начинаешь писать код. Если ты пишешь код сам, то у тебя возникают какие-то мысли, ответвления в стороны, которые не возникают, чем если ты это скармливаешь просто в ЛМ, с рагами, все дела. Вот хотелось бы понять, в этой структуре есть какая-то,
Speaker A
ну, не знаю, путь какой-то предзаданный для вот этих вот каких-то творческих моментов в самой системе ЛМА? Вот или по сути ведь, если я правильно понял, он будет действовать строго по спекам, да?
Speaker A
То есть вот мы их указали и вот тут тоже вроде как: недожмёшь его, он начнёт творить безобразие. Перезажмёшь, всё. То есть ты не не придёшь в эту точку, когда у тебя возникнет мысль, когда ты пишешь сам. Но это то же самое, как часто
Speaker A
читаешь с бумаги, наверное. и запоминается лучше, чем с текста, чем с экрана. Ну, может, это у меня так вот это, собственно говоря, вопрос, как вот ваш подход может с этим подружиться. И просьба, сделайте как-нибудь стикер Контец.
Speaker A
Контец. Хорошо, спасибо. [смех] Авито, Контец. Смотрите, я отвечу так. В моей жизни, я буду от себя говорить, потому что сложный вопрос такой околофилософский. Я в моей жизни в часть с проектированиям изменилась. Не знаю, у кого-то и было такое. У меня всегда
Speaker A
лежало кипа использованных бумаг бумажек белых ручкой. И ты сначала на бумажке долго-долго что-то рисуешь, рисуешь, думаешь несколько раз, да, потом кодишь, оно не сходится, на бумажке ещё порисовал, закодил. Вот в работе с агентом у меня не особо что изменилось.
Speaker A
Я продолжаю на бумажке что-то придумывать, может быть, с ним оббиваю мысли и потом вожу. Я, наверное, понимаю, про какую часть говоришь ты в том части, что когда ты пишешь код, как-то код обратной петлёй на твоё мышление влияет. Да, к сожалению, этого
Speaker A
нет. Теперь, ну, отталкиваешься от текста, который написан. В общем, как-то так. То есть реально способ нашего мышления и отбивки идей при взаимодействии с агентом и бывший, когда мы смотрели по долгу функцию и думали, что в ней поменять, чтобы стало как
Speaker A
надо, оно изменилось. Ну я эти перемены чувствую, да. Стало по-другому. Ага. Так, давайте кого-нибуд из дальних рядов. Вот вижу мужчина. Да-дада.
Speaker A
Здравствуйте. Интересный доклад. А-а, я услышал, что вы лидер кластера и хотел задать такой вопрос: а как изменится роли в кроссфункциональной команде? Вот с этим подходом я вижу, что у нас сейчас роли-то поменяются, да? То есть аналитик у нас перестанет аналитить, например,
Speaker A
да? Тестировщик перестанет тестировать, ну и вот вот это вот всё. Ой, такой сложный вопрос. Даже не знаю, сейчас наговорю.
Speaker A
[смех] Смотрите, что я думаю. Что я думаю? Я думаю, происходит такой мрч, мёрч ролей.
Speaker A
Вот я показывал пример с мультитеком. У нас сейчас, не знаю, 80% бэкэндеров спокойно пишут кусочки кусочки фронта, которые изначально вообще говорили: "О, фулстек - это что-то такое, никогда в это не пойду". А сейчас бах и вот пишут и нормально. Ну, обратная сторона с
Speaker A
фронтендер. По фронтендерам почему-то немножко сложнее писать БК, но вот они тоже пытаются. А про аналитиков [вздыхает][тяжело вздыхает] не знаю, мне кажется, просто ролей, может быть, станет чуть меньше. То есть вот у нас сейчас есть отдельно там продуктовые аналити продуктовые
Speaker A
руководители аналитики может какой-то здесь мёрч произойдёт. Исчезновения роли не будет, потому что, ну, вот я как человек, у меня в голову помещается определённое количество информации, знаний и инструментов, которыми я могу пользоваться. И даже когда я делегирую это всё агенту, нужен
Speaker A
кто-то, кто будет его контролировать. И я не могу сейчас сам взять весь инструментарий продуктовый, аналитический системно-аналитический всех стеков и всего остального. Просто моей головы не хватит, чтобы быть уверенным, что агент делает что правильно. Да, мы немножко занимаем другую нишу. какие-то роли, которые
Speaker A
близкие по смыслу будут объединяться. Но вот это базовая, я считаю, что вот это базовое фундаментальное знание, которое дают в университетах в наших, ну, и которые разработчик там в ходе своей жизни получает, читает книжки, оно становится только валиднее, только
Speaker A
нужнее. То есть сейчас не так важно знать синтаксис там, условной скалы, Java и чего-нибудь ещё, но знать, как работает процессор, как работает память, это всё нужно, нужно видеть это в коде, как это, как это выглядит и так далее.
Speaker A
Вот я думаю, так будет. Не знаю, надеюсь, ответил на вопрос. Угу. Давайте очень кто хочет всё интересные цифры были. Я там помню, они говорил, что что-то внедрили на 300 млн, никто не пользуется, внедряем на 3 млрд.
Speaker A
Как вы мерили ваши цифры? Типа вот пример про количество задач, формированных, сделанных с помощью спеккита. Вряд ли же вы транскрипты КД-кода у каждого разработчика читали по задаче. написали скилл, который для расширили возможности спеккита новым скилом, чтобы он ставил тег в джире
Speaker A
Sdased. Всё. Ну то есть понял, спасибо. Мы сейчас хотим ещё и померить, а сделать теги там условно AI impact, low AI impact и посмотреть на самом деле вот какое-то распределение. Ну я я по своему кластеру просто так через общение, через
Speaker A
скиплевелы и так далее понимаю, что 90% человек всё пишут уже в агентах, то есть никто уже руками почти не пишет код.
Speaker A
ответил. Ага. Ну давайте вон мужчины. Давайте мужчина в очках. А сейчас принесут вам. Угу.
Speaker A
Ээ ну я регулярно вот пишу успехи сейчас. Пользуюсь банком и страдаю от такой проблемы.
Speaker A
Первое - это загрязнение контекста от нагенериённых планов, которые не были корректными. И при итеративной подходе разработки, то через каких-то 10 фич э агент может ээ, скажем так, скорректировать то, что написано в меory ээ о проексе.
Speaker A
Угу. И, соответственно, потом опять же происходит загрязнение контекста, и из-за этого решают некорректно. Если какие-то подходы, которые ты знаешь, можно поправить, ээ всякие вот тулы, которые показывал, они не помогают.
Speaker A
А я правильно тебя слышу, у тебя какой-то самописный фреймворк, грубо говоря? Сейчас лучше всего работает просто обычный клоуди с правилами написанными, чтобы он делил на таски. Примерно то же самое, что делает Кира, только в, ну, в описании кода пишешь, и он справляется.
Speaker A
Ну, моё мнение тут простое, как бы базовая базовая рекомендация с незагрязнением контекст - это периодически делать клир. Но это просто понятно, очень простой совет. Но вот почему я и предлагаю пользоваться готовыми фреймворками, потому что люди как раз внутри вот ээ когда создают
Speaker A
продукт этот фреймворк, они как раз вот решают вот такие проблемы. как, например, организовать таки таким образом флоу, чтобы все части были полезны и, например, э создавали непротиворечивые спецификации, дизайн, задачи и в итоге код. Как сделать флоу таким, чтобы можно было на каком-то
Speaker A
этапе что-то переделать и перегенерировать полностью, чтобы не загрязнить контекст сложнее. Как построить структуру лойаута так, чтобы каждая спека была отдельным каким-то там условным кейсом, который не пересе остальными, ой, сорри, и не загрязняет.
Speaker A
То есть надо пользоваться разными инструментами, которые специально структурируют и в рамках этого флоу пробовать. Я бы посоветовал пробовать разными вещами. Вот Speit, Open SPC, super Power. Вот из того, что ты рассказал, как будто Super Power можно попробовать и искать своё, потому что,
Speaker A
ну, самому писать неэффективно, я считаю. Ну, я вот пользуюсь, пользовался вот всеми этими инструментами, пробовал, и они не решают эту проблему никак.
Speaker A
Ну, сложно мне проверить. Можем вместе посидеть посмотреть. Можно. О'кей. Вот. А можно? Да. Извини.
Speaker A
Ну давайте. У нас Да, я извини, у нас потихоньку время заканчивается, поэтому давай ещё два вопроса. А все остальные вопросы, если что, можно в кулуарах уже после доклада у нас будет перерыв, можно будет помочь Сашу.
Speaker A
Йоу. А в общем, да, кайфовый доклад. Хотел ещё спросить. Ну, в целом, ну, вот, у меня лично темперамент такой, что мне очень сложно писать, вот сидеть и писать спеку вот так вот, типа сидишь, пишешь её. Ну, довольно такое нудное занятие.
Speaker A
А, но опять же от себя отталкиваюсь. Вот, может быть, есть какие-то идеи, как можно выйти на следующий некий метауровень, как с помощью агента, собственно, генеять вот эту спеку, вот, и чтобы он в диалоговом режиме как-то опрашивая вот эти, ну, ключевую как бы
Speaker A
структуру заполнил. и дальше уже эту спекуть типа условно руками. Так, ну, во-первых, вот хочется спросить, э, во сколько раз выросла твоя скорость разработки с выходом агентов?
Speaker A
Моя? Я не пишу код. А, не пишешь, да? Ну, ладно. Ну, я так чисто, ну, я тоже как бы на позиции инженеринг-менеджера. Ага.
Speaker A
Вот. И я опять же смотрю, что у меня у ребят происходит. Ну, и сам что-то так экспериментирую смотрю.
Speaker A
Ну, о'кей, отвечаю на твой вопрос. Смотри, э-э SD фреймворки умеют так делать. То есть есть фреймворки, которые как раз первый этап. Ты прямо с ним в дискуссии описываешь все шаги, он тебя переспрашивает допрашивает уточняет предлагает варианты, ты ему отвечаешь, и
Speaker A
он выдаёт результат. В спикете, по-моему, такого нету, потому что мы на вход готовый пирдишку берём, и у нас исследование есть. То есть продукт продукт бизнес-аналитик пошёл исследовал. То есть такое есть. А полностью удовлетворительный, ну, в твоём случае ответ будет тогда,
Speaker A
наверное, когда скорость инференца модели будет со скоростью мысли человека. То есть вот мы будем думать, и оно сразу будет инференса. Вот надо такого ждать. Тогда оно будет прямо супербыстро работать.
Speaker A
Угу. О'кей, спасибо. Угу. И последний вопрос. Давайте последний. Ну вот мужчина на вас рукой, да, показываю. Угу.
Speaker A
Да, спасибо за доклад. А вот вы пришли к выводу, что большие задачи имеет смысл делать по SДD, маленький нет. А как вы, ну, боретесь с тем, чтобы соблюдать консистентность спеки? Вот когда я делаю часть СД, а часть руками,
Speaker A
здесь нет такой большой проблемы, потому что нужна ли нам информация о всех подчиненных багах? Ну, наверное, нет.
Speaker A
Нужна ли нам информация о всех задачах в один стоит, где мы поменяли в HTML-разметки, что-то? Да, не особо. А большие фичи - это прямо такие обычною usер-стари большие, которые добавляют новое поведение, новый какой-то сценарий пользовательский там, э, разной степени
Speaker A
важности. И вот его бы неплохо зафиксировать. И вот это именно этот сценарий целиком возможно будет меняться. Тогда можно найти старую спеку либо написать новую, сослаться на старую, сказать: "Вот мы итеративно развиваем вот тот пользовательский путь, давай здесь". Поэтому я здесь проблемы
Speaker A
не вижу. То есть потерялся информация про бак, она нам такая тяжеловесная. Мы же этиры не пишем на все, на все изменения в коде, а только такие на важные, на новые интеграции. Вот то же самое.
Speaker A
Ну, имеется в виду, не воспроизведётся ли потом опять этот баг или вот эта фича, которую мы поправили где-то?
Speaker A
Пирамида тестирования. [смех] Спасибо. Спасибо большое, Саш, ваши аплодисменты. Ээ, не уходи. Во-первых, у нас есть QR-код, просьба отсканировать, оставить обратную связь. Второе, нужно выбрать вопрос, который получит подарок.
Speaker A
Так, вопрос. Аэ, сейчас я всё. Два вопроса, два вопроса можно выбрать, да? Усложним задачу.
Speaker A
Так, ну, мне понравился вот вопрос один точно. Ты спросил, как спеки укладываются внутри фреймворка. Такой мне нравится это практичный подход. То есть точно есть вовлечённость в то, как это реально работает внутри. Вот поэтому один вопрос сюда. А так так так.
Speaker A
Ну и на самом деле мне нравится, что покритиковали подход, сказали, что ничего не работает вот мужчине в очках, который которому не помогло.
Speaker A
Так.
Topics:спек дривен дизайнspec-driven developmentAI в разработкепродуктивность разработчиковтехнический долгавтоматизация кодаревью кодаАвитометодологии разработкиинструменты AI
