**AI SDLC at Scale: как масштабировать агентную разработку. Асхат Уразбаев — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/ai-sdlc-at-scale-agentic-development-askhat-urazbaev/

Асхат Уразбаев (ScrumTrek) о масштабировании агентной разработки (AI SDLC): уровни зрелости от ИИ-ассистентов до управляемой автономии, команды будущего и spec-driven development.

## Key Takeaways

- Будущее разработки — небольшие команды с ИИ-агентами, а не большие структуры
- Эффективность агентов напрямую зависит от качества спецификаций и контекста организации
- Зрелость внедрения ИИ растёт постепенно: от ассистентов к управляемой автономии с харнесом и quality gates
- Человек остаётся ответственным за качество процессов и эскалацию системных проблем

## What the video covers

- Вступление: разработка ПО меняется, автор сравнивает роль ИИ с рабовладельческим обществом Древней Греции — людям остаётся управлять «рабочей силой» (токенами)
- Концепция маленьких команд: Tiny Team, Solo Team, Two Burger Team — продакт плюс один технический специалист способны создавать ценность
- Пример ScrumTrek: разработчик-агент в телеграм-чате принимает запросы сотрудников, большинство спецификаций закрываются в тот же день
- Перевод legacy-разработки на ИИ как отдельная задача, в отличие от полного переписывания с нуля
- Пять уровней зрелости: без ИИ, ИИ-ассистент в чате, локальный помощник в редакторе, агентный пайплайн, управляемая автономия
- На уровне агентного пайплайна улучшение процессов остаётся за человеком, который дорабатывает харнес (AI-harness) после ошибок
- Spec Driven Development победил Intent Driven Development как подход к постановке задач
- Quality Gate и красные флаги: при повторных провалах агента задача эскалируется человеку
- Лог решений: фиксация альтернатив и причин выбора вместо простого журнала действий
- Контекст организации повышает эффективность агентов; базы знаний и инжест документов (Markdown, PowerPoint) как основа

## Chapters

1. 00:00 Введение: разработка меняется и аналогия с рабовладением
2. 02:30 Команды будущего: Tiny Team и Two Burger Team
3. 05:30 Пример ScrumTrek: разработчик-агент в чате
4. 08:00 Пять уровней зрелости ИИ в разработке
5. 19:00 Агентный пайплайн и улучшение харнеса
6. 28:20 Spec Driven Development и контекст организации
7. 35:00 Legacy-разработка и инжест в базу знаний

Answers

## Questions about this video

Какие уровни зрелости использования ИИ в разработке выделяет автор?

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

Что такое команда будущего по мнению спикера?

Это небольшая команда, например продакт, знающий потребности бизнеса, и один технический специалист, которые с помощью ИИ-агентов способны создавать ценность. Спикер упоминает названия Tiny Team, Solo Team и Two Burger Team.

Почему важна спецификация и контекст организации при работе с агентами?

Агенты работают тем эффективнее, чем больше контекста о бизнесе и продукте они получают. Поэтому требования готовятся в виде спецификаций (Spec Driven Development), а документы загружаются в базу знаний через процесс инжеста.

## Full Transcript — Download SRT & Markdown

00:03

Speaker A

Итак, всем привет. Сегодня немножко поговорим про IASDLC. У нас на панельке эта тема затрагивалась. В целом мы много говорим о том, что разработка программного обеспечения меняется, и мы немножко поговорим, что это физически означает под капотами, какие-то примерки при попривожу, что это означает в целом

00:17

Speaker A

для организации. Э-э, пока все собираются, тоже такая вещь, тоже думал над тем, куда мы движемся как общество, когда вот придёт искусственный интеллект, да?

00:28

Speaker A

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

00:46

Speaker A

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

00:53

Speaker A

Были общества в истории человечества, в которых ценность производили ну, как бы не те люди, которые были внутри этого общества.

01:02

Speaker A

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

01:20

Speaker A

какая-то общественная нагрузка, он был магистратом. Потом он и шёл в гимназиум, там без штанов бегал, значит, занимался спортом, потом у него вечером симпозиум, где он винца выпил, и в целом как бы вот как бы вечер закончился. И оставалась у

