Скрам не нужен: как ИИ-кодинг меняет представление об эффективной команде — Глеб Кудрявцев

Коллеги, всем здравствуйте.

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

нашем эфире. Запись пошла, люди к нам

приходят. Рады вас видеть. Коля, рад

тоже тебя видеть. Вот передаю тебе эфир

для приветственного слова. Вот вступай.

>> Спасибо, Саш. Всем привет, ребят. Добро

пожаловать на AI Hardwork. Меня зовут

Коля Шейко. Мы вместе с Максимом

Романовским делаем и конференции под

именем Пиy Talk. Я сейчас скажу

небольшое вступительное слово, объясню,

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

чего от неё ждать, а потом передам слово

Саше, нашему партнёру Стартоплана. И

сегодня он будет главным ведущим. Вообще

эта конференция - это такой же

эксперимент, как и наши предыдущие.

Может быть, вы слышали про конференцию

AI of Life или итоги 25. И если честно,

у нас с Максом всё ещё нет какой-то

понятной бизнес-модели, поэтому просто

пробуем разное и смотрим, что

получается. В этот раз получилось

привести очень известных спикеров и

найти крутого партнёра в лице

Стратоплан. Ребята взяли на себя всю

техническую организацию эфира и все

сложности по продвижению конференции,

без чего у нас бы не получилось собрать

4.000 зрителей и привлечь под это дело

тех спикеров, которых мы привлекли.

Давайте сейчас парочку оркмоментов

важных. Вообще у нас много тем, и, если

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

доклады будут интересны каждому

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

часть будет скорее верхнеуровневые,

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

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

есть у части наших спикеров. Какие-то,

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

гайдами и разбором каких-то практических

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

этих кейсах случались.

Поэтому, так как в нашем закрытом канале

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

выбрать, какие доклады вы хотите

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

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

может быть, послушаете в записи.

Ещё в конце каждого доклада будет время

на вопросы. Я рекомендую писать их

сразу, как только они появляются. Но мы

не обещаем, что получится ответить на

все вопросы. Мы будем выбирать те,

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

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

А ещё я всегда говорю, что что-нибудь

обязательно пойдёт не так.

Но обычно на наших ивентах

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

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

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

не помешают. Ну а теперь я передаю

бразды ведущего Саше, соснователю школы

менеджмента Стратоплан, спикеру нашей

конференции и сегодняшнему ведущему. А я

к вам вернусь завтра как ведущий и

послезавтра как спикер.

>> Всё, всем хорошего вечера.

>> Пока-пока, Саш, начинай.

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

думаю, ещё неоднократно увидимся с тобой

и сегодня, вот и в конце нашего

сегодняшнего дня. Коллеги, всех радо

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

устроились, есть какие-то поддерживающие

вас напитки рядом. И первый у нас

официально по расписанию ещё несколько

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

вводную часть, прежде чем мы перейдём к

докладам. Поэтому я проговорю некоторые,

на мой взгляд, важные моменты, которые

помогут вам получить больше пользы от

конференции. Во-первых, чат у нас сейчас

отключен. Вот можно не пытаться туда

что-то сейчас написать. Мы первые минуты

его отключаем в рамках борьбы с

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

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

всех работает, и уже начнём общаться в

рамках наших докладов и с вами

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

про нас. Рапилк, стратаплан. Я тут

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

конспектируют всё, что написано на

экране. Вот. Но если в двух словах про

стратоплан, мы 16 лет занимаемся

обучением руководителей. У нас два

основателя. Мой коллега Слава Панкратов

и я. Мы сами с айтишным анамненом, то

есть работали на инженерных позициях,

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

директорских. последние 16 лет

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

работать с другими умными людьми. У нас

есть какое большое количество программ

вот для руководителей. Если интересно,

мы про них ещё расскажем многократно. У

нас есть специальное предложение для вас

как участников конференции. И в целом

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

обычно в преддверии запуска наших

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

этот ивент. Но для того, чтобы вы

захотели прийти учиться в Стратоплан,

нужно, чтобы от этих бесплатных ивентов

вы тоже получали пользу, верно? Поэтому

мы стараемся в рамках каких-то

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

конференций делать так, чтобы те, кто

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

заплатили своё участие в конференции или

не заплатили, чтобы это было вам

полезно. Поэтому вот вместе с коллегами

из Нтрапии Talkк, с Коле и с Максом, мы

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

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

рассказать так, чтобы это было для вас

ценно.

что я, как там человек, многократно

выступающий на конференциях и

организующие конференции здесь ещё хотел

бы сказать. Коллеги, постарайтесь

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

свою реальность. Что вы можете взять для

себя полезного? Какой вопрос задать

спикеру, чтобы унести что-то для себя? Я

бы вас призвал не соревноваться со

спикерами в экспертности или в чём-то

ещё. Если хотите быть спикером, вот,

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

и в Telegram написать, вот, потому что

мы постоянно заняты поиском новых

спикеров. Я сейчас свои контакты

оставлю. Вот. Если хотите, пишите,

приходите. Буду рад с вами обсудить

любые вещи, в том числе и ваши

выступления. Но постарайтесь всё-таки от

конференции вынести что-то полезное для

себя. И подумайте, какой вопрос вы

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

полезное прозвучало в эфире. И ещё один

важный момент, поскольку у нас больше

4.000 регистраций, у нас на эфире

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

всего, будет будут сотни человек. У нас

