Operator Loop

Product-Operated Agentic SDLC для growth-команд. Продолжение Hypothesis Board.

Operator Loop — короткое имя для Product-Operated Agentic SDLC. Одно и то же.

Коротко

AI удешевил не только код, но и всю поверхность исполнения. Когда продукт может через подключённых агентов сам собирать дизайн, спецификацию, PR и пакет доказательств, передача работы от продукта к инженерам перестаёт быть критическим путём. Роль инженерии меняется: из исполнителя по умолчанию она становится владельцем control plane — agent skills, CI, фичефлаги, evals, триггеры, rollback, архитектура.

Product operates. Agents execute. Engineering owns the control plane. Telemetry decides.

Это не «AI помогает инженерам писать код быстрее». Это инверсия того, кто держит руль петли доставки.

Первая зона применения — growth-разработка: маленькие, наблюдаемые, обратимые, feature-flagged изменения.

Начинать там, где петля короткая: growth, онбординг, paywall, активация, retention, прайсинг, funnel и AI-промпт-эксперименты.

TL;DR

• Единица работы остаётся та же: гипотеза с порогом опровержения (falsification threshold).
• Исполнитель по умолчанию меняется: продукт сам запускает агентов через связанный toolchain — трекер, дизайн-инструмент, репозиторий, CI.
• Инженерия никуда не исчезает. Она становится владельцем control plane: agent skills, CI, фичефлаги, evals, триггеры, rollback, архитектура.
• Выход агента — это пакет доказательств (evidence package), а не «готово».
• «Готово» по-прежнему значит вердикт, подтверждённый телеметрией.

Что значит «Product-Operated»

В классической модели:

Product writes requirements
→ Engineering builds
→ QA verifies
→ Release

В Product-Operated Agentic SDLC:

Signals from Insight Inbox → Product states the hypothesis
→ Prototype → spec
→ Agent run produces PR, tests, telemetry plan
→ Review: engineering reviews, approves, or takes over if a trigger fires
→ Controlled rollout behind a flag, measurement begins
→ Telemetry delivers the verdict

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

Инженерия перестаёт быть исполнителем по умолчанию для каждого артефакта низкого риска. Она становится владельцем control plane: agent skills, CI, фичефлаги, evals, триггеры, rollback, архитектура.

Review включён всегда. Перехват — условно.

Что мы реально собрали

Не новую физику. Более агрессивную сборку:

HYPEX: hypothesis → experiment → data → learning
RIGHT: infrastructure for experimentation
JPD: idea / insight / delivery tracking
Shape Up: shaping before build
Connected agents: Product can operate tools directly

Сдвиг дефолтов:

Продукт больше не передаёт намерение.
Продукт ведёт петлю доставки сам.

Где это работает в первую очередь

Operator Loop — не универсальное правило для всей разработки.

Она работает в первую очередь там, где цикл фидбэка короткий, а поверхность изменения наблюдаемая: growth, онбординг, paywall, активация, lifecycle, прайсинг, funnel, prompt- и UX-эксперименты. Фичи в этой зоне видны на поверхности продукта, не размазаны по микросервисам и очередям, а работа там в основном тюнинг: копирайт, расположение, флоу, порог, prompt, — а не крупные новые куски функциональности.

Конкретные примеры:

• изменения в онбординг-флоу
• paywall- и pricing-эксперименты
• апгрейд- и активационные нудж
• retention- и lifecycle-письма
• пуш-уведомления
• варианты промптов AI-ассистента
• изменения шагов funnel-а
• варианты лендингов
• тюнинг рекомендаций

Плохая первая посадочная площадка: enterprise-масштабные cross-service-изменения, квартальный релизный scope, глубокие рефакторинги, platform-миграции, домены, где функциональную декомпозицию нельзя однозначно извлечь из продуктового намерения.

Operator Loop не решает проблему функциональной декомпозиции в больших системах. Он обходит её, начиная с маленьких, наблюдаемых, growth-ориентированных изменений. Это не слабость. Это честный вход.

Начинать там, где продукт может увидеть изменение, запустить под флагом, измерить и убить.

Feasibility разбивается на два прохода

