# Не покупайте платформу: AI-SDLC на готовом стеке

Canonical: https://www.kt-team.ru/blog/ai-sdlc-off-the-shelf-stack

Source: https://www.kt-team.ru/blog/ai-sdlc-off-the-shelf-stack

## AI-SDLC 2026: готовый стек вместо вендорской платформы

Выигрышный AI-SDLC для среднего и крупного бизнеса в 2026 — не ещё одна вендорская платформа-конструктор, а git-native сборка из готовых, off-the-shelf инструментов, где владелец процесса разговаривает с Claude Code или Codex и меняет прод. Между ним и продом стоят ровно три вещи: git-репозиторий с реестром, git-native лог промптов и лёгкий автоматический гейт. Между владельцем процесса и продом нет ни одного человека-привратника и ни одной проприетарной платформы — только автоматический обратимый гейт. Мы проверяем это на себе: этот сайт правит AI-агент поверх репозитория, и каждый промпт пишется в prompts/log.jsonl рядом с изменением.

## Коротко

- Выигрышный контур — git-native сборка из готовых инструментов: это не «всё open source» и не вендорская платформа. Движки Claude Code и Codex проприетарны, но арендуются и заменяются; git и CI открыты, MCP — открытый протокол.
- Три опоры между владельцем и продом: реестр репозиториев, лог промптов и лёгкий обратимый гейт. Это тончайшая платформа, которую вы строите и которой владеете, а не толстая, которую покупаете.
- Shadow AI — рациональная реакция на трение: 78% пользователей ИИ приносят свои инструменты мимо ИТ. Тяжёлый централизованный контур не убирает риск, а перепрятывает его в тень.
- Гейт — не человек, говорящий «да», а автоматическое доказательство: тесты и валидаторы без человека; ревью подключается только на изменениях с большим радиусом поражения.
- Лог промптов даёт провенанс, а не аудит: JSONL-файл правится обычным коммитом. Полноценный аудит — это защита ветки и подпись коммитов поверх лога.

## Тезис: не покупайте платформу — соберите тонкую и владейте ей

Вендорская платформа-конструктор обещает «всё в одном», а на деле создаёт три проблемы: lock-in на поставщика, очередь к ИТ-отделу на каждую правку и гейты, которые владелец процесса начинает обходить. Ответ — не «нет платформы», а самая тонкая платформа, которую вы строите сами и которой владеете. Она собирается из готовых commodity-инструментов и выигрывает потому, что удобнее обходного пути.

Честно про стек: git и CI — открытые, MCP — открытый протокол обмена контекстом между агентами и системами. Движки Claude Code и Codex — проприетарные платные клиенты, которые вы арендуете и в любой момент заменяете на другой. Выигрыш не в том, что «всё open source», а в том, что нет bespoke-платформы, из которой нельзя уйти.

Тонкая — не значит «никакая». У неё есть контракт: изменяемые данные читаются и меняются через agent-readable CLI с plan/apply/verify, общий production-контур живёт по единому пути, у сервиса есть собственный аккаунт, а доступ к данным идёт через MCP с минимальными правами, а не прямым подключением к БД. Это тот же инженерный фундамент, что и у нашего сервиса [AI-native разработки](/instruments/ai-native-development); здесь мы разбираем не сервис, а как собрать сам контур и почему он выигрывает.

## Опора 1: git-репозиторий с реестром всех репозиториев

Первая опора — карта. Реестр перечисляет все репозитории контура: скиллы, агентов, сервисы, серверы, boilerplate и рекомендации по изменениям. Он одинаково читается человеком и AI-агентом: агент по реестру понимает, где лежит нужный процесс, какой скилл его меняет и куда писать результат.

Мы держим такой реестр у себя. Наш power-user boilerplate — это REGISTRY.md как единый каталог артефактов и зеркальная структура подгрупп skills, agents и servers, повторяющая GitLab-группу. Новый сервис по умолчанию создаётся как общая платформа: он разворачивается из общего пути, а не из домашней папки одного разработчика, и другие авторизованные агенты получают к нему доступ через общий аутентифицированный контур без передачи секретов.