сейчас 800 человек онлайн. Думаю, что

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

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

всерьёз не рассчитывайте на то, что мы

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

всего, их заберём и вот как раз

обсуждаем с коллегами, куда дальше

отнесём. Возможно, передадим спикерам,

чтобы они в своих каналах на них

отвечали. Поэтому, если ваш вопрос

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

обижайтесь. Ну, чат будет, скорее всего,

жить своей жизнью. Вот. И там будут

какие-то свои обсуждения. Нам важно,

чтобы то, что мы пообещали в рамках

конференции, прозвучало. Надеюсь, здесь

мы с вами на одной волне.

И второй момент, давайте зададим правила

общения. Мы в Стратоплане всегда

выступаем за то, чтобы у нас общение

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

такая площадка здравомыслия. Поэтому у

нас в рамках конференции, в том числе,

строго запрещены три вещи. Это мат в

чате. Со стороны спикеров. Не знаю,

будет ли звучать. Мы с ними не

проговаривали. Вот посмотрим с вами.

Вот. Но в чате это точно запрещено.

Обсуждение политики в любом виде. И

третье - это неконструктив. То есть

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

отношении других участников чата,

спикеров, кого-то ещё. Вот это мы

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

коллеги. Кого-то будем банить. Вот

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

потому что чат будет жить своей жизнью.

Вот. Но наша задача сделать это

пространство, ну, достаточно

конструктивным, так, чтобы все в нём

чувствовали себя комфортно. Первый

спикер у нас Глеб Кудрявцев, наш

товарищ, партнёр. Глеб у нас уже

выступал. Глеб, рад, что ты нашёл

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

Передаю тебе слово,

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

AA и всё, что с этим связано.

>> Врывайся. Всем привет. Что я вам хочу

сегодня рассказать? Я вам хочу

рассказать про мой мой опыт AI-кодинга в

команде. а-а, какие у меня лично, э, ну,

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

камнями я столкнулся и, возможно,

сокращу вам какое-то время на

самостоятельном освоении всей этой

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

где-то на полчасика. останется

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

можете их готовить, можете писать в

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

потому что я уверен, что тема такая вот

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

потому что я кое-какие вещи скажу,

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

поспорить.

Вообще, кто я такой? Я очень долгое

время был CPO, я работал

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

А я давненько программирую для души.

Последнее время я программирую не для

души, а для работы. Делаю это с

агентами. А и, ну, за прошлый год я

сделал, я не знаю, сколько, ну, десят

более 10.000 комитов точно в свои разные

репозитории, в разные проекты. А, и я,

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

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

в общем, угораю по абсолютно всей части

айтишки и последнее время ещё помогаю

компаниям переходить в IT-трансформации.

Потому что когда они видят всякие

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

может написать каких-то очень крутых

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

говорят: "А почему у нас там команда в

20 человек не может это сделать за

полгода? А, и что для этого нужно?" Вот,

соответственно, а я помогаю в этом.

Что я сделал, да, из интересного? Из

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

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

кодинговый агент, а, который

ну имеет приличный объём кодовой базы,

где-то больше 3 млн строк, приличное

количество комитов, здесь только

автоматизированных комитов. Этим же

самым агентом, да, я с помощью него и

его же самого разрабатывал больше тысячи

штук. А, ну ещё там несколько тысяч

ручных, наверное, комитов. И самый

прикол, что, в принципе, это всё сделано

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

человек чуть поменьше комитил за 2

месяца в full AI режиме. То есть Full

AI, что я имею в виду? Мы практически не

читали код, да? То есть у нас обычно

AI-кодинг начинается с того, что вы

что-то, ну, сначала там в ручном режиме,

потом в агентском режиме. Ну, очень

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

код, они его читают. Я пришёл к тому,

что я его не читаю совсем. Я вам

расскажу, что мне это даёт. Да, это это

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

позволило мне перейти на технологии

более совершенные. То есть, если я

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

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

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

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

пишу на го и на расте. Абсолютно не знаю

ни строчки кода, ни на Го на Расте, но у

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

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

такой проект этот VLДK, да, он же,

который делает Валера Ковальский. Я его

полностью переписал на Тауре, то есть

раст с электрона. Ну не знаю ни

электрона, ни ни Тауре. И всё прекрасно

работает. Вот такая водная, да. То есть

я абсолютно угоревший по технологиям.

Вот. И сейчас я вам расскажу,

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

а, ну, так называемый кодинг, да? Я я

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

assistant coding и VIP codдинing для

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

А я в какое-то время стеснялся вот этого

слова. Я такой говорил: "Вот это одно

дело кодинг, другое дело AI assistant

coding." Сейчас я стал говорить, что а

это всё vibe кодинг. Всё, пофигу. А,

короче говоря, если ты пишешь код с

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

это, имей смелость это признать. Э, но

при этом я считаю, что нужно, что это не

непростая область знаний. Здесь нужно

прилично вообще вникать, что ты делаешь.

Здесь практики нужны определённые. И

здесь, в общем-то, на халяву оно не

прокатывает. Но тем не менее, если

достаточно опытный разработчик в

одиночку, да, вайп-кодит, ну, в том

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

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

числе там каких-нибудь сложных агентских

пайплайнов и так далее, а обычно это

даёт прирост производительности, да, при

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

порядка там x10 это в среднем. А то, что

я видел, это, наверное, от двух до 20

раз, да? И как происходит кодинг в