Классический порядок: анализ impact и feasibility → спецификация → прототип. Этот порядок исходил из предположения, что прототипирование дорого.

Operator Loop разбивает feasibility на два прохода.

Pre-flight, до Prototype: лёгкий AI-ассистированный разбор самой гипотезы — сила сигнала, обратимость, измеримость, грубая оценка impact, очевидные блокеры. Используется, чтобы решить, стоит ли вообще делать дешёвый прототип. Дёшево провести, дёшево пропустить.

Committed, после Prototype: настоящий feasibility-проход по живому артефакту, который уже прошёл через дизайн, код, телеметрию, стоимость, задержку и rollout. Только тогда команда берёт обязательство на спецификацию.

Feasibility не уходит в конец. Он делится. Первый проход убивает гипотезы, не стоящие прототипирования. Второй проход убивает прототипы, не стоящие обязательства.

Самая сложная часть — не генерация кода

Самая сложная часть — функциональная декомпозиция. Превратить продуктовое намерение в правильное изменение означает определить, какие сервисы затронуть, какие доменные правила сохранить, какие архитектурные границы не сломать, и в каких местах эти три требования конфликтуют. Reverse-engineering этой декомпозиции из большой распределённой кодовой базы работает ненадёжно. Это самая нерешённая часть agent-driven delivery, а не генерация кода.

Operator Loop обходит breakdown как первую adoption-проблему, сужая зону: изменения достаточно маленькие, чтобы поведение на стороне пользователя было видно на поверхности продукта, rollout мог уйти под флаг, первый продуктовый сигнал мог быть измерен за дни, а плохой результат можно было убить. По мере роста зрелости агентов граница расширяется. Первая безопасная операционная зона — ограниченная growth-работа, а не enterprise-масштабная декомпозиция.

Технические предпосылки

Это уже не футуризм. Отдельные компоненты уже работают в 2026 году.

Три capability должны быть на месте:

1. Интеграция с трекером. AI-агенты умеют искать, создавать и обновлять задачи и страницы в проектных трекерах через natural-language-команды, работая с правами пользователя. Atlassian Jira Product Discovery — самый явный текущий пример; другие вендоры трекеров двигаются в ту же сторону. [1]

2. Мост дизайн→код. Агенты умеют вытягивать структурированный контекст дизайна — не скриншоты — из дизайн-инструмента для design-informed генерации кода. Интеграция Figma Dev Mode — один из примеров; принцип в том, что дизайн становится структурированным источником, который агент может читать. [2]

3. Кодовые агенты с человеческим ревью. Фоновые coding-агенты берут задачу, читают кодовую базу в песочнице, пишут diff и открывают PR для ревью. В защищённых репозиториях сохраняется независимое человеческое ревью как обязательный этап — агент производит работу, решение о слиянии остаётся за человеком. [3]

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

Как это ложится на Hypothesis Board

Точка входа принципиальная. Сигналы — это не колонка доски, это доказательства, привязанные к гипотезам. Слева — Insight Inbox, куда постоянно падают support-тикеты, просадки аналитики, фидбек, отказы продаж, паттерны из логов, рыночные наблюдения, заметки от стейкхолдеров. Это не стадия и не workflow-state. Это входной слой.

Справа — семь actionable-колонок, по которым движется единица работы:

Hypothesis → Prototype → Spec → Agent Run → Review → Measure → Verdict

Один сигнал может породить несколько гипотез. Одна гипотеза может опираться на пять сигналов. Некоторые сигналы вообще не становятся работой. Поэтому сигналы сидят в Inbox как evidence, а на доске двигается только гипотеза.

В Jira Product Discovery это маппится напрямую: Insight в JPD — это сигнал, Idea — гипотеза, связанные delivery-тикеты в Jira Software — работа на стадиях Agent Run и Review.

Первое действие продукта в понедельник — не «создать карточку в первой колонке». Это посмотреть на Insight Inbox и на Signal Review выделить паттерны, достойные гипотезы.

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

Слоган:

Signals feed the loop.
Hypotheses move through the loop.

Исполнитель по умолчанию меняется на каждой стадии.

