State of AI4SDLC, или Как меняется индустрия разработки под влиянием AI - мое выступление на DotNext в этом году (Рубрика #AI4SDLC)

Видимо, крайней моей российской конференцией до отъезда в Лондон будет DotNext в Москве 25 сентября. Там у меня будет keynote доклад про состояние дел в AI4SDLC, где я расскажу и про исследования и про свой путь с AI4SDLC в бигтехе, поделюсь мыслями про влияние этих инструментов на продуктивность, а также сделаю прогнозы на будущее в этой теме. В общем, обещаю, что я постараюсь сделать этот доклад максимально крутым и полезным, так как хз когда я вернусь на сцены больших конференций в следующий раз. Если вы будете на конференции, то заходите послушать, позадавать вопросы и пообщаться после доклада - обычно я еще часами отвечаю на вопросы в зоне Q&A.

Ну и спасибо организотрам jug.ru, которые предоставили мне такую площадку. Кстати, этой теме про изменение разработки и мира Java будет посвящен Joker, что пройдет 14 и 15 октября - рекомендую конфу к посещению. Возможно, я тоже туда доеду, так как меня позвали заглянуть в гости и для этого мне даже не надо делать доклад:)

#AI4SDLC #Engineering #Conference #Software

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

Данила Штань: AI не отменяет фундамент и инженерную ответственность (Рубрика #AI4SDLC)

Посмотрел выпуск Beyond Coding с CTO Nebius Данилой Штанем. В заголовке обещают рассказ о навыках, с которыми берут на работу, но для меня разговор оказался шире: найм, устройство инженерной организации и подход к доверию AI-коду у Штаня сходятся в одном принципе — автономность не убирает контроль, а переносит его ближе к тому, кто принимает решение и отвечает за последствия.

Интересно, что в 2021 году на Highload++ я как раз рассказывал доклад о том, как меняется эта роль при росте организации. Ответ Штаня вполне определённый: техническая глубина остаётся, но по мере роста организации CTO прежде всего строит команду, отвечает за результат, разрешает конфликты инженерии с бизнесом и управляет ожиданиями. Обещание важно не только выполнить — отклонение нужно показать до того, как оно стало сюрпризом для чужого плана.

С инженерными навыками похожая картина. По словам Штаня, для многих задач AI-облака не обязателен опыт именно в AI: нужны инженеры по распределённым системам, драйверам, сети, низкоуровневому хранению, GPU-ядрам и оптимизации инференса. Это хорошо рифмуется с недавним разбором vLLM и PagedAttention: проблему управления памятью KV-кеша решили с помощью классической идеи виртуальной памяти.

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

Организационно тот же принцип выглядит жёстче. По описанию Штаня, у инженерных команд Nebius нет отдельного архитектора и архитектурного комитета: команда сама проектирует систему, запускает её, дежурит и отвечает за сервис. Свобода решения оплачивается эксплуатационной ответственностью. Иначе автономность быстро превращается в локальную оптимизацию за чужой счёт. Интересно, что я примерно всю дорогу пропагандировал такой подход в Т-Банке, когда отвечал за архитектурную функцию, хотя мне часто ставили в укор то, что у нас нет департамента корпоративной архитектуры как в Сбере (хотя к концу моей работы в Т-Банке внутри некоторых крупных блоков появились свои отделы корпоративных архитекторов, но это инициатива на местах:))

С AI-агентами Штань проводит похожую границу. Он сравнивает работу с агентом с работой с младшим инженером: у агента нет полного контекста, он предлагает странные идеи и может далеко их развить. По словам Штаня, на момент записи в компании были доступны модели OpenAI и Codex, но не было широкого доступа к Claude Code. Он объяснял это не «запретом AI», а нехваткой защитных правил и наблюдаемости.

Желаемый им протокол для пул-реквеста с участием AI включает отметку об участии агента, сохранение полной траектории сессий, возможность аудита и обсуждение не только кода, но и исходного замысла: где человек направлял модель и спорил с ней. В выпуске это именно целевое состояние, а не уже внедрённая обязательная политика. Владелец изменения в рабочей системе при этом остаётся человеком.

Последние посты про Cursor Cloud Agents, одного агента с файлами вместо сложной обвязки и удаление 80% системного промпта Claude Code складывались в техническую историю: сильной модели всё меньше нужно диктовать каждый шаг, а сложность переезжает в среду, инструменты, состояние и проверки. Штань добавляет организационное продолжение: чем больше свободы получает агент или команда, тем яснее должны быть границы и человеческая ответственность за результат.

