Speaker A
Сегодня говорим про SDD. Пару слов начнём о том, кто я такой. А меня 15 лет в IT. Я прошёл путь в тимлида. Сейчас CTO в компании VPT. Это порядка 150 человек.
Доклад о внедрении Spec Driven Development (SDD) в крупной компании, опыте адопшна и развитии процессов с применением AI.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- SDD позволяет стандартизировать процесс разработки, делая спецификацию единственным источником истины.
- Клуб энтузиастов и парное программирование эффективны для достижения высокого уровня адопшна.
- Матрица зрелости помогает оценить и планировать рост автономности команд с использованием AI-агентов.
- Платформенный подход снижает нагрузку на разработчиков, предоставляя готовые рабочие процессы.
- Полная автоматизация ('тёмная фабрика') пока достижима лишь немногими, но тренд на повышение автономности очевиден.
What the video covers
- Автор с 15-летним опытом в IT и CTO компании VPT рассказывает про внедрение SDD.
- SDD рассматривается как единый процесс, где спецификация — источник истины, из которой рождается код.
- Обсуждается путь достижения 100% адопшна среди разработчиков через клуб энтузиастов и парное программирование.
- Представлена матрица зрелости инженерной автономности с уровнями от ручной работы до полностью автоматизированной 'тёмной фабрики'.
- Рассмотрены сложности и подходы к масштабированию SDD на все команды в компании с 150 сотрудниками.
- Обсуждается роль AI и облачных агентов в повышении автономности и эффективности процессов разработки.
- Подчёркивается важность платформенного подхода для скрытия сложности харнеса от разработчиков.
- Приводятся примеры интеграции SDD в монолитные проекты с десятилетней историей без документации.
- Обсуждаются технические детали и вызовы, связанные с поддержкой и автоматизацией процессов через агентов.
- Завершается доклад сессией вопросов и ответов, где обсуждаются практические проблемы внедрения SDD.
Chapters
- 00:00Введение и представление спикера
- 02:59Путь к 100% адопшну SDD среди разработчиков
- 06:12Матрица зрелости инженерной автономности
- 08:44Уровни автономности и роль AI-агентов
- 11:12Проблемы интеграции и согласования подходов
- 14:00Жизненный цикл и команды в SDD процессе
- 16:59Технические детали и вызовы автоматизации
- 20:12Вопросы и ответы, обсуждение практических аспектов
Full Transcript — Download SRT & Markdown
Speaker A
Программного комитета действительно большого количества разных конференций. И на этих конференциях я в основном курирую именно AI из DLCK. А это позволяет мне прогонять через себя достаточно большое количество разных докладов, разной экспертизы разного уровня разных компаний. Это довольно-таки интересный опыт, который
Speaker A
позволяет мне, в том числе, обобщать некоторые знания и помогает для внедрения DLC у себя, в том числе в компании. Также я организатор ростовского сообщества аналитиков и разработчиков. И что бы себе хотел сказать, что я трансформирую из DLC
Speaker A
процессы под AI трек уже примерно полтора года. А из некоторых моих достижений — это то, что я получил 100% адопшн среди разработчиков ещё в 2025 году. И сейчас я занимаюсь масштабированием SDD процессов на все команды. Что такое сквозной SDD процесс,
Speaker A
мы поговорим чуть-чуть дальше. Собственно, Webpractic — веб-интегратор для корпораций. А это пример компании, с которой мы за последние 10 лет работали.
Speaker A
Если оператор может включить мне таймер, я буду благодарен. А о чём поговорим? А поговорим о том, как мы пришли к SDD, а через призму двух историй. То есть я расскажу по сути, как мы к нему вообще подошли. А поговорим о
Speaker A
том, как SDD стал для нас по сути ответом на хаос контекста, на разнобой практик. Расскажу именно, какие боли конкретные мы решали, когда внедряли конкретный фреймворк. А какой харнес мы строили и очень много сосредоточим внимания на полезности
Speaker A
именно сквозного SDD процесса. Итак, начнём с базы. Что такое SDD? Вот одно из определений — это подход, где спецификация становится единственным источником истины. Сначала фиксируем намерение в спеки, потом из неё рождаем код. По определению, кажется, что-то, что мы слышали уже 30 лет назад. Вот. Но
Speaker A
в сфере AI трансформации этот подход играет новыми красками. Собственно, давайте, а ещё небольшая просьба. Можно обновить страничку в браузере, пожалуйста? Ctrl+R или F5 нажмите, пожалуйста.
Speaker A
Да. А поднимите руку, кто из вас уже юзает SDD или пришёл узнать опыт коллег? Вот кто уже использует. Супер, классно, как рад вас видеть. Так, хорошо. А кто из вас уже внедрил не только в разработчиков, но и в
Speaker A
аналитиков EQA? Вот прямо сквозной процесс. Круто, красавцы. Так, а кто пришёл познакомиться с тем, что это такое, собственно, и понять вообще, насколько это применимо? Ага, супер.
Speaker A
Хорошо. Собственно, как мы пришли к SDD. Две истории. А первая история — это про адопшн, как мы его прокачивали. Давайте просто познакомимся. Вот кто ли тут и выше здесь руководство. Ага, отлично, много рук. А у кого адопшн разработчиков и практик уже более 50%? Так, а 100% — круто, что такие есть. А у кого адопшн в аналитиков уже больше половины? Вообще тоже круто. Супер. Отлично. Вот, собственно, мы пришли к концу 2025 года через разные тернии. 100% адопшн среди разработчиков. Очень
Speaker A
коротко, как мы это прошли, да? То есть мы там летом создали клуб энтузиастов. Мы там сделали там 15–20 человек. У нас этот клуб был, где мы регулярно собирались для того, чтобы отресёрчить стек модели, основы нашего харнеса. И
Speaker A
потом всем инженерам в компании мы назначили трекеров из этого клуба, которые помогали им адоптиться. Основная практика, которую мы использовали, — это парное программирование. Это ирлиадоптер, то есть эксперт по сути в SDD, садился с любым разработчиком и один день решал с ним его задачи в
Speaker A
парном программировании. Сначала показывал: смотри, вот на конкретной твоей задаче это конкретно работает. Так, мы победили практически всех скептиков и довели до 95%. И оставшиеся 5% мы добили кадровыми решениями. Так, мы, собственно, к концу года есть, и мы решили, начали думать, как качать глубину
Speaker A
используемых практик. А я не ожидал, что такая реакция будет, извините. То есть, окей, все используют, но как теперь понять, что они используют правильно? Ну, мы такие: "Ну, окей, ладно, у нас уже есть механизм, да, вот этот адаптации. Давайте мы начнём этим
Speaker A
же механизмом качать глубину." Вот мы там сделали какую-то матрицу зрелости именно разработчика по этим, вот она примерно такая была, там, может быть, чуть больше уровней было. И даже начали её внедрять, но остановились, потому что вот для нас, в нашей модели
Speaker A
мира, мы поняли, что, блин, учить всех разработчиков в глубине харнеса для нас это избыточно. То есть на самом деле мы понимаем, что разработка харнеса — это платформенный подход. То есть мы должны сделать именно платформенный слой, который закрывает эту сложность, а
Speaker A
разработчику дать просто там готовые скилы, готовый workflow, который он просто должен прожимать, да? Вот и мы эволюционно к этому пришли и как бы остановились и не перестали всех разработчиков тянуть там разбираться очень в глубине харнеса. Это вот первая
Speaker A
история, как мы пришли именно к SDD фреймворкам. Вторая история — это про матрицу зрелости. С некоторыми докладчиками мы ещё в прошлом году вот примерно сделали такую матрицу зрелости.
Speaker A
Она про такую инженерную зрелость. Её шкала — это автономность. И здесь основная метафора — это фабрика, да? То есть вот как мы в производстве — фабрика.
Speaker A
Вот берём классические три амига: аналитика, разработчик. И на нулевом уровне мы в нашем конвейере, да, работаем вручную. На первом уровне условно мы там даём чатик, да, то есть где AI напрямую не взаимодействует с нашими артефактами, то
Speaker A
есть мы там спеки, требования, код, тесты, мы Ctrl+C, Ctrl+V в чат, да, то есть это вот такой промежуточный уровень. А очень большой важный уровень — это локальные агенты, когда мы ставим те же самые cloud-агенты, кодекс, OpenCD, и они
Speaker A
уже напрямую работают с артефактами. И здесь вот метафора — это экзоскелет, который мы даём нашим специалистам. Если тут достаточно хорошо видно, да, то есть это, наверное, один из основных уровней, на который сейчас все идут или
Speaker A
на котором многие находятся. А третий уровень — это вот по шкале автономности мы агентов выносим с ноутбуков наших разработчиков или специалистов в облако в более автономных агентов. То есть, на мой взгляд, никакой автономности нельзя говорить о том, когда вы зависите от
Speaker A
человека и его ноутбука. Соответственно, и человек здесь может подключаться и где-то даунгрейдиться на каком-то конкретном задаче на предыдущий уровень, если, к примеру, агент не справляется.
Speaker A
Но ключевая суть в том, что какая-то часть этих задач может уже минуя какие-то роли решать автономно. Допустим, аналитик написал задачу какую-то небольшую, и уже её можно решить без разработчика EQA. И четвёртый уровень — это такая метафора тёмной фабрики.
Speaker A
Это когда по сути решение у нас уже полностью закрывается. А что термин тёмной фабрики — Dark Factory? Кто-нибудь знает?
Speaker A
Да, для тех, кто не знает, расскажу. Это термин из Японии. Это довольно-таки старый термин. На многих производствах в Японии уже давно пришли к такому уровню автоматизации, что там просто не работают люди в процессе производства. И поэтому им не нужен
Speaker A
свет. И поэтому эти фабрики называются тёмными фабриками, потому что свет им не нужен, собственно.
Speaker A
Четвёртый уровень, мне кажется, достигли либо критически малое количество компаний, либо это, возможно, какой-то гражданский стартап, где безумие и отвага, на мой взгляд. А третий уровень компании были уже в 2025 году, а в 2026 году я их вижу всё больше. На
Speaker A
конференции на подлодке я на прошлой неделе с многими ребятами рассказывал, обсуждал. Действительно, уже многие находятся на этом уровне автономности.
Speaker A
Это довольно-таки круто. Собственно, мы сейчас до сих пор находимся на втором уровне в практике. И вот полгода назад мы решили, что нам бы надо проектировать третий уровень. В том числе для чего? Для того, чтобы снижать потенциальный басфактор,
Speaker A
потому что вот сейчас все говорят о том, что мы должны с ростом продуктивности уменьшать размер команды, да, те...
Speaker A
потому что а вот сейчас все говорят о том, что мы должны с ростом продуктивности уменьшать команды размер, да, те самые Tiny Teams, а меньше команда, но у нас выше риск завязки на конкретных людей. А, соответственно, повышение уровня автономности - это одна
Speaker A
из вещей, которая нам позволяет уменьшать басфактор. И вот мы полгода назад, у нас как стратегическая сессия была, и мы решили темой этой стратегической сессии сделать именно то, чтобы руководители сыхов нарисовали то, как они видят свой выход на лретий
Speaker A
уровень как раз автономности. Ну, собственно, каждый нарисовал, пришёл, презентовал эту схему. Ну, и как вы дорадываетесь, что произошло, да? То есть мы поняли, что это вообще абсолютно какие-то несовместимые вещи и виды. То есть каждый спроектировал какой-то свой visionханеса свой, а, свои способы
Speaker A
работы с контекстом, а, свои скилы. В общем, мы поняли, что это вообще потом не соединить никак, да? То есть, и здесь для нас вот это как раз подтолкнуло, что, блин, нам надо пересаживать всех на единый фреймворк, на единую платформу. И
Speaker A
реально вот мне кажется, это я вижу, что мы остановились на самом старте, но многие зашли в этой ошибке нам, ну, сильно дальше. А когда мы видим, что как спустили там эту я идею, говорит, вот в каждую профессию, там тестировщики,
Speaker A
фронтендеры, бэкэндеры, вот внедрите себе и ай как-нибудь. И они уже настолько далеко происполнились. Я даже видел, э, матрицы компетенций по ролям, где, а, есть разные роли, и в каждой роли свой SDD фреймворк используется. То есть, ну, это прямо такой
Speaker A
интересный такой кейс. И, собственно, для нас это ответ как раз вот этот самые сквозно SDD, единый язык и процесс через всю цепочку из DLC. О'кей. Рассказал о том, как мы пришли а к основные наши такие идеи, почему мы пришли к SDD
Speaker A
фреймворкам и выбор SD фреймворка. Здесь глубоко сильно погружаться не буду, то есть их есть там пять примерно топовых.
Speaker A
Это GitHub Spec Kit, а BMAT, Open Spec, а JSD, который не так давно взломали.
Speaker A
Причём сам автор его слил. А, интересная история. А мы выбрали конкретно OpenSpec. А, и расскажу, почему мы выбрали именно его. Во-первых, простота.
Speaker A
То есть для нас, на, на наш взгляд, это один из самых простых фреймёков, с которым проще всего стартануть.
Speaker A
Во-вторых, его киллерфича - это два состояния контекста из коробки. А как мы обычно ведём документацию? А-а, у нас есть вариант А - это когда мы описываем текущее состояние системы. Оно вот S is.
Speaker A
И каждый инкремент мы прямо берём и изменяем текущее состояние. Второй вариант, мы пишем какие-то ЧТЗшки, и они вот наслаиваются как а такая стопка изменений, да. Так вот, а резко кто когда кто делал и то, и другое, потому что с человеческим трудом это накладно.
Speaker A
В AI мире это стало гораздо более реальность, потому что это автоматизировано. И вобнпек - это его базовая фишка из коробки. То есть он действительно делает вот эти два состояния: и состояние инкремента, и состояние SS, состояние SK. А что ещё
Speaker A
также подкупает, что они говорят, что Brownfield - это наше ключевое направление, на которое мы идём. Это то, что а вот десятилетние монолиты с без документации идите. Это про нас, это вот мы про это. А, собственно, ну и хороший
Speaker A
тренд популярности в сообществе, 58.000 звёзд на GitHub. И тренд довольно-таки растущий, поэтому, собственно, это нас всё подкупило.
Speaker A
Кто пробовал OpenS? Отлично. Много адептов. А, расскажу для остальных просто основу Open SPC на пальцах примерно, как это работает. Ну вот, собственно, те два два две сущности, да, то есть инкременты, которые идут, это как раз вот эта папочка Changes - это как раз а папка с
Speaker A
конкретным набором артефактов, которая вам нужна, чтобы имплементировать конкретные инкременты. И спек - это как источник истины. Там лежат только спеки, которые описываются текущее состояние системы. А-а, собственно, по по жизненному циклу, собственно, Чейндж живёт, проходит ревью, реализацию, деплоится и потом он вливается в
Speaker A
источник и стены. Тоже встроенным механизмом ничего придумать не нужно. Примерно там структура папок, да? То есть вот эти вот самые SPC changes, а спикеры разбиты по доменам. А мы, причём сейчас сделали у себя сделали ещё под домены, а, чтобы более большая
Speaker A
вложенность была. И там вот как бы источники истины лежат. Ичин. Вот здесь чуть подробнее остановимся, да. Базовый набор артефактов в рамках этого ченджа инкремента. Э первый файлик - это пропоd. Это в нём лежит смысл, зачем, да, инtent тот самый, о котором вот в
Speaker A
том числе в дирапте DLC говорится. А то есть зачем мы это делаем, собственно, и этот артефакт, который в том в том числе по хорошему, в идеале владеет бизнес, а а когда именно он является постановщиком, инкремента. Дизайн - это
Speaker A
такой адрка, но она такая довольно-таки низкоуровневая. Там может быть описано, в том числе низкоуровневые инкременты какие-то компоненты которые будут использованы для решения этой задачи. А TASMD - это план, а конкретный чек-лист, который позволяет вам, аэ, делать эту сессию, разрывать сессию, к
Speaker A
примеру, там закончились токены, продолжили в соседней сессии, там закончилась подписка, там и так далее.
Speaker A
То есть можно прерваться в любой момент. в любой момент продолжится с другого с того места, где остановились. Ну и важно, он декомпозировать довольно-таки маленькими задачками, с которыми агент гораздо лучше справляется. Вот и те самые спеки, которые он генерирует - это
Speaker A
как раз критерии приёмки. А по умолчанию они в Геркине, которые позволяют агенту проверять свою работу по результату.
Speaker A
Соответственно, что важно, да, все артефакты, которые здесь описаны, это они автоматически генерируются агентами, да? То есть мы не говорим о том, что мы что-то пишем в наше время ручками, всё генерируется агентами, а мы это ревьюем, можем вносить правки руками либо агент.
Speaker A
А, собственно, жизненный цикл и основные команды, которые у нас есть. А основные команды - это вот эти вот три справа. А, проse, apply и архив. Props - это как раз создаёт, мы передаём на вход агенту, что мы хотим создать, и он создаёт как
Speaker A
раз а вот эти основные артефакты. Он опирается на код, на предыдущие спеки и создаёт набор этих артефактов. Apply - это как раз э а команда, которая запускает разработчик для того, чтобы имплементировать это всё из на основе спроектированных папки Чинджа. И архивация - это уже
Speaker A
после того, как вы реализовали, вылили фичу, вы сливаете её в источник истины. А опционально есть у него ещё дополнительный skill Explore, который можно запустить перед Propose. Это такой вот аналог Greill Meinstorm, который прожаривает вашу идею, и потом она на вход может передать пропоз. Он в
Speaker A
какой-то момент может там предложить: "Давайте я запущу пропоз" и, собственно, это туда все наши мысли с тобой туда оформим.
Speaker A
А поговорим про сквозной SDD и SDD разработчик. А-а, проблема в том, что многие, а, внедряют SDD только в разработчика, а не во все роли. То есть и к чему это приводит? То есть на самом деле у нас спеки, источник истины есть,
Speaker A
живёт в каком-то конфлюенсе. Разработчик берёт из этого конфлюенса, копирует в свойdфorkк и, э, генерирует ещё один источник ск. То есть у нас уже, в принципе, две два источника истины, кажется, уже где-то пахнет не очень хорошо. Вот тестировщик может вообще не
Speaker A
смотреть на эти спеки, которые написал разработчик провалидировал будет смотреть в конфлюнс. В общем, какой-то прямо сильно разорванный цикл, да, то есть который как будто бы прямо сильно выглядит как а антипоттерн, на мой взгляд. Конечно, какие-то плюсы с того
Speaker A
подхода можно взять, но можно получать, но всё-таки видны сразу проблемы этого подхода. Поэтому правильное внедрение SD - это когда у нас одна платформа на всю команду. То есть аналитик должен брать или продукт может быть он брать, вызывать пропоз генерировать первичные
Speaker A
намерения, что зачем, как, а и передавать дальше разработчику. Разработчик ревьют, э, артефакты как раз адрки, смотрит там всё, что ок, правит, и запускает конкретный apply. и quality gate, если у вас есть QA, соответственно, он shiftleтся и проверяет артефакты
Speaker A
после выхода продукта аналитика и после выхода артефактов разработчика в собственном в виде реализации. Ну и, конечно, в этом моменте нам становится гораздо менее нужна какая-нибудь какой-нибудь конфлюенс, как источник истины, мы уже начинаем работать все в одном репозитории с единым контекстом. А
Speaker A
пережиток некоторого старого мышления. Мы когда внедряли, и мы прямо на эту ошибку в том числе наступили, мы такие: "Так, а после разработчика будет ещё тестировщик, который будет писать to тесты". И мы думали, что это вот прямо наша часть нашего цикла. Ну вот как бы
Speaker A
все сейчас слышали про этот луп инженеринг, да, мы тоже где-то в мае к этому пришли, что, блин, на самом деле эффективней цикл замыкать, когда агент сам пишет тесты end to end и сам их проверяет, потому что это источник
Speaker A
проверок для самой реализации. Аа причём а так как SDD он помогает лечить распространённую проблему, что агент может подстраивать аа тесты под реализацию, а потому что он а берёт, использует критерии приёмки как источник для того, чтобы а написать эти тесты.
Speaker A
Чуть позже об этом сейчас поговорим. Собственно, в нашем случае мы поняли, что нам навыки у тестировщиков NН тестирования уже не нужны. То есть нам нужно, нам нужно это отдавать разработчику. И, собственно, вот эта вот схема, да, мы отдали Nнn разработчику,
Speaker A
агенту на самом деле, а разработчик всего лишь верифицирует. И, собственно, квалитети гейты вот в виде тестировщиков поставили за Shiftлефтились.
Speaker A
А, собственно, для этого мы ещё дополнительно сделали дополнительный артефакт. Важно сказать, что Openпект очень гибкий фреймворк. Вот это базовый набор артефактов, их три. Если у вас на самом деле есть много там других файлов, вы можете там файл по безопасности, ещё
Speaker A
по какому-то комплайнсу, ещё каким-то вещам добавлять. То есть это очень расширяемый фреймворк. И это очень расширяемый фреймворк по процессам. Вот я показал вам три стадии. Вы можете сделать их там, чтобы у вас было восемь стадий, если у вас сложный процесс, там
Speaker A
согласование и, соответственно, всех подключить вот эту вот шину фреймворка. Соответственно, [фыркает] вот один из файликов, который мы себе добавили, дополнительно генерируемый - это тестплан. А мы берём, собственно, change и берём через все, а, используя все спецификации, мы через всю
Speaker A
пирамиду юнитов компонентных на фронте НТН тестов проектируем, как мы должны будем покрыть этот инкремент автотестами. Соответственно, прикольная штука, что действительно вот у нас есть вот эта трассировка, и она трассировка на критерии приёмки, которые в том числе провалидировал тестировщик. И получается
Speaker A
довольно-таки хорошо, что у нас не раздувается количество НТН тестов, которые тяжёлые и сложные там в поддержке и там долгие по скорости работы. И этот артефакт нам позволил действительно улучшить наше тестовое покрытие. А-а, обсудили Tiny Teams. А, все слышали этот термин в наше время?
Speaker A
Почти все, да? То есть, а это про то, что аэ сейчас говорят, что команды должны схлопываться, да? Мы немножко чуть-чуть об этом упоминал. Вот там в целом в среднем по рынку минимальная там композиция. Говорят, что вообще это команда из одного, это продукт-инженер.
Speaker A
На самом деле во многих случаях он даже может справляться. А когда мы говорим про более сложный проект, то вот к нему добавляется один, может быть два. Это full stepк или full cycle инженер, который закрывает весь цикл за собой по
Speaker A
экспертизе. А у кого есть в командах вот эти вот самые full cycle инженеры, да, вот немножко рук, так, а у кого они есть в каждой команде, [смех] то есть, да, то есть, ну, вы либо маленькие, либо вы гении, наверное, да? То есть хорошо,
Speaker A
круто. А, собственно, full cycle инженер, да? То есть это человек, который в себя вмещает большое количество ролей. Но я могу себе представить да что ну допустим он разкрывает синьор может закрывать часть аналитики требования, да, но научили мы его писать, валидировать автотесты,
Speaker A
допустим. О'кей, он верхнеуровнево понимает. Плюс платформа, на самом деле, закрывает ему платформенный слой, часть компетенций. Но вот для меня лично самый большой вызов - это как раз иметь глубокую экспертизу и во фронт-эндде, и в бэк-энде. Вот. То есть условно сейчас
Speaker A
сказать, товарищ бэкндер, э, начни валидировать React-компоненты, их сложные стейты где-то, которые бывают очень сильно разросшиеся, когда этот бэкдер никогда не написал ни одного рядкомпонента. Я понимаю, что в этом есть некоторый вызов, как и наоборот, если фронт начнёт проектировать базы
Speaker A
данных, когда ни разу он как-то валидировать проектирование базы данных, когда он ни разу не их не проектировал.
Speaker A
В этом для меня некоторый вызов есть. Поэтому, как бы, я понимаю, что мы тоже туда хотим идти, нам нравится концепция, но нам нужен некоторый переходный период, в котором мы сейчас в реальности, мы сейчас хотим внедрять это. И то есть, если сейчас я отдам
Speaker A
полностью валидировать там условно бэкэндеру или фронтендеру вчерашнему, то я понимаю, что у него не хватит компетенций действительно хорошо провалигировать. Я просто получу просадку качества. Поэтому мы в план MD сразу и агенту говорим, что вот часть задачи выделяя на фронта, часть на БКА.
Speaker A
И, собственно, backender и фронт запускает свою команду Apply front apply back. И он валидирует только именно каждую свою часть, собственно, в общем, опять же, в общем пайплайне, в общем процессе.
Speaker A
Это как мы решили эту проблему. А с аналитиками, да, то есть как аналитиков отучить писать в конфлюнс. Э на самом деле нам сильно помог то, что у нас у аналитиков, а ещё с начала годов мы их подсадили на локальный харнес, причём с
Speaker A
другой стороны зашли, а другую проблему решали. А часто аналитики прибегали к разработчикам: "Блин, расскажи, как это работает." Особенно вот там Большой Монолит, там с большой историей, у которого ни фига нет нормальной документации и аналитик там, у которого год опыта, условно, да, с этим проектом.
Speaker A
А собственно и ну действительно было много таких коммуникаций. И мы просто как бы сказали: "Товарищ аналитик, вот ставь локальный harness, вот там clouди код, кодекс Open Cod, аа качай репозиторий и просто задавай вопрос коду. он тебе расскажет, как это
Speaker A
работает, какие таблицы, какие данные, какие методы там используют. Блин, на самом деле аналитики были в восторге, да? То есть нереально не нужно дёргать этот. Многие цепочки сократились там в какой-то момент. Мы поставили там одному аналитику сначала, и все аналитики к
Speaker A
нему бегала. А так, Боря, а спроси у него вот вот это как работает там и так далее. Короче, эффект был классный и мно у многих уже стояло, и это немножко помогло нам, в том числе, к этому этому.
Speaker A
Но, конечно, всё равно нам пришлось там целый ряд сессий с аналитиками а делать с проработкой рисков перехода отказа от конфлюенса. Там как бы было мно много довольно-таки разных интересных подводных камней. А-а в целом как бы тоже помогло то, что Docsot на некоторых
Speaker A
проектах у нас был и раньше, как мы, где мы ещё ручками даже на в то время писали. Но, собственно, Doc делает, даёт некоторые накладные расходы на накладные расходы на старте, но в конечном счёте там с учётом агентов это там нивелирует
Speaker A
их кратно. Это точно. Собственно, одна из ключевых проблем, да, а что делать с документацией для стейкхолдеров, которые хотят всё-таки заходить в конфлюенс и его там читать? А, ну мы решили как бы, о'кей, если теперь источник истины у нас
Speaker A
есть DD пеки, а у нас там по договору в некоторых контрактах, нам нужно действительно артефакты в определённом строгом, бюрократизированном виде заливать в confluлюнс. Ну, о'кей, давайте мы из вот этого инкремента будем генерировать отдельным скилом артефакт в формате, который требуется заказчику, и
Speaker A
заливать его в конфлюненс тем же самым скилом. Собственно, таким образом мы, по сути, закрыли этот вопрос для себя. То есть формально мы тоже для клиента действительно всё как как бы [фыркает] транслируем туда. А-а, идём дальше.
Speaker A
Аналитики на посмотрели а по умолчанию в Опенспеке Геркин. Они говорят: "Блин, ну Геркин тяжеловато читать". говорит: "Давайте мы всё-таки там привыкли к юзкейсам, давайте на юзкейсах это всё будем делать". Мы поменяли, да, то есть там по сути, э, [фыркает] OpenaS опять
Speaker A
же гибкий, мы там поменяли его промты, о'кей, теперь делает он в юзкейсах. Но на самом деле мы получили деградацию качества автотестов, и это нас заставило вернуться на Геркин как на основу назад.
Speaker A
И для некоторых элементов мы дополнительным скилом генерируем именно юзкейсы для того, чтобы у нас можно было какие-то юзкейсы полные, а, просмотреть.
Speaker A
Таким образом закрыли этот вопрос. Работа с мультирепа. А вот это такой хороший подводный камень, да, был.
Speaker A
Идеально, когда монорепа, когда у вас там условно все в монорепе, агент может ходить во все какие-то эти. Но у нас было как вот конкретно вот этот проект, про который рассказываю. Большой монолит. По факту это два монолита, два репозитория. Монолит фронтенда, монолит
Speaker A
бэкэнда, у него огромный такой шлейф истории многолетний. И ещё пачка сервисов и микросервисов вокруг него. И каждый в своём репозитории, собственно.
Speaker A
А мы хотим делать сквозной процесс сквозным чинжом, да? То есть и что мы сделали? Мы сделали скваз метрепозиторий, а который, э, командой up клонирует все репозитории, которые нам нужны. Вот в этом метарепозитории мы по сути поместили и наш Open Spect и
Speaker A
вообще разместили весь наш харнес, все наши основные скилы. Для того, чтобы агент понимал, в какие папки ему ходить, а в Agence MD мы просто описали, что что где находится для того, чтобы мог ориентироваться. На всякий случай, если кто-то не знал, что AGНC MD, как и Clou
Speaker A
MD, они рекурсивные, и вы можете вкладывать свой, то есть и в каждом репозитории есть свой ещё Agents MD или Cloud MD для того, чтобы это всё подтягивать. Собственно, таким образом мы, по сути, превратили, а, э, мультирепа в монорепа и получили вот
Speaker A
этот как раз профит, что агент действительно может ходить во все, и мы можем действительно одним ченджом в одном там конкретном домене сделать сквозное изменение через n-репозиториев.
Speaker A
Он пойдёт изменит и во фронтнде, и в микросервисе, и в монолите. Сквозное изменение это затащит.
Speaker A
А, ну вот там примерно как это может выглядеть, да, собственно, там Make File, там Agents Open Spec, вот лежит там папочка скилов у нас лежит там и прочие элементы хагнеса. И, собственно, там сервисы. Правда, единственное, что они у нас в папочке сервисов лежит
Speaker A
отдельно и где у него у каждых есть там, в том числе свой AGН ENCM MD.
Speaker A
А про трассировку смысла, а каждый комит мы заставили, а подписывать change, в том числе сделали проверку на прихуке. А для чего? А это вот на самом деле возможно давняя мечта даже не то что агента, это разработчика, да? Вот вот как часто мы заходим в
Speaker A
какой-нибудь код и такие: "Блин, а откуда это вообще родилось? Почему это здесь живёт?" И опспек на самом деле помогает это и агенту в первую очередь, и человеку.
Speaker A
Когда у нас каждый комит пописан ченджом, мы можем понять смысл, ради которого писалась эта строчка кода. И это классно, да? То есть можно прямо вдшки взять там через gitlame посмотреть и отрассировать к ченжу, к которому мы делали. Соответственно, это в том числе
Speaker A
подсказывает агенту. Агент точно так же, как и мы, может прийти в какой-то код и которыму вроде нужно здесь реализовать, а здесь уже часть реализована. А какого фига и в рамках какого намерения эта была часть реализована? И это помогает
Speaker A
ему трассировать. И что классно, это прям действительно работает. Это очень классно видеть, как агент заходит такой: "Так, а что это такое?" Типа такой: "Ага, я пошёл поищу спейки". Нашёл спеки, которые относятся именно к этим строчкам кода. Такой: "Всё, я понял, как
Speaker A
бы я там расширяю теперь вон ту реализацию, которая была". Короче, очень классно вот это рекурсивно он распутывает вот этот контекст.
Speaker A
Анжцентричная парадигма. То есть у нас в итоге вот этот чеange инкремент, вот если раньше мы жили вокруг задачи, то сейчас мы живём вот вокруг этого ченджа. И у него есть свой жизненный цикл, который на самом деле далеко не равен жизни Таски.
Speaker A
В том числе, потому что какие-то ченджи могут рождаться там техническим намерением. А когда, то есть там какой-то рефакторинг или какую-то небольшую техническую фичу мы затягиваем, и не обязательно там заводить, допустим, задачу для для этого в джире. Вот. Аа он начинается,
Speaker A
собственно, раньше он начинается на досках Recovery по факту, да, то есть в смыслах Recovery. Держит смыслы и дизайн, что тоже далеко не всегда в Таasске Gri есть. Поэтому в какой-то момент мы даже сделали с собой сервис визуализации жизненного цикла, а, спек
Speaker A
назвали его спек, э, никого не удивили. Собственно, сделали там в нём удобный поиск статистики, связи, статус прогресса. То есть вот там примерно вот так он выглядит. Аа, буквально за пару вечеров завайп-кодили, и он ещё в процессе очень плотного развития. В
Speaker A
каждый чейндж можно зайти. Вот те самые основные документы, а где вот в этом э прописано как раз примерно то, что мы собираемся реализовать.
Speaker A
А вопрос, который возникает в SD очень у многих, а вообще всё ли нужно делать через change? Да, то есть, а, и здесь явный ответ нет. То есть есть, ну, overhead, когда вам нужно действительно для этого сделать чеange, то есть, ну,
Speaker A
допустим, вам нужно поправить там цвет кнопки. Влияет ли это как-то на спеки? Нет, это не должно влиять никак на спеки, да? То есть там подвинуть эту кнопку, то есть э какой-нибудь баг по спеке. То есть на самом деле спек
Speaker A
описывает правильно, но у нас агент ошибся, да, и реализовал это неправильно. Тоже для этого не нужно поднимать ещё один чейндж. Вы говорите, просто можно допромтить эти элементы как раз там не тратя дополнительные усилия для того, чтобы там сделать этот
Speaker A
формальный артефакт. А, собственно, мы сделали регламент, который фиксирует вот что можно, что нельзя. Но если очень просто, да, то есть смысл в том, что если это как-то влияет на должно повлиять на спецификацию, на историю, которая полезна агенту, мы должны это
Speaker A
обязательно сохранять. И здесь важно, конечно, поддерживать э дисциплину. А [фыркает] технический чеange выделили. У нас прямо отдельной командой создаём чейн, в котором нет, к примеру, спек. Тот самый вот пример - это рефакторинг, когда мы меняем поведение, но не меняем
Speaker A
смысл, да, и нам мы говорим, что мы хотим от рефакторе, для чего, почему, да? То есть у нас и пропоз есть, и реализацию мы описываем, валидируем, и, собственно, реализацию и план мы также запускаем, но у нас, к примеру, там нет
Speaker A
спек. И вот про дисциплину, это про контроль. Аа, что по факту сейчас мы иногда боремся с некоторыми нарушениями среди разработчиков, а, и сейчас вот мы там в спеке как раз реализуем, аэ, чтобы был список комитов из всех мультирепа,
Speaker A
да, он агрегировался в один, и мы смотрели, какие комиты подписаны Чинджом, какие нет. В том числе можно проанализировать действительно, какие комиты разработчик сделал, а, по-хорошему, без ченджа, а, по-хорошему должен был сделать с Чинджом. Ну, вообще, конечно, можно сделать даже
Speaker A
агентвалидатор C, который будет этот факт проверять. Это вполне реальная моя задача. Это для нас не шаг какой-то.
Speaker A
Вот. Ну и нужно понимать, что как бы каждый раз, если там кто-то поленился создать change, он получает регресс качества нашего спецификации. Ну и в конечном замедление нашей работы и ухудшения качества. Аа коротко про наш харнес.
Speaker A
Просто дополнительно расскажу, что вот SDD мы его считаем как фундамент э нашего харнеса. И все там основные скилы, практики и всё остального мы на самом деле настраиваем сверху него. То есть для нас это вот как бы фреймворк и
Speaker A
сверху мы это всё настраиваем. [фыркает] И вот здесь вот некоторая карта а инженерных практик, а более продвинутых, которые мы для себя наметили. Они у нас в том числе в нашей дорожной карте для выхода на третий уровень автономности. И
Speaker A
здесь вот в этой карте важная мысль о том, что а мы э можем а эволюционно идти к третьему шагу. То есть на самом деле внедряя, усиливая практики второго уровня нашего текущего, мы уже прокладываем себе дорожку к третьему уровню. Это то есть, но важно очень
Speaker A
здесь выбирать правильные инструменты, потому что если выбирать некоторые инструменты, которые могут прибивать вас к второму уровня автономности, если вы хотите идти к более высокому уровн автономности, то нужно, к примеру, ну, не останавливаться, например, на плагинах, у которых нет кли варианта и у
Speaker A
которых нет сквозной обвязки, чтобы там одинакового исполнения, если у него есть даже кличный вариант, чтобы он одинаково работал, к примеру, не переиспользовал индексы.
Speaker A
Короче, чтобы вы могли действительно выйти на третий уровень, не переписывая потом в итоге свой харнес. Вот. А это набор практик. Мы где-то там, наверное, процентов 35 из этого списка сейчас внедрили, а по остальным плотно двигаемся и надеемся мы на третий
Speaker A
уровень выйти где-нибудь осенью. Собственно, скилы, а основные, то есть группы - это много чего берём из сообщества. Тот же самый Superpers, который тоже считает, что он SDD подход, а он мы его до сих пор используем, а используем в нём те скилы, которые а
Speaker A
там, к примеру, tтишную часть. Мы просто её берём. Её, конечно, можно выковырить, но мы пока не сделали. Просто, грубо говоря, в рамках apply а может вызваться такой: "Ага, мне нужно использовать TTD, я беру, подтягиваю скилл TTD и суперпаурса". И, к примеру, его
Speaker A
использую. Agent Browser отверстие используемся и скилы саж для дистрибьюции скилов. большое количество своих скилов. Очень много запариваемся с тем, чтобы агент не выполнял каких-то лишних операций.
Speaker A
Сейчас пока что анализируем это на локальном уровне, но но сейчас переходим к тому, чтобы собирать трейсы в LUS со всех разработчиков, с их локальных харнесов. Собственно, ставится плагинов в том же Cloud кода и и в кодексе ещё проще делается. А и, собственно,
Speaker A
анализировать это сквозным образом, смотреть, где делаются лишние тол-колы, которые мы можем оптимизировать. Собственно, мы уже так на этом уровне достаточно большое количество скилов своих костомных написали. Ну и вот как раз те самые обвязки Open Spec, они очень многие вот именно ложатся именно
Speaker A
на парадигму этого фреймворка. То есть и вот там разбиение работы по ролям, создание пирамиды тестирования, экспорт в confluence, критические вопросы, которые должны быть заданы там в рамках этого проекта. То есть это вот для нас всё идёт уже настраиваться над
Speaker A
обнспекто. Текущие эффекты, следствия. А здесь, конечно, про всё внедрение, не только про SDD. Аа, собственно, узкое бедство реально у нас на многих проектах сместилось. А, и сейчас у нас это либо в аналитике, либо в продукт-менеджменте, особенно вот на вх собственных
Speaker A
продуктах, которые у нас есть. У нас есть, да, конечно, бклок большой, но не все задачи, на самом деле на достаточном уровне проработки требований. И то есть действительно у нас очень много смыслов сместилось влево. И именно [фыркает] там часто затык, в том числе у нас затык, к
Speaker A
примеру, сейчас очень сильно в дизайнеров, которых мы я и не внедрили, и они до сих пор ещё в с фигме ручками иконки двигают, собственно, а не без агентов. Но, собственно, мы за это взялись и ребятка ребята уже подтягиваются. Вот. А эффекты
Speaker A
и бейзлайн, а как мы в том числе измеряли эффект? А у нас ещё до АИ был бейзлайн оценок всех. А, то есть мы посчитали, что любой сложный функционал можно разложить на простые элементы и эти простые элементы оценить и сделать
Speaker A
бейзлайн оценок. И, собственно, у нас был бейзлайн до того, как мы внедрили EI и SDD. И сейчас вот как бы в мае мы сделали, обновили его уже, когда у нас уже достаточно глубокий адопtionн, когда у нас хорошо практики раскатаны. А, и мы
Speaker A
поняли, что где-то мы получили аэ прямо кратное ускорение. Есть задачи, в которых мы считаем вообще нет ускорения.
Speaker A
То есть это всё зависит очень сильно от задач. И мы начали по-новому оценивать, ориентироваться на новый бейзлайн, и мы начали укладываться в эти оценки.
Speaker A
Собственно, для нас это и в том числе был доказательный эффект ускорения на своих же задачах. Выводы.
Speaker A
А внедряете вы сделал себе обязательно сквозным образом. Единый процесс, единая цепочка, единая шина контекста, которая у вас должна быть. SDD - это как раз тот самый ответ. Спеки как источник истины, общий язык для агентовлю людей. Ну и харнес - это движок, ядро вашего
Speaker A
производственного процесса. И именно на SDD рельсах оно едет гораздо увереннее. Спасибо. [аплодисменты] А QR с сердечком - это поставить хорошую оценку за доклад. Спасибо. И слева снизу Telegram-канал, где я рассказываю про то, что мы делаем.
Speaker A
Спасибо вам большое. Очень интересный доклад. Переходим к секции вопросов и ответов. И первую уроку, которую я увидел, был была вот эта.
Speaker A
Спасибо за доклад, очень интересно. Вопрос такой, что вот там были четыре уровня. И последний уровень - это фабрика, в которой выключен свет. И вот у меня вопрос: как вы видите вообще будущее агентств там по аутсорсу разработки?
Speaker A
Если условно будет достроен конвейер, когда там от идеи до условно прода оно всё будет автоматически делаться, там какая роль останется вот у таких компаний?
Speaker A
Чем они будут заниматься? Спасибо. А я не буду прямо сильно футуризмом заниматься. Опять же, до четвёртого уровня ещё пока что далеко, а загадывать в наше время на несколько лет вперёд сложновато, но а мы сейчас в процессе как раз штормим, что такое будущие роли
Speaker A
будущего. То есть действительно мы тоже идём к Солмсу, к схлопыванию. А мы, к примеру, понимаем, что вот аналитиков у себя полностью убрать не сможем. Почему?
Speaker A
Потому что на продуктов клиентов мы повлиять не можем, чтобы они, к примеру, спеки в нашем формате сразу делали. Ну и вообще там культура бывает у клиентов не всегда хорошая, да? То есть мы от них зависим. Поэтому где-то, к примеру,
Speaker A
аналитики останутся и где-то, то есть роли мы действительно собираемся схлопывать в каких-то проектах. У нас уже стартуем какие-то пилоты, на своих продуктах мы это протестили, это работает. А и то есть идёт всё схлопывание. И действительно вот вот этот Small Teams, да, то есть
Speaker A
действительно продукт и продукт плюс инженер - это, наверное, плюс-минус будущее. А если говорить про будущее агентств, ну не у всех будет вот этот самый харнес и продвинутые продукты и инженеры, которые смогут это слтим обеспечить. То есть, мне кажется, в
Speaker A
будущем мы точно также будем поставлять Small Teams с клиентом нашим. Вот рука следующая. Максим Ларшин.
Speaker A
[фыркает] А, привет. Очень классно. Сразу видно дофаминовый шок от внедрения, и это прямо хорошо. Значит, вопрос следующим.
Speaker A
Про маркировку, маркировку комитов через Change ID. Это охрененно классно, охрененно важно. Мы сейчас это всё себя костылим пока людьми с помощью редмайна и разных уровней. Ну там идея, фичие.
Speaker A
Вопрос в следующем, что если можно проскочить мимо этого, это же стала какая-то вещь опциональная, да? То есть то, что накомичено, то есть может быть какой-то комит, не привязанный кange ID, особенно если он технический. С чем я сталкиваюсь? Программисты очень любят
Speaker A
разлозить до техники. И дальше, ну, мы ковыряемся над какой-то маленькой технической задачкой и выкидываем из контекста этот change. А были ли у вас здесь какие-то проблемы с этим? То есть нет ли такого, что слишком много комитов, э, не промаркированы этим
Speaker A
чейнджем? Потому что, например, у нас это привязано к собственному учёту и времени людей, и эффективности фичи, и сколько мы её в неё вложили, сколько заработали с рынка, а, ну, и потом отчёты всяким разным там Минцифрам тоже для нас это важно. Вот есть ли у вас эта
Speaker A
проблема, то есть она вообще была? Если была, то решали ли вы ту проблему, что слишком много комитов не маркированы вот, ну, такой высокоуровневой как бы долгосрочной идеей, а просто типа я тут просто порефакторил, а заодно ещё и сделал половину какой-то там важной
Speaker A
фичи, но нет, прокировал её. Как я сказал, эта проблема есть. И, собственно, мы её начинаем решать.
Speaker A
Во-первых, это ещё сложнее усложняется у нас тем, что у нас мультирепа, да, пойди побегай со всех репозиториев, там пару десятков это всё пособирай.
Speaker A
Соответственно, мы вот тут сейчас собираемся внедрить в спек и начать контролировать, где, чтобы к каждому разработчику можно прийти с вопросом: "А почему это не промаркировано туда?" А во-вторых, действительно, чуть позже это сделать валидатор, который будет валидировать. То есть само количество
Speaker A
комитов нас не пугает. То есть, ну, маленький комит - это тоже хорошо. Маленький комит из трёх строк - это хорошо, это нормальный хороший комит валидный. То есть, если он [фыркает] как бы один смысл несёт, то есть нам важно,
Speaker A
чтобы не проскакивали туда комиты, которые не изменяют спеки. Угу. [фыркает] Вот в середине рука.
Speaker A
А, здравствуйте, аналитик системный Сбер. А вопрос: а что если к вам приходит новый проект, у которого там, не знаю, 50 микросервисов, и они не слышали ни о чём? Вы, не знаю, скупили конкурентов, например, как вы сейчас на основании опыта будете на это
Speaker A
раскатывать OpenS и все пироги. Вот прямо на самом деле описал наш вот вот тот тот самый большой проект, о которой в который мы внедрили. На самом деле мы внедрили в ряд уже проектов, но вот один из больших ключевых проектов. А
Speaker A
пришёл вообще ноль документации, ноль какого-то подхода. Собственно, ставим HNES и Open Spec он не заставляет вас, а реверсить обязательно всю спецификацию.
Speaker A
То есть он работает в режиме спека есть, нет. Есть, хорошо, спеки нет. Ну о'кей, буду по ходу дела разбираться. Ну как, как в принципе он бы разбирался, если бы как в принципе не было спеки. Можно ли отреверсить? Можно, но как бы там нужно
Speaker A
будет очень много вычитывать качества. То есть точно ли вы в это хотите инвестировать? Это вариант, это возможно, но как бы это такой дополнительный сложный путь. Некоторые, я знаю, реверсят. А мы пока просто как бы оставили режим. Вот есть вещи, на
Speaker A
которые мы написали спецификации, есть те, которые, ну, разбирайся по ходу, давай фидбэк в рамках эксплора.
Speaker A
Угу. Вот рука, молочк тянет уже и не опускает. Нет, нет, за ним. Привет, спасибо за доклад, Ван, э, сначала короткий вопрос. Я же правильно понял то, что вот, э, фраза ту просust в спеках имеется в виду по сравнению с
Speaker A
кодом. То есть у нас спека перед кодом становится. И не только для меня это что у меня нету ещё кучи разрозненных других источников контекста в разных системах, которые разбросен, что-то в джире, что-то в конфлюенсе и так далее. То есть в том,
Speaker A
что как минимум а источник истины весь, который нужно для реализации, он у меня сосредоточен всегда именно в репозитории. Вот можно ещё из с этого разреза посмотреть. Ну, то есть, чтобы поменять там код, мне в первую очередь нужно отредактировать релевантную спеку, и
Speaker A
потом от этого генерится код. Да, да, да. Ну, получается, тогда объём спеки по размеру примерно выглядит как код.
Speaker A
И да, ну, я просто пытаюсь понять, ну да, то есть действительно где-то может быть, ну, где-то может быть много спеки, а там реализации будет мало.
Speaker A
Где-то будет может наоборот мало спеки, а кода много он нагенит. То есть, ну, как бы связь не прямая. Один.
Speaker A
Почему? Почему именно такой подход? Вот почему не код, допустим, главный и рядом лежит спека?
Speaker A
Потому что в коде ты не можешь хранить всё намерение и всю реализацию. А, во-вторых, этот подход он в том числе позволяет качественнее реализовывать.
Speaker A
Когда ты продумываешь хорошо свой а смысл, что, зачем, как ты собираешься это делать, ты это контролируешь на раннем этапе, то у тебя и реализация становится гораздо лучше. Ну, на самом деле, не знаю, Cloud Code Super Power тот же с 200.000 звёзд. Они
Speaker A
все пришли к этому, что сначала запланируй, потом реализуй. Но, собственно, вот этот план - это очень важный артефакт, который потом а важно сохранять, да, потому что если вы его не сохраняете как артефакт, то вы теряете большое количество почему решения,
Speaker A
почему было принято такое решение, а это важные, то есть трейдофы, которые вы приняли. Это для агента и для человека потом важно.
Speaker A
Спасибо. Угу. Сложный выбор. Вот далеко не отходи. Вот давай дома. На одном из слайдов мелькал тул спек, который вы сами напилили вопрос, а он в openсорсе. И был ли он написан по спекам? Можно ли почитать, как продобре себя бреет? Был по спекам нахаб не
Speaker A
выложен. Реально его завайпкодить, ну, блин, 1-д вечера под себя сделать и так далее. Пока что мы, он как бы в процессе довольно-таки большой допилки, на него на самом деле много планов. Может быть, когда-нибудь выложим. Но опять же, это
Speaker A
дополнительный фокус, потому что как бы не всё хочется, а на в Open source надо это причёсывать, это нужно open source поддерживать, это всё равно какие-то затраты. Поэтому вот пока что никуда не выкидываем, пока что это вот внутренняя штука, но она настолько простая, что
Speaker A
реально просто там опиши, говорит, я вот хочу визуализацию, мне нужен список спек, что в нём. Построй по нему граф, выведи с этих репозиториев с него данные. Ну, короче, там его описать за вечер можно сделать вообще два вечера просто потому что в процессе делали.
Speaker A
Поэтому он не никакой тороке science несёт, на самом деле.
Topics:Spec Driven DevelopmentSDDавтономностьAI в разработкепарное программированиематрица зрелостимонолитхарнесавтоматизациятёмная фабрика