01:33

Speaker A

него одна обязанность, которую с него не снимали, и лучше всего об этом сказал Аристотель, э-э, это собственно управление своими рабами.

01:42

Speaker A

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

01:56

Speaker A

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

02:08

Speaker A

И здорово было бы уметь ей управлять. И об этом мы с вами сегодня поговорим.

02:13

Speaker A

А, уже на панельке говорили о том, что есть понятие команда будущего. В 2024 говорю году мы что-то предсказывали, я на конференции рассказывал, что это вот какая-то как-то условная Discovery команда плюс один айтишник. И вот эти люди будут, значит, строить наше прекрасное будущее.

02:28

Speaker A

Значит, а по-разному их называют, вы слышали название Tiny Team, наверняка, да? Solo Team ещё я сегодня слышал. Ещё вот мне очень нравится название Two Burger Team. То есть, раньше это была команда Two Pizza Team, помните, да? Вот это Agile коучи все там. Ну, такая

02:41

Speaker A

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

02:54

Speaker A

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

03:08

Speaker A

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

03:23

Speaker A

переписываются все в компании, кому что-то нужно. Вот Оля Сухих у нас занимается а ме- методист открытых курсов. Вот она переписывается, значит, с этим разработчиком. И в принципе, он делает работу. Он смотрит и контент, он как бы всё умеет. Вот. И э

03:38

Speaker A

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

03:53

Speaker A

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

04:09

Speaker A

ну, тот же день time to market. То есть, это, ну, если в днях считать, равно равен нулю, да? То есть, он вот примерно вот такой вот. То есть, закрывается в тот же день.

04:17

Speaker A

Значит, как это технически работает? Давайте поговорим. Ну, помимо того, что мы, э, типа, сделали это себе, и сейчас ещё 18 проектов это используют, есть ещё задача, когда нам нужно какую-то, э, legacy разработку перевести на искусственный интеллект. Что такое

04:32

Speaker A

legacy разработка? У нас-то хорошо, мы взяли и всё переписали, сократили единственного разработчика, который у нас был, был. И, значит, теперь у нас как бы с нуля переписано всё, за несколько месяцев мы это сделали, и очень довольны. Скорость очень высокая,

04:44

Speaker A

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

04:56

Speaker A

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

05:05

Speaker A

ИИ-ассистент, спрошу ИИ. Это, знаете, когда вы в ChatGPT получили доступ, описали ему задачу, он вам сгенерировал функцию, вы её закопипастили, в Stack Overflow больше не ходите, вы просто там всё генерируете, это у вас работает.

05:16

Speaker A

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

05:30

Speaker A

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

05:44

Speaker A

работаете. У кого-нибудь квод, кто-нибудь квод-код использовал? Поднимите руки, просто интересно. Ага, примерно треть, отлично.

05:52

Speaker A

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

06:02

Speaker A

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

06:14

Speaker A

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

06:29

Speaker A

специальный агент, который, например, отвечает за написание кода, или агент, который отвечает за создание требований, агент, который отвечает за создание ещё чего-то, и вот они вот сквозным образом здесь вот так вот работают.

06:41

Speaker A

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

06:54

Speaker A

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

07:07

Speaker A

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

07:24

Speaker A

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

07:37

Speaker A

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

07:49

Speaker A

делаете, в Mattermost'е или в Slack'е, или ещё где-то. И и там дальше эта штука уже начинает крутиться. Вот примерно таким образом устроено. Но начинаем мы обычно с этого.

07:59

Speaker A

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

08:06

Speaker A

Все его активно используют. Это означает, что у продуктолога есть свой искусственный интеллект, и у разработчика, и так далее, и так далее.

08:13

Speaker A

Это к каким проблемам это приводит? Продуктолог написал какие-то требования. Эти требования не соответствуют тому, что находится в кодовой базе. В лучшем случае чуть-чуть соответствует тому, что написано в Confluence'е. Вот как-то это с этим связано.

08:28

Speaker A

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

08:35

Speaker A

