Книжный куб

Программирование смыслов (Рубрика #AI) Посмотрел вчера интересное выступление Алексея Гусакова, CTO бизнес‑группы «Поиск и рекламные технологии» в Яндексе. Алексей рассказывал об изменениях в подходах к созданию продуктов - они активно развивают ML и LLM‑стек и внедряет нейросети в ключевые сервисы (Поиск, Алиса, Браузер и др.). Если кратко, то фокус разработки смещается от детального кодирования алгоритмов к проектированию намерений и смыслов: вы формулируете задачу, ограничения, источники знаний и метрики качества, а поведение системы «программируете» комбинацией промптов, данных, инструментов и вознаграждения (reward). В такой модели ценность создаётся не одиночным микросервисом, а циклом: гипотеза → прототип → измерение → дообучение/тонкая настройка → интеграция. Внутренний стек и процессы должны это поддерживать. Собственно, доклад Алексея отлично рассказывает переход к программированию смыслов по шагам 1) Как всё началось В 2022 Яндекс запустил диалоговый эксперимент «Гуру по товарам» - это была попытка превратить поиск в помощника по выбору: задаёшь вопросы (“какой телек взять?”), система уточняет параметры и ведёт к покупке. Но пользователям не зашло - общение с гуру ощущалось как заполнение скучной анкеты. Команда потратила много ресурсов, наделала ошибок, но получила важные сигналы о том, какой диалог “продаёт”, а какой — раздражает. 2) Поворотный момент В конце 2022 года вышел ChatGPT и появились генеративные ответы в Bing. Перед командой Yandex появилась дилемма: пилить “большую сложную штуку” (аля как у Bing) или идти инкрементально. Выбрали второе - быстрые, приземлённые улучшения вокруг текущей выдачи. 3) Что именно сделали (и где) - Начали собирать ответы на основе сниппетов и инфоконтекста; обучили собственную LLM для абзацев‑ответов. - Перешли к структурированным ответам из нескольких источников: модель планирует, какие документы использовать и как сшивать факты. Балансировали стабильность vs. риск: не выпускать “магический” ответ любой ценой, а двигаться ступеньками, проверяя качество. Сместили фокус с “идеальной рекомендации” к системе ограничений: не повторяться, сохранять разнообразие, поддерживать новичков и т. п. Оптимизация таргета происходила внутри набора правил, а не поверх “чёрной коробки”, - так проще контролировать поведение. - Пошли в ассистенты, но абстрактные описания вроде “будь умным и полезным” не собирают дают продукт. Выработали принципы, которые действительно работают: ответы не слишком длинные/короткие, правдивые, персонализированные, без вымышленных товаров/свойств; форму ответа модель выбирает, глядя на онлайн‑сигналы. 4) Машинное обучение как конвейер Запустили повторяемый цикл: AI-тренеры размечают и оценивают ответы → обучаются генеративная модель и модель вознаграждения (RM) → катим улучшения → снова собираем обратную связь. Стали на встречах “мудрецов” обсуждать работу моделей - Использовали пайплайны с несколькими моделями на один запрос: даже с “замороженными” параметрами можно сильно вырасти за счёт правильной оркестрации и большего вычисления. 5) Какие проблемы были и как их лечили - Reward‑хаккинг: после первого цикла RM модель “учится” радовать оценщик - внезапно удлиняет ответы, начинает копировать куски источников, вставляет лишние дисклеймеры. - Фиксы: в модель rewards добавили регуляризацию на длину, штрафы за копипасту/канцелярит; отдрессировали стилистику. Был прикольный пример про дисклеймеры, которые оставили только там, где они реально помогают. - В итоге, продуктовая и ML‑разработка смешались - промпты, RM, правила и метрики стали такими же артефактами продукта, как код. 6) Принципы ранжирования и ответов Ссылки в выдаче — это смесь офлайн‑оценки релевантности и онлайн‑вероятности успеха. Ассистенты строят ответы поверх этих ссылок, а не “из воздуха”, чтобы сохранять верифицируемость. #Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Что происходит, когда продукт строится не из метрик, а из идеи. История «Сфер» (Рубрика #ProductManagement) Этот доклад рассказал мой коллега, Иван Турлаев, который уже больше 8 лет развивает мобильные приложения в Т-Банке. Доклад был посвящен созданию и внедрению новой концепции банковского приложения – «Сферы». Предпосылка проста: современные банковские приложения устроены одинаково. Счета, карты, платежи, кредиты – все разложено по привычным категориям. Банки, ориентируясь на метрики и копируя друг друга, выпускают однотипные решения. Но мы решили взглянуть на приложение не со стороны компании, а со стороны клиента и подумать, а что если сгруппировать сервисы не по банковским продуктам, а по жизненным потребностям человека? Так возникла идея «Сфер». Эта концепция родилась не на основе цифр или бизнес-планов - она появилась из стремления сделать сервис понятным и полезным для человека. Придумать смелую идею мало, ее нужно реализовать. Разработка «Сфер» потребовала объединить усилия множества разрозненных команд. В T‑Банке разные направления (карты, кредиты, платежи, страховки, путешествия и др.) имели свои цели и метрики. Объединить их вокруг новой концепции оказалось непросто. Нужно было убедить менеджеров и разработчиков принять общую идею и найти с ними общий язык. При этом бросить текущие проекты было нельзя. Проекту помог единый vision, который был подготовлен командой в качестве наглядного концепта нового интерфейса. Увидев цельный образ будущего продукта, разработчики и менеджеры смогли эффективнее взаимодействовать. Обсуждения сместились с узких показателей на пользовательский опыт: фокус на том, как сделать удобнее человеку. Единый дизайн-концепт выступил «клеем», объединяющим команды. Важно было регулярно сверяться с изначальным замыслом и быть настойчивым. Основой был дизайн-концепт. Команда сознательно отошла от банковских шаблонов интерфейса. Цель - сделать так, чтобы интерфейс говорил на языке жизненных ситуаций, а не банковских продуктов. Дизайнеры экспериментировали с навигацией и визуальным стилем, уходя от перегруженных списков и меню. На главном экране пользователь сразу видит ключевые сферы своей жизни вместо длинного перечня услуг. В итоге, на первом этапе в приложении T‑Банка появились четыре первые «Сферы»: «Шопинг», «Дом», «Авто» и «Путешествия». Каждая стала единым центром для своей темы, объединяя все связанные сервисы банка и партнеров. Например, «Дом» собрал в одном месте оплату коммунальных услуг, страховку жилья и покупки для дома. А «Авто» объединил все для автовладельцев: от штрафов и заправки до страховок и ТО. Такой подход резко отличался от традиционного: прежде эти операции были разбросаны по разным разделам, а теперь клиент решает задачу целиком, не переключаясь между вкладками. Для инженеров проект «Сферы» тоже стал испытанием. Нужно было интегрировать множество разных систем – внутренних и внешних – в единое целое. Фактически команда создала платформу по принципу супераппа, где разнородные модули работают согласованно ради общего сценария. Архитектуре потребовалась гибкость: унифицированные API, общая навигация, единая система уведомлений - всё для цельного UX. Решения по backend и frontend принимались с оглядкой на задуманный пользовательский опыт, чтобы техническая реализация не испортила UX. Если говорить про извлеченные уроки, то я бы отметил для себя следующие - Большие изменения рождаются из смелых гипотез и тут не всегда решают метрики, а вот дальше оптимизировать идею без них не получится - Сценарии работы пользователей важнее структуры компании. Приложения части компаний отражают их внутреннюю структуру (у каждого отдела свой раздел). В сферах мы пошли от сценариев пользователя, а потом уже пришли и к реорганизации структуры подразделений внутри компании (я про это уже как-то писал) - Для больших изменений важен единый vision и коммуникации вокруг него. Без единой цели не получится объединить работу многих команд #Management #Design #Engineering #Leadership #Project #Metrics #Philosophy

[2/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture) Но на этом история монарха не закончилась. Уже в 2023 году на конфе ICSE‑SEIP’23 ребята из Google опубликовали whitepaper-продолжение (что я уже разбирал). Тезисно этот paper можно сократить до следующих пунктов 1) Причина: двукратный рост год‑к‑году QPS и числа рядов, проблемы с поддержкой и дальнейшим попаданием в SLO 2) Команда решила провести редизайн с опорой на quality‑attribute сценарии + лёгкие UML‑модели 3) Фактически, декомпозицировали Leaf на Leaf (KV‑хранилище), Leaf Index Server и Leaf Mixer. 4) Это повлияло в плюс на доступность и сопровождаемость, а latency выросла умеренно, хотя хопов стало больше на 2  (рост с ~12–14 до 16–18 RPC) Но и это было не все - принципы Monarch легли в основу облачного Managed Service for Prometheus: это сервис на том же бэкенде Monarch, которым Google мониторит свои сервисы. Запросы PromQL частично вычисляются на стороне Monarch. Для инженерных команд это даёт из коробки «глобальный» Prometheus‑опыт. Кстати, вопрос масштабирования отдельных Prometheus возникает у крупных компаний часто и для решения этого вопроса появился проект Thanos. Еще можно глянуть на VIctoriaMetrics, этот проект тоже борется с ограничениями Prometheus, но по другому (можно глянуть мой разбор подкаста где автор проекта про это рассказывал) Если подбивать уроки из истории Monarch, то стоит - Собирать метрики ближе к источнику, аггрегировать рано (уменьшение кардинальности и стоимости) - Дешёвый предикатный индекс → дешевле распределённые запросы (урезать fanout до выполнения) - Строго разделять stateful и stateless части (проще сопровождать, легче выдерживать SLO при росте) - фокус на этом во втором whitepaper про редизайн - Шардирование по бизнес‑ключу (target) - локальные агрегации/джойны дешевле. #Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture) Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов 1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации. 2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers). 3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов. Как это примерно работало - Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов. - Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации. - Архитектура обработки выглядела примерно так -- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation. -- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут. - Отдельно были сделаны оптимизации -- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик. -- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок. -- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout. В продолжении я расскажу, а что было с этой системой дальше. #Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

