За аббревиатурами SDLC и PDLC прячется простая вещь: жизненный цикл, по которому фича проходит путь от идеи до пользователей. Конечно, сейчас важно понять, как этот цикл выстраивать в формате AI-native.
Вместо разговоров мы поставили эксперимент — 6–8 недель на двух боевых проектах — и собрали методологию с двух сторон, разработки и продукта. Оба метода выложили в open source и делимся с вами здесь, должно быть полезно. Поехали!
Принцип для обеих сторон: жизненный цикл переезжает в репозиторий, агент ведёт работу, человек принимает решения на развилках.
🟥 Сторона разработки ↗️very-ai-framework
Агент ведёт фичу от идеи до прода, человек занимается инженерией.
• Код — единый источник истины. Всё идёт от кода, а не из параллельной джиры с ручной синхронизацией артефактов. От кода живут доки, задачи и контекст для продакта. Отсюда растёт агентное обслуживание: релизный агент реагирует на выкатки, задачи двигаются по доске сами, база знаний обновляется при изменениях в коде.
• Контроль сместился на контекст. Агенты эффективны, когда контекст задан правильно, и этот контекст — ответственность инженера. Человеческое ревью никуда не делось, но рядовой PR теперь это условно10 тыс. строк вместо привычных 300, и классические подходы к проверке на таком объёме не работают — нужны новые.
• Agentic review моделью из другого семейства. Код фичи перед выкатом обязательно проверяет вторая модель, например, у нас пишет Claude Code, ревьюит Codex. Разные модели качественнее ловят разные косяки.
🔳 Сторона продукта very-ai-product-loops☝️
Здесь тот же принцип: продуктовая стратегия вместо документа живёт в разных версиях в репозитории, который агент ведёт вместе с командой.
• Шесть шагов от идеи до спринта: паспорт продукта → анализ → стратегия → стратегический план → тактический план → план спринта. Каждый шаг это отдельный markdown-файл со своим горизонтом — от всего срока жизни продукта до пары недель.
• Живые регистры — память продукта. Сквозь все шаги проходят гипотезы, риски и метрики. Они рождаются там, где впервые становятся важны, и уточняются по мере спуска к спринту.
• Агент драфтит, человек решает. Агент читает текущее состояние, собирает черновики из реальных материалов, помечает утверждения источником , а на настоящих продуктовых развилках останавливается и предлагает пару вариантов. Изменения фиксируются в changelog и сигнал идёт дальше по цепочке.
Ручная стыковка #️⃣
Две стороны пока сшиваем вручную: из продуктового плана собираем список работ на спринт, каждую фичу скиллами переносим в таск-трекер, дальше она идёт в разработку и на прод. Прямой путь без ручного вмешательства у нас в планах.
🕐 Что пока не решено
• Безопасность — агенту нужен доступ почти ко всему — файлы, git, серверы, логи, код. Безопасных стандартов под это пока нет, проверку СБ такой контур не пройдёт. Копаем, но это открытый вопрос.
• Зрелость — разработку гоняем на боевых проектах, а продуктовая часть ещё совсем свежая. Обе репы публичные, но сырые и специфичные: это наш прикладной подход к общей концепции, а не готовое решение.
• Цена — быстрые релизы держатся на строгом флоу и возросших требованиях к разработчику — порог входа для инженера поднимается.
Дальше: замкнуть цикл после релиза ⚡️
Мы проектируем единый стандарт админок для наших SaaS, тогда петля замкнётся. Например, фича подняла удержание, но просадила активацию, сигнал уходит в продуктовый цикл, агент выдвигает гипотезу, что виноват усложнившийся процесс, и в следующий спринт падает конкретная задача по устранению этого. Так получится измерять эффект фич и мониторить продукты по метрикам.
Авторы этого поста и, соотвественно, своих фреймов:
Артём Лысенко — Team Lead в R&D red_mad_robot;
Тим Михайлов — Product Owner в R&D red_mad_robot.