Между Prototype и Spec — точка валидации, не новая колонка. Критерии выхода:

• прототип объясняет исходный сигнал
• прототип создаёт правдоподобный измеримый путь к целевой метрике
• прототип не выявил более дешёвую или меньшую альтернативу
• прототип подтвердил или обнаружил отсутствующую телеметрию

Если прототип не может объяснить сигнал, запустивший гипотезу, он не становится спецификацией.

Подотчётность остаётся за людьми. Агенты исполняют, но ничего не подписывают. Инженерия не дефолтный исполнитель — она слой review и takeover. Review — всегда-активный гейт на этой стадии; takeover — условное вмешательство по триггерам ниже.

Роли в Product-Operated Agentic SDLC

Ролевой слой меняется, но не разваливается. Продукт ведёт петлю: формулирует гипотезы, запускает агентов, подписывает вердикт. Инженерия владеет control plane: agent skills, CI, фичефлаги, evals, триггеры, rollback, архитектура. И вмешивается при срабатывании триггеров перехвата. AI-агент исполняет и производит артефакты как пакет доказательств, но не принимает решений. Дизайн отвечает за качество дизайна: продукт готовит черновики через дизайн-инструмент, дизайн проверяет целостность и консистентность. Аналитика отвечает за метрики: продукт читает дашборды, аналитика валидирует baseline, окно измерения и обвязку телеметрией. QA — это функция, не департамент. Инженерия владеет инфраструктурой автоматических тестов, CI и техническими проверками безопасности. Продукт отвечает за приёмку — подтверждение того, что артефакт делает то, что заявляла гипотеза, до выхода к пользователям. В agent-driven delivery это важнее, а не менее важно, потому что агент производит код, проходящий тесты, но промахивающийся по намерению. Спонсор отвечает за kill-решения и масштабирование, подписывает крупные сделки по риску.

Главный сдвиг:

Продукт больше не передаёт намерение.
Продукт ведёт петлю доставки сам.

Инженерия никуда не исчезает. Она перестаёт быть исполнителем по умолчанию для каждого артефакта низкого риска. Она становится владельцем control plane: agent skills, CI, фичефлаги, evals, триггеры, rollback, архитектура.

Review включён всегда. Перехват — условно.

Производительная работа инженерии тоже смещается. Меньше прямого авторства фич. Больше платформенной работы: agent skills, промпты и tool permissions, telemetry hooks, триггеры перехвата, CI-интеграции, ops. Система, на которой работает delivery loop, — это инженерный deliverable. Каждый перехват — ещё и сигнал обратной связи в эту систему: какого скилла не хватило, какой триггер сработал поздно, где сломались ops.

Продукт собирает прототипы и шипит больше. Инженерия строит и поддерживает систему, которая позволяет продукту шипить.

Точки перехвата

Правило формулируется жёстко:

Default mode: Product-operated agentic work.
Exception mode: Engineer takeover.

Перехват запускается автоматически при любом из условий: затронута поверхность авторизации, платежей, медицинских данных, приватности или безопасности; предполагается миграция данных или разрушающая операция; требуется новая внешняя зависимость; красный CI; оценочный балл (eval score) опустился ниже baseline на заданный порог; нарушен cost guardrail в CI; PR превышает ограничение по сложности (например, 500+ строк или больше N файлов); есть риск по производительности или масштабированию; меняется версия модели или набор разрешённых инструментов (tool permissions); агент не может объяснить свой diff; обвязка телеметрией невалидна; scope уехал от формулировки гипотезы.

Каждый триггер шлёт инженерии автоматическое уведомление через CI или мониторинг. Инженер не авторит каждый артефакт. Инженер ревьюит на гейте и перехватывает руль на красном свете. Финальный merge остаётся за инженером — не за продуктом и не за агентом.

Один delivery loop и одна инженерная control plane.

Delivery loop — продуктовый: Hypothesis → Prototype → Spec → Agent Run → Review → Measure → Verdict.

Инженерная control plane — не вторая продуктовая петля. Это система, которая делает loop безопасным: agent skills, CI, branch protection, feature flags, телеметрия, evals, триггеры перехвата, rollback rules, архитектурные границы.

