Why your AI product needs a different development lifecycle

Почему вашему AI-продукту нужен другой цикл разработки

Представляем фреймворк Continuous Calibration/Continuous Development (CC/CD)

👋 Добро пожаловать в ✨ бесплатный выпуск ✨ моей еженедельной рассылки. Каждую неделю я разбираю вопросы читателей о создании продукта, росте и развитии карьеры. Больше материалов: Lenny's Podcast | How I AI | Lennybot | Курсы

P.S. Годовые подписчики получают бесплатный год 15+ премиум-продуктов: Lovable, Replit, Bolt, n8n, Wispr Flow, Descript, Linear, Gamma, Superhuman, Warp, Granola, Perplexity, Raycast, Magic Patterns, Mobbin и ChatPRD (пока есть в наличии). Оформите подписку.

В эпоху AI техническим лидерам приходится пересматривать каждую отраслевую best practice по созданию отличных продуктов. AI-продукты просто строятся иначе. Команды, которые осознают это и быстрее адаптируются, получат огромное преимущество.

Основываясь на опыте руководства более чем 50 внедрениями AI в таких компаниях, как OpenAI, Google, Amazon, Databricks и Kumo, Aishwarya Reganti и Kiriti Badam разработали фреймворк Continuous Calibration/Continuous Development (CC/CD), специально предназначенный для решения уникальных задач при выпуске качественных AI-продуктов. В этом посте они впервые делятся им с вами.

Чтобы узнать больше от Aish и Kiriti, посмотрите их популярный курс на Maven и предстоящий бесплатный lightning talk, где эта тема разобрана подробно.

Если вы продакт-менеджер или билдер, выпускающий AI-фичи или продукты, вы наверняка ощущали это:

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

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

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

Нельзя строить AI-продукты так же, как другие продукты, по двум причинам:

AI-продукты по своей природе недетерминированыКаждый AI-продукт должен балансировать между агентностью и контролем

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

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

Давайте пройдёмся по тому, чем создание AI-продуктов отличается от традиционного ПО.

1. AI-продукты по своей природе недетерминированы

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

AI-системы ведут себя иначе. Они привносят недетерминизм с обеих сторон: то есть существует непредсказуемость и в том, как взаимодействуют пользователи, и в том, как отвечает система.

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

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

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

2. Каждый AI-продукт балансирует между агентностью и контролем

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

Агентность в этом контексте — это способность AI-системы предпринимать действия, принимать решения или выполнять задачи от имени пользователя (отсюда и термин «AI-агент»). Например:

Бронирование рейсаВыполнение кодаОбработка тикета поддержки от начала до конца

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

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

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

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

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

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

Мы называем его CC/CD: Continuous Calibration/Continuous Development.

Название отсылает к Continuous Integration/Continuous Deployment (CI/CD), но, в отличие от своего тёзки, оно предназначено для систем, где поведение недетерминированно, а агентность нужно заслужить.

Фреймворк Continuous Calibration/Continuous Development

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

Фреймворк CC/CD спроектирован так, чтобы работать с этими двумя реалиями, путём:

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

В нашем фреймворке создатели продукта работают в непрерывном цикле разработки (CD) и калибровки (CC). Во время разработки вы определяете рамки задачи, проектируете архитектуру и настраиваете оценочные метрики, чтобы держать недетерминизм под контролем. Вы начинаете с фич с низкой агентностью и высоким контролем, а затем постепенно поднимаетесь по мере того, как система доказывает, что может справляться с большим.

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

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

Давайте разберём каждый шаг цикла CC/CD подробнее: как он выглядит, почему важен и как делать его хорошо. Первые три шага составляют сторону Continuous Development цикла: определение возможности, настройка приложения и проектирование eval-ов.

CD 1. Определите возможности и подберите данные

Допустим, у вас есть большая продуктовая идея, и вы уже провели исследование. Очевидно, что AI — правильный подход. В традиционной разработке ПО вы обычно планировали бы v1, v2, v3 нового продукта на основе глубины функционала или потребностей пользователей. С AI-системами версионность всё ещё применима, но угол зрения меняется.