одиночку? Ну, очень просто. Мы берём,

делаем какую-нибудь веточку себе в гите.

А крайне редко в одиночку работает через

фичаетки. Это надо быть достаточно

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

работают в одной ветке, а, ну, одну одну

деф-ветку, да, какую-нибудь релизную

ветку. Вот прекрасно с этим живут.

Постольку поскольку используют тесты,

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

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

ну, их пишешь, как бы, на некоторые

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

Правила, опять же, хочешь использовать,

хочешь нет. Как такового планирования ты

себе никакого не делаешь, а, ну, и

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

то есть стараешься со своими

пользователями быть ВКонтакте. Например,

ты делаешь какой-то сервис, у тебя там с

ними чатик, они тебе что-то написали,

пошёл закодил. Вот буквально прямо

сейчас. Да. Все очень сильно удивляются.

Внешний эффект, конечно, поразительный,

когда тебе говорят: "У тебя там

проблема, ты говоришь там через 15

минут, всё, проблема пофикшена". Все

такие: "Вау, ну вот это хорошая

скорость". Да. В отличие от энтерпрайза,

в отличие от традиционной разработки и

работе в команде, да, что там

происходит? Ну, во-первых, давайте,

почему я говорю с точки зрения гита? Ну,

потому что, не знаю, для меня это как-то

вот ядро разработки, да, вот как это всё

выглядит. В обычной работе команде

всегда приняты фичи ветки. Мы работаем в

фичиветках, а мы в них, э, делаем новые

фичи, мы их мёржем, потом а делаем ревю,

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

некоторое время поступают в прот. Ну,

дай бог через неделю, зачастую там через

месяц, а иногда и по полгода. А тесты в

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

тоже как бы, да, и тут, и тут, заметьте,

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

там, мы хотим достигать покрытия 100%.

Вот вы в жизни когда-нибудь видели

реальное покрытие 100%. Я не видел, да.

Да, и потом это даже сама постановка

вопроса принята считать, что дурацкая,

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

что нужно 100% покрытие, ну, значит вы

вообще не очень понимаете, а что вы

делаете, потому что нужно, а, не 100%,

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

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

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

далее зачастую. Далее, что ещё у нас

интересно в разработке? В разработке

нужно как-то уживать вместе разных

разработчиков. И, как правило, очень

развесистые есть правила. Ну, начиная от

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

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

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

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

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

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

вот, а здесь шаг в сторону, короче,

расстрел. И так как шаг в сторону,

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

медленной поставке. И вот это вот 10 фич

в неделю на человека, это я ещё,

пожалуй, загну. Это быстрая команда, да.

Ну реально там а-а пять фич бывает, две

фичивает, да, регулярно. А если крупная,

то я и ни одной, да, крупной фичи в

команде. Не знаю, какого какой у вас

опыт у меня такой, что разработчик может

и месяц делать в одиночку, да. Ну и

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

скрам конбан какой-нибудь стандартный ag

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

или околокрамовские техники - это некий

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

раз в неделю. Допустим, раз в неделю. И

раз в неделю считается ещё достаточно,

а, быстро, да? Ну, то есть такой быстрый

скрам. О'кей. О'кей. И, а-а, и что из

этого вообще-то следует, да? Так как у

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

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

вайп-кодинг существует в одиночку, он

ускоряет. Естественное желание всех

попробовать - это что? Ну, вайпкодить в

команде, да? И вайп-кодить в команде -

это совершенно особая история. Аэ,

давайте подумаем, с чего начинается.

Начинается с чего? С того, что, ну, с

одного из этих двух состояний, да? Либо

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

себе берёте кого-то, допустим, или вы

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

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

э вам хочется внедрить AI практики. Так

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

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

факт, а предворять его я его буду тому,

как мы к этому факту приходим, а с каких

позиций. Скажу сразу, да, вот я начинал

как индивидуальный контрибьютор в этом

проекте, потом ко мне вот пришёл один,

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

деле у нас были сложности, да, после

этого я ещё в проектах поработал, где

есть совместный кодинг, и у меня

выработался набор практик,

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

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

контрибьюшена, потому что, а, то, что

происходит После вайбкодинга в одиночку,

как только ты себе берёшь первого же

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

какие-то обычные традиционные практики,

и ваша скорость резко резко сокращается,

да? А за счёт чего она резко

сокращается? А сейчас будем будем

рассуждать, будем смотреть, да? Итак,

для начала, что у нас происходит? А,

во-первых, если вы попытаетесь, а, по

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

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

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

аа, вы ваш лимит, да, ваш лимит - это

ваша способность придумать фичей на

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

разработки x10, то

на неделю надо придумать фичей. Ну,

умножим, да, сколько? 10 недель, 2 с 1

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

скажем, у меня лично мозг не способен

столько придумать. Я реально, я не знаю

вообще, как будет выглядеть проект через

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

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

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

добавится. Я без понятия вообще, что

через неделю произойдёт. Если вы

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

быстро убеждаетесь, что уже через по 2

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

неактуальный. Ну то есть вообще нет

смысла, да? А поэтому естественным

образом вы приходите вот к такой

странной истории, что рабочий горизонт

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

Тем не менее планирование вполне

полезно. А зачем оно нужно? В отличие от

индивидуальной работы, да? Вот если мы

посмотрим, здесь вообще нет

планирования. А зачем нам планирование?

А дело в том, что вам нужно

