0: Друзья, привет. Это подкаст, организованное программирование. Я его ведущий Кирилл Макевнин. У меня сегодня в гостях Иван Поддубный. Вань, привет, привет, Ваня ситио в компании веб практик. Это интегратор. Примерно 150 человек компания. И, соответственно, так получилось, что

1: За последнее время на большом количестве конференций, которые проходили там в Москве, в Питере, Ваня приезжал, выступал и рассказывал про то, как они внедрили эс диди спёк девелопмент в свою компанию. И мне после того, как я это посмотрел,

2: Vania там пользовался популярностью во всех кулуарах говорили смотрите, какой классный доклад у Вани вообще класс, мне очень захотелось сделать этот подкаст, поговорить, потому что в основном говорят про теоретическую какую-то имплементацию, да, а на практике кейсов мало, то есть что-то, какие-то кусочки где-то появляются у тебя.

3: Есть законченный кейс от начала до конца и сегодня у нас будет не теоретизация на тему того, что такое dd и как мы будем жить будущее мы поговорим про то, как вот вы наверное одни из пионеров, как минимум в русскоязычном мире, кто это сделал.

4: Соответственно, у меня 1 прям к тебе вопрос как вы вообще пришли к идее, нам нужно внедрить sde да, я немножко, чуть чуть буквально скажу поправлю слово законченные мне кажется, слово закончить этот процесс нельзя, он итеративный, постоянно улучшающий.

5: Особенно в нашем изменчивом мире по поводу того, как мы пришли к std, мы одни из тех, кто довольно-таки рано заадолжености, но то есть 1 из наших некоторых достижений то, что мы к концу прошлого года у нас был там стопроцентный адопшен среди всех разработчиков.

6: И именно уже когда к концу, когда мы подходили к тому, что уже мы отмасштабировались, уже там, не знаю, когда там декабрь, примерно начали возникать мысли, а, собственно, а что дальше? А как делать? Процесс более системный, как его отстраивать и как его

7: Отстраивать, масштабировать на не только на разработчиков, а на весь процесс разработки, в принципе, можно сказать, с 2 сторон, да, подошло и со стороны необходимости, системности, и со стороны необходимости масштабирования процесса, чтобы он был единый для аналитиков, для разработчиков, для

8: И здесь как раз dd для нас выступил некоторым шиной, которая должна была объединять эти процессы, тут ещё вот была такая история, что мы в начале года 26 как раз собрались всеми руководителями.

9: Сессию очередную ежегодную. И вот там руководители профессий всех собрались, там бэкендеров, контендеров, аналитиков и девопсов. И всем была поставлена такая задача. Типа, говорит, вот следующий шаг, он какой, как вы видите, вот постройте себе вот архитектурную схему.

10: Агентов ваши, как вы видите, вот именно ваше развитие в отделе для того, чтобы в том числе повышать автономность вашей работы. Вот 1, 1 из тезисов, это вот куда мы стремились. Мы уже тогда начали думать, как нам потихонечку подбираться к увели

11: В течение автономного времени прошла эта стратегическая сессия, и все пришли со своими схемами. Но вот такая классическая, не классическая. У многих такая ошибка была. Собственно, мы её вот получается, отловили на самом, так сказать, начале, некоторые в этой ошибке

12: Дальше все пришли, принесли и у всех свои источники контекста, свой способ их сохранения, там свои какие-то агенты. И вот мы просто посмотрели на вот эти там, условно, 5 презентаций, как краткие, да, со схемами. И мы понимаем, что, ну, эта штука, ну, она вообще

13: Вообще никак не состыкуется для того, чтобы выстроить этот сквозной процесс. Ну и вот, то есть, как бы это такой вот 1 из таких основных причин, да, тоже в том числе, чтобы мы действительно сделали, объединили этот процесс, нам нужна вот эта единая общая

14: Шина контекста, которая нас будет объединять. Вот. Ну и тут уже понятно, что нам действительно вот нужен этот flow, какой-то движок, вор готовый, который бы нам это позволил. Ну то есть мы сразу начали уже смотреть, какие есть готовые инструменты для этого изучать, сравнивать их, точнее, мы

15: Их начали чуть раньше сравнивать, но вот тогда уже стало понятно, что прям без этого нам никуда. Просто потому, что без единого способа работы со всей контекста, чтобы каждый работал вот с единой этой шиной, мы двинуться дальше не можем. Наверное, вот как мы пришли к ди, это ответ на

16: Вопрос тогда чуть чуть расширю, потому что какие должны быть предпосылки ещё с точки зрения того, что болело? То есть мы начали пользоваться, то есть вы начали пользоваться агентами и поняли, что какой-то разнобой идёт или у вас были спеки, но с этим были какие-то проблемы. То есть вот почему именно идиди, почему ты сказал, например,

17: Krum то есть ты же мог также сказать да да, не мог не, ну в смысле sd для меня давай, как я его воспринимаю, для меня это способ работы с спеками и контекстом, который у вас есть на весь, на всем истории, то есть.

18: Спеками я называю, то есть артефакт, который нам идёт на всем протяжении жизни, да, то есть это требования, которые мы должны выразить, спецификации, которые мы должны спроектировать, имплементировать, проверить, да, условно. И для меня cd это как раз тот инструмент.

19: Который это делал, да, у нас были вот как раз там в прошлом году какие-то попытки, да, то есть там локально в виде файликов кто-то пробовал сохранять там разными там super powers какие-то артефактами генерировали то есть реально пробовали различные подходы но это было все не системно. То есть вот нам нужн,

20: Нужен был какой-то фреймворк, который бы позволил и регламентировал, требовал как нужно на каждом этапе, условно какие скиллы. Каждый участник этого там линейного по факту процесса должны запускать для того, чтобы вот у нас фича от

21: Проектирование до тестирования как минимум проходило. То есть вот как минимум через 3 омига проходило там вопрос диплоя, мы немножечко там за скобки выносили, он нас не так беспокоил, не какая-то больная для нас именно конкретно в нашей компании вещь, да, то есть, ну там вы просто 1 скилл сделали, там для того,

22: Чтобы это все диплоилось или выливалось в mr, там циклично перепроверяло себя, это как бы у нас на этом не было фокуса основной фокус это у нас классический 3 амига, это аналитика разработка, тестирование и вот собственно нам нужно

23: Был как бы системный подход. То есть мы от февра взяли не только то, как мы пишем спеки, мы и взяли ещё и воркфлоу, да, то есть для нас это как движок воркфлоу, это как фреймворк, мы к нему относимся. Вот примерно не знаю, как symphony ларавел какой-нибудь java spring.

24: React для нас это вот что-то, какой-то фундаментальная штука, на которой мы уже все остальное строим. Кстати, можно было сразу добавить слово водопад. Вот. Да, блин, ну действительно, мы приходим к классическому этому водопаду, точнее мы пытаемся

25: К нему прийти, но иногда спотыкаемся вот ооо гибкие реалии мира, что вот одни из проблем, которые мы решаем вот в процессе вот я из отпуска вышел как раз вот на этой неделе и разбирал какие проблемы были с didi за

26: Последние пару недель. И вот там на 1 из проектов, как это в классическом мире бывает, что бывает, нужно быстро что-то сделать, а требования не успевают. Бывает за разработкой. То есть ты, у тебя в итоге сроки приближаются, аналитика полностью не

27: Оработано, но уже надо начинать, иначе не пойдёшь. И здесь вот как бы в эту классическую схему водопада ты немножко упираешься и такие так разработчики пойдут параллельно уже работать, и они такие начинают уже вносить изменения в эту спеку вместе параллельно с аналитиками.

28: Здесь они друг другу мешают, толкаются немножко локтями в этом плане, когда ещё не до конца требования проработаны, а их уже частично делают, они меняются по ходу тела ещё, то есть даже то есть на уровне черновика подключились ребята, и вот такие случаи ломают нашу классическую

29: Водопадную схему. Хотя вот по факту эс диди это идеальный водопад, да, к которому мы вернулись, который переосмыслен с приходом мишки.

30: Последний вопрос. Перед тем, как нырять прям внутрь уже и поговорить о том, че там у тебя происходит, какие вы метрики ставили. То есть это же не просто там, о, давайте внедрим. То есть были же конкретные проблемные зоны, которые хотелось победить. И, наверное, вы как-то их оценили, что что-то должно произойти ускорение.

31: Разработки, не знаю, что-то ещё может быть. Ну, конечно же, ускорение разработки, да, то есть мы, мы понимали, да, то есть, что наши пилоты ещё там в прошлом году показали, да, ну, условно, на уровне компонента, на уровне модуля ты можешь сильно ускориться.

32: Но как теперь этот результат сделать системным, да, то есть чтобы он был воспроизводим всеми участниками процесса, отмасштабирован на все проекты, на все процессы. И, соответственно, это была не какая-то там выброс какой-то просто где

33: У кого-то что то получилось, как это чтобы работало на потоке и стабильно. Вот. И, ну то есть основная цель, которую мы ставили, действительно себе ставили, это ускорить разработку. Прям цифра была какая-то с точки зрения цели. Вот там мы хотим ускориться 5 раз. Нет, мы так не ставили, мы то есть понимали, что рост

34: Во многих задачах будет кратный. И он подтвердился, да, то есть потом мы, когда мы в мае сделали, замер, знаешь, вот мы чуть в сторону отойду. Я участвовал в 2 круглых столах, как измерять эффективность разработки после пришествия иай, и на самом деле

35: Это сложный вопрос, потому что мы не научились измерять эффективность разработки ещё до и i. Хорошо и качественно, да, то есть там все способы, они немножко лгут, могут лгать, скажем так. Особенно если там начинать делать трессировка на пользу.

36: Для бизнеса, насколько это эффективно, там приносит все остальное, там все ещё сильно сложнее становится. И вот 1 из способов, который для меня, я считаю, 1 из простых и валидных, это оценка по билайна. То есть когда у вас есть оценка стартов,

37: Там типовых задач до и оценка после сколько вы выполняете? И так получилось, что действительно у нас в компании этот бейзлайн, он был задолго до ишки. То есть у нас был бейзлайн оценок фронтенда бэкенда это типовые какие-то штуки простые и логика что почти все сложные.

38: Вещи можно разложить до простых, на которые все команды, все разработчики, там аналитики, тестировщики должны ориентироваться в плане оценки. То есть, грубо говоря, мы понимаем, что вот такой модуль, его можно разложить на такие компоненты. Такие компоненты примерно столько должны занимать по времени. Вот, ну,

39: Понятно, что там специфика проекта учитывалась, да, сложность. Ну вот это такое некоторое мерило, которое нам позволяло примерно равнять разработчиков команды и задавать рамки, в рамках которых примерно нужно существовать, чтобы не было кратного

40: Разрыва между там в 1 команде с такими таймингами работает в другой с такими. И когда мы переоценили этот бейзлайн в мае, мы увидели кратное увеличение по больше чем половине задач вот прям там x, 3, x, 4, x, 5 вот.

41: Множители, которые мы получили на выходе. То есть, когда мы шли, мы не ставили себе цель. Вот мы вся разработка должна быть x 5. Нет, мы понимали, что мы придём к этим множителям, но, соответственно, это нужно измерить, когда мы там начнём масштаби,

42: Немножко процесс не только на звёздных ребят, которые и так действительно и так были быстрые, они стали ещё быстрее. Но, соответственно, нужно смотреть вот на масштабе. Вот, к примеру, как раз в мае мы эти цифры замерили, ну и вот реально больше половины задач кратное увеличение

43: И после мая мы увидели, что ребята действительно укладываются в эти оценки. То есть это не то, что мы их переоценили, там с ребятами, в том числе опросили всех и так далее. И мы действительно увидели, что ребята в новый тип оценок уже начинают вкладываться, там, на самом деле ещё дальше рост мы оценили линейный.

44: Рост, а есть ещё нелинейный рост, потому что, условно, 1 задачу ты делаешь там в 3 раза быстрее, но по факту это ты разработчик сейчас не работает над 1 линейной задачей. Он работает там 3 5 сессий, да, и там ещё есть нелинейное ускорение.

45: Это вот такой вот следующий нырок вглубь, который тоже позволит нас ещё сильнее получать больше профита в плане ускорения. Знаешь, какой-то интересный момент, когда ты говоришь про разработку фич, речь идёт из про отдал в тестирование, или ты говоришь про сквозную выклад?