Review of Book "AI Engineering" #3 - Chapter 3 & 4: Evaluation Methodology и Evaluate AI Systems(Рубрика #AI) Вышла третья серия подкаста с разбором крутой книги "AI Engineering", которая дает представление об оценке как самих foundation models, так и приложений на их основе. Книгу разбирает Александр Поломодов, технический директор Т-Банка, а также Евгений Сергеев, engineering director в Flo. Собственно, в этой серии мы обсудили две главы: "Chapter 3: Evaluation Methodology" и "Chapter 4: Evaluate AI Systems". Ну а если раскладывать по темам, то они представлены ниже - Введение и тема выпуска - Почему оценка ИИ‑приложений сложна; рост важности валидации - Валидация в пайплайнах и сложности доменов - Ограничения бенчмарков и переход к продуктовой валидации - Риски неконтролируемой генерации - Теория информации: энтропия как база метрик - Кросс‑энтропия и KL‑дивергенция для оценки моделей - Перплексия и влияние контекста на уверенность модели - Функциональная корректность vs нефункциональные требования - От лексической к семантической близости; эмбеддинги - Паттерны валидации и AI as a judge - Попарные сравнения и ранжирование моделей; транзитивность и голосования - Каркас системы: критерии → выбор моделей → сборка пайплайнов - Факт‑чек и референс‑чек; доверенные источники; человеческий бейзлайн - Дизайн пайплайна: независимые тесты, гайдлайны, разметка; финальные выводы Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Vite: The Documentary (Рубрика #Frontend) На прошлой неделе вышел документальный фильм про Vite или как один побочный проект Эвана Ю (автора Vue.js) за несколько лет изменил весь фронтенд. Начать стоит с того, а почему Vite так важен. Он появился в ответ на то, что Webpack стал слишком медленным и громоздким. В этот момент Эван Ю, автор Vue.js пытался улушить DevEx инженеров, что писали на Vue и он попробовал радикально другой подход: запускать dev-сервер без бандлинга, отдавая модули прямо в браузер через ESModules. Так появился Vite - инструмент, который: - Стартует почти мгновенно; - Обновляет код без перезагрузки страницы (hot module replacement, HMR); - Компилирует зависимости через esbuild и Rollup, обеспечивая скорость на уровне Rust-решений. В начале фильма звучит фраза «если вы пишете на современном JS-фреймворке, вы, скорее всего, используете Vite» и это уже не преувеличение. На нем работают Vue, SvelteKit, Nuxt, Astro, Remix, Qwik, Laravel, Shopify Hydrogen и десятки других фреймворков. Авторы фильма рассказывают про таймлайн развития технологии, который выглядит примерно так - 2020 - Первая версия как dev-сервер для Vue. - 2021 - Vite 2.0 — мультифреймворк, переход SvelteKit и Laravel. - 2022 - Экосистема взрывается: ViteConf, Vitest, интеграции с Nuxt 3 и Astro. - 2023 - Remix и RedwoodJS переходят на Vite; анонс Rust-бандлера Rolldown. - 2024 - Основана компания VoidZero; Vite 6.0, 17 млн скачиваний в неделю. - 2025 - Премьера фильма и планы на Rust-реализацию всего стека. Ключевые факторы DevEx, за которые инженеры полюбили Vite - Скорость: дев-сервер стартует за секунды, HMR - почти мгновенный. - Простота: минимальная конфигурация и плагинная архитектура. - Расширяемость: единая база для React, Vue, Svelte, Qwik и др. - Интеграции: тестирование (Vitest), Storybook, E2E (Cypress, Playwright), Laravel, Rails. - Сообщество: 850+ контрибьюторов, десятки компаний (Google, Shopify, Cloudflare, NASA, OpenAI). Но Vite не стоит на месте и окмпания VoidZero уже пишет на Rust собственные инструменты: - Rolldown - замена Rollup внутри Vite; - Oxc - быстрый парсер и линтер; - Есть планы на «Vite +» - единый стек для сборки, тестирования и форматирования. - Есть движение в сторону AI - на ViteConf 2025 уже обсуждали агентов, помогающих создавать приложения на Vite. Фильм получился не только про технологию, но и про сообщество: как инженерный «побочный проект» стал точкой объединения фронтенда. Раньше я уже рассказывал про другие документальные фильмы из этой же серии и могу рекомендовать их любителям технологий и историй про их создание и развитие. - Kubernetes Documentary - eBPF Documentary - Inside Envoy - GraphQL: The Documentary - Node.js Documentary - Python: The Documentary - Ruby on Rails: The Documentary - React.js: The Documentary - Angular: The Documentary #Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment

