Сезон кода: Нижний Новгород (Рубрика #Engineering)

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

#Engineering #Travel #ForKids

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

Дискуссия — «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

Водоходъ (Рубрика #ForKids)

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

Вывод: оплачивайте картами Т, чтобы иметь возможность оспорить оплату у таких "водоходов".

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

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.

P.S.
Пройдите опрос, чтобы поучаствовать в нашем про влияние AI на разработку в России.

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[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

Как продакты, аналитики и дизайнеры создают ценность через мышление (Рубрика #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