46: Что вот прям довели до прода наши оценки, они довели до прода. То есть у нас оценки все включаются с доведения до прода. Там есть у нас некоторая хитрая схема, что мы день оцениваем не в 8 часах.

47: Специально, а в 5 для того, чтобы у нас были некоторые буферы, которые могут покрывать некоторые риски, там, на коммуникации, все остальное. И благодаря этим буферам. То есть мы, у нас оценки условно в пятичасовом Дне.

48: Мы считаем, что эти буферы должны гасить все там, некоторые шероховатости, которые могут возникать. Вот, и это позволяет нам точнее попадать в свои оценки, потому что у нас есть буферы как-то так, с 2013 года я создаю курсы хекслет сейчас

49: Сейчас мы активно двигаемся в сторону искусственного интеллекта агентное программирование, автоматизация и low coding ллм. Программирование все это становится ключевыми направлениями в ближайшем будущем, если вы хотите повысить собственную продуктивность, внедрить решение на базе ии в работе или стартовать собственные.

50: Проекты, то вы попали в правильное место. Посмотреть на конкретные программы обучения можно по ссылке в описании. Хорошо. Ну что, давай переходить к самой сути. Ты уже говорил про опен спёк вообще, давай поговорим про вот это направление что ли? Да, что

51: Появились прям целые фреймворки, и ты же выбирал. Расскажи чуть про это. Мы ресерчили вместе с ребятами, да, то есть, ну давай так, там есть 4 основных игрока, которые там можно рассматривать как больше командные

52: Инструменты и 2, которые не сильно, на мой взгляд, можно воспринимать как командные, да, то есть основные вот это 3 эшелона. Наверное, 1 эшелон это open спёк, спёк, кит, 2 эшелон это вот они больше воркфлоу.

53: Движки, на мой взгляд, здесь можно, конечно, со мной поспорить, это beat judy и 3 это вот про индивидуальную работу чуть больше, это вот это кок и суперпауэр мед. Покок, чуть я на самом деле позднее познакомился, в том числе ты

54: Меня его подтолкнул, хотя скилл грили я использовал до этого. Я просто не знал, что у него целая пачка этих Скилов, которые он прям некоторую систему даже построил. Вот это больше про индивидуальную, на мой взгляд, работу. Я бы вот не воспринимал это.

55: Инструмент для как для командной работы, вот для командной работы, как раз там интерпрайз как классическая. Вот для меня это в 1 очередь все-таки open спёк спеки. Я бы сравнивал эти 2 инструмента, причём у спеките больше звёзд, он чуть больше

56: Раскручен он был 1, но не всегда 1, самый лучший, даже несмотря на то, что у него больше звёзд. И он, на мой взгляд, здесь имеет место инерция, да, то есть некоторая, да, когда лидеры становятся

57: Ещё больше лидером. Не потому, что он лучше, да, а просто потому, что на него в 1 очередь пересаживаются, несмотря на других игроков. Ну, там много разных примеров, не знаю, можно там реакт редакс какой-нибудь вспомнить, да, когда лидер просто каменеет, да, в своей нише вот open.

58: Чем меня подкупил 1 гибкость, простота входа бай дизайн. Вот by прям у них файлик идеологии. Они говорят, мы изначально про Браун Фил проект. Мы вот изначально затачиваем всю свою работу про

59: Там вот эти вот десятилетние монолиты, идите все к нам, это мы про них, мы прям на них заточены. Spike кид, по мнению многих экспертов, он чуть лучше работает для гринфилд проектов. Вот проект с нуля, потому что вот там все чисто выстраивается.

60: Успех кита, он чуть более сложный, у него выше порог входа, у него там нужно там питон, ещё там себе поставить эти пакеты дополнительные больше сложности, именно большее количество артефактов. Причём он родился раньше, в то время, когда модели

61: Были ещё чуть более слабые и вот нужно нужна была большая жёсткость, соответственно, open спёк. Он вышел чуть позже, и он уже немножко предвидел, что такая большая жёсткость может быть избыточной и можно с меньшей жёсткостью меньшим.

62: Контролем меньше времени тратить на количество вычитку большого количества артефактов, достигать неплохого довольно-таки результата. И, наверное, 1 из его там киллер фич это 2 состояния. 1 состояние это то, что как обычно

63: Вернёмся назад. Как обычно велась у нас документация спецификации в конфлюенсе. В корпорациях 2 варианта. Либо мы описывали состояние сис и постоянно его патчили, либо 2 вариант мы там выпуска.

64: И они наслаивались. Вот у нас есть требования на изменение вот этого функционала и так далее. И вот, собственно, она как история в гите, да, условно у тебя были этот, и не было источника истины, и очень мало кто поддерживал сразу 2 этих источника, потому что, ну, это на

65: Ладно, с точки зрения человеческих ресурсов и чтз да и состояние и смерджить белковой нейронкой, да, так скажем а с приходом мишки как раз кажется это стало не так сложно, и open спекта взял эту киллер фичу, на мой взгляд, бай дизайн себе.

66: То у тебя есть вот эти вот чейнджи, которые, ну вот если очень там упростим, скажем, что это чётка, да, такая, частное техническое задание, если ты не сталкивался с термином, и есть состояние, когда ты выполнил, да, этот change,

67: Что он его мержит в main Спека, да, то есть в текущее состояние сис системы, на которое можно тоже всегда очень быстро положиться, и которым агент пользуется. И это удобный, хороший для него источник контекста. То есть у него, у агента теперь

68: Есть вот 2, 2 возможности, во первых, посмотреть эти чейнджи, что, зачем, когда вносилось и состояние спецификации требований сис сейчас, как вот источник истины менете, вот, наверное, основной набор причин.

69: Почему мы выбрали опа Сбер?

70: Знаешь, я сейчас че подумал, мы можем это продемонстрировать, ну, чтобы вот прям не рассказывать, прям пошарить экран и показать, может быть, на прям на гитхабе, в смысле, не ваш проект, а в целом, как? Там же, example, какой-то есть, может на твоём проекте. Угу.

71: Сейчас подумаю, посмотрю, да, минутку. А ты все сделал уже, да? Окей, начинаем. Угу. Да, собственно, примерно, давайте просто покажу, как это выглядит в проекте. Да, вот это небольшой, это внутренний портал.

72: Который мы там называем неон, который там отвечает, автоматизирует некоторые наши виды деятельности, там и некоторые вещи, там сотрудники могут зайти, посмотреть, сделать планирование какое-то у нас и разные другие штуки помогает сделать.

73: Как выглядит папочка опен Спека, да, вот, то есть по умолчанию вот есть 2 папочки ченджи и спеки. Вот чейнджи это как раз тот источник документации, про который говорил, это когда у нас каждый чейндж это папочка с набором изменений. Грубо говоря, каждая папочка такой четырешка отдельная котора.

74: И про бизнес, и про технологии и так далее. И есть папочка спеки, которая разбита, ну на капабилити можно как-то называть, где-то называть это доменами, какими-то, какими-то группами. Сейчас он последняя версия позволяет

75: Делать двойную вложенность, где мы там на каждый какую-то функциональность. У нас есть смежённая Спека, да, которую мы можем посмотреть. Но давайте вернёмся к чижам. Да, это вот такая основная единица рабочая, с которой, собственно, все работают.

76: И вот там вот, к примеру, фича, сейчас мы там делаем каталог продуктов внутри нашего портала, и какие здесь основные артефакты? 3 основные артефакты начинается это с пропосол Эмди, то есть когда мы работаем

77: Условно я в консоли пишу, в клоде опс икс прополз и с агентом я проектирую. Зачем я это вообще все делаю. Когда я спроектировал его, обсудил его с ним, он фиксирует.

78: Как артефакты. И вот самый главный артефакт это зачем мы это все делаем? Это какие там требования? Зачем мы это делаем, что изменится, что не является целями этой работы, что мы собираемся получить. То есть это вот такая бизнесовая штука.

79: В нашем понимании, это основной артефакт, который должны, над которым должны работать аналитики и продукты. Здесь он довольно-таки простой, потому что это опять же, проект не разрабатывается командой. На самом деле, там в большей мере, там его разрабатываю я и 1

80: Разработчик полного цикла. Я здесь как вот выступаю больше как продукт инженер некоторый такой, который и код пилит, и идеи придумывает, и мне помогает 1 из наших старших Ким Дедов делать какие-то штуки интересные фичи. Итак, мы сделали пропоз, пропоз.

81: Сгенерировался потом на основе него агент генерирует дизайн ди, это что-то типа адрки. Здесь как раз технические решения, что как происходит там модель данных, как это все должно работать вплоть до того, там, здесь мож.

82: Быть описано, какие компоненты могут быть использоваться и так далее. 3 важный файлик это tasks Эмди, это конкретный план работы агента. Это очень удобно, особенно, когда у вас ограниченный контекст или там можно начать рабо.

83: Работать на работе, продолжить дома без проблем. То есть необязательно хранить это. То есть не важно, чтобы вы там сохраняли какую-то сессию, вы можете сессию потерять, вы можете начать в 1 агенте закончить в другом агенте весь контекст у вас сохраняется внутри чижа и

84: В любой момент вы можете пойти и продолжить начинать какой-то следующий, другой пункт делать. Соответственно, вот примерно вот так план этот выглядит, он его довольно-таки низкоуровневый декомпозирует и по ходу работы, когда вы запускаете, выполнить команду выполнения опен спики, там

85: Команда он берет и начинает заполнять эти пункты. Следующая папочка это spooky, он их разбивает на капабилити, это, по сути, вот там функциональность, которая он будет конкретно затронута и в каждом.

86: Capability, он пишет требования, он их делает в виде гертина, вен зен, классические формат требований в таком виде спецификации очень удобно трассировать в тесты, то есть можно генерировать прям по нему.

87: Пирамиду Тестов, которая должна закрывать каждый из сценарий, который у нас здесь прописан как-то так, наверное, основа, она вот в этом после, то есть у нас, грубо говоря, следующие команды, да, то есть получается у нас вот там главная команда, это про

88: Где мы сгенерировали чендж. Следующая команда. Это у нас команда эплай, это выполнить. И 3 команда это архив, что делает команда архив. Она чендж переносит в пеки, она, точнее, сам чендж, она переносит в архиве, в архив. Здесь

89: Тут они архивируются, но она мержит как раз вот ваши требования в состоянии с x в спеке и, соответственно, у вас получается так, что у вас вот это вот состояние s x, состоящее из всех спёк, оно вот здесь, если вам нужна историческая какая

90: Эта информация по прополза, по чижам, то вы можете зайти в агент, может зайти в архив. Опять же ручками мы гораздо Реже это заходим, это в 1 очередь мы строим весь контекст для агента это такая самая база основа.

91: Конспекта. Ну, наверное ещё можно, стоит упомянуть про скил эксплор. Это вот что-то такое, чуть более облегчённый вариант гримми. Он немножко по другим принципам работает, но смысл примерно такой. Это вот формат брейншторма вместе с вами. Где он

92: Задаёт разные вопросы, рисует схемы, проектирует вместе с вами, и он может быть опциональным, да, то есть когда вот у вас особенно там идея довольно-таки сырая, и он хорошо с вами поштормит. И по результату его работы он предложит вызвать скилл.

93: Проползу, скажеть. Кажется, мы все проработали, как бы, если у тебя нет вопросов, давай мы сделаем прополз. Я говорю, да, давай все делаем пропос, там фиксируем эплай и так далее. Вот это самая основа. Понятно, что у нас на самом деле, когда мы работаем в команде, там интерпрайс наших клиентов, у нас там набор команд, он шире.

94: То есть там есть разные дополнительные нюансы, о них может быть чуть позже мы как раз поговорим как-то так. Ну, кстати, я тебе хотел сказать, что поскольку я пользуюсь скиллами мата, они же тоже там постоянно меняются и добавляются. И у него сейчас недавно было вот прям очень серьёз.

95: Апдейт и там вот то, что export ты называешь, это сейчас не грил ми, это вайфайндер называется. Это там прям описано, что он используется при тасках, которые невозможно там закрыть в рамках 1 сессии бла бла бла. Там есть такое описание короче, когда он составляет некую такую карту вижн.

