Про доработку и расширение классической сервисной модели расскажу в ближайшее воскресенье на конференции “Современная системная инженерия и менеджмент-2026”

Название моего доклада: «Расширение онтологии сервисного запроса при помощи LLM+FPF».
Подключайтесь по этой ссылке (откроется Zoom, сейчас там идут другие доклады):
https://systemschool2026-zoom.timurb.ru
Слайды соедующим сообщением.

Мой слот по расписанию: 13:30-14:00

Слайды: https://systemschool2026.timurb.ru

Интересный момент, что с появлением coding agents автоматизация SDLC (т.е. в частности CI/CD, вот это наше всё) стала ещё более важной чем была до этого.
Люди более детерминированные чем LLM тупо в силу того что у них есть привычки, и в силу того что постоянно общаются друг с другом вне кода и тикетов. А LLM это бывалый сыч, который всё умеет, но сидит где-то в углу, кодит что-то в одиночку, что-то там бормочет, иногда вскрикивает, и ни с кем не общается. Задачи закрывает быстро, но его лапшу никто кроме него понять не может, да ещё и душнит как только какой-то косяк ему предъявишь.

И с одной стороны, для организации такой ситуации нужен нормально работающий SDLC, а с другой — часть его переедет из собственно CI-сервера в AGENTS.md, openscpec workflows и подобные промпт-компоненты

Как вы знаете, я давно работаю над «путем развития инженера» от джуна до милорда, и чтобы при этом описание этого пути получилось компактным.
Переход на каждый новый грейд это как переход в новую профессию — нужно не развитие существующих навыков, а абсолютно новые (рассказывал про это в прошлом году на конференции).
И чтобы это не взрывало мозг людям, важный момент, чтобы рост был непрерывным — новые навыки появляются в рамках того уровня где ты находишься, закрепляются и осваиваются и ты движешься дальше.

Рост из миддла в сеньора это не «изучить больше инструментов» или «изучить какие-то инструмент глубоко», а научиться декомпозировать задачу на составляющие, контролировать насколько качественно эти составляющие реализованы.
«Глубокое знание инструментов» (или навык быстро набирать эту глубину) это просто необходимая база для того чтобы выполнять эту самую декомпозицию.
Рядом органично вырастают архитектурные паттерны — если мы можем разрезать задачу на структурные части, то дальше логичным образом мы перестаем оперировать деталями и начинаем оперировать этими самими структурными частями, связями между ними, их характеристиками и т.д.

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

В управление кубером, облаком и инфрой вообще через агентов + MCP есть интересный и тонкий момент.
Это уход от configuration management в «deployless» (шуточный термин): «ща емана тут на проде один параметр поправлю падажжи нах»
Т.е. это шаг назад.

Подобный уход уже был некоторое время назад через Operator Pattern, и к нему до сих пор довольно неоднозначное отношение в сообществе — хорошие операторы писать сложно, пользоваться ими тоже сложно, супер важен API/DX для них и т.д.

Так вот, с агентами и MCP похоже будет продолжение этой истории по одному из направлений (или сразу по всем трем):
• трэш и содомия «deployless и правим на проде» (и все откатится обратно)
• агенты будут не править кубера/облака, а будут коммитить в гит — благо что они это умеют, и дальше все катится обычными пайпами
• либо будет дальнейшее развитие Operator Pattern и пока неясно в какую сторону (замену софта на агента умеет делать мало кто, и плюсы от этого довольно узкие)

Недавно Онтико (организаторы крупнейших технологических конференций) сделали публикацию про новую систему разделения труда, которая у нас на подходе с появлением ИИ: https://t.me/onticochannel/60

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

Давайте рассмотрим слайд «Матрица четырёх промышленных революций» (с ним я согласен только отчасти) и проследим как собственно происходила эволюция через революции.

У тебя есть цепочка добавления ценности (совпадает с разделением труда).
Во время промышленной революции №0 (нумерация со слайдов) разделение труда начало проявляться в обществе, а не только в общине: не человек пришел к соседу за луковицей/тканью, а человек пришел к мастеру, который именно этим и занимается профессионально, и занимается не по запросу (ты попросил я сделал), а под постоянный сбыт.
Этот ремесленник, или может быть купец (но еще не предприниматель).

Следующей промышленной революцией обычно считается изобретение паровой машина и механизация силы.
Но вот с промышленными революциями 20 века не все так однозначно.

Если говорить о конвейере как центральном элементе промышленных революций 20в, то до собственно прохождения детали по конвейеру у тебя должна появиться стандартизация изделий и деталей (19в), и дальше декомпозиция техпроцесса на стадии (операции) и их регламентация. Их сборка в поток это и есть конвейер.
Первое — это инженерия, второе — технология.
Работа с временами производства в потоке это менеджмент, но менеджмент процессный, который весьма сильно отличается от например менеджмента проектного и продуктового. И до второй половины 20 века еще не считалось зазорным производить продукцию «на склад», т.е. и процессный менеджмент был в довольно зачаточном состоянии.

Если более пристально посмотреть на изменения цепочки добавленной ценности («горизонтальный сдвиг»), то увидим, что происходили переходы:
• Обособление торгово-сбытовой функции: от «стихийного взаимодействия между ремесленниками» к установившимся цепочкам добавленной ценности (каналам спроса и поставки)
• Появление управленческого учета и здесь же стандартизация выпускаемой продукции (т.е. появление функции проектирование изделий): от простых и локальных цепочек к длинным, сложным и географически распределенным, где нужна спецификация на продукцию
• Становление операционной декомпозиции и регламентации: деление на операции в производстве, конвейер
• Появление процессного управления: оптимизация потока в производстве (TPS, Lean, вот это все), глобализация производств
• Формализация и инструментализация проектирования и перепроектирования систем и организаций <— ИТ здесь
В параллель с этим еще идут сильные линии маркетинговая и предпринимательская (как у Шумпетера) с начала 20в, которые я сейчас не рассматриваю.

