После перехода ITI AI Concierge на формат AI Pod количество релизов в продакшн выросло с 2 за пять месяцев до 10 за четыре, а ежемесячный бюджет сократился на 52%. Крупные функции по-прежнему ждут ждут принятия клиентом около недели, а команда теперь тратит больше времени на ревью, чем на написание кода.
Под выпускает релизы быстрее, потому что в нем отсутствуют передачи задач (handoffs): эстафетная схема разработки, где каждая роль передает эстафетную палочку дальше, превратилась в автономную работу (bench delivery), где каждый разработчик доводит функцию до продакшна, а единственным общим барьером остается клиент.
Чего просил ITI и что изменилось
ITI AI Concierge — это AI-ассистент Международной команды по имплантологии (ITI), глобального сообщества, объединяющего более 25 000 профессионалов в области дентальной имплантологии. Он отвечает на вопросы участников только из одобренных ITI источников и цитирует каждый из них с указанием страниц, авторских прав и авторов.
Краткая версия проекта представлена в нашем кейсе по ITI AI Pod. В этом посте приведены полные цифры и требования, которые модель предъявляет обеим сторонам.
В мае 2026 года ITI попросил Netguru увеличить количество функций на каждый потраченный евро, причем формирование идей и приоритетов оставалось за ITI. Новый бюджет позволил сократить четыре роли в проекте в течение месяца, и формат AI Pod заработал 1 июля 2026 года.
Netguru ответила на запрос переводом продукта на модель AI Pod. При эстафетной разработке теряется время и контекст каждый раз, когда бизнес-аналитик, дизайнер, разработчик или тестировщик передают функцию дальше. При автономной разработке четыре специалиста самостоятельно ведут функцию от концепции до продакшна.
Релизы в продакшн, объем выполненной работы и бюджет улучшились. Ограничителями стали ревью, приемка и решения клиента.
Мы рекомендуем автономную разработку для одного продукта с единственным лицом, принимающим решения, которое может выносить вердикт каждую неделю, поскольку быстрые разработчики все равно стоят в очереди на приемку у клиента. Если такого лица нет, экономия заходит в тупик.
До и после: цифры в одной таблице
Команда выпускала релизы в продакшн в пять раз чаще при примерно вдвое меньшем бюджете. Мы сравниваем период с февраля по июнь 2026 года (классическая команда) с периодом с июля по октябрь 2026 года (AI Pod), данные подсчитаны по 22 октября включительно.
Временные интервалы неравны (пять месяцев против четырех), поэтому пятикратный рост отражает сырые показатели из данных по доставке одного проекта.
Объединенные PR (merged PR) и коммиты легко завысить с помощью ИИ, поэтому они служат лишь вспомогательной иллюстрацией, в то время как закрытые задачи и сторисы являются более надежным показателем результатов. То же самое относится к стоимости одного объединенного PR, которая снизилась на 68%. Это реальный показатель, но он имеет смысл только рядом со строкой релизов.
Для финансового директора ключевое значение имеют строки бюджета и релизов. Остальная часть этого поста посвящена тому, во что они обходятся по времени ревью, приемки и участия клиента.
Как работает команда AI Pod: каждый разработчик отвечает за функцию
AI Pod в ITI AI Concierge опирается на четырех ключевых специалистов, каждый из которых доводит функцию от концепции до продакшна. Четыре роли, которые раньше передавали работу по цепочке (аналитика, дизайн, фронтенд и безопасность), покинули проект в течение месяца.
В состав этих четырех специалистов входят: PM-оркестратор, который также пишет код; QA-инженер, написавший набор автоматизированных тестов UI; бэкенд-инженер, который также пишет фронтенд и доводит функции до конца, а также AI-инженер. Места для передачи задач при эстафетной разработке больше не существуют.
Технический лид и DevOps-инженер подключаются по мере необходимости для проверки направления работ. Ни один из них не входит в основной состав команды.
Неделя имеет фиксированную структуру. Четыре дня уходят на функции, а пятый — на тесты, безопасность, доступность и наведение порядка.
ИИ-агенты (Claude Code) пишут большую часть кода на основе письменных спецификаций. Люди контролируют замысел, ревью и качество.
Состав также зависит от человека вне команды. Каждую среду на 30-й сессии ITI демонстрируются новые концепции в виде кликабельных прототипов, и клиент дает зеленый свет перед тем, как команда приступает к разработке. Отдельная еженедельная синхронизация по дорожной карте между владельцем продукта со стороны ITI и нашим PM определяет приоритеты. Четыре потока движутся ровно с той скоростью, с какой принимаются эти решения.
Какие этапы передачи задач исчезли и чем их заменили
Устранение этапов передачи задач в ITI AI Concierge означало, что передача эстафетной палочки между бизнес-аналитиком, дизайнером, разработчиком и QA была исключена, и каждый специалист доводит функцию от концепции до продакшна. На смену им пришла задокументированная база знаний в GitHub. Сам процесс работы AI Pod мы описываем в отдельном посте.
Мы перенесли знания в репозиторий перед сокращением команды в следующем порядке:
- Пересечение при передаче дел. Перед сокращением команды задачи пересекались в период передачи дел, пока люди, обладавшие контекстом, все еще участвовали в проекте.
- Аудит кода. Технический лид провел аудит кодовой базы и навел порядок в архитектуре до сокращения команды.
- AGENTS.md. Заметки по сборке, тестированию и принятым соглашениям были помещены в корень репозитория, чтобы каждая сессия агента начиналась с одного и того же инструктажа.
- Файлы правил. Конституция проекта и файлы BACKEND, FRONTEND и DESIGN.md (последний ссылается на Figma) содержат архитектурные правила, которые раньше удерживали в голове техлид и дизайнер.
- Журнал решений. Решения фиксируются в репозитории, где их читают агенты и новые сотрудники.
- Спецификации. Каждая функция начинается как короткая письменная спецификация, поэтому область видимости согласовывается до написания кода, а Claude Code с помощью GitHub Spec Kit превращает ее в план, задачи и реализацию. С июля по октябрь команда написала 109 спецификаций.
Внедрение в новую функцию теперь занимает около часа. В сентябре двухнеционное отсутствие участников в команде все равно позволило выпустить 3 релиза. Один месяц полевых наблюдений не является гарантией.
Почему количество релизов в продакшн выросло с 2 до 10
Частота релизов в продакшн увеличилась, потому что устранение этапов передачи задач убрало очереди между завершенным изменением и его развертыванием. Теперь каждый разработчик доводит функцию до продакшна, не дожидаясь следующей роли в цепочке.
Метрики DORA дают более надежные показатели: частоту развертывания и время выполнения изменений. После перехода среднее время от завершенного изменения кода до продакшна составило 6 дней. Мы считаем время с момента слияния (merge), а не первого коммита, поэтому это значение занижает полную метрику lead time по DORA.
6-дневный медианный показатель объединяет два разных сценария:
- Небольшое исправление: попадает в продакшн за считанные часы.
- Крупная функция: занимает 1–2 недели от концепции до продакшна, из которых около недели уходит на приемочное тестирование (UAT) со стороны ITI.
Мы считаем, что релизы теперь задерживаются на этапе приемки, а не написания кода.
Механика релизов тоже изменилась. ITI тестирует и принимает каждый релиз в среде UAT, а в продакшн попадает помеченная тегом точная копия того, что принял клиент, с примечаниями к релизу. За первые четыре месяца этот ритм позволил внедрить голосовые вопросы, указание авторов источников и четыре режима ответов.
Коммиты демонстрируют ту же динамику. С февраля по июнь команда делала от 5 до 10 коммитов в неделю. В июле шшла настройка нового метода работы, и с августа этот показатель вырос примерно до 15–20 и более коммитов в неделю. Мы рассматриваем коммиты и объединенные PR только как косвенные доказательства, поскольку они отражают активность и ничего не говорят о том, что именно дошло до пользователей.
Что стало сложнее после перехода
Издержки более быстрой поставки в ITI AI Concierge проявляются в трех аспектах: ревью, приемка и специализированная работа, которой больше нет в штате команды.
Ревью стало главным узким местом. ИИ-агенты производят код быстрее, чем люди успевают его проверять, и каждый проверяющий должен понимать то, что он одобряет.
Приемка стала узким местом при UAT (пользовательском приемочном тестировании). Около недели из 1–2 недель выхода крупной функции в продакшен в ITI приходится на UAT, и более высокая скорость разработчиков не сокращает эту неделю. Открытые вопросы также ждут еженедельного решения со стороны клиента.
В ходе аудитов обнаруживаются нехватки специалистов. Поскольку в основной команде не было дизайнера, фронтенд-разработчика или специалиста по безопасности, вопросы доступности откладывались до еженедельного дня обслуживания вплоть до AA-аудита в октябре. Аудит выявил проблемы, и первые исправления были выпущены в версии 1.3.1.
Данные по тикетам также перестали быть сопоставимыми. До перехода тикеты делились на подзадачи. После перехода текстовые спецификации заменили это разделение, поэтому количество задач в Jira и медианное время выполнения тикета для этих двух периодов описывают разные объемы работы. По этой причине мы исключаем время выполнения тикета из сравнения.
То, к чему нам следует готовиться, — это то, что проверка и приемка теперь задают темп. Закладывайте в бюджет QA и приемочное тестирование как постоянную мощность, а также согласуйте с клиентом, кто проводит UAT и сколько дней выделяется на крупную функцию.
Что позволяет контролировать качество, когда бо́льшую часть кода пишет ИИ
После перехода узкое место в ITI AI Concierge сместилось с написания кода на его проверку и приемку, причем темп задавали решения клиента. Проверки качества должны были выполняться при каждом изменении.
Защитными механизмами выступают правила для агентов в репозитории и последовательность «сначала спецификация». Каждое изменение кода проходит проверку ИИ, сканирование безопасности и зависимостей, а также проверку человеком, который разбирается в коде. Автоматизированные UI-тесты запускаются при каждом изменении, а каждый релиз проходит сквозное (end-to-end) тестирование с помощью Playwright.
Качество ответов проверяется отдельно. Перед каждым релизом Promptfoo запускает клинический тестовый набор, а также проверки на галлюцинации, вопросы вне зоны ответственности и атаки типа red-team. В продакшене Langfuse отслеживает ответы и собирает отзывы участников.
Ассистент отвечает только на основе фрагментов текста, которые генерация с дополненным извлечением (RAG) находит в библиотеке ITI, созданной на базе FastAPI, LangChain и Azure OpenAI; платформа работает в Microsoft Azure за брандмауэром веб-приложений (WAF) с настроенным мониторингом.
Каждая роль должна заниматься разработкой. QA и продакт-менеджер пишут код наравне с бэкенд-инженерами и ИИ-инженерами, а один только наш QA-инженер внедрил 54 изменения кода и написал набор автоматизированных UI-тестов.
Это предъявляет высокие требования к людям. Каждому разработчику необходима лицензия агента (в данном случае Claude Code), а команда проводит еженедельные сессии «люди программируют» для обмена опытом. Такой подход подходит для опытных специалистов.
Что нужно AI-подразделению (AI Pod) от клиента?
AI Pod требуется назначенный ответственный за принятие решений со стороны клиента, который участвует в еженедельном 30-минутном цикле принятия решений, принимает работу на стейджинге и имеет зарезервированное время для пользовательского приемочного тестирования (UAT).
В проекте ITI AI Concierge эту роль выполнял продакт-менеджер ITI в ходе среды прототипирования и еженедельной синхронизации по дорожной карте. Каждый разработчик отвечает за функцию от концепции до продакшена, поэтому ни одна внутренняя передача дел не задерживает открытый вопрос. Нерешенные вопросы поступают напрямую клиенту, и подразделение ждет ответа.
Таким образом, часть экономии бюджета перекладывает ответственность на клиента. Уточнение требований и погоня за приемкой в классической команде распределялись по разным ролям. В AI Pod и то, и другое становится временем клиента, и узкое место UAT для крупных функций проявляется в этом в первую очередь.
ITI приняла это. Филипп Нюш (Philipp Nueesch), директор по маркетингу ITI: «Мне это безумно нравится, абсолютно. Я горжусь тем, что у нас хватило смелости сделать это будучи небольшой гибкой организацией. Это действительно заметно, и результаты отличные».
Наше правило принятия решений, выведенное на основе этого проекта: внедряйте AI Pod только при выполнении всех трех условий.
- Назначенное лицо, принимающее решения, посещает еженедельные встречи и может на месте решать вопросы по содержанию работ.
- Этот человек или уполномоченное лицо с равными полномочиями принимает функции на стейджинге.
- Ресурс для UAT забронирован до начала работы над крупной функцией.
Если какое-то из условий не выполняется, путь от концепции до продакшена застопорится на первом же открытом вопросе, а меньший бюджет пойдет на оплату простоя разработчиков. Назначайте ответственное лицо и бронируйте ресурс для UAT до подписания договора. Клиенту с распределенной цепочкой согласований может потребоваться более 30 минут в неделю, а один вовлеченный клиент — это узкая выборка.
Как оценивать AI Pod: по частоте релизов, а не по пулл-реквестам
Оценивайте AI Pod по частоте релизов в продакшен и времени доставки до продакшена, а затем проверьте, поддерживает ли базовый показатель вендора такое сравнение. DORA определяет частоту развертываний и время выполнения изменений в качестве базовых метрик, и обе они учитывают только то, что доходит до продакшена.
Задайте любому вендору эти четыре вопроса:
- Базовый показатель: Какой период считается «прошлым» и существовали ли тогда конвейер продакшена или теги версий? Без них старое количество релизов — это лишь воспоминания.
- Знания: Спецификации и правила для агентов хранятся в репозитории или в головах людей?
- Разработчики: Могут ли QA и PM открывать и мерджить PR? Если нет, передача дел все еще существует.
- Тикеты: Одинаковы ли размеры историй и правила их разделения до и после? Перенарезка меняет пропускную способность и время выполнения без изменения объема поставки.
Цифры ITI AI Concierge получены по одному продукту, одному клиенту и одной команде по состоянию на 22 октября 2026 года. Клиенту с медленным принятием решений или зарегулированным процессом релизов следует ожидать другого результата.
Наша статья о модели поставки AI Pod рассматривает метрики в теории, а готовая услуга AI Pod отличается по конфигурации от реализации в ITI.
Заключение: Обеспечьте ресурсами этап приемки, а затем обсудите с нами внедрение AI Pod
Покупайте AI Pod ради частоты релизов и времени доставки до продакшена и обеспечьте ресурсами тот самый этап приемки, который эта модель делает узким местом.
В случае ITI AI Concierge разработка силами команды продвигалась быстрее, чем при конвейерной модели, поскольку каждый разработчик доводил функцию от концепции до продакшена без передачи эстафетной палочки. При этом каждая функция все равно выстраивалась в очередь в одной общей точке контроля: клиентская приемка и клиентские решения. Более быстрые разработчики не сокращают эту очередь.
Обеспечение ресурсами этапа приемки означает три вещи. Назначьте ответственного за приемку с полномочиями на подписание. Проводите еженедельный 30-минутный цикл принятия решений с клиентом каждую неделю. Забронируйте время для UAT до начала работы над крупной функцией. Воспринимайте нагрузку по проверке, время UAT и специализированные аудиты как цену этой модели и планируйте их заранее.
Если ваша сторона этапа приемки готова, поговорите с нами об AI Pod.
Часто задаваемые вопросы
Сколько людей входит в AI Pod?
AI Pod проекта ITI AI Concierge состоит из четырех основных разработчиков: PM-оркестратор, QA-инженер, бэкенд-инженер, который также занимается фронтендом, и ИИ-инженер, причем каждый отвечает за функции от концепции до продакшена. Технический лид и DevOps-инженер привлекаются по запросу для проверки направлений и находятся вне основной команды. В предыдущей классической команде было восемь человек.
Как вы поддерживаете качество, когда бо́льшую часть кода пишет ИИ?
Каждая функция начинается с письменной спецификации, и каждое изменение кода проходит проверку ИИ, сканирование безопасности и зависимостей, а также проверку человеком, который разбирается в коде. Автоматизированные UI-тесты запускаются при каждом изменении. Перед каждым релизом набор тестов для ответов проверяет клиническую точность, отсутствие галлюцинаций, вопросы вне зоны ответственности и атаки red-team, а Langfuse отслеживает ответы в продакшене.
Насколько быстро команда выпускала релизы после перехода на AI Pod?
Выпуск релизов увеличился с 2 за пять месяцев до 10 за четыре. Медианное время от завершения изменения кода до передачи в продакшн составляет 6 дней: небольшие исправления доставляются в течение нескольких часов, а крупные функции занимают 1-2 недели, включая примерно неделю приемочного тестирования (UAT) на стороне ITI.
Что должен делать клиент в составе AI Pod?
Клиент участвует в еженедельном 30-минутном цикле принятия решений и проводит приемочное тестирование крупных функций. Разработчики действуют на основе этих решений напрямую, без цепочки передачи задач, способной задержать ответ. Если клиент пропускает неделю, работа останавливается, и вместе с ней растет очередь UAT.
Каковы недостатки AI Pod?
В проекте ITI AI Concierge узким местом стал этап проверки: крупные функции ждали UAT около недели, проблемы с доступностью выявлялись в ходе аудита, а не повседневной работы, а скорость поставки зависела от еженедельных решений клиента. Кроме того, формат pod предъявляет высокие требования к небольшой группе участников, которым приходится проверять и принимать больше кода, чем писать. Выбирайте этот подход, если частота релизов перевешивает данные издержки.