96: Много исследований, и на базе этого генерирует ишью, и к нему цепляет ещё много, ну, поднаправлений, если они там есть, потому что эта штука может цеплять как бы вообще все подряд. И я, кстати, это интересно, получается, у мата оно использует, знаешь, что оно использует ту систему?

97: Которые у тебя есть. То есть он в начале тебя опрашивает, типа, ты где хочешь? Ты ему говоришь, например, на гитхабе, он говорит, окей, он использует определённую систему лейблов, плюс использует фишки самого гитхаба, чтобы строить зависимости и так далее. И в конечном итоге у нас сейчас там вот просто вот

98: Такой огромный объём ишьюсов, который он генерит без остановки, там есть карты, там есть grilling, и он все это как бы помечает. И удобно ещё то, что любой может, как бы там есть даже такой, у него классное скилл, который называется аск мат. Она тебе говорит, типа, что дальше делать? Либо в

99: Текущей сессии, либо ты говоришь аск мат, посмотри, че там в вышлюа надо. И он такой скажет, смотри, вот там, типа вот эту штуку можно сейчас грилить. Вот эту нужно доработать на wayfinder проделать. А вот это уже реди ту эйджент можно брать в работу. А вот это надо в тикеты превратить. У тебя из Спека? Ну,

100: Как бы вот такой примерно процесс может там происходить. Вот мы можем показать. Кстати, вот давай, если это возможно, propose, прям запустить, посмотреть, как он спрашивает. Просто интересно, я почему хочу, чтобы это люди увидели 1 из же важных факторов работы в этой системе, что ты

101: Ты сам ничего не пишешь, все, по сути, сводится к вопросам. Это довольно прикольно, потому что это намного проще, чем думать о том, что, блин, мне придётся писать спеку, там все это делать не придётся. Он ведь не только тебя спрашивает, он же исследует кодовую базу, берет весь конте.

102: Это очень важно, да, это сильно облегчает ему работу. Ну, соответственно, вот как раз больше он задаёт вопросы именно в режиме эксплоре. И сейчас давайте что-нибудь здесь. Давай сделаем раздел, не знаю.

103: Github. Да, условно. Ну, понятно, что здесь ты большое описание какое-то будешь составлять здесь он будет сейчас проводить анализ. Угу.

104: Всегда, часто я в программном комитете большого количества конференций, и когда говорят, давайте мы сделаем какой-нибудь интерактив и будем показывать работу агентов, я всегда говорю, что это максимально скучно, потому что ты сиди, вы cd.

105: И там втроём. Смотрите как агент что-то делает. Это вот такой некоторый куколдинг это, это, это не очень динамично и нужно постоянно развлекать слушателей. В этот момент ты не поверишь я же делал 2 мастер класса на

106: Как раз, да, мы где-то там в параллель выступали, и я, и у меня был он двухчасовой, и я понимал, что я не смогу как бы вот в таком режиме людям показывать, потому что ты его запускаешь, и ты, поняти, не имеешь, сколько он там будет работать. И тебе реально нужно развлекать. И у меня в итоге это просто в стендап превращалось, потому что

107: Там запустил и с людьми просто разговариваю. Да, я до сих пор не научился этого делать. Я не знаю, как правильно. Ну, то есть реально вот показывать работу интерактивную с агентами, это, это скучно. Поэтому вот в некоторых докладах, которые там ребята готовили, они просто

108: Так, говорит, просто чекаут делали. Следующий говорит, так, смотрите, я сделал, вот он сделал, он сделал следующее. Вот такие артефакты, он, да, да, да. Типа того. Ну, я единственное, что хотел не пройти с тобой полностью, этот путь, очевидно. А дойти до точки, когда он начнёт задавать вопрос,

109: Прям увидеть вот этот процесс, потому что это будет, ну, как-то поинтереснее. Другой вопрос. Мы не знаем, сколько времени он сейчас вот будет заниматься тем, чем он занимается. Ну, окей, давай, пусть он занимается, мы как бы его оставляем. Окей. То есть, вот есть понятный процесс, есть историчность, есть спеки, много довольно документов.

110: И так далее. Там много вопросов из этого вытекает. Но давай сначала поговорим про опшен. То есть, когда вот у тебя конкретная компания, вот конкретно ты это посмотрел, поттер такой ручки и говоришь, так, ребята, с завтрашнего дня работаем по open спёк. Вот расскажи, как это начиналось и как ты этот процесс делал, собственно,

111: И с какими проблемами сталкивался? Ну, начали мы просто с того, что ребя дали разработчикам. Он говорит, ребят, вот это, наверное, ещё до, наверное, стратегического решения, что мы 100% вообще полностью все на него будем.

112: Ходить. Мы просто нашим членам ий клуба пару слов о том, что такое l клуб, это мы ещё в середине 25 сделали небольшую группу. Позвали ребят, которые идейные, которым кайф, это которые мы там Собира.

113: Там раз в 2 недели примерно сейчас чуть пореже собираемся, и мы там, вот там какая модель вышла, какой агент, что нам, что зашло, что не зашло, ресерчили на каком там, не знаю, стеке, мы хотим работать, чтобы это там не было полностью.

114: Вообще, что каждый на чем-то своём работает. И, собственно, вот он, в том числе этот клуб нам помогал в своё время адопт ребят, то есть мы, к примеру, ребята, которые сомневались, что это работает. Мы просто в парное программирование ставили кого-нибудь члена этог.

115: Клуба, и он помогал кому-то заддоить. Я для того, чтобы понять, что вот там садился на конкретные задачи, показывал. Вот твоя задача. Давай мы сегодня делаем её с агентом. Вот видишь, она работает. Теперь ты попробуй пробуй. Нет, не руками код пишешь, нет, с агентом вот садишься и вот собственн.

116: Таким образом, ребята, адаптил сь и собственно, ребята из клуба, там разработчики начали тестить просто именно в рамках функции, да, в рамках разработки, вот как разработчик садился, писал себе спеки из spec аналитик, да, то есть аналитики там.

117: В конфлюенсе по прежнему ещё тогда работали преимущественно из этого он агрегировал какие-то артефакты, именно спеки и, соответственно, работал это вот то, с чего начиналось потом, вот когда мы в новом году, как раз после стратсессии, когда мы поняли, что нам нужно все-таки рейк расширять на

118: Всю команду, чтобы это была общая вот эта шина контекста у нас было месяца месяц или полтора брейншторма с аналитиками. Это вот где-то в феврале, там встречались 1, 2 раза в неделю. Мы когда говорили,

119: Что, товарищи аналитики, теперь вы должны будете писать спецификацию не в конфлюенсе, а агентами в репозитории. Ну, это большое такое, на самом деле значимое изменение в процессах, да, оно затрагивает много чего.

120: Его, потому что и заказчик может хотеть артефакты в некоторых проектах ещё до сих пор в конфлюенсе, да, то есть и в некоторых случаях это требование договора, что у нас там должны быть эти артефакты в принципе, сам pipeline работы нужно было вот туда.

121: Перестраивать потому что опять же бывает бизнес может ходить в confluence, задавать вопросы как он будет делать это в новой реальности и там вот прям очень большой Пласт вопросов мы обсуждали, думали как наверное вот это такой был самый такой сложный такой brainstorm.

122: Этап прежде чем мы продумали примерно как действительно аналитики вот в это все будут перестраивать свою работу после этого мы начали запускать пилоты с аналитиками и параллельно начали думать, что как работать с k с que мы здесь изначально.

123: Думали, что вот как приходит аналитик, запускает, условно прополз разработчик условно только эплай, и у тестировщика, который у него там тоже свои будут скилы, которые он запускает для того, чтобы там написать тесты и так далее. И 1 из таких

124: Который мы получили где-то в апреле, что вот эта вот идея, то что тестировщики должны приходить писать автотесты, она мёртвая, она неэффективная, потому что агент должен писать автотесты сразу, в том числе, ну он их может делать.

125: И в рамках своей реализации он должен их сразу писать, сразу же их прогонять, и они сразу же должны выполнять эту функцию, как раз прогонять эти автотесты. Они дают сразу цикл, задают ему обратную связь, где что-то пошло не так, а разрывать это на

126: 2 Роли это, ну просто, а зачем это больше потерь и так далее. Поэтому мы в какой-то момент поняли, что где умирает роль автотестов, тестировщиках, вот примерно в этом месте, да, то есть действительно это, это такое.

127: Понимание, что действительно на рынке, даже, скорее всего, именно тестировщики, которые пишут автотесты, на мой взгляд, будут нужны меньше, потому что, действительно, теперь это должна, скорее всего, делать 1 роль, просто потому, что так процесс эффективнее строится. Это вот такой прям 1 набор.

128: Problematic, который мы столкнулись, которую мы начали решать, соответственно мы начали с определённого количества проектов, наверное замедлилась адаптация dd у нас, скажем так, мы внедрили его где-то в мае, где-то на половину проектов, скажем так.

129: Вот на половине проектов начали экспериментировать для того, чтобы с этим работать. И здесь у нас просто пришёл очень крупный важный государственный проект, который с очень сжатыми сроками, и аналитики этого проекта справедливо сказали, что, ребята, мы не хотим идти

130: Эти риски сейчас с переработкой принципов документации пришлось сказать, пойти у них на поводу и сказать, что хорошо, ребят, мы не запускаем на вашем проекте cd, понимаем, ну там реально очень большая горячка была. Оглядываясь назад, я не уверен, что мы поступили правильно.

131: Возможно, все-таки нужно было это делать, потому что разработчики то все равно писали аишкой, им не хватало спёк в формате, который бы лучше воспринимался агентом, разработчики начали на этом проекте open спёк использовать без аналитика.

132: Шаря спики между фронтом и бэком в каких-то случаях. Точнее, вот даже до того, как это они дошли, они начали делать спеки. Каждый свою бэк свою пишет, фронт свою пишет. Это 1 же ошибка, наверное, которая там очень быстро всплыла, то, что спики расхо,

133: Да, то, что 2 агента в 2 сессиях фронт и бэк по разному. Даже несмотря на то, что это контрактное описание, бизнес логику они по разному интерпретировали. То есть мы вот тут же поняли, что она должна быть единой, ни в коем случае не должна разделяться Спека между

134: Фронтом и бэком, потому что это как бы мало того, что дублирование тебе вот смысла, бизнес смысла, да, для чего вы это делаете? Они у вас дублируются зачем-то, так они ещё и разряжаются и по разному интерпретируются разными моделями. Потом, когда это сшиваешь, возникают там

135: Набор некоторых проблем, поэтому они начали делать общие ченжи между фронтом и бэком. Там у нас тоже как бы не все гладко пошло. То есть вот не хватало как раз вот, чтобы аналитики к этому моменту подключались. Ну вот там на, на, в середине процесса опять же, очень

136: Очень крупного большого проекта в сжатые сроки не могли мы себе позволить прям всех аналитиков перевести. Там нужно ещё и на заказчика то некоторые вещи завязаны. Поэтому проект, он там сейчас подходит потихонечку к своему завершению. То есть это там

137: Федеральный конкурс, федеральное мероприятие для школьников, скажем так, сейчас уже потихонечку ребята, которые переходят с этого проекта, который идёт к концу, они вот погружаются. И я надеюсь, там в ближайшие пару месяцев мы сможем сказать, что у нас действительно

138: Те 100% проекта перешли на ssd, как-то так ответил на твой вопрос давай дальше копать вглубь, расскажи про монорепу, потому что как бы переход на файлики это не просто раз и сделали.

139: Да, потому что у тебя бывает, что проект состоит из большого количества подпроектов и тебе нужно сервисов там, да, и тебе нужно как-то все синхронизировать. Расскажи про концепт, как с этим правильно работать в современном мире. Собственно, проблема нюансов, да, то есть на внедрение диди.

140: Которая по факту для нас внедрение, и в том числе сквозного по сквозным процессам много. На самом деле таких кейсов нюансов породило. Вот. А что делать, когда у тебя не 1 репозиторий с монорепой, где у тебя и фронт, и бэк делает. А когда у тебя

141: Есть несколько сервисов или есть монолит, и как бывает очень часто есть большой монолит, и вокруг него пачка некоторых сервисов. Ну вот, конечно, начинали мы, в том числе с простых проектов, где действительно монорепа, и там агент очень себя хорошо чувствуе.

142: Это вот у нас есть несколько продуктов международных, там с многомиллионной посещаемостью и с монорепами. И там он отлично, хорошо себя очень опен, спёк чувствовал, делая сквозные какие-то изменения, что делать с вот большим монолитом