синхронизировать работу с товарищами,

потому что товарищи тоже, а лазают

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

всякой ээ всякой всячины. А что будет,

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

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

поляну пытается копать? Ну, произойдёт

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

будете сталкиваться, да? Аа вы будете

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

постоянные конфликты, вы будете всё

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

конфликтов. Вам это не надо. Короче

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

углам этой поляны, да. Вот это реально

очень хорошая хорошая аналогия.

Представьте код в виде поляны. И ну там

значит до этого там бригады с лопатами

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

на квадратный метр расставить. А теперь

у каждого экскаватор. А экскаватор

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

чем 1 м, да. Соответственно, их

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

она гораздо реже. А и уже нужно, если с

людьми ещё плюс-минус там можно по ходу

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

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

кто-то ту же самую ямку тоже

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

все на экскаваторах, там начинается

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

мешать. Поэтому, а-а, вот это вот, ээ,

это прямо важно и важно постоянно быть

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

за, повторюсь, много дней вообще

непонятно, то мы стараемся быть

ВКонтакте каждый день. Как это на

практике? На практике очень просто. Тут

нужен син, но син не такой, что: "А я

вот делал, а я, а я буду делать".

Знаете, вот этот типичный стендап

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

крайне угнетающе действовал. Вот как,

знаете, ну как будто это отчёт о

трудовой повинности, типа я вот барщину

несу и я должен сейчас отчитаться

обязательно. Нет, там основная основной

смысл вообще проинформировать людей, что

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

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

друг другу не мешали. Всё. Точка. То

есть ты говоришь: "Я, например, сегодня

хочу порефакторить а наш

какой-нибудь там профиль пользователя.

Если кто-то туда полезет, пожалуйста,

тоже скажите, а то мы столкнёмся. И

вообще я, может быть, ещё и в базу

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

пофакторлифн, ещё икс сюда заодно, да,

потому что мы же а кроссфункциональны.

Об этом немножко дальше. Почему в

вайпкодерской команде полезно быть

кроссфункциональным? И это тоже, да,

имейте в виду. А потому что если кто-то

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

беке, я об этом должен знать заранее.

Может быть, мы заранее тогда распределим

по-другому немножко работы. О'кей. идём

дальше. Идём дальше. И такой интересный

вопрос. Инструменты. Почему-то с него

обычно начинают, а на самом деле он

самый, на мой вкус, не очень важный,

потому что а история такая, что

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

важны. То есть, э, если вы работаете в

курсоре, ваш товарищ Клоди, а ещё третий

в кодексе, и вы ещё это обмазываете

какими-нибудь там внешними

инструментами, не знаю, вот с моим

шотганом кто-то хочет в шотгане, да, это

прекрасно всё сочетается, вообще нет

проблемы, на самом деле. А все кодерские

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

поддерживают так или иначе Git Pipeline,

да?

Либо, ну, какие там есть варианты, вы

можете у себя на десктопе что-то

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

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

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

гиIT, вы оттуда забираете изменения. Да

какая разница? Это, короче говоря, всё

работает. Поэтому мой опыт такой:

инструменты вообще не особо важны,

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

иметь общие правила. А почему важно

иметь общие правила? Потому что правила

- это как раз тот вот, э, общий клей,

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

чтобы проект не распадался. Потому что в

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

да? Ну, у нас есть, понятно,

какой-нибудь линтинг в обычном проекте.

А у нас есть какие-нибудь скрипты? Ну,

допустим, у нас есть какие-нибудь commit

actions. Ну, это вот классика, да? И то

зачастую комитет экшнсов нет, потому что

команда девопсов там нет, допустим, да?

Или мы или мы это настраиваем там год,

знаете, типа мы к этому идём, да? А, ну

какие-нибудь скрипты, типа кто-то

делает, кто-то не делает. Ну, в общем, и

вот то, что я встречал в проектах,

зачастую это просто написанные, да,

просто написанные правила. Просто

правила, а, на бумажке, грубо говоря,

написаны, э, в текст файле, как мы

пишем, да? Потом на кодрев тыкает,

говорит: "А, пункт 10, ты неправильно

сделал". Ага, плохо прочитал. Дальше

продвинутые команды. У них есть вот lint

какие-нибуд скрипты и какие-нибуд GitHub

Actions, да?

А что мы к этому добавляем? В агентской

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

эти вот две штуки. Ну, во, во-первых, мы

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

да? Во-вторых, мы используем, стараемся

использовать общие скилы. А почему? Ну,

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

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

понятия.

Если агенту не задать общего понятия,

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

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

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

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

разные фреймворки фреймворки вообще

выберут. Поэтому вот эти вот правила о

фреймворках, об основных каких-то

особенностях нашего проекта, а

обязательно стоит

ну именно в контексте общих правил

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

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

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

далее. И это и плюс всё остальное тоже,

да, плюс всё остальное тоже. И я бы

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

уделять правилам тестов, да? Вот сейчас

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

тесты, особенно про тесты,

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

особенно в командной агентской

разработке, всё крутится вокруг тестов.

Без тестов, без прямо развесистых

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

быстро родится хаос. А про то, почему не

спасают тестировщики, тоже чуть

подальше.

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

преобразуется Git, да? Потому что Git

Workflow для нас - это то, в чём мы

живём. Это то, та основа, на котором

всё, ну, всё нанизывается. Давайте

посмотрим на традиционный workflow,

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