Э-э, там, не знаю, как по объёму, как этот, э-э, Песнь льда и пламени, и по по по по сюжету это фэнтези. То есть, там вообще какая-то фантазия написана. И вы это потом скидываешь это на разработчика, давай делать. И он

08:46

Speaker A

пытается это всё превратить в код. Ругается что-то пишет, пытается всё поправить. Это в хорошем случае.

08:53

Speaker A

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

09:06

Speaker A

самым. Вот. И или второй вариант, что он делает, получает спеку, скармливает к воду и кнопочка дальше, да?

09:15

Speaker A

Approve approve approve approve approve, approve. И раз, у нас 200 подсистем контактов в нашей кодовой базе. Две системы отчётов выросли. И ещё какая-нибудь странная вещь. Всё перемешалось, ничего непонятно, всё выглядит отвратительно. Потом у нас возникает задача ревью кода. О'кей, мы

09:30

Speaker A

настряпачили м-м, тонну кода. Кто будет ревьюить? Обычно за это отвечают сеньор-девелоперы. Но они заняты.

09:37

Speaker A

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

09:46

Speaker A

Ну, в общем, короче, вот все эти истории. Значит, это нужно заменить на что? Скажите, как это исправлять? Вот это местечковое э-э внедрение искусственного интеллекта на штуку, которая называется а а, ну, вот ещё одна мотивирующая цитата. Это вот то, примерно, во что превращается

10:05

Speaker A

управление такими агентами а в такой, примерно системе. Это госпожа Простакова "То барыня ругается, то с теми дом держится, мой батюшка".

10:13

Speaker A

Превращается всё это в Spec Driven Development. Что такое Spec Driven Development? Это означает, что мы должны взять одну конкретную штуку, идею, превратить спецификацию с точки зрения того, что мы хотим получить а с функциональной точки зрения и постепенно, значит, у нас дизайн, то

10:29

Speaker A

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

10:44

Speaker A

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

10:58

Speaker A

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

11:10

Speaker A

А есть такой Если вы хотите в этом разобраться, то есть такой стандарт, который, мне кажется, с которого имеет смысл начать, он называется Open Spec.

11:17

Speaker A

Может быть, видели такую штуку. Его можно взять и начать использовать, он самый простой и понятный, вы, правда, сможете разобраться, если у вас есть квота и поковырять её. Работающая история совершенно очень просто. Есть Propose файлик, вернее, там skill, который называется Propose.

11:32

Speaker A

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

11:40

Speaker A

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

11:52

Speaker A

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

12:07

Speaker A

скилла можно пронести всё это вот в эту папочку. У нас всегда готовы актуальные требования. Это называется Spec Driven Development, подход, который победил, потому что был ещё Intent Driven Development и мы тут сражались, как правильно. Intent Driven Development, простите, не выжил, поэтому Spec Driven

12:22

Speaker A

Development наше всё. И здесь мы двигаемся примерно вот таким вот подходом. При этом есть понятие Zero Assumption, который ввёл Андрей Карпатый, и смысл его очень простой.

12:30

Speaker A

Zero Assumption означает никаких скрытых допущений. Всё, что можно будет понять не так, мы должны по брейнштормить. Там есть даже специальные скиллы в Open Speke, которые называются, по-моему, Explore. В этом Grilme называется Spekity, да. То есть, а смысл в том, что

12:45

Speaker A

он должен со всех сторон и за всех сил понять, что может пойти не так и все такие Zero Assumption, все Corner Case, все вычистить оттуда вот на этом этапе.

12:54

Speaker A

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

13:01

Speaker A

Потому что если мы так не сделаем, во что это превратится? На этапе валидации результата вы будете всё переписывать, боль, страдания, сопли и и ругань будет, да? Жень, что-то хотел сказать?

13:22

Speaker A

Вот здесь понятие быстро поменялось. Вот быстро всё ещё быстро, всё ещё за один. Просто мы больше можем сделать.

13:36

Speaker A

А, в этом смысле это анти-джава. У нас у нас много анти-джава. Вот, например, одна из вещей, которые тоже относятся к анти-джава, извиняюсь за выражение, есть понятие там факинг-фокус. Помните такая штука? Когда мы говорили всем: "Ребята, сосредоточьтесь на одной задаче.

