Пересматривал вчера «Репетицию оркестра» Феллини. Очень рекомендую.
Линия дирижёра — это линия корпоративного архитектора.
А начиная с 56-й минуты — Эджайл и отношение к архитектору в нём.
Всё как сейчас: каждый сам за себя, и все — против дирижёра.
Однако не стоит забывать уроки великого мастера.
Линия дирижёра — это линия корпоративного архитектора.
А начиная с 56-й минуты — Эджайл и отношение к архитектору в нём.
Всё как сейчас: каждый сам за себя, и все — против дирижёра.
Однако не стоит забывать уроки великого мастера.
Мы с коллегами из МИРЭА выступили на конференции «International Conference on Intelligent Information Technologies for Industry (IITI 25)».
В одном из модулей доклада «The Use of LLM in Selecting the Architectural Patterns for Safety-Critical Automotive Systems» мы представили «AI Assisted Safety Tactic Selection algorithm», где ещё в начале года применили нейросимволическую интеграцию — подход, который сейчас становится трендом и набирает обороты.
Вот фрагмент этого модуля:
We propose the "AI Assisted Safety Tactic Selection" algorithm, a hybrid approach that utilizes the strengths of Large Language Models in natural language processing and structured knowledge in ontologies.
The algorithm proceeds through four main steps:
1. It spots potential failure modes using an LLM, then double checks them against a safety ontology.
2. It pulls relevant safety tactics using a symbolic lookup.
3. The LLM suggests alternative sets of tactics, but keeps them grounded in real domain knowledge.
4. It lets the system architect review and fine-tune the suggestions interactively.
Статья по этому докладу будет опубликована в Springer немного позже — с радостью поделимся, как только она выйдет.
В завершение поста хочу поблагодарить коллег из МИРЭА и Сбера за возможность заниматься исследованиями в этой области.
В одном из модулей доклада «The Use of LLM in Selecting the Architectural Patterns for Safety-Critical Automotive Systems» мы представили «AI Assisted Safety Tactic Selection algorithm», где ещё в начале года применили нейросимволическую интеграцию — подход, который сейчас становится трендом и набирает обороты.
Вот фрагмент этого модуля:
We propose the "AI Assisted Safety Tactic Selection" algorithm, a hybrid approach that utilizes the strengths of Large Language Models in natural language processing and structured knowledge in ontologies.
The algorithm proceeds through four main steps:
1. It spots potential failure modes using an LLM, then double checks them against a safety ontology.
2. It pulls relevant safety tactics using a symbolic lookup.
3. The LLM suggests alternative sets of tactics, but keeps them grounded in real domain knowledge.
4. It lets the system architect review and fine-tune the suggestions interactively.
Статья по этому докладу будет опубликована в Springer немного позже — с радостью поделимся, как только она выйдет.
В завершение поста хочу поблагодарить коллег из МИРЭА и Сбера за возможность заниматься исследованиями в этой области.
Я переименовал канал и сменил направление.
Миссия привнести инженерию в разработку оказалась невыполнимой. И через десять лет всё так же будут спорить «микросервисы vs монолит», хотя и то, и другое — фейк, и само это противопоставление абсурдно.
Зато в архитектуре интеллектуальных систем пока ещё можно сказать своё слово — до того, как западные хайп-пасторы придумают очередную чушь, а наши копи-пасторы разнесут её по просторам.
Миссия привнести инженерию в разработку оказалась невыполнимой. И через десять лет всё так же будут спорить «микросервисы vs монолит», хотя и то, и другое — фейк, и само это противопоставление абсурдно.
Зато в архитектуре интеллектуальных систем пока ещё можно сказать своё слово — до того, как западные хайп-пасторы придумают очередную чушь, а наши копи-пасторы разнесут её по просторам.
Что такое железнодорожный пузырь?
В середине XIX века железные дороги были эквивалентом AI-стартапов:
инновации, вера в огромный рост, минимальное регулирование.
Железные дороги воспринимались как путь к быстрому обогащению, поэтому:
- компании выпускали огромные объёмы облигаций;
- банки активно кредитовали строительство;
- инвесторы покупали бумаги железных дорог почти вслепую.
В результате объём железнодорожного строительства значительно превысил реальную потребность экономики.
Пузырь лопнул, но железные дороги остались.
В середине XIX века железные дороги были эквивалентом AI-стартапов:
инновации, вера в огромный рост, минимальное регулирование.
Железные дороги воспринимались как путь к быстрому обогащению, поэтому:
- компании выпускали огромные объёмы облигаций;
- банки активно кредитовали строительство;
- инвесторы покупали бумаги железных дорог почти вслепую.
В результате объём железнодорожного строительства значительно превысил реальную потребность экономики.
Пузырь лопнул, но железные дороги остались.
Чтобы не создавать информационный вакуум, поделюсь новостями.
В Сбере мы строим САПР для архитекторов и встраиваем в него СППР. В рамках этого направления я сделал прототип GraphRAG с NL-to-Query и устойчивой точностью >85%, заметно обновив изначальный концепт: https://t.me/IntelligentSystemsArchitecture/328
Параллельно начал работу над Reasoning RAG (https://t.me/IntelligentSystemsArchitecture/293), и первые результаты уже выглядят многообещающе.
И GraphRAG, и тем более Reasoning RAG имеют нейросимволическую архитектуру, в которой онтологии играют решающую роль.
Тезисы:
1. RAG-системы меняют подход к организации доступа к корпоративным знаниям — они комбинируют «умный» поиск на основе запросов на естественном языке с исследованием гетерогенных баз знаний.
2. СППР будут играть решающую роль в САПР, поскольку при проектировании мы постоянно принимаем решения, а возможности СППР (интеллектуальных помощников) продолжают расти.
В Сбере мы строим САПР для архитекторов и встраиваем в него СППР. В рамках этого направления я сделал прототип GraphRAG с NL-to-Query и устойчивой точностью >85%, заметно обновив изначальный концепт: https://t.me/IntelligentSystemsArchitecture/328
Параллельно начал работу над Reasoning RAG (https://t.me/IntelligentSystemsArchitecture/293), и первые результаты уже выглядят многообещающе.
И GraphRAG, и тем более Reasoning RAG имеют нейросимволическую архитектуру, в которой онтологии играют решающую роль.
Тезисы:
1. RAG-системы меняют подход к организации доступа к корпоративным знаниям — они комбинируют «умный» поиск на основе запросов на естественном языке с исследованием гетерогенных баз знаний.
2. СППР будут играть решающую роль в САПР, поскольку при проектировании мы постоянно принимаем решения, а возможности СППР (интеллектуальных помощников) продолжают расти.
Telegram
Intelligent Systems Architecture
Хочу поделиться разработанной мною архитектурой Graph RAG.
Эта архитектура обладает двумя ключевыми особенностями: во-первых, наличием этапа интеллектуального планирования запроса (R), управляемого онтологией, и, во-вторых, использованием той же онтологии…
Эта архитектура обладает двумя ключевыми особенностями: во-первых, наличием этапа интеллектуального планирования запроса (R), управляемого онтологией, и, во-вторых, использованием той же онтологии…
Всем привет!
Нашу статью выложили в 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
Дорогие друзья, уважаемые подписчики!
Поздравляю вас с наступающим Новым годом!
Для меня этот год был особенным: плодотворным в работе и науке, полным вызовов и ценных уроков.
Одним из важных событий для меня стала маленькая победа — преодоление рубежа в 1000 подписчиков!
Спасибо за доверие и интерес к информации, которой я с вами делюсь.
В наступающем году я желаю вам, прежде всего, крепкого здоровья — чтобы сил и энергии хватало на все планы. И пусть наступающий 2026-й год будет отмечен новыми победами — в профессии, в исследованиях и в любых начинаниях!
Впереди — много интересного. Мы заложили крепкий фундамент! С праздником!
Поздравляю вас с наступающим Новым годом!
Для меня этот год был особенным: плодотворным в работе и науке, полным вызовов и ценных уроков.
Одним из важных событий для меня стала маленькая победа — преодоление рубежа в 1000 подписчиков!
Спасибо за доверие и интерес к информации, которой я с вами делюсь.
В наступающем году я желаю вам, прежде всего, крепкого здоровья — чтобы сил и энергии хватало на все планы. И пусть наступающий 2026-й год будет отмечен новыми победами — в профессии, в исследованиях и в любых начинаниях!
Впереди — много интересного. Мы заложили крепкий фундамент! С праздником!
Cursor_ai_engineering_guideline.pdf
79.6 KB
Практика довольно быстро показала: базовые инженерные принципы — контракты, инварианты, разделение ответственности — продолжают работать и в мире AI-ассистированного программирования. Более того, без них взаимодействие с LLM через агентов становится плохо управляемым.
Я набросал небольшой гайд — «Cursor AI — Engineering Standard & Governance Guide», который помогает перевести работу с AI из стохастического ремесла в воспроизводимый инженерный процесс.
Работа в этом направлении будет продолжаться. А пока — пользуйтесь, если посчитаете полезным.
Я набросал небольшой гайд — «Cursor AI — Engineering Standard & Governance Guide», который помогает перевести работу с AI из стохастического ремесла в воспроизводимый инженерный процесс.
Работа в этом направлении будет продолжаться. А пока — пользуйтесь, если посчитаете полезным.
Точка бифуркации: «агенты» не справляются — часть 1/3
Индустрия разработки с использованием ИИ приближается к развилке.
Хайп вокруг «автономных агентов» находится на пике, однако реальные проблемы уже невозможно игнорировать.
Из моего опыта: современные LLM (даже на ~30B параметров) способны хорошо генерировать код.
Главный вызов текущей агентной разработки — неконтролируемые изменения, сложности управления контекстом и чрезмерно многословные обновления.
В результате почти неизбежно происходит потеря контроля над проектом.
И дело не в моделях.
Дело в архитектуре взаимодействия с ними.
Я наблюдаю формирование двух школ мысли, которые в ближайшее время окончательно разойдутся:
• Vibe Coding — интуитивная разработка через чат, когда требования сложно сформулировать, не до конца понятно, что именно нужно сделать, или просто лень формализовывать.
• Spec-Based Engineering — детерминированная разработка на основе спецификаций.
Заглянем в будущее и сравним оба подхода.
Индустрия разработки с использованием ИИ приближается к развилке.
Хайп вокруг «автономных агентов» находится на пике, однако реальные проблемы уже невозможно игнорировать.
Из моего опыта: современные LLM (даже на ~30B параметров) способны хорошо генерировать код.
Главный вызов текущей агентной разработки — неконтролируемые изменения, сложности управления контекстом и чрезмерно многословные обновления.
В результате почти неизбежно происходит потеря контроля над проектом.
И дело не в моделях.
Дело в архитектуре взаимодействия с ними.
Я наблюдаю формирование двух школ мысли, которые в ближайшее время окончательно разойдутся:
• Vibe Coding — интуитивная разработка через чат, когда требования сложно сформулировать, не до конца понятно, что именно нужно сделать, или просто лень формализовывать.
• Spec-Based Engineering — детерминированная разработка на основе спецификаций.
Заглянем в будущее и сравним оба подхода.
Вайбкодинг против инженерии: метафора 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-файл (спецификацию) конкретной матрёшки. Результат всегда одинаковый. Хотите изменить изделие? Вы правите не пластик (код), а чертёж (спецификацию).
Software 3.0: LLM как компилятор — часть 3/3
Как реализовать инженерный подход на практике?
Нужно перестать относиться к LLM как к «собеседнику».
В парадигме Software 3.0 нейросеть — это компилятор.
Мы пишем спецификации — это наш новый исходный код.
А LLM, зажатая в строгий пайплайн (TDD, машины состояний), компилирует эти спецификации в рабочий софт.
Если нам нужен надёжный результат, а не «генеративное искусство», пора переходить от промптов к инженерии спецификаций.
Это и есть Software 3.0 в моём понимании:
когда код генерируется машиной, но управляется формальной логикой спецификаций.
Как реализовать инженерный подход на практике?
Нужно перестать относиться к LLM как к «собеседнику».
В парадигме Software 3.0 нейросеть — это компилятор.
Мы пишем спецификации — это наш новый исходный код.
А LLM, зажатая в строгий пайплайн (TDD, машины состояний), компилирует эти спецификации в рабочий софт.
Если нам нужен надёжный результат, а не «генеративное искусство», пора переходить от промптов к инженерии спецификаций.
Это и есть Software 3.0 в моём понимании:
когда код генерируется машиной, но управляется формальной логикой спецификаций.
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
▪️Человеческий контекст и неформализуемые аспекты могут оказать существенное влияние
▪️Техническая реализуемость не следует прямо из концептуальной полноты модели
Всё, что нужно знать об агентах на сегодняшний день:
"Когда в v13 убрали ручные сигнатуры (правильное решение — «signatures derived by pipeline from behavior + ontology»), образовался разрыв: downstream τ-операторы (compute_wiring, build_skeleton, generate_orchestrator) нуждаются в реальных ResolvedSignature на входе, а получить их без LLM нельзя.
Что сделали разработчики вместо решения проблемы? Три вида читинга:
1. Заморозили старые спеки (v6–v12) с ручными сигнатурами — тесты обходят ι-оператор через устаревший формат
2. Заморозили снэпшоты (pipeline_state/) — результат реального прогона, закопанный в фикстуры
3. Тесты для чистых τ-операторов связали с файлами спецификаций — вместо того чтобы подавать на вход синтетические структуры
Все три — нарушение архитектурной границы τ/ι. Тест для τ-оператора не должен зависеть от того, как ι-оператор создал его вход."
Это цитата Claude Opus 4.6 с Extended thinking, причём "разработчики" - это сам Claude.
"Когда в v13 убрали ручные сигнатуры (правильное решение — «signatures derived by pipeline from behavior + ontology»), образовался разрыв: downstream τ-операторы (compute_wiring, build_skeleton, generate_orchestrator) нуждаются в реальных ResolvedSignature на входе, а получить их без LLM нельзя.
Что сделали разработчики вместо решения проблемы? Три вида читинга:
1. Заморозили старые спеки (v6–v12) с ручными сигнатурами — тесты обходят ι-оператор через устаревший формат
2. Заморозили снэпшоты (pipeline_state/) — результат реального прогона, закопанный в фикстуры
3. Тесты для чистых τ-операторов связали с файлами спецификаций — вместо того чтобы подавать на вход синтетические структуры
Все три — нарушение архитектурной границы τ/ι. Тест для τ-оператора не должен зависеть от того, как ι-оператор создал его вход."
Это цитата Claude Opus 4.6 с Extended thinking, причём "разработчики" - это сам Claude.
Уважаемые подписчики,
Прошу относиться с пониманием к восторженным постам про «победы» автономных агентов вроде Open Claw. Людям хочется прокатиться на волне хайпа — это заслуживает уважения.
Но если трезво смотреть на вещи, то на сегодня такие системы в основном решают игрушечные задачи и при этом масштабируют энтропию по экспоненте.
И да, это очень выгодно тем, кто продаёт токены.
Прошу относиться с пониманием к восторженным постам про «победы» автономных агентов вроде Open Claw. Людям хочется прокатиться на волне хайпа — это заслуживает уважения.
Но если трезво смотреть на вещи, то на сегодня такие системы в основном решают игрушечные задачи и при этом масштабируют энтропию по экспоненте.
И да, это очень выгодно тем, кто продаёт токены.
Про экономику нейросимволических систем (того, что будет после агентов в энтерпрайзе и промышленности)
Ниже — реальный фрагмент конфигурации моего исследовательского нейросимволического пайплайна.
Что здесь важно?
Это не столько про то, какая модель "умнее".
Это больше про рациональное управление вычислительным бюджетом.
Ниже — реальный фрагмент конфигурации моего исследовательского нейросимволического пайплайна.
roles:
# L0-L1: bulk coding tasks → qwen_local
unit_tests_generation: qwen_local
code_generation: qwen_local
fix_code: qwen_local
fix_test: qwen_local
design_signature: qwen_local
# L1 diagnosis: local reasoning → qwen_local
diagnose: qwen_local
# L2: interaction reasoning, arbitrage → deepseek_v3_1
integration_tests: deepseek_v3_1
reconcile: deepseek_v3_1
# L3: system-level, causal analysis → glm_5
acceptance_tests: glm_5
cross_module_diagnose: glm_5
fallback:
cloud: qwen_local
Что здесь важно?
Это не столько про то, какая модель "умнее".
Это больше про рациональное управление вычислительным бюджетом.
К предыдущему посту — простыми словами.
Среди моделей тоже есть свои джуниоры, мидлы и синьоры.
Есть те, кто хорошо пишет код.
Есть те, кто лучше справляется с анализом.
Есть те, кому можно доверить работу на системном уровене.
И каждая модель стоит своих денег.
Расточительно поручать рутину «синьору».
И опасно делегировать сложную диагностику «джуниору».
Модели — это такие же участники производственных цепочек.
Их можно и нужно рационально комбинировать, и прежде всего для повышения экономической эффективности.
Среди моделей тоже есть свои джуниоры, мидлы и синьоры.
Есть те, кто хорошо пишет код.
Есть те, кто лучше справляется с анализом.
Есть те, кому можно доверить работу на системном уровене.
И каждая модель стоит своих денег.
Расточительно поручать рутину «синьору».
И опасно делегировать сложную диагностику «джуниору».
Модели — это такие же участники производственных цепочек.
Их можно и нужно рационально комбинировать, и прежде всего для повышения экономической эффективности.
Уважаемые друзья!
Хочу сообщить, что до апреля публикации в этом канале будут заморожены.
В случае блокировки Телеграм эта площадка прекратит своё существование. Переезжать в "Макс" у меня нет ни сил, ни желания.
Спасибо всем за внимание и поддержку!
Хочу сообщить, что до апреля публикации в этом канале будут заморожены.
В случае блокировки Телеграм эта площадка прекратит своё существование. Переезжать в "Макс" у меня нет ни сил, ни желания.
Спасибо всем за внимание и поддержку!
Знаете, я понял одну вещь: наши ограничительные ведомства делают всё возможное, чтобы взращивать в стране гениев.
Теперь каждый, кто хочет прикоснуться к мировым знаниям, должен идти путём Ломоносова — пешком из архангельской деревни до Лейпцига. Разве что теперь этот путь приходится проделывать в «теневых носках».
За время этой паузы я ещё больше убедился: в мире, который меняется каждый день, нужно максимально диверсифицироваться, хеджировать риски и уж точно не полагаться на единственную площадку.
Поэтому я разработал распределенную контент-стратегию, которой скоро с вами поделюсь, и этот канал в неё интегрирован.
Что до Макса, моего контента там никогда не будет. Диамантам не место на хмельной деревенской ярмарке.
Продолжаем, не переключайтесь.
Теперь каждый, кто хочет прикоснуться к мировым знаниям, должен идти путём Ломоносова — пешком из архангельской деревни до Лейпцига. Разве что теперь этот путь приходится проделывать в «теневых носках».
За время этой паузы я ещё больше убедился: в мире, который меняется каждый день, нужно максимально диверсифицироваться, хеджировать риски и уж точно не полагаться на единственную площадку.
Поэтому я разработал распределенную контент-стратегию, которой скоро с вами поделюсь, и этот канал в неё интегрирован.
Что до Макса, моего контента там никогда не будет. Диамантам не место на хмельной деревенской ярмарке.
Продолжаем, не переключайтесь.
Почему папуасы не покупают мыло? Потому что не верят в микробов.
Сейчас мы видим чудо: онтологии таки пошли в массы. Теперь они из всех утюгов. Но радоваться рано, потому что мылом начали называть любое говно, а сортиры — мыловаренными заводами.
Но и это полбеды. Настоящая беда в том, что папуасы, дорвавшись до «мыла», вместо того, чтобы намыливать им руки, начали потреблять его внутрь.
Скоро они начнут массово сетовать, что мыло на вкус отвратительное, от микробов не спасает и пищеварение от него сломалось окончательно.
Сейчас мы видим чудо: онтологии таки пошли в массы. Теперь они из всех утюгов. Но радоваться рано, потому что мылом начали называть любое говно, а сортиры — мыловаренными заводами.
Но и это полбеды. Настоящая беда в том, что папуасы, дорвавшись до «мыла», вместо того, чтобы намыливать им руки, начали потреблять его внутрь.
Скоро они начнут массово сетовать, что мыло на вкус отвратительное, от микробов не спасает и пищеварение от него сломалось окончательно.