Xora SDLC
Разработка, где человек ставит задачу и принимает результат
AI-native конвейер разработки, который проводит задачу от бизнес-требования до оттестированного релиза. Агенты выполняют аналитику, архитектуру, спецификацию, разработку, ревью и тестирование. Человек остаётся там, где нужны ответственность и решение: задаёт рамки, утверждает ключевые архитектурные решения и принимает результат.
Проблема
AI ускорил код. Но узкое место оказалось дальше
Генерация кода перестала быть главным ограничением. Код появляется быстрее, чем команда успевает проверить требования, архитектуру, качество и регрессии.
В результате дополнительная скорость разработки не всегда превращается в дополнительную скорость бизнеса.
Xora SDLC меняет сам процесс
Не AI-помощник, который пишет отдельные фрагменты за разработчиком
Конвейер, который проводит задачу через весь SDLC — с проверяемыми артефактами на каждом этапе и человеческим контролем в критических точках.
Конвейер
Доска: колонки — этапы, карточки едут сами
Доска выглядит как привычный канбан, но двигает карточки не человек. Колонка — это этап жизненного цикла с закреплённой агентной ролью и гейтом на выходе: как только артефакты этапа готовы и гейт пройден, карточка переходит дальше без чьего-либо клика.
Вход. Бизнес-задача, сформулированная человеком одним-двумя абзацами.
Между точками. Агент-аналитик превращает формулировку в проверяемые требования, агент-архитектор — в записанные решения и контракты, агент-разработчик пишет код строго через TDD, агент-ревьюер проверяет каждый merge request силами другой модели, агент-тестировщик проверяет продукт двумя контурами.
Человек. Стоит не у станка, а на трёх гейтах: подтверждает рамки после аналитики, утверждает trade-off архитектуры и принимает релиз.
Этапы
Шесть этапов. Три решения человека
SDLC автоматизирует выполнение, но не делегирует ответственность. У каждого этапа — свои артефакты и гейт: карточка не пройдёт колонку без них.
Аналитика
Агент-аналитик берёт бизнес-задачу, как её написал владелец — одним-двумя абзацами, — и разворачивает в полный аналитический пакет: user stories с критериями приёмки, сценарии с краевыми случаями, глоссарий и явные границы «что не входит». Все пробелы и противоречия он превращает в список вопросов владельцу — и снимает их здесь, пока это стоит минуты, а не спринты.
На выходе
- user stories с проверяемыми критериями приёмки
- сценарии: основной путь, краевые случаи, ошибки
- глоссарий домена и явные границы задачи
- вопросы владельцу — списком, до старта работ
Гейт · дальше только если
- каждый критерий приёмки проверяем тестом
- противоречия и пробелы закрыты ответами
- владелец подтвердил рамки — одно действие человека
Архитектура
Агент-архитектор превращает требования в устройство системы: компоненты и их границы, модель данных, контуры интеграций, выбор стека под нефункциональные требования. Ключевой артефакт — журнал ADR: каждое решение записано вместе с отвергнутыми альтернативами и причиной выбора. В конвейере, где исполнители сменяются, «почему» обязано жить в документе, а не в чьей-то голове.
На выходе
- схема компонентов и границы (C4)
- ADR: каждое решение с альтернативами и причиной
- модель данных и контуры интеграций
- стек и разложенные по компонентам НФТ
Гейт · дальше только если
- решения зафиксированы — не «в голове»
- нагрузка и безопасность разнесены по компонентам
- ключевые trade-off утверждены человеком
SDD-контракт
Specification-driven development: перед разработкой требования и архитектура сходятся в исполняемый контракт — OpenAPI, схемы данных, контракты событий и интерфейсов модулей, definition of done. Это единственный источник правды для трёх потребителей сразу: разработчик пишет по нему код, тест-план порождается из него, ревью сверяет с ним результат. Расхождение кода и документации невозможно по построению — документ первичен.
На выходе
- OpenAPI-контракты и схемы данных
- контракты событий и интерфейсов модулей
- definition of done по каждой задаче
- тест-план, порождённый из контрактов
Гейт · дальше только если
- по спецификации можно писать код, не задавая вопросов
- каждый контракт покрыт пунктом тест-плана
- работа нарезана на задачи размером в один прогон агента
Разработка · TDD
Агент-разработчик работает строго циклом test-driven development: по каждому контракту из спецификации сначала пишется падающий тест, затем минимальный код до зелёного, затем рефакторинг без изменения поведения. SDD и TDD смыкаются: контракт — это уже готовый сценарий теста, агенту не нужно его придумывать. Не бывает кода, для которого не существовало падавшего теста.
На выходе
- тесты, написанные до кода — по контрактам SDD
- код, проходящий все тесты
- рефакторинг под контракт, поведение неизменно
- PR с трассой до бизнес-задачи
Гейт · дальше только если
- цикл «красный → зелёный» пройден по каждому контракту
- сборка, линт, статический анализ чисты
- MR с трассой собран и передан в колонку «Ревью»
Ревью merge request
Каждый merge request разработчика проверяет агент-ревьюер, и маршрутизатор гарантирует главное: это другая модель, не та, что писала код. Ревью идёт не «по вкусу», а по артефактам конвейера: код сверяется с SDD-контрактом и трассой тестов, отдельными проходами проверяются качество (дублирование, сложность, лишние зависимости) и безопасность (секреты, инъекции, права). Каждое замечание — блокер, а не совет: MR не мерджится, пока агент-разработчик не исправит и ревьюер не перепроверит. Человек подключается к ревью выборочно — например, только к изменениям в платёжном контуре.
На выходе
- вердикт по каждому MR: approve или блокирующие замечания
- сверка кода с SDD-контрактом и трассой тестов
- findings качества: дублирование, сложность, лишние зависимости
- проверка безопасности: секреты, инъекции, права доступа
Гейт · дальше только если
- все блокирующие замечания исправлены и перепроверены
- ревьюер — гарантированно не та модель, что писала код
- расхождение с контрактом чинится в коде, а не в контракте
Тестирование: машина + агент
Первый контур — запрограммированный: unit-тесты, унаследованные от TDD, API-тесты, сгенерированные из OpenAPI, функциональные тесты по критериям приёмки и e2e-сценарии на Playwright. Он детерминирован, живёт в CI и ловит регрессии на каждый PR. Второй контур — агентский: агент-тестировщик (намеренно не тот, что писал код) открывает продукт как первый пользователь и работает за пределами сценариев — исследует, ломает, спешит, вводит невозможное, сверяет фактическое поведение с аналитикой и контрактами. Найденный баг сам становится карточкой на доске и уходит в «Разработку».
Контур 1 · машинный — ловит регрессии
- unit — наследие TDD, на каждый коммит
- API-тесты — сгенерированы из OpenAPI-контрактов
- функциональные — по критериям приёмки из аналитики
- e2e — Playwright, ключевые пути пользователя
Контур 2 · агентский — ловит неожиданное
- агент открывает продукт как первый пользователь
- исследует за пределами сценариев: ломает, спешит, ошибается
- сверяет поведение с аналитикой и контрактами SDD
- баг — сразу карточка на доске, с шагами воспроизведения
Слой исполнения
Пул исполнителей: роль — в процессе, исполнитель — в настройке
Агентные роли — аналитик, архитектор, разработчик, ревьюер, тестировщик — принадлежат конвейеру, а не конкретной модели. На каждую задачу маршрутизатор выбирает исполнителя из пула по политике этапа, специализации, стоимости и доступности.
Один этап может работать на Codex, соседний — на Claude Code; кросс-проверки конвейер устраивает намеренно: ревью и агентское тестирование отдаются не той модели, что писала код. Смена вендора — правка настройки, а не перестройка процесса.
Есть
- единый интерфейс задачи для любого исполнителя
- выбор per этап и per задача: политика, специализация, стоимость
- кросс-проверка: ревью и тестирование — другой моделью
- fallback: исполнитель недоступен — задачу берёт следующий
- журнал: кто, что, когда и по какому контракту делал
Нет
- привязки к одному вендору моделей
- ручной настройки под каждую задачу
- человеческого фактора: настроения, отпуска, увольнения
- потери знания при смене исполнителя — всё в артефактах
Принципы
Три принципа SDLC
Контракт раньше кода
Сначала определяется, что должно работать. Только после этого появляется код. Один контракт используют требования, разработка и тестирование — поэтому спецификация, реализация и проверка остаются связаны между собой.
Тест раньше кода
Ожидаемое поведение фиксируется до реализации. Каждый значимый контракт получает проверку, а разработка движется от проверки к работающему результату. Не просто «написать код». Сначала определить, как доказать, что он работает.
Проверяет не тот, кто писал
Агент-разработчик не является единственным источником истины. Результат независимо проверяет другой исполнитель. Ревью и тестирование работают как отдельные контуры контроля. Генерация и проверка разделены.
Роль человека
Человек остаётся в системе — но перестаёт быть её конвейером
SDLC не пытается убрать человека из разработки. Он убирает человека из операций, которые можно формализовать, проверить и повторить.
Человек
- формулирует задачу;
- определяет приоритет;
- утверждает рамки;
- принимает архитектурные решения;
- принимает релиз;
- отвечает за продуктовый результат.
SDLC
- анализирует;
- документирует;
- проектирует;
- формирует спецификации;
- пишет код;
- запускает проверки;
- проводит ревью;
- тестирует;
- возвращает ошибки в разработку.
Человек принимает решения. Конвейер выполняет работу.
Трассировка
Каждая строка кода имеет происхождение
SDLC сохраняет трассировку:
В результате через полгода не нужно восстанавливать контекст из переписок и памяти команды.
Для регулируемых отраслей этот же контур становится основой технического аудита.
Периметр
Ваш код остаётся у вас
SDLC может работать в вашем периметре или в облачной инфраструктуре. Для закрытого контура:
- код не выходит за пределы инфраструктуры;
- модели могут быть российскими или открытыми;
- ключи и production-секреты изолированы;
- действия агентов журналируются;
- SAST и SCA работают в CI;
- безопасность проверяется отдельным контуром.
Передача
Что остаётся вам
После внедрения у компании остаются:
И обученный человек внутри компании, который может этим управлять.
Мы не строим зависимость от Xora. Мы строим контур, который работает у вас.
Границы
Где заканчивается SDLC
SDLC отвечает за путь: задача → требования → архитектура → контракт → код → ревью → тестирование → релиз. Есть задачи, которые требуют отдельного контура.
Эксплуатация
24/7, дежурства, мониторинг и ответственность за доступность — отдельная услуга.
Инциденты production
Разбор инцидентов и восстановление production требуют отдельного процесса.
Миграции данных
Необратимые операции требуют отдельной подготовки, контроля и стратегии отката.
Продуктовые решения
SDLC реализует принятое решение. Он не определяет, что бизнесу следует строить.
Legacy
Если система не имеет спецификаций и тестов, сначала необходимо восстановить её поведение.
Для legacy можем провести отдельный этап:
Границы фиксируются до начала проекта.
Польза и выгода
Экономика: команда 10–20 человек → 1 человек
Конвейер не «ускоряет команду» — он заменяет её ролевой состав. Функции аналитика, архитектора, разработчиков, ревьюеров, тестировщиков и технического писателя исполняют агентные роли; человеку остаётся то, что нельзя делегировать — ответственность: постановка задач, приоритеты, гейты и приёмка.
Конвейер не спит, не ходит на встречи и не теряет контекст при передаче между этапами: каждый следующий этап читает артефакты предыдущего.
Качество при этом не «на доверии к модели» — оно встроено в процесс: ни одна карточка не проходит колонку без своих артефактов и гейта, каждая строка кода трассируется через тест и контракт до бизнес-задачи, а проверяет результат всегда не тот агент, который его делал.
Расчёт экономии
Сколько это в деньгах: два сценария
Считаем полную стоимость сотрудника для компании: медианная зарплата «на руки» по московскому рынку × 1,3 (НДФЛ и страховые взносы аккредитованной ИТ-компании). В сценарии «стало» учтены и человек, и расходы на конвейер — подписка на платформу и токены моделей при постоянной загрузке.
Команда 10 человек → 1 человек
Малый проект
Было. стоимость для компании ×1,3 = 3,55 млн ₽/мес → 42,6 млн ₽/год.
Стало. владелец продукта (300 000 ₽/мес на руки) — 4,7 млн ₽/год + модели и платформа (~250 000 ₽/мес) — 3,0 млн ₽/год = 7,7 млн ₽/год.
экономии на проект (−82% ФОТ) · ≈ 2,9 млн ₽ каждый месяц — конвейер окупается в первый же месяц
10 команд × 15 человек → 10 × 1 человек
Средний бизнес
Было. команда — 5,41 млн ₽/мес → 64,9 млн ₽/год; 10 команд → 649 млн ₽/год, штат 150 человек.
Стало. 10 владельцев продукта (по 350 000 ₽/мес на руки) — 54,6 млн ₽/год + конвейер на каждую команду (~400 000 ₽/мес) — 48 млн ₽/год = ≈ 103 млн ₽/год, штат 10 человек.
экономии на компанию (−84% ФОТ) · ≈ 54,6 млн ₽/год на каждую команду · штат разработки 150 → 10
Допущения: ставки — медианы «на руки» по московскому ИТ-рынку, 2026, уровень middle/senior, округлены; ×1,3 — приведение к полной стоимости для аккредитованной ИТ-компании (НДФЛ + льготные страховые взносы; для компании без ИТ-льгот коэффициент ≈ ×1,5 — экономия ещё выше). В расчёт не включены офис, оборудование, найм и текучка — они дополнительно увеличивают экономию. Бюджет моделей и платформы — консервативная оценка при круглосуточной загрузке конвейера.
Что измеряем
Меняется не только скорость разработки. Меняется стоимость единицы работы
SDLC переносит значительную часть SDLC из человеческого труда в автоматизированный агентный контур. Поэтому мы смотрим не только на количество написанного кода.
На диагностике мы фиксируем вашу исходную точку. На пилоте сравниваем её с результатом SDLC.
Не обещаем эффект заранее. Сначала считаем его на ваших данных.
Кому подходит
SDLC имеет смысл, если у вас
Особенно хорошо подходит для новых модулей и продуктов рядом с существующим legacy.
- собственная команда разработки;
- несколько параллельных потоков;
- высокая стоимость разработки;
- растущая нагрузка на QA и code review;
- накопленный технический долг;
- уже используются AI-инструменты, но они ускоряют отдельных разработчиков, а не весь процесс;
- есть требования к безопасности и контролю данных;
- необходимо масштабировать разработку без пропорционального роста команды.
Как начать
Пять шагов от разговора до постоянного потока
Разговор
40 минут
Разбираем задачу, текущий SDLC, инфраструктуру, ограничения по моделям и периметру.
Диагностика
1–2 недели
Изучаем репозиторий, тесты, CI/CD, документацию, постановку задач, архитектуру, текущие метрики. На выходе: карта готовности → потенциальный эффект → ограничения → scope пилота. И честный ответ: подходит ли вам SDLC сейчас.
Пилот
4–6 недель
Один выбранный модуль проходит полный цикл: задача → спецификация → архитектура → контракт → код → ревью → тесты → релиз. Критерии успеха фиксируются до старта. Стоимость пилота фиксированная. Стоимость диагностики засчитывается в пилот.
Постоянный поток
После подтверждения результата SDLC становится частью процесса разработки. Метрики и состояние потока доступны вашей команде.
Передача
Передаём настроенный контур, конфигурацию, документацию, права, знания и обучение владельца процесса.
Частые вопросы
Что спрашивают до старта
«У нас legacy. Там нет спецификаций и тестов»
Это не препятствие, но это другая задача.
Для legacy сначала необходимо восстановить фактическое поведение системы и создать минимальный слой проверок. Поэтому первый пилот обычно разумнее запускать на новом модуле рядом с legacy.
«Нам нельзя зарубежные модели»
SDLC может работать внутри вашего периметра с российскими или открытыми моделями.
Исполнитель является заменяемым компонентом архитектуры.
«Кто отвечает, если агент ошибётся?»
Агент не несёт ответственность за результат. Ответственность остаётся у людей.
SDLC ограничивает риск через артефакты, автоматические проверки, независимое ревью и человеческие гейты. Юридические гарантии, ответственность за дефекты и SLA фиксируются в договоре.
«Разработчики будут против»
SDLC не должен отбирать у команды контроль. Он забирает повторяемую работу: однотипное ревью, регресс, документацию, формализацию требований и технические проверки.
Команда сохраняет контроль над архитектурой, приоритетами и релизом.
«А если Xora исчезнет?»
У вас остаётся весь созданный контур: код, тесты, спецификации, конфигурация, документация и права. И человек внутри компании, обученный управлять процессом.
Это часть модели передачи, а не обещание на словах.
Разработка нового поколения
AI уже умеет писать код. Следующий шаг — научить весь процесс разработки работать как система
Человек формулирует задачу. Агенты выполняют работу. Контракты фиксируют результат. Другие агенты его проверяют. Человек принимает релиз. Расскажите о команде и задаче — рассчитаем эффект на ваших данных.
Заявка отправлена
Спасибо. Разберём задачу и ответим в ближайшее время.