Здесь каждая версия определяется тем, насколько большой агентностью обладает система и насколько большим контролем вы готовы пожертвовать. Поэтому вместо того, чтобы мыслить наборами фич, вы определяете рамки возможностей. Начните с выявления набора фич, которые имеют высокий контроль и низкую агентность (версия 1 на изображении выше). Они должны быть небольшими, тестируемыми и легко наблюдаемыми. Отсюда подумайте, как эти возможности могут эволюционировать со временем за счёт постепенного увеличения агентности — по одной версии за раз. Цель — разбить грандиозное конечное состояние на ранние формы поведения, которые вы можете оценивать, итерировать и наращивать сверху.

Например, если ваша конечная цель — автоматизировать customer support в вашей компании, способом с высоким контролем было бы определить v1 (версия 1) просто как маршрутизацию тикетов в нужный отдел, затем перейти к v2, где система предлагает возможные решения, и только в v3 позволить ей автоматически закрывать тикеты с откатом к человеку.

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

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

Вот ещё пара примеров:

Маркетинговый ассистент

v1: Создаёт черновики писем, объявлений или соцсетей по promptsv2: Создаёт многоступенчатые кампании и запускает ихv3: Запускает, проводит A/B-тестирование и авто-оптимизирует кампании по разным каналам

Coding-ассистент

v1: Предлагает инлайн-дополнения и boilerplate-сниппетыv2: Генерирует более крупные блоки (например, тесты или рефакторинги) для проверки человекомv3: Применяет ограниченные изменения и автономно открывает pull requests (PRs)

Если вы следили за тем, как развивались инструменты вроде GitHub Copilot или Cursor, это ровно тот сценарий, который они использовали. Большинство пользователей видят только текущую версию, но базовая система поднималась по этой лестнице постепенно. Сначала автодополнения, потом блоки, потом PRs — и каждый шаг был заработан через использование, обратную связь и итерации.

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

В примере автоматизации customer support, для версии маршрутизации (v1), ваш референсный датасет мог бы включать:

Запрос пользователяОтдел, в который он должен быть направленМетаданные, использованные для принятия решения: тип продукта, тарифный уровень или канал

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

Мы продолжим использовать пример customer support, чтобы пройтись по следующим шагам цикла CC/CD. Представьте, что вы строите полностью автономную систему поддержки для компании. Ниже — версии, к которым мы будем обращаться, вместе с соответствующими уровнями агентности и контроля. Мы будем ссылаться на v1, v2 и v3 на протяжении остальной части поста.

CD 2. Настройте приложение

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

В софте есть знаменитое высказывание, и не зря: «Преждевременная оптимизация — корень всех зол.» Это применимо и здесь. Не переусердствуйте с инженерией. Не переоптимизируйте. Не на этом этапе. Просто не надо. Стройте только то, что нужно для текущей версии. Сделайте систему измеримой и итерируемой, настроив логи, которые фиксируют, что система видит от пользователя, что она возвращает и как с ней взаимодействуют. Это станет основой вашего датасета живых взаимодействий и поможет улучшать систему со временем. Мы не будем уходить в реализацию здесь, но если вы выпускаете это на конечных пользователей, убедитесь, что базовые вещи вроде guardrails и compliance на месте.

Ещё один важный момент: при настройке приложения убедитесь, что контроль можно бесшовно передавать обратно людям, когда это нужно. Будем называть это передачей контроля (control handoffs). Например, в v1 customer support, если тикет был неправильно направлен, принимающий агент (контактное лицо отдела) должен иметь возможность легко его перенаправить. Поскольку эта корректировка логируется, она не только помогает улучшать систему со временем, но и сохраняет пользовательский опыт. Думать о control handoffs с самого начала — ключ к построению доверия и к тому, чтобы вещи оставались восстанавливаемыми.

CD 3. Спроектируйте eval-ы

Это часть, которая обычно требует некоторого размышления. Прежде чем что-либо выпускать, нужно определить, как вы будете измерять, делает ли система то, что вы ожидаете, и готова ли она к следующему шагу. Это делается с помощью оценочных метрик (evals, для краткости).

Итак, что такое evals?

Evals — это механизмы оценки, которые помогают понять, работает ли ваша AI-система, где она проседает и что нужно улучшать. Думайте о них как об аналоге тестов в традиционном ПО. Но, в отличие от обычных unit- или integration-тестов, где входы и выходы фиксированы, а корректность бинарна, AI-evals имеют дело с неоднозначностью.

