Why your AI product needs a different development lifecycle

Why your AI product needs a different development lifecycle

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

Introducing the Continuous Calibration/Continuous Development (CC/CD) framework

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

👋 Welcome to a ✨ free edition ✨ of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career. For more: Lenny’s Podcast | How I AI | Lennybot | Courses

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

P.S. Annual subscribers get a free year of 15+ premium products: Lovable, Replit, Bolt, n8n, Wispr Flow, Descript, Linear, Gamma, Superhuman, Warp, Granola, Perplexity, Raycast, Magic Patterns, Mobbin, and ChatPRD (while supplies last). Subscribe now.

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

In this AI era, tech leaders need to re-evaluate every single industry best practice for building great products. AI products are just built differently. The teams that realize that and adjust the most quickly will have a huge advantage.

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

Based on their experience leading over 50 AI implementations at companies including OpenAI, Google, Amazon, Databricks, and Kumo, Aishwarya Reganti and Kiriti Badam have developed the Continuous Calibration/Continuous Development (CC/CD) framework to specifically address the unique challenges of shipping great AI-powered products. In this post, they’re sharing it for the first time with you.

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

For more from Aish and Kiriti, check out their popular Maven course and their upcoming free lightning talk that explores this topic in depth.

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

If you’re a product manager or builder shipping AI features or products, you’ve probably felt this:

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

Your company is under pressure to launch something with AI. A promising idea takes shape. The team nails the demo, the early reviews look good, and stakeholders are excited. You push hard to ship it to production.

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

Then things start to break. You’re deep in the weeds, trying to figure out what went wrong. But the issues are tangled and hard to trace, and nothing points to a single fix. Suddenly your entire product approach feels shaky.

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

We’ve seen this play out again and again. Over the past few years, we’ve helped over 50 companies design, ship, and scale AI-powered autonomous systems with thousands of customers. Across all of these experiences, we’ve seen a common pitfall: people overlook the fact that AI systems fundamentally break the assumptions of traditional software products.

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

You can’t build AI products like other products, for two reasons:

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

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

When companies don’t recognize these differences, their AI products face ripple effects like unexpected failures and poor decision-making. We’ve seen so many teams experience the painful shift from an impressive demo to a system that can’t scale or sustain. And along the way, user trust in the product quietly erodes.

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

After seeing this pattern play out many times, we developed a new framework for the AI product development lifecycle, based on what we’ve seen in successful deployments. It’s designed to recognize the uniqueness of AI systems and help you build more intentional, stable, and trustworthy products. By the end of this post, you should be able to map your own product to this framework and have a better sense of how to start, where to focus, and how to scale safely.

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

Let’s walk through the ways that building AI products is different from traditional software.

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

1. AI products are inherently non-deterministic

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

Traditional software behaves more or less predictably. Users interact in known ways: clicking buttons, submitting forms, triggering API calls. You write logic that maps those inputs to outcomes. If something breaks, it’s usually a code issue, and you can trace it back.

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

AI systems behave differently. They introduce non-determinism on both ends: in other words, there’s unpredictability in how users engage and how the system responds.

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

First, the user interaction surface is far less deterministic. Instead of structured triggers like button clicks, users interact through open-ended prompts, voice commands, or other natural inputs. These are harder to validate, easier to misinterpret, and vary widely in how users express intent.

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

Second, the system’s behavior is inherently non-deterministic. AI models are trained to generate plausible responses based on patterns, not to follow fixed rules. The same request can produce different results depending on phrasing, context, or even a different model.

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

This fundamentally changes how you build and ship. You’re no longer designing for a predictable user flow. You’re designing for likely behavior—both from the user and the product—not guaranteed behavior. Your development process needs to account for that uncertainty from the start, continuously calibrating between what you expect and what shows up in the real world.

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

2. Every AI product negotiates a tradeoff between agency and control

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

There’s another layer that makes AI systems different, and it’s one we rarely had to think about before with traditional software products: agency.

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

