Я переименовал канал и сменил направление.
Миссия привнести инженерию в разработку оказалась невыполнимой. И через десять лет всё так же будут спорить «микросервисы vs монолит», хотя и то, и другое — фейк, и само это противопоставление абсурдно.
Зато в архитектуре интеллектуальных систем пока ещё можно сказать своё слово — до того, как западные хайп-пасторы придумают очередную чушь, а наши копи-пасторы разнесут её по просторам.
Миссия привнести инженерию в разработку оказалась невыполнимой. И через десять лет всё так же будут спорить «микросервисы vs монолит», хотя и то, и другое — фейк, и само это противопоставление абсурдно.
Зато в архитектуре интеллектуальных систем пока ещё можно сказать своё слово — до того, как западные хайп-пасторы придумают очередную чушь, а наши копи-пасторы разнесут её по просторам.
👍23😁6👏5❤4🤯2🍾2🔥1😢1🤩1👌1
Что такое железнодорожный пузырь?
В середине XIX века железные дороги были эквивалентом AI-стартапов:
инновации, вера в огромный рост, минимальное регулирование.
Железные дороги воспринимались как путь к быстрому обогащению, поэтому:
- компании выпускали огромные объёмы облигаций;
- банки активно кредитовали строительство;
- инвесторы покупали бумаги железных дорог почти вслепую.
В результате объём железнодорожного строительства значительно превысил реальную потребность экономики.
Пузырь лопнул, но железные дороги остались.
В середине XIX века железные дороги были эквивалентом AI-стартапов:
инновации, вера в огромный рост, минимальное регулирование.
Железные дороги воспринимались как путь к быстрому обогащению, поэтому:
- компании выпускали огромные объёмы облигаций;
- банки активно кредитовали строительство;
- инвесторы покупали бумаги железных дорог почти вслепую.
В результате объём железнодорожного строительства значительно превысил реальную потребность экономики.
Пузырь лопнул, но железные дороги остались.
🔥5👍1🤔1
Чтобы не создавать информационный вакуум, поделюсь новостями.
В Сбере мы строим САПР для архитекторов и встраиваем в него СППР. В рамках этого направления я сделал прототип GraphRAG с NL-to-Query и устойчивой точностью 85-100%, заметно обновив изначальный концепт: https://news.1rj.ru/str/IntelligentSystemsArchitecture/328
Параллельно начал работу над Reasoning RAG (https://news.1rj.ru/str/IntelligentSystemsArchitecture/293), и первые результаты уже выглядят многообещающе. Поделюсь наработками в статьях в следующем году.
И GraphRAG, и тем более Reasoning RAG имеют нейросимволическую архитектуру, в которой онтологии играют решающую роль.
Тезисы:
1. RAG-системы меняют подход к организации доступа к корпоративным знаниям — они комбинируют «умный» поиск на основе запросов на естественном языке с исследованием гетерогенных баз знаний.
2. СППР будут играть решающую роль в САПР, поскольку при проектировании мы постоянно принимаем решения, а возможности СППР (интеллектуальных помощников) продолжают расти.
В Сбере мы строим САПР для архитекторов и встраиваем в него СППР. В рамках этого направления я сделал прототип GraphRAG с NL-to-Query и устойчивой точностью 85-100%, заметно обновив изначальный концепт: https://news.1rj.ru/str/IntelligentSystemsArchitecture/328
Параллельно начал работу над Reasoning RAG (https://news.1rj.ru/str/IntelligentSystemsArchitecture/293), и первые результаты уже выглядят многообещающе. Поделюсь наработками в статьях в следующем году.
И GraphRAG, и тем более Reasoning RAG имеют нейросимволическую архитектуру, в которой онтологии играют решающую роль.
Тезисы:
1. RAG-системы меняют подход к организации доступа к корпоративным знаниям — они комбинируют «умный» поиск на основе запросов на естественном языке с исследованием гетерогенных баз знаний.
2. СППР будут играть решающую роль в САПР, поскольку при проектировании мы постоянно принимаем решения, а возможности СППР (интеллектуальных помощников) продолжают расти.
Telegram
Intelligent Systems Architecture
Хочу поделиться разработанной мною архитектурой Graph RAG.
Эта архитектура обладает двумя ключевыми особенностями: во-первых, наличием этапа интеллектуального планирования запроса (R), управляемого онтологией, и, во-вторых, использованием той же онтологии…
Эта архитектура обладает двумя ключевыми особенностями: во-первых, наличием этапа интеллектуального планирования запроса (R), управляемого онтологией, и, во-вторых, использованием той же онтологии…
👍5🔥3👏1🤝1
Всем привет!
Нашу статью выложили в researchgate: https://www.researchgate.net/publication/398872240_The_Use_of_LLM_in_Selecting_the_Architectural_Patterns_for_Safety_Critical_Automotive_Systems
Это предпоследний пост в этом году. Последний — контентный, дальше будет только поздравление.
Нашу статью выложили в researchgate: https://www.researchgate.net/publication/398872240_The_Use_of_LLM_in_Selecting_the_Architectural_Patterns_for_Safety_Critical_Automotive_Systems
Это предпоследний пост в этом году. Последний — контентный, дальше будет только поздравление.
ResearchGate
The Use of LLM in Selecting the Architectural Patterns for Safety Critical Automotive Systems | Request PDF
Request PDF | On Dec 19, 2025, Maxim Tikhomirov and others published The Use of LLM in Selecting the Architectural Patterns for Safety Critical Automotive Systems | Find, read and cite all the research you need on ResearchGate
1👍9🔥5⚡2
Дорогие друзья, уважаемые подписчики!
Поздравляю вас с наступающим Новым годом!
Для меня этот год был особенным: плодотворным в работе и науке, полным вызовов и ценных уроков.
Одним из важных событий для меня стала маленькая победа — преодоление рубежа в 1000 подписчиков!
Спасибо за доверие и интерес к информации, которой я с вами делюсь.
В наступающем году я желаю вам, прежде всего, крепкого здоровья — чтобы сил и энергии хватало на все планы. И пусть наступающий 2026-й год будет отмечен новыми победами — в профессии, в исследованиях и в любых начинаниях!
Впереди — много интересного. Мы заложили крепкий фундамент! С праздником!
Поздравляю вас с наступающим Новым годом!
Для меня этот год был особенным: плодотворным в работе и науке, полным вызовов и ценных уроков.
Одним из важных событий для меня стала маленькая победа — преодоление рубежа в 1000 подписчиков!
Спасибо за доверие и интерес к информации, которой я с вами делюсь.
В наступающем году я желаю вам, прежде всего, крепкого здоровья — чтобы сил и энергии хватало на все планы. И пусть наступающий 2026-й год будет отмечен новыми победами — в профессии, в исследованиях и в любых начинаниях!
Впереди — много интересного. Мы заложили крепкий фундамент! С праздником!
❤18🎄2⚡1🥰1😍1
Cursor_ai_engineering_guideline.pdf
79.6 KB
Практика довольно быстро показала: базовые инженерные принципы — контракты, инварианты, разделение ответственности — продолжают работать и в мире AI-ассистированного программирования. Более того, без них взаимодействие с LLM через агентов становится плохо управляемым.
Я набросал небольшой гайд — «Cursor AI — Engineering Standard & Governance Guide», который помогает перевести работу с AI из стохастического ремесла в воспроизводимый инженерный процесс.
Работа в этом направлении будет продолжаться. А пока — пользуйтесь, если посчитаете полезным.
Я набросал небольшой гайд — «Cursor AI — Engineering Standard & Governance Guide», который помогает перевести работу с AI из стохастического ремесла в воспроизводимый инженерный процесс.
Работа в этом направлении будет продолжаться. А пока — пользуйтесь, если посчитаете полезным.
⚡7🔥3👍2🤔1
Точка бифуркации: «агенты» не справляются — часть 1/3
Индустрия разработки с использованием ИИ приближается к развилке.
Хайп вокруг «автономных агентов» находится на пике, однако реальные проблемы уже невозможно игнорировать.
Из моего опыта: современные LLM (даже на ~30B параметров) способны хорошо генерировать код.
Главный вызов текущей агентной разработки — неконтролируемые изменения, сложности управления контекстом и чрезмерно многословные обновления.
В результате почти неизбежно происходит потеря контроля над проектом.
И дело не в моделях.
Дело в архитектуре взаимодействия с ними.
Я наблюдаю формирование двух школ мысли, которые в ближайшее время окончательно разойдутся:
• Vibe Coding — интуитивная разработка через чат, когда требования сложно сформулировать, не до конца понятно, что именно нужно сделать, или просто лень формализовывать.
• Spec-Based Engineering — детерминированная разработка на основе спецификаций.
Заглянем в будущее и сравним оба подхода.
Индустрия разработки с использованием ИИ приближается к развилке.
Хайп вокруг «автономных агентов» находится на пике, однако реальные проблемы уже невозможно игнорировать.
Из моего опыта: современные LLM (даже на ~30B параметров) способны хорошо генерировать код.
Главный вызов текущей агентной разработки — неконтролируемые изменения, сложности управления контекстом и чрезмерно многословные обновления.
В результате почти неизбежно происходит потеря контроля над проектом.
И дело не в моделях.
Дело в архитектуре взаимодействия с ними.
Я наблюдаю формирование двух школ мысли, которые в ближайшее время окончательно разойдутся:
• Vibe Coding — интуитивная разработка через чат, когда требования сложно сформулировать, не до конца понятно, что именно нужно сделать, или просто лень формализовывать.
• Spec-Based Engineering — детерминированная разработка на основе спецификаций.
Заглянем в будущее и сравним оба подхода.
❤3👍2
Вайбкодинг против инженерии: метафора 3D-принтера — часть 2/3
Давайте сравним эти два подхода.
1. Школа «Vibe Coding» (Вайбкодинг)
Это то, что нам активно продают сейчас: бесконечные контексты и идея «поговори с кодом».
Суть: разработка на основе нечеткого интента. «Сделай красиво», «поправь тут», «перепиши в другом стиле».
Результат: отлично подходит для прототипирования «на выброс». Но на длинной дистанции это путь к хаосу. Контекст размывается, энтропия растёт.
Аналогия: у вас есть 3D-принтер, и вы говорите ему: «Напечатай матрёшку». Он печатает. Потом вы говорите: «Сделай её повеселее». После сотни итераций матрёшка превращается во Франкенштейна, и никто не понимает, как вернуть её к нормальному виду.
2. Школа «Spec-Based Engineering» (инженерный подход)
Это направление, к которому неизбежно придут команды, создающие production-ready решения.
Суть: управляемая генерация на основе формализованных требований (спецификаций).
Результат: гарантированная воспроизводимость и трассируемость к требованиям.
Аналогия: вы не разговариваете с принтером. Вы загружаете в него STL-файл (спецификацию) конкретной матрёшки. Результат всегда одинаковый. Хотите изменить изделие? Вы правите не пластик (код), а чертёж (спецификацию).
Давайте сравним эти два подхода.
1. Школа «Vibe Coding» (Вайбкодинг)
Это то, что нам активно продают сейчас: бесконечные контексты и идея «поговори с кодом».
Суть: разработка на основе нечеткого интента. «Сделай красиво», «поправь тут», «перепиши в другом стиле».
Результат: отлично подходит для прототипирования «на выброс». Но на длинной дистанции это путь к хаосу. Контекст размывается, энтропия растёт.
Аналогия: у вас есть 3D-принтер, и вы говорите ему: «Напечатай матрёшку». Он печатает. Потом вы говорите: «Сделай её повеселее». После сотни итераций матрёшка превращается во Франкенштейна, и никто не понимает, как вернуть её к нормальному виду.
2. Школа «Spec-Based Engineering» (инженерный подход)
Это направление, к которому неизбежно придут команды, создающие production-ready решения.
Суть: управляемая генерация на основе формализованных требований (спецификаций).
Результат: гарантированная воспроизводимость и трассируемость к требованиям.
Аналогия: вы не разговариваете с принтером. Вы загружаете в него STL-файл (спецификацию) конкретной матрёшки. Результат всегда одинаковый. Хотите изменить изделие? Вы правите не пластик (код), а чертёж (спецификацию).
❤6👍4
Software 3.0: LLM как компилятор — часть 3/3
Как реализовать инженерный подход на практике?
Нужно перестать относиться к LLM как к «собеседнику».
В парадигме Software 3.0 нейросеть — это компилятор.
Мы пишем спецификации — это наш новый исходный код.
А LLM, зажатая в строгий пайплайн (TDD, машины состояний), компилирует эти спецификации в рабочий софт.
Если нам нужен надёжный результат, а не «генеративное искусство», пора переходить от промптов к инженерии спецификаций.
Это и есть Software 3.0 в моём понимании:
когда код генерируется машиной, но управляется формальной логикой спецификаций.
Как реализовать инженерный подход на практике?
Нужно перестать относиться к LLM как к «собеседнику».
В парадигме Software 3.0 нейросеть — это компилятор.
Мы пишем спецификации — это наш новый исходный код.
А LLM, зажатая в строгий пайплайн (TDD, машины состояний), компилирует эти спецификации в рабочий софт.
Если нам нужен надёжный результат, а не «генеративное искусство», пора переходить от промптов к инженерии спецификаций.
Это и есть Software 3.0 в моём понимании:
когда код генерируется машиной, но управляется формальной логикой спецификаций.
👍23❤1🤝1
Forwarded from Блог Сергея Баранова (Сергей Баранов)
Темпоральность в Event Storming
Вчера обсуждали с Геной Кругловым темпоральность в Event Storning, а сегодня выступал перед участниками IN HUB с темой «Картина производственной системы за часы» (домен промышленного производства и смежных отраслей) и был у меня в презентации такой слайд и вчерашнее обсуждение и сегодняшнее выступление привели к новым мыслям.
Так вот, на этом слайде сразу четыре темпоральности (авторская интерпретация и она может измениться):
▪️Хаос (Chaotic Exploration)
Здесь только темпоральность события как высказывания с точки зрения семантики (по модели Рейхенбаха). События концептуально относены ко времени.
▪️Хронология (timeline enforcement)
Это интерсубъективно разделяемая хронология. Ключевой смысл в том, что здесь появляется темпоральность модели как структуры. В самой структуре появляется отношение порядка. Однако, пока только порядка (раньше/позже) и это важно.
▪️Контекст (обогащение модели, в первую очередь через Policy в рассматриваемом контекст)
В хронологии появляется своего рода реактивная темпоральность. На самом деле это кусочки реактивной темпоральности. Политики позволяют отличить автоматизированную реактивность от человеческой и вводят критерий верификации модели: Почему эта команда выполняется? При каких условиях? Всегда ли? Отсутствие явных политик делает причинно-следственные связи неявными и модель теряет способность отвечать на вопросы «Почему?» и «В каком случае/когда?»
▪️История (Narrative / Reverse Narrative
А здесь самое интересное. Это нарративная темпоральность (Paul Ricoeur, Джером Брунер), история, общий нарратив, обеспечивает переход от «позже - не значит вследствие» к «это вследствие вот этого». Это усиление темпоральности модели причинно-следственными связями.
А теперь прикладной вывод: если мы можем построить согласованную историю, построенную полностью на основе реактивной автоматизированной темпоральности (между каждым событием и командой поставить Policy), то мы можем с большей степенью уверенности говорить, что описанный процесс может быть реализован с помощью автономного ИИ-агента или мультиагентной системы.
Однако на текущий момент требуется больше наработок, потому что:
▪️Не факт, что агенты способны интерпретировать все типы Policy
▪️Человеческий контекст и неформализуемые аспекты могут оказать существенное влияние
▪️Техническая реализуемость не следует прямо из концептуальной полноты модели
Вчера обсуждали с Геной Кругловым темпоральность в Event Storning, а сегодня выступал перед участниками IN HUB с темой «Картина производственной системы за часы» (домен промышленного производства и смежных отраслей) и был у меня в презентации такой слайд и вчерашнее обсуждение и сегодняшнее выступление привели к новым мыслям.
Так вот, на этом слайде сразу четыре темпоральности (авторская интерпретация и она может измениться):
▪️Хаос (Chaotic Exploration)
Здесь только темпоральность события как высказывания с точки зрения семантики (по модели Рейхенбаха). События концептуально относены ко времени.
▪️Хронология (timeline enforcement)
Это интерсубъективно разделяемая хронология. Ключевой смысл в том, что здесь появляется темпоральность модели как структуры. В самой структуре появляется отношение порядка. Однако, пока только порядка (раньше/позже) и это важно.
▪️Контекст (обогащение модели, в первую очередь через Policy в рассматриваемом контекст)
В хронологии появляется своего рода реактивная темпоральность. На самом деле это кусочки реактивной темпоральности. Политики позволяют отличить автоматизированную реактивность от человеческой и вводят критерий верификации модели: Почему эта команда выполняется? При каких условиях? Всегда ли? Отсутствие явных политик делает причинно-следственные связи неявными и модель теряет способность отвечать на вопросы «Почему?» и «В каком случае/когда?»
▪️История (Narrative / Reverse Narrative
А здесь самое интересное. Это нарративная темпоральность (Paul Ricoeur, Джером Брунер), история, общий нарратив, обеспечивает переход от «позже - не значит вследствие» к «это вследствие вот этого». Это усиление темпоральности модели причинно-следственными связями.
А теперь прикладной вывод: если мы можем построить согласованную историю, построенную полностью на основе реактивной автоматизированной темпоральности (между каждым событием и командой поставить Policy), то мы можем с большей степенью уверенности говорить, что описанный процесс может быть реализован с помощью автономного ИИ-агента или мультиагентной системы.
Однако на текущий момент требуется больше наработок, потому что:
▪️Не факт, что агенты способны интерпретировать все типы Policy
▪️Человеческий контекст и неформализуемые аспекты могут оказать существенное влияние
▪️Техническая реализуемость не следует прямо из концептуальной полноты модели
🔥3❤1