143: Когда у тебя есть монолит и несколько разных сервисов, которые прям реально разные домены, но иногда у них очень сильная связанность, допустим, админка монолита может управлять вот этим вот сервисом. Ну вот так вот исторически сложилось. Нам так передалось в проекте.

144: Ошибочно мне, на мой взгляд, то есть брать и разбивать это на разные спеки в каждом репозитории, потому что иногда у тебя приходит сквозная сквозное изменение бизнес функциональности. И вот в том числе с точки зрения аналитики,

145: Да, то есть у тебя 1 1 спецификация, которая затрагивает, описывает все это сквозное изменение через несколько спёк, через несколько репозиториев, сервисов и так далее. И надо было это как-то проблему эту решать и доставать вот эти спеки из выделенных сервисов.

146: В какой-то общий вид, че мы придумали, мы сделали мета репозиторий, вот это эволюционно к нему пришли, в том числе это ещё в рамках брейнштормов с аналитиками. В феврале, тире, марте, месяце создали этот мета.

147: Репозиторий, и в него просто там команда make up, он клонирует все дочерние репозитории всех проектов, при этом папка опен спёк, она оказывается на самом верхнем уровне, и она получается, и агентом ты управляешь именно само с этого самого верхнего уровня в то,

148: В том числе мы такие, ну раз уж у нас для как бы спех это общая папка, давайте мы, в принципе весь харнесс будем класть на верхний уровень в agency, мы прописали описание, вот что условно, что, какой репозиторий, какая.

149: Под papa к чему относится и ну, в общем, если очень грубо сказать, мы действительно вот этим мета репозиторием мы превратили все свои вложенные репозитории, все сервисы и в том числе репозитории монолита в 1 общий, в 1 общую монолит, да, такую искусственно.

150: Созданную, но позволяющую иерархично агенту во все сервисы ходить и внедрять сквозные бизнес изменения, что избавило нас от необходимости, от большого количества проблем, от необходимости описывать агентов.

151: Дублировать бизнес, логику, мотивацию. Почему это делается в каждой из отдельных реб, когда у тебя сквозные изменения. Вот примерно так. А с точки зрения внесения изменений, то есть это стандартно пулреквесты сохранением обратной совместимости

152: Там, не знаю, порядок применения, какие-то правила особые задаются на верхнем уровне. Ну, у тебя в любом случае, от того, что их засунул, вот в такую, можно сказать, монорепа, мета, репа, да, то есть, которая, ну, эфемерная, можно такое слово использоват.

153: Это не означает, что у тебя все стало релизиться как единый монолит. То есть ты, когда вносишь изменения, у тебя может быть пулрквест. Тут, тут, тут они как бы связаны, но они в разных местах, и у тебя есть разный порядок деплоя, опять же, та же самая независимость, ради которой эти сервисы и вводились. Соответственно, видимо, должен быть ещё какой-то набо.

154: Правил или это естественным образом получается? Ну, естественным образом получается, да, то есть, ну, грубо говоря, как такие изменения были раньше, да, то есть, когда у тебя действительно нужно было внести изменения функциональности этого, эта проблема уже была решена, да, то есть слов

155: Ручным способом, да, то есть мы не автоматизировали это, в принципе, это не автоматизировано и до сих пор потом, ну, как бы условно на решение тимлида, он там определяет порядок деплоев, как, что должно задеплоиться. Нужный день x. Условно, когда

156: А мы это релизим на prod как минимум ну мы понимаем что умная иишка, она как бы сама предлагает это она такая нельзя, а то сломаем да, то есть у нас иишка, у нас есть скилы, которые там деплоят, это на тестовый стенд и на этот стенд и та.

157: Можно задавать в скилле в том числе порядок деплоя, хотите расти как разработчик, не в одиночку, а вместе с сильным сообществом вступайте в хесед клуб это закрытое пространство для тех, кто уже в профессии хочет развиваться дальше здесь помогают определить уровень, построить персональный план развития и дают обратную связь.

158: Есть менторы из индустрии, в том числе из зарубежных компаний в клубе живые разговоры о технологиях, собеседованиях, работе в компаниях, карьерном росте и networking, есть отдельные топики с историями участников, отзывами о работодателях, отчётами менторов и планами развития люди приходят в клуб, чтобы расти.

159: И помогают другим делать тоже самое. Кстати, знаешь, не могу не задать такой гипотетический вопрос. Вот нас слушают сейчас ребята, да, и такие, ну вам классно, вы там с клодом все сидите, и он за вас там все решает. А вот те, у кого не клод, а квены шмены, че там ещё сейчас?

160: Локально ставится. Как ты думаешь, есть ли вообще у них теоретическая возможность без дополнительного харнесса? Вот в чистом виде, так начать работать или этой штуке нужно будет слишком много объяснять и направлять её этой штуке. Это какой это open спеку в смысле или чему модель?

161: Которая будет использоваться, я имею ввиду, не топовая модель. То есть, если они взяли квн, если они взяли дипси, ну, короче, че то такое, вот, что можно поставить локально, а мы начали, начинали работать с спеком ещё в конце прошлого года, да, то есть, и уже тогда было видно, что он не

162: Плохо справляется, это лучше, чем работать другим способом, да, то есть, если мы сравниваем работу бессистемно, без единой шины, не сквозным образом, да, то есть и с песпе, да, то есть в рамках 1 модели, то мы понимаем,

163: Что испёк уже тогда приносил пользу, на мой взгляд, как будто бы сейчас все эти квены, дипики и так далее. Ну, состояние клода осени прошлого года, мне кажется, они плюс минус уже достигли. Вот, и

164: И поэтому, на мой взгляд, опен спёр здесь будет помогать в том числе слабым моделям, давая ему чуть более жёсткие границы. Опять же, ну как бы, чем слабее модель, тем жёстче должен быть харнесс, да, как минимум, который будет держать её в

165: И направлять, позволять меньше ошибаться, скажем так. Угу. Ну, то есть, глобально в целом, наверное, можно сказать, что в течение года проблема будет решена, и от того, что у нас локальные модели, мы не будем испытывать. Ну, те, у кого они стоят, они не будут испытывать больших пробле.

166: С тем, что оно там тупит, не задаёт вопросов и вообще идёт не туда, правильно я понимаю? Ну да. Ну слово локальный. Тут иногда некоторые воспринимают как локальный на компьютере, да, то есть локальный, мы имеем ввиду, в это может быть какая-то и большая модель на внутренних производственных мощностях, потому что я не уверен.

167: Он премис, давай модель. Да, да, он премис модель. Да, потому что локальные, которые у нас на компьютере, я не знаю, когда они вот прям до такого хорошего уровня могут дойти с нашим небольшим объёмом памяти на наших локальных устройствах. Да, правильно, тогда он

168: Будем говорить. Хотя, наверное, когда-то дойдут и такие, при том, что ты более менее рассказал, но мы не поговорили прям о конкретном процессе. То есть вот как конкретно поступает задача, в каком виде, кто её берет, какую команду выпускает? Есть ли тут при этом тикетница, как он передаёт дальше можешь пря,

169: Вот рассказать весь пайплайн и сложности, которые возникают на разных этапах, да, сложности, на самом деле, вот таких вот маленьких интересных сложностей. Во всех случаях их прям хватает. Ну и они бывают достаточно индивидуальные, в целом, отно.

170: Процесса. Сейчас чуть чуть в сторону, прежде чем отвечу на твой вопрос, собираемся. У нас такой маленький диди комитет раз в неделю. И вот реально раз в неделю от часу до полутора у нас идёт эта встреча и мы какие-то кейсы. Ну она, конечно, сейчас там

171: Не знаю, процентов 30 занимает это то, как нам развивать наш харнесс, какие точки развития мы обсуждаем, да, еженедельно, но действительно, во многом мы разбираем какие-то нюансы, кейсы, которые нам позволяют там это сделать. Мы даже сделали свой отдельный сервис.

172: Которые показывают трассировку чейнджей. То есть мы, грубо говоря, на этой встрече мы открываем этот сервис и там он собирает эту информацию с репозиториев и показывает, какой каждый чендж у нас происходит, в каком он состоянии его можно просмотреть.

173: Можно посмотреть трассировку коммитов на ченджи. У нас 1 из метрик, которую мы сейчас смотрим, это то, чтобы каждый коммит у нас был подписан ченджем. Это нам важно для того, чтобы в том числе агент на это мог опираться. То есть, условно, он когда заходит в код, когда ревер

174: Что-то смотрит, а что, а почему здесь это происходит он может просто по гиту посмотреть что это за коммит и какой коммит ссылается, на какой change и понять то есть смысл а там там найти файлик прополз то есть чем это отличается у нас есть и task id, но в task id там нужно

175: По цепочке было идти в confluence, идти ресерчить, а тут тебе сразу конкретный кейс на change, там у тебя все смыслы, почему это было принято и на уровне технического дизайна, и на уровне бизнесового Смыслов. В общем, это довольно-таки классно работает. В общем, через него мы смотрим трессировка, да, это

176: Про то, что действительно кейсов прям много очень интересных возникает в процессе работы. И там я, я пока не могу сказать, что вот когда это будет идеально работать, ну примерно тогда же, когда мы идеально вообще все процессы во всех компаниях будут работать, примерно тогда же, возвращаясь назад,

177: У нас сейчас в среднем работает любая задача. Ну то есть, опять же, клиент у нас чаще всего сейчас берём не продуктовую нашу историю, да, там, где продукт взял, сформировал требования. Хотя, давайте, давай, давай, давай сначала с простого примера. Вот наша продуктовая команда наш, где продукт

178: Это делается продукт, мы ему дали возможность делать спеки. Продукт делает эксплор, штормит ботом, делает прополз, формирует вот этот change, но верифицирует в 1 очередь именно файлик прополз, вот в дизайн он вообще может не лезть, иногда он может полезть

179: Захотеть что-то посмотреть, что-то там поменять, но в целом говорит, мы вот твоя зона, это propose, дальше ты не смотришь вообще как-то это детали реализации. Дальше он делает задачу. Ну, собственно, если задача из discovery приходит в деливери, в деливери, в задаче

180: Конкретно указывает имя чейнджа, который у тебя он есть, он его пушит в main ветку репозитория разработчик, когда подключается к этой задаче в продуктовых командах. У нас в большей мере универсальные разработчики, хотя есть там, где и фронт, и бэк, разработчики подключаются к этому ченджу и

181: Начинает работать. Давай раскрой здесь. Что делать, когда у вас фронт, бэк. То есть и вообще изначально вся эта движуха с аишкой, она гораздо лучше работает, когда у вас 1 фулстек, инженер, который отвечает и за то, и друго.

182: Но как бы реальность такая, что мы сейчас вот не можем взять и всех вот так вот щёлк. И завтра вы все full stack, инженеры это некоторый процесс, долгий переобучения людей и изменения Майсет и всего остального, поэтому

183: Мы делаем так, что в skill агента, мы в proposes задали инструкцию, что ты должен разбивать работу фронтендера и бэкендера в дизайн льдин, соответственно, бэкендер фронтендер, когда подключается, они выполняют именно свои пункты агента, то есть они говорят о своих.

184: Play сделай фронт уиппла, сделай back и соответственно, выполняет только свой набор пунктов. Таким образом мы разделяем работу между фронтом и бэком. Опять же, это, ну, некоторый костыль, да, объективно, потому что процессы и там 10 лет последнего разви,

185: Из веб мастеров сделали нас фронтендеров, бэкендеры условно, поэтому как бы сейчас вот будут назад схлопывать, но пока мы этого не достигли, у нас есть такой костыль, ребята делают это, проверяют свою работу, деплоят, тестируют.

186: Соответственно, у нас продуктов в продуктовых наших командах нет, и диплоид показывают заказчику продукту. Продукт проверяет и диплоид. Это на прод. Опять же, после этого, после диплоя на прод происходит архивация. Ты архивируешь спеку для того, чтобы работать дальше с другими.

187: Тут, кстати, важный момент, что здесь важно, это как подчищать старые фича флаги, так и делать эту архивацию, потому что когда у тебя висит большое количество открытых спёк, у тебя больше шанс конфликтов, потому что потом в каком правильнее, в правильном порядке их мер.