Agency, in this context, is the AI system’s ability to take actions, make decisions, or carry out tasks on behalf of the user (which is where the term “AI agent” comes from). Think:

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

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

Unlike traditional tools, AI systems are built to act with varying levels of autonomy. But here’s the part people often overlook:

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

Every time you give an AI system more agency, you give up some control.

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

So there’s always an agency-control tradeoff at play. And that tradeoff matters (a lot!). If your system suggests a response, you can still override it. If it sends the response automatically, you’d better be sure it’s right.

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

The mistake most teams make is jumping to full agency before they’ve tested what happens when the system gets it wrong. If you haven’t tested how the system behaves under high control, you’re not ready to give it high agency. And if you hand over too much agency without the system earning it first, you may lose visibility into the system, and the trust of your users.

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

What’s more, you’re stuck debugging a large, complicated system that has taken actions you can’t trace, for reasons you’ve lost insight into, so you don’t even know what to change.

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

Which brings us to the core framework we’ve developed to help teams navigate these distinctions.

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

We call it CC/CD: Continuous Calibration/Continuous Development.

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

The name is a reference to Continuous Integration/Continuous Deployment (CI/CD), but, unlike its namesake, it’s meant for systems where behavior is non-deterministic and agency needs to be earned.

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

The Continuous Calibration/Continuous Development framework

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

Just like in traditional software, AI products move through phases toward an end goal. But building AI requires you to account for two things we mentioned earlier: non-determinism and the agency-control tradeoff.

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

The CC/CD framework is designed to work around these two realities by:

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

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

In our framework, product builders work in a continuous loop of development (CD) and calibration (CC). During development, you scope the problem, design the architecture, and set up evaluations to keep non-determinism in check. You start with features that are low-agency and high-control, then gradually move up as the system proves it can handle more.

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

Then you deploy, not as a finish line but as a transition into the next phase. Once you’ve deployed, you enter the calibration loop, where you observe real behavior, figure out what broke, and make targeted improvements.

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

With every cycle, the system earns a bit more agency. Over time, this loop turns into a flywheel, tightening feedback, building trust, and making the product stronger with each version.

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

Let’s go deeper into each step of the CC/CD loop, what it looks like, why it matters, and how to do it well. The first three steps make up the Continuous Development side of the loop: scoping the capability, setting up the application, and designing evals.

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

CD 1. Scope capability and curate data

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

Let’s say you have a big product idea and you’ve already done your research. It’s clear that AI is the right approach. In traditional software development, you’d typically plan for v1, v2, v3 of the new product based on feature depth or user needs. With AI systems, the versioning still applies, but the lens shifts.

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

Here, each version is defined by how much agency the system has and how much control you’re willing to give up. So instead of thinking in terms of feature sets, you scope capabilities. Start by identifying a set of features that are high control and low agency (version 1 in the image above). These should be small, testable, and easy to observe. From there, think about how those capabilities can evolve over time by gradually increasing agency, one version at a time. The goal is to break down a lofty end state into early behaviors that you can evaluate, iterate on, and build upward from.

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

For instance, if your end goal is to automate customer support in your company, a high-control way to start would be to scope v1 (version 1) as simply routing tickets to the right department, then move to v2 where the system suggests possible resolutions, and only in v3 allow it to auto-resolve with human fallback.

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

Remember, this is just one approach. What it looks like in practice will depend on your product, but the process tends to be consistent: Start with simple decisions that are easy to verify and easy for humans to override. Then, as you progress through the CC/CD loop, gradually layer in more autonomy with each version.

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

How long you stay in each version depends entirely on how much behavioral signal you’re seeing. You’re optimizing for understanding how your AI behaves under real-world noise and variation.

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

Here are a couple more examples:

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

Marketing assistant

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

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

Coding assistant

Coding-ассистент

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