Для меня главный вывод: AI удешевляет локальное производство кода, но повышает ценность владения системой. Постановка задачи, понимание ограничений, независимая проверка, эксплуатационный контекст и готовность отвечать за последствия не исчезают. Наоборот, именно они отделяют автономность от бесконтрольности.

#AI4SDLC #AI #Agents #Engineering #Architecture #Management

Я тут подумал, что надо бы устроить ask me anything сессию завтра. Если есть желание у меня что-то спросить, то закидывайте вопросы сюда, а завтра вечером я на них поотвечаю в прямом эфире. Если наберется достаточно вопросов, то эфир случится.

llm-d: как KV-cache стал состоянием всего кластера (Рубрика #AI)

У архитектурных идей бывает два дня рождения: сначала paper показывает, что приём работает, потом кто-то превращает его в систему, которую можно развернуть и сопровождать. Доклад Cong Liu из Google и Maroon Ayoub, работавшего тогда в IBM Research, на PyTorch Conference 2025 — как раз про второй случай. llm-d не изобрёл Prefill/Decode disaggregation. Он пытается сделать из исследовательского паттерна управляемый production stack. Слайды доклада здесь

Это продолжение истории PagedAttention и vLLM, где KV-cache перестал требовать непрерывного куска памяти внутри одного inference engine. Здесь меняется уже единица оптимизации: prefill, decode и сам KV-cache становятся ресурсами всего кластера.
- Prefill обрабатывает prompt целиком, строит KV-cache, упирается прежде всего в вычисления и определяет time to first token
- Decode выпускает токены последовательно, сильнее зависит от пропускной способности памяти и определяет задержку между токенами
- В одном сервере тяжёлый prefill мешает равномерному decode, а обе фазы получают одну конфигурацию железа и parallelism.

llm-d разносит их по разным пулам
- Scheduler выбирает decode worker с учётом prefix cache, занятой памяти и очереди
- Если незакэшированной работы много, отдельно выбирает prefill worker
- Sidecar отправляет туда запрос с max_tokens=1, после чего decode worker забирает рассчитанный KV-cache через NIXL и продолжает генерацию
- Получается интересный сдвиг: маршрутизируется уже не только HTTP-запрос, но и вычисленное состояние модели.

В собственном benchmark команда сравнила одинаковые 16 H200 с InfiniBand: четыре монолитных TP4-реплики против четырёх prefill TP2 и двух decode TP4 на Llama-4 Scout с 5000 входных и 250 выходных токенов. По данным проекта, P/D-вариант дал заметно больше throughput на GPU в средней зоне нагрузки, особенно при 64–128 одновременных запросах. На низкой и предельной нагрузке кривые сближались — универсального множителя здесь нет.

История развивалась так:

- в 2023 году PagedAttention сделал KV-cache эффективнее внутри одного движка;
- в 2024-м Splitwise и DistServe показали, зачем физически разделять prefill и decode, а Mooncake — как строить вокруг KV-cache распределённую архитектуру;
- 20 мая 2025 года запустили llm-d, а в июле v0.2 принесла первые воспроизводимые well-lit paths для P/D, cache-aware routing и wide expert parallelism;
- Доклад 23 октября 2025 года зафиксировал раннюю рабочую систему, где главный вопрос был уже не «можно ли разделить фазы», а «как выбрать P, D и безопасно передать состояние»;
- в 2026-м llm-d вошёл в CNCF Sandbox, вышел за границы обязательного Kubernetes и в v0.8 прямо назвал себя inference control plane. Обещанное в докладе P2P-переиспользование KV-cache стало отдельным well-lit path 15 августа, а 17 августа вышла v0.9.

Самая важная оговорка прозвучала у самих спикеров: P/D подходит не каждому workload. Они советуют начинать эксперименты с моделей порядка 70B+, длинных контекстов вроде 10k input / 1k output и sparse MoE. Текущая документация vLLM всё ещё называет disaggregated prefilling экспериментальной возможностью и прямо предупреждает: само разделение throughput не повышает. Оно позволяет независимо настраивать TTFT и inter-token latency; итоговый выигрыш даёт только вся конфигурация — topology, router, workload и достаточно быстрая сеть.

Поэтому начинать стоитс профиля нагрузки: распределения input/output tokens, concurrency, SLO по TTFT и задержке между токенами, стоимости KV-transfer. Без этих чисел P/D disaggregation может оказаться как хорошей системной оптимизацией, так и дорогим способом отправить несколько гигабайт кэша по сети и вернуть их почти туда же.

#AI #Engineering #Architecture #Software #DistributedSystems #PlatformEngineering

Материалы про то как выстроить собственную систему управления с Михаилом Тюргановым (Рубрика #AI4SDLC)

В начале недели мы с Мишей обсудили его карьерный путь и как меняется CTO, когда небольшая команда вырастает в организацию на тысячи человек? И что делать, если прежние методы сами становятся ограничением? И теперь готовы все материалы по этому прямому эфиру

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

#Management #Leadership #Engineering #Architecture #PlatformEngineering

Code of Leadership S2E13: AMA с подписчиками: чтение, карьера, пет-проекты и AI-разработка (Рубрика #SelfDevelopment)

Вы прислали столько хороших вопросов, что из комментариев получилась программа отдельного эфира.

23 августа в 16:00 МСК выйду в прямой эфир на YouTube и отвечу на вопросы подписчиков «Книжного куба» (в этот раз попробую параллельно стримить на своем VK канале)

Поговорим о том:
- Как я выбираю книги, читаю несколько материалов параллельно и работаю со сложными white papers;
- Как устроен путь от найденного источника до поста, схемы, лонгрида или эфира и нужна ли для этого отдельная база знаний;
- Как превратить знания в навык и куда развивается System Design Space;
- Зачем мне пет-проекты и что AI изменил в greenfield-разработке;
- Что советовать школьникам и джунам и как лидеру перейти на следующий масштаб;
- Чем уход с топ-менеджерской позиции отличается от обычного увольнения и что будет дальше;
- Где проходит граница автономности AI, кто отвечает за AI-код и как считать реальный эффект для компании.

Можно будет задавать дополнительные вопросы в чате трансляции. Запись останется.

#AMA #Engineering #Leadership #Career #AI4SDLC #SystemDesign

Эфир стартовал, если кто-то планировал заглянуть на него, то самое время подключиться. Если кто-то предпочитает vk, то там теперь тоже есть прямой эфир.

Материалы со второго выпуска подкаста "3 AImigo" (Рубрика #AI)

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

Мы обсуждали ее втроём: Евгений Сергеев, Алексей Литвинов и я, а ниже представлены материалы выпуска
- Страничка эпизода
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

P.S.
У Леши есть свой канал в tg @tip_podcast и на Youtube, а у Жени пока нет:)

#AI #Management #Processes #Engineering #Software #AI4SDLC #Software #Agents #Leadership

Omer Primor про CaaS: где заканчивается аренда контекста (Рубрика #AI)

У контекста для агента есть неприятная бухгалтерия. Пока вопрос разовый, AI-поиск выглядит как обычный API: спросили, получили ответ, пошли дальше. Но если каждый день проверять одни и те же компании, вакансии и цены, счётчик запускается заново — даже когда ничего не изменилось. В какой-то момент мы арендуем уже не ответ. Мы арендуем способность системы помнить.

Именно эту границу разбирает Omer Primor из Bright Data в докладе «The Rise of CaaS: Context-as-a-Service for Agentic AI» с AI Engineer World’s Fair 2026. Название похоже на ещё один "-aaS", но вопрос внутри вполне взрослый: когда агенту достаточно покупать контекст, а когда его пора собирать, обновлять и хранить самому? Тема уже появлялась в разборе Hands-On RAG for Production, где retrieval из одного паттерна постепенно вырастал в платформенный слой. Primor добавляет к архитектуре экономику: кто платит за обновление знаний и у кого остаётся накопленный актив.

Его отправная точка — веб не снимок. По показанному в докладе анализу Bright Data, данные социальных сетей могут терять актуальность меньше чем за сутки, а новости, финансовая и retail-информация — в основном за 30 дней. Это внутренний анализ компании, а не универсальный закон. Но сама проблема понятна: один раз найти страницу недостаточно, если агенту важно знать, как менялись цена, вакансии или состав компании.

CaaS в описании Primor больше похож на вертикальный поиск и платформу данных. Такой сервис заранее собирает источники, нормализует и дедуплицирует сущности, связывает их в граф и отдаёт агенту контекст через API, CLI или MCP. Плюс — структура и быстрый старт. Ограничение встроено туда же: если нужного поля нет в модели данных сервиса, агент не сможет выколдовать его запросом.

А дальше частота запросов приводит к огромному счету.

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

Чтобы показать механику, команда Bright Data провела небольшой тест. Карточку из 25 полей проверили на 100 компаниях-спонсорах конференции и сравнили AI-поиск, несколько CaaS и прямой сбор из известных источников. Primor сразу называет это тестом, а не benchmark. Покрытие оказалось близким, но некоторые CaaS уступили поиску на выбранных полях: сервис знает только то, что решил собирать. При этом сам докладчик оговаривает, что у этих платформ могут быть другие данные и преимущества, которые тест просто не измерял. Для собственного варианта команда использовала готовые источники Bright Data и два специально собранных скрейпера. По словам Primor, демонстрационный конвейер занял около дня. Затем он условно оценил полноценную настройку в неделю и $5 000 — при таких допущениях пересечение получилось чуть выше 15 000 сущностей или запросов.

Красивое число, но переносить его в закупочную таблицу я бы не стал. Primor тут же допускает и 10 000, и 30 000, и 100 000: всё зависит от сценария. К тому же он представляет Bright Data, а «самостоятельный» путь собран на инструментах той же компании. За рамкой расчёта остаются поддержка скрейперов, полноценное сопоставление сущностей (entity resolution), контроль качества, юридические ограничения, наблюдаемость и дежурства. Собственный конвейер особенно дёшев на слайде. В жизни первый редизайн сайта-источника быстро добавляет в формулу людей и кофе :)

Поэтому я бы выбирал не по магической отметке 15 000, а по пяти вопросам:
— Как часто повторяется запрос?
— Как быстро устаревают данные?
— Насколько стабильны сущности и схема?
— Сколько стоит неверный или несвежий контекст?
— Во что обходится владение всем конвейером?

Мой базовый вариант здесь — гибрид. Разовые вопросы и неизвестные заранее источники остаются у AI-поиска или CaaS. Частые запросы к понятным сущностям и полям уходят в собственный сбор, нормализованное хранилище и инкрементальные обновления. Внешний поиск остаётся резервом для пробелов, а не обязательным шагом каждого запуска агента. Это та же граница «арендовать — адаптировать — оставить своим», о которой я писал в лонгриде про AI-стек. Только считать здесь полезнее не цену одного запроса, а стоимость принятого результата с нужной свежестью.

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

#AI #Agents #Architecture #Data #PlatformEngineering #FinOps

Research Insights Made Simple #28: дата-платформа в 2026 году — от DWH к Lakehouse и AI-агентам (Рубрика #Data)

Совсем забыл, что сегодня в 16:00 будет эфир про дата-платформы и он будет продолжать тему из шестого выпуска Research Insights Made Simple, где мы с Николаем Головым разбирали, как строить дата-платформы в 2025 году. А 28-м выпуске мы возвращаемся к теме с вопросом посложнее: что происходит, когда аккуратная схема из storage, compute, catalog и orchestration встречается с legacy, стоимостью миграции и реальными аналитическими запросами?

В гостях опять Николай Голов вместе с Александром Филатовым. Николай — директор по продукту Tengri Data, в прошлом руководитель дата-платформ в Avito и ManyChat и преподаватель Harbour.Space. Александр пришёл в DWH из backend-разработки: до этого писал инструменты обработки данных на Python и C++. Почти десять лет он развивал хранилище данных Авито, в 2022–2025 годах занимался переходом с Vertica на Trino/Iceberg/S3, а теперь возглавляет разработку Tengri Data.

Поговорим о том:

- Где проходит граница между OLTP и OLAP, почему аналитика на реплике быстро упирается в потолок и отчего «давайте просто прикрутим ClickHouse» — ещё не архитектура;
- Как профиль чтения и записи меняет устройство системы и почему инженеру важно отличать то, что аналитик просит, от того, что ему действительно нужно;
- Когда классическое MPP-хранилище становится тормозом и что на практике даёт разделение storage и compute в Lakehouse;
- Как переехать на новый стек, не остановив аналитику: параллельные контуры, проверка результатов, стоимость и эксплуатационные риски;
- Что AI-агенты меняют в требованиях к платформе — от метаданных и прав доступа до прозрачности действий и контроля ресурсов;
- Нужна ли в итоге отдельная AI-native дата-платформа или хороший фундамент остаётся тем же.

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

#Data #DataEngineering #Databases #Architecture #PlatformEngineering #AI

Через пару минут стартует прямой эфир с Сережей Бережным из Yandex.

Мы поговорим про карьеру Сергея и обсудим вопросы
- Зачем бизнесу DevRel и чем измерять его результат;
- Почему внутреннюю технологию стоит открывать миру и как выбирать проекты для open source
- Как разработка проходит путь от автодополнения к AI-агентам и harness-системам;
- Что происходит с ролью руководителя, когда частью команды становятся агенты;
- Кого и чему учить, если привычные entry-level задачи всё чаще забирает AI.

#CodeOfLeadership #DevRel #OpenSource #AI #Leadership #Education

Harness Engineering is not Enough: Why Software Factories Fail (Рубрика #AI4SDLC)

Dex Horthy - отличный спикер и я посмотрел его очередной доклад. В предыдущих сериях сооснователь HumanLayer предлагал лечить AI-slop через context engineering и цикл Research → Plan → Implement (доклад "No Vibes Allowed"). А в разборе "The New SDLC" у нас появилась формула Agent = Model + Harness. В новом 19-минутном keynote с AI Engineer World's Fair 2026 Dex ставит к этой формуле важную сноску: хорошая обвязка резко улучшает исполнение, но сама по себе не учит модель сохранять качество архитектуры на длинной дистанции.

Это достаточно интересный и местами отрезвляющий разбор текущего состояния AI-разработки. Но независимым обзором его назвать нельзя. Horthy — сооснователь HumanLayer, компании, которая продаёт AI IDE и инструменты для совместной работы людей и кодинг-агентов. В письменной версии Dex сам предупреждает о возможной предвзятости, а в финале доклада прямо предлагает продукт. То есть перед нами содержательный отчёт практика-провайдера, а не нейтральное исследование рынка. При этом он не сводит метод к своему продукту: для ревью документов прямо называет GitHub, Notion и Plannotator.

Отправная точка — lights-off software factory. Агент пишет код, другие агенты рецензируют изменения и прогоняют regression tests, инциденты и обратная связь пользователей сразу попадают в очередь, а человек перестаёт читать изменения. По рассказу Dex, в июле 2025 года HumanLayer попробовала именно такой режим. Через несколько месяцев команда столкнулась со сложной проблемой, которую агенты не смогли исправить: во время инцидента с недоступностью сайта пришлось разбираться в кодовой базе, за развитием которой люди уже не следили. Это ретроспективный рассказ Horthy о собственной команде без независимых данных, но почти учебный пример потери понимания из моего разбора Loop Engineering.

Почему, по версии Horthy, очередной loop здесь не спасает? На примере SWE-bench Multilingual он показывает test-based оценку: исправлена ли задача, прошли ли новые тесты и не сломались ли старые. По его гипотезе, похожий reward signal не штрафует модель за лишний try/catch, сомнительный cast или shotgun surgery, когда одно изменение расползается по всей системе. Цена плохого program design проявляется через месяцы, а короткий эпизод обучения её просто не видит.

Важно, что Dex честно обозначает границу своего аргумента: доказать деградацию maintainability он не может, потому что хорошего бенчмарка для неё пока нет. Появляются long-horizon evals, а Frontier Code использует multi-PR tasks, но, по его оценке, model-as-a-judge ещё не превращает архитектурное качество в надёжно измеримый сигнал.

Предложение автора — не отказаться от агентов, а «включить свет» и перенести человеческое суждение в начало процесса:

1️⃣ Product requirements: какую проблему решаем, для кого и как поймём, что результат полезен;
2️⃣ System architecture: контракты компонентов, модели данных и ограничения;
3️⃣ Program design: типы, сигнатуры методов, раскладка кода и call graphs;
4️⃣ Vertical slices: порядок реализации и проверяемые сквозные куски вместо огромного горизонтального плана.

Небольшие задачи по-прежнему можно отдавать агенту напрямую. Для крупных Dex предлагает согласовывать решения до реализации, затем читать код и проверять результат по частям. Его практическая оценка — около 30 минут предварительного согласования могут сэкономить часы review; это опыт команды, не результат эксперимента.

И здесь коммерческий интерес снова виден очень хорошо: рецепт явно рифмуется с workflow HumanLayer — Questions → Research → Design → Structure → Plan → Implement. Но полезную границу это не отменяет. Harness помогает агенту лучше выполнить сформулированную задачу; он ещё не заменяет архитектурный вкус, ментальную модель системы и ответственность за то, каким код станет через полгода.

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

Материалы 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