188: Ты можешь не в правильном порядке могут конфликтовать, может агент не учесть все конфликты открытых спёк, потому что он заточен в 1 очередь смотреть именно на main спеку, смотреть на конфликты, потенциальные точки развития именно с ней. Хотя, опять же, вот работа.

189: Мы себе можем позволить работать с топовыми моделями. Во многих проектах, в большинстве проектов, он замечает, не забывает это проходить и по текущим открытым ченджа у него, то есть есть такие вот, то есть установки, и в принципе, он находит, но все-таки, когда прям слишком

190: Много. У нас прям был кейс, когда он не учитывал проблемы, которые есть в соседнем ченже. Вот. Поэтому мы, в том числе сейчас, когда там у нас несколько ченже из них цепочку делаем о том, что ты, ты не можешь запуститься раньше, чем этот, и так далее. И, соответственно, иногда ты, кстати, из эксплорера я, кстати, не упомяну.

191: Ты не обязательно делаешь 1 change, эксплор говорит, что я тебе предлагаю сделать 3 разных ченджа и, соответственно, декомпозировать работу таким образом, причём сделать их строго в такой последовательности, и в том числе сам пропишет эти зависимости. Вот это как работает.

192: Команде в проектах заказной разработки, которые у нас есть, когда мы, как интеграторы выступаем, роль продукта у нас здесь меняется на роль аналитика. Продукты зачастую находятся на стороне заказчиков. Ну и мы вряд ли, когда, ну, в ближай

193: Время сможем прийти к Такому, что переучить продуктов заказчиков, работать с аишкой на таком уровне, чтобы получать синергию с нашими разработчиками. То есть это такой непростой уровень, это тот момент, когда

194: Я понимаю, что роль аналитиков в заказной разработке, она останется ещё долго, Ровно, потому что не всегда компетенции продукт на стороне заказчиков, там позволяет достаточную глубину. Во первых, хорошо, правильно все формулировать, правильно ресерчить, правильно проектировать.

195: И работать с в агентском пайплайне современном, так как работаем сейчас внутри у себя мы, поэтому это аналитики и аналитики. В этом случае у нас пишут пропос. То есть условно они сделали интервью с заказчиком, с клиентом, собрали с него требования, эти требования.

196: В сыром виде, да, там интервью передают, закидывают в агента, в тот же самый эксплор, проектируют этот прополз и передают это разработчику. У нас в какие есть такие интересные нюансы, есть скилы, например, вот как раз разработчик сейчас это. А сейчас мы это вшили, мы это вшили.

197: И в прополз у нас в рамках прополза проектируется в том числе, 1 дополнительный файлик тестовой стратегии, которая трессируется, сценарии Геркина на пирамиду тестирования и говорит, каким видом тестирования нужно будет.

198: Покрыть каждое требование. Это позволяет не дублировать где-то тесты, чтобы тесты там, к примеру, на разных уровнях у нас не покрывали одно и то же. Да, к примеру, что мы не на юнитах и интеграционных нтм не делали. Все тоже самое позволяет сократить количество нтм Тестов, которые

199: По прежнему остаются дорогие, несмотря на то, что, конечно, кратно проще, чем раньше, да, нтм, тесты сейчас даются, тем не менее, они могут гораздо чаще, и флаке могут быть и так далее. Поэтому юниты интеграционными, где есть возможность закрыть ими, это замечательно.

200: Поэтому мы это используем, не открываем спор, там, пирамммида или кубок, по моему, на 1 проекте у нас больше кубок идёт, а на другом проекте пирамида. Это, мне кажется, ещё от проекта зависит какие-то у нас ещё дополнительные артефакты есть, есть артефакты документации.

201: Что должно быть ещё по итогу смержено в документацию пользовательскую и есть ещё артефакты дополнительные в рамках ченджа у нас формируются для того, чтобы закрыть формализованное требование заказчика.

202: По освещению и подписыванию некоторых моментов, для чего это нужно? Потому что потом аналитик для того, чтобы показать заказчику, он берет этот change и экспортит отдельным скиллом в confluence вот именно в том виде в виде шаблона, который

203: Нужно именно заказчику. Также есть ещё дополнительный файлик юзкейсы. Тут у нас была такая интересная история, когда мы заходили в марте в open спёк с аналитиками. Аналитики говорят, блин, вот Геркин, он хуже считается, чем юскейсы. Вот.

204: Кейсы проще читаются человеком. Давайте мы переделаем на юскейс. Мы такие, да, в принципе, давай попробуем. И мы перепилили скиллы опен Спека так, чтобы они делали именно в формате юскейсов, и откатились назад. Почему?

205: Потому что мы поняли, что автотесты как раз трессировка в выполнении. И вообще, в принципе, автотесты, именно Герцен ложится намного лучше. Поэтому, да, здесь пожертвовали чуть чуть читаемостью относительно человека.

206: Spec, но получили лучшие трассировку в тесты, которые у нас есть. Дальше там разработчики передаются. Все тоже самое. Там у нас фронтбэк, разделение в большинстве проектов заказной разработки у нас там практически нет, и там некоторые скиллы

207: Диплоя тестировщики сейчас, отходя немножечко от автотестов, хотя они сейчас в некоторых проектах все-таки приходят и такие говорят, а вот мы, как люди здесь заметили, что здесь автотесты можно сделать, улучшить, и они могут в том числе вносить

208: Изменения в автотесты, но опять же, основной цикл все-таки автотестирования закрывается в эплай именно разработки цикла. То есть они могут внести какие-то изменения в автотесты, могут дописать свои какие-то автотесты, то что вот они подумали и сказали, что вот мы ещё вот такой хотим придумать условно автотест

209: Который там автоматически это закроет. Они ещё вот так вот, ну, скрупулёзно и не до конца доверяют нашему агентскому пайплайну. У них есть некоторые скилы, когда они проверяют отдельным агентом корректность наших спёр, да, то есть точно ли там у нас нету расхождения.

210: И были случаи, когда даже какие-то случаи находили эти вещи. Да, кстати, там разработчики в конце цикла разработчиков, у них есть ещё ревью. Раньше он у нас был в репе, сейчас он есть, в, мы его замкнули локально, потому что, ну, нет смысла.

211: Там пушить куда-то в репозитории, там запускать агента ревью, чтобы и так далее. Проще локально. Ты цикл ревью пройди, а потом уже запуши уже чистую версию. Условно после работы тестировщиков уже показывается заказчику. Соответственно, приёмка, если есть.

212: Замечания и там диплей. Ну вот примерно так писал весь цикл.

213: Да, у меня тут много вопросиков по пути возникло. Давай начнём, наверное, с продуктов. Есть такое мнение. Ну, понятно, что у вас заказная разработка, но когда речь идёт про продуктов, да, во первых, судя по тому, что ты говоришь, если бы это был не заказной проект, а

214: Product был на вашей стороне, который участвует, он должен быть довольно техническим чуваком, чтобы не только конлайн, м, пользоваться, но и, по сути, даже вот когда ты показал этот propose, он все равно какие-то технические детали туда включает, и получается, что он должен, ну, хоть как-то понимать.

215: Эту тему правильно я понимаю? Смотри, то есть задача работы именно продукта чуть в сторону. Я считаю, что понимание там, чтения, Гита, работы с агентами, работа с гитом.

216: Это база для любого офисного сотрудника современности. То есть вот как раньше, не знаю, там, ты че там, браузер, эксель вора должен знать, сейчас ты должен, помимо этого, агентов и гид знать. Это вот маст хэв. Мне кажется, без этого сейчас прям никак.

217: Тем более, если ты продукт. Поэтому вот у нас там коллеги иногда говорили о, давайте мы упростим так, чтобы коллегам не пришлось использовать агентов и гид у себя там локально, где-то и так далее. Ты понимаешь, что они там строят замки для того, вместо того, чтобы

218: Решить вопрос небольшого самообразования, который прям людям очень сильно в дальнейшем поможет. Поэтому люди должны писать скиллы, работать с этим и так далее. Поэтому продукты с этим работать могут, могут работать с, я не уверен, что они работают.

219: Знаю, они, по моему, не с консольным работают, не с cloud кодом они работают с аппами, да, с эпом. И, по моему, там они там скиллы запускают и нарики, по моему, у нас тоже не все с cloud кодом работают. По моему, там половина точно работает с эпом и там гоняет.

220: Насколько я знаю, и вроде как бы нормально все у них получается, читаю насчёт чтения в proposes, мы стараемся, чтобы туда протекало минимум технических деталей, хотя иногда технические детали туда некоторые протекают, мы стараемся это уменьшать.

221: В том числе, был такой недавно буквально запрос, что действительно вот получился какой-то слишком технический чейндж в propose. И почему бы это не выносить все больше в дизайн для того, чтобы вот оставлять больше технических Смыслов туда, и мы, возможно, даже чрез

222: Корректируем сейчас скилы для того, чтобы действительно чуть меньше протекало. Хотя, ну как бы сейчас как это решается? Просто если есть технические детали, ты за них можешь не вникать, ты на них не отвечаешь, за них отвечает разработчик, когда он приходит, принимает этот change, и он в том числе отвечает за то, что в любом случае

223: Учитывает весь пропос и валидирует все технические детали. Есть мнение, что наиболее эффективный путь во всей этой цепочке пи диэлси, скажем так, да, это когда product не просто готовит какой-то

224: Базовое там описание в каком-то виде, в зависимости от фреймворка или подхода, который ты используешь, а прям делает прототип, который уже потом передаёт. Дальше че ты об этом скажешь? Да, да, да. Ну здесь как, как это делается, продукты сейчас возьму продуктов сначала.

225: В клоде они запускают скилл. Сделай мне прототипы, и клод делает сейчас эмэль прототипы, который сам заливает в своё облако, которое может показать, который в том числе на самом деле пойдёт в дизайн систему, возьмёт даже твои типы стилей. Но пускай он верхнеуровнево по блокам.

226: Разложит, как это все примерно работает именно с точки зрения, там просто файл как страничка выглядит, там даже какие-то компоненты будут частично работать у аналитиков примерно такой же. Вот у аналитиков есть свой скилл, который они пошарили через свой репозиторий, дополнительный, внешний, и сейчас они в том числе

227: В наши репозитории общих Скилов, которые переиспользуются на всех основных проектах заказчиков, которые они запускают, и генеру свои прототипы, там с некоторыми своими нюансами. Это вот то, что у нас сейчас с точки зрения прототипов используется. Я знаю, что был доклад

228: У коллег на подлодке, по моему, было аишный клюшно, как раз открытой, причём сессии ребята рассказывали про и open, спект тоже используют, и они говорили, что вообще делают в отдельном репозитории полноценный рабочий прототип.

229: Причём не обязательно они делают со спеками, потом отдают это разработчиками. Разработчики просят. А теперь отреверсь мне этот проект в open спёк и брали контрол ц контрол в эти спеки переносили в свой основной проект и теперь по этим спекам реализую уже вот в этом проекте, опять же обновив, конечно.

230: С учётом того, что у неё теперь новый источник контекста. Вот слышал такую практику, мы не пробовали пока что так. Угу. Ну, в любом случае, все идут в то, чтобы не просто продукт дал какое-то описание, но и че то показал и дал. Да, у нас вот именно с точки зрения аналитики,

231: Сейчас почти всегда, когда там собрались требования заказчика, они сейчас всегда делают какой-то прототип, чтобы заказчику показать это очень сильно ускоряет согласование процесса. Все так, соответственно, и продукты у нас тоже приходят часто с каким-то

232: Прототипом к ребятам из продуктовой разработки, когда у нас в цикле внутри YouTube не единственное место, где можно получить пользу от организованного программирования, также я пишу про обучение, разработку и технологическое предпринимательство у себя в telegram канале и вконтакте там я публи.

233: Бережно написанные руками посты пару раз в неделю. Только мой личный опыт без новостей, без кликбейта и Нерослова. Будьте организованны, подпишитесь. Ссылка в описании. Хорошо, тогда следующий вопрос. Мы поговорили о том, как происходит передача, но

234: Есть ситуации, при которых нужно вернуть обратно и доработать, как это. То есть на уровне репозитория. Понятно, все артефакты там фиксируются, но должен же быть ещё какой-то процесс, где в тикете есть, что задача заблочена, что она на ком-то висит, чтоб можно было понять, а че собственн?

