Книжный куб
الذهاب إلى القناة على Telegram
Рекомендации интересных книг, статей и выступлений от Александра Поломодова (@apolomodov), технического директора и эксперта в архитектуре (no ads in channel)
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام Книжный куб
تُعد قناة Книжный куб (@book_cube) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 14 586 مشتركاً، محتلاً المرتبة 2 549 في فئة الكتب والمرتبة 45 295 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 14 586 مشتركاً.
بحسب آخر البيانات بتاريخ 21 يوليو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 315، وفي آخر 24 ساعة بمقدار 17، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 16.21%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 10.16% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 2 363 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 481 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 17.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل engineering, native, devex, devops, leadership.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Рекомендации интересных книг, статей и выступлений от Александра Поломодова (@apolomodov), технического директора и эксперта в архитектуре (no ads in channel)”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 22 يوليو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة الكتب.
14 586
المشتركون
+1724 ساعات
+807 أيام
+31530 أيام
جاري تحميل البيانات...
القنوات المماثلة
سحابة العلامات
الإشارات الواردة والصادرة
---
---
---
---
---
---
جذب المشتركين
يوليو '26
يوليو '26
+254
في 4 قنوات
يونيو '26
+349
في 3 قنوات
Get PRO
مايو '26
+212
في 2 قنوات
Get PRO
أبريل '26
+2 210
في 6 قنوات
Get PRO
مارس '26
+542
في 5 قنوات
Get PRO
فبراير '26
+676
في 6 قنوات
Get PRO
يناير '26
+284
في 5 قنوات
Get PRO
ديسمبر '25
+198
في 4 قنوات
Get PRO
نوفمبر '25
+252
في 4 قنوات
Get PRO
أكتوبر '25
+249
في 5 قنوات
Get PRO
سبتمبر '25
+201
في 8 قنوات
Get PRO
أغسطس '25
+408
في 4 قنوات
Get PRO
يوليو '25
+355
في 8 قنوات
Get PRO
يونيو '25
+314
في 6 قنوات
Get PRO
مايو '25
+216
في 3 قنوات
Get PRO
أبريل '25
+199
في 7 قنوات
Get PRO
مارس '25
+419
في 5 قنوات
Get PRO
فبراير '25
+272
في 2 قنوات
Get PRO
يناير '25
+281
في 3 قنوات
Get PRO
ديسمبر '24
+368
في 6 قنوات
Get PRO
نوفمبر '24
+515
في 6 قنوات
Get PRO
أكتوبر '24
+607
في 4 قنوات
Get PRO
سبتمبر '24
+569
في 0 قنوات
Get PRO
أغسطس '24
+359
في 2 قنوات
Get PRO
يوليو '24
+320
في 1 قنوات
Get PRO
يونيو '24
+429
في 6 قنوات
Get PRO
مايو '24
+383
في 0 قنوات
Get PRO
أبريل '24
+449
في 1 قنوات
Get PRO
مارس '24
+360
في 2 قنوات
Get PRO
فبراير '24
+353
في 1 قنوات
Get PRO
يناير '24
+533
في 5 قنوات
Get PRO
ديسمبر '23
+561
في 3 قنوات
Get PRO
نوفمبر '23
+442
في 3 قنوات
Get PRO
أكتوبر '23
+406
في 3 قنوات
Get PRO
سبتمبر '23
+566
في 0 قنوات
Get PRO
أغسطس '23
+446
في 0 قنوات
Get PRO
يوليو '23
+333
في 0 قنوات
Get PRO
يونيو '23
+234
في 0 قنوات
Get PRO
مايو '23
+228
في 0 قنوات
Get PRO
أبريل '23
+214
في 0 قنوات
Get PRO
مارس '23
+224
في 0 قنوات
Get PRO
فبراير '23
+173
في 0 قنوات
Get PRO
يناير '23
+227
في 0 قنوات
Get PRO
ديسمبر '22
+142
في 0 قنوات
Get PRO
نوفمبر '22
+242
في 0 قنوات
Get PRO
أكتوبر '22
+181
في 0 قنوات
Get PRO
سبتمبر '22
+126
في 0 قنوات
Get PRO
أغسطس '22
+62
في 0 قنوات
Get PRO
يوليو '22
+82
في 0 قنوات
Get PRO
يونيو '22
+176
في 0 قنوات
Get PRO
مايو '22
+64
في 0 قنوات
Get PRO
أبريل '22
+36
في 0 قنوات
Get PRO
مارس '22
+275
في 0 قنوات
| التاريخ | نمو المشتركين | الإشارات | القنوات | |
| 22 يوليو | +9 | |||
| 21 يوليو | +25 | |||
| 20 يوليو | +12 | |||
| 19 يوليو | +8 | |||
| 18 يوليو | +23 | |||
| 17 يوليو | +22 | |||
| 16 يوليو | +18 | |||
| 15 يوليو | +15 | |||
| 14 يوليو | +13 | |||
| 13 يوليو | +9 | |||
| 12 يوليو | +10 | |||
| 11 يوليو | +3 | |||
| 10 يوليو | +4 | |||
| 09 يوليو | +6 | |||
| 08 يوليو | +9 | |||
| 07 يوليو | +9 | |||
| 06 يوليو | +8 | |||
| 05 يوليو | +7 | |||
| 04 يوليو | +8 | |||
| 03 يوليو | +13 | |||
| 02 يوليو | +6 | |||
| 01 يوليو | +17 |
منشورات القناة
+1
Люблю встречаться с интересными людьми на встречах CxO Community. Такие коммьюнити есть у разных компаний, но у Сбера это часто связано не только с нетворкингом, но и с интересным опытос. В прошлый раз событие было вокруг дегустации вин, а в этот раз мы слушаем Оскара Конюхова, руководителя штаба его отца, Федора Конюхова. Рассказ идет про планирование и реализацию сложных проектов на грани технических и человеческих возможностей.
Спасибо организаторам Sber CxO TechCommunity, это реально интересные мероприятия.
| 2 | Research Insights Made Simple #23 - Экономика AI в разработке (Рубрика #AI4SDLC)
Голосование показало, что тема интересна и поэтому завтра в 17:00 в прямом эфире разберём экономику AI в разработке. Суть в том, что токены дешевеют, модели становятся быстрее, но AI-бюджет компании от этого не обязательно уменьшается. Чем больше появляется рабочих сценариев, тем больше становится задач, агентных цепочек, инфраструктуры, проверок и цены ошибок.
Поговорим о том:
- Почему удешевление фиксированного уровня качества расширяет спрос и способно увеличить общий бюджет;
- Как агентная задача превращается в длинный trace с десятками вызовов, повторами и растущим контекстом — и почему ограничения нужны на весь workflow;
- Как считать cost per accepted task, включая инструменты, инфраструктуру, человеческую проверку, переделки и цену ошибки;
- Зачем сначала вводить общий quality gate и showback, а уже потом chargeback, роутинг и оптимизацию стоимости;
- Где возникает vendor lock-in и когда локальная модель действительно выгоднее облачной после учёта качества и эксплуатации.
Отдельно покажу рабочий сценарий до 2029 года: цена сегодняшнего уровня качества может снизиться в разы, а бюджет успешного AI-портфеля — вырасти. Это не обещание рынка, а рамка для разговора о том, что именно компания получает за эти деньги.
Основной вопрос эфира про то, какая единица связывает качество, стоимость и риск? Токены удобны для счёта поставщика. Для инженерной организации полезнее принятая работа — задача, которая прошла проверку, не потребовала дорогой переделки и дала нужный результат.
Материалы к эфиру: дека и лонгрид, а также можете закидывать свои вопросы в комментариях к этому сообщению.
#AI #AI4SDLC #Engineering #FinOps #Agents #Management #Metrics | 1 209 |
| 3 | Вчера выступал на Podlodka AI Club и рассказывал свои мысли про экономику AI в разработке.
Когда готовился, то собрал вот такой лонгрид и вот такую слайд деку, но само выступление не записывалось.
Я могу записать отдельное видео для подписчиков канала, если вы хотите, но давайте соберем 👌 под этим постом, чтобы я понял, что вам эта идея нравится. Если их будет больше двадцати по итогу, то видео выйдет на Youtube, если нет, то останется только текстовые версии. | 1 509 |
| 4 | Грэм Уивер: как придумать игру, в которой хочется победить (Рубрика #Management)
Посмотрел последнюю лекцию Грэма Уивера для класса Stanford GSB 2025 года - «How to Design a Winnable Game». Грэм - преподаватель менеджмента в Стэнфорде, основатель и партнер Alpine Investors. Но говорит он не об инвестициях, а о моменте, когда понимаешь: много лет ты успешно играешь не в свою игру.
Начинается лекция с личного момента, когда во время кризиса 2008 года, по словам Уивера, фонд потерял 40%, крупнейший инвестор решил уйти, а он ночью считал, на сколько месяцев семье хватит сбережений, пока рядом спала новорожденная дочь. Вместо «как работать лучше, быстрее и больше?» появился другой вопрос: «а в ту ли игру я вообще играю?». И выигрышная игра в его понимании - та, в которой внешний успех не спорит с внутренним ощущением смысла. Ее не находят в готовом виде, а проектируют по четырем правилам.
1️⃣ Выбрать цель, которая по-настоящему зажигает
Не ориентир «лишь бы не проиграть», а направление, ради которого хочется вставать утром. Большая цель меняет наши действия и готовность идти долго.
2️⃣ Придумать собственную игру
Многие ограничения - не правила, а привычки отрасли. Стоит искать то, что ненавидят клиенты, чего не делают конкуренты, что лично не дает покоя, - и развивать уже работающие сильные стороны.
3️⃣ Играть с людьми, которыми восхищаешься
Окружение формирует наши цели, ценности и характер. Важно выбирать людей, рядом с которыми можно оставаться собой и не приносить жизнь в жертву результату.
4️⃣ Начать сейчас
«Не сейчас» - удобная форма страха. Жизнь не начинается после кредита, повышения или смены работы. Все, что мы пытаемся поскорее «пройти», и есть наша жизнь.
Это очень глубокое и личное выступление. Оно не обещает быстрых ответов, но мотивирует остановиться, честно посмотреть на свою жизнь и начать изменения — не когда-нибудь, а сейчас.
Ну и я забрал из этой истории идею о том, что прежде чем становиться эффективнее, стоит проверить саму систему координат. Хочу ли я победить в этой игре? Делает ли участие в ней меня тем человеком, которым я хочу быть? И с теми ли людьми я ее прохожу?
P.S.
Мне вспоминалась другая последняя лекция примерно того же уровня «Randy Pausch Last Lecture: Achieving Your Childhood Dreams», о которой я рассказывал раньше.
Обе эти лекции построены похоже и мотивируют посмотреть на свою жизнь и понять, а занимаешься ли ты тем, что действительно хочешь ... и если нет, то это значит, что пора что-то менять.
#Management #Leadership #Career #Goals #Stanford | 1 503 |
| 5 |  ArchBench: хороший каркас, слабый лидерборд (Рубрика #Architecture)
Прочитал короткую работу "ArchBench: Benchmarking Generative-AI for Software Architecture Tasks". Идея здравая: собрать разрозненные evals для software architecture в одну расширяемую систему. Но на 19 июля 2026 года это скорее каркас будущего бенчмарка, чем рабочий лидерборд для выбора модели (можете сами оценить лидерборд на сайте бенча).
Команда SERC из индийского IIIT Hyderabad собрала открытую систему из CLI и React-сайта. Каждая задача - это плагин со своим загрузчиком данных, промптом, парсером и метриками. Общий конвейер проходит стадии загрузки, инференса и оценки, сохраняя промпты, сырые ответы, использование токенов и latency. Результаты и новые задачи предполагается принимать через PR.
Но наполнение у самого бенча слабое - всего 5 задач
- Генерация ADR (architecture decision records)
- Генерация serverless-компонентов
- Создание dynamic IoT сервисов
- Создание микросервисов
- Восстановление traceability
Эти задачи не покрывают архитектурный анализ, размышление о зависимостях, масштабный рефакторинг или работу с компромиссами. Причем end-to-end автоматизированы в CLI только написание ADR и восстановление traceability, а еще три таблицы с метриками перенесены из исходных исследований, их пайплайны для оценок пока интегрируются.
Метрики смешивают разные вещи
- ROUGE и BERTScore измеряют похожесть текста (для написания ADR)
- Test pass rate - функциональность кода при генерации сервисов и функций
Правда, это далеко от оценки качества архитектуры.
Агентных sandbox-окружений для использования инструментов у ребят пока нет пока нет.
Набор моделей тоже удивляет: GPT-3.5, старые GPT-4, Flan-T5/T0, CodeQwen и DeepSeek прежних поколений.
В генерации микросервисов есть Codex и Claude Code, но без точных версий и конфигураций, а значит сравнивать такие цифры сложно
Авторы отмечают, что рассчитывают на коммьюнити рост (вот GitHub бенча, если захотите законтрибьютить), но в публичной истории на 19 июля не видно внешних контрибьютов с новыми задачами или результатами моделей. После статьи менялись интерфейс и код, но не сам измерительный корпус.
Итого, этот бенч выглядит как концепт, но он станет реальным бенчом после расширения задач, полной автоматизации, запуска современных версионированных моделей и появления независимых участников. А пока это приглашение строить бенч.
#Architecture #AI #AI4SDLC #Evals #Research | 1 549 |
| 6 | لا يوجد نص... | 1 816 |
| 7 | McKinsey про экономику AI-агентов: считать не токены, а результат (Рубрика #Management)
Прочитал интервью McKinsey с Дэвидом Теппером, CEO AI-FinOps-платформы Pay-i, про экономику агентных систем. В этом разговоре интересно то, что это взгляд не изнутри ИТ с моделями, контекстом, evals и tool calls, а со стороны CIO, CFO и владельца процесса. Какие агенты заслуживают бюджета и как это доказать?
Photo
Основная мысль в том, что цена токена почти ничего не говорит о ценности системы. Токены - это счёт, а не результат, причем агент может сделать сотни вызовов, по-разному пройти одну задачу и потратить в 30 раз больше или меньше ресурсов. Считать нужно стоимость завершённой и принятой бизнес-задачи.
McKinsey разделяет три сущности, которые рынок привык одинаково называть агентами.
- Workflow - обычный процесс с AI на отдельных шагах;
- Pipeline - заранее известная последовательность вызовов;
- Настоящий агент - сам выбирает инструменты, порядок действий и длительность работы.
У первых двух расходы ограничены архитектурой, у агента стоимость становится распределением с длинным хвостом. Автономность нельзя покупать «на всякий случай»: она должна окупать собственную неопределённость.
Исследования агентного программирования, на которые ссылается статья, дают показательные оценки: до 1000 раз больше токенов, чем в обычном coding chat, и около 59% расхода на проверку и исправления (1 и 2). Это не нормативы для любого бизнеса, но механизм важен: дороже всего может оказаться доведение результата до приемлемого качества.
Автор предлагает так оценивать, когда стоит внедрять агента:
P(success) > T(verify) / T(do).
Если человек выполняет задачу два часа, а результат агента проверяет за шесть минут, агенту достаточно для паритета с человеком примерно 5% успешных попыток. Но это верно, если ошибка не имеет внешних ээффектов. Плохой документ можно выбросить; неверное обещание клиенту уже создаёт стоимость восстановления. Проверку и переделку Теппер называет «налогом автономности» — agency tax.
Здесь особенно заметен бизнес-взгляд гостя интервью
- Технических метрик - latency, error rate, стоимость вызова - недостаточно.
- До запуска нужно определить, какой KPI меняет агент: время обработки заявки, выручку, число ошибок, конверсию.
- ROI - не KPI, а расчёт на основе KPI и полной стоимости сценария.
Практический план поэтому организационный: провести инвентаризацию агентов, назначить владельцев и бизнес-KPI, измерять результат всего workflow, а не только счёт провайдера, и собрать общий контур управления из финансов, ИТ и бизнес-заказчика. KPI после пилота легко превращается в оправдание уже сделанных расходов.
Этот ракурс полезен, но не самодостаточен. Бизнес-метрики не заменяют evals, безопасность и инженерную надёжность. Как и идеальная архитектура не отвечает на вопрос, зачем агент нужен компании.
Для меня главный вывод: обсуждение агента стоит начинать с единици ценности, критериев приёмки, цены проверки и последствия ошибки, а уже затем думать про архитектуру и токены. Тогда AI становится не экспериментом внутри ИТ, а управляемой инвестицией бизнеса.
#AI #Agents #Management #FinOps #Metrics #Engineering | 1 910 |
| 8 | Theo Browne про AI-разработку: мыслить шире, проектировать строже (Рубрика #AI4SDLC)
Посмотрел заключительный keynote Theo Browne «Everything we knew about software has changed» с AI Engineer World's Fair 2026. Theo строит инструменты для разработчиков, поэтому его интересно слушать не как комментатора моделей, а как практика, у которого AI уже изменил масштаб проектов. Главная мысль его доклада: границу «слишком большого» пора провести заново.
Сдвиг Theo показывает через собственную лестницу
- Reddit scraper был проектом на два-три дня
- Ping, сервис для совместных стримов, стал стартапом и прошёл Y Combinator
- Full-stack cloud - условный Vercel с базами данных - казался затеей для большой компании.
Теперь, считает Theo, вся лестница сдвинулась вниз: вчерашний стартап становится side project, а внутренний сервис - исполняемой инструкцией. Его агент каждое утро разбирает pull requests в четырёх репозиториях, расставляет приоритеты и публикует HTML-отчёт в S3. Вместо отдельного сервиса - Markdown и cron.
Переход Theo связывает с тремя поколениями моделей:
1) Sonnet 3.5 для него дал надёжный tool calling
2) Opus 4.5 - длинные самостоятельные задачи
3) Mythos (Fable 5) - оркестрацию с дополнительными агентами.
Это его личная карта, а не бенчмарк, но вопрос интересный: выдавая новой модели старую работу размером с Jira-тикет, не пропускаем ли мы возможность ставить задачи другого масштаба?
Самая интересная часть - переход от узких продуктов к широким. Theo считает, что маленькая команда теперь может собрать большую поверхность продукта, а недостающую глубину отдать пользователям через расширения. Но разработка всё ещё живёт в «скевоморфной фазе»: мы работаем через естественный язык, сохраняя ограничения времён дорогого кода. Отсюда провокация в финале: почему бы не попробовать конкурировать со Slack, AWS или Salesforce?
Здесь нужна инженерная оговорка. Ширина прототипа и зрелость продукта - разные вещи. AI удешевляет реализацию, но не отменяет модель данных, миграции, права доступа и наблюдаемость. Пользователь сможет достроить продукт только там, где есть стабильные контракты и безопасные примитивы.
Смотреть доклад стоит не ради прогноза о победе маленьких команд над AWS. Он показывает путь Theo от двухдневного скрипта к проектам, которые раньше он сам отбрасывал как невозможные, и хорошо перенастраивает масштаб мышления.
#AI #AI4SDLC #Engineering #Architecture #Product #Agents | 1 920 |
| 9 | Опубликовал лонгрид о конфигурациях агентного стека. Спор обычно сводят к выбору между «своим OpenCode» и «чужим Claude Code или Codex», но это ложная развилка: отдельно выбираются обвязка, модель и инструменты, а контроль нужен над всей цепочкой _ от данных и идентичности до фактического действия в системе. Разобрал восемь вариантов стека: их TCO, lock-in, характерные отказы и границы безопасности. Главный вывод: суверенность и безопасность — свойства всей архитектуры, а не отдельного компонента.
Сегодня в 17:00 МСК будем разбирать эти идеи на стриме с Мишей Трифоновым: что выбрать для пилота, корпоративной платформы и регулируемого контура.
#AI4SDLC #Agents #Architecture #PlatformEngineering | 2 381 |
| 10 | Бенуа Шиллингс: R&D после кода (Рубрика #AI4SDLC)
Посмотрел keynote доклад Бенуа Шиллингса, VP из Google DeepMind на AI Engineer World’s Fair 2026. Его позиция мне интересна - он не лидер продуктового ИТ, внедряющий агента в SDLC, а руководитель R&D. Его команда создаёт технологии, которые понадобятся Gemini на горизонте от месяца до года. Поэтому вместо backlog, CI/CD и SLO он обсуждает, чему должна научиться следующая модель.
У истории забавное начало. В 2018 году его команда в X запустила проект Pitchfork про применение ML к коду, но идею почти никто не воспринимал всерьёз. Сам Шиллингс отвергал программирование на естественном языке: для этого уже есть языки программирования. Теперь человек с 45-летним опытом - от ассемблера до Python - признаёт ошибку и использует vibe coding.
Главный тезис: генерация кода и software engineering - это разные задачи. По мнению Шиллингса, модели уже генерируют синтаксис лучше человека. Но настоящая разработка начинается, когда нужно изменить систему с 35 миллионами строк PHP, учесть архитектуру, безопасность и последствия решения через десять лет. Узкое место переезжает в постановку задачи, декомпозицию и проверку замысла.
Код для DeepMind - это удобная R&D-лаборатория: данных много, результат проверяется компилятором и тестами. Следующий шаг - self-play, где модель сама создаёт задачи, решает и проверяет их, как AlphaZero учился через игру с собой. Ограничением становятся compute и качество среды обучения.
Исследовательский roadmap из доклада выглядит так:
- Учить модель писать безопасный код сразу, а не только находить уязвимости постфактум;
- Развивать планирование, декомпозицию и перенос идей между областями;
- Менять evals: проверка «запустилось и выдало ответ» слишком узка для архитектуры;
- Выходить за линейную цепочку токенов к мультимодальным представлениям;
- Возможно, создавать строгие языки для моделей, даже если человеку их будет неудобно читать.
Последний пункт особенно хорошо показывает R&D-оптику: снять ограничение читаемости кода человеком и переложить доказательство корректности на модель и язык.
Шиллингс прогнозирует, что код станет почти бесплатным, его объём взорвётся, а через год люди почти перестанут читать результат агента - как сегодня редко проверяют ассемблер после компилятора. Это прогноз, не факт и есть определенная разница между агентом и компилятором - последний работает по строгой спецификации, а агент - в неоднозначном бизнес-контексте.
За рамками остаются legacy, ownership, SLO, стоимость inference и rollout. Зато финал уходит в химию и биологию: для Шиллингса coding models - полигон для общего reasoning и научных открытий.
Мне это выступление понравилось - это не инструкция по внедрению AI в ИТ (с этим у меня проблем нет), а скорее карта upstream-исследований. Условно
- R&D спрашивает: «Что модель сможет открыть и построить?»
- Продуктовое ИТ добавляет: «Как доказать, что результат нужен, безопасен и управляем?»
#AI #AI4SDLC #Research #Engineering #Architecture #Evals | 2 135 |
| 11 | لا يوجد نص... | 1 943 |
| 12 | لا يوجد نص... | 1 971 |
| 13 | لا يوجد نص... | 1 |
| 14 | Алексей Миловидов и ClickHouse: от любопытства до компании в $15 млрд (Рубрика #Software)
С большим интересом посмотрел большое интервью Елизаветы Осетинской (иностранного агента) с Алексеем Миловидовым, создателем и CTO ClickHouse. Формально это история компании с оценкой $15 млрд. Но мне она показалась интереснее как путь инженерного проекта: от любопытства и внутреннего инструмента до open source и глобального бизнеса.
Программировать Алексей начал на советском БК-0010. Игру можно было загрузить с кассеты или вручную набрать десять страниц кода из журнала. Если ошибся, вспоминает он, игра могла работать «чуть-чуть по-другому». Старшие братья в итоге просто выдали ему книгу: «Разбирайся».
Позже он поступил на мехмат МГУ, хотя хотел на ВМК, а затем выбрал «Яндекс» — несмотря на меньшую зарплату. В первый же отпуск руководителя система веб-аналитики, которую поддерживали два человека, перестала справляться с трафиком. Алексей её стабилизировал, а затем захотел отчёты в реальном времени с произвольными разрезами. Так из практической боли начал расти ClickHouse.
Название сложилось из clickstream и data warehouse. Когда аналитики «Яндекса» вместо многочасовых Perl-скриптов получили ответы за секунды, технология выглядела как магия. При этом её долго почти не замечали — и это оказалось преимуществом: команде не мешали спокойно строить систему.
В 2016 году ClickHouse открыли как open source. Алексей называет это способом «проникнуть на рынок, пока никто не видит». Сначала появились пользователи, контрибьюторы и митапы, а уже потом — компания. Бизнес построили вокруг того, чего нет в «голом» движке: масштабирования, резервного копирования, безопасности и интеграций. Самостоятельно можно бесплатно; тем, кто не хочет содержать отдельную экспертизу, продают ClickHouse Cloud.
Сам стартап тоже собирался необычно. В 2021 году 12–14 человек переходили из «Яндекса», а трое кофаундеров знали друг друга только по Zoom — онлайн-дейтинг, шутит Осетинская. В компанию уже вложили $50 млн, хотя облачного продукта ещё не было, а у нанятой sales-команды оставался вопрос: «Да что продаём-то?»
Роли разделили прагматично: Аарон Кац — бизнес и продажи, Юрий Израилевский — облако и команды, Миловидов — технология. Алексей не стал CEO: без опыта шанс убедить нужных людей он оценивал примерно в 5%. Сейчас в компании больше 600 сотрудников, но формально он не руководит никем, работает со всеми и соглашается с ролью «создателя тревоги».
В истории много таких деталей. Квартиру в Амстердаме Алексею сдала хозяйка, чья сестра знала ClickHouse по Китаю. За четыре с половиной года он выучил по-нидерландски главным образом goedemorgen. А AI-сотрудник Groene AI чинит «красные» тесты и уже подружился с особенно угрюмым контрибьютором.
Если сокращать, то получаются два основных момента
- ClickHouse вырос не из гениального питча, а из цепочки хорошо решённых инженерных проблем (а я помню как лет 10 назад ClickHouse захватывал рынок аналитических решений в России, так как других решений такого класса в opensource не было)
- Но одной технологии было мало, ее создателю пришлось увидеть продукт глазами клиентов, доверить продажи и компанию людям с другим опытом и продолжать строить крутой продукт
#Software #Data #OpenSource #Engineering #Architecture #Management | 2 227 |
| 15 |  Материалы про кодинговых агентов и важность экспертизы (Рубрика #AI4SDLC)
Готовы материалы с подкаста Code of Leadership, который был в среду с Евгением Сергеым:
- Презнтация: Слайд дека с разбором
- Видео: Youtube, VK
- Аудио: Podster, Ya Music
- Текст: Краткая расшифровка
#AI4SDLC #Agents #Architecture #Engineering #Software #Books | 2 292 |
| 16 | The Java Story: как язык стал долгоживущей платформой (Рубрика #Software)
Посмотрел вчера в прямом эфире документалку «The Java Story» от CultRepo про историю Java. В кадре были James Gosling, Joshua Bloch, Brian Goetz, создатели Tomcat, Spring, Hibernate и Kotlin, а также инженеры Java-экосистемы. Но для меня это не столько история просто языка, скорее это история про целую технологическую платформу, что пережила собственные ошибки, смену владельца и попытки объявить её мёртвой. И кажется, что причина в том, что эта платформа научилась меняться, не разрывая экосистему. Совместимость, управление платформой и сообщество оказались важнее красоты отдельных языковых решений.
Изначально java называлась Oak и ее создавали для бытовых вычислительных устройств. Интерактивное телевидение не взлетело, команда переключилась на веб, а настоящий масштаб Java в итоге нашла на сервере. Уже здесь видна повторяющаяся схема: технология сохраняет ядро, но меняет рынок и задачу вокруг него.
Даже знаменитое мотто write once, run anywhere в фильме постепенно перестаёт быть рекламным лозунгом. Конфликт Sun с Microsoft показан как борьба за то, кто контролирует платформенный контракт. Если реализация Java под Windows становится несовместимой с остальными, переносимость исчезает, а вместе с ней - и сама причина существования платформы. Здесь Microsoft тех лет представлен в виде гиганта, что греб все под себя:)
Но одной защитой совместимости экосистему не построить. Java Community Process формализовал участие компаний и сообщества в развитии спецификаций. Tomcat показал Sun, что открытый код не обязательно ведёт к хаосу. Позже OpenJDK закрепил ещё более важную мысль: платформу можно открыть, не отказываясь от общего контракта.
Здесь история начинает переплетаться с другими фильмами. J2EE пыталась стандартизировать корпоративную разработку сверху, но стала слишком тяжёлой для повседневной работы. Spring и Hibernate ответили снизу: обычные объекты, тестируемость и более прямой контроль над кодом. В фильме это сформулировано довольно жёстко: сообщество открытого кода справилось там, где спецификации и поставщики платформы не услышали разработчиков.
А когда после Java 5 развитие языка замедлилось, сама виртуальная машина Java (JVM) не опустела. Scala, Clojure и Kotlin предложили более современные модели, сохранив библиотеки, инструменты и среду выполнения Java. Это сильная платформенная конструкция: недовольство языком не обязательно означает уход из экосистемы. Иногда новая идея сначала появляется рядом, а затем заставляет основную платформу двигаться.
Полезно сопоставить эту линию и с .NET. В фильме Microsoft сначала выступает угрозой из мира закрытой Windows-платформы. Но позднее C# и .NET сами прошли путь к открытому коду и кроссплатформенности. Получается не простая история «Java против Microsoft», а две разные траектории к одной задаче: как удержать разработчиков, не запирая их в технологическом тупике.
Современная Java продолжает ту же логику. Java 8 добавила лямбды и Stream API, не создавая отдельный «новый Java». Шестимесячный цикл отделил готовность конкретной возможности от большого редкого релиза. А virtual threads в Project Loom меняют внутреннюю механику потоков, сохраняя знакомые API и последовательную модель thread-per-request. Инженерно это красивая часть истории: заменить фундамент дома так, чтобы людям наверху не пришлось учиться ходить заново.
У фильма есть понятная оптика: его поддержали компании Java-экосистемы, а историю в основном рассказывают люди, которые эту платформу создавали. Поэтому я бы смотрел его как коллективную инженерную автобиографию, а не как независимое расследование. Особенно там, где участники оценивают решения Sun, Oracle или влияние отдельных проектов.
Для меня главный вывод такой: зрелая платформа - это не только язык, среда выполнения и API. Это ещё бюджет совместимости, правила принятия решений, инструменты, открытый код, выпуск обновлений и возможность сообщества исправить платформу, когда её владельцы ошибаются. Практически это означает, что архитектору платформы мало проектировать расширяемое ядро. Нужны путь миграции, предсказуемый цикл релизов и место для альтернатив. Java выжила не потому, что всегда выбирала правильно. Она выжила потому, что экосистема снова и снова получала возможность скорректировать курс.
Связанные разборы документалок в System Design Space:
- Spring: The Documentary
- IntelliJ IDEA и линия Kotlin
- C#, TypeScript и эволюция .NET
- Clojure как альтернативная линия JVM
А вот они же но просто в виде фильмов, если вы решите почилить и продолжить после истории Java просмотр остросюжетных документалок про Spring, IntelliJ IDEA, Clojure и Apache Tomcat
#Software #Java #JVM #Architecture #Engineering #OpenSource #History | 2 229 |
| 17 | Research Insights Made Simple #22: как собрать управляемый агентный стек (Рубрика #AI4SDLC)
Что компания делает «своим» в агентной платформе: код клиента, модель, контур исполнения, данные или право агента менять внутренние системы? Эти вещи часто смешивают и сводят выбор к спору между «своим OpenCode» и «чужим Claude Code или Codex».
В понедельник 20 июля в 17:00 по мск мы с Мишей Трифоновым из Cloud.ru разберём в прямом эфире эту ложную развилку и соберём полное описание агентного стека в рамках 22-м выпуска подкаста Research Insights Made Simple.
Миша Трифонов - Директор департамента внутренней платформы разработки Cloud.ru
Рабочая формула шире привычной пары «модель + обвязка»:
агентный стек = обвязка + модель + инструменты + идентичность + технические границы исполнения.
Обвязка управляет циклом работы и контекстом, модель предлагает план, инструменты создают реальный эффект. Идентичность, sandbox и policy engine определяют, от чьего имени и в каких границах действует агент.
Поговорим о восьми конфигурациях: от автономного стека и локальной модели до внешнего планировщика, корпоративного tool gateway и полного SaaS. У каждой схемы своя цена контроля, скорости, lock-in и эксплуатации.
Отдельно обсудим несколько неочевидных следствий:
- open source ≠ local inference;
- self-hosted ≠ безопасные действия;
- доступы сотрудника ≠ доступы агента
- внутренний MCP ≠ узкие полномочия;
- внешний API ≠ внешнее право на действие;
- multi-model router = отдельная платформа.
Ключевая идея — разделить два пути. Модельный шлюз контролирует, какие данные и к какой модели уходят. Инструментальный шлюз решает, кто, что и от чьего имени может изменить. Между ними нужны единые identity, policy, trace и evals.
И здесь разговор переходит к безопасности. Атакуют не абстрактную модель, а путь от недоверенного README, issue или tool result до действия с реальными полномочиями. Поэтому ограничения должна обеспечивать инфраструктура, а не системный промпт.
В общем, мы обсудим не «какой агент лучше», а какую минимальную конфигурацию выбрать для пилота, корпоративной платформы или регулируемого контура — и кто отвечает за фактическое изменение системы.
Добавляйте стрим в ваш календарь, чтобы не пропустить его.
#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Security #Engineering | 2 396 |
| 18 |  Материалы про AI-assisted Engineering (Рубрика #AI4SDLC)
Готовы материалы с подкаста Code of Leadership, который был в среду с Алексеем Литвиновым:
- Презнтация: Слайд дека с разбором
- Видео: Youtube, VK
- Аудио: Podster, Ya Music
- Текст: Краткая расшифровка
#AI4SDLC #Agents #Architecture #Engineering #Software #Books | 2 351 |
| 19 | Через 5 минут стартуем стрим с Алексеем Литвиновым, где будем говорить про свежие бенчи интерактивной работы с агентами: SWE-Together и SWE-INTERACT
Подключайтесь к стриму и задавайте вопросы в комментах - мы постараемся интреактивно на них отвечать:) | 2 358 |
| 20 |  Мысли про архитектуру (Рубрика #Architecture)
Поймал себя на мысли, что в своих пет-проектах я архитектуру улучшаю из идеи, что хочу быстро пилить фичи, но
- Не хочу тратить много денег на обслуживание - нужны эффеrтивные CI/CD пайплайны и оптимальная схема для работы в проде
- Не хочу тратить много времени на поддержание - приложения должны быть self-healing, а эволюция решения простой в нужную мне сторону
- Не хочу тратить много слов на объяснение агентам как пилить новые фичи (на объяснение что пилим тратить время готов) - должны быть заданы понятные архитектурные рамки
- Не хочу тратить много сил на ревью и разбираться с регрессионными багами - нужно много детерминированных проверок
Вроде бы получается неплохо, но когда я косячу, то сразу вижу, что закончились лимиты или начал быстро уходить бюджет - дальше это прямой триггер, чтобы разобраться где я налажал:) В больших компаниях с такими триггерами и быстрой обратной связью плохо и поэтому к моменту, когда люди решают взяться за решение проблемы у систем уже не просто отдышка, а ожирение 4 степени и жировые бляшки в сердце, которое уже не может нормально прокачивать кровь для всего организма.
P.S.
Мысли появились после изучения whitepaper про AI для software architecture.
#Architecture #Engineering #Software #SystemDesign | 2 338 |
