Книжный куб

Code of Leadership S2E15 - Последние 90 дней в компании начинаются до заявления (Рубрика #Management) Часть много говорят о первых 90 днях в новой роли. Мне захотелось разобрать обратную сторону перехода — последние 90 дней в компании. 31 августа в 17:00 проведу сольный эфир Code of Leadership где рассмотрю не только увольнение, но и все три равноправных исхода: остаться в пересобранной роли, перейти внутри компании или уйти. Поговорим о том, как не принять карьерное решение после одной плохой недели; понять, что именно перестало работать; описать следующую роль через ответственность, а не должность; проверить внутренние возможности и внешний рынок; выбрать исход и передать управление так, чтобы старая роль больше не зависела от вашего незримого присутствия. Отдельно разберу важную для руководителей часть: документ не равен переданному знанию. Сначала новому владельцу нужно передать право принимать решения, затем — контекст, отношения, рабочие ритмы и доступы. И дать ему начать управлять ещё до вашего последнего дня. Для меня главный тезис такой: последние 90 дней — это не обратный отсчёт до увольнения. Это управляемый переход между двумя профессиональными главами (если новое место уже выбрано) #Management #Leadership #Engineering #Career

Материалы 3 AImigo S1E3: почему AI дешевеет, а внедрение усложняется? (Рубрика #AI) Готовы материалы третьего выпуска 3 AImigo, который вышел 28 августа. Вместе с Евгением Сергеевым и Алексеем Литвиновым мы впервые сделали совместный новостной дайджест: не прошлись по ленте анонсов, а собрали шесть связанных сюжетов вокруг одного сдвига. Модели и их использование дешевеют, а собрать из них работающую AI-систему становится сложнее. Обсудили: - Почему рост личной продуктивности ещё не равен системному ROI — и как данные McKinsey возвращают разговор от скорости отдельного инженера к перепроектированию всего цикла поставки; - Почему, по нашей оценке, дефицит смещается в данные, интеграции с унаследованными системами и governance; фоном для этого сюжета стали июльская сделка SAP–Dremio и ранние сигналы Reuters о спросе на работу интеграторов; - Как улучшение price-performance расширяет число выгодных AI-сценариев и почему общий расход может расти даже при удешевлении каждого запроса; аналогия с парадоксом Джевонса здесь остаётся гипотезой, а не прогнозом; - Зачем enterprise-агентам control plane с управлением правами, бюджетами, размещением и сроками хранения данных, а также аудитом: возможности модели важны только внутри управляемого контура; - Как Cursor собирает цикл compute → model → harness/evals → code hosting → deploy → telemetry → correction — и почему часть этого полного цикла обратной связи из продакшена пока остаётся планом, а не готовой автономной системой; - Чему учат инциденты OpenAI и Anthropic во время cyber-evals: сочетание слабой изоляции, ошибочной модели окружения и реальных инструментов создаёт практический риск, но не доказывает «сознательный побег» агента. Все материалы выпуска: - Страница выпуска: конспект, таймлайн, факт-карточки и источники - Интерактивная дека - Видео: YouTube, VK Видео - Аудио: Podster, Яндекс Музыка, Apple Podcasts Если вы иначе видите главный сдвиг августа — поспорьте с нами в комментариях. И присылайте новости, которые стоит проверить в следующем дайджесте. #AI #AI4SDLC #Agents #Engineering #Management #Security #Podcast

Loop Engineering: агентный цикл как термостат, а не бесконечный bash (Рубрика #AI4SDLC) В июле мы уже разбирали Loop Engineering с Максом Смирновым, но у слова loop есть ловушка: оно заставляет смотреть на повторение, хотя инженерная ценность начинается с обратной связи. В 18-минутном докладе «Loop Engineering from First Principles» Kyle Mistele предлагает воспринимать coding agent не как prompt, засунутый в бесконечный bash, а как часть настоящего контура управления. Kyle — CTO и сооснователь HumanLayer, автор технических материалов про MCP, context и harness engineering. В его публичном профиле рядом стоят OSCP, distributed systems и вклад в vLLM и llama.cpp — полезный контекст для внимания к детерминированным границам. В докладе он опирается на внутренний кейс HumanLayer, а в финале приглашает попробовать опубликованный skill и присоединиться к компании. Поэтому это взгляд инженера-провайдера из собственной практики, а не независимое исследование рынка. Антипример — blind loop, который получает большую задачу и возвращает PR на 40 000 строк: формально агент сделал много, практически результат никто не хочет читать. Для команд, сложных кодовых баз и систем с реальными пользователями он возвращает loop к control theory и объясняет его через обычный термостат: - Set point задаёт желаемое свойство кодовой базы; - Sensor измеряет текущее состояние и ошибку относительно цели; - Controller выбирает следующее небольшое изменение; - Actuator — coding agent — вносит его; - Затем система проверяет результат и начинает новый оборот уже из нового состояния. Главная деталь — LLM здесь нужна далеко не везде. В примере HumanLayer постепенно переводит RPC procedures на Effect. ast-grep детерминированно находит старый паттерн, controller может выбрать самую маленькую процедуру, а агент переносит её по вручную написанным golden patterns. Базовый список нарушений хранится в Git, чтобы новые изменения команды не увеличивали долг. Одна итерация CI создаёт маленький PR; пока он открыт, следующий не появляется. Если человек оставляет /iterate, замечания попадают в versioned feedback-файл и меняют дальнейшее поведение цикла. Ту же схему Mistele в день доклада выложил как open-source skill. И вот здесь нужно сказать о том, что в день выхода видео другой сооснователь HumanLayer, Dex Horthy, опубликовал большой пост «Why Software Factories Fail». Dex объясняет, почему lights-off factory ломается даже с хорошим harness: тесты дают быстрый сигнал «работает сейчас», но цена плохого program design проявляется через месяцы. Надёжного быстрого verifier для maintainability пока нет. Примерно об этом он рассказывал в выступлении "Harness Engineering is not Enough: Why Software Factories Fail", о котором я рассказывал Получается важная граница. Если sensor видит только количество немигрированных RPC procedures, loop может идеально свести этот счётчик к нулю — и ничего не понять про архитектуру получившегося кода. Контур оптимизирует выбранный сигнал, а не наше невысказанное намерение. Поэтому Kyle и Dex не противоречат друг другу: - У Kyle человек уже присутствует в контуре: задаёт golden patterns, читает каждый небольшой PR, оставляет feedback и не разрешает работе бесконтрольно накапливаться. - Dex добавляет уровень выше: человек должен владеть самим set point и медленными переменными — product requirements, system architecture, program design и порядком vertical slices. Я бы смотрел и читал их парой. Kyle показывает механику: автоматизировать actuator и воспроизводимые проверки там, где они возможны. Dex ставит ограничитель: пока инженер по-прежнему выбирает, что считать ошибкой, и отвечает за код, к которому придётся вернуться через полгода. #AI4SDLC #AI #Agents #Architecture #Evals #Engineering #Software

Материалы выпуска с Антоном Костериным: как замкнуть 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

Сергей Левин: почему акробатические трюки — плохой тест для робота (Рубрика #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

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

Dominika Rogala про выгорание: AI ускоряет работу — и поднимает норму нагрузки (Рубрика #Management) В посте про AI-burnout речь шла о конечности человеческого внимания. Dominika Rogala добавляет организационный слой: AI может удешевить задачу и одновременно перегрузить рабочую систему. Инструменты стали быстрее — и ожидания тоже. Rogala — founder и leadership coach в Good Job Coffee, бывший VP of Engineering NeuroDevice и Engineering Manager в Vector Technologies и Intel. Её рамка инженерная: искать проблему не только в человеке, но и в системе приоритетов, решений и восстановления. Доклад начинается у океана в Назаре. Rogala — подготовленный спасатель и хороший пловец, но большая волна всё равно сбила её с ног. Когда волну уже хорошо видно, ты часто внутри неё. С выгоранием так же: лучше замечать ранние сигналы. Rogala раскладывает их на четыре измерения. Первые три опираются на классическую рамку выгорания; четвёртое — её практическое расширение. 🔸 Истощение — энергия перестаёт восстанавливаться достаточно быстро, и даже небольшие решения становятся дорогими. 🔸 Эмоциональная дистанция — ещё работаешь, но отстраняешься от того, что раньше было важно; «работает — и ладно» вытесняет заботу о качестве. 🔸 Снижение ощущения эффективности — занят постоянно, но всё равно чувствуешь, что отстаёшь и уже не справляешься как прежде. 🔸 Identity gap — человек на работе всё меньше похож на инженера или руководителя, которым хотел стать. Иногда тяжелее не усталость сама по себе, а то, что перестаёшь узнавать себя в собственной работе. Дальше Rogala использует модель Job Demands–Resources — Demands — нагрузка, переключения контекста, постоянная доступность и адаптация — Resources — автономия, ясность, поддержка, смысл, время на обучение и восстановление — Риск растёт, когда высокие demands становятся нормой, а resources системно не хватает. AI попадает в обе колонки. Он снижает усилие на задачу, но человек по-прежнему отвечает за результат, проверяет его и принимает решения. Параллельно растут скорость, число контекстов и ожидания. Главная мысль Rogala: система не обязательно становится проще — она становится быстрее. А выигрыш в эффективности быстро превращается в expectation inflation. Здесь доклад стыкуется с постом Paweł Soluch — основателя NeuroDevice и нынешнего CEO и co-founder Spinally. В NeuroDevice Rogala позже была VP Engineering. В начале карьеры Soluch мог работать двое суток без сна и постоянно менять часовые пояса. Годы всё выглядело нормально; затем он набрал 30 кг, организм заставил остановиться, а восстановление заняло месяцы. Его формула: с инвесторами можно договариваться, с биологией — нет; восстановление — это фундамент компании. Rogala ответила под этим постом: такую инфраструктуру нужно встраивать в каждый день. Маленькие регулярные паузы удерживают энергию лучше, чем ожидание «подходящего момента», после которого недельного отпуска уже может не хватить. Это не диагноз со стороны, а два уровня одной истории: у Rogala — модель дисбаланса, у Soluch — личный рассказ о цене его многолетнего игнорирования. Практический вывод — не wellness-перки — Если половину недели съедают status meetings, нужно меньше встреч, а не лекция по тайм-менеджменту — Если приоритетно всё — убрать два приоритета — Ещё три идеи: вернуть 1:1, защитить deep work и дать команде buffer week с самостоятельным выбором работы. — Обучение AI становится ресурсом, только когда есть рабочее время применить его. Для меня здесь важна мысли, что AI не создаёт энергетический долг автоматически. Но если каждый сэкономленный час сразу заполнить новой задачей, мы получим не устойчивую систему, а более быстрый маршрут в ту же кроличью нору. #Management #Leadership #AI #Engineering #DevEx #Process

Ищу человека, который подхватит AI4SDLC после меня (Рубрика #AI4SDLC) 31 августа я покидаю компанию. Но задача, которой я занимался, остаётся: менять процессы разработки и вести компанию к AI Native. Планка здесь высокая. Нужно знать передовые подходы, иметь hands-on опыт, уметь работать со множеством стейкхолдеров — и действительно хотеть изменить к лучшему одну из крупнейших технологических компаний России. Про текущее состояние AI4SDLC лучше всего расскажет моё выступление на Turbo ML Conf этого года. Работать предстоит под руководством Игоря Маслова — VP и руководителя департамента платформенной инженерии всей компании. Если вы читаете это и думаете «кажется, это про меня», напишите мне в личку (или сразу @kovalevatin). А если знаете подходящего человека — пожалуйста, перешлите ему этот пост. #AI4SDLC #AI #Engineering #PlatformEngineering #Leadership

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

3 AImigo S1E3: Новостной дайджест AI за август (Рубрика #AI) В пятницу в 12:00 у нас пройдет последний эфир 3 AImigo в этом августе и мы решили проверить новый формат с обсуждением новостей AI за месяц. Вообще, тема AI развивается очень бурно и событий, что достойны упоминания достаточно много: новые модели и продукты, исследования, заметные кейсы, изменения в подходах команд к разработке с AI. Мы выбрали новости, доклады и тренды, которые показались нам действительно важными, и обсудим не только «что произошло», но и что за этим стоит. Мы попробуем разобраться где новости относятся к реальным изменениям для инженеров и компаний, а где это пока маркетинговая шумиха. На что стоит обратить внимание прямо сейчас, а что можно пока отложить. Как обычно, разбираемся втроём: Евгений Сергеев, Алексей Литвинов и Саша Поломодов:) Если формат зайдёт, будем делать такой выпуск в конце каждого месяца. #AI #AI4SDLC #Agents #Engineering #Architecture #Management #Metrics #DevEx #Productivity #Software

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

Материалы выпуска с Сергеем Бережным: что остаётся дефицитным, когда код становится дешёвым? (Рубрика #Management) Готовы материалы очередного выпуска Code of Leadership S2E14, который прошёл 24 августа. Вместе с Сергеем Бережным — директором по взаимодействию с разработчиками Яндекса, CTO Яндекс Практикума и соавтором БЭМ — разбирали, что становится узким местом, когда сам код генерировать всё легче. Обсудили: - Как БЭМ вырос из внутреннего решения для большой фронтенд-разработки в методологию, инструменты и инженерную экосистему; - Как митапы, DevRel и open source помогают распространять технологии — и почему публичность приносит не только охват, но и ответственность; - Как устроена матрица продукта и технологии: продуктовые задачи меняются быстро, а профессиональная специализация живёт дольше; - Как лидеры уровня Staff+ проводят поперечные изменения через стандарты и договорённости, не имея прямого административного мандата; - Почему AI даёт системный эффект после перепроектирования рабочего цикла, а не просто ускорения прежних тикетов; - Что, по итогам разговора, остаётся дефицитным при дешёвом коде и контенте: постановка задачи, инженерное суждение, критическая проверка, фокус, обратная связь, доверие и ответственность за результат. Все материалы выпуска: - Страница выпуска - Видео: YouTube, VK Видео - Аудио: Podster, Яндекс Музыка, Apple Podcasts - Текст: краткая расшифровка Спасибо Сергею за разговор. Если после просмотра появятся вопросы — пишите в комментариях: соберу их для продолжения темы о техническом лидерстве в эпоху AI. #Management #Leadership #Engineering #AI4SDLC #OpenSource #Education

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

Почему удачный 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

Материалы выпуска «Дата-платформа в 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

Первые 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

Материалы AMA с подписчиками «Книжного куба» (Рубрика #AI4SDLC) Готовы материалы с AMA-сессии, которая прошла 23 августа. Вопросов было много, поэтому за полтора часа мы успели пройти путь от выбора следующей книги до ответственности за действия автономного AI-агента. Мы обсудили: - Как выбирать книги от текущего вопроса и превращать чтение в заметку, схему, эксперимент или решение; - Как устроены 6D, личная система знаний и переход от материалов к навыкам в System Design Space; - Зачем нужны пет-проекты и почему короткая петля обратной связи важнее их масштаба; - Вход в IT, рост лидера, завершение десятилетнего карьерного этапа и следующий шаг; - SDD, детерминированные проверки и ответственность за AI-код; - Экономику агентной разработки и сценарии AGI/ASI — без обещаний даты. Все материалы выпуска: - Страница выпуска - Видео: YouTube, VK Видео - Аудио: Podster, Яндекс Музыка - Текст: краткая расшифровка Спасибо всем за вопросы и живое обсуждение. Если после просмотра появились новые — пишите в комментариях: соберу их для следующей AMA или отдельных постов. #AI4SDLC #Engineering #Leadership #Career #Architecture #Management