Продукт шипит через петлю. Инженерия улучшает систему, которая шипит.

Три горизонта обратной связи

У growth-работы три вложенных горизонта обратной связи, и вердикт не должен их смешивать.

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

Средний горизонт — продуктовая валидация. Пользователи ведут себя иначе? Активация, использование, вовлечённость, прогрессия по funnel-у, adoption фичи. Дни или неделя. Продуктовые метрики — лидирующие индикаторы и могут двигаться без движения бизнеса.

Длинный горизонт — бизнес-валидация. Изменение сдвинуло retention, монетизацию, LTV, paid conversion или revenue? Недели или квартал. Бизнес-горизонт — настоящий growth-вердикт.

Продуктовые метрики могут расти при плоском бизнесе. Это не Confirmed; это Iterate или Inconclusive, и Hypothesis-карточка должна нести два отдельных поля Product signal и Business signal, чтобы различие записывалось, а не схлопывалось. В growth именно смешивание этих двух — самый частый способ отпраздновать неверный результат.

Пять условий

Первое. У продукта нет прямой записи в main. Продукт может создавать задачи в трекере, обновлять спецификации, править дизайн-черновики, запускать агентов, создавать ветки, открывать PR, готовить тесты и план телеметрии. Продукт не может мержить без ревью, обходить CI, трогать секреты, делать разрушающие миграции или катить на 100% без флага. Это не недоверие к продукту. Это нормальная граница безопасности, которая уже встроена в схему protected-repo в GitHub.

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

Третье. Кодовая база должна быть agent-friendly. Без тестов, без локального запуска, без CI, без feature flag-ов модель не взлетит. Отчёт DORA 2025 формулирует прямо: AI работает как усилитель, он магнифицирует уже существующие сильные и слабые стороны организации; наибольшая отдача приходит не от инструмента, а от качества системы под ним. [4] AI не починит плохой SDLC. Он ускорит его провалы.

Четвёртое. Всё, что делает агент, — это доказательства, а не «готово». Правильный выход агента: PR, результаты тестов, скриншоты, eval results, заметки по рискам, заметки по откату, подтверждение работы телеметрии, краткая сводка решения. Неправильный выход: «готово». Агент не закрывает гипотезу. Он собирает пакет доказательств, на который подписывается ответственный человек.

Пятое. Нужна инфраструктура feature flag-ов и телеметрии. Без feature flag-ов, поэтапного выката по когортам, kill switch и телеметрии Operator Loop не работает — он превращается в небезопасную автоматизацию. Минимум: feature flag-и, поэтапный выкат по когортам, kill switch, CI, стенд для preview или staging, дашборд телеметрии, план отката. Для AI-фич ещё: eval harness, версионирование промптов и моделей, стоимость на взаимодействие, latency guardrail, аудит разрешённых инструментов, регрессионные проверки при обновлении модели. Operator Loop не считает релиз единицей прогресса — единица это контролируемый rollout. Build заканчивается, когда изменение доступно под флагом, телеметрия подключена, план отката готов. Measure начинается, когда целевой cohort получает изменение.

Где модель сломается

Она не подходит, если нет feature flag-ов, нет CI, нет владения результатом у продукта, нет телеметрии, инженеры воспринимают это как обход своих ворот, продуктовые менеджеры не готовы отвечать за исход, кодовая база слишком хрупкая, все изменения считаются высоким риском, или компания продаёт разработку по фиксированному объёму. Она также ломается, когда фича не наблюдаема: если команда не видит эффект ни в продуктовом поведении, ни в бизнес-телеметрии, петле нечем замкнуться.

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

Продукт шипит через петлю.
Инженерия владеет control plane.

Если инженерию ставят перед фактом merged PR, который сломал прод, доверие испаряется за неделю, и модель откатывается к старой.

Рыночные свидетельства и предостерегающие кейсы

Эти кейсы не доказывают Operator Loop. Они показывают окружающий сдвиг: исполнение становится дешевле, не-инженеры ближе подбираются к production-артефактам, а ungated-автоматизация даёт регрессии по качеству.