If you’ve followed how tools like GitHub Copilot or Cursor evolved, this is exactly the playbook they used. Most users only see the current version, but the underlying system climbed that ladder gradually. First completions, then blocks, then PRs, with each step earned through usage, feedback, and iteration.

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

Now, because user behavior is non-deterministic, you’ll need to build a reference for what expected behavior looks like and how your AI system should respond. That’s where data comes in. Data helps break the cold start and gives you something concrete to evaluate against. We call this the reference dataset.

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

In the customer support automation example, for the routing version (v1), your reference dataset might include:

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

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

You can pull this from past logs if available, or generate examples based on how your product is expected to work. This dataset helps you evaluate system performance and also tells you what context your assistant needs in order to perform reliably. Since most products start cold, aim to gather at least 20 to 100 examples up front.

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

We’ll continue using the customer support example to walk through the next steps in the CC/CD loop. Imagine you’re building toward a fully autonomous support system for a company. Below are the versions we’ll reference, along with their corresponding agency and control levels. We’ll refer to v1, v2, and v3 throughout the rest of the post.

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

CD 2. Set up application

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

Most people skip step 1 and jump into the setup phase too early, getting lost in implementation choices and overthinking which components are needed. But if you’ve scoped your capability properly in step 1, looked at enough examples, and curated a solid reference dataset, setting up the application should be fairly straightforward. You already know what the system needs to do, have a sense of what users are likely to throw at it, and understand what a good response looks like. Now it’s just about wiring together the simplest version that gives you a useful signal.

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

There’s a famous saying in software, for a reason: “Premature optimization is the root of all evil.” It applies here too. Don’t overengineer. Don’t over-optimize. Not at this stage. Just don’t. Build only what’s needed for your current version. Make the system measurable and iterable by setting up logs to capture what the system sees from the user, what it returns, and how people interact with it. This will form the basis of your live interaction dataset and help you improve the system over time. We won’t go deep into implementation here, but if you’re exposing this to end users, make sure the basics like guardrails and compliance are in place.

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

One more important point: When setting up the application, make sure control can be handed back to humans seamlessly when needed. We’ll refer to these as control handoffs. For example, in the customer support v1, if a ticket is misrouted, the receiving agent (the point of contact for that department) should be able to reroute it easily. Since that correction is logged, it not only helps improve the system over time but also preserves the user experience. Thinking about control handoffs from the start is key to building trust and keeping things recoverable.

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

CD 3. Design evals

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

This is the part that usually takes a bit of thought. Before shipping anything, you need to define how you’ll measure whether the system is doing what you expect and whether it’s ready for the next step. You do this using evaluation metrics (evals, for short).

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

So, what are evals?

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

Evals are scoring mechanisms that help you assess whether your AI system is working, where it’s falling short, and what needs improvement. Think of them as the equivalent of tests in traditional software. But unlike typical unit or integration tests, where inputs and outputs are fixed and correctness is binary, AI evals deal with ambiguity.

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

They’re entirely application-specific and tied to the task you scoped in step 1. You’re not just checking if the system runs—you’re checking how well it does something inherently non-deterministic, like summarizing a document or answering a question. That’s why evals aren’t one-size-fits-all. They serve as the signals to guide your iteration loop, helping you tune and refine behavior over time.

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

For example, in the routing v1 of the customer support system, a simple but strong eval would be routing accuracy—how often the system routes to the correct department. That alone can tell you if the model is learning the right distinctions and whether or not your setup is solid.

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

In v2 of the customer support system, where you’re retrieving internal standard operating procedures (SOPs) or past resolutions to assist an agent, your evals shift to retrieval quality. Are the suggestions actually relevant to the ticket? Are they what a human agent would have looked at?

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

One of the best practices at this stage is to run evals against the reference dataset from step 1. This helps you gauge performance, validate whether your evals are well-designed, and make early tweaks to your product setup from step 2. Some teams wait until after deployment to refine, relying on real user interactions. That approach can work too, depending on the system’s risk profile and how much reference data you can collect up front.

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