Реестр отвечает на вопрос «что и где меняется». Кто имеет право менять прод сам и на каком уровне зрелости — отдельная тема; мы разбираем её в материале про [уровни разработчика и ПМа L10–L60](/blog/developer-pm-assessment-ai-native-workflow).

## Опора 2: владелец разговаривает — и доходит до прода

От разговора владельца до прода: Владелец процесса → Claude Code / Codex (готовый арендуемый клиент, заменяем) → Реестр репозиториев (где лежит процесс и чем менять) → Plan + diff (промпт пишется в prompts/log.jsonl) → Лёгкий гейт (тесты и валидаторы без человека) → apply → verify → прод (наблюдаемость на месте).

Ветвление по риску: при низком риске изменение проходит гейт автоматически и уходит в прод; при большом радиусе поражения подключается ревью человека; откат — git-revert возвращает прод в прежнее состояние. Между владельцем и продом нет человека-привратника и проприетарной платформы — только реестр, лог промптов и автоматический обратимый гейт. Лог и наблюдаемость замыкаются обратно на владельца.

## Опора 3: все промпты логируются git-native, без центральной БД

Третья опора — прослеживаемость. Каждое изменение прода сделано по промпту, и этот промпт хранится рядом с изменением, в самом репозитории, без отдельной БД и внешнего сервиса. Так у любой правки есть провенанс: видно, какой запрос породил какой diff.

Ключевое слово — провенанс, а не аудит. Файл лога правится обычным коммитом, как любой другой файл: наш собственный лог однажды был удалён и добавлен заново. Он даёт прослеживаемость и источник записи, но не защищённый от подделки аудитный след. Полноценный аудит — это защита ветки, подпись коммитов (git commit -S) и требование записи в CI; лог-файл — прагматичный первый слой под ними. И это молодая, недавно принятая у нас конвенция, а не годами обкатанная система.

## Три механизма и что с ними происходит при squash и rebase

- **Трейлеры коммита.** Строка Prompt: … в теле коммита видна и грепается, но хрупкая: squash при слиянии съедает тела промежуточных коммитов. Наши авто-коммиты Deploy… — ровно этот случай.
- **Файл prompts/log.jsonl.** Append-only JSONL рядом с кодом. Переживает любой squash и rebase, читается человеком и агентом. Это рекомендуемый источник записи.
- **git notes.** Заметки переживают rebase, но по умолчанию невидимы и не пушатся. Durable, но их легко потерять из виду.

## А что с секретами и ПДн в промптах?

Логировать все промпты в репозиторий — значит сразу спросить: а если в промпте секрет или персональные данные? Ответ до записи, а не после. Промпты проходят секрет-скан и обезличивание перед попаданием в лог (у нас для этого есть отдельный скилл anonymize и практика 152-ФЗ), либо лог живёт в приватном репозитории. Пример строки лога: {"ts":"2026-07-18","author":"process-owner","prompt":"обнови прайс на странице услуги","diff":"pricing.json","commit":"3f6ed32"} — значения ПДн в неё не попадают, они псевдонимизируются до записи.

## Лёгкий гейт: почему он не противоречит принципу

Гейт стоит между владельцем и продом — как это сочетается с «ни одного привратника»? Разрешение простое: гейт — это не человек, говорящий «да». Это автоматическое доказательство безопасности изменения: plan/apply/verify, тесты и валидаторы отрабатывают сами. Человек подключается только на изменениях с большим радиусом поражения, а не на каждой правке. Гейт быстрый, разнесённый по областям и обратимый: если что-то пошло не так, git-revert возвращает прод назад.

Здесь наш собственный опыт — самый сильный аргумент, и он честный. Наш первый гейт был монолитным: одна общая проверка на всё, и любая ошибка валидатора — даже в чужой, несвязанной области — замораживала публикацию всего сайта. Такой централизованный гейт связывает владельцев между собой и сам провоцирует shadow AI: проще обойти, чем ждать. Поэтому правильный ход — не более крупный центральный гейт, а гейты по областям, разнесённые по риску. Даже мы уходим от монолитного гейта к разнесённому. Правило одно: санкционированный путь должен быть удобнее обходного.