Они полностью специфичны для приложения и привязаны к задаче, которую вы определили на шаге 1. Вы не просто проверяете, что система работает — вы проверяете, насколько хорошо она делает что-то по своей сути недетерминированное, например, суммирует документ или отвечает на вопрос. Поэтому evals — это не one-size-fits-all. Они служат сигналами, направляющими ваш цикл итераций, помогая настраивать и оттачивать поведение со временем.

Например, в v1 системы customer support с маршрутизацией простой, но сильный eval — это точность маршрутизации: как часто система направляет тикет в правильный отдел. Уже это может сказать вам, учится ли модель правильным различиям и насколько надёжна ваша настройка.

В v2 системы customer support, где вы извлекаете внутренние standard operating procedures (SOPs) или прошлые решения, чтобы помочь агенту, ваши evals смещаются к качеству извлечения (retrieval quality). Действительно ли предложения релевантны тикету? Это ли посмотрел бы человек-агент?

Одна из лучших практик на этом этапе — прогонять evals по референсному датасету из шага 1. Это помогает оценить производительность, проверить, хорошо ли спроектированы ваши evals, и внести ранние правки в настройку продукта из шага 2. Некоторые команды ждут до развёртывания, чтобы доработать, опираясь на реальные взаимодействия с пользователями. Этот подход тоже может работать, в зависимости от рискового профиля системы и того, сколько референсных данных вы можете собрать заранее.

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

Чтобы глубже погрузиться в проектирование и доработку evals, отличной отправной точкой будет материал Aman.

Как только вы реализовали систему и убедились, что она правильно очерчена и оснащена инструментарием, пора развёртывать. Развёртывание — это переходная фаза между циклами Continuous Development и Continuous Calibration.

Переход: развёртывание

Развёртывание — самая увлекательная часть. Но вы не просто vibe-deploy (за неимением лучшего термина 🙂) и не надеетесь на лучшее. Вы настроили пайплайн, который позволяет учиться и улучшаться. Вы логируете взаимодействия, встроили способ передать контроль обратно людям и установили оценочные метрики, которые сигнализируют, если что-то не так. Теперь — ваш шанс увидеть систему в дикой природе.

Бум. Вы развёртываете на небольшой когорте, и система начинает работать.

Отсюда вы переходите в фазу Continuous Calibration. Здесь начинает проявляться поведение в реальном мире и вы начинаете понимать, что работает, что ломается и что нужно исправлять дальше.

CC 4. Запустите evals

Вы спроектировали eval-метрики в цикле CD. Теперь, когда вы развернули систему и у вас есть логи поведения пользователей, пора оценить, как система действительно отработала. Как только вы собрали значимый объём данных живых взаимодействий, можно начать запускать оценку. Вы можете запустить её на подмножестве данных или на всём датасете — в зависимости от ограничений по стоимости и вычислениям.

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

Логи передачи контроля (control handoff logs) также могут давать ценные сигналы для оценки, особенно когда они фиксируют, как человек вмешался бы или скорректировал результат.

Пример оценки для v1 системы customer support

В зависимости от вашего use case, выберите наиболее репрезентативную выборку живых пользовательских взаимодействий для запуска ваших eval-метрик. А если данных взаимодействий немного (2 000–3 000 логов), смело запускайте на полном датасете.

CC 5. Проанализируйте поведение и выявите паттерны ошибок

Когда вы смотрите на свои evals, может, они выглядят солидно. А может, и нет. Если вы хорошо выполнили шаги 1–3 фазы Continuous Development, ваши метрики, вероятно, где-то посередине, а значит, есть что оптимизировать.

Теперь пора начать вручную просматривать ваши данные. Это одна из самых недооцённых, но необходимых частей построения AI-систем. Простая стратегия — начинать там, где ваши eval-метрики слабее всего. Обычно именно там самый ценный сигнал.

Например, в v1 маршрутизации системы customer support вы могли бы:

Подтянуть 20–50 тикетов с низкой точностью по каждому отделуСфокусироваться больше на отделах, где оценки отстают (возможно, отдел возвратов проседает, а биллинг выглядит нормально)

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

