Телеграм канал «Клуб CDO»

Собрал тут по заметкам основные законы и принципы software engineering, будем осваивать по одному :)

🎹 Инструмент — временная переменная: Брюс Стерлинг о главной ловушке AI-эпохи

Американский фантаст и основатель киберпанка Брюс Стерлинг выступил в Риме с лекцией, в которой сравнил происходящее с AI с историей технологических революций в музыке. Не с конкретным изобретением, а с самим паттерном.

Каждый раз, когда появлялась новая технология — запись звука, механическое пианино, телевидение, — она не уничтожала музыку. Она перемалывала предыдущий уклад в сырье для нового.

🎙️ Живое исполнение не исчезло, но изменилось навсегда

Когда появились восковые цилиндры, которые впервые позволили записывать звук, живое исполнение не исчезло. Но то, чем оно было — ритуал, физическое присутствие, совместное переживание, — изменилось необратимо.

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

🎹 Притча об эоломелодиконе

Стерлинг приводит пример Шопена. Когда молодому музыканту предложили продемонстрировать публике странный клавишный аппарат — «эоломелодикон», — он не испугался, а отыграл концерт и получил гонорар.

Писатель считает, что целью Шопена было не отвержение или принятие машины. Его целью было мастерство, которое он демонстрировал всегда. Независимо от того, играл он на обычном фортепиано или на странном новом инструменте.

Эоломелодикон через пару лет забыли навсегда. Шопена играют до сих пор.

🏢 Как это относится к AI

Этот паттерн стоит рассмотреть применительно к тому, что сейчас происходит с AI в корпоративном контексте.

Значительная часть дискуссии сосредоточена на инструментах:
❓какую модель внедрить
❓какой процесс автоматизировать
❓какого вендора выбрать

Но история технологических сдвигов учит простой вещи:
инструмент — это временная переменная.
Эоломелодикон корпоративных AI-платформ 2024–2025 годов будет забыт так же быстро, как и оригинал.

🔄 А что тогда не будет забыто?

Изменение самой среды. Многое из того, что привычно — процессы, роли, инфраструктуры, — будет перемолото. Не уничтожено, а именно переработано в основу для следующего слоя. Как живое исполнение не умерло с появлением записи, но стало чем-то принципиально другим.

💡 Практический вывод для технологических команд

❌ Фокус на конкретном AI-инструменте — это ставка на эоломелодикон.

✔️ Фокус на перестройке мышления, процессов и архитектуры принятия решений — это ставка на мастерство, которое переживет любую смену платформ.

#радар_трендов
Подписывайтесь на AI Inside в Max | ВКонтакте

Небольшой воскресный оффтоп: OpenAI выкатили три голосовых модели в Realtime API (reasoning, транскрипция и синхронный перевод).

Последняя меня зацепила больше всего. GPT-Realtime-Translate обучали на тысячах часов аудио профессиональных синхронных переводчиков, именно поэтому модель не отвечает на вопросы и не выполняет инструкции, а только переводит.

Слушает и понимает 70+ языков, отвечает на 13, русский в том числе. Попробовать можно тут.

В демке двое говорят на французском и немецком, модель переводит обоих на английский в реальном времени.

Anthropic пугает дизайнеров и разработчиков, а OpenAI синхронных переводчиков 😄

@ai_for_devs

Дайджест статей

📰 BI-движок на остатках Cursor токенов за месяц
🔗 https://habr.com/ru/articles/1030948/
💬 Автор за выходные на остатках месячного лимита Cursor собрал кроссплатформенный аналог VertiPaq — DAX-движок на C# с TDD-сверкой против Power BI, плюс выполнение DAX внутри Markdown-отчётов вместо классических дашбордов.
💡 Вывод: стоимость воспроизведения нетривиальной BI-инфраструктуры на ИИ-кодинге упала до уровня «потратить остатки подписки за выходные» — это меняет переговорную позицию команд по отношению к вендорам и означает, что внутренние реализации узких BI-задач становятся реалистичной альтернативой лицензиям, а не теорией.

📰 Лаборатория решений DataLens: как российский BI помогает бизнесу принимать решения (по метаданным)
🔗 https://habr.com/ru/articles/1031892/
💬 Обзор конференции DataLens с точки зрения практика из фармы: эволюция корпоративной аналитики от Excel к платформенному BI на российском стеке.
💡 Вывод: российский рынок BI после ухода Power BI и Tableau консолидируется вокруг DataLens — для CDO в РФ это де-факто базовая ставка, а не одна из опций; имеет смысл оценивать кадровый и интеграционный долг при выборе альтернатив.

