Книжный куб
رفتن به کانال در Telegram
Канал Александра Поломодова (@apolomodov), cto & technical fellow. https://polomodov.tech - сайт со всеми материалами youtube.com/@tellmeabouttech - канал со всеми видео
نمایش بیشتر📈 تحلیل کانال تلگرام Книжный куб
کانال Книжный куб (@book_cube) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 15 752 مشترک است و جایگاه 2 336 را در دسته کتب و رتبه 41 358 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 15 752 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 16 سپتامبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 1 053 و در ۲۴ ساعت گذشته برابر 2 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 16.63% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 10.47% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 2 620 بازدید دریافت میکند. در اولین روز معمولاً 1 650 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 21 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند engineering, native, devex, devops, leadership تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Канал Александра Поломодова (@apolomodov), cto & technical fellow.
https://polomodov.tech - сайт со всеми материалами
youtube.com/@tellmeabouttech - канал со всеми видео”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 17 سپتامبر, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته کتب تبدیل کردهاند.
15 752
مشترکین
+224 ساعت
+187 روز
+1 05330 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
سپتامبر '26
سپتامبر '26
+234
در 4 کانالها
اوت '26
+1 165
در 5 کانالها
Get PRO
ژوئیه '26
+355
در 7 کانالها
Get PRO
ژوئن '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 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 17 سپتامبر | 0 | |||
| 16 سپتامبر | +10 | |||
| 15 سپتامبر | +9 | |||
| 14 سپتامبر | +12 | |||
| 13 سپتامبر | +18 | |||
| 12 سپتامبر | +9 | |||
| 11 سپتامبر | +14 | |||
| 10 سپتامبر | +7 | |||
| 09 سپتامبر | +5 | |||
| 08 سپتامبر | +10 | |||
| 07 سپتامبر | +5 | |||
| 06 سپتامبر | +6 | |||
| 05 سپتامبر | +8 | |||
| 04 سپتامبر | +8 | |||
| 03 سپتامبر | +33 | |||
| 02 سپتامبر | +19 | |||
| 01 سپتامبر | +61 |
پستهای کانال
Developer Productivity for Humans: четыре противоречия AI (Рубрика #AI4SDLC)
В разборе «All Models Are Wrong But Some Are Useful» я рассказывал, почему измерение продуктивности инженеров требует баланса между speed, ease и quality. Удобная модель может просто выкинуть часть работы из рассмотрения — и показать красивое ускорение. После этого я собрал другие исследования серии Developer Productivity for Humans в двух постах 1 и 2: про цели разработчиков, качество, техдолг, онбординг и многое другое.
Теперь прочитал продолжение — «Navigating the Tensions of AI in the Software Development Lifecycle», опубликованное 4 сентября 2026 года. Здесь ребята из Google разбирают, что происходит с этой рамкой при использовании AI. Они проанализировали 1110 открытых ответов разработчиков Google о влиянии AI на их работу за последние три месяца. Это качественный анализ опыта внутри одной компании: универсального процента ускорения из него не получится, зато хорошо видны четыре противоречия.
1️⃣ Экономия работы и её перенос
Код появляется быстрее, но дальше нужно сформулировать уточнения, проверить результат, исправить ошибки. Часть нагрузки может вообще уехать к другому человеку: автор быстро отправил изменение, а ревьюеру теперь разбираться со всем сгенерированным объёмом. Ускорение одного инженера ещё надо сопоставить с затратами всей команды.
2️⃣ Быстрый результат и накопление долга
Разработчики отмечают многословный код и документацию, которая красиво написана, но плохо объясняет причины решений. Авторы связывают это с техническим, когнитивным долгом и долгом замысла (intent debt): система работает, а понимание её устройства и того, почему она устроена именно так, постепенно теряется. При этом AI может помогать и сокращать долг — вопрос в том, какие задачи ему ставить.
3️⃣ Лёгкий старт и сложная последняя миля
AI помогает быстро собрать прототип, но остаются пограничные случаи, безопасность и интеграция с внутренней инфраструктурой. В ответах даже встречались случаи, когда инструмент сообщал об успешных тестах, вообще их не запустив. По скорости появления демо легко переоценить готовность продукта:)
4️⃣ Возможность сделать и способность проверить
С AI проще взяться за незнакомый язык или систему. Но знаний для проверки решения может не хватить. Авторы обсуждают риск пропустить самостоятельное разбирательство, через которое формируется экспертиза, и со временем потерять навыки. Это риск, а не установленный этим опросом долгосрочный эффект.
Дальше авторы предлагают вполне конкретные меры:
- Проверять по ходу работы: встроить тесты и автоматическую валидацию в цикл агента, давать ему небольшие задачи, сократить переключения между разрозненными AI-инструментами.
- Следить за долгом: убирать дублирование и неудачные абстракции, проверять содержательность документации, сохранять объяснения архитектурных решений.
- Отдельно планировать доведение до прода: учитывать проверки и интеграцию, обеспечивать инструменты контекстом внутренних API, кода и архитектуры.
- Защищать обучение: использовать AI как объясняющего помощника, сохранять наставничество и самостоятельную работу там, где команде нужна глубокая экспертиза.
И заканчивают они темой командной работы: ясные процессы, связь с долгосрочными целями, психологическая безопасность и баланс нагрузки. Инженер должен иметь возможность сказать, что устал проверять генерацию или не доверяет результату, без страха получить претензию за недостаточную скорость. Хорошее продолжение разговора про модели продуктивности: учитывать нужно и тех, кто проверяет результат сегодня, и тех, кому развивать эту систему завтра.
P.S.
Приложил к посту свою версию этой статьи с разметкой интересных моментов (именно так я обычно и читаю whitepapers).
#AI4SDLC #AI #Engineering #Management #Productivity #Research
| 2 |  Раньше я читал whitepapers и обсуждал их сам с собой. Выглядело это как игра и за белых и за черных на шахматной доске. Теперь я читаю whitepapers, оставляю заметки на полях, а потом обсуждаю это с Codex/Claude, причем ассистент не только видит исходный текст, но и мои отметки и готов с ними поспорить. Честно говоря, теперь их изучать стало сильно интереснее.
Кстати, дальше буду выкладывать краткие саммари по научным статьям со своими отметками на полях - теперь я их в основном на планшете читаю. А раньше я часто печатал их на бумаге - в итоге, в моем кабинете в Т-Банкке осталась стопка в 20 см распечатанных научных статей с моими отметками во время разборов. | 1 448 |
| 3 | Как Vercel строила d0: путь агента и вопросы к результату (Рубрика #AI4SDLC)
В докладе «How We Solved Agent Building» Andrew Qu, Chief of Software в Vercel, рассказывает, как команда строила внутреннего аналитического агента d0. Каждое архитектурное решение упиралось в следующую проблему. В итоге, по оценке Qu, получился полезный агент, а затем и фреймворк eve. Насколько этот путь подтверждает слово «solved» в заголовке — хороший вопрос по ходу разбора.
1️⃣ Большой промпт: проверить, умеет ли модель решать задачу
Исходная боль вполне приземлённая: аналитиков постоянно отвлекали вопросы коллег о клиентах, продуктах и показателях. Qu начал со схемы Snowflake, вставленной в системный промпт. Модель генерировала SQL, который он копировал и запускал вручную.
Хороший дешёвый эксперимент. Но между исполняемым SQL и правильным ответом на бизнес-вопрос ещё есть расстояние: нужно выбрать нужный показатель, период, фильтры и связи между таблицами. Следующая версия должна была выполнять весь процесс.
2️⃣ Цепочка специалистов, затем один агент с общей историей
Команда разложила работу на этапы: исследовать схему, спланировать запрос, выполнить SQL, подготовить отчёт. Каждому агенту дали узкую роль и свои инструменты. По словам Qu, проблема была в передаче контекста: следующий участник получал лишь краткую выжимку предыдущего шага.
Когда выполнение обнаруживало неверное предположение, хотелось вернуться к исследованию. Поэтому этапы объединили в одного агента, который сохранял историю работы и сам переключался между планированием, выполнением и проверкой. Обобщать этот результат на все многоагентные системы рано: здесь мешали жёсткая последовательность и потеря контекста при передаче. И первые пользователи всё равно оценили новую систему плохо — их вопросы выходили за пределы сценариев разработчиков.
3️⃣ Рабочий каталог вместо разрастающейся обвязки
Следующий поворот случился, когда, по словам Qu, Claude Code с Opus 4.5 стал отвечать на их вопросы заметно лучше собственного агента. Команда перенесла этот подход в d0: изолированная среда, файлы семантического слоя, обычные инструменты чтения, поиска и bash, плюс операции для задач Vercel. Семантический слой — это описания показателей и связей между сущностями. Теперь агент мог сам исследовать их и возвращаться за деталями по мере необходимости. Qu говорит, что оценка на внутренних тестах примерно удвоилась.
Тут сразу два вопросика:
❔ Какую часть улучшения дала архитектура, а какую — более сильная модель? Доклад не позволяет разделить эти эффекты
❔ Насколько убедительны сами тесты? «100% успеха» в связанной статье — это пять успешных запросов из пяти вместо четырёх. С удвоением оценки из выступления их объединять нельзя: сопоставимость наборов не показана.
Кстати, в статье Qu отдельно оговаривает: у команды уже были хорошо документированные данные. Файловая система открыла модели доступ к готовому знанию. При переносе такого решения в другую компанию качество этого знания придётся проверять отдельно.
4️⃣ Повторяющиеся запросы превращаются в skills
После расширения использования d0 команда заметила, что многие запросы похожи по структуре. По словам Qu, регулярная задача анализирует недавние запросы и выделяет из них навыки; к моменту выступления накопилось около ста. Следующий запуск получает уже подготовленный способ работы с типовой задачей. В eve такие навыки — инструкции, которые подгружаются по необходимости.
Вот здесь становится особенно интересно. Кто проверяет, что популярный способ посчитать показатель ещё и правильный? Как обновить навык после изменения бизнес-логики? Как откатить процедуру, которая разносит одну ошибку по новым ответам? Механизм генерации описан, а проверка, обновление и удаление навыков остались за кадром. Частота повторения сама по себе качество не гарантирует.
5️⃣ Удачный внутренний опыт упаковывают во фреймворк
Из этого пути вырос eve: инструкции, навыки, инструменты и каналы общения задаются файлами, а фреймворк собирает из них агента и обеспечивает среду выполнения. Qu говорит о тысячах запросов к d0 в день и примерно 20 востребованных агентах внутри Vercel.
Это признаки использования. Для оценки эффекта хотелось бы ещё увидеть долю правильных ответов, время на их проверку и стоимость сопровождения. Заявление, что аналитики освободились для более содержательной работы, выглядит правдоподобно, но измерений экономии времени в докладе нет.
Путь d0 хорошо показывает, как работа над агентом постепенно затрагивает устройство знаний самой компании. Самый интересный следующий доклад был бы про жизнь этих ста навыков: кто отвечает за их правильность и как команда замечает, что накопленный опыт пора пересмотреть.
#AI #AI4SDLC #Agents #Data #Architecture #Evals | 1 525 |
| 4 | YC Paper Club: что делает модель рабочим агентом (Рубрика #AI4SDLC)
Посмотрел интересную встречу YC Paper Club про harness, которая называлась «Why The Harness Matters More Than The Model» и где обсуждалась обвязка модели: инструменты, память, выполнение кода и управление работой агента. Сама запись появилась 7 сентября и хоть заголовок видео спорный, но внутри четыре инженерных выступления о том, а что меняется, когда той же модели дают больше возможностей работать с окружающей средой.
1️⃣ Вступление François Chaubard из Y Combinator отлично работает как вступление. Он проходит путь от генерации текста к инструментам, памяти, навыкам, субагентам и системам, которые меняют собственную обвязку по результатам работы (тут прямо много отсылок к whitepapers). Заодно показывает свой эксперимент с автоматизацией исследований: задаёшь идею и метрику, дальше агенты ищут статьи, ставят эксперименты и готовят текст. Среди ролей есть даже научный руководитель, который периодически напоминает исследователю, что пора двигаться дальше. Академическую жизнь тоже автоматизируют :)
2️⃣ Seth Karten из Prime Intellect рассказывает про Prime Agent. У него интересная аналогия с иерархией памяти компьютера: веса модели, активный контекст, переменные в работающем Python-процессе и долговременные файлы. Большой результат инструмента можно оставить в памяти процесса, обработать кодом и передать модели только нужный фрагмент. Субагента можно вернуть к задаче с сохранённым контекстом. По мере работы обновлять навыки и инструкции, чтобы полезный опыт переживал отдельную сессию. Кстати, сама идея «дать агентам общаться друг с другом» выросла у Karten из вполне человеческой проблемы: надоело самому переносить информацию между параллельно работающими помощниками.
Среди примеров — создание эмуляторов игровых систем, оптимизация GPU-ядер и многодневные исследовательские задачи. Есть и история про почти идеальный результат на ARC-AGI: по словам Karten, первый запуск показал 99,9%, но просмотр логов обнаружил жульничество. Пришлось исправлять изоляцию среды и запускать заново. Полезная деталь для всех, кто привык смотреть только на итоговую цифру бенчмарка.
3️⃣ Jon Saad-Falcon из Stanford показывает OpenJarvis — персонального помощника, работающего на собственном устройстве. Здесь интересна схема настройки: сильная облачная модель изучает ошибки локальной системы и предлагает изменения модели, инструментов, памяти и логики агента. Изменения проходят проверку, а готовая конфигурация выполняет задачи локально. Авторы заявляют снижение предельных API-затрат примерно в 800 раз на своих тестах. Это не полная стоимость владения с железом и электричеством. Но сама возможность использовать облачную модель для подготовки более дешёвого локального помощника заслуживает внимания.
4️⃣ Самая прикладная часть — Josh France и Regan Bell из YC Labs про QM, внутреннюю платформу агентов для сотрудников YC. До неё команда подняла больше 50 Hermes-агентов в виртуальных машинах. Помощники были полезными, но требовали настройки и постоянного обслуживания: приходилось заходить в отдельные экземпляры и что-то чинить.
В QM историю и состояние разговоров вынесли в PostgreSQL, а песочницы стали ресурсами, которые агент подключает по необходимости. Обсуждают и менее очевидные трудности: агент слишком рано заканчивает работу; автоматические исправления помогают одному участку, но не учитывают систему целиком; информация из личного разговора может попасть в общий канал, потому что модель плохо понимает социальный контекст.
В общем, рекомендую посмотреть оригинальную запись - она длится всего час и там есть и исследовательские идеи и прикладной опыт.
#AI4SDLC #AI #Agents #Engineering #PlatformEngineering | 1 636 |
| 5 | Как AI изменит разработку ПО: материалы Organized Programming №92 (Рубрика #AI4SDLC)
Собрал материалы разговора с Кириллом Мокевниным: 13 сентября 2026 года вышел выпуск №92 Organized Programming, где я был гостем. Обсуждали, как AI меняет программистов, команды и IT-компании. Делился опытом внедрения AI в Т-Банке — и тем, почему после ускорения написания кода ещё приходится разбираться со всей остальной разработкой.
Если продуктовый менеджер быстрее пишет постановки, аналитик — требования, а разработчик — код, очереди между ними могут только вырасти. Интереснее посмотреть, сколько людей и согласований проходит одна задача, прежде чем результат увидит пользователь.
Обсудили
🔸 Команды с агентами
Один инженер может брать на себя больше этапов работы, сокращая передачи задачи между людьми. При этом необходимые роли сохраняются. Компактная команда — обсуждаемое направление изменений, а не уже достигнутая норма для любой компании.
🔸 Внедрение на масштабе
Общий доступ к моделям, инструменты, навыки для агентов и изолированные среды дают техническую основу. А менять процесс должно само продуктовое направление: исключения, на которых взлетел пилот, ещё нужно научиться воспроизводить для остальных.
🔸 Спецификации и проверку плана
Кирилл рассказал, как использует эти практики даже в небольших проектах: агенты снижают стоимость оформления. Но требования к качеству всё равно нужно подкреплять автоматическими проверками — один документ ничего не гарантирует.
🔸 Знания и внутренние платформы
Агенту трудно разобраться с неявными правилами и корпоративным форком, который ведёт себя иначе, чем исходный продукт. При этом документацией пользуются и люди вне разработки: переезд всего знания в Git меняет их работу тоже.
🔸 Три уровня измерения пользы
Используют ли инструмент, сколько времени он высвобождает и что компания получает с учётом всех затрат. Больше закрытых задач может означать, что команда просто добралась до менее полезной части очереди. Нужны новые стоящие гипотезы и понимание, куда направить освободившееся время.
🔸 Обучение и границы автономии
Готовая функция мало говорит о том, чему научился джун: надо разбирать постановку, план и понимание результата. В сложном легаси похожая проблема — сначала выяснить, почему система устроена именно так и кто зависит от её поведения.
Материалы выпуска
📌 Страница выпуска
📖 Когда код пишет агент: что остаётся инженерией — лонгрид подготовки к разговору.
🎬 Запись на YouTube
📝 Текстовый конспект разговора
Если уже внедряете агентов в команде, расскажите: что теперь дольше всего задерживает полезное изменение на пути к пользователю?
#AI4SDLC #AI #Agents #Engineering #PlatformEngineering #Management | 1 824 |
| 6 | Материалы выпуска: свобода CTO в стартапе и корпорации с Кириллом Евсеенко (Рубрика #Leadership)
Собрал материалы разговора с Кириллом Евсеенко, CTO аудиостримингового сервиса «Звук». Эфир Code of Leadership прошёл 11 сентября 2026 года. Обсуждали свободу технического директора: можно быстро принять решение и упереться в нехватку людей, а можно получить ресурсы для большого изменения — и обнаружить, сколько ещё людей должны с ним согласиться. Кирилл сравнивает эти среды через свой опыт: медицинский стартап, START и «Звук». По его словам, за шесть лет команда START выросла примерно с 12 до 150 человек, а на понимание правил работы в «Звуке» ушло около полугода. Разговор получился про то, как вместе с масштабом меняется сама работа CTO.
Обсудили:
- Когда пора строить своё. START начинал с внешних CDN, биллинга и кодировщика; затем стоимость и ограничения поставщиков стали поводом делать отдельные компоненты внутри. Как связать архитектуру с деньгами и учитывать поддержку решения через несколько лет.
- Как перестать чинить всё лично. Кирилл рассказал о переходе к работе через руководителей и платформенные команды. В том числе о распределении знаний, которые раньше держались на отдельных незаменимых людях: с ростом компании такая зависимость обходится дороже.
- Куда расти сильному инженеру. Техническая карьерная ветка позволяет расширять влияние без обязательного ухода в менеджмент. Но под роль нужны реальные сложные задачи и польза бизнесу — одного нового названия должности мало.
- Что происходит после «решили делать». Безопасность, юристы и смежные команды могут остановить уже подготовленный запуск. При этом Кирилл оговаривается: в корпорации решение тоже может занимать несколько часов. Важны конкретные полномочия, зависимости и цена ошибки.
- Как закрывать ненужные инициативы. Команде хочется продолжать свой проект, а руководителю бывает безопаснее ждать указаний: личный риск неудачи выше награды за успех. Обсудили, как такие стимулы мешают изменениям и зачем нужна ответственность за завершение работы, включая решение её остановить.
Материалы выпуска:
📌 Страница выпуска с таймкодами
🎬 YouTube, [VK Видео
🎧 Podster, Яндекс Музыка, Apple Podcasts
📝 Текстовый конспект разговора
Если переходили между стартапом и большой компанией, расскажите: какую привычку пришлось менять первой — и какое решение оказалось труднее всего довести до результата?
#CodeOfLeadership #Management #Leadership #Career #Strategy #Engineering | 1 954 |
| 7 |  +9Science Museum Souvenir Book (Рубрика #Museum)
Музей науки в Лондоне мне очень понравился - по нему было интересно гулять как одному, так и с детьми. В нем много экспонатов, организованных в серии по доменам, а внутри по времени. Примерно та же схема прослеживается и в сувенирной книге, что выхватывает изобретения, которые продвинули человечество, а также присутствуют в коллекции музея.
В общем, это крутое место, что заслуживает посещения:)
#Science #Museum #History | 2 149 |
| 8 | Где профит от данных, Лебовски? Материалы первого выпуска (Рубрика #Data)
Собрал материалы первого выпуска «Где профит от данных, Лебовски?». Эфир прошёл 7 сентября 2026 года: вместе с Андреем Цыбиным и Николаем Головым обсуждали, как превратить данные в деньги. Начали с вполне житейского запроса: данных накопили много, теперь хочется на них заработать. Только размер хранилища ещё ничего не говорит о том, кто готов за его содержимое платить. Кстати, у проекта есть собственный отдельный сайт prodata.tech, а следующий эпизод выйдет где-то через неделю.
Получился разговор с трёх сторон: продуктовая аналитика и эксперименты, архитектура платформ данных и инженерное лидерство. И со спором о том, сколько ценности остаётся в данных, когда убираешь подробности.
Обсудили:
- Три пути к деньгам. Продать данные наружу, улучшить решения внутри компании или построить на них продукт. Рамку обозначили целиком, а большую часть первого выпуска посвятили внешней продаже.
- Покупателя и его задачу. Кому нужен именно этот набор и что человек сможет с ним сделать? Андрей обращает внимание на охват, репрезентативность и стабильность сбора: рост показателя может означать, что мы стали больше наблюдать, а не что вырос сам рынок.
- Копию, права и обезличивание. Николай разбирает вопросы целей сбора и дальнейшего использования; отдельно говорили о повторной идентификации по событиям и маршрутам. Юридические примеры в разговоре — вопросы к проверке конкретной сделки, а не готовое разрешение продавать данные после удаления имён.
- Агрегированную аналитику. На примерах Strava и аналитики для поставщиков X5 спорили о цене детализации. Мы с Николаем обсуждали, как её потеря может снизить ценность; Андрей возражал, что качественный ответ на нужный покупателю вопрос сам может стать продуктом.
- Расходы после выгрузки. Подготовка, поддержка, защита, возможность копирования и собственное конкурентное преимущество, которым делишься с покупателем. Счёт за первую поставку ещё не отвечает на вопрос, выгодно ли всё это компании.
Материалы выпуска:
📌 Страница выпуска с таймкодами
📖 Лонгрид: три пути от массива к деньгам — отдельный разбор темы с кейсами и схемами, который я делал при подготовке к выпуску
🎬 Запись на YouTube
📝 Текстовый конспект разговора
Если пробовали монетизировать данные, расскажите, где оказалось сложнее: найти покупателя, подготовить полезный продукт или посчитать, что осталось после всех расходов?
#Data #Product #Analytics #Architecture #Management | 1 977 |
| 9 | Habitat: эволюция слоя хранения OpenAI (Рубрика #AI4SDLC)
Во втором квартале 2026 года два инженера с помощью Codex и GPT‑5.5 переписали Habitat с Python на Rust. В статье от 11 сентября OpenAI сообщила: Rust уже обслуживает 95% запросов этого сервиса. Habitat — это слой между ChatGPT, Codex и хранилищами: маршрутизация, права доступа, шифрование и правила размещения данных. И это интересный кейс AI-assisted миграции критической инфраструктуры, причем миграции масштабной — по данным OpenAI: почти 40 регионов, свыше 500 ПБ и 70 млн внутренних запросов в секунду. Компания заявляет выигрыш в эффективности CPU в 6 раз, памяти — в 15, правда, методики сравнения в статье нет.
Но изюминка здесь — в том, как ребята дошли до момента, когда переписывание стало правильной следующей задачей.
1️⃣ В 2023 году Habitat начинался как Python-библиотека над Cosmos DB. Она прятала детали хранения от продуктовых команд. Удобно: подключил библиотеку и работаешь с данными, не разбираясь каждый раз с маршрутизацией и авторизацией.
2️⃣ К середине 2025-го эта простота стала дорого обходиться. Новую логику приходилось раскатывать через десятки сервисов. Добавили проверку на теневом трафике — ещё несколько дней согласований. Исправили ошибку — новый круг. А потом одна команда откатила свой сервис по другой причине и вернула старый баг. Получили именно тот сбой, от которого пытались защититься.
3️⃣ Общая библиотека перестала быть удобной границей управления
— Habitat выделили в сервис: теперь изменения хранения, наблюдаемость и политики доступа можно было контролировать централизованно.
— И тут команда сознательно оставила Python. Сначала требовалось стабилизировать платформу и API, разблокировать продуктовую разработку. За эффективность решили заплатить позже, рассчитывая в том числе на развитие кодинг-моделей. Техдолг здесь был осознанным выбором порядка работ.
— При этом API намеренно сделали менее мощным. Простые операции над объектами и связями, предсказуемый объём работы, никаких произвольных SQL-запросов и неограниченных обходов графа. Объект и его связи лежат в одной партиции; соседние объекты могут оказаться в другом регионе. Красивый граф в модели данных ещё не обещает дешёвого обхода.
— Для сложных запросов — отдельные экземпляры Rockset, получающие изменения через CDC. Их масштабируют сами команды. Да, клиентам добавили хлопот. Зато цена сложного запроса становится их явной задачей, а аналитика изолирована от оперативного доступа к данным.
4️⃣ Следующий вызов — хвостовые latency внутри самого сервиса
База уже ответила, но занятый asyncio-цикл ещё не дал обработать результат. Команда стала измерять задержку планирования задач. Даже периодический разбор большого конфига feature flags оказался источником тормозов: помогли уменьшение конфига и разнесение обновлений во времени. А пул соединений с LIFO создал совсем неприятную петлю: медленный сервер позже возвращал соединение, оно первым использовалось снова, и перегруженный процесс получал ещё больше работы (это была ситуация с метастабильными отказами). Переход на FIFO разорвал эту обратную связь.
5️⃣ До Rust дошли уже с работающей платформой и понятными ограничениями. Python-версия на пике обслуживала более 20 млн запросов в секунду. Дальше пришло время снижать ресурсную цену этой архитектуры. Поэтому «два инженера переписали сервис» — финал длинной истории. До него пришлось определить границы ответственности, ограничить стоимость операций и разобраться с поведением системы под нагрузкой.
В общем, AI помог переписать реализацию, но сам кейс гораздо интереснее.
#AI4SDLC #Architecture #PlatformEngineering #Engineering #Rust #AI | 1 969 |
| 10 | Codex: почему дешёвые переделки не отменяют архитектуру (Рубрика #AI4SDLC)
Агенты удешевляют переделку систем, но хорошие границы и архитектура от этого становятся только важнее. Раньше команда росла постепенно, вместе с ней появлялись договорённости и документация. Теперь, по образному сравнению Тибо Соттьо, за выходные к проекту можно подключить сотню агентов. И все они начнут что-то менять. Хорошо бы к этому моменту понимать, что мы строим и как эти изменения должны уживаться друг с другом.
Это интересная линия в интервью Building Codex with Tibo Sottiaux, которое вышло 9 сентября на The Pragmatic Engineer. Тибо — один из создателей Codex, сейчас руководит Core Products & Platform в OpenAI. Разговаривает с ним Gergely Orosz, чей доклад «замедлиться, чтобы ускориться» я уже разбирал.
У Тибо хорошо прослеживается интерес к инструментам, которые помогают другим работать быстрее. В DeepMind он занимался инфраструктурой для исследователей. По его рассказу, из интерфейса для экспериментов с языковыми моделями вырос внутренний чат, которым коллеги активно делились ещё до выхода ChatGPT. Но превратить его в публичный продукт не удалось: Тибо связывает это с устройством Google и сложностью выпуска новых продуктов (но он сам признаёт, что ранние модели были довольно бестолковыми и это историю стоит читать с этой оговоркой).
В OpenAI он пришёл в 2024 году ради более тесной связи исследований и продукта. Снова начал с инфраструктуры, а затем вместе с коллегами стал обучать модели работать с внутренним Python-кодом и собирать агентов для ускорения исследований. Эти эксперименты объединились с направлением Autonomous Software Engineer и стали одной из основ Codex. Причём Тибо признаёт, что ранняя облачная версия не нашла product-market fit: слишком много трения для пользователя. Внутри полезно — ещё не значит, что снаружи удобно.
Дальше в разговоре есть несколько деталей о том, как это меняет саму разработку:
🔸 Архитектура нужна и самому агенту
Ядро Codex отделили от интерфейсов и написали на Rust ради надёжности, безопасности и эффективности. Хотя тогда модели лучше писали на Python и TypeScript. Команда заранее думала о том, как агент будет работать в разных продуктах и масштабироваться.
🔸 Часть обвязки должна уметь отмирать
Harness — окружение с инструментами и инструкциями — компенсирует слабости модели. Сначала ей приходится напоминать запускать тесты, потом это поведение появляется в самой модели. Тибо описывает совместную работу инженеров и исследователей: где исправлять проблему и сколько ждать следующую модель. Ты можешь написать большой обходной механизм, который через месяц уже не понадобится.
🔸 Code review смещается к намерению и контрактам
По словам Тибо, в OpenAI автоматизируют проверки корректности и безопасности; найденные проблемы безопасности блокируют PR. Человеческое обсуждение он предлагает сосредоточить на том, что компонент должен делать, какие данные может использовать и какие инварианты обязан сохранять. Об этом полезно договориться до генерации реализации.
🔸 Агенту нужна история решений
Внутри OpenAI Codex подключён к коду, Slack и документам. При объединении Codex с ChatGPT он даже вёл хронику обсуждений и выбранных решений. Получается интересное применение агента: помогать команде восстанавливать, почему система стала именно такой.
Это продолжает тему AI для software architecture: границы, ограничения и история компромиссов должны быть доступны для работы. А рядом остаётся вопрос из разбора Geoffrey Litt про понимание: что из этого способна объяснить сама команда?
По оценке Тибо, обслуживание и смена архитектуры сильно дешевеют. Но в его рассуждении есть условие: хорошие абстракции позволяют менять внутренности компонента, не задевая всё вокруг.
#AI4SDLC #AI #Agents #Architecture #Engineering | 2 257 |
| 11 | Залетайте на прямой эфир с Кириллом Евсеенко, техническим директором Звука. Мы с Кириллом планируем обсудить его карьеру, а также ответить на вопрос, а где у CTO больше свободы - в стартапе или в корпорации. Если будет вопросы, то мы с удовольствием по ходу будем на них отвечать. | 2 158 |
| 12 | [2/2] DistServe: параллелизм, очереди и баланс GPU (Рубрика #Research)
В первой части поста мы остановились на разделения prefill и decode. И после этого у нас появляется свобода: каждой стадии можно выделить свои GPU и по-своему распределить модель. Теперь эту свободу надо превратить в работающую конфигурацию.
Есть два подхода к параллелизму:
- Intra-op делит одну операцию, например умножение матриц, между GPU. В этом контексте — tensor parallelism. Отдельный шаг выполняется быстрее, но GPU часто обмениваются данными. Ускорение зависит от того, сколько съедает коммуникация.
- Inter-op делит слои модели на стадии конвейера — pipeline parallelism. Пока одна GPU обрабатывает следующий запрос, другая заканчивает предыдущий. Запрос всё ещё проходит все стадии; зато конвейер пропускает больше запросов. Расплата — простои, если стадии загружены неравномерно.
То есть можно ускорять прохождение одного запроса, а можно увеличивать частоту, с которой конвейер принимает следующие. Под нагрузкой второй вариант тоже сокращает задержку: меньше времени уходит на ожидание входа.
Здесь авторы достают из чулана теорию очередей.
Для начала они упрощают prefill: одинаковые промпты, постоянное время обработки D, пуассоновский поток R запросов/с, одна обслуживающая очередь без батчинга. Получается модель M/D/1:
TTFT = D + R·D² / [2·(1 − R·D)]
Это среднее время: вычисление плюс ожидание. Формула работает при R·D < 1. Если D = 100 мс, при 5 запросах/с среднее TTFT составит 150 мс, а при 9 запросах/с — 550 мс. Само вычисление осталось тем же. Выросла очередь.
Для двух GPU авторы сравнивают:
- intra-op: D/K + R·D² / [2K·(K − R·D)]
- inter-op: D + R·D² / [4·(2 − R·D)]
K — ускорение intra-op, здесь между 1 и 2. Во втором случае предполагаются две равные стадии и пренебрежимо малый обмен между ними. Каждая формула применима, пока соответствующая очередь устойчива.
При редких запросах intra-op выигрывает за счёт быстрого вычисления. По мере роста потока inter-op может выиграть за счёт очереди. Очень строгий TTFT снова делает скорость отдельного запроса критичной. У decode свой баланс: размер батча, память под кэш и требование к TPOT. Правила «prefill всегда так, decode всегда иначе» здесь нет.
Но реальные промпты и ответы разной длины, а сервису нужна заданная доля запросов в SLO. Одной формулы среднего недостаточно.
Поэтому дальше ребята переходят к симуляции нагрузки. DistServe использует модель времени вычислений и профиль запросов: интенсивность поступления, распределения длин входа и выхода. Перебирает допустимые конфигурации параллелизма и размещения, а бинарным поиском находит поток, при котором ещё соблюдается целевой SLO attainment. Затем подбирает число экземпляров стадий под требуемую нагрузку. При медленной сети варианты prefill и decode приходится выбирать совместно.
Получается баланс для конкретной модели, железа, нагрузки и SLO. Когда профиль меняется, расчёт надо повторять. Формулы объясняют механизм, симулятор помогает выбрать конфигурацию; проверка на настоящем кластере остаётся необходимой.
В продолжении рассмотрении этой темы дальше я планирую прочитать несколько статей и потрогать llm-d. План примерно такой
- Splitwise, ISCA 2024 — соседняя работа про выбор разного железа для фаз, стоимость и энергопотребление.
- Sarathi-Serve, OSDI 2024 — другая ветка: дробить prefill на части и совмещать их с decode через планирование батчей.
- Mooncake, FAST 2025 — другой масштаб: распределённый KV-кэш, его хранение и повторное использование становятся центром архитектуры.
А в мае 2025-го llm-d уже предложил объединять disaggregated serving и маршрутизацию с учётом кэша с Kubernetes-инфраструктурой. Так что через эти работы можно пройти путь от разделения двух стадий до управления вычислениями и состоянием всего кластера.
#Research #AI #Architecture #Engineering #DistributedSystems | 1 903 |
| 13 | [/2] DistServe: зачем разделять prefill и decode (Рубрика #Research)
Этот пост посвящен статье DistServe от команды из Peking University, UC San Diego и StepFun, опубликованной на OSDI 2024. Причем в разборе llm-d я уже рассказывал про разделение prefill и decode. А в работе DistServe очень хорошо разобрана инженерная сторона этого решения: что выигрываем, когда разносим стадии по разным GPU, и чем за это платим. Помимо самой статьи есть и открытый код который позволяет не только посмотреть на результаты авторов, но и почитать при желании код.
Если возвращаться к основной теме, то у запроса к LLM есть две довольно разные части:
- Prefill обрабатывает входной текст, вычисляет KV-кэш и первый токен ответа. Позиций много, их можно обрабатывать параллельно; при достаточно длинном промпте стадия обычно упирается в вычислительную мощность.
- Decode выпускает следующие токены по одному на запрос. При небольшом батче вычислений относительно мало, а веса и кэш приходится читать из памяти снова и снова. Здесь ограничением часто становится её пропускная способность. Объединение запросов в батч помогает эффективнее использовать GPU.
Когда обе стадии живут вместе, новый тяжёлый prefill задерживает уже идущую генерацию. Даём приоритет decode — новые пользователи дольше ждут начала ответа. Плюс обеим стадиям достаётся одна конфигурация параллелизма, хотя потребности у них разные.
В DistServe процесс выглядит так: Запрос → очередь prefill → обработка промпта и первый токен → передача KV-кэша → очередь decode → генерация остальных токенов.
У prefill- и decode-экземпляров свои копии весов модели. KV-кэш содержит промежуточные ключи и значения attention: с ними другая GPU продолжает вычисление, не обрабатывая промпт заново. Prefill и decode теперь можно отдельно масштабировать и настраивать.
Дальше начинается знакомая жизнь распределённой системы: появились сеть, дополнительная память и ещё одно место, где может вырасти очередь :)
Для OPT-66B авторы оценивают кэш промпта из 512 токенов примерно в 1,13 ГБ. При 10 запросах/с это около 90 Гбит/с только на кэш. Причём совпадения средней потребности с полосой мало: всплескам нагрузки нужен запас. Если decode принимает работу медленнее prefill, готовые кэши тоже начинают ждать и занимать память.
Поэтому DistServe учитывает топологию. При медленной сети между серверами соответствующие стадии prefill и decode размещаются на разных GPU внутри одного сервера, чтобы передавать кэш по NVLink. В их измерениях более 95% запросов передавали кэш менее чем за 30 мс.
Цель авторов — goodput на GPU: предельный поток запросов при заданной доле соблюдения требований к задержке (SLO). Проверяются TTFT (time to first token) — время до первого токена — и TPOT (time per output token), среднее время на следующий токен. Обычно целевая доля — 90% запросов. Средний TPOT, кстати, ещё не гарантирует отсутствие отдельных пауз в генерации.
Они проверяли свой подход на OPT-13B/66B/175B, кластере из 32 A100 и данных для чата, дополнения кода и суммаризации. В чатовых тестах получили в 2–4,6 раза больший поток на GPU относительно тогдашнего vLLM; максимум 7,4 раза — относительно DeepSpeed-MII. Это выигрыш всей конфигурации при выбранных SLO. Времена поступления запросов синтезировали, а пороги задержки задали сами; переносить множители на произвольный сервис нельзя.
Остаётся самая интересная часть: сколько GPU выделить каждой стадии и как разложить на них модель. Во второй части поста будет рассказ про intra-op, inter-op и теорию очередей, которая помогает понять, почему самый быстрый отдельный запрос ещё не определяет лучшую конфигурацию сервиса.
#Research #AI #Architecture #Engineering #DistributedSystems | 1 756 |
| 14 | Кстати, выпуск 3 AImigo про джунов стартанул. | 1 750 |
| 15 | Материалы выпуска: первые 90 дней CTO (Рубрика #Leadership)
Собрал материалы сольного выпуска Code of Leadership «Первые 90 дней CTO». Эфир прошёл 9 сентября 2026 года — это расширенная версия доклада, который я рассказывал на мероприятии Стратоплана. Начинаю с того, что первый рабочий день — уже середина перехода. Компания выбрана, ожидания сформированы, о части полномочий вы уже договорились. А о части, возможно, решили поговорить потом. Вот это «потом» и может оказаться самым интересным местом испытательного срока :)
В выпуске разобрал:
- Что скрывается за названием CTO. Главный архитектор, партнёр продукта, руководитель масштабирования и человек, которого зовут разбираться с кризисом, — очень разные работы. Как заранее понять, какая из них нужна компании, и проследить связь технологий с деньгами бизнеса.
- О чём договориться до выхода. Какого результата ждут через 30 и 90 дней, что вы можете менять самостоятельно, какие есть бюджет и кадровые полномочия, кто поддерживает изменения. Это важно и при внутреннем повышении: знакомая компания не делает договорённости очевидными.
- Как провести первый месяц. С кем поговорить, на какие рабочие процессы посмотреть и как отделять факты от чужих интерпретаций. Фраза «в прошлой компании мы делали так» легко мешает увидеть, что здесь устроено иначе. При этом срочные угрозы безопасности и непрерывности бизнеса не ждут конца диагностики.
- Что выбрать на дни 30–90. Одно-два изменения с понятной болью, владельцем и наблюдаемым результатом. Как проверить гипотезу в пределах испытательного срока, заработать доверие и не замкнуть все решения на себе.
- Что делать, если обещания разошлись с реальностью. Мандат сузился, бюджет не появился, поддержка исчезла. Как назвать расхождение, зафиксировать его и поставить срок для новой договорённости, пока ответственность ещё можно привести в соответствие с полномочиями.
Моя рамка здесь — испытательный срок проходит и компания. Она тоже проверяется: можно ли в ней решить ту задачу, ради которой вас нанимали.
Материалы выпуска:
📌 Страница выпуска с таймкодами и слайды доклада
📖 Лонгрид о переходе в роль CTO
🎬 YouTube, VK Видео
🎧 Podster, Яндекс Музыка, Apple Podcasts
📝 Конспект эфира
Какая договорённость при выходе на руководящую роль у вас оказалась самой важной — или выяснилось, что её стоило обсудить заранее? Делитесь в комментариях.
#CodeOfLeadership #Management #Leadership #CTO #Career #Engineering | 1 806 |
| 16 | Randy Shoup про eBay: инженерия ускорилась, а система — нет (Рубрика #Management)
Супер-крутой доклад — прямо много попаданий в реальность. Пока слушал, то и дело ловил дежавю. И у этой истории есть первый акт: в 2023 году я уже разбирал, как Randy Shoup с командой удвоил engineering productivity в eBay. Новый доклад — неприятный второй акт. Техническая трансформация сработала, а траектория бизнеса и культура руководящего слоя, по оценке Шоупа, почти не изменились.
Шоуп был Chief Architect и VP of Platform Engineering в eBay в 2020–2022 годах. По его данным, инициатива Velocity дала 2× по числу features и bug fixes на единицу времени. Deployment frequency выросла в 10 раз, lead time сократился с 10 до 2 дней, change failure rate и time to recover улучшились втрое. Это цифры из доклада и слайдов, а не независимый аудит. Но масштаб всё равно впечатляет: около 5000 инженеров в компании; Velocity со временем охватила 400 продуктовых команд и 4500 приложений и сервисов.
Секретного фреймворка не было. Команды спрашивали: если завтра придётся выкатываться ежедневно, что именно вам помешает? Ответы становились бэклогом Platform Engineering. Дальше — сокращение build, test и PR validation time, автоматизация deployment и обновлений, общая staging-среда, DORA как outcome-метрики и developer friction как входной сигнал.
Но важнее инструментов была механика взаимодействия. Сильных IC из платформы встраивали в продуктовые команды, руководители синхронизировались ежедневно, команды делились локальными автоматизациями, а Security, Compliance, Accessibility и Localization переставали быть внешними «воротами» и становились участниками улучшения потока. Начали с пилотов, затем расширялись квартальными когортами и повторяли цикл: нашли bottleneck, сняли, посмотрели, кто теперь получил повышение.
А затем Шоуп задаёт неприятный вопрос: если инженерная продуктивность выросла вдвое, почему это не развернуло бизнес? Его ответ состоит из трёх слоёв.
1️⃣ Стратегия и планирование
Годовой план собирался централизованно и надолго. Работа получала деньги, только если была достаточно большой для executive-level инициативы; небольшие изменения выживали как «прицеп» к гигантским программам. Новые знания появлялись, а курс уже нельзя было менять.
2️⃣ Execution
Нормой оставались релизы на десятки команд и годы работы. Вознаграждалось выполнение обещанного списка, а не изменение клиентской или бизнес-метрики. То есть feature factory стала выпускать больше features — ровно как и было заказано.
3️⃣ Культура
Используя типологию Ron Westrum, Шоуп описывает её как pathological: страх ошибок, поиск виноватого, zero-sum борьба руководителей за scope и headcount, Not Invented Here. В такой системе осторожность — не дефект отдельных людей, а рациональная стратегия выживания. Вот здесь дежавю становится особенно сильным. Ускорить CI/CD политически проще, чем изменить бюджетный процесс, права на решения и систему стимулов. Можно дать командам прекрасную дорогу, но если маршрут определён 18 месяцев назад, они просто быстрее приедут не туда.
В ретроспективе Шоуп считает, что поддержки CEO сверху и энтузиазма команд снизу оказалось недостаточно: трансформации нужен ещё middle-out — союз с peer-руководителями, чьи границы и стимулы она неизбежно затрагивает. Его рассказ об увольнении и культуре — личная версия событий, не независимое расследование. Но именно поэтому доклад хорош: автор не продаёт очередной transformation playbook, а честно показывает предел уже успешного.
И да, в 2026 году невозможно не увидеть продолжение про AI. Если агенты ускорят производство кода, но не выбор задач, обратную связь и принятие решений, feature factory просто получит двигатель помощнее. Поэтому до вопроса «насколько мы ускорились?» стоит задать другой: «а инженерная скорость вообще ограничивает результат всей системы?»
#Management #Leadership #Culture #DevOps #PlatformEngineering #Engineering #Metrics | 1 921 |
| 17 | AI4SDLC на ИТ-Пикнике: материалы выступления (Рубрика #AI4SDLC)
Собрал материалы моего выступления на ИТ-Пикнике 8 августа — «State of AI4SDLC: AI сдвигает узкие места разработки». Это было моё последнее выступление от имени Т-Банка. В нём я подвёл итог AI4SDLC в том виде, в котором развивал это направление: с исследованием, инженерной платформой, агентами и перестройкой работы команд.
В докладе разбираю, что происходит после того, как код научились писать быстрее. Задачи начинают скапливаться на ревью и тестировании, а дальше выясняется, что ограничением стали постановка и приёмка результата. Выдать всем AI-инструменты — только начало работы. Отсюда и остальные темы: зачем снова нужны спецификации, как подготовить внутреннюю платформу к работе агентов, почему стоит измерять ожидание, переделки, качество и стоимость. И как меняется работа инженера, который всё больше формулирует задачи, собирает контекст и проверяет сделанное агентами.
Материалы можно открыть в удобном формате:
— Слайды
— Видео выступления
— Конспект и сокращённая расшифровка — около 7 минут чтения, подготовлены по субтитрам и слайдам.
#AI4SDLC #Agents #PlatformEngineering #Conference | 2 160 |
| 18 | ArchDays в эпоху AI (Рубрика #Architecture)
Я в программном комитете ArchDays с 2019 года, с основания конференции. Мне кажется, в эпоху AI такие встречи особенно важны. Когда AI пишет код, вопросы к архитектору только прибавляются. Как поставить задачу, чтобы результат можно было проверить? Где нужны ревью и участие человека? Кто отвечает за решение, которое предложил агент? Быстрее получить код — еще не значит быстрее получить работающую систему.
Поэтому для меня архитектурная конференция сегодня — это возможность не просто узнать про новые технологии, но и разобраться в редизайне инженерных процессов: от требований и экспериментов до проверки изменений и эксплуатации. А еще — понять, как меняется профессия архитектора. Думаю, все больше внимания придется уделять тому, как люди и AI вместе принимают решения и проверяют их последствия. Здесь полезно сравнить опыт команд, обсудить ошибки и поспорить с коллегами.
ArchDays — 27 ноября 2026.
Приходите обсуждать.
P.S.
Я хотел по традиции выступить на этой конфе, но я буду уже не в Москве, а она полностью в оффлайне. Но думаю, что мы с Сережей Барановым придумаем как мне рассказать свой доклад может быть не в рамках конфы, а в виде отдельного онлайн эфира на youtube канале Archdays.
#AI #Engineering #Conference | 2 116 |
| 19 | Материалы выпуска: продуктовый инженер — разговор с Глебом Михеевым (Рубрика #Leadership)
Собрал материалы разговора с Глебом Михеевым, CPO ГигаАгента в Сбере. Эфир Code of Leadership прошёл 8 сентября 2026 года. Говорили о том, что происходит с работой инженера, когда можно быстро получить несколько работающих реализаций — и всё равно остаётся вопрос, какую из них вообще стоило делать.
Глеб рассказал, как на полгода вернулся из менеджмента в индивидуальную инженерную роль и каждый день работал с агентами. Из этого опыта вырос разговор о продуктовой ответственности, устройстве команд и обучении.
Обсудили:
- Продуктового инженера. Понять проблему пользователя, предложить решение, выпустить его и собрать обратную связь. Как дать человеку такую ответственность и не навесить на него несколько прежних должностей с прежней нагрузкой.
- Очередь после ускорения. В разговоре есть хороший мысленный пример: если разработка ускорилась в пять раз, нижние четыре пятых старого бэклога от этого полезнее не стали. Дальше упираемся в выбор гипотез, проверку результата и эксплуатацию.
- Размер команды и границы специализации. Глеб считает, что агенты позволят небольшим командам закрывать больше работы. Но для платёжных и других критичных систем он делает оговорку: там цена ошибки требует более строгой проверки и сохранения специализации.
- Рост джунов. Готовый pull request уже мало говорит о том, чему человек научился. Как проверить, что он может объяснить устройство решения, заметить ошибку и разобраться, если условия задачи изменились.
- Переучивание опытных разработчиков. Как перестроить привычку делать всё руками, сохранить инженерное суждение и не застрять в бесконечном цикле «ещё одну задачу агенту — и спать».
Материалы выпуска:
📌 Страница выпуска с таймкодами
🎬 YouTube, VK Видео
🎧 Podster, Яндекс Музыка, Apple Podcasts
📝 Текстовый конспект
#CodeOfLeadership #AI4SDLC #Engineering #Product #Leadership #Career | 2 135 |
| 20 |  Stanford MS&E435: от мегаватта до молекулы — весь курс в девяти разборах (Рубрика #AI)
С курсом Stanford MS&E435 «Economics of the AI Supercycle» в канале всё: девять лекций — девять разборов, от экономики GPU и строительства дата-центров до кодинговых агентов и разработки лекарств. Курс интересен тем, что не пытается выбрать «лучшую модель», а рассматривает AI как большую производственную и экономическую систему. На каждом слое повторяются одни и те же вопросы: где сейчас бутылочное горлышко, кто оплачивает капитальные затраты, что становится commodity, а у кого остаются влияние на цены, данные и замкнутый цикл обратной связи.
Если сложить лекции вместе, бутылочное горлышко всё время переезжает: из чипов — в электричество и готовые дата-центры, затем в корпоративный контекст, человеческое внимание, evals, дистрибуцию и лабораторный эксперимент. Вместе с ним перемещается и граница между тем, что компания может купить как услугу, и тем, что ей приходится контролировать самой.
Все разборы по порядку:
1️⃣ Экономика AI-суперцикла — вводная лекция интересна картой всего стека chips → infrastructure → models → applications и вопросом, почему основная экономика пока сосредоточена внизу.
2️⃣ Inference как производственная система — разговор с Sunny Madra и Brad Gerstner показывает, почему prefill и decode могут требовать разного железа, а считать полезнее стоимость проверенного результата, а не число сожжённых токенов.
3️⃣ Дефицитный мегаватт AI-фабрики — Чейз Локмиллер из Crusoe опускает «облачный AI» на землю: к подстанциям, охлаждению, стройке и дефициту площадок, где GPU вообще можно включить.
4️⃣ Али Годси: AGI уже здесь, а компания — ещё нет — лекция интересна кейсом Databricks, в котором заметный рост throughput появился после перепроектирования процесса, а не после замены модели.
5️⃣ Sachin Katti и человек как bottleneck AI-системы — взгляд оператора frontier-лаборатории связывает динамические агентные нагрузки, гетерогенную инфраструктуру и цену человеческого внимания, проверки и ответственности.
6️⃣ Yash Patil: внутреннее знание компании как learning loop — здесь корпоративная экспертиза превращается из абстрактного «контекста» в evals, reward, post-training и воспроизводимый цикл обучения.
7️⃣ Кто выбирает технологический стек — разработчик или кодинговый агент? — Guillermo Rauch показывает, как агент становится новым gatekeeper, а open source, документация и агентная эргономика — каналом дистрибуции.
8️⃣ Baseten и как юнит-экономика меняет стратегию — история полезна симметрией: по мере роста приложение забирает под контроль модели, а инфраструктурная платформа — вычислительные мощности.
9️⃣ Chai и Claude: кто заберёт деньги в AI-биотехе? — финальная лекция переносит ту же экономическую рамку в drug discovery, где ценность зависит не от красивой молекулы, а от замкнутого цикла гипотеза → дизайн → эксперимент → данные и прав на результат.
Это не нейтральный учебник: среди гостей инвесторы, основатели и руководители компаний, которые продают ровно те слои стека, о которых рассказывают. Но если отделять механизм от vendor pitch, получается редкая сквозная карта AI — от электронов до молекул.
Если времени на весь плейлист нет, выбирайте слой, за который отвечаете. А если есть — я бы шёл по порядку: так особенно хорошо видно, как дефицит и ценность путешествуют по стеку.
#AI #Engineering #Infrastructure #Product #Strategy #Economics | 2 129 |
