Книжный куб
Open in Telegram
Канал Александра Поломодова (@apolomodov), cto & technical fellow. https://polomodov.tech - сайт со всеми материалами youtube.com/@tellmeabouttech - канал со всеми видео
Show more📈 Analytical overview of Telegram channel Книжный куб
Channel Книжный куб (@book_cube) in the Russian language segment is an active participant. Currently, the community unites 15 752 subscribers, ranking 2 336 in the Books category and 41 358 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 15 752 subscribers.
According to the latest data from 16 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 1 053 over the last 30 days and by 2 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 16.63%. Within the first 24 hours after publication, content typically collects 10.47% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 620 views. Within the first day, a publication typically gains 1 650 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 21.
- Thematic interests: Content is focused on key topics such as engineering, native, devex, devops, leadership.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Канал Александра Поломодова (@apolomodov), cto & technical fellow.
https://polomodov.tech - сайт со всеми материалами
youtube.com/@tellmeabouttech - канал со всеми видео”
Thanks to the high frequency of updates (latest data received on 17 September, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Books category.
15 752
Subscribers
+224 hours
+187 days
+1 05330 days
Data loading in progress...
Similar Channels
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
September '26
September '26
+234
in 4 channels
August '26
+1 165
in 5 channels
Get PRO
July '26
+355
in 7 channels
Get PRO
June '26
+349
in 3 channels
Get PRO
May '26
+212
in 2 channels
Get PRO
April '26
+2 210
in 6 channels
Get PRO
March '26
+542
in 5 channels
Get PRO
February '26
+676
in 6 channels
Get PRO
January '26
+284
in 5 channels
Get PRO
December '25
+198
in 4 channels
Get PRO
November '25
+252
in 4 channels
Get PRO
October '25
+249
in 5 channels
Get PRO
September '25
+201
in 8 channels
Get PRO
August '25
+408
in 4 channels
Get PRO
July '25
+355
in 8 channels
Get PRO
June '25
+314
in 6 channels
Get PRO
May '25
+216
in 3 channels
Get PRO
April '25
+199
in 7 channels
Get PRO
March '25
+419
in 5 channels
Get PRO
February '25
+272
in 2 channels
Get PRO
January '25
+281
in 3 channels
Get PRO
December '24
+368
in 6 channels
Get PRO
November '24
+515
in 6 channels
Get PRO
October '24
+607
in 4 channels
Get PRO
September '24
+569
in 0 channels
Get PRO
August '24
+359
in 2 channels
Get PRO
July '24
+320
in 1 channels
Get PRO
June '24
+429
in 6 channels
Get PRO
May '24
+383
in 0 channels
Get PRO
April '24
+449
in 1 channels
Get PRO
March '24
+360
in 2 channels
Get PRO
February '24
+353
in 1 channels
Get PRO
January '24
+533
in 5 channels
Get PRO
December '23
+561
in 3 channels
Get PRO
November '23
+442
in 3 channels
Get PRO
October '23
+406
in 3 channels
Get PRO
September '23
+566
in 0 channels
Get PRO
August '23
+446
in 0 channels
Get PRO
July '23
+333
in 0 channels
Get PRO
June '23
+234
in 0 channels
Get PRO
May '23
+228
in 0 channels
Get PRO
April '23
+214
in 0 channels
Get PRO
March '23
+224
in 0 channels
Get PRO
February '23
+173
in 0 channels
Get PRO
January '23
+227
in 0 channels
Get PRO
December '22
+142
in 0 channels
Get PRO
November '22
+242
in 0 channels
Get PRO
October '22
+181
in 0 channels
Get PRO
September '22
+126
in 0 channels
Get PRO
August '22
+62
in 0 channels
Get PRO
July '22
+82
in 0 channels
Get PRO
June '22
+176
in 0 channels
Get PRO
May '22
+64
in 0 channels
Get PRO
April '22
+36
in 0 channels
Get PRO
March '22
+275
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 17 September | 0 | |||
| 16 September | +10 | |||
| 15 September | +9 | |||
| 14 September | +12 | |||
| 13 September | +18 | |||
| 12 September | +9 | |||
| 11 September | +14 | |||
| 10 September | +7 | |||
| 09 September | +5 | |||
| 08 September | +10 | |||
| 07 September | +5 | |||
| 06 September | +6 | |||
| 05 September | +8 | |||
| 04 September | +8 | |||
| 03 September | +33 | |||
| 02 September | +19 | |||
| 01 September | +61 |
Channel Posts
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 |