235: Происходит, как это решается то есть какой-то параллельный тикет в жире, где куда любые истории эти отмечаются в виде статусов или как-то по другому. Смотри, мы работаем по канбану и у нас есть с точки зрения визуализации проекта, да, то есть у нас

236: Там, вспомню, основные колонки в работе, в тестировании, по правилу канбана, ты назад передавать, ну, плохая практика, возвращать на процессы назад. И поэтому мы не двигаем назад условно, просто приоритет этой задачи, да, то есть, если задача какая-то в тестировании,

237: Нашлась какие-то проблемы, баги и все остальное. Соответственно, просто разработчики туда делают акцент и работают, дорабатывают в рамках неё. То есть в том числе там дали какой-то фидбэк, заказчики, если требуется аналитика может подключиться, в том числе аналитик.

238: До проработать требования. Это выразится в изменении чижа, в появлении дополнительных пунктов в тасках, которые даются разработчики, разработчики имплементируют, если это просто баг. То есть, грубо говоря, когда не нужно требуется, не требуется изменение

239: Фикации, то разработчики просто дорабатывают в рамках текущего изменения баги ещё когда нужно использовать open спёк, когда нет, да, то есть иногда вот слушай, ну мне там цвет кнопки поменять, а надо ли мне open спёк для этого запускать? Нет, да, то есть, если у тебя там действительно это ошибка вёрстки какой-то

240: Ты можешь просто попросить напрямую агента и не дёргать именно open спёк, потому что, ну, как бы здесь у тебя никакого эффекта нет. То есть мы важно говорим, что ты должен включать голову, да, то есть, если ты видишь, что Спека точно никак не аффектится, то тебе незачем, действительно.

241: Запускать пайплайн эксплорер для того, чтобы это все делать. Помимо этого мы ещё учли. То есть это вот такие кейсы мы решали. Помимо этого, ещё решается ченджи, которые технические бывают, ченджи, которым там, допустим, не нужно изменение спёк. И мы это ещё там, по моему,

242: Весной у себя решили, что у нас есть типа чейнджей, отдельный скилл, который создаёт технический чендж. Допустим, это рефакторинг. У тебя изменение функциональности, не изменения требования, да, и там у тебя спеки не генерация. И вот, кстати, open спёк только сейчас.

243: В версии, по моему, 1 и 8, которая вышла пару недель назад, тоже добавил такую функциональность, что вот такие у тебя технические ченжи есть, которые не аффектят изменения спёк. И там тот теперь тоже гладко работает. Наши наработки можно убрать. Вообще забавно, что те проблемы

244: Которые мы решали весной, смотрим как open спёк, их сейчас догоняют, и нам наши решения уже нужно убирать, потому что вот как бы open спёк это решил своим системам. Здесь мы, грубо говоря, немножко впереди опенспорт ми шли и какие-то проблемы решали сами. Я, кстати, постоянно об этом говорю.

245: Говори, мы с тобой это даже обсуждали, да, что пытаться пилить собственную такую систему это довольно безумно в современном мире, потому что они все равно сделают лучше. Да, да, да, там весь мир над этим работает. Все так, все так хорошо. Мы ещё с тобой не разобрали ревью. Ты сказал, что он

246: Сам ревьювит, но когда все-таки пулреквест отправлен, как будто бы ревью тоже должно быть, да, от более там старших опытных товарищей. Вот эта часть, потому что обычно все жалуются же именно на неё, что вы, конечно, классно там все сделали, у вас там все ревью, но в конечном итоге вот это все прилетает, и кто

247: То должен прям ручками, глазками смотреть или нет. Да, это, это все осталось, это все классический процесс, просто настолько классика, что я даже не стал сильно вдаваться ревью. Есть человеческое, соответственно. То есть как мы и ещё в конце 25 мы сделали

248: Помощника, который ревьюит внутри цикла помогая. Причём сначала сделали продвинутого, который там каждую строчечку размечает, типа, вот здесь вот такой комментарий. Вот здесь вот здесь такие штуки, а потом ребята говорят, а можно пока что мы возьмём

249: Это уберём и сделаем это так, что просто он простыню отдаёт, потому что контрол ц контрол вэ агента так проще отдавать, чем копировать. С каждой строчки. Мы сделали упрощённый такой штуку. В то время модели очень сильно шумели и очень много давало

250: Вот прям много шумности было сейчас на последних моделях последние месяцы я вот спрашиваю насчёт шумности её очень мало. То есть получается это такой помощник для человека. Опять же, человек, в 1 очередь сам, кто отправил, он получил какой-то фидбэк, и он

251: Увидел то, что считает не шумом, он пошёл, поправил, потом собственно человек ещё сам это проверяет, но опять же для него вот эта штука подспорье, опять же для того, чтобы мы поняли, что это в 1 очередь для человека, который создаёт этот mr, это отправить там запустить агента, зачем тебе?

252: Это долгий цикл, если ты все равно передашь это агенту назад на вход. Поэтому давай-ка ты будешь скилл ревью обязательно запускать. Локально. И, собственно, у нас сейчас есть скилл, который автоматизирует вообще весь пайплайн. Вот это окончание работы. То есть ты работаешь, посмотрел?

253: Посмотрел, все хорошо и ну там, вместо того, чтобы там говорить, там коммить, архивируй, там отправляй и так далее, то есть ты просто синхронизируй спеки, запускай валидацию, спёк у spec ест ещё там дополнительная команда, которая под капотом запускается, тебе не обязательн.

254: Делать это, валидировать это все дело. Вот. Но дополнительно желательно перед коммитом это делать. А когда ты сам просишь закоммитить, агент понимает, что он будет это делать, но мы это у себя в скиллах явно прописали, соответственно, вместо всего, вот.

255: Этого там прогони, ревью отправь. Мр. Мы это теперь сделали. Отдельный скилл. Типа завершай, он коммитит, синхронизирует, валидирует, запускает ревью после ревью может внести правки.

256: Закоммитит это все если все ок ревью пройдено через глаб. Кстати вот классная штука. Если кто-то не пользуется поздно для себя немножко её открыли. Хотя я так понимаю она очень давно живёт консольная утилита для работы с гитлабом для агента он

257: Создаёт mr через глаб, отправляет его там там до сих пор остался ещё агент на другой модели, который по моему там гипсик у нас крутится, который дополнительно это валидирует, ещё берет его обратную связь, если что может что-то доработать, но

258: Опять же обратной связи стало гораздо меньше, потому что мы локально теперь гоняем локальный луг, у тебя это замыкает, все делает, mr тебя оповещает и так далее что это делает высвобождает вообще полностью тебе руки ты сказал, завершал, пошёл делать за другой задачей.

259: Понимаешь, что на этапе завершения у тебя там он полчаса, иногда час даже может работать. Просто то, что там в рамках ревью че то найдёт, так далее поправит и так далее. Все. Дальше мер, как раньше принимает все это есть. Но в итоге то получается, что количество

260: Скорее всего, стало больше, а тимлидов больше не стало, и они там висят или нет? Да, есть такое, конечно. Да. Ну, то есть работы стало больше, в принципе, выполняем. И больше, конечно, всего стало больше, да, то есть, условно, работы, работы руками.

261: Да, код писать мы стали меньше, мы стали заниматься вообще другими задачами по сравнению с тем, как мы работали год назад, да, то есть очень много всего поменялось. И, да, действительно, ты читаешь код, ты читаешь спёк больше, ты читаешь свой код. Больше ты читаешь чужой код.

262: Больше много читаешь, мало пишешь. Это то, к чему пришли. Окей. Ну, наверное, можно сказать, что в этом процессе стало участвовать больше людей. И, соответственно, в целом люди стали больше, как бы, заниматься ревью, чем всем остальным, но

263: Возникает, знаешь, какой вопрос? Сейчас во многом это профессиональные разработчики, да, и во многом они ещё помнят, потому что, как бы ручки, вот они, это было недавно, как ты думаешь, вот на перспективе, скажем, года 2, 3, сейчас даже речь не

264: Про появление новых ребят, а вот даже про ускользание навыков от текущих ребят, потому что ты же всегда учишься или делаешь какие-то новые задачи, которые ты раньше не делал. То есть, например, у тебя там какая-то оптимизация в базе данных, тут ты работаешь с новым видом аутентификации. И когда ты это делаешь,

265: Вот без ручёек, естественно, ты очень будешь примерно представлять, как это работает. Я с этим последнее время очень много сталкиваюсь. Я уже очень большое количество вещей, не понимаю, как в проекте реально работает. Типа, я какие-то общие. Причём это, знаешь, это ещё проблема такая, как в обучении, когда ты что-то учишь.

266: Тебе очень надо долго учить и прям упираться, чтобы это запомнить. А когда ты 1 раз ручками сделал, у тебя, как бы это в тебя вошло, и все, и ты это можешь. Вот ты чувствуешь, что это будет проблема, или это уже проблема, или вообще не проблема. И в конечном итоге нам не придётся погружаться в спеки.

267: Ну, я имею ввиду спеки, не знаю, протоколов, понимание каких-то систем, которые вокруг нас, и все это будет само. Я, давай так, в целом, у меня такой мансе, что предсказывать какое-то будущее, я, наверное, пере,

268: В 23 году, наверное, или в 24, потому что такая дичь у нас во всем этом творится каждый месяц, когда ты вообще не понимаешь. Ну, то есть все твои прогнозы, они могут очень сильно разбиваться. Этот, какое количество вообще, вот если взять 25 год по аишки, какие?

269: Как мы это представляли, как это будет работать, какое количество инструментов, просто практик умерло, да, то есть когда там выпускались какие-то стандарты, это все перечёркивалось, там вышли, вот скилы вышли, да, они просто кто то какие-то свои большие.

270: Замки контекста встроил. Вот просто 1 из кейсов программного комитета тоже в сторону предсказывания будущего расскажу. Пришли ребята, которые говорят, что ребят, вот мы запилили платформу для ii агентов, член программного комитета.

271: Такие смотрят на него и такие говорят, ну, все хорошо, ребята несколько месяцев работали, но это уже платформа предыдущего поколения, сейчас уже даже как бы не имеет смысла. Ты понимаешь, что ребята месяцы работали, да, то есть это очень сильно показательно, это насчёт прогнозов. Ну,

272: Если все-таки там попытаться это сделать и поговорить, подискутировать немножко про эту проблему, с 1 стороны, меня не пугает то, что это происходит, это потому что здесь у меня условно аналог. Пугаешься ли ты, когда ты делегируешь работу на джуна, и ты

273: Не знаешь, как он там код написал, да, условно. Или на, на медла, джуна, давайте забудем же на медла. Ты делегировал, у тебя там 6 миддлов, но ты не знаешь каждую строчку кода, там, которую он написал, ты, возможно, через себя её не попускаешь, если у тебя кросс ревью. Вот, соответственно, тут такое же примерно делегирование, да, на

274: А можно я поспорю немножко? Давай я, кстати, вот часто про это говорю, как будто немножко размылось слово, делегирование, делегирование это про ответственность, это не про то, что ты кому-то что то сказал, это про то, что передал ответственность и с агентами делегирования не бывает.

275: Это невозможно по определению слова делегирование. Ну тогда это просто другое какое-то слово должно быть, потому что вот у меня, например, вот представь, я все-таки компанией управляю, да, вот у меня есть руководитель отдела маркетинга, у меня есть финансовый директор, у меня есть главный бухгалтер, ты же понимаешь, какой это уровень ответственности и какие там ре,

276: Решения принимаются, вот это называется делегирование. Эти люди действительно делают мою жизнь проще, потому что я могу не думать о бухгалтерии, а какой-нибудь штраф, может быть, там миллионов 20, допустим, который меня обанкротит и приведёт к катастрофе. И теперь агент, который, ну, представь, я его упущу и скажу, ну, давай, подай мне годово.

277: Отчётность, естественно, делегирования там в жизни никогда не будет. Это помощник главного бухгалтера, это помощник финансового директора, это помощник руководителя маркетинга, но это не замена никогда. И поэтому, а ведь есть g4, 4 уровня делегирования, да, вот по 1, по 1 из разных классификаций.

278: Есть уровень делегирования, когда ты отдаёшь типа полностью, и все, ты под ключ все делаешь. А с другой стороны, когда ты просто каждый шаг контролируешь его, да, то есть ты делегируешь, но маленькими маленькими шагами и у тебя много, много точек контроля, это, то есть, вот, ну,