себе, да? Ну вот обычная работа, давайте

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

работа. Ну, традиционно, во-первых, у

нас есть деф какая-нибудь ветка, да?

Деф-веетка. Что делает разработчик,

когда

хочет новую фичу взять? Он себе

отпачковывает фичику.

Он начинает в ней разрабатывать. Когда

он разработал, да? А если это хороший

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

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

бы всё решено. О'кей. В этот момент он

делает request, потом PL request висит,

Pull request проходит в review, и если а

в момент, после э допустим, Тимлит

говорит, что всё ок, да, то происходит

итоговый мер. Бывает ещё здесь,

например, что в этот момент что-то

влили. Пока он там ревьюил, уже транк

вообще изменился, надо заново

перемеживать. Но это редкость, да, это

редкость. И в принципе вот такая вот

история работает. А почему она работает?

Потому что у нас этих фичоветок, а, ну,

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

каждого разработчика в неделю, и они вот

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

друга, ну, не сильно задевают. Stage

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

стабилизированная версия странка льётся

в stage, stage же ещё раз там

стабилизируются, гоняются какие-нибудь

тестюты и прочее, и заливается в прот.

О'кей, всё понятно. Ну, стандартно все

знают. Но в чём здесь есть проблема?

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

То есть вот стадия ревью всех бесит. А

почему? Потому что она, блин, занимает

меньше, ну, времени. Зачастую не меньше,

чем вообще сама разработка, да. Плюс

ревью бывает ревью ручные, ревью,

основанные на правилах вот этих вот, да,

текст файл, а-а, вот это вот кнуть носом

в пункт 36, который ты там не учёл, да,

обязательно. А хорошо, если есть,

который сразу сам работает. Далее, потом

фичи на каждый чих создаются. Ну, это,

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

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

мелкие очень фичи, типа, добавить

кнопку. Ну и зачем ей как бы фичаетка?

Так, глобально. А, ну и пока

делается фича. На самом деле бывает, что

накидают, э, изменения. А если

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

если ревью, не дай бог, затянулось, то

все успевают понакидать тебе сюда разных

своих комитов. Ты потом это каждый ра

каждый раз ты это мёрзшь, в общем,

ругаешься и всё это как-то неприятно. Ну

о'кей. Но все к этому привыкли. Хорошо.

Стандартный Git Workflow.

А есть, но с этим есть проблема. Почему?

Вот проблема такая. Представьте, что у

нас, а, вот такая вот история. Но только

мы делаем не 10 комитов в неделю, да, не

10 фич в неделю, а 10 фич в день. Причём

нас пять человек. 50 фич мы делаем в

день. Вы можете себе представить 50

ревью в день в команде? Вы можете себе

представить 50 мёржей, да? Причём это

эти мёржи вообще в произвольное время

должны происходить абсолютно. То есть

это, ну, это такая каша становится, что

просто жесть. И вот эта, собственно, вот

эта каша, она максимально начинает

тормозить разработку. То есть в итоге

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

потому что, ну, пошёл агенту, как бы

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

сделал. А всё остальное время мы

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

задачками, типа: "авайте пообсудим, а

давайте ревью, а давайте теперь, пока мы

тут ревью, ещё три человека, влили свои

какие-то фичи. У нас там теперь уже мж,

ну, какие-то мёржконфликты. Давайте их

теперь заново мёржить. Ну, короче, в

общем, весело, да. Так вот, чтобы это

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

чудовищную вещь. Мы делаем совершенно,

а, гнусный антипаттерн, называемый

именная ветка. То есть мы берём и

раздаём каждому разработчику ветку. Вот

я Глеб, у меня будет ветка Глеб, а,

Витя, Петя, Даша, Маша, у всех у них

есть своя веточка. И что я делаю?

Во-первых, в начале дня я мержусь

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

спрашиваю. Моя задача какая, чтобы, ну,

я отвечаю за свою ветку, чтобы она мне

была вообще удобна в работе. И моя

моя задача, что то, что я лью вообще со

своей ветки, оно работоспособно. Это я

за это вообще отвечаю. А то, что

происходит в рамках моей ветки, я её

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

откатывать, я её могу бранчить. Короче,

что хочу вообще с ней делаю. В общем, а

развлекаюсь, как хочу. Почему я

развлекаюсь, как хочу? Дело в том, что я

в параллель. Вы, наверное, в курсе, но

эффективный агентский пайплайн - это

две-три фичи в параллель. Вообще

зачастую, да, иногда в разных

инструментах. И я постоянно

отпачковываю, а, от своей вот этой

именной большой ветки. Я либо

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

чувствую, что фичи вообще достойны своих

отдельных веток. бывает, что фичи такие

мелкие, что и не нужно. А, ну, взрослые

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

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

вот здесь вот аналог, но только не

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

отпачковываю. Отпачковал, вмёрл,

отпачковал, вмёрл. Мёржко конфликты

решаю сам, да, сам, сам сво со своими

фичами разбираюсь, какая из них там

главнее, какую дропнуть, какую не

дропнуть, как это всё должно работать. А

половину фичей мелких вообще делаю без

фичеток, потому что, опять же, я сам

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

тут, э, не знаю, 30 комитов сзади. Моя

проблема. Главное, что Главное, чтобы

тот мёрж, который я потом отправлю в

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

вот я делал кусок какого-то важного

функционала, аа, и меня там Вася, а Вася