📰 Как мы автоматизировали аналитику маркетплейсов в Yandex DataLens
🔗 https://habr.com/ru/articles/1031902/
💬 Классический разбор перехода от «бизнес-логика в Google Sheets» к слоистой архитектуре: Python-загрузчики API WB/Ozon → BigQuery как сырой слой → SQL views как слой бизнес-логики → DataLens только как интерфейс, плюс Telegram-бот для мониторинга джобов.
💡 Вывод: главный сдвиг — вытащить бизнес-логику из таблиц и зафиксировать её в SQL-views поверх сырого слоя; это превращает аналитику из ручного ремесла в управляемый конвейер и снимает потолок масштабирования, упирающийся в количество людей, поддерживающих формулы.

📰 LinkedIn Consolidates Hiring Data Pipelines to Power AI-Driven Talent Systems
🔗 https://www.infoq.com/news/2026/05/linkedin-unified-hiring-platform/
💬 LinkedIn запустил унифицированную интеграционную платформу, стандартизирующую и сверяющую данные о найме между системами; заявлено сокращение времени онбординга на 72%, улучшение консистентности и полноты данных.
💡 Вывод: универсальный паттерн «фрагментированные источники → единая интеграционная платформа» воспроизводится во всех крупных AI-инициативах — без слоя, нормализующего данные, ИИ-агенты строятся на песке; это аргумент в пользу того, что master data management и data contracts становятся обязательной инфраструктурой для AI, а не «гигиеной для зрелых компаний».

📰 The Data Warehouse Concurrency Playbook
🔗 https://dzone.com/articles/dw-concurrency-playbook
💬 Сценарий «Super Bowl moment» для хранилища: что делать, когда одновременная нагрузка пробивает архитектурные допущения и DWH захлёбывается.
💡 Вывод: предсказуемая граница масштабирования у современных DWH — не объём данных, а конкурентность запросов; имеет смысл проектировать рабочие нагрузки с учётом worst-case concurrency (отдельные warehouses под BI, ETL и ad-hoc), а не средней нагрузки, иначе самый дорогой инцидент — это успешный маркетинг.

📰 RAG Done Right: When to Use SQL, Search, and Vector Retrieval
🔗 https://dzone.com/articles/rag-sql-search-vector
💬 Разбор того, когда использовать SQL, полнотекстовый поиск и векторный retrieval в RAG-пайплайнах и как их комбинировать.
💡 Вывод: «vector-only RAG» — это уже устаревший дефолт; зрелый RAG — это маршрутизация запроса по типу: структурные факты → SQL, точные термины → keyword search, семантика → vector; кто продолжает строить «всё через embeddings», платит за это точностью и стоимостью инференса.

📰 Как устроена ML-платформа Michelangelo и какие базовые принципы из неё важно усвоить
🔗 https://habr.com/ru/companies/yandex_praktikum/articles/1031378/
💬 Подробный разбор архитектуры Michelangelo от Uber — от ранней схемы 2015 года до зрелой версии с control plane (Pipeline/PipelineRun, Model, InferenceServer, Deployment), feature store (Hive + Cassandra → Palette), Horovod для distributed training и эволюции в сторону LLMOps; с проекцией на российские реалии.

💡 Вывод: ключевой урок не в том, чтобы повторять Uber, а в трёх вещах, которые повторяются у всех зрелых ML-платформ: (1) единый слой признаков с явными определениями и владельцами, иначе train/serve skew гарантирован; (2) деплой как описываемый процесс с версионированием и проверками, а не ручная передача файла между командами; (3) наблюдаемость встроенная в платформу на уровне данных, признаков, предсказаний и бизнес-эффекта — отдельно эти куски в крупной компании никогда не сходятся.

Пост с артефактами в комментариях 🙂

Поведение системы определяется её структурой, а не отдельными событиями. Хочешь другой результат — меняй структуру, а не пинай выходы.

Это ядро «Thinking in Systems» Донеллы Медоуз. Перечитал её на днях — за годы только обострилось.

Звучит банально ровно до того момента, пока не начинаешь честно считать, на что уходит время. План квартала не сходится — давим на сейлз. Команда выгорает — устраиваем тимбилдинг. Продукт буксует — добавляем фичи. Структуру никто не трогает, потому что её не видно. Видно только события.

В этот раз я решил не ограничиваться чтением. Сделал из книги рабочий инструмент:

• Claude собрал саммари ключевых идей в HTML
• ChatGPT нарисовал инфографику
• Claude написал промпт-фреймворк для разбора любой системы по Медоуз: её циклы, петли обратной связи, точки рычага

Положил этот промпт в своего персонального ассистента как skill и прогнал через него пару своих проектов. Получил пищи для размышления на неделю вперёд: несколько мест, где я годами пинал выходы, оказались прямым следствием структуры, которую я сам же и собрал.

Сам учебник пересказывать смысла нет — это нужно читать. А вот артефакты, которые помогут применить идеи Медоуз к вашей системе, — все три в комментариях.

Забирайте 🙂