The 4 Patterns of AI Native Development — Patrick Debois (Рубрика #AI)

Вчера посмотрел короткое, но интересное выступление от Патрика Дюбуа, эксперта по DevOps, соавтора "DevOps Handbook", эксперта по интеграции AI в разработку. Это выступление состоялось 4 июня 2025 года на AI Engineer World's Fair 2025 в Сан-Франциско — крупнейшем отраслевом событии, посвященном практическому применению AI в инженерии. Конференция собрала около 1000 основателей, вице-президентов и ведущих инженеров со всего мира (я с большим интересом следил за этой конференцией в прямом эфире, что был доступен на Youtuve).

Ключевые идеи Патрика о том, что мы сейчас в состоянии перехода от обычной разработки к AI Native. По его мнению это похоже на то, как мы все двигались в сторону cloud native, но теперь у нас новая волна изменений. А это приводит к тому, что инженеры меняются в 4 направлениях

1. От производителя к менеджеру.
Разработчики все меньше пишут код сами, вместо этого управляют AI-агентами, которые генерируют код. Время написания кода сокращается, но время на ревью увеличивается — когнитивная нагрузка растет.
2. От реализации к намерениям
Фокус смещается с "как делать" на "что делать". Мы описываем цель и требования, позволяя AI самостоятельно найти решение. Появляются specification-центричные инструменты.
3. От delivery к discovery
Стоимость экспериментов резко снизилась. Теперь можно быстро создавать прототипы, тестировать множественные варианты и исследовать новые идеи, прежде чем принимать решения.
4. От контента к знаниям
AI дает мотивацию систематизировать и сохранять знания команды. Накопленная экспертиза становится конкурентным преимуществом компании, поскольку создание продуктов становится все более автоматизированным.

Если подводить итог, то AI не заменяет разработчиков, а изменяет области, где мы создаем ценность. Понимание этих паттернов поможет инженерам эффективно позиционировать себя и свои команды в меняющемся ландшафте разработки.

#AI #Software #Engineering #Architecture #Agents #Leadership

Надежность на масштабе 50 млн клиентов: опыт Т-Банка для инженеров (Рубрика #SRE)

Сегодня на Хабре вышла статья Алексея Мерсона, бывшего dev advocate нашей платформы Sage. Леша рассказывал про то, как у нас выстроены процессы обеспечения надежности и как они инструментализированы. Ниже я кратко описал основные мысли статьи

- Леша начал с базы, рассказав определение надежности по SRE Book от Google, пирамиду качества (надежность -> UX -> Enjoyment), отметив, что без надежной основы нет смысла говорить об удобстве интерфейсов.
- Дальше пришла пора тройки: SLI/SLO/SLA, а также бюджета ошибок и его связи с каноническими MTTR и MTBF
- Потом Леша рассказал про святую троицу инструментов
-- Sage — единая платформа наблюдаемости, заменившая зоопарк инструментов мониторинга
-- FineDog — система инцидент-менеджмента для учета SLA и здоровья услуг
-- Колобок — инструмент управления релизами с календарем и светофором
- Но инструменты обычно поддерживают процессы, поэтому Леша рассказал про работу с инцидентами: от алертинга с принципом "stateless-инженера" до кризис-менеджмент-планов, а также объяснил как мы разгружаем контакт-центр во время инцидентов
- Вопросы надежности курирует наш центр надежности, который работает над методологией, процессами, делает deep dive по крупным инцидентам и делится со всеми статистикой и интересными инсайтами

Если подводить итог и как-то суммировать то, что полезно сделать в компании почти любого размера и прямо сейчас, то получится следующее
- Стоит заниматься наблюдаемостью независимо от размера сервисов
- Важно наладить работу с инцидентами и научиться писать постмортемы
- Если компания большая, то может потребоваться гибридная схема с центром надежности и ролями chief reliability officers по отдельным бизнес-вертикалям
- Важно держать фокус на клиентском опыте — технологии делаются ради решения задач клиентов
Если же накинуть масштаб Т, то видно, что
- Важна автоматизация всех процессов - нельзя лично поговорить с миллионами клиентов
- Важно собирать и анализировать большие объемы данных
- Важно проектировать отказоустойчиво свои системы и использовать платформенные сервисы (XaaS)

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

P.S.
Интересно, что я недавно выступал с докладом "Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем?" на PHDays и упоминал процессы и инструменты, которые подробно разбирает Леша в этой статье.

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

Code of Leadership #40 - Interview with Vladimir Lazarev about media platforms and SDLC (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Владимир Лазарев, бывший технический руководитель Т-Ж. Вова живет сейчас в Белграде и мы с ним обсудили его путь в ИТ, работу в Т, а потом отъезд зарубеж и работу в качестве engineering manager и консультанта по инженерным процессам.

За полтора часа мы обсудили много интересных тем
- Введение и знакомство с гостем
- Влияние семьи и самообразование
- Выбор профессии и поступление в вуз
- Опыт в менеджменте и работа в диджитал-агентстве
- Приход в Т-Банк и работа над проектами
- Развитие и модернизация медиа-проектов
- Переезд в Белград и опыт работы в TravelTech
- Обсуждение ухода из ETG
- Советы по саморазвитию и рекомендации по книгам

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

Статьи и контакты Вовы есть на его сайте: https://laidrivm.com/. Пишите Вове, если ищите engineering management/director, или хотите проконсультироваться о менеджменте команд или веб-разработке.
Рекомендации Вовы:
- Книга "Designing Data-Intensive Applications", про которую я уже рассказывал
- Книга "Теоретический минимум по Computer Science", про которую я уже рассказывал
- Книга "Пиши, Сокращай", про которую я уже рассказывал
- Школа Менеджеров Бюро Горбунова
- Сайт о local-first разработке

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

Cursor CEO: Going Beyond Code, Superintelligent AI Agents, And Why Teste Still Matters (Рубрика #AI)

Посмотрел интересное интервью Michael Truell с Garry Tan. Они говорили про будущее разработки и это действительно интересно, ведь Майкл — соучредитель и генеральный директор Anysphere, компании, создавшей Cursor, один из самых быстрорастущих AI-инструментов для кодирования. А Гарри — президент и генеральный директор Y Combinator, известного стартап-акселератора. Это интервью было 11 июня и оно проходило во время Demo Day Y Combinator Summer 2025, где представляются новые компании из текущего набора Y Combinator. Ниже представлены ключевые идеи интервью в моей интерпретации

1. Революционное видение будущего программирования
Основная цель Cursor — изобрести новый тип программирования, где разработчики смогут просто описывать желаемый результат, а не писать сложный код. Майкл предвидит, что программисты будут становиться "дизайнерами логики", фокусируясь на высокоуровневом проектировании, а не на написании низкоуровневого кода. Интересно, что раньше часто говорили про языки программирования новых поколений, например, третьим поколением были стандартные C, C++, C#, Java и JavaScript, но люди говорили про четвертое поколение. Но оно особо не полетело:) А теперь новым поколением языков программирования похоже будет plain english/russian/whatever text (но лучше с правильными промптами). Интересно, что Майкл считает, что за следующие 5-10 лет произойдет значительное изменение в способах создания софта.

2. Текущее состояние AI в программировании
Наибольшие изменения уже заметны в небольших кодовых базах, где разработчики могут работать на более высоком уровне абстракции. В среднем разработчики используют AI для написания 40-50% кода в Cursor, но все еще требуется человеческий контроль и понимание. Майкл говорит о том, что vibe coding пишется без глубокого понимания и не рекомендуется для долгосрочных проектов (а для прототипов он отлично подходит)

3. Технические вызовы и ограничения
Ограниченный размер контекстного окна AI затрудняет работу с большими кодовыми базами, содержащими миллионы строк кода (что типично для больших компаний). Существующие модели испытывают трудности с непрерывным обучением и сохранением контекста организации и предыдущих решений. AI-модели пока не имеют четкого представления об эстетике, что требует участия человека-дизайнера.

4. История и эволюция Cursor
Команда основателей из MIT первоначально работала над AI для автоматизированного проектирования (CAD), но позже переключилась на программирование. GitHub Copilot и исследования OpenAI о масштабируемости моделей стали ключевыми источниками вдохновения для создания Cursor. Вместо создания расширения для условного VSCode команда решила разработать собственный редактор, что оказалось важным преимуществом.

5. Рост и успех компании
Anysphere достигла оценки в 9,9 миллиардов долларов после привлечения 900 миллионов долларов инвестиций. Компания достигла 100 миллионов долларов годового дохода всего за 20 месяцев после запуска, а затем выросла до 300 миллионов за два года и более 500 миллионов к середине 2025 года. Cursor используется в крупных технологических компаниях, включая OpenAI, Stripe, Spotify и других.

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

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

#AI #ML #Software #DevEx #Engineering #Development

[1/3] Enabling the Study of Software Development Behavior With Cross-Tool Logs (Рубрика #Management)

Прочитал наконец-то исследование, вышедшее в 2020 году, где авторы из Google рассказали про создание своей системы InSession, которая позволяет проводить комплексный анализ поведения инженеров путем интеграции логов от множества инструментов разработки. Ценность исследования в том, что разработчики - это одна из самых затратных частей разработки софта, поэтому даже небольшие улучшения продуктивности могут принести значительные результаты. InSession отличалось от других подобных инструментов тем, что собирало не только данные из IDE, но и не требовало установки на рабочие машинки инженеров (данные собирались из существующих облачных инструментов).

Если говорить про саму систему, то она состояла из следующих ключевых частей
1. События (Events)
Событие - это отдельное использование инструмента или системы разработчиком или от имени разработчика. Для каждого типа логов был свой импортер, который трансформировал данные в общий формат событий. Сами события были разных типов
- Фронтенд-события: инициируемые разработчиком активно (например, нажатие кнопки интерфейса)
- Бэкенд-события: происходящие асинхронно от имени разработчика (например, cron-задания)
- Мгновенные события: с неопределенной конечной точкой
- Длительные события: с установленным временем начала и окончания
2. Артефакты
Для большинства событий собиралась еще дополнительная метаинформация, которую авторы называли артефактами. Они были двух типов
Идентифицирующие задачу артефакты: идентифицируют конкретную задачу разработки для группировки связанных событий
Информационные артефакты: предоставляют контекстную информацию о событии
3. Сессии
Собственно события объединялись в сессии при помощи группировок, которые
- Происходят в один день
- В течение временного интервала (10 минут)
- Имеют одинаковые идентифицирующие задачу артефакты (или не имеют никакую)
4. Метрики
Система выводит семь ключевых метрик поведения разработчиков:
- Время кодирования - время написания или maintaining кода
- Время рецензирования - время на ревью кода
- Время сопровождения (shepherding) - время на доработки кода по результатам обратной связи с code review
- Время исследования - время на изучение документации
- Время разработки - время на разработческие активности любого типа (что не покрыты другими категориями)
- Время работы с электронной почтой
- Время, проведенное на встречах

Если говорить про источники данных для InSession, то это множество инструментов, включающих
- Buganizer - система отслеживания ошибок
- Code Search - инструмент поиска и просмотра кода
- Cider - веб-IDE
- Blaze - распределенная система сборки
- Critique - инструмент рецензирования кода
- Gmail и Calendar - здесь тянулись ограниченные метаданные
- Еще более 90 инструментов командной строки

Продолжение обзора этой интересной статьи в следующем посте.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

[2/3] Enabling the Study of Software Development Behavior With Cross-Tool Logs (Рубрика #Management)

Продолжая рассказ про эту статью, надо рассказать про принципы конфиденциальности, способы валидации, пример исследования, а также про последствия создания методологии InSession и где она дальше засветилась. Ну а начнем мы с принципов конфиденциальности, которым следовали авторы
- Сбор данных только от сотрудников
- Фокус на рабочих инструментах
- Отказ от сбора контента, созданного сотрудниками
- Шифрование хранимых данных
- Аудируемый доступ к данным
- Запрет на отчетность по индивидуальным сотрудникам без согласия (интересно, что на практике соблюдение этого принципа ооочень трудно добиться)
- Уничтожение данных после установленного периода хранения (3 года)

Для валидации полученных измерений авторы решили сравнить их с поведенческими самоотчетаим (diaries). Авторы провели исследование с 25 инженерами Google, которые создавали дневники своей деятельности, затем сравнили эти дневники с данными сессий, используя показатель согласия PABAK (Prevalence and Bias Adjusted Kappa). Результаты показали высокое согласие для времени рецензирования (0.81), кодирования (0.69) и исследования (0.70).

Дальше авторы провели эксперимент для оценки эффекта readability certification инженеров на время рецензирования. Readability certification - это сертфикация о том, что инженер знает идиомы языка и правила написания принятые в Google. Гипотеза была в том, что при получении инженером сертификации по readability
- Ревьюверам придется тратить меньше времени на ревью
- Инженерам придется тратить меньше времени на доработки по комментариям ревьюверов (shepherding)

При анализе влияния процесса читаемости кода они применили линейную регрессию с контролем стажа разработчика, количества рецензентов и размера изменения, а также включили случайный эффект для идентичности автора. И они получили такие результаты
- Для C++: время рецензирования сократилось на 4.5%, время shepherding - на 10.5%
- Для Java: время shepherding сократилось на 10.0%
- 88% инженеров, завершивших процесс читаемости Java, согласились с утверждением о положительном опыте

Это исследование значительно повлияло на подходы к измерению продуктивности разработчиков в индустрии. Система InSession стала основой для ответа на долгосрочные вопросы программной инженерии, такие как "делают ли типы разработку более эффективной?". Подход Google к измерению поведения разработчиков через кросс-инструментальные логи вдохновил другие организации на создание аналогичных систем.

Методология придуманная авторами упоминалась и в следующих статьях, например
- "What Improves Developer Productivity at Google? Code Quality" (2022) - исследование использовало методологию, разработанную в InSession, для изучения панельных данных и установления причинно-следственных связей между качеством кода и продуктивностью разработчиков. Я уже разбирал эту статью
- "Predicting developers' negative feelings about code review" (2020) - работа применила данные InSession для предсказания негативных межличностных взаимодействий во время рецензирования кода, используя 90-й процентиль времени рецензирования и сопровождения.
- "The pushback effects of race, ethnicity, gender, and age in code review" (2022) - исследование использовало инфраструктуру данных InSession для изучения влияния демографических факторов на процесс рецензирования кода.

Окончание разбора с изображениями из статьи будет в последнем посте.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

What your CEO must know about AI (Рубрика #AI)

Посмотрел интересное выступление Хьюберта Мистела, Senior AI Researcher в компании Novartis. Хьюберт руководит командой исследователей искусственного интеллекта в области разработки лекарств, а также преподает машинное обучение и науку о данных в Dublin Business School. Это выступление состоялось на конференции AI Engineer World's Fair 2025 — крупнейшем техническом ИИ-событии года, которое прошло 3-5 июня 2025 года в Сан-Франциско. Ниже представлены ключевые идеи выступления в моей интерпретации

1. Агентское будущее организаций
Хьюберт начал с провокационного заявления: через три года организации могут управляться ИИ-агентами. Это следует из темпов развития технологий. Дальше он рассуждает о том, что такое AI агент - по его мнению это приложение на основе больших языковых моделей, обладающее автономным поведением. Ключевая особенность агентов в том, что они выполняют пошаговые действия с динамическим контролем, адаптируя использование инструментов в зависимости от результатов предыдущих шагов.

2. Трансформация рабочих процессов
Агентные рабочие процессы — главное отличие от традиционной автоматизации. Если раньше машинное обучение могло автоматизировать отдельные шаги, то ИИ-агенты способны:
- Автоматизировать и делегировать несколько шагов одновременно
- Действовать как связующее звено между задачами
- Работать без человеческого вмешательства, запрашивая обратную связь только при необходимости

Дальше автор размышляет об архетипах сотрудников, среди которых он выделяет следующих
- Молчаливые исполнители — низкая коммуникация, высокая производительность
- Индивидуальные исполнители — сбалансированный профиль
- Связующие звенья — соединяют разные команды
- Умножители — усиливают работу других участников команды
- Центры знаний — предоставляют экспертизу

3. Новая реальность рынка труда
Доменные знания и интеллект становятся дешевыми и легкодоступными, а это значит, что
- Компаниям и сотрудникам стоит стремиться к мультидисциплинарным знаниям
- Появятся новые роли: "майнеры рабочих процессов", "люди-оркестраторы ИИ"
- ИИ ускоряет "деятелей" — разница в производительности может достигать не 10x, а 100x (похоже на отсылку к 10x инженерам)

4. Демократизация создания агентов
Критически важно дать возможность сотрудникам самостоятельно создавать агентов с помощью no-code/low-code инструментов, для этого нужно следующее
- Когнитивная самоосознанность — понимание собственных мыслительных процессов
- Способность переводить ментальные шаги в конкретные инструкции
- Доступ к инструментам быстрого создания агентов

5. Этические вопросы
Есть два критических вопроса, которые надо решить для дальнейшего распространения агентов:
- Готовы ли мы не просто делегировать задачи, а позволить ИИ-агентам управлять процессами?
- Какие ценности заложить в агентов и как разрешать конфликты между человеком и ИИ?

6. Практические рекомендации для руководителей
- Аудит стратегии: если ваша AI-стратегия остается актуальной при замене "AI-агент" на "ML" — она устарела
- Картирование рабочих процессов: детальное понимание workflows критично для получения максимальной выгоды
- Готовность к трансформации: организационная структура компании может кардинально измениться
- Инвестиции в контекст: контекст становится новой нефтью, важнее самих данных

В общем, у Хьюберта получилась интересное выступление о революции AI-агентов, которая уже началась и к которой стоит быть готовым.

#AI #ML #Software #Engineering #Development #Agents #Architecture

Интервью с Максимом Евдокимовым про современных CPO, крутые продукты и сложные решения (Рубрика #Management)

Посмотрел с большим интересом интервью с Максимом Евдокимовым, бышим коллегой, который когда-то был CPO в Т-Банке, CPO в hh.ru, большим директором в Сбере, гендиром Okko, а сейчас занимает должность CPMO (Chief Product and Marketing Officer) в Bir Bank, крупнейшем розничном банке Азербайджана. Ниже я выделил основные моменты интервью с моей точки зрения

1. Начало карьеры и опыт в телекоме
Максим рассказал о своем первом заработке в качестве дворника еще в школьные годы. Профессионально он начал работать в 1995 году в торговой компании, для работы хватило знания английского языка и компьютера. Позже, в 2001 году, он попал в финскую компанию Sonera, что стало началом его карьеры в телекоме. По словам Максима, телеком-компании в начале 2000-х были главными драйверами развития цифровых технологий, хотя тогда еще не существовало многих современных терминов и фреймворков. Работа в Мегафоне научила его фокусироваться на клиенте и его потребностях, а также формировать пользовательскую потребность, а не просто отвечать на существующие запросы. Интересно, что сейчас телеком компании - это скорее консерваторы:)
2. Опыт в Тинькофф Банке
В Тинькофф Банк (ныне Т-Банк) Максим пришел в 2013 году после 12 лет работы в телекоме. Первым его проектом был "Тинькофф Wallet" — мобильный кошелек с входом по номеру телефона, который был запущен в декабре 2013 года. Из-за регуляторных изменений проект пришлось трансформировать, и Максим перешел к управлению клиентской частью мобильной платформы банка. Одним из значимых достижений Максима в Тинькофф было внедрение концепции лайфстайл-банкинга и запуск сторис в банковском приложении. Тинькофф стал первым банком на европейском рынке, использовавшим формат сторис для персонализированных предложений клиентам.
3. Продуктовый подход и управление
Максим поделился своим видением продуктового подхода, который он называет "продакт-менеджмент от Евдокимова". Его ключевой принцип: лучше сделать продукт на "твердую четверку" и потом довести до "пятерки", чем выпустить "тройку с минусом" и никогда к ней не вернуться. Он выступает против использования термина MVP (Minimum Viable Product) и предпочитает концепцию MLP (Minimum Lovable Product) — ограниченного, но очень хорошего продукта. По его мнению, для крупной компании неприемлемо делать некачественные продукты, так как это создает репутационные и конкурентные риски.
4. Текущая роль в Bir Bank
В Bir Bank Максим отвечает за продукты и маркетинг. Он рассказал о двух основных задачах в своей текущей роли:
- Построение эффективных продуктовых процессов, так как банк переживает "болезнь роста"
- Развитие экосистемной повестки, чтобы клиенты банка могли увидеть ценностное предложение от других активов экосистемы
По оценке Евдокимова, финтех и банкинг в Азербайджане отстают от российского рынка примерно на 5-7 лет, но в некоторых аспектах, например, в цифровом правительстве и связке бизнеса с государством, некоторые вещи сделаны даже лучше.
5. Ключевые выводы и идеи
Максим подчеркивает важность "ownership" (чувства собственности) в продуктовых командах. По его мнению, идеальная команда — это единомышленники, где каждый отвечает за весь продукт, а не только за свою зону ответственности. Он считает, что в организации нужно развивать культуру доверия и ответственности, чтобы люди могли проявлять инициативу. Причины неудач в продуктовом подходе часто кроются в головах менеджмента, включая акционеров. Для разных стадий развития организации нужны разные управленческие лидеры, и важно вовремя принимать решения о смене руководства.

В общем, подкаст получился достаточно интересным:)

#ProductManagement #Management #Leadership #Software #Engineering #Career