Shopify в апреле 2025 сделал использование AI базовым требованием: менеджеры обязаны доказать, что задача не решается через AI, прежде чем просить новый найм. Те, кто не инженеры, используют Cursor для внутренних тулов. Публичных метрик по доле фич от не-инженеров нет — это организационная декларация, а не измеренный результат. [13]

Duolingo заменил контракторов на AI для производства контента и за год запустил 148 новых курсов. Это не программный код, но паттерн тот же: те, кто не инженер, катят продакшен-контент без традиционных ворот. [14]

Lovable (Стокгольм) сообщил о $200M ARR в ноябре 2025 — четырьмя месяцами ранее было $100M ARR. По отдельным публикациям примерно в тот же период компания приближалась к 8 миллионам пользователей. Это доказательство со стороны предложения: рынок «не-инженер → работающее приложение» существует и платит. Качество публично развёрнутых приложений не аудировалось. [15]

Atlassian сообщает, что Rovo Dev Code Reviewer уменьшил медианное время цикла PR на 30,8% и число комментариев от человеческих ревьюеров на 35,6% во внутренней online evaluation на 1 900+ репозиториях. [16]

Anthropic опубликовал внутреннее исследование на 132 инженерах (данные собраны в августе 2025): 59% рабочего времени — с Claude (год назад было 28%), +67% merged PR на инженера в день, 27% работы «не была бы сделана иначе». Сотрудники без инженерного бэкграунда используют Claude Code для отладки (51,5%) и задач по данным (12,7%). Исследование вендор-внутреннее, на основе самоотчётов. [17]

GitHub Copilot преодолел 20 миллионов пользователей за всё время существования; Microsoft сообщает об использовании в 90% компаний Fortune 100. Активное месячное или дневное использование не раскрывается. Вторичные агрегаторы вендорских данных сообщают о 46% сгенерированного кода (для Java — 61%) и acceptance rate 27–30%. Эти цифры стоит рассматривать как directional vendor-disclosure, а не как аудированные productivity-метрики. Если acceptance rate 27–30%, большинство сгенерированных подсказок не становятся принятым кодом. Генерация дешёвая. Acceptance остаётся гейтом. [18]

У этого momentum-а есть обратная сторона, и её тоже опубликовали.

Отчёт GitClear 2025 на 211 миллионах проанализированных строк из репозиториев Google, Microsoft, Meta и корпораций: code churn вырос с 3,1% (2020) до 5,7% (2024), дублированный код — с 8,3% до 12,3% за четыре года. Впервые за историю датасета copy/paste превысил перемещённый код. Рефакторинг упал с 25% до менее 10% изменений. [19]

METR в июле 2025 провёл рандомизированный контролируемый эксперимент: 16 опытных open-source-разработчиков на 246 реальных задачах в репозиториях 22k+ звёзд. С AI задачи выполнялись на 19% медленнее, хотя сами разработчики считали, что ускорились на 20%. Самый жёсткий counter-evidence к нарративу «AI = скорость»: для сложных задач в незнакомых кодовых базах AI замедляет опытного разработчика. [20]

Отчёт DX за четвёртый квартал 2025 на 135 000 разработчиков: 91% adoption, но только 22% merged кода квалифицируются как «написано AI» без крупной человеческой правки. При наличии AI-ревью в петле 81% команд сообщают об улучшении качества — против 70% без него. [21]

Stack Overflow Developer Survey 2025 [10]: 84% используют AI, но 46% не доверяют точности (год назад было 31%), 66% раздражает паттерн «почти правильно, но не совсем». Использование растёт, доверие падает.

Klarna — это не SDLC-кейс, но предостерегающий кейс автоматизации без достаточных human-quality gate-ов. В январе 2024 AI заменил 700 агентов поддержки; ранние метрики выглядели отлично: время ответа с 11 минут до менее 2, проекция прибыли +$40M. К маю 2025 CEO Siemiatkowski вернул людей: «слишком сосредоточились на эффективности и стоимости, результат — более низкое качество». Паттерн обобщается: полная автоматизация без human-quality gate может выглядеть как краткосрочная победа и дать среднесрочную регрессию. [22]