Как продакты, аналитики и дизайнеры создают ценность через мышление (Рубрика #ProductManagement) Интересное выступление Кирилла Николаева, моего коллеги, директор по аналитике в Т-Банке. Кирилл разбирает, что на самом деле стоит за jobs to be done (JTBD) и почему не всегда цель продукта - "снять трение": иногда продукт должен намеренно заставлять пользователя подумать, если это повышает качество решения и снижает риски. Если выделять ключевые идеи, то в разрезе ролей они выглядят так - Product manager задает рамку смысла: он формулирует «работу» (JTBD) и желаемое изменение поведения, а не список фич. Цель - ценность, а не “проще любой ценой”. - Аналитик переводит гипотезу в проверяемые критерии, выбирает метрики качества решения (не только CTR): ошибки, возвраты, LTV‑эффекты, время принятия решения. - Дизайнер (когнитивный интерфейс): проектирует правильное трение - подсказки, подтверждения, микро‑обучение - там, где «подумать» критично (финансы, безопасность, ответственность). Почему не всегда надо упрощать - упрощая без разбора, легко ускорить неверные решения. Добавленное «осмысленное усилие» иногда повышает доверие, снижает ошибки и улучшает долгосрочные метрики. Что это значит для инженеров/техлидов: - Инфраструктура экспериментов: feature‑flags, канареечные релизы, дешёвая постановка A/B системы, единая схема событий. - Телеметрия качества решения: события «я понял/подтвердил риски», отмены, возвраты, ошибочные действия, dwell/time‑to‑decide. - Доступ к объяснимости: журнал «критических точек мышления» (какие подсказки/правила сработали) для дебага и аудита. - Ритуалы: единый JTBD‑бриф на 1 страницу; общий план экспериментов; еженедельный «decision review» по качественным и количественным сигналам. Антипаттерны: - "Оптимизация на клики": растит метрики, но ухудшает решения. - "Простота ради простоты": убивает безопасность/ответственность там, где пользователю нужно разобраться. - Feature-driven без JTBD: лечим симптомы, а не работу пользователя. В итоге, ценность возникает на стыке мышления пользователя и инженерной дисциплины принятия решений. JTBD задаёт смысл, аналитика - критерии качества, дизайн - нужную когнитивную нагрузку, а инженерия - инструменты измерения и быстрых проверок. #Software #Metrics #ProductManagement #Software #Design

[2/2] Designing Your Work Life (Дизайн работы мечты) (Рубрика #Career) Продолжая рассказ про книгу дизайна работы мечты, можно показать как советы авторов разложить на 4 недели 1) Неделя 1 - Диагностика и рефрейм - Начать вести энергодневник (5 дней). Отмечайте задачи, которые «заряжают/высасывают». Найдите 2‑3 быстрых улучшения (автоматизация, шаблоны, таймбоксы в расписании) - Сделать рефрейминг топ‑боли. Например, "Слишком много митингов" можно превратить в задачу "за 2 недели сократить суммарно с 10ч до 6ч через 15‑мин стендапы и ассинк‑апдейты". Это и есть MAP (минимально осуществимая проблема), которую перед собой предлагают ставить авторы - Разделите гравитацию и задачи. "Акции идут на рынке вниз" - это гравитация; а "у нас нет тестов" - это задача. 2) Неделя 2 - Мини‑эксперименты (bias to action) - Составьте job backlog: выпишите 10 гипотез, что сделает работу лучше/ценнее; выберите 1 с максимальным эффектом - Раскатите прототип, например, поставьте добавьте no‑meeting block 2×90 мин в своем расписании, или внедрение pre‑commit hooks с прогоном проверок. Только надо определить метрику успеха заранее. - Проведите несколько инфо‑интервью. Это могут быть 30‑мин разговоры с людьми из интересных команд/ролей. Просите рассказать истории, а не спрашивайте "есть ли вакансии". Зафиксируйте навыки/артефакты, которые реально ценят. 3) Неделя 3 - Remodel/Relocate - Составьте 1‑пейджер для изменения в своей работе. Что вы убираете/делегируете, что берёте взамен, выгода для команды, риски, план проверки через 2 недели. - Попробуйте shadow‑ротацию. Попроситесь на 1–2 технических шэдоу‑слота в соседнюю команду (обзор инцидентов, демо). Это безопасный "relocate‑прототип". 4) Неделя 4 - углубление анализа - Проведите ARC‑скан. Оцените работу по шкале 1–5: автономия/связность/компетентность и проанализируйте, удовлетворены ли эти потребности в его текущей работе, и как можно улучшить ситуацию. - Оцените как вы хотели бы выглядеть баланс денег, смысла и саморазвития в работе. В долгосрочной перспективе карьеру нельзя измерять одним показателем (например, только зарплатой) - Внедрите WIP‑лимиты. Не более 2 параллельных задач; остальное в очередь. - Практикуйте ритуалы роста. Еженедельный короткий пост‑анализ без обвинений: что попробовать иначе в следующем спринте. Если улучшения не происходит, то можно начинать думать про "созидательное увольнение", где нужно максимально круто завершить текущую работу, параллельно занимаясь обновлением портфолио/репо/кейсы, собром референсов, составлением историю перехода ("что я изменил и чему научился"). Общий посыл в том, что надо уходить красиво, чтобы текущая работа стала трамлином к новым высотам, а уход не выглядел побегом #Career #Software #Design

[1/2] Designing Your Work Life (Дизайн работы мечты) (Рубрика #Career) Недавно прочитал книгу Билла Бернетта и Дэйва Эванса из Стэнфорда, что создали курс Designing Your Life. В своей книге авторы переносят принципы дизайн-мышления в область карьеры, где ключевой идеей становится тезис, что работу мечты не «находят» - её проектируют. А значит если вам что-то не нравится в текущей работе, то не обязательно увольняться - часто достаточно сделать рефрейминг и задизайнить роль по другому:) TL;DR для инженеров выглядит примерно так - Думайте как дизайнер и используйте цикл: понять → сгенерировать варианты → прототипировать → внедрять. - Bias to action: меньше «обсждайте» и проводите больше небольших экспериментов. - Reframing: формулируйте минимально осуществимую проблему вместо общих «всё плохо». - Good enough for now: перестаньте ждать идеала, улучшайте 1–2 вещи уже сейчас. - Различайте гравитационные проблемы и реальные задачи. Первые нельзя изменить (так устроен мир) - надо это принять и обойти, а вот вторые можно решить по настоящему. - Счастье на работе = баланс A‑R‑C: autonomy (автономия), relatedness (связи), competence (компетентность) Авторы предлагают заменить решение "я увольняюсь" на 4 стратегии - Re‑enlist - переосмыслить «зачем» в текущей роли (обновить цели/метрики/обратную связь). - Remodel - перестроить обязанности: убрать «песок», добавить «энерго‑фичи», взять мини‑проект. - Relocate - сменить команду/продукт внутри компании. - Reinvent - сменить трек в той же организации (например, из Backend → Platform/SRE/ML). Как этот подход авторов связан с привычными нам в IT вещами - Это похоже на рефакторинг легаси систем: сначала маленькие безопасные шаги, затем - архитектурные изменения. - Прототи работы похож на небольшой a/b тест за фичефлагом. - Пользовательские интервью напоминают предложенные авторами разговоры с людьми из целевых команд/ролей (инфо‑интервью) - Backlog продукта напоминает список гипотез, которые повышают вашу ценность и удовлетворённость. В следующем посте я расскажу как все эти советы могут выглядеть в реальности и укладываться в месяц. #Career #Software #Design

AI в SDLC: путь от ассистентов к агентам (Рубрика #AI) Записал расширенную версию доклада, который продолжает мое предыдущее "Интегрируем AI в процессы разработки в большой компании". Тогда я задал рамку и рассказал про то, как подходить к внедрению AI в крупной компании. А на этот раз я сделал фокус на переходе к агентским сценариям и обсудил следующие темы - Введение и обсуждение темы доклада - История ассистентов (GitHub Copilot, Cursor) - Переход к агентам и почему они выглядят как революция - Примеры агентов и инструменты (Claude Code от Anthropic, OpenAI Codex) - Инфраструктура и протоколы (MCP, A2A) - Экономические предпосылки агентского хайпа - Примеры успешных кейсов от Google AlphaEvolve - Будущее работы и уровни агентности в исследовании от Stanford - Управление и регулирование агентов в исследовании от Google Deepmind - Эволюция SDLC к агентскому Software Engineering 3.0 - Демо агентского режима внутри Т-Банка на примере игры "5 букв" - Экосистема разработки и цели инженеров в исследовании "Measuring Developer Goals" от Google - Внутренняя платформа разработки и Spirit и наш подход к AIфикации разработки - Агентский режим и работа с данными внутри python notebook - Агентский режим для обеспечения качества и создания тест-кейсов - Агент для код-ревью - Агент для поиска уязвимостей (safeliner) - Измерение эффективности и фреймворки оценки - Фреймворк для оценки ассистентов и агентов от платформы DX - Результаты использования ассистентов/агентов в Т-Банке Разбор и ссылки на все источники для изучения доступны в моем tg-канале - https://t.me/book_cube/3925 - https://t.me/book_cube/3931 Выпуск подкаста доступен в Youtube, VK Video.

Жемчужины программирования (Рубрика #Engineering) Первое издание этой книги Джона Бентли вышло почти 40 лет назад, как раз в год моего рождения. Но я читал уже второе издание, что вышло в начале 2000х годов. Это была книга, которая отличалась от других - она учила думать как инженер, а не просто писать код. Автор книги - исследователь из Bell Labs и Carnegie Mellon, соавтор алгоритма k-d деревьев и усовершенствованного quicksort. Но известен он больше колонкой в журнале "Communications of the ACM", из которой выросла эта книга. Это было в 1980-х годах, эпохе, когда 1 МБ памяти считался роскошью. Бентли писал для практиков, которые хотели не просто “работающий код”, а *красивое решение*. Он сравнивал алгоритм с жемчужиной: реальная проблема - это песчинка раздражения, а изящное решение - результат терпения и формы. Каждая глава - это короткое эссе с задачей, размышлением и выводом. Они покрывают следующие темы - Как формулировать задачу и искать ага!-решение; - Оценка на салфетке, где автор рассказывает про оценку времени и памяти алгоритмов буквально на пальцах; - Алгоритмические трюки: сортировка, выборка, поиск, оптимизация; - Как писать корректные и понятные программы. Интересно, что Бентли написал еще и книгу продолжение "More Programming Pearls", где он добавил следующие темы - Философия инженерного мышления (“исповеди кодера”); - Маленькие языки - предтечи DSL и скриптов внутри систем; - Афоризмы и практические советы вроде “плохую программу ухудшить не грех”. Если говорить про значимость книги в далекие времена, то автор в ней показал, что программирование - это не набор трюков, а искусство видеть структуру задачи. Когда-то книгу использовали в курсах по алгоритмам и дизайну программ. Сейчас большинство примеров устарело, но подход - нет. В итоге, книги Джона Бентли по праву считаются сокровищницей знаний для программистов. Они объединяют поколение инженеров 1980-х и современных разработчиков общими ценностями - страстью к изящным решениям и глубокому пониманию задач. «Жемчужины программирования» до сих пор сияют и продолжают вдохновлять новых читателей на поиск красоты в коде. #Engineering #Software #Architecture #SystemDesign

Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering) Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем - Введение и представление гостя - Детство, образование и первые шаги в IT - Работа в «Одноклассниках»: начало карьеры - Инцидент в ОК и переосмысление надежности - Переход к системной надежности - Работа с Cassandra и автоматизация процессов - Новые технологии и взаимодействие команд - Миграция дата-центра: проект и организация - Уход из «Одноклассников»  - Первые шаги с Cassandra в новой роли - Развитие Cassandra как сервиса в Т-Банке - Проблемы архитектуры и декомпозиции кода - Практические выводы и преимущества Cassandra - Рекомендации инженерам по поводу развития и роста Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems

Водоходъ (Рубрика #ForKids) Решили прокатиться на кораблике в Нижнем Новгороде. Пришли вчера в кассы компании "Водоходъ" купить билеты, но их на вчера уже не было. Мы решил попробовать покататься сегодня и купили комфорт билеты на сайте Водоходъ. Пришли на посадку, но нам объяснили, что даже с билетами мы не покатаемся на кораблике. На сайте было указано, что для детей до 5 лет включительно билет нужен, но он бесплатный. Опции получить этот бесплатный билет на сайте не было и мы решили получить его в кассах. А в кассах нам сказали, что этот бесплатный билет для детей есть только в тарифе билетов стандарт, а в комфорт надо покупать билеты на всех (но на сайте этой инфы не было). Докупить билет мы не смогли - мест в комфорт не было. Сдать билеты на комфорт нормально тоже не получилось - в кассе сказали "где билет покупали, туда и идите", а на сайте Водохода предлагают заполнять документ и ножками приносить его в офис компании (или присылать письмом Почтой России). Классно, что у нас в Т-Банке есть возможность оспорить любую операцию, по которой не предоставили услугу.

Гуляя с семьей по парку Швейцария в Нижнем Новгороде, наткнулся на "Отель для книг" и "Отель для насекомых". Креативный тут подход у ребят:) А чуть позже мы поедем на нашу конфу "Сезон кода".

Дискуссия — «GenAI и dev платформы – как меняется разработка» (Рубрика #AI) На летнем IT Пикнике мой коллега Дима Гаевский вел дискуссию на эту тему, где участвовали уважаемые джентельмены - Иван Пузыревский, CTO Yandex Cloud - Александр Лукьянченко, руководитель разработки платформы в Авито - Станислав Сычев, руководитель разработки платформы в Т-Банке Ребята обсуждали следующие темы 1. Роль разработчика меняется ИИ перестал быть только частью IDE. AI пишет код, предлагает оптимизации, генерирует тесты - а инженер становится ревьюером и архитектором решений, а не только исполнителем. Сильные инженеры теперь курируют и людей, и AI-агентов. Джуны растут быстрее - у них под рукой “AI-ассистент”, который подсказывает, как писать код. Главный навык будущего - уметь ставить задачи ИИ и проверять результат, а не просто знать синтаксис языка. 2. AI становится частью платформ разработки - Платформы (CI/CD, IDE, облака) интегрируют AI-помощников, которые анализируют код, собирают метрики, предлагают фиксы. - AI-модели дообучаются на данных из внутренних репозиториев, понимают корпоративный стиль кода и стандарты. Как итог: внутренние dev-платформы становятся “живыми системами”, где ИИ не только помогает людям, но и сам учится на их паттернах. 3. Автономность AI пока не так велика - Ни один из участников не верит в «AI-разработчика без человека». - Сейчас граница ясна: AI можно доверить рутину (генерацию шаблонов, тестов, фиксов), но не архитектуру и продакшен-код. - Везде действует правило: «AI предлагает, инженер утверждает» (условно, есть human in the loop). Это связано со стоимостью ошибок 4. Новые роли и процессы - Появляются новые профессии: AI-инженеры, промпт-дизайнеры, ревьюеры моделей. - Некоторые частично детерминированные сценарии работают лучше: генерация тест-кейсов, юнит-тестов, агенты для код-ревью, миграции кода - DevEx-платформы превращаются в экосистемы для людей и агентов: оба учатся на общих данных и повышают эффективность. 5. Что дальше - AI-first-платформы станут стандартом: без встроенного помощника IDE или CI/CD скоро не обойтись. - Команды станут меньше и междисциплинарнее - рутину берут машины, людям остаются дизайн, логика и ответственность за свою работу и работу AI-агентов - AI-грамотность станет новой базовой компетенцией инженера. - Появятся агентные среды, где несколько AI-сервисов будут решать задачу “от ТЗ до деплоя” под присмотром тимлида-человека. Если подводить итоги, то ребята - Не верят, что AI не заменит инженеров - скорее инженеры станут тимлидами команды AI-агентов - Платформы разработки становятся умнее, интегрируя AI-возможности в себя #Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy

Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap (Рубрика #AI) Недавно прочитал интересное продолжение whitepaper "Rethinking Software Engineering in the Foundation Model Era: From Task-Driven AI Copilots to Goal-Driven AI Pair Programmers", которую я уже разбирал. В новой статье те же авторы развивают идеи и рассказывают про Software Engineering 3.0, где текущий этап copilot и AI ассистентов они нумеруют SE 2.0 (они ускоряют работу, но создают когнитивный шум). На новом этапе разработка будет строиться вокруг намерений (intent-first). Условно, инженер говорит AI агенту, что нужно, а уже агент в формате диалога пишет код. Агент работает как напарник, обученный понимать цели и превращать их в работающую систему. Авторы этой научной статьи выделяют пять составляющих новой экосистемы - Teammate.next - AI-партнёр с «социальным интеллектом». Учится на диалогах, уточняет требования, помогает держать контекст. - IDE.next - чат-среда вместо редактора. Код можно скрыть: внимание фокусируется на смысле, а не синтаксисе. - Compiler.next - компилятор-агент, который не просто компилирует, а проверяет, совпадает ли результат с намерением и стандартами качества. - Runtime.next - динамическая среда, оптимизирующая ресурсы для AI-сгенерированного кода, с учётом SLA и latency. - FM.next — новое поколение foundation моделей: не обученных на шумных данных, а «воспитанных» через curriculum engineering – структурированное обучение инженерным знаниям Авторы считают, что SE 3.0 будет работать лучше 2.0, так как в новой версии исчезает «шквал подсказок»: AI-партнёр сам агрегирует решения. Человек отвечает за смысл, машина — за механику. Вместе они снижают когнитивную нагрузку и ускоряют цикл разработки. Компилятор-агент проверяет качество, а knowledge-driven модели делают выводы не по шаблонам, а через понимание принципов. Авторы уверены: при целенаправленных исследованиях эти технологии приведут к новой эре разработки — более масштабируемой, надёжной и человеко-центричной. По мнению авторов мы стоим на пороге перехода от ремесла к наставничеству. Разработчик будущего не пишет код, а обучает ИИ-агента думать о системе, ставит задачи и проверяет результаты. Код превращается во вторичный артефакт — результат диалога человека и машины. Интересно, что статья вышла осенью 2024 года, поэтому она предвосхитила хайп 2025 года вокруг AI агентов. В этом году концепция “agentic AI”, то есть AI-агентов, способных самостоятельно принимать решения, набирает популярность и рассматривается как следующий этап эволюции помощников для программистов. Аналитики прогнозируют, что эта тенденция уже в ближайшие годы подтолкнёт переход от простых AI-копилотов к полноценной AI-native разработке софта. Собственно, авторы не стали скромничать и в сентябре этого года выпустили продолжение "Agentic Software Engineering: Foundational Pillars and a Research Roadmap" с таким описанием (заметим, что ключевые слова про агентский подход к разработке теперь указаны правильно)

Agentic Software Engineering (SE 3.0) represents a new era where intelligent agents are tasked not with simple code generation, but with achieving complex, goal-oriented SE objectives. To harness these new capabilities while ensuring trustworthiness, we must recognize a fundamental duality within the SE field in the Agentic SE era, comprising two symbiotic modalities: SE for Humans and SE for Agents.

Посмотрим, что будет дальше, но пока дейстительно кажется, что AI-агенты могут стать значительной вехой в разработке софта. #AI #Software #Architecture #Agents #Leadership #ML #SystemDesign

Сезон кода: Нижний Новгород (Рубрика #Engineering) Сегодня вечером я уезжаю в Нижний Новгород, где планирую завтра потусить в офисе и пообщаться с коллегами, включая сессию вопросов и ответов, а в субботу загляну на наше мероприятие "Сезон кода", где будет плотная программа про надежность, масштабируемость и полезные инженерные практики. Так что если вы будете на этом событии, то можно будет попробовать найти меня. Правда, я еду в Нижний с семьей: женой и двумя младшими детьми, а значит в планах у меня не только сезон кода, куда я загляну всей семьей, но и более широкомасшабные прогулки по городу, в котором детишки еще не бывали. #Engineering #Travel #ForKids

[2/2] Исследование AI в SDLC от IT One и Сколково (Рубрика #AI) Продолжая рассказ про исследование и переходя к российским реалиям хочется процитировать отчет На текущий момент в России проникновение ИИ в задачи разработчиков происходит темпами, сопоставимыми с мировыми. Однако, на российском рынке, в отличие от мирового, проблемы и вызовы изменения жизненного цикла разработки под влиянием ИИ только начинают входить в приоритеты и фокусы технологических лидеров и тимлидов. Эта цитата подкрепляется исследованием Руссофт от 2024 года, где опрос софтверных компаний показал, что 54,8% из них отметили, что они имеют экспертизу и опыт в области искусственного интеллекта и используют их в разработке новых заказных систем или собственных решений (эта чиселка отросла с 46,6% в 2023 году). Авторы исследования дают оценку, что ИИ используют ~62% сотрудников ИТ‑команд (в 2 раза выше 2024), а к 2028 пороникновение будет ~98% (~3,22 млн пользователей). Я не смог источник, откуда взят этот прогноз (упоминается отчет Руссофта, приведенный выше, а также отчет T-Adviser про рынок труда). Дальше авторы рассказывают про ландшафт AI инструментов в России и делятся оптимистичными цифрами - Ассистенты разработчика: GigaCode (Сбер), Yandex Code Assistant / SourceCraft, МТС Kodify; DevSecOps: Safeliner (Т‑Банк) - Публичные заявления о результатах применения этих инструментов навроде -- GigaCode: до +28% к скорости разработки; −50% времени на регрессию; +30% скорость UI‑автотестов; 3× быстрее настройка конвейера; 2× быстрее онбординг DevOps; -- 5× быстрее обработка ИБ‑уязвимостей в Safeliner от Т-Банка -- Platform V Works (СберТех): −40% времени до прома в CI/CD; −50% времени на тестирование; +25% релизов; −20% трудозатрат -- Альфа‑Банк: ИИ‑агенты‑тестировщики — −30% ошибок за счёт роста покрытия, до 70% быстрее генерация автотестов; масштаб на 60+ команд Среди трендов авторы выделяют - Встраивание AI в платформы разработки: IDE, CI/CD, DevSecOps и т.д - Появление агентных сценариев - автогенерация тестов/кода, проведения код-ревью - Изменение нормы эффективности и дальнейшее движение в стороны T‑shaped разработчиков Интересно, что вызовами являются темы - Измерений эффектов - меньше 25% компаний замеряют их, а те, кто измеряют ориентируются на TTM/Lead Time, дефекты на проде - Регуляторика и риски качества недетерминированной работы LLM - ИБ/152‑ФЗ, качество LLM, контроль использования и «галлюцинаций» Авторы исследования предлагают следующий план внедрения AI - Выберите 1–2 узких сценария: юнит‑тесты, код‑ревью, ... - Зафиксируйте базовые метрики: TTM, Lead Time, дефекты - Примите политику ИБ: что можно/нельзя; on‑prem/cloud LLM для кода - Встраивайте в платформу разработки/CI‑CD, а не кустарно сбоки - Введите quality‑gate для AI‑кода% кодстайл, статанализ, обязательное ревью - Создайте библиотеку промптов и обучите команду. - Сравнивайте российские и зарубежные модели на своих задачах. - Масштабируйте после 2–3 успешных пилотов с подтверждённым ROI. #Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy

[1/2] Исследование AI в SDLC от IT One и Сколково (Рубрика #AI) Недавно я был на презентации результатов этого исследования от IT One и Сколково, где участвовал в панельной дискуссии. Потом я взял это исследование и изучил все 59 страниц, в которых примерно следующая структура 1) Мировая практика: существующая и предстоящая трансформация SDLC под влиянием ИИ - здесь авторы провели мета-исследование, проанализировав отчеты других уважаемых ребят (приведу ссылки ниже при описании результатов) 2) AI в SDLC в России: ландшафт рынка, сервисы, практики и ожидания по развитию - здесь авторы проанализировали публичные сервисы, доступные на рынке Росии + проанализировали крупные анонсы от игроков, даже если сами решения еще не доступны для широкого круга пользователей 3) Взгляд технологических лидеров на AI в SDLC: результаты интервью СТО / CIO и руководителей по разработке крупных компаний - здесь авторы взяли интервью с 50+ уважаемых людей в индустрии (списка этих людей я в отчете не нашел, но поверим на слово) 4) Прогнозы, выводы и рекомендации о возможностях и рисках, с которыми связано использованием AI в SDLC - мнение авторов о том, как дальше будет развиваться AI и как его интегрировать в разработку Начнем в этом посте с общемировой практики - Рынку AI-инструментов для разработки : $6,9 млрд → $29,6 млрд к 2032 (х4). Наибольший эффект на этапах разработки и тестирования. Источник Spherical Insights - 62% разработчиков уже используют ИИ; ещё 13,8% — в планах (по данным 2024 года). Менеджеры оценивают проникновение ниже, но тренд ускоряется. Источник StackOverflow 2024 (я разбирал этот отчет 2024 года, а также разбирал и новый отчет 2025 года) - Ценность смещается от личной эффективности (быстрее пишет код) к командной: сейчас +10% к скорости кодинга, в горизонте нескольких лет +25–30% к продуктивности команд при работе "ИИ-на-уровне-команд" (чтобы это ни значило). Источник Mia Platform - Ускорение SDLC: уже 15–20% сейчас (источник: Forrester), потенциал 30–50% на среднесрочном горизонте (источник: medium статья от Сатиш Рама, Director Gen AI @ Paypal) - Горизонт трансформации процессов - 1–3 года; у 32% техлидеров фактический эффект уже превзошёл ожидания (Источник: MIT, но конкретной ссылки на статью нет) Отдельно авторы упоминают про исследование METR, где на сложных задачах/репозиториях ИИ может замедлять работу опытных инженеров. Подробный разбор есть в моих постах 1 и 2 и даже в подкасте RIMS, где показано, что само исследование задизайнено под конкретный результат + представляет очень узкий кейс. Интересно, что авторы исследования нашли модель зрелости от министерства DEFRA правительства Великобритании "The AI-Powered SDLC: A Comprehensive Technical and Cultural Maturity Assessment Framework". Я сначала не понял как ведомство, отвечающее за охрану окружающей среды, продовльственную политику и развитие сельских регионов связано с цифровизацией, но потом изучил вопрос и понял:) С середины 2010-х DEFRA стало одним из лидеров цифровой трансформации в британском госсекторе, во многом благодаря активному сотрудничеству с Government Digital Service (GDS) и Central Digital and Data Office (CDDO). У DEFRA тысячи источников данных (от спутников до фермерских отчетов) и огромное разнообразие пользователей. Поэтому именно здесь британское правительство активно тестирует свои AI/ML темы и агентские системы. Если же говорить про риски AI, которые отмечают западные отчеты, то они такие - Утечки кода/данных и проблемы с соблюдение требований комплаенса; - Деградация компетенций инженеров и «слепое» доверие подсказкам; - Рост техдолга и vendor lock‑in на провайдеров В итоге, видно, что тема AI-фикации процессов разработки софта сейчас горяча как никогда. На Западе только ленивый не публикует свои отчеты/прогнозы/продукты/... и по большей части они сейчас в положительной тональности. Но многие отмечают, что скачок эффективности будет при переходе от личных копилотов к интеграции в процессы компаний. Дальше поговорим про Россию. #Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy

У системных аналитиков нет комьюнити: миф или реальность Почему у аналитиков нет ощущения «мы — вместе»? Можно ли построить сообщество без формальной структуры и зачем вообще это делать? И правда, что фраза «мы как семья» больше мешает? Все это мы обсудили в финальном выпуске второго сезона подкаста с Анастасией Кабищева, PMO Ekleft и консультантом по психологической безопасности команд. Слушайте последний выпуск этого сезона, чтобы узнать: ➡️Что такое комьюнити и почему его нельзя построить «сверху». ➡️Зачем сообществу нужны цели, роли и даже «боли». ➡️Как уживаются конфликтность и безопасность внутри одной группы. ➡️Почему научить людей спрашивать — отдельный навык. ➡️Какие качества помогают системным аналитикам создавать живое комьюнити. Где слушать? 🔸Яндекс.Музыка 🔸ВК 🔸Apple Podcasts 🔸Telegram-плеер 🔸остальные платформы