13:53

Speaker A

Мультитаскинг это зло". А теперь кто такой производительный разработчик? У него три чата одновременно с разными задачами открыто.

14:01

Speaker A

Нет. Нет, это вот надо надо, потому что иначе тебя уволят из компании, где требуется высокая производительность. Поэтому да, вот этот факинг-фокус исчез. Почему?

14:11

Speaker A

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

14:21

Speaker A

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

14:30

Speaker A

А ну, я думаю, это наша специфика, но смысл в том, что как бы это приводит к тому, что он становится становится более многословным. Появляется штука AI-харднес. Вы слышали такое понятие?

14:39

Speaker A

Мне просто нужно примерно понимать ваш уровень. Поднимите руку, кто слышал слово AI-харднес. А, все знают. Ну, отлично. Практически. AI-харднес это обвязка. Что такое обвязка? Правильный, кстати, перевод не обвязка, а упряжка для наших агентов. Я бы даже сказал ярмо

14:54

Speaker A

в некотором смысле. То есть это что-то, что заставляет их определённым образом работать. AI-харднес. Как он устроен?

15:00

Speaker A

Если вы используете Cloud Code или кодекс или что-то похожее в этом духе, у вас есть модель, как внутри которой тоже есть Вернее, модель-подход, внутри которого тоже есть свой харднес.

15:10

Speaker A

Он должен уметь прочитать экспорт, там есть там есть планирование, он умеет план делать, запускать, проверять и в общем, короче говоря, сам Cloud Code умеет такой харднес базовый гонять.

15:20

Speaker A

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

15:32

Speaker A

Он умеет тестировать, умеет проверять, получается ещё больше тестов, как бы знаний в виде markdown файлов мы ему даём, чтобы он больше умел. Это есть AI харнес, обвязка такая.

15:42

Speaker A

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

15:58

Speaker A

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

16:11

Speaker A

использовать, надо туда-то, туда-то посмотреть, что-то почитать, прежде чем принимать какие-то решения. То есть мы ему рассказываем, как работать. И также со всеми остальными ролями. Разработчик у нас умеет проектировать и писать код и так далее. У нас получается вот такой

16:22

Speaker A

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

16:37

Speaker A

называется агентный пайплайн. У нас чуть-чуть сложнее это устроено эволюционно, у нас всё это развивалось.

16:43

Speaker A

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

16:55

Speaker A

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

17:03

Speaker A

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

17:19

Speaker A

И получается, что для какой-то команды, для какого-то скива вполне возможно разные агенты будут работать над этим. И оркестрировать всё это будет TPM, Technical Product Manager, который является оркестратором всего этого хозяйства.

17:33

Speaker A

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

17:47

Speaker A

Э-э, ревью не успевает за агентом, да. Что значит двуголовый? Я, может, не знаю. А, мы используем две модели, да. То есть, мы используем э-э ревью делает всегда другая модель. То есть, например, если мы пишем с помощью модели э-э

18:02

Speaker A

Anthropic, то ревью делает э-э Codex и наоборот. По-моему, нет. Я не знаю в деталях. Но это мы всё время меняем, там у нас этих Надо у Серёжи уточнить уже последнее видение, по-моему, нет. Итак, агент э-э ревью не успевает за агентом, мы

18:18

Speaker A

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

18:32

Speaker A

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

18:48

Speaker A

говорил, в B1 и прочие такие вещи, это это это очень умным надо быть, чтобы это всё как бы и проще нажать дальше.

18:54

Speaker A

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

19:11

Speaker A

а не собственно саму работу, потому что это становится местом. Нужно, чтобы он просто понятно объяснял, чтобы мы могли с этим работать. Мы экспериментировали и выбрали такой подход, мы назвали это decision log, то есть он на тебя вываливает не свой просто чат, что он

19:24

Speaker A

сделал, что не сделал, а некий структурированный файл. Фактически нам нужно log решений. Какие были альтернативы при принятии решений?

19:32

Speaker A

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

19:47

Speaker A

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

20:01

Speaker A

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

20:15

Speaker A

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

20:30