You don’t need to over-optimize evals on the reference dataset. The goal is broad coverage across key use cases, not perfection. Production behavior will differ, but a strong eval setup gives you a dependable starting point.

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

To dive deeper into designing and refining evals, a great starting point is Aman’s piece.

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

Once you’ve implemented your system and verified that it’s properly scoped and instrumented, it’s time to deploy. Deployment is the transition phase between the Continuous Development and Continuous Calibration loops.

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

Transition: Deploy

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

Deployment is the fun part. But you’re not just vibe deploying (for lack of a better term 🙂) and hoping for the best. You’ve set up a pipeline that lets you learn and improve. You’re logging interactions, you’ve built in a way for humans to take back control, and you’ve put evaluation metrics in place to flag when something is off. Now’s your chance to see the system in the wild.

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

Boom. You deploy to a small cohort, and the system starts running.

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

From here, you move into the Continuous Calibration phase. This is where real-world behavior starts to show up and where you begin to learn what’s working, what’s breaking, and what needs fixing next.

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

CC 4. Run evals

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

You designed eval metrics in the CD loop. Now that you’ve deployed and have user behavior logs, it’s time to assess how well the system actually performed. Once you’ve collected a meaningful amount of live interaction data, you can start running your evaluation. You can run them on a subset of the data or across the full dataset, depending on cost and compute constraints.

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

If you need to evaluate on a subset, use the unique properties of your system to decide which data points to sample. For example, in the v1 for the customer support system, you might use logs showing whether a human agent rerouted the query to a different department as a proxy for routing accuracy. In more complex systems, you could look at things like the number of conversation turns, whether users gave thumbs-up or thumbs-down feedback, or other in-session signals.

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

Control handoff logs can also provide valuable eval signals, especially when they capture how a human would have stepped in or adjusted the outcome.

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

Example evaluation for customer support system v1

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

Depending on your use case, choose the most representative sample of live user interactions to run your eval metrics on. And if your interaction data is small enough (2,000 to 3,000 logs), go ahead and run them on the full dataset.

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

CC 5. Analyze behavior and spot error patterns

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

When you look at your evals, maybe they look solid. Maybe they don’t. If you’ve done steps 1 through 3 of the Continuous Development phase well, your metrics are probably somewhere in the middle, which means there’s something to optimize.

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

Now it’s time to start manually reviewing your data. It’s one of the most underrated but necessary parts of building AI systems. A simple strategy is to begin where your eval metrics are weakest. That’s usually where the most valuable signal is.

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

For example, in the customer support system routing v1, you might:

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

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

Look at what the user said, what the system did, and what the outcome was. Depending on your application, this might be a single interaction or a multi-turn session. Your eval metrics should help you identify where things went wrong and guide you to the point of failure.

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

Once you’ve manually reviewed enough examples, you’ll start to notice repeat error patterns. This is where you begin documenting them. A simple table format works well at this stage:

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

These patterns show you what needs to change in your system’s logic, prompts, or inputs. They also help you scope the next version more intentionally.

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

CC 6. Apply fixes

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

Once you have actionable error patterns, you can start outlining ways to fix them. This could be anything from a simple prompt tweak to switching to a better model, improving retrieval quality, or adding new components to break down the task. What you change depends entirely on what broke.

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

Remember how in step 2 of the Continuous Development phase we said not to overengineer? That’s because this step is when you should engineer more. Evolve the architecture, but do it intentionally—backed by data, not guesswork.

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

This step is often iterative in itself. You apply a fix, run your eval metrics again, and either keep refining the current version or cycle through steps 2 to 5 until the system performs well enough. And since you already have data, you don’t need to redeploy each time.

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