ждёт, пока я его закончу, чтобы самому

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

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

потом сложного мёрзжа не было, он ждёт,

пока я его доделаю. Да, вот этот кусочек

я отправляю в тран. Что суперважно? А

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

придерживаются вот такой конвенции.

Во-первых, тестов много.

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

тесты зелёные. Если хотя бы один тест

падает, именная ветка не имеет права

замёржиться в тран. Потому что если у

каждого один тест упадёт и вы это всё

замёрз в тран, всё у вас будет

катастрофа. Вы потом в жизни не

разберётесь, что там вообще происходит.

Короче, у вас возникнет каша. А

единственный способ сохранить, э,

ну, вообще рассудок - это следить за

тестами в данном случае, да? Почему?

Потому что код, давайте подумаем, а что

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

А-а, кодрев на уровне того, что я 10

фичей или там 20 фичей в день делаю и

кто кто мои фичи будет ревьюить. Ну,

о'кей, агент поревьюет, да, кодревью

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

разработчик другой успеет ревьюить? Да

нет, конечно, он прочитать это всё не

успеет. А сможет ли другой разработчик

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

всё то, что я наделал за сегодняшний

день? Нет, не сможет, потому что за

сегодняшний день я в среднем там меняю 5

тире 10.000 строк кода. Ну какой вообще

какой разумный человек это всё сможет

осознать? Нет, никакого времени на это

не хватит. А сможет ли тестировщик

протестировать вообще все мои изменения?

Да не в жизни. Не в жизни он мою каждую

фичу успеет протестить. Это сколько надо

тестировщиков? На одного разработчика 10

тестировщиков придётся делать, да?

Поэтому тестировщик, я сам пишу тесты,

ээ пишу автотесты, да, много, потому что

я же ленивый тестировщик. Я стараюсь

всё-таки, чтобы, а, побольше было, а-э,

ну, того, что не надо потом, да, больше

ещё раз, второй раз тестировать, чтобы

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

Но я, на самом деле, и вручную тестирую,

будучи а вот такой вайб-команде. На

самом деле,

необходимость в чисто ручных

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

уменьшается, так скажем, ну, не совсем

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

тесты, например, там из trank of stage,

да, они могут гонять, о'кей, о'кей, и то

их можно toend тестами заменить на том

же самом плейрайте, на чём угодно. А

просто не хватит столько тестировщиков,

если вы хотите выжимать из команды там

X10 эффективность, да, а не а не

дропнутся там до X полтора, да, как или

до 20% сверху. А поэтому вот вот так

вот, да, и ээ вот именные ветки. А в

классическом Git Workflow это считается

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

ужас-ужас, да. А тем не менее это

прекрасно всё работает. И более того, я

считаю, что так и надо работать. Вот это

вообще вот новая парадигма, да? Новая

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

когда мы ещё а не были приучены, как

надо, как правильно. Аа идём дальше. А,

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

говорил. Ещё пару слов скажу. Аа есть ну

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

так называемый enticinting, да? То есть,

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

помимо каких-то, а-э, ну,

верифицированных правил, там, как бы,

заранее заданных, да? То есть мы, у нас

есть линтеры, которые чисто языковые

особенности делают, и у нас есть агенты,

которые проверяют на архитектурные

паттерны, на соответствие технологиям,

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

можно выделять в сайгентский workflлоow,

это можно выделять вообще в отдельную

стадию, это можно повесить на

какие-нибудь комитхурки, да, вот,

допустим, аа вот, ну, линтить абсолютно

каждую фичу, это бывает просто долго. А,

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

сюда какого-нибудь агента, который, а,

смотрит просто по всем, ну, по всему

комиту проходится и смотрит на кодстайл,

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

рабочая. Вот. А-а, далее, интересная

штука про роли в команде. Ну, во-первых,

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

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

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

и все и могут сделать всё. То есть у нас

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

как это сказать, блин, забыл слово. Ну,

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

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

быть деление там фронтбк. Ладно,

фронтбк, аа проject-менеджеры,

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

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

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

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

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

объединяться, и все делают всё просто,

может быть, с разной с разной

эффективностью, да. Вот у меня как раз

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

проекте мне вообще больше всегда БК

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

алгоритмы, что-то такое там, а вот

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

всегда вообще сложно, да, у меня чувство

красоты и немножко своеобразное. И у нас

была такая была такое, ну, было

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

возможность, я прошу другого

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

он занят, например, или или у него там

большая задача, он этот фронт там

целиком рефакторинг, а мне нужен вот

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

фечи, но я беру и сам пишу, да, не

проблема. Точно так же с бэком.

Допустим, я пишу бк, я там хорошо

ориентируюсь, аэ, но ему там, чтобы меня

не ждать, он, пожалуйста, берёт и пишет

бэк. Ну, про спеки, про всё это. Это

само собой. Если у нас SДD, а у нас SD,

да, чуть попозже про SD, что это такое,

для чего в команде? Аа это база вообще,

поэтому все пишут спеки. И

продакт-менеджер там тоже пишет спеки, и

разработчики пишут спеки. И

продакт-менеджер потом идёт и

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

пишет спеки, то нафиг он кому нужен.

Нуще, серьёзно. А, о'кей. Али вообще за

что во всей эта истории отвечает, на

самом деле? А, Тимли очень просто. Он

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

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

и он работоспособен. Как он это

поддерживает? Ну, это его проблема, да.