Что из этого следует для Operator Loop. Цифры по использованию и скорости большие; передача работы действительно ломается. Три независимых источника (GitClear, METR, DX) показывают: выход агента требует дорогой точки ревью. 22% merged-as-is у DX — это не дефект модели, это её проектное требование. Klarna показывает, что без этих ворот в клиентских доменах модель ломается за 12 месяцев.

Netflix и Booking.com работают на фронте экспериментирования, но прямого публичного доказательства того, что AI генерирует или оценивает гипотезы в их пайплайнах, пока нет. Компонент «гипотезы, управляемые AI» в модели остаётся [SPECULATIVE] для этих команд.

Это не Shape Up

Shape Up [5] разделяет дисциплину шейпинга, и на этом сходство заканчивается. Shape Up предполагает, что после шейпинга работа уходит команде дизайнеров и программистов. В Product-Operated Agentic SDLC передача ломается: продукт сам ведёт гипотезу через связанный toolchain.

Честная формулировка:

Shape Up fixes delivery discipline.
Operator Loop fixes learning discipline.

Shape Up asks: can we ship the shaped bet within appetite?
Operator Loop asks: did this hypothesis move product or business telemetry?

Shape Up перенёс работу из бэклога в выделенные ставки. Operator Loop переносит работу из инженерной передачи в прогоны агентов под управлением продукта.

Для первой adoption-зоны Operator Loop шестинедельные циклы обычно слишком медленные. Growth-циклы должны идти днями, не спринтами.

И это не vibe coding и не Product Engineering

Это не vibe coding: каждый прогон агента обязан производить доказательства, проходить гейты и заканчиваться телеметрией.

Это не классический Product Engineering: инженеры больше не дефолтные исполнители каждого артефакта низкого риска.

Это не agent-in-command SDLC: подотчётность за людьми, агенты исполняют.

Четыре правила Hypothesis Board

1. No hypothesis without signal.
2. No committed spec before prototype.
3. No agent output without evidence.
4. No done without telemetry.

По-русски:

1. Нет гипотезы без сигнала.
2. Нет финальной спецификации до прототипа.
3. Нет выхода агента без доказательств.
4. Нет «готово» без телеметрии.

Первое правило задаёт вход: без сигнала гипотеза — это чьё-то мнение. Четвёртое задаёт выход: без телеметрии вердикт подписывать нечего.

Одной строкой: нет доказательств — нет прогресса.

Что меняется в понедельник

1. Создать Insight Inbox.
2. Сделать Hypothesis первой колонкой доски.
3. Добавить Prototype до Spec.
4. Добавить Agent Run до Review.
5. Прописать триггеры перехвата.
6. Требовать feature flags для Measure.
7. Требовать вердикт, подтверждённый телеметрией.

Итог

Product-Operated Agentic SDLC — это не «продуктовый менеджер теперь работает за инженера». Это:

Продукт получает руль для задач низкого и среднего риска — через агентов.
Инженерия перестаёт быть узким местом на каждом шаге,
а получает более важную роль: control plane — skills, CI, фичефлаги, evals, триггеры, rollback, архитектура.

Самая сильная формулировка:

Shape Up moved work from backlog to shaped bets.
Product-Operated Agentic SDLC moves work from engineering handoff
to product-operated agent runs.

The unit isn't a pitch.
The unit is a hypothesis with evidence.
The end state isn't shipped.
The end state is a telemetry-backed verdict.

Operator Loop — не универсальная замена SDLC.

Это growth-first, product-operated агентная петля доставки для маленьких, наблюдаемых, обратимых, измеримых продуктовых изменений.

Продукт превращает сигналы в гипотезы, собирает прототипы и шипит больше. Агенты производят прототип, спецификацию, PR, тесты, телеметрию и доказательства. Инженерия владеет control plane: agent skills, CI, фичефлаги, evals, триггеры, rollback, архитектура. Телеметрия выдаёт вердикт.

Продукт шипит через петлю. Инженерия улучшает систему, которая шипит.

Начинать там, где петля короткая.