279: Классификация уровня делегирования и то, и другое называется делегированием. Можно так говорить. Но, по сути, самое главное в делегировании это то, что ты высвобождаешь свой ресурс. Здесь ты его, ну, не высвобождаешь. Это просто, ну, тоже самое можно говорить, что когда редактор генерирует тебе класс или

280: Диаграмму или по ерди, диаграмме, ну или там тесты генерируют и так далее. Ну, генерация не сегодня появилась, да, она появилась достаточно давно. Мы же тоже могли тогда говорить, что это делегирование, но никто это слово не употреблял. Здесь я, наверное, склонен вот к этому, потому что если какая-то штука не убирает от меня уровен,

281: Ответственности. Ну, она не освобождает мой мозг, она не освобождает мой ресурс, я не могу как бы переключиться на что-то другое, пока есть риск, что, ну, в конечном итоге прилетит ко мне, если я не понимаю в этой штуке. Вот слушай, ну ты же высвобождаешь своё время, когда ты

282: Работаешь с агентами, и они тебе экономят время, и ты ему даёшь выполнить какую-то задачу, проверяя за ним работу. Просто этот уровень делегирования, да, то есть мы сейчас на самом, во многих случаях мы на самом низком уровне делегирования, когда у нас много точек контроля, но со временем

283: По мере того, как растёт наш харнесс, как растёт этот, мы отдаём ему все больше и больше куски ответственности. Разве нет в рамках твоей работы? Не в рамках твоей работы? Потому что, смотри, это очень большая разница, которую, ну, разработчикам может быть чуть сложнее понять, потому что они привыкли. Вот я разработчик, я пишу код, когда

284: На уровне другом, и у тебя есть зоны, в которых ты, допустим, вообще ничего не понимаешь. То есть, опустим, допустим, финансовый учёт, ну, то есть 0 понимания, да, то там, ну, ты понимаешь, да, это совершенно другая работа. Я, в принципе, не могу этим заниматься никак. И поэтому там вот такое делегирование, это единственный спосо.

285: Масштабироваться, иначе я, ну, останусь всегда маленьким, я никогда не смогу расти. А когда, например, я сам, вот, например, я пишу тексты, я снимаю видео, я там пишу курсы и так далее, мне агенты делают действительно очень много и позволяют делать больше, но это все моя компетенция, и это моя ответственность. И я не называю делеги.

286: Это просто как бы, ну, такие экзоскелет, который делает меня сильней. Вот. Угу. Ну, это просто к слову, что вот все-таки, вот мы к чему это все ведём, да, что, грубо говоря, появляются какие-то у программиста. Это, наверное, можно связать с тем, что, ну вот появляются

287: Что-то совершенно новое, с чем он не взаимодействовал. И можем ли мы жить в режиме, когда ему и не придётся на этот уровень опускаться вот что-нибудь с сертификатами, например, вот появляется какая-нибудь штука, надо с госуслугами как-то интегрироваться так, чтобы там вот, понимаешь, там безопасность, передача.

288: Данных, трата та та та и какие-то там технологии, с которыми ты раньше не сталкивался, связанные с генерацией там сам каких-нибудь мега сертификатов и, ну понимаешь, да, вот эта вот вся история может примерно там, что-то, что-то там происходит, примерно что-то там работает.

289: Ты примерно, он мне обещал, что все будет хорошо. Можешь ли ты не опускаться на уровень понимания деталей? Я не уверен, мы просто работаем со смелом где-то, да, местами. И там обычная разработка на самом деле. То есть там нет, ну.

290: Пример, наверное, этот, то есть верхнеуровневый, ты ответственность делаешь, архитектуру ты валидируешь, но там, условно, опуска до уровня переменных и функций класса уже можно не опускаться, да, то есть зачастую, то есть и зависит от того, как

291: Тебе это позволяет это делегировать или нет? Да, на каких точках ты сделаешь и какие, как ты продумал тест, стратегию, вот этот файлик, да, как ты это будешь проверять и валидировать. Но если сеньор, который с этим никогда не работал, кстати, вот классный пример. У тебя был чувак, который занимался мобильной разработкой, и ты говориш,

292: А вот теперь разрабатывай сайт, это вот будет очень похоже на то, что я сейчас говорю, грубо говоря, он же разработчик, он же все понимает, ему не надо идти на нижний уровень, вот он сможет, грубо говоря, делать. То есть это примерно тоже самое, если как бы джун, ну, джун в какой-то момент приходит, да, как он из джуна станет сеньором, вот тоже само.

293: Самое приходит у тебя там мобильный разработчик, он делает сайт, и он не понимает, например, клиент серверную архитектуру. Вот мне кажется, чуть чуть как раз в обратную сторону интереснее будет, когда веб разработчик в мобилку пойдёт, мне кажется, ну, клиент, серверную архитектуру, мобильщик тоже понимает, потому что чаще всего мобилка это, извини.

294: Я дотошный, но, к примеру, в мобилке там много каких-то своих нюансов. Есть действительно тоже, с которыми нужно будет знакомиться. То есть, мне кажется, сеньор, когда он придёт в новую штуку, ему нужно некоторое время на погружение в эту специфику область, прежде чем он

295: Сможет принять на себя возможность валидировать результаты ответа. 2, это будет уровень, он, он сильно понизит уровень делегирования, он сделает его максимально дотошным. Поначалу для того, чтобы впитать эти знания, он будет задавать много

296: Вопросов когда-то есть ему агент выдаст какую-то вот я тебе сделал там какой-то компонент, условно он скажет, а почему так, а где, какие варианты ты принял в том числе вот запускай вот некоторый такой цикл обучения самого себя на примере каких-то конкретных

297: Реализации, то есть инженер, который там уже прошёл так много лет, да, то есть на других каких-то senior, да, и когда он придёт в новую отрасль, ему нужно знакомиться с новой спецификой, с новым доменной зоной, с новыми техническими правилами.

298: И итеративно, да, то есть от агента он не станет писать код руками, он станет писать код агентом, но он будет очень много задавать вопросов для того, чтобы впитать в себя как минимум архитектурные границы, понять, на каких границах он будет валидировать и

299: Проверять эту работу и постепенно, по мере роста его скилла именно в этой зоне он сможет повышать этот уровень. Ну, если пускай я согласен с тобой, что вот уровень, слово, делегирование может быть не до конца, это подходит, оно вот какое-нибудь делегирование со звёздочкой бы, да.

300: Это бы лучше бы выражало то, что происходит у нас с агентом. Ну вот все-таки для меня пока что это близко слово делегирование, потому что там есть уровни делегирования. Вот они вот очень понятны. Это то, что при работе с агентами, в зависимости от твоего, твоей компетен.

301: Неопределённости, уровня дотошности ты повышаешь или понижаешь уровень делегирования. Мне это очень близко. Вот такое сравнение я понял. Кстати, интересно, у меня при том, что я обучаю людей, до сих пор нет ответа на этот вопрос, но лично мой экспириенс вот последний, потому что мы начали параллельно делат

302: Проекты, например, там я никогда на гошке не писал, именно, знаешь, больше, чем какие-то скрипты, то есть скрипты, писал проекты никогда. И вот у меня новый стек полный, да, там довольно большой проект, он гошный, и я его весь генерирую. Я просто в какой-то момент понял, что это в чистом виде вайб, кодинг даже, н.

303: Смотря на то, что я смотрю на код, мне не хватает вот этого ручками пощупать. И у меня прям запланирован на там, типа конец года, ближе к праздникам, что я прям сяду и должен потратить какое-то время ручками для того, чтобы, знаешь, вот это вот ощущение на кончиках пальцев. Я думаю, что я хорошо пойму.

304: Ну, как бы, когда будет достаточно, но вот как ты рассказываешь, что только на уровне задавания вопросов я уже вижу, что у меня, по крайней мере, это не работает. Вот для момента место, в котором появляется много сложных деталей, ну, потому что в го, когда начинается у тебя там гарутино и так далее, да, если

305: Ты не понимаешь, что ты совсем не понимаешь, а насколько он адекватно вообще пилит и в ту сторону идёт. Вопрос вообще большой. Поэтому я такой понимаю. Либо я полностью вайб кожу и доверяю всему, что происходит, либо я все-таки должен сесть и поработать немножко ручками. Вот это, по крайней мере, моё последнее.

306: Открытие. Вот в этом отношении я с тобой соглашусь, я с тобой соглашусь, что, ну, то есть по ощущениям, там, теряю ли я какие-то компетенции. Возможно, они у меня немножко условно выветриваются вот в моём стеке, да, на котором я пишу, я вот я сейчас на этом стеке валидирую проекты, и я чувствую, что я где-то могу ещё

307: Дать жару агенту и нормально его отвалидировать, направить и сказать, что ты вообще фигню делаешь. То есть я понимаю, что здесь у меня может, если есть какая-то утечка, то она очень слабая, и я не скажу, что она прям есть. Я понимаю, что да, я как

308: Если я сяду сейчас писать код, я его буду писать медленно, с точки зрения агента, и медленнее, чем я раньше руками писал, то есть мне нужно будет некоторое время, вот и на кончиках пальцев это вспомнить, но структурно, архитектурно продумать любой компонент, любой

309: Архитектурный модуль, модель данных в базе данных это я все могу, это все, это все не проблема. Но когда мне приходится писать на тех языках, которые я не знаю или плохо знаю, действительно, я понимаю, что там вот немножко спускаясь на уровень

310: Кодинга и теряешь контакт. Да, нужно через себя пропускать некоторые вещи, чтобы ты лучше мог валидировать эти решения, архитектурные и так далее. Я здесь с тобой согласен полностью. Это вот, когда ты входишь в новую зону, как в твиттере недавно написали, что системный дизайн это новый язык прог.

311: Программирование. Да, да, да, да, да, абсолютно. То есть это прям 1 из наиболее востребованных компетенций. Мы вот для себя сейчас, как раз понимая, что нам нужно, ну, пускай мы не говорим о том, что вот нам надо взять всех, сделать фулстек инженерами сейчас, да, то есть утопия, да.

312: Кажется, сразу так амбициозно заявлять, но мы понимаем, что количество этих самых фул, сайкл инженеров у нас нужно будет больше, потому что, в принципе, и сама агентская разработка этого требует, и эта эффективность выше, и мы сейчас как раз думаем о проработке вот этой

313: Матрица компетенций внутри компании. Как должен выглядеть этот инженер, какими навыками он должен обладать и там действительно системный дизайн будет превуалировать для того, чтобы действительно мы могли переучивать сейчас ребят, там фронтов в бэков, бэков во фронт.

314: Да да, туда и сюда это все делать и каких-то где то и k, которые захотят стать фу цикл инженерами, им станет, на мой взгляд, им x 2 сложнее во многом, поэтому дадим возможность переучиваться всем, но вот эти критерии.

315: Нам надо прорабатывать и системный дизайн. Там будет 1 из основных. Не могу не обратить внимание, что есть стой не ту руку поднял, что есть место, куда можно идти учиться. Да, и мы этим добром занимаемся. Какие следующие шаги? Скажи, пожалуйста.

316: Вот вы дошли до этой точки, у вас пк девелопмент, вы даже опережаете опен спёк, с которым вы работаете. Что вот что дальше? Что теперь бэклога куча гипотез, да, то есть, ну очень много всяких точек улучшения харнесса, да, то есть нужно идти в сторону автономности. Продолжитель

317: Циклов, которые у нас есть. То есть нужно идти в сторону того, чтобы как можно меньше было вот этих интерактивных сессий разработчиков, чтобы действительно разработчик мог спокойнее передать и меньше дёргаться интерактивно для

318: Нужно улучшать качество харнесса, причём оно проектно, зависимо, правильно передавать контекст и детали проекта архитектуры в ограничения какие-то ставить агента, чтобы он не уходил ни вправо, ни влево.

319: У нас там все больше и больше появляется различных хуков, которые запрещают агенту что-то делать прям на уровне отлова его каких-то типовых, на наш взгляд, галлюцинаций, то есть точек роста в харнесс их прям очень

320: Очень много нужно зацикливать этот харнесс, в том числе замыкать петлю обратной связи, собирая ееще сквозную штуку. У нас же ещё ребята работают с разными моделями, с разными. Ну то есть у нас есть там 2, 3 разрешённых провайдера моделей, которые мы разрешаем, и