Ну, как-то он поддерживает. В общем, ну,

я просто хочу подчеркнуть, что не стоит

цепляться за старые практики

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

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

это, а-а, всё это, например, ревью.

О'кей. А процессы,

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

вот. Я его назвал ультраканбан. Почему

вообще он похож на канбан? Э, потому что

очень важны ограничения на число задач в

работе. Потому что, когда у нас такое

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

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

не за неделю и не за месяц, а за час и

за день, да? Она начинает протухать с

такой же скоростью за день, как раньше

она протухала за месяц. И это прямо

боль, да, это боль. А если вы начинаете

копить эти ветки, вы их потом никогда не

перемёрз и проще. И более того, вы

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

перемёржете, у вас сама спецификация

успеет поменяться, потому что весь

остальной проект уехал. А, поэтому

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

ни в коем случае много задач

одновременно. Далее, планирование. Аа,

спланируем на день, на неделю.

Бесполезно. Это вот всё, ну, время

потратите, а толку не будет.

Коммуникации с коллегами. Раньше вот

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

пообщались, ну, и всё, самые хардкорщики

могут ещё вечерний какой-то митинг

устроить. Я считаю, что, ну, в

современном процессе, если вы хотите

выжить максимум, но это минимум три раза

в день. Но при этом это не должно быть

прямо регламентированное общение. Вы

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

Телеграме. А этого достаточно, да.

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

вот этот еже

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

там, может быть, какой-то код заливаете,

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

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

человеческое, всё убираем. Это, я

считаю, пережиток старины. Вот эта вот

история, что: "Ой, а я только я знаю,

какой код хороший". Да нет, сетки лучше

тебя знают. Ты просто им плохо доверяешь

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

да? А на самом деле агенты прекрасно

ревьют. А про артефакты, во-первых, а

процесс SD, я надеюсь, ну, многие уже в

курсе, что это такое, да? Specification

Driven Development, да? Specification

Driven Development, то есть разработка

по спецификациям. спецификации must

have, да, до кода мы пишем вообще план,

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

степени техничности. Но важно с

выкидываемыми спецификациями, что это

значит? Это значит, что мы пишем

спецификацию, потом пишем код, покрываем

тестами, а потом эту спецификацию

архивируем. Мы более на неё стараемся не

ссылаться. Почему? Потому что она

устареет очень быстро. Потому что код

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

живёт в системе, а, и он эволюционирует

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

день, каждый час какие-то новые фичи.

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

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

начинают тупить, да, они смотрят

реализацию по спеке, смотрят код,

понимают, что всё, ну, вообще одно

другому полностью не соответствует,

начинают фигню какую-то делать. Поэтому,

а, всё очень просто. Архивируем спеку.

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

снова что-то делаем? А как нам понять? А

как же сделано? Должна же быть

нормальная документация? Очень просто.

А-а, задаём агенту вопрос: как у нас

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

функционал сделать. Пишем новую

спецификацию. Соответственно, он нам

говорит, как сделаем. Мы на этой базе

пишем новую спецификацию. Мы не

цепляемся за старую. У нас код - это

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

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

архивируем. Вот это называется

specification Ren Development с

выкидываемыми спецификациями.

Вот. И а мой опыт в итоге, да, то есть я

вот так уверенно говорю, собственно, а

что это всё позволило сделать? А вот за

3 месяца, ой, за 2 месяца в три руки, ну

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

так сильно увлечёт. Мы сделали 1.000

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

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

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

которые мы сделали через

ну, автоматизированный, я имею в виду, у

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

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

merge full request. А, несколько тысяч

фич/комитов, э, полуавтоматизированных,

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

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

комметишь. А в проекте написано больше

600 бкэнд-тестов, там 50 фронт N2N

тестов. Вот этого, кстати, мало, да? Вот

этого мало, надо больше. Вот и это

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

порядка двух крупных фич в день или там

двадцати мелких фич в день, да, в

отличие от там 10 фич в неделю, что

бывает. Причём это разработка в команде.

И у нас было даже такое ощущение, что

какое-то просто сумасшествие, потому что

мы вдвоём, ну, прямо реально делаем

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

10 человек. Мы все, да, все те, кто

работали над этим проектом, мы имели

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

командах разработки. И скорость мы,

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

да, вот такими вот способами.

То есть мы смогли сохранить скорость

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

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

качеству, потому что вот эти

бэкэнд-тесты нас очень хорошо спасали.

Ну, вообще все, все подряд тесты нас

спасали. А напомню, у нас тестировщиков

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

Аа куда это всё улучшать? Улучшать очень

просто. Пишите больше тестов, ещё

больше, да, и в 10 раз больше. Ну и

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

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

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

ненужные. За ними нужно иногда

послеживать.

А теперь последнее самое. И э у нас

останется, наверное, 5 минут ответить на

вопрос. Как внедрить это себе? Да, вот

вы сейчас посмотрели, такие: "Ой, это

какие-то сказки, у нас так не работает,

мы уже пробовали там ещё что-то".

Во-первых, нужен один человек, фанат, а,

который на себе знает, что это

эффективнее там 10-20 раз, да, он уже

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

проводник. Далее, вам нужна отдельная

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

То есть вы не пытайтесь это на команде,

которая уже есть, развернуть сразу.

Скорее всего, будет большое

сопротивление. Сопротивление само по

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

результат, да, потому что наш образ

мысли, он формирует, в общем-то, итог. А