Speaker A

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

20:44

Speaker A

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

20:53

Speaker A

Какие у нас есть подходы? Первую штуку, которую мы должны сделать, мы назвали промежуточный контроль.

21:00

Speaker A

А э-э ну а нет, это сначала немножко о результатах. Значит, у нас доля починок не растёт с возрастом проекта. То есть здесь, от 9 до 14% коммитов у нас это починка.

21:12

Speaker A

И, несмотря на то, что кодовая база растёт, количество, как бы, починок при этом не падает. То есть, мы, в принципе, более-менее справляемся с тем, что чиним наш код более-менее эффективно.

21:22

Speaker A

А, как это делается на практике? Есть такое понятие Quality Gate. Quality Gate - это некоторый контроль качества. Это специальная проверка после определённого этапа, что у нас всё хорошо.

21:32

Speaker A

Если агент эту про- проблем- агент сделал какую-то работу, мы начинаем проверять его работу. Если он сделал что-то неправильно, мы возвращаем ему на доработку. Мы отдаём ему список замечаний.

21:43

Speaker A

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

21:57

Speaker A

инженер, и попытаться её нам решить. Это вот такой Quality Gate. А, значит, вот наш пример Quality Gate'ов. Спецификация согласована с владельцем, всё хорошо. Приёмка, то есть, продукт, который мы разработали, соответствует функциональным, нефункциональным требованиям. Он ещё не технически не обязательно грамотный, но

22:15

Speaker A

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

22:22

Speaker A

Проверки технические, что у нас сделано, и документацию в конце тоже нужно Quality Gate по ним сделать. Это внутренние проверки внутри нашей системы. То есть, как мы проверяем то, как работает наша система внутри самой команды. Есть ещё внешние проверки. У нас их, понятно, нет, но в

22:38

Speaker A

целом в других компаниях мы такую штуку строим. Это один из способов масштабировать как раз разработку. О чём идёт речь? У архитектора есть свои требования к тому, как всё должно быть устроено внутри организации.

22:51

Speaker A

Сейчас мы, если мы масштабируем с помощью Tiny Teams или там вот этих Two Burger Teams нашу разработку, получается, что мы быстро на них вываливаем кучу кода или там кучу каких-то решений, идите ревьюйте. И они становятся узким местом процесса. То

23:04

Speaker A

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

23:17

Speaker A

конкретный человек, который за это отвечает, security officer, не с не успевает нас ревьюить. Э что означает фактически вот ну там на панельке говорили агентизировать работу такого типа людей, которые оунят не команду, а проблему внутри организации.

23:30

Speaker A

Архитектуру. Может быть даже процессы какие-то, Agile какой-нибудь там, не знаю, как они планируют, ещё что-то в этом духе. Вот короче говоря, вот такого типа люди, как они должны работать, чтобы не становиться тормозом? Они создают своих агентов, которые встраиваются в эти quality

23:45

Speaker A

gates. То есть фактически их задача, то есть задача, вернее, нашей разработки пройти через quality gate этих внешних и вот этих вот агентов, которых написали нам замечательные архитекторы. Понятно, что это работает с разной степенью крутости пока, но в целом это некоторое

23:59

Speaker A

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

24:12

Speaker A

Тебе не нужно, тебе нужно написать одного агента. А с это означает, ты тоже тайнитим, у тебя вас тоже двое теперь.

24:19

Speaker A

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

24:29

Speaker A

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

24:34

Speaker A

Мы можем таким образом это всё через quality gate этим процессом управлять. Но решение иногда возвращается человеку, и эти правила тоже должны э-э быть обсуждены. Ну вот наш пример, как мы это делаем.

24:47

Speaker A

А новая архитектура требуется. Ой, давайте поговорим об этом. Высокая цена ошибка ошибки, тоже об этом сейчас чуть-чуть поговорим поподробнее.

24:55

Speaker A

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

25:03

Speaker A

Бывает так, что вы даёте очень простую задачу вашему агенту с вашей точки зрения. Он уходит на месяц, не на месяц, там, не знаю, на на на не знаю, на 8 часов в разработку и перефигачивает всё, перестраивает, потому что он нашёл