Как только вы вручную просмотрите достаточно примеров, вы начнёте замечать повторяющиеся паттерны ошибок. Здесь вы начинаете их документировать. На этом этапе хорошо работает простая табличная форма:

Эти паттерны показывают, что нужно изменить в логике системы, в prompts или во входных данных. Они также помогают более осознанно очертить следующую версию.

CC 6. Внесите исправления

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

Помните, как на шаге 2 фазы Continuous Development мы говорили не переусердствовать с инженерией? Это потому, что именно на этом шаге следует заниматься инженерией больше. Развивайте архитектуру, но делайте это осознанно — на основе данных, а не догадок.

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

Также нередко сама конструкция eval-ов оказывается недостаточной. Это происходит потому, что evals часто проектируются на основе референсного датасета, который опирается на то, что вы ожидаете от пользователей. Реальное поведение пользователей, однако, может сильно отличаться. Этот недетерминизм может сбить и ваши evals. Проходя шаги 4 и 5 заново, вы можете обнаружить устойчивые места, где evals пропускали проблемы или давали высокие оценки дефектным выводам. Поэтому шаг 6 может также включать пересмотр и перестройку ваших evals — и это абсолютно нормально. Скорее всего, вы проведёте несколько раундов оценки по мере того, как продукт продолжит формироваться. Эх… это всё часть процесса.

Когда вы впервые доходите до конца шага 6, вы, вероятно, уже начинаете осваиваться. Вы пройдёте через этот цикл много раз, постепенно снижая контроль, давая системе становиться более автономной и позволяя продуктовым фичам направлять ваши решения по дизайну. Помните, что развёртывание — лишь часть большой картины. Большая часть работы — в том, чтобы хорошо спроектировать.

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

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

Соединяя всё вместе: цикл CC/CD для customer support

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

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

Если бы вы сразу выпустили полностью автономную систему поддержки (v3), очень многое могло бы быстро пойти не так. Простой пример: запрос на возврат средств ошибочно помечается как биллинговая проблема, система подтягивает не тот SOP и генерирует правдоподобное, но неверное решение, и пользователь оказывается сбит с толку и теряет доверие к продукту.

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

Подход CC/CD помогает избежать этой спирали. В v1 customer support система занимается только маршрутизацией тикетов, давая вам сигналы о том, как пользователи формулируют проблемы, какие отделы часто путают и какие метаданные на самом деле имеют значение. Затем вы используете это, чтобы улучшить логику маршрутизации и доработать prompts, прежде чем двигаться дальше. В v2 система готовит черновики ответов на основе SOPs, но человек по-прежнему их проверяет. Это помогает понять, где ломается извлечение и какие документы нужно обновить. К v3 система готова взять больше агентности и сама закрывать ограниченные тикеты. Но теперь вы знаете, какие запросы безопасно автоматизировать и где нужен fallback.

Куда двигаться дальше

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

Мы часто сравниваем работу с AI с онбордингом нового товарища по команде. Этот товарищ может быть блестящим, но он ещё не знает, как работает ваша команда. Вы не дадите ему самые ответственные проекты в первый же день. Вы начинаете с малого, наблюдаете, выстраиваете доверие и, по мере того как он показывает, с чем может справиться, постепенно расширяете его зону ответственности. AI-системам нужен такой же путь. Именно для его поддержки и предназначен фреймворк CC/CD.

В сердце CC/CD лежит суждение: то самое, которое помогает решить, что выпускать, как защищать пользователей, когда что-то идёт не так, когда возвращать контроль и как определять, что такое «достаточно хорошо».

Не существует one-size-fits-all в том, сколько возможностей давать каждой версии, как долго собирать данные перед движением вперёд или насколько узко задавать рамки. Это зависит от вашего продукта, ваших пользователей и ваших таймлайнов. Одним продуктам нужны недели итераций. Другие могут двигаться быстрее. Вот тут и подключается ваше суждение.

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

Спасибо, Aish и Kiriti! Вы можете подписаться на них в LinkedIn, а также посмотреть их популярный курс на Maven и предстоящий бесплатный lightning talk, где эта тема разобрана подробно.

Желаю вам наполненной и продуктивной недели 🙏

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

Искренне ваш,

Lenny 👋