Если продолжать цепочку, то для меня лично выглядит, что с появлением ИИ и других технологий следующий шаг это «становление управления функциями» и «протоколизация коммуникаций» — быстрое производство функций (а не изделий), и создание протоколов взаимодействия чтобы развязать узкое место в коммуникациях (смарт-контракты и маркетплейсы против юридической прозы).

Ведущие роли в новом технологическом укладе — предприниматель (тот, кто выявляет необходимость и оправданность новых продуктов и функций), и коммуникатор в техническом смысле — тот, кто строит протоколы взаимодействия между разнородными системами и сообществами и все что это включает (формат, совместимость онтологий, управление конфигурацией и эволюцией протокола, доверие и т.д.)

Если кого-то из вас shieldybot незаслуженно кикнул из чата — напишите мне (@TimurBatyrshin), я вас разбаню

Попросили меня сегодня прокомментировать модель зрелости для внедрения AI в devops, и у меня получились такие интересные результаты, что чем выше уровень зрелости по условному CMMI тем меньше в нем места для AI в принципе.

(на примере только CI/CD, не рассматривал другие поднаправления)
UPD: кажется можно и в принципе для разработки эту шкалу применять

L0 (нулевой). AI не используется для CI/CD.
L1 (стихийный). AI для написания и исправления кода пайплайнов по месту.
L2 (повторяемый). AI используется для написания сквозных пайплайнов на местах.
Задан набор правил и code style для агентов.
L3 (управляемый). Заданы критерии качества к коду пайплайнов написанного AI.
Построен процесс для контролируемой доставки инкрементов пайплайнов, реализованных агентами.
Результаты работы пайплайнов (результаты и логи сборок и т.д.) доступны агентам для анализа.
Задана и выполняется политика безопасности для доступа агентов к исходному коду приложений
L4 (оптимизируемый). Заданы характеристики качества самих пайплайнов, реализовано измерение качества, эти характеристики качества используются в качестве цели для постановки задач для AI.
Заданы и выполняются политики по выполнению операций не связанных с управлением кодом пайплайнов и приложений -- запуск пайплайнов, создание тикетов, создание архитектурных RFC для пайплайнов, работа с секретами (например, создание плейсхолдеров)
L5 (инновационный). Выбран портфель характеристик элементов ИТ-ландшафта; характеристики пайплайнов входят в состав этих элементов.
Выполняется управление портфелем характеристик, задания на изменение набора характеристик ставятся в качестве задач для AI.
Заданы, контролируются и улучшаются правила и полномочия действий конкретных ролей агентов на уровне организации, а не только на уровне технологических элементов.

А вы что думаете?

Если сделать смелый шаг и принять, что в LLM уже есть ответы на все вопросы и есть реализация всех возможных задач (ок, не сами ответы и не сама реализация, а быстрый и дешевый способ их получить в мало мальски достаточном качестве), то узкое место в предприятии смещается от получения этих ответов и решений, к их фактическому воплощению — эта роль всегда останется за человеком, ее полностью агентам никогда не отдадут или это потребует социальных изменений сравнимых с переходом от монархии к коммунизму или государственному перевороту в масштабах человечества.

Фактическое воплощение решений — это не писать код или тексты, не рисовать картинки, не строить модели, а вписывать их в реальность.

За этим стоит достаточно большая и непростая работа:
• выстраивание уже существующих систем, людей, и организаций вокруг новой реальности (которой еще нет)
• визионерство того какая это новая реальность в принципе это должна быть
• построение циклов обратной связи для поддержки этой новой реальности (не loop engineering, а построение именно физических циклов в реальности — обмен сообщениями, документами, артефактами и физическими предметами, и конкретные действия сотрудников и систем)
• непрерывная поддержка и корректировка этой картины (continuous vision)
• ну и естественно, создание всех необходимых инструментов, программ и подобных инструментальных объектов — с этим агенты нам помогут

Что-то типа «стартап теперь запустить может каждый», но ограничение теперь не в реализации (она перестала быть ограничением лет пятнадцать назад) и не в стоимости реализации (она перестала быть ограничением сейчас), а в собственно том чтобы брать и делать.

Если это рассуждение продолжать не в сторону запуска отдельных приложений, а в сторону масштаба, мы можем прийти к еще одной интересной гипотезе.

Agile и DevOps 10-15 лет назад позволили выпускать прототип приложения за месяц, за 3 месяца первую версию, за год полноценный продукт, который генерирует доход.
Если продукт успешен и у основателей есть видение совпадающее с будущей реальностью (и/или влияние на массы), следом за ним выпускались другие продукты и через несколько лет получалась «экосистема продуктов» или «платформа» (as in boundaryless.io, а не team topologies, не перепутайте) — Hashicorp, Ruby on Rails, Kubernetes, Shopify.

Сейчас по-видимому должны появиться какие-то подходы, которые позволят сокращать цикл выпуска «экосистем», а не отдельных приложений.
Можно еще порассуждать какой disruption будут оказывать «экосистема on demand» на корпорации, в которых ИТ-ландшафт обычно достаточно зацементирован, или собран на зыбком балансе костылей и палок, но это я оставлю на другой раз.