25:15

Speaker A

corner case, поправил его, это привело к новому corner case, он ещё раз поправил, и он начинает бегать вот так по кругу, перелопачивая всю кодовую базу. Почему?

25:25

Speaker A

Ну, потому что надо. А может, таких corner case of ты и нет в жизни, понимаете? Таких пользователей нет. Он же этого не проверял, он этого не знает, у него данных может не быть.

25:33

Speaker A

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

25:44

Speaker A

Потому что мы просто потратим кучу денег на это. А как следующая вещь, которая называется blast radius, насколько далеко разойдётся ошибка ошибка. Это к вопросу масштабирования. Смотрите, я внутри команды что-то поменял. Э, поменял два поля местами. Да бог с ним, я как

25:59

Speaker A

product могу выкатить это в продакшн и мне никто не нужен, мне не нужен никакой каст, мне никакой ревью наружу не нужно.

26:05

Speaker A

Если это затрагивает соседнюю команду, значит, мне нужно какое-то внешнее ревью. Чем больше blast radius, чем больше радиус поражения, или я, например, хочу центральный компонент поменять, который определяющий для всех команд. Радиус поражения большой, соответственно, здесь нужно будет остановиться, сделать ревью, и вот здесь

26:22

Speaker A

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

26:37

Speaker A

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

26:51

Speaker A

масштабируется. Так, у меня мало времени осталось". Ретроспектива наша с вами любимая. Давайте поговорим, как проводить ретроспективы.

26:59

Speaker A

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

27:14

Speaker A

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

27:26

Speaker A

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

27:37

Speaker A

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

27:53

Speaker A

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

28:06

Speaker A

это происходит относительно редко. И наконец, Never Again - это память об об ошибках. То есть, если что-то пошло не так э-э в работе самого харнеса. То есть, харнес его там, не знаю, тикет не обновили в джире, хотя должны были.

28:20

Speaker A

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

28:29

Speaker A

Э-э Дальше. Ну, и вот ка- количество Never Again, то есть вначале, пока писали, было их много, ну, потом постепенно их количество постепенно как бы стабилизируется. В принципе, когда у нас плюс-минус стабилизирована архитектура, понятно, как делать, у нас правила

28:42

Speaker A

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

28:59

Speaker A

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

29:13

Speaker A

чтобы ретро проводить, они сами себе ретро проведут. А мы просто им немножко в этом смысле подсобим.

29:21

Speaker A

Последняя здесь история структура команд, а ну наверное достаточно понятная вещь, кто слышал про Team Topologies, ничего нового тут мы не изобретаем. У нас появится у каждой команды безусловно свой Harness, но им нужен некоторый общий общий подход. Для того, чтобы мы например те же Quality

29:36

Speaker A

Gate могли понятным бесшовным образом строить. Ну если просто у каждой команды будет всё по-своему, мы не сможем это сделать. То есть всем нужен Spec Driven Development. Например можно стандартизировать использование подхода Open Spec внутри организации. Делайте что хотите, но вот Open Open Spec

29:50

Speaker A

используется определённым образом. Определённым образом структурированные базы знаний базы знаний внутри организации таким образом, чтобы агенты могли одновременно это использовать, такие кросс-агентные у нас были бы а какие-то истории. И вот за это отвечает команда, которая обеспечивает этот AI Harness. А

30:07

Speaker A

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

30:18

Speaker A

Но справедливости ради, они всё-таки маленькие. Вот по сравнению с тем, что я что что я бы ожидал на самом деле, там один-два человека, это тоже Tiny Team. Если раньше бы там сидело там 20 инженеров, сейчас там сидит два человека. То есть

30:30

Speaker A

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

30:42

Speaker A

огромное количество всего здесь, поэтому команды всё-таки при этом небольшие. И какая-то enabling team, которая всё это внедряет внутри организации. То есть мы как начинаем? Мы обычно с пилота начинаем, берём одну команду э-э замечательную штуку, которую мы всегда используем, kick-off делаем, то

30:57

Speaker A

есть запуск команд, всем очень нравится. Давайте kick-off команды сделаем. Команде соответственно появляется такая enabling team, которая помогает это всё запускать.

