Материалы AMA с подписчиками «Книжного куба» (Рубрика #AI4SDLC)

Готовы материалы с AMA-сессии, которая прошла 23 августа. Вопросов было много, поэтому за полтора часа мы успели пройти путь от выбора следующей книги до ответственности за действия автономного AI-агента. Мы обсудили:

- Как выбирать книги от текущего вопроса и превращать чтение в заметку, схему, эксперимент или решение;
- Как устроены 6D, личная система знаний и переход от материалов к навыкам в System Design Space;
- Зачем нужны пет-проекты и почему короткая петля обратной связи важнее их масштаба;
- Вход в IT, рост лидера, завершение десятилетнего карьерного этапа и следующий шаг;
- SDD, детерминированные проверки и ответственность за AI-код;
- Экономику агентной разработки и сценарии AGI/ASI — без обещаний даты.

Все материалы выпуска:
- Страница выпуска
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка
- Текст: краткая расшифровка

Спасибо всем за вопросы и живое обсуждение. Если после просмотра появились новые — пишите в комментариях: соберу их для следующей AMA или отдельных постов.

#AI4SDLC #Engineering #Leadership #Career #Architecture #Management

Первые 90 дней CTO начинаются до первого рабочего дня - Менеджмент 360 (Рубрика #Management)

В айтишке есть странная традиция: сначала получаешь новую должность, а потом начинаешь выяснять, на какую именно работу согласился. Для CTO это особенно дорогой способ знакомиться с ролью. Поэтому 3 сентября в 19:35 на «Менеджменте 360» от Стратоплана я буду рассказывать про первые 90 дней технического директора. Начну с небольшого переворота: первый рабочий день — уже середина перехода.

В докладе разберу весь маршрут:

- Как выбирать задачу, а не красивый шилдик;
- Зачем до выхода договориться о полномочиях, ресурсах и критериях успеха;
- Почему первый месяц лучше потратить на сбор реальной карты компании, а не на формирование портфеля изменений;
- Как к 90-му дню выбрать одну-две системные ставки, показать первый результат и не пропустить красные флаги.

Это не универсальный чек-лист «успешного успеха», а практическая модель: исследование → взаимный контракт → диагностика → первые изменения. И ещё: компания в эти три месяца тоже проходит испытательный срок.

«Менеджмент 360» идёт онлайн 1–4 сентября, каждый день с 18:00 до 21:00 GMT+3. Четыре дня — четыре управленческие роли: тимлид, руководитель отдела, CTO и COO. В программе 16 живых эфиров про переход в роль, базовые инструменты, первые 90 дней и типовые грабли; записи останутся у участников.

Среди спикеров — тренеры Стратоплана, COO Welltory, руководители из Yandex Infrastructure и Ozon, основатель Product Heroes.

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

Регистрация бесплатная при подписке на Telegram-каналы спикеров. Есть и платный вариант без подписок — с именным сертификатом и курсами «Менеджмент 101» и «Директор 101».

👉 Регистрация

#Management #Leadership #CTO #Conference

Материалы выпуска «Дата-платформа в 2026 году» (Рубрика #Data)

Готовы материалы 28-го выпуска Research Insights Made Simple, который вышел 24 августа. Вместе с Николаем Головым и Александром Филатовым из Tengri Data мы прошли путь от границы между OLTP и OLAP до прав, изоляции и проверки запросов AI-агентов.

Обсудили:
- Как по реальной нагрузке понять, когда операционная СУБД перестаёт справляться с аналитикой;
- Где упирается классическое MPP-хранилище и что меняет разделение хранения и вычислений;
- Из чего на практике складывается Lakehouse на S3 и Iceberg: каталог, вычислитель, права, кэш, уплотнение мелких файлов и эксплуатация распределённых компонентов;
- Почему переход с Vertica на Trino, Iceberg и S3 занимает годы и какой длинный хвост создают унаследованные расчёты и хранимые процедуры;
- Чему год разработки, пилотов и продаж научил Tengri Data: технологию платформы нужно связывать с измеримым результатом для бизнеса;
- Почему AI-агенту мало доступа к SQL — нужны семантический слой, детерминированные проверки, строгие права и изоляция нагрузки.

Все материалы выпуска:
- Страница выпуска
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: краткая расшифровка

Если после просмотра останутся вопросы — пишите в комментариях. Соберу их для продолжения темы дата-платформ: здесь ещё есть куда копать.

#Data #PlatformEngineering #Architecture #Database #AI4SDLC #Engineering

Почему удачный POC (proof of concept) AI продукта ещё не готов к production (Рубрика #AI4SDLC)

Посмотрел новый доклад с конфы AI Engineer World’s Fair, который развивает тему FDE (Forward Deploy Engineer). В прошлый раз я разбирал FDE — инженера, который встраивается в команду клиента и доводит AI до работающего процесса. А новый доклад показывает следующий акт этой истории: POC уже работает, а production ещё даже не начинался.

Christopher Lovejoy из Anthropic и Saul Howard, VP Engineering в Anterior, начинают с условного сценария. Два инженера за четыре недели собирают агента для медицинского workflow. Accuracy хорошая, система быстрая и относительно дешёвая. На презентации все довольны: финансы считают бюджет, медицинский директор готов рассказывать коллегам о точности, а продажи уже хотят написать на сайте «Powered by AI».

На следующий день в комнате появляются другие вопросы. Где полный audit trail? Как перемещаются медицинские данные? Кто подтверждает спорное решение? Может ли недоверенный документ управлять моделью? Как проверять качество после релиза? И красивый POC останавливается: он оптимизирован под правильный ответ, но не под доказуемость каждого действия.

Спикеры предлагают поменять порядок: сначала сделать production-ограничения несущей конструкцией, а уже потом возвращать точность прототипа. Для этого нужны три примитива:

1️⃣ Append-only журнал событий — единая история действий, доступов и авторизаций. Он помогает воспроизводить состояние и строить аудит, но у компромисса есть цена: записывать легко, читать сложнее, нужны projections и snapshots;
2️⃣ Schema-driven object storage для самих медицинских данных. В журнале остаются ссылки, доступ выдаётся в момент использования, а инженер может отлаживать путь агента, не видя PHI;
3️⃣ Единый контракт действий для LLM и человека. Любой шаг можно передать человеку посреди workflow, а общий контекст отобразить либо как prompt, либо как UI. Речь об одинаковом интерфейсе, а не об одинаковых полномочиях.

Из этой основы, по мнению авторов, получаются и evals: можно повторно проигрывать тот же эпизод с другим prompt, моделью или кодом, сравнивать действие агента с человеческим и запускать проверку на production data внутри контура клиента. И мне здесь нравится именно порядок мышления. Если audit, границы данных и human approval появляются в плане «после успешного POC», архитектура уже опоздала. В регулируемой системе это не ворота перед релизом, а сама модель данных и исполнения.

#AI4SDLC #AI #Agents #Architecture #DevSecOps #Evals #Engineering

Research Insights Made Simple #29 про «The AI-Native SDLC playbook» с Антоном Костериным (Рубрика #AI4SDLC)

Кодинговые агенты уже пишут код гораздо быстрее. Но если планирование, архитектурное ревью, безопасность, тестирование и деплой остаются на «человеческой скорости», ускоряется ли delivery — или очередь просто переезжает в соседний этап?

27 августа в 14:00 в прямом эфире Research Insights Made Simple вместе с Антоном Костериным, principal engineer RnD-центра Т-Банка, разберём свежий материал Anthropic — The AI-Native SDLC playbook. С Антоном мы уже говорили об architecture governance, RFC/ADR и архитектурных ревью. Теперь вопрос шире: как перестроить под агентов не только написание кода, но весь SDLC.

Тезис playbook: после ускорения Build bottleneck смещается в Plan, Test/Review и Deploy. Anthropic предлагает замкнуть шесть стадий, от Plan до Maintain, в цикл. intent.md, spec.md, plan.md, diff с тестами, результаты review и записи об инцидентах образуют цепочку версионируемых артефактов и одновременно audit trail. Человек остаётся ответственным, но подключается в точках, где действительно требуется суждение.

Обсудим:

- Действительно ли код перестал быть узким местом и где теперь скапливается очередь;
- Зачем нужны markdown-артефакты, если уже есть Jira, wiki и архитектурные процессы;
- Как превратить знания компании в CLAUDE.md, skills и проверяемые политики, не законсервировав ошибки;
- Как связать continuous evals, hooks, агентное и человеческое review с production monitoring;
- С какого участка SDLC начинать и какими метриками доказывать эффект.

Это практическое руководство команды Claude, а не исследование со сравнительным экспериментом. Поэтому отдельно проверим, где здесь переносимый инженерный подход, а где пока видение поставщика — особенно для большой регулируемой организации.

Подключайтесь 27 августа в 14:00 и приносите свои кейсы и вопросы. Особенно если coding agents уже ускорились, а delivery почему-то нет.

#AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research

Материалы выпуска с Сергеем Бережным: что остаётся дефицитным, когда код становится дешёвым? (Рубрика #Management)

Готовы материалы очередного выпуска Code of Leadership S2E14, который прошёл 24 августа. Вместе с Сергеем Бережным — директором по взаимодействию с разработчиками Яндекса, CTO Яндекс Практикума и соавтором БЭМ — разбирали, что становится узким местом, когда сам код генерировать всё легче.

Обсудили:

- Как БЭМ вырос из внутреннего решения для большой фронтенд-разработки в методологию, инструменты и инженерную экосистему;
- Как митапы, DevRel и open source помогают распространять технологии — и почему публичность приносит не только охват, но и ответственность;
- Как устроена матрица продукта и технологии: продуктовые задачи меняются быстро, а профессиональная специализация живёт дольше;
- Как лидеры уровня Staff+ проводят поперечные изменения через стандарты и договорённости, не имея прямого административного мандата;
- Почему AI даёт системный эффект после перепроектирования рабочего цикла, а не просто ускорения прежних тикетов;
- Что, по итогам разговора, остаётся дефицитным при дешёвом коде и контенте: постановка задачи, инженерное суждение, критическая проверка, фокус, обратная связь, доверие и ответственность за результат.

Все материалы выпуска:

- Страница выпуска
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: краткая расшифровка

Спасибо Сергею за разговор. Если после просмотра появятся вопросы — пишите в комментариях: соберу их для продолжения темы о техническом лидерстве в эпоху AI.

#Management #Leadership #Engineering #AI4SDLC #OpenSource #Education

Bassem Dghaidi: «Simple is complicated enough» — system design без театра овер-инженерии (Рубрика #Architecture)

Почти любой разговор о разработке сейчас довольно быстро съезжает к моделям, агентам и процентам сгенерированного кода. Поэтому эта 46-минутная беседа на Beyond Coding особенно хороша: AI появляется только в последней четверти. До него — спокойный инженерный разговор о system design, вертикальном масштабировании, цене абстракций и ответственности перед бизнесом. Очень уместный контрапункт общему AI-хайпу.

В гостях у Patrick Akil — Bassem Dghaidi, senior software engineer в GitHub, работающий над GitHub Actions. У него больше 15 лет опыта в разных доменах: от банков и контейнерных терминалов до интернет-сервисов. В разговоре он опирается на конкретные задачи — перестройку частей GitHub Actions, инфраструктуру терминала и системы для банков, — поэтому «масштаб» здесь не упражнение у доски.

Основной тезис Dghaidi: system design — не конкурс на самое большое количество модных коробочек. Систему стоит проектировать на следующий порядок величины, а не на воображаемые 100x, и только после того, как данные показали предел текущего решения. ПО не строят один раз — оно постоянно развивается, поэтому архитектура требует регулярных инвестиций, а не одной попытки угадать устройство системы на десять лет вперёд.

Из разговора я бы забрал четыре мысли.

1️⃣ Масштабирование начинается с измерений
По словам Dghaidi, некоторые сервисы GitHub обрабатывают миллионы запросов в секунду всего на пяти-шести контейнерах. Это внутренний пример спикера, не независимый бенчмарк. Сам контекст перестройки позже описал GitHub: старое ядро Actions обслуживало 23 млн jobs в день, новую архитектуру проектировали с запасом 10x, а к декабрю 2025 года она держала 71 млн jobs в день. Принцип тот же: сначала реальная кривая нагрузки, потом распределённая сложность.

2️⃣ Конкретное решение полезнее универсального фреймворка
Кеш, NoSQL или новая абстракция появляются, когда есть конкретное узкое место. Иначе невозможно осмысленно выбрать компромиссы: универсальная конструкция оптимизируется сразу для всех гипотетических задач — и ни для одной реальной.

3️⃣ Архитектуру надо объяснять в единицах, что понятны бизнесу
На контейнерном терминале, который вспоминает Dghaidi, задержка означала деньги и иногда риск для людей, а не просто красный график времени ответа. Его совет инженерам: переводить «база данных перегружена» в стоимость простоя, окно разгрузки, скорость поставки фичи и риск для клиента. Самый красивый Kubernetes-кластер ничего не доказывает, пока не показан измеримый эффект для бизнеса.

4️⃣ AI меняет рычаг, но не задачу инженера
Dghaidi утверждает, что агенты пишут около 90% его кода. В одном кейсе агент за 20 минут собрал и прогнал три бенчмарка для разных ключей Redis — вручную это, по его оценке, заняло бы два-три дня. Освободившееся внимание он тратит на паттерны доступа к данным, надёжность, эксплуатацию и последствия ошибки. Его аналогия с автоматическим сцеплением на мотоцикле здесь точная: переключать передачи стало проще, но дорогу, скорость и допустимый риск всё ещё выбирает человек.

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

В эпоху, когда заголовки соревнуются в том, какая модель написала больше кода, здесь задают менее эффектные вопросы: какой предел мы измерили, какой риск уменьшаем, кто будет эксплуатировать решение и что изменится для бизнеса. AI из разговора не исчезает — он просто возвращается на своё место: мощный инструмент внутри инженерной системы, а не замена system design.

#Architecture #SystemDesign #Engineering #Software #AI #AI4SDLC

3 AImigo S1E3: Новостной дайджест AI за август (Рубрика #AI)

В пятницу в 12:00 у нас пройдет последний эфир 3 AImigo в этом августе и мы решили проверить новый формат с обсуждением новостей AI за месяц.

Вообще, тема AI развивается очень бурно и событий, что достойны упоминания достаточно много: новые модели и продукты, исследования, заметные кейсы, изменения в подходах команд к разработке с AI. Мы выбрали новости, доклады и тренды, которые показались нам действительно важными, и обсудим не только «что произошло», но и что за этим стоит.

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

Как обычно, разбираемся втроём: Евгений Сергеев, Алексей Литвинов и Саша Поломодов:)

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

#AI #AI4SDLC #Agents #Engineering #Architecture #Management #Metrics #DevEx #Productivity #Software

Research Insights Made Simple #29 про «The AI-Native SDLC playbook» с Антоном Костериным (Рубрика #AI4SDLC)

Через 5 минут стартанет прямой эфир Research Insights Made Simple, где мы вместе с Антоном Костериным, principal engineer RnD-центра Т-Банка, разберём свежий материал Anthropic — The AI-Native SDLC playbook. С Антоном мы уже говорили об architecture governance, RFC/ADR и архитектурных ревью. Теперь вопрос шире: как перестроить под агентов не только написание кода, но весь SDLC.

#AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research

Ищу человека, который подхватит AI4SDLC после меня (Рубрика #AI4SDLC)

31 августа я покидаю Т-Банк. Но задача, которой я занимался, остаётся: менять процессы разработки и вести компанию к AI Native.
Планка здесь высокая. Нужно знать передовые подходы, иметь hands-on опыт, уметь работать со множеством стейкхолдеров — и действительно хотеть изменить к лучшему одну из крупнейших технологических компаний России.

Про текущее состояние AI4SDLC лучше всего расскажет моё выступление на Turbo ML Conf этого года.
Работать предстоит под руководством Игоря Маслова — VP и руководителя департамента платформенной инженерии всей компании.
Если вы читаете это и думаете «кажется, это про меня», напишите мне в личку (или сразу @kovalevatin). А если знаете подходящего человека — пожалуйста, перешлите ему этот пост.

#AI4SDLC #AI #Engineering #PlatformEngineering #Leadership

Приходите через 5 минут обсудить новости за август - у нас в 3 AImigo пройдет экспериментальный эфир, где мы обсудим интересные истории этого месяца.

Сергей Левин: почему акробатические трюки — плохой тест для робота (Рубрика #Robotics)

В мае я начал рубрику про робототехнику с вопроса: где реальный инженерный прогресс, а где хорошо поставленное демо? Интервью Сергея Левина, опубликованное 24 августа 2026 года, даёт полезный критерий: эффектный бэкфлип иногда говорит о будущем роботов меньше, чем скучная работа с незнакомой чашкой в новой комнате.

Левин — associate professor EECS в UC Berkeley и сооснователь Physical Intelligence. Его основной тезис: робототехника ещё не на стадии GPT-4/5, где рецепт уже найден и остаётся наращивать данные и модель. Отрасль всё ещё выясняет, какое сочетание архитектуры, данных и обучения масштабируется. По его оценке, компоненты уже появились, но вместе они ещё не дают предсказуемого роста. Это взгляд исследователя и одновременно ставка компании, которая строит базовые модели для роботов.

Первый тест здесь — generalization, способность переносить навык в новые условия. Отрепетированный трюк проверяет конкретный навык, а полезный робот должен перенести его на новый предмет, помещение или другую конструкцию машины. По словам Левина, в тесте Physical Intelligence модель разъединила две случайно захваченные футболки и продолжила складывать одну — восстановилась после неожиданности. В другом она не смогла открыть ящик и стала убирать столовые приборы в духовку: не зависла, а выбрала осмысленное, но неверное продолжение. Так выглядит разрыв между впечатляющим поведением и надёжностью.

За переносом стоит правильная программа обучения. Повторение одной сварочной операции научит робота лучше варить, но не сделает его универсальным: нужны разные задачи, среды, предметы и конструкции машин. Причём Левин предлагает не начинать с YouTube. Сначала широкий реальный опыт роботов должен дать модели физическую опору, а уже затем человеческие видео и симуляции могут расширять её знания. Это перспективная исследовательская гипотеза, а не установленный закон отрасли.

Дальше важна модальность промежуточного шага. Язык задаёт последовательность задачи: открыть ящик, взять предмет, убрать его. Изображение или видео показывают следующее состояние сцены — куда нужно переместить руку и что должно измениться. По результатам команды Physical Intelligence, такая визуальная подцель помогает переносить навыки между разными роботами.

Но вся гипотеза упирается в последние проценты. Даже условные 95% успеха означают ошибку в каждой двадцатой попытке. Левин считает, что этот участок потребует обучения с подкреплением на автономно собранном опыте. И здесь важна оговорка: в 13-часовом опыте PI, описанном Левиным и в статье команды, человек примерно раз в пять минут задавал высокоуровневую команду, включая уборку после ошибки. Это длинный прогон, но ещё не полностью автономная смена.

У масштабирования есть и индустриальный слой. Отвечая на вопрос о Китае, Левин не говорит в терминах победитель/проигравший. Его урок в другом: модели не взлетают отдельно от производства, цепочек поставок, открытых разработок и доступного качественного железа. Масштабирование Physical AI — это вся система вокруг обучения модели.

Прогноз у Левина осторожно оптимистичный: структурированные применения могут появляться уже сейчас, среды вроде дома — через несколько лет, вероятно раньше чем через десять лет. Но это прогноз, не план. И раздел про безопасность в интервью заметно слабее технической части: Левин предлагает выводить системы в мир, наблюдать и корректировать подход. Это не заменяет проверки, ограничения и доказательство готовности, о которых я недавно писал на примере Waymo.

Эту запись стоит смотреть как инструкцию к следующему рободемо. Новый ли перед роботом предмет? Работает ли он в другой комнате? Как часто вмешивается оператор? Умеет ли система восстановиться после ошибки — и превратить её в данные? Именно эти вопросы стоит держать в голове, когда гуманоид снова красиво сделает бэкфлип.

#Robotics #AI #Engineering #Research #Architecture

Материалы выпуска с Антоном Костериным: как замкнуть AI-native SDLC? (Рубрика #AI4SDLC)

Готовы материалы 29-го выпуска Research Insights Made Simple, который прошёл 27 августа. Вместе с Антоном Костериным — principal engineer RnD-центра Т-Банка — разбирали "The AI-Native SDLC Playbook" от Anthropic: что должно измениться вокруг кодинга, чтобы скорость агентов превратилась в скорость поставки.

Обсудили:
- Почему playbook ценен не принципиально новыми практиками, а тем, что собирает их в последовательность с примерами и шаблонами, — и почему это руководство поставщика нужно проверять в собственном контексте;
- Как intent.md, spec.md и проверенный человеком plan.md превращают замысел в версионируемую цепочку артефактов и одновременно audit trail;
- Зачем команде CLAUDE.md, skills, команды, hooks и специализированные агенты — и каких начальных вложений и организационного доверия требует такой контур;
- Почему после ускорения Build ограничение переезжает в постановку, review, тесты или выпуск, а детерминированные проверки в CI/CD и continuous evals должны независимо ловить нарушения и повторные ошибки;
- Где проходит граница автоматизации: hooks закрепляют проверяемые запреты, но review, инженерное суждение и принятие остаточного риска остаются за человеком;
- Как Maintain замыкает цикл: инцидент может породить новый intent, а runbook — превратиться в ограниченный политиками агентный self-healing; экономику при этом полезнее считать по принятым задачам и предотвращённым переделкам, а не только по токенам.

Все материалы выпуска:

- Страница выпуска и слайды
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: краткая расшифровка

Спасибо Антону за разговор. Если после просмотра появятся вопросы — пишите в комментариях: соберу их для продолжения темы о том, как переносить AI-native практики в большие инженерные организации.

#AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research