XDLC в деле #0. Один фреймворк на все среды
Запускаю серию: публично обкатываю наш "будуший корпоративный фреймворк" - XDLC, надстройку над AI-Disrupt PDLC Сбера (его наследник - амазоновский AI-DLC). Итерации - на реальных задачах, с цифрами и провалами.
Полигоны ("с нуля", "новый", "legacy" 5-7+ лет): 1. SmartBiz - SaaS с тремя маркетплейсами: n8n-автоматизации (self-hosted или наше облако), дашборды Apache Superset, AI-агенты и модели через MCP (провайдеры - только Россия, плюс свои); 2. PlayBiz - мой личный сайт: озеро медиа-контента, портфолио, услуги и многое другое; 3. Legacy заказчика (с разрешения, без конкретики): кастомные IM/CRM/CMS.
Веду все один - все роли на мне. Исполнитель кода - SourceCraft от Яндекса (агент + IDE/OS/инфра). Для "дешмана" сверху: максимум "АлисаAI". Принципиально: никаких VPN/Proxy - доступно "среднестатистическому Васе из глубинки России" (это Я 😉). И подход должен доказать: сменись модель хоть на локальный Qwen<=10B - проседают качество и скорость, но не сам подход.
Откуда 🦶🦶: Сбер в июне 2026 выпустил whitepaper AI-Disrupt PDLC v2.0: двухпетлевая модель (намерение -> реализация), SDD (разработка через спецификацию), "среда важнее модели", Governance Mesh etc. Подход супер, но как он ляжет на МСП? У Сбера ресурсы с запасом, у МСП - нет: решил проверить на "реальных" проектах.
Изучил документ и предшественников - не нравится их "рамка": все они про ПО и "цифровые продукты". Discovery в примерах - finTech и страховые, метрики - DORA, R0-R5 - операции с кодом etc. Все круто, да, но внутри их мира.
Мне нужен каркас, который переживет не только софт: умный дом, программируемые чипы, роботы, да хоть "киберпанк" - мало ли что "великий русский ум" завтра выдумает 🤣
Поэтому собрал XDLC, где X - параметр домена: X = P (продукт), S (софт), A (агент), H (железо), C (киберфизика), O (организация)...
PDLC, SDLC, ADLC - частные случаи одного цикла. Фреймворк один - домен подставной. Пока работаем с P/S/A (+O для мета-команды).
Что уже работает (v0.1 = draft, все - MD-файлы в git): - база знаний читается агентом нативно: спеки, паттерны, карта модулей, журнал решений - без трекеров; - состояние живет в репо, а не в чате: потерял контекст - приложил STATE (почему не SessionHandoff - потом) и продолжил с места остановки, ну это классика, которая еще в "мохнатых 20-ых" работала; - экономия дорогих токенов встроена: дешевый контур (планирование, спеки) vs дорогая кодогенерация по файлу-заказу WO=WorkOrder - привет 1С.
Зачем надстройка (WO и прочее) вместо монолитного SDD? Тоже потом 😉. Подсказка: мы не Сбер, у нас $ нет.
"Среда важнее модели" - дожимаю: среда целиком в файлах -> заменима вся цепочка, не только модель: агент, IDE, исполнитель, да что угодно - у вас кроме кучи MD-шников вообще нифига не будет: проекты живут как "структурно-текстовое описание", а "код"/"прод"/"шмот" - ВНЕЗАПНО side-артефакты. Фантастика? Проверим! 🧐
Роли - шапки из ролевой карты Сбера, не оргструктура: product engineer ведет от идеи до замера, platform engineer строит среду, guardian engineer - контур управления. Свой шаг: обобщил product engineer до X-Engineer - инженера под домен. И добавил седьмую компетенцию - научное мышление: гипотеза результата без умения ее опровергнуть - это просто лозунг. Как даже тот же Сбер будет делать из своих "джунов будущих ученых" - я хз. А вот я планирую.
Конвейер серии: issue -> спека -> заказ агенту -> акт приемки -> пост. Внедрение: ядро xdlc + .xdlc каждого проекта. Детали - в следующих статьях.
Если фреймворк покажет прирост на замерах - уйду в массовое внедрение: "дешевые и быстрые" старты - наш хлеб как и поддержка кастомных web-проектов (CRM/CMS/ERP/IM), которые "хотят хоронить". Хотите так же - пишите в личку или на сайт.
Вопрос к аудитории: Субъект жизненного цикла DLC - только IT? Когда говорят про DLC - все равно подразумевают софт/медиа/роботы/{ВСТАВЬТЕ_ОКОЛО_ITшное}. Шагнем дальше вместе?
Вот вам и челлендж: пишите свой проект вместе со мной, весь фрейм мы конечно не откроем, но по ходу эксперимента точно вывалим многое ;)