## Вендорская платформа vs git-native сборка

| Критерий | Вендорская платформа | Git-native сборка на готовом стеке |
| --- | --- | --- |
| Владение и lock-in | Данные и логика заперты в продукте поставщика | Всё в вашем git, движок заменяем |
| Скорость правки владельцем | Через очередь к ИТ или вендору | Владелец меняет прод сам в рамках своего уровня зрелости |
| Прозрачность | Логи внутри платформы, экспорт ограничен | Каждый промпт и diff лежат в репозитории |
| Риск shadow AI | Высокий: трение гонит в тень | Ниже: санкционированный путь удобнее обходного |
| Стоимость | Лицензия плюс lock-in, «всё включено» на бумаге | Обмен: сиденья Claude/Codex плюс инженерное владение и сопровождение реестра, гейта, MCP и валидаторов. Дешевле по lock-in, не по усилию |
| Кто отвечает за результат | Поставщик за платформу, вы — за исход | Вы владеете контуром и результатом |
| Интеграции | Проприетарные коннекторы | MCP как открытый протокол |
| Гейт | Часто монолитный, общий на всех | Разнесённый по областям и риску, обратимый |

## Анти-теза: тяжёлый централизованный контур = shadow AI

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

**78%** пользователей ИИ приносят собственные инструменты на работу (BYOAI), вне ИТ-контроля.

- Данные — опрос 31 000 человек в 31 стране (Microsoft/LinkedIn, Work Trend Index, май 2024); у вендора-источника есть интерес показать проблему, но порядок величины подтверждают и независимые опросы.
- Тяжёлый централизованный контур не убирает риск, а перепрятывает его: данные компании утекают в неконтролируемые сервисы.
- Тонкий git-native контур с логом промптов и лёгким гейтом делает контролируемый путь удобнее теневого.

## Что делает KT.Team

Мы собираем такие контуры и живём в них сами.

OSNO-VA — наш AI-продукт для бухгалтерии: управленческая отчётность с MCP-доступом для людей и агентов, автопроведение первички в 1С (от фото счёта до проводки) и корпоративная память проектов в GIT. Это живое доказательство связки MCP плюс git-native память, а не слайд. Финансовую логику мы вынесли из хрупких таблиц в SQL и исполняемые скиллы, к которым агент обращается через MCP.

Контекстный слой — sloy-KT: чаты, встречи, файлы, задачи и финансы становятся машиночитаемым контекстом в GIT, разбитым по проектам. Реестр и структура — наш power-user boilerplate с REGISTRY.md. А этот сайт — тот самый контур в действии: его правит AI-агент поверх репозитория, с логом промптов рядом с изменениями.

Границу мы называем честно: контур даёт владельцу процесса менять прод сам, но в рамках его уровня зрелости — реестр, агент и лёгкий гейт компенсируют разрыв, а не отменяют его. ИИ без инженерных основ роняет стабильность, и это прямо показывают метрики DORA, поэтому гейт нужен, но лёгкий. Собрать первый рабочий рычаг можно на живой задаче за 1–2 недели, с оплатой после принятия результата.

## Соберём ваш первый AI-рычаг

Возьмём одну реальную задачу владельца процесса и соберём под неё рабочий git-native контур: реестр, агент, лог промптов и лёгкий гейт. Оплата — после принятия результата. [Разобрать задачу за 30 минут](/ai/agent-sprint-for-executives).

## Источники

Дата проверки источников: 18.07.2026.

Microsoft и LinkedIn, «2024 Work Trend Index Annual Report: AI at Work Is Here. Now Comes the Hard Part» (8 мая 2024, опрос 31 000 человек в 31 стране): 75% сотрудников умственного труда используют ИИ на работе, 78% из них приносят собственные ИИ-инструменты (BYOAI) — microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part