31:05

Speaker A

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

31:16

Speaker A

говорил, универсальности нам нужен. Нам нужно универсализировать э-э какие-то подходы внутри команды. Контекст важен. Это я на, по-моему, прошлой конференции в двадцать пятом году context is king, нам нужен контекст. Это следующая вещь, которую мы, скорее всего, будем решать уже в следующем

31:31

Speaker A

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

31:47

Speaker A

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

32:00

Speaker A

обсуждала несколько раз, поменяла решение, ну, там надо было в CRM-ке э-э связанные имейлы найти, которые связаны с этой сделкой. Концепция поменялась, просто вытащили более полный контекст из созвонов и уточнили постановку. Если бы этих созвонов там не было, мы бы просто

32:15

Speaker A

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

32:27

Speaker A

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

32:41

Speaker A

Ну, я думаю, в целом, если такие организации строить, то это вот задача следующего года. И здесь, кстати, маленькой организации проще.

32:49

Speaker A

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

33:01

Speaker A

организацию, то это очень долгий и довольно тяжёлый процесс. А-а, наш этот, м-м, QR-код нашего, э-э, как назвать, господи, Telegram-канала. Да, да, спасибо.

33:14

Speaker A

Ставьте лайки, подписывайтесь. Да, в запрещённом в Российской Федерации. Так, сколько у меня на вопросы? 2 минуты, я вижу.

33:20

Speaker A

Да, у нас сейчас, э, по расписанию 20 минут перерыв, но я думаю, мы несколько минут уделим вопросам. По руке, пожалуйста, по очереди будем.

33:30

Speaker A

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

33:37

Speaker A

Скажи, пожалуйста, а вы information aware на компанию как строите? Смотри, всё валится в базу знаний, а куда и как?

33:45

Speaker A

Как Карпаты завещал, трёхуровневая или что? Да, да, да, в основном так. То есть, соответственно, технически в большинстве случаев мы начинаем с просто с набора Markdown-файлов.

33:54

Speaker A

Вот, соответственно, они просто у нас в репозитории хранятся. Как конкретно, это очень сильно зависит от организации, потому что кому-то что это нельзя, кому-то то нельзя, эти не могут Git использовать, этим ещё что-то. Вот как конкретно технически это делается

34:05

Speaker A

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

34:22

Speaker A

придётся захватить. Это всё, что связано с тем, как бизнес устроен по метрикам, по, по структуре, кто за что отвечает и так далее. Вот это вот на самом деле небольшой объём информации. Потом берём какой-то один сквозной процесс, например, это вот нам сейчас компания

34:35

Speaker A

работаем, ну, к там, не знаю, чаще всего это прямо который бизнес related, например, процесс продаж в B2B.

34:41

Speaker A

Ну, то есть, как завещали опять же классики, берём какой-то value chain, да? Да. Ценность потом его автоматизируем, потом следующий, следующий, следующий берём. И где-то останавливаемся. Прямо до конца доводить не надо, потому что даже в нашей компании ну, человек стоит там

34:53

Speaker A

40.000 руб. Ну, как бы, я сейчас пойду потрачу 3 месяца на это, ну, типа, нафига мне это надо.

34:58

Speaker A

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

35:06

Speaker A

А, есть, смотри, там чуть-чуть сложнее получается, к сожалению. Первое дело, нам нужно выстроить антологию.

35:12

Speaker A

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

35:27

Speaker A

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

35:36

Speaker A

Соответственно, есть зависимости, что от кого зависит. Это антология называется. А потом у нас есть, как правило, коробка на несколько десятков гигабайт файликов, которые есть в любой организации, эксели, какие-то пауэрпоинты, где всё это либо структурировано, либо не структурировано, как повезёт, валяется.

35:54

Speaker A

И соответственно, нужно запустить процесс, который называется инжест, это всё нужно обсосать в базу знаний, потому что иначе искусственный интеллект не сможет там, потому что пауэрпоинт файл, он не сможет по ним быстро работать. Это нужно всосать в базу знаний. Этот вот

36:05

Speaker A

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