Первая зона применения — growth-разработка. Не enterprise-delivery. Не platform-рефакторинги. Не fixed-scope-контракты. У growth правильная форма: маленькие изменения, прямые метрики, обратимый rollout, давление на скорость.

Начинать с growth. Проверить петлю. Потом расширять границу.

Источники

1. Atlassian. Getting started with the Atlassian Rovo MCP Server. 2026. https://support.atlassian.com/atlassian-rovo-mcp-server/docs/getting-started-with-the-atlassian-remote-mcp-server/
2. Figma. Introducing Figma’s Dev Mode MCP server: Bringing Figma into your workflow. 2025. https://www.figma.com/blog/introducing-figmas-dev-mode-mcp-server/
3. OpenAI. Codex CLI and cloud agent for software engineering. 2025–2026. https://github.com/openai/codex and https://openai.com/index/introducing-codex/
4. DORA. State of AI-assisted Software Development. 2025. https://dora.dev/report/2025
5. Singer, R. Shape Up: Stop Running in Circles and Ship Work that Matters. Basecamp, 2019. https://basecamp.com/shapeup
6. Olsson, H.H.; Bosch, J. From Opinions to Data-Driven Software R&D: A Multi-case Study on How to Close the ‘Open Loop’ Problem. SEAA 2014.
7. Fagerholm, F. et al. The RIGHT Model for Continuous Experimentation. Journal of Systems and Software, 2017.
8. Atlassian. Jira Product Discovery — Ideas and Insights overview. https://www.atlassian.com/software/jira/product-discovery/guides/ideas/overview and https://www.atlassian.com/software/jira/product-discovery/guides/insights/overview
9. Kohavi, R.; Tang, D.; Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. https://www.cambridge.org/core/books/trustworthy-online-controlled-experiments/D97B26382EB0EB2DC2019A7A7B518F59
10. Stack Overflow Developer Survey 2025 — AI section. https://survey.stackoverflow.co/2025/ai
11. Microsoft Security Blog. Addressing the OWASP Top 10 Risks in Agentic AI with Microsoft Copilot Studio. 2026-03-30. https://www.microsoft.com/en-us/security/blog/2026/03/30/addressing-the-owasp-top-10-risks-in-agentic-ai-with-microsoft-copilot-studio/
12. Bessemer Venture Partners. Inside Shopify’s AI-first engineering playbook. 2025. https://www.bvp.com/atlas/inside-shopifys-ai-first-engineering-playbook
13. CNBC / Lütke, T. Shopify: prove AI can’t do the job before asking for more headcount. April 2025. https://www.cnbc.com/2025/04/07/shopify-ceo-prove-ai-cant-do-jobs-before-asking-for-more-headcount.html
14. TechCrunch. Duolingo launches 148 courses created with AI. April 2025. https://techcrunch.com/2025/04/30/duolingo-launches-148-courses-created-with-ai-after-sharing-plans-to-replace-contractors-with-ai/
15. TechCrunch. Lovable crosses $200M ARR, nears 8M users. November 2025. https://techcrunch.com/2025/11/10/lovable-says-its-nearing-8-million-users-as-the-year-old-ai-coding-startup-eyes-more-corporate-employees/
16. Atlassian. Developer productivity improved with Rovo Dev. April 7, 2026. https://www.atlassian.com/blog/artificial-intelligence/developer-productivity-improved-with-rovo-dev
17. Anthropic. How AI is transforming work at Anthropic. Published December 2, 2025; data collected August 2025. https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
18. Second Talent. GitHub Copilot statistics 2025 (aggregated GitHub data). https://www.secondtalent.com/resources/github-copilot-statistics/
19. GitClear. AI Assistant Code Quality Research Report 2025. February 2025. https://www.gitclear.com/ai_assistant_code_quality_2025_research
20. METR. Early 2025 AI-assisted experienced OSS dev productivity study. July 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ · arxiv.org/abs/2507.09089
21. 510. AI-assisted engineering Q4 2025 impact report. https://getdx.com/blog/ai-assisted-engineering-q4-impact-report-2025/
22. Fortune. Klarna CEO reverses course, hires humans back. May 2025. https://fortune.com/2025/05/09/klarna-ai-humans-return-on-investment/