321: И в зависимости от моделей, в зависимости от провайдера модели, в зависимости моделей внутри него у нас там получается в том числе разный результат, к примеру, там 1 из Куков, который мы сейчас обсуждали на последней неделе, что, к примеру, нельзя запускать прополз или explorer на модели.

322: Чем 3 уровень, да, там opus и луна, по моему. Да, луна, сол, чат gpt сол, 3 уровень. Я, извините, я не в кодексе не работаю, я в клоде работаю, поэтому ошибиться. Ну, просто солнце, оно, типа, самое большое, да, окей.

323: Вот соответственно, то есть к примеру проектирование только на старших моделях, дальше реализацию ты можешь получить младшим моделям, но просто иногда мы сейчас там словили, иногда в sd проблематику, что кто-то взял и сонетом сгенерил спеку, а Санет, он там, короче средние модели, они чаще

324: Типа, а, все готово, да, то есть и наши модели там получше, больше перепроверяют. Есть такое, да, да. Вот. Поэтому проектирование лучше им давать. Просто хотел сказать, что мы сначала так пытались сделать, а потом, когда стали просто покупать клод, у некоторых

325: По двое премиум аккаунтов, когда по 100 $ 2, да, но вот 2 100 долларовых аккаунта уже хватает для того, чтобы всегда пользоваться только опусом. И поэтому мы как бы такие, блин, нам не жалко. Давай. И мы в итоге вообще перестали, в принципе, кроме опуса, чем-то пользоваться при любом

326: Да, у нас многие тоже так делают, но иногда это ещё сонет, ещё и некоторая скорость, но по большей части, да, действительно так. В любом случае, мы захотели это прям системно ограничить для того, чтобы прям даже не допускать такие возможности. И там вот таких вот маленьки.

327: Точек ограничений по харнесса, допилу каких-то различных Скилов. Их очень много из того, что хотим вот таких больших вещей, это делаем свой проект по ивалу для того, чтобы внесение Скилов и изменение харнесса определялось не на вкус, да, вроде, но

328: Стало лучше или не хуже, чтобы мы это цифрами все подтверждали. Большое направление. Это по аналитике сессий. Мы собираем все эти аналитики, сессий с разных моделей агрегируем для того, чтобы анализировать различные аспекты, начиная от где

329: Агенты тупят, ошибаются и вызывают лишние Тулы, вместо того или там в лишние циклы, запуская анализ и достигая результата, заканчивая тем, что понимать, как выглядит цикл работы.

330: Современного разработчика, да, где он там у него получается в течение рабочего дня, допустим, запускать много сессий, где нет, да, то есть, потому что мы, ну, действительно приходим вот такую нам нужно исследовать то, как строится работа современных разработчиков, потому что, ну,

331: Она сильно изменилась по сравнению с тем, что было и каких-то вот там чётких хороших исследований, как это было, как это должно строиться, оно нет, мы сейчас действительно в некотором фронтире находимся все вместе на рынке и нам нужно

332: Понимать, как это работает, исследовать границы где-то в том числе, где там человек ментально может уставать в течение дня с пятью сессиями работать, эффективность падает. И вот эти вот метрики собирать. Это очень интересно. Мы вот этим тоже всем начинаем заниматься по

333: Age дидишки у меня 1 из такой внутренних вопросов а не нужен ли нам 3 слой, не нужно ли нам 3 слоем сделать ещё lm Вики помимо вот этих 2 уровней, чейнджей и спецификаций для того, чтобы это чуть такой?

334: Huma френдли чуть больше документацию сделать и выделять туда некоторые моменты, потому что спецификация в open спеке, да и в спеките, она довольно-таки жёсткая, формальная, а нужно ещё некоторую другой род.

335: Документации. Вот у меня вот есть пока что мысль, с которой мы, коллеги, обсуждаем пока что спорим где-то местами, не нужно ли нам построить 3 слой, когда из ченджа будет не только архив спецификации делаться архив мастер Спека, вот это делаться, но ещё и собираться 3 уровень видео.

336: Viki причём сказать, что лм. Вики могла бы заменить мастер спеку ни в коем случае, потому что мастер Спека, она даёт вот эту жёсткость, которая сейчас ещё довольно-таки сильно актуальна, и в виде набора требований, который мерджится, и лучше конфликт, я понимаю, чт.

337: Вики на конфликты, на непротиворечивость проверить будет сильно сложнее. Когда она разрастётся до такого масштаба, она, она мягкая, скажем так, она более гибкая. И, соответственно, вот этой жёсткости, которую даёт этот spec, она не даст. Ну, в общем, как-то так, наверное,

338: По набор гипотез Скилов, по аналитикам по k очень много, ну а дальше нам нужно все потихонечку к схлопыванию в идеале универсальных инженеров.

339: И мы понимаем, что вот это сокращение ролей, оно даст довольно-таки сильное усиление.

340: 1 из таких вот небольших инсайтов. Это мы заметили, что блокеров стало больше, вроде работаем с ленками, но каждый день начало в какой-то момент вот там фронт от бэка зависит бэк от фронта. И таких вот кейсов много. И вот

341: Собственно, если на график нанести некоторую работу, я потом картинку скину, мы даже немножко визуализировали условно. Это когда у тебя условно вот были длинные, там, условно, работа фронта, работа бэка, и всегда у тебя есть маленькая коммуникация между фронтом и бэком, там согла.

342: Контракт там 1 от того, другого зависит и так далее. И вот у нас промежутки работы уменьшились и, соответственно, точек коммуникации их стало больше. И, соответственно, у тебя количество вот этих коммуникаций между специалистами, их стало больше. Это проблема именно

343: Вот этого подхода, когда мы действительно слишком много нарезали на эти узкие Роли. И когда мы будем схлопывать это все-таки в единые Роли, вот это сам с собой, ты коммуницировать будешь намного эффективнее. У тебя количество блокеров сильно уменьшается, поэтому 1, 1

344: Таких наибольших, наверное, значимых точек роста эффективности. На мой взгляд, это действительно схлопывание ролей для того, чтобы вот этих количество трений стало меньше, потому что сами промежутки работы стали меньше благодаря агентам, как-то так, и

345: Тарусу, наверное, такую вещь хочется сказать, очень много из за скорости развития инструментов. Очень много быстро становится оверинженирингом. Да, я имею ввиду, что, ну, ты понимаешь, да, когда у тебя, вот ты клодом,

346: Пользуешься, ты просто офигеваешь, как каждый месяц он настолько кардинально меняет свою работу, что очень большое количество всего, что ты напилил до этого, нужно просто выкидывать, потому что он даже мешать начинает. И в итоге вот эта команда такая инфраструктурная, которая занимается постоянным контролем, отслеживанием улу.

347: Становится 1 из главных, наверное, да, в компаниях, в принципе, харнесс в компании становится, по сути, ядром. Это, это самая главная часть, которая у вас есть. И это почему очень важны валы вам, да, то есть, потому что это, ну, типа, ваша

348: Core функциональность это core функциональность вашего бизнеса практически становится, да, по разработке её не покрывать автотестами. Это как бы очень нерационально и в том числе мы должны понимать деградацию своего харнесса.

349: При выходе новой модели мы, то есть новая модель, мы должны взять, посмотреть, сравнить с харденом и провести набор экспериментов. А точно ли нам вот эти блоки харнесса нужны и, возможно, их нужно действительно выпилить и посмотреть. Возможно, они становятся, добиваются лучшего эффекта, поэтому

350: Здесь с тобой полностью согласен. Кстати, нативная интеграция. Мы с Ваней тут фоном прорабатываем курс, в котором, собственно, ивалы будут 1 из таких важных частей, где мы будем про это рассказывать, этому обучать. Так что следите за анонсами. Знаешь ещё какую штуку хотел сказать?

351: Знаешь, когда у тебя все это развивается, у тебе постоянно какие-то овые идеи в go приходят, которы раньше бы не пришли. У меня вот такая идея прям на днях пришла, да, он стал генерить много Тестов, но у нас было написано много Тестов уже до этого там 1000, да, допустим, в проекте. И я понимаю, что именование этих

352: Тестов, оно не идеальное, прям скажем. Ну, потому что, когда ты сам пишешь, оно такое себе. А ведь как он понимает, что какие кейсы вообще есть, покрыты? Нет, реверсит, он же не из кода это делает, потому что если так много Тестов он делает из названий. Я вдруг понял, что как будто бы, например, у нас появляется 1 из

353: Таких задач, причём, казалось бы, она такая простая достаточно, да, что попросить его прям как отдельной большой сессией проанализируй все тесты, которые есть, и напиши адекватное название теста, соответственно, что в будущем позволит ему гораздо быстрее отслеживать. А какие кейсы были реализован?

354: Нет, без того, чтобы изучать тело теста. И вот чем дальше, тем больше я таких вот штучек начинаю видеть, которые раньше в голову как бы не приходили. Я такой прикольно, потому что он все это начинает использовать, потому что вот эти грепы туда, сюда, они дают ему очень много возможностей.

355: Это, кстати, тоже 1 из штук, которую мы решали, в том числе даже формирование вот этих доменов и capability в open спеке он фантазирует, и он их называет действительно по разному. И 1 из элементов жёсткости, который мы добавляем.

356: Это мы делали справочник доменов и capability, которые есть. Угу. Чтобы он не фантазировал и не отклонялся. И чтобы он оперировал только это. То есть по факту мы приходим к классическому, да, вот этот дидиди, как вот справочник терминов, вот этих всех сущностей, которые у нас должен быть единый язык, д.

357: Да, да, это я, кстати, забыл сказать про это, да, что даже у тебя в маленьком проекте. Ну, ну, относительно, да, у тебя там этих папочек миллиард, и если он создаёт что-то новое, ты за этим не отследил, у тебя может быть такое, типа, да, часть заехала немножко сюда, часть.

358: Заехал немножко сюда фронт бэк, какая-нибудь сбоку фигня у тебя миллиард папочек в какой-то момент это просто, ну никто не понимать, ни разбирать не будет, да, поэтому надо это тоже сводить. Это я вот показал, как раз делал проект, делался на предыдущем спехе, а сейчас он как раз двухуровне

359: Позволяет это в домены объединить ещё. Соответственно, это лучше контролировать. И вот, собственно, внутренняя задача, это у меня взять, это отрефакторить в новые домены для того, чтобы это теперь чуть лучше работало. Угу. Забавно, что мат, я вот просто, ну, как бы комментарии не вставлял. Очень многие

360: Вещи мат покок, они двигают в похожие штуки. Например, у них там есть такое понятие сейчас контекст мапп, то есть ты прям выбираешь, я хочу, типа, у меня проект, когда 1 context или проект, когда много контекстов, там это опция, да, и ты выбираешь, если несколько, он создаёт специальный файлик, который называется

361: Который как раз определяет эти контексты и как бы оно погнало, потому что, ну все, все, короче, наталкиваются на какие-то проблемы, потому что по дефолту эта штука создаёт слишком много всего. И оно поначалу как бы весело и здорово, да, в какой-то момент просто неуправляемым может легко стать.

362: Кстати, может быть, мы на это ещее наткнёмся, когда у тебя будут гигантские объёмы этих данных, и никто не будет понимать, че вообще происходит. Да, да, да, да. Все правильно. Не кажется, что уже должен быть скилл, который называется review, и compact, который как раз смотрит их, объединяет и убирает.

363: Лишнее. Я уже думал в последнее время о том, что такая, слушай, по моему, я вот недавно смотрел мэтт покока у него, по моему, прям даже че то такое есть, когда в конце архитектуру он берет и как раз компактит, по моему, что-то такое делает, как будто новое. Точно. Я видел, что уже хотят такое добавить. Да, я вот прям

364: Я видел, как будто бы это даже есть у него уже, по моему. Угу. Короче, появляются скиллы. Теперь то, чтобы все чистить, да, в обратную сторону. Да, да, да. Все так, вань, тебе большое спасибо, что ты пришёл, поделился своей историей. Ребят, если вам понравилось, поставьте лайк. Если не понравилось, поставьте дизлайк.

365: Напишите обязательно, используете ли вы у себя не используете. Может быть, вы вообще против? А, хотя, мне кажется, сейчас уже это редко встречается. Да че вы обо всем этом думаете? Будете ли вы в эту сторону идти? С какими сложностями сталкиваетесь сами? Всем спасибо. Пока.

366: До новых встреч. Пока.