негативный результат закрепится как уже

норма, новая норма, да. Мы такие: "Мы

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

работает". Да, будет вот так вот.

Поэтому пробуйте на отдельной команде. А

если у вас и если и когда у вас на

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

два-три человека, не более, да? два-три

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

слишком большое вот трение по процессам.

А далее, когда вы вот в таком формате

сможете от этой команды добиться

результатов, уже ээ члены этой команды

идут другие, делают

становятся их ядрами и трансформируют

остальные команды в организации.

На этом всё. Да, я попытался рассказать

про своём о своём опыте выстраданном,

как делать вайбкодинг эффективно. А

давайте отвечу, с удовольствием отвечу

на вопрос.

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

во-первых, во-первых, спасибо за доклад.

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

живую реакцию. Вот я в чате следил за

нашим чатом. Коллеги слушатели, вам

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

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

внутри меня, которым я отработал 8 лет,

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

Глеб, ну, главный вопрос имхо, если

обобщить вот комментарии, сомнения

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

себя то, что ты говоришь, это область и

граница применимости такого подхода. То

есть насколько это работает там для

энтерпрайса, для больших проектов, для

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

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

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

так далее. Как ты

>> видишь, классный вопрос. А на самом деле

очень важно вообще для AI-кодинга

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

имеем дело, с какого объёма проектом.

Почему? Потому что если представить вот

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

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

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

это, допустим, 200.000 токенов, ну такой

средненький, маленький. Стартап там на

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

способом. Это, допустим, две там 2 тире3

млн токенов, да, какой-нибудь, э,

корпорация,

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

так, разделите на 15, а, соответственно,

2 млн токенов - это что у нас там? Я

плохо делю на 15 уме. Аа что-то типа

100.000, да, 100 с копейками. А, раздели

130-10.000 токенов, да, это, ну, такой

как бы не не шибко не шибко большой

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

строк. Но в корпорациях бывают проекты

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

десятки миллионов строк. Так вот, а вот

этот подход идеально работает на

маленьких проектах. А почему? Потому что

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

проблемой. Там всё, там всё ещё узким

горлышком на самом деле является

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

она вот она не в 10 раз ускоряется. То

есть на чем меньше проект, тем быстрее у

нас вот схлопывается стоимость

разработки. Маленький проект, там

действительно X20. Проект побольше, там,

допустим, X3. Проект совсем большой,

может быть, там X075.

Она, конечно, увеличивается не

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

можно жить на традиционном workкфлоу. На

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

ещё не настолько сильно улучшается. Тем

не менее, она каждый месяц улучшается,

да, каждый месяц новые среды, новые

агенты, не знаю, какой-нибудь кодекс.

Офигенно уже круто работает с

контекстом, да? А и там в X2

производительности он уже даже на

больших проектах позволяет выжить и так

далее. И это будет схлопываться. Чем

далее это схлопывается, тем больше

ну больше оверхед на всё остальное. Вот

и всё. на больших проектах. Что ещё,

кстати, ну, как бы наоборот плюс, что

вот этот бульдозер, да, бульдозеры на

поляне, у нас поляна-то большая, мы

меньше мешаем друг другу. А поэтому

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

На самом деле, я думаю, в какой-то

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

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

большие проекты будут даже проще

маленькие в каком-то смысле. Знаете, как

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

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

ну, в неё не засунуть там две команды,

там буквально там два человека начинают

какую-то вот бойлерплей делают, базу

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

человек подключить. Они там поработали,

поработали, можно и 20 человек

подключить, да? То есть поляна

расширяется. Ну вот здесь точно так же.

Чем больше проект, тем, с одной стороны

overhead, э, как бы больше, с другой

стороны поляна шире, нам проще. А вот,

надеюсь, ответил.

>> О'кей, принято. Слушай, второй вопрос,

коллеги. Я, извините, вот я их записывал

все. Я, наглеп, могу тебе потом

передать. Может быть, ты в канале

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

Слушай, а как с качеством? Ну, то есть

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

интеллект не нагенерил каких-то не очень

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

стали все зелёненькие?

А потому что мы подключаем, ну,

во-первых, ты подключаешь ревюеров, в

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

агентских. А если у тебя есть сомнения,

смотришь глазами. Если ты глазами

смотришь и понимаешь, что там 3/4 тестов

молоко, ну, значит, что-то не так.

Значит, может быть, к твоей ситуации это

ещё не зрелый агент для разработки, но

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

агенты пишут хорошо. А я не вижу такого,

чтобы они совсем вот 3 с 12, например,

год назад отвратительно тесты писал. Он

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

просто, да, прекрасный тест, конечно,

очень всегда зелёный, да, и вот в таком

духе. То есть он какие-то стабы писал

вместо тестов. В последнее время агенты

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

писать штабы вместо тестов. Но поэтому

достаточно на тесты несколько раз

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

вменяемые, ну и всё. И отдать это

агентам.

>> Хорошо. Слушайте, ну что, коллеги, у нас

в целом время доклада подошло к концу.

Мы хотим оставаться в тайминге, поэтому,

Глеб, большое спасибо. Вот, давай мы

тебя отпустим. Коллеги, е, если что, да,

да, контакты спикеров можно найти. А

может быть, Глеб, кстати, останешься,

да, сейчас и в чате кому-то сможешь

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

>> Вот поэтому всех с вопросами и

комментариями по этому докладу

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

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

программе.