Also, it’s not uncommon for the eval design itself to fall short. That’s because evals are often designed using the reference dataset, which is based on what you expect users to do. Real user behavior, however, can be very different. That non-determinism can throw off your evals too. As you go through steps 4 and 5 again, you may find consistent places where the evals missed issues or gave high scores to flawed outputs. So step 6 may also involve revisiting and rebuilding your evals—and that’s completely normal. You’ll likely end up running multiple rounds of evaluation as you continue to shape the product. Sigh . . . it’s all part of the process.

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

Once you get to the end of step 6 for the first time, you’re probably getting the hang of it. You’ll go through this loop multiple times, gradually reducing control, allowing the system to become more autonomous, and letting product features guide your design choices. Remember that deployment is just one part of the bigger picture. Most of the work is in designing things well.

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

Which brings us to a small rant: Too many people focus almost entirely on implementation, chasing the latest tools and frameworks, but end up making costly mistakes. We started with a large goal, broke it down, and used more complex solutions only when they actually solved a real problem.

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

Never lead with the tech. Let the problem, evals, and data guide what gets added next. That’s how you keep non-determinism in check with AI products.

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

Putting it all together: A CC/CD loop for customer support

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

Here’s a potential table that breaks down the problem into multiple versions, each adding more agency over time. It also outlines the flywheel you could build at each stage, using the customer support example we’ve been discussing. Each iteration sets up the next. This is just one way to approach it.

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

Use this as inspiration to think about how you could break down your own product to build and scale intentionally.

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

If you shipped a fully autonomous support system (v3) right away, a lot could go wrong fast. Take one simple example: A refund request gets incorrectly tagged as a billing issue, the system pulls the wrong SOP and generates a plausible but incorrect resolution, and the user ends up confused and loses trust in the product.

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

And while you may have evals in place to flag that something went wrong, you’re now stuck untangling a chain of failures. The final mistake ended as a generation error, but it started at routing, was compounded by missing context, and led to a poor outcome. This is just one simple case, but you can already see how quickly things can get complicated.

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

The CC/CD approach helps you avoid that spiral. In the customer support v1, the system handles only ticket routing, giving you signals on how users phrase issues, which departments are often confused, and what metadata actually matters. You then use that to improve routing logic and refine prompts before moving on. In v2, the system drafts responses based on SOPs, but a human still reviews them. This helps you understand where retrieval breaks down and which documents need updates. By v3, the system is ready to take on more agency by resolving scoped tickets on its own. But now you know which queries are safe to automate and where fallback is needed.

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

Where to go from here

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

AI systems have the incredible potential to operate with some level of agency, but getting there is rarely about stacking complex tools or scaling things with brute force. It’s not about writing the perfect prompt either. Creating an AI system that saves time, money, and energy through effective automation is about solving the actual problem, step by step, by understanding its nuances.

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

We often compare working with AI to onboarding a new teammate. The teammate might be brilliant, but they don’t yet know how your team works. You don’t hand them your highest-stakes projects on day one. You start small, observe, build trust, and, as they show what they can handle, you gradually expand their scope. AI systems need that same path. That’s what the CC/CD framework is designed to support.

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

At the heart of CC/CD is judgment: the kind that helps you decide what to ship, how to protect users when things go wrong, when to hand control back, and how to define what “good enough” looks like.

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

There’s no one-size-fits-all for how much capability to give each version, how long to gather data before moving forward, or how tightly to scope. It depends on your product, your users, and your timelines. Some products need weeks of iteration. Others can move faster. That’s where your judgment comes in.

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

Most of that valuable product thinking already lives in successful product leaders. CC/CD simply gives it structure. The framework offers a loop, a rhythm, and a shared language to apply that already-great product instinct to AI systems.

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

Thanks, Aish and Kiriti! You can follow them on LinkedIn, and check out their popular Maven course and their upcoming free lightning talk that explores this topic in depth.

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

Have a fulfilling and productive week 🙏

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

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already. There are group discounts, gift options, and referral bonuses available.

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

Sincerely,

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

Lenny 👋

Lenny 👋