36:17

Speaker A

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

36:30

Speaker A

скапливается в такую э-э ну, LLM базу знаний в виде набора Markdown файлов, с которой уже может работать искусственный интеллект. Может ему вот в Клод это всё положить, сказать ему: "Уважаемый Клодик, а как отдай нам коммерческие предложения по канбану, которые мы делали в за эти

36:46

Speaker A

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

37:03

Speaker A

"Мне Я ещё там проговариваю какие-то детали, потому что знаю, что у меня запись есть, поэтому лучше проще там проговорить какие-то детали. А он потом мне коммерческое предложение сделает почти всегда сразу правильно. Теперь.

37:15

Speaker A

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

37:25

Speaker A

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

37:37

Speaker A

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

37:44

Speaker A

Иногда он непрозрачен совершенно. Ну, вроде прикольно стало. К Хогвартс такой. Показываешь, людям нравится, независимо от того, есть эффект или нет.

37:55

Speaker A

А, Асхаб, спасибо за доклад. У меня вопрос про метрики. Угу. А, мы всё это делаем для того, чтобы повысить эффективность, ну, например, разработки, а, процессов и так далее.

38:08

Speaker A

Есть стандартные метрики там, мы работаем с ресурсами, качество, скорость. Вот здесь добавляются ещё какие-то, либо мы смотрим на то же самое и просто смотрим, как это изменилось.

38:19

Speaker A

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

38:33

Speaker A

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

38:45

Speaker A

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

38:56

Speaker A

какой-то дополнительной метрикой, на которую мы можем смотреть. Но в целом бизнесу нравится time to market. Причём time to market не как мы в аджайле понимаем, да, от момента, как мы начали работать, до момента, как мы закончили, от момента, как есть идея до момента,

39:08

Speaker A

когда реализовано. То есть такой широкий lead time такой, не cycle time, а какая-то длинная история. Вот вот вот эта штука им нравится, что у меня есть идея, в этот же день у меня это Ну, там, хорошо, это если вот

39:19

Speaker A

там в предельном случае green grass, когда мы с нуля всё строим, greenfield, да? Это может быть один день. Ну, всё равно мы это постепенно сокращаем, я уверен, что м-м, через там, не знаю, год, два, три, когда просто cloud, может

39:30

Speaker A

быть, будет уметь это из коробки. Представляете, как будет круто? Вы ему говорите: "Вот база знаний организации.

39:37

Speaker A

Засоси её в LLM Wiki". Он такой: "Ща всё сделаю. Утром приходи, всё будет готово". Утром пришёл, там всё готово.

39:43

Speaker A

Вот это было бы круто. Ну, не думаю, что так прямо будет работать, но как бы инструменты чем дальше, тем больше могут.

39:50

Speaker A

Есть такая история. Метрики не умеем. Очень хотим научиться, пробуем, есть идеи. Было бы здорово тоже на эту тему поговорить.

40:00

Speaker A

Ещё вопросы? А? Time to yes, это что такое? Ну, может быть, да. Ну, вот это всё всё про скорость принятия решений, ты имеешь в виду, да? Да, да, наверное, это тоже тоже, наверное, было бы прикольно мерить.

40:14

Speaker A

Супер. И? И тогда И тогда всё, всем спасибо. Спасибо тебе, тебе спасибо большое.

Topics: AI SDLC агентная разработка spec driven development AI-харнес маленькие команды ИИ-агенты управляемая автономия база знаний legacy ScrumTrek

Учить по этому видео

- [Карточки по этому видео](https://sozai.app/ru/tools/flashcard-maker/?from=transcript&id=90965)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=90965)
- [Кроссворд по этому видео](https://sozai.app/ru/tools/crossword-maker/?from=transcript&id=90965)
- [Филворд по этому видео](https://sozai.app/ru/tools/word-search-maker/?from=transcript&id=90965)
- [Шпаргалка по этому видео](https://sozai.app/ru/tools/study-guide-maker/?from=transcript&id=90965)

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.


---
This is the markdown twin of https://sozai.app/transcript/ai-sdlc-at-scale-agentic-development-askhat-urazbaev/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/