Краткий обзор платформы данных Т-Банка (Рубрика #Data)

Прочитал интересную статью от коллег про про нашу data platform. Если обобщать достаточно длинную статью, то можно отметить, что платформа данных Т-Банка эволюционировала более 18 лет, следуя общеотраслевым трендам. Компания постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — к современным Lakehouse-архитектурам. Платформа сейчас обслуживает более 17 тысяч пользователей и обрабатывает свыше 144 млн запросов в месяц, что требует постоянного развития масштабируемости и производительности. Текущая архитектура включает 19 ключевых систем, которые обеспечивают полный жизненный цикл работы с данными — от сбора до визуализации и обеспечения безопасности. Вот как они сгруппированны

1. Сбор и транспортировка данных
- Data Replication: BODS (legacy) и Chrono для пакетной и потоковой репликации
- Event Sourcing: SDP (Streaming Data Transfer Platform) на основе принципов Data Mesh
- Reverse ETL: Spheradian для возврата данных в операционные системы с латентностью до 100 мс
2. Хранение данных
- Data Warehouse: GreenPlum как основная СУБД (15 кластеров, 1,7 ПБ данных)
- LakeHouse: Spark/Trino + S3 с несколькими вычислительными движками
- Real-Time Analytics: ClickHouse для быстрой аналитики на больших таблицах
3. Обработка и трансформация
- Streaming Processing: Unicorn (на Apache Flink) и NiFi
- Workflow Management: TEDI (на Apache Airflow) и Moebius для оркестрации
- Analytics Tools: Proteus (на Apache Superset) для дашбордов и Helicopter для совместной работы
4. Управление данными
- Data Discovery: Data Detective для поиска и каталогизации
- Data Governance: Data Contracts для управления поставками данных
- Data Observability: DQ Tools для контроля качества и Data Incident Management
- Data Security: SLH для управления доступом к чувствительным данным

Если хочется узнать больше, то можно почитать статью и позадавать вопросы в комментариях.

#Data #Database #Architecture #Software #Engineering #PlatformEngineering

What is a Principal Engineer at Amazon (Рубрика #Staff)

Посмотрел на выходных интересную серию подкаста про principal инженеров от Gergely Orosz, автора рассылки "The Pragmatic Engineer". Для обсуждения этой темы к Gergely присоединился Steve Huynh, бывший principal инженер Amazon с 17-летним стажем работы в компании. Стив работал над многими проектами: от первого Kindle до Prime Video, включая поиск внутри книг, платежи, Amazon Local, рестораны и спортивные трансляции. В 2024 году покинул Amazon для развития YouTube-канала "A Life Engineered".

Ниже представлены основные идеи интервью:
1. Сложность повышения до уровня principal инженера в Amazon
Переход от senior engineer (L6) к principal engineer (L7) в Amazon - один из самых сложных в технологической индустрии. Amazon пропустила промежуточный уровень staff engineer, создав "скачок на два с половиной уровня". Стиву потребовалось 8 лет для получения этого повышения. Несмотря на сотни открытых вакансий главных инженеров, большинство кандидатов не получают повышение с первой попытки.
2. Масштаб и технические вызовы Amazon
Amazon обрабатывает 10,000-100,000+ запросов в секунду на критически важные сервисы. Один запрос к главной странице Prime Video может породить сотни downstream-запросов к различным микросервисам. Стив рассказал про понятие "brownout" - состояние, когда сервис доступен, но работает медленно или возвращает частичные результаты.
3. Связь latency с доходом
Amazon измерил прямую корреляцию между задержкой загрузки страниц и доходом - чем быстрее загружается страница, тем больше покупок совершают клиенты. Это привело к общекорпоративной одержимости производительностью и оптимизации задержек.
4. Эволюция архитектуры: от монолита к микросервисам
Amazon начал с монолитной архитектуры на C++, но столкнулся с ограничением в 4 ГБ для бинарного файла в 32-битной системе. Переход к микросервисам был вынужденным решением для масштабирования, но привел к компромиссам в производительности.
5. Культура письменных документов
Amazon славится культурой шестистраничных меморандумов (6-pager), которые заменили PowerPoint-презентации. Встречи начинаются с 30-минутного молчаливого чтения документа, что способствует глубокому пониманию проблем. Мне нравится этот подход, но зачастую оно сложно приживается в организациях, которые предпочитают для решения любого вопроса собирать большие встречи
6. Процесс COE (Correction of Errors)
Amazon использует структурированный подход к анализу инцидентов через документы COE. В отличие от обычных постмортемов, COE фокусируется на корректирующих действиях, а не только на документировании сбоев. Тут я не до конца уловил отличие от написания постмортемов, как описано в SRE Book от Google
7. Сообщество главных инженеров
В Amazon существует уникальное сообщество главных инженеров с собственными встречами и slack-каналом. Высокие стандарты для получения этого уровня означают, что каждый главный инженер обладает исключительными навыками.
8. Принципы лидерства Amazon
Стив отдельно отметил важность наличие самих принципов, которые можно использовать как аксиомы для построения дальнейших рассуждений и для принятия решений на всех уровнях компании. Если говорить про конкретные принципы, то Стив особенно выделил принцип "Customer Obsession" (одержимость клиентами).
9. Политика свободы передвижения
Amazon внедрил политику "freedom of movement", позволяющую сотрудникам переходить между командами без блокировки со стороны менеджеров. Это создало внутренний рынок талантов, где плохие команды теряли людей, а хорошие - привлекали.
10. Патентная стратегия
Amazon активно патентует программное обеспечение, имея более 15,000 патентных заявок. Культура письменных документов помогает передавать идеи юристам для патентования. Компания имеет уровень одобрения патентов 97.12%.

Это интересное интервью раскрывает аспекты инженерной культуры Amazon и объясняет, почему компания остается привлекательной для талантливых инженеров, несмотря на высокие требования и интенсивную рабочую среду.

#Staff #Engineering #Software #Architecture #Leadership #Processes

Review of Book "AI Engineering" #2 - Chapter 2. Understanding Foundation Models (Рубрика #AI)

Вышла вторая серия подкаста с разбором крутой книги "AI Engineering", которая дает представление о создании gen AI приложений. Книгу разбирает Александр Поломодов, технический директор Т-Банка, а также Евгений Сергеев, engineering director в Flo. Во второй серии мы обсудили вторую главу книги, которая посвящена рассмотрению foundational models. Глава была сложной, но вроде мы с Женей справились и обсудили крупными мазками следующие темы

- Введение, структура главы и стадии обучения моделей
- Данные и языки: влияние представленности языков в датасетах
- Доменные знания и необходимость специализированных моделей
- Специфические модели (пример MedPaLM)
- Мультимодальные модели (текст + изображения)
- Переход от RNN/Seq2Seq к трансформерам
- Структура трансформера и механизм внимания
- История разработки трансформеров и их распространение
- Параметры и компоненты трансформеров
- Контекстное окно и MLP-блоки
- Ограничения ресурсов и оптимизация обучения
- Пост-тренинг моделей: SFT и RLHF
- Обучение моделей через RFHF (примеры промптов и ответов)
- Сэмплирование и их стратегии
- Галлюцинации моделей и их природа
- Стоимость ошибок и сценарии применения моделей

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

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Aravind Srinivas: Perplexity's Race to Build Agentic Search (Рубрика #AI)

Посмотрел интересное интервью Аравинда Шриниваса, CEO Perplexity AI, на мероприятии YC AI Startup School. Аравинд рассказал про путь компании от SQL-прототипа до многомиллионного "ответного движка", поделился планами по запуску браузера Comet и объяснил, почему скорость, точность и фокус помогают стартапу конкурировать с Google, OpenAI и Anthropic. Если говорить про историю Perplexity, то ее можно посмотреть в другом выпуске YC "How To Build The Future: Aravind Srinivas", про который я уже рассказывал, а тут я расскажу только про diffs

1. Масштабирование и рост
Аравинд поделился цифрами
- 2024: ARR вырос до ≈$80 млн; декабрьская оценка $9 млрд.
- 2025 май: переговоры о раунде $500 млн при оценке $14 млрд.
- Штат ~200 человек; обязательное использование AI-кодеров Cursor и GitHub Copilot ускорило эксперименты с 3–4 дней до 1 часа.
2. Comet браузер как "когнитивная ОС"
Аравинд рассказал про следующую большую ставку от Perplexity, а именно концепцией их браузера Comet, так как
- Это единая точка контекста. Вкладки, куки, сессии и история уже содержат персональные данные, необходимые агентам.
- Его сложно скопировать, так как разработка мобильной версии браузера требует месяцы, что даёт стартапу фору.
- Браузер дает абстракцию над чат-ботами. Comet управляет несколькими задачами параллельно; чат-боты воспринимаются как частные случаи
Если говорить про технику, то
- Это Chromium fork с поддержкой расширений Chrome, что доступен подписчикам (200$/месяц)
- В нем есть такие фичи: omnibox-чат для информации и агентских задач, comet assistant в сайдбаре: суммирует почту, бронирует отели, оформляет покупки, заполняет формы
- Используется гибридная архитектура - локальные модели для быстрых задач, облачные API для сложных
- Данные хранятся локально, а режим strict блокирует трекеры и обрабатывает чувствительные запросы on-device
3. Perplexity находится в конкуренции с ключевыми игроками
- Google - AI Overviews, Gemini-сводки в Chrome, но модель CPC-рекламы мешает давать прямые ответы, так как это риск потерять доход
- OpenAI - здесть есть режим Search в ChatGPT, есть браузер в планах, но пока нет собственного индекса
- Anthropic - здесь уже есть веб-поиск в бете
Тут расчет на скорость инноваций, чтобы бежать быстрее конкурентов
4. Бизнес-модель и монетизация
Аравинд рассказал про варианты монетизации
- Подписка Pro/Max - Здесь расширенные модели, больше запросов. Маржинальность тут высокая - многие платят, но не используют лимит
- Usage-based агенты - Эта модель для автоматизация задач в Comet. Маржинальность средняя, так как затраты растут из-за потреблений внешних API
- Транзакции (CPA) - Например, бронирования Selfbook или шопинг Firmly. Маржинальность низкая (исторически ниже CPC)
- Венчур-фонд - Это про инвестиции в экосистему API. Доходность тут портфельная
5. Принципы организационной культуры
- "Пользователь никогда не ошибается" - продукт подстраивается под нативные запросы, не учит «prompt-инженерии»
- CEO лично фиксит баги и это мотивирует команду
- Обязательное применение AI-инструментов: "кто не использует Cursor, тот медленнее"

Ну и напоследок выводы
1. Браузер - логичное продолжение после поискового движка - по образу Google, что в 2008 выпустил Chrome
2. Сильный бренд + скоростная итерация > планового развития- при 10–20 млн платящих пользователей бренд становится самодостаточным активом, даже если крупные модели копируют функции.
3. Рыночные возможности лежат в агентских сценариях - Монетизировать надо не ответы, а действия: бронирование, шопинг, автоматизация рутины. Браузер-агент даёт инфраструктуру для usage-based тарификации.
4. Главный риск — убыточная себестоимость вычислений - рост запросов и агентских задач требует оптимизировать inference; Perplexity вкладывается в дистилляцию моделей и гибридную архитектуру.
5. Эпоха многополярного поиска - антитрестовые риски Google открывают путь альтернативам

#AI #Management #Startup #Engineering #ML #Agents #Software #Architecture

Опросы о влиянии AI на разработку софта за последние несколько лет (Рубрика #AI)

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

1. Stack Overflow Developer Surveys (2023, 2024)
Эти опросы являются одними из самых масштабных и содержат ценные данные. Они основаны на опросе десятков тысяч инженеров, что все еще пользуются Stack Overflow (а не переключились полностью на ChatGPT). Опросы 2023 и 2024 годов соджержали отдельный блок вопросов про AI. Интересно, что в 2023 году 70% из 90,000 разработчиков уже использовали или планировали использовать AI-инструменты в своей работе. К 2024 году этот показатель вырос до 76%. Основными инструментами стали ChatGPT (83%) и GitHub Copilot (56%). Эти опросы можно использовать для отслеживания трендов, так как вопросы год от года достаточно похожие. Кстати, опрос 2025 уже прошел, но результаты пока не опубликованы. Как появятся я покручу данные и посмотрю на тренды.

2. GitHub Developer Survey (август 2024)
GitHub провел исследование среди 2,000 разработчиков из США, Бразилии, Индии и Германии. Результаты показали, что 97% респондентов использовали AI-инструменты на работе. Примечательно, что 61-73% разработчиков в зависимости от страны убеждены в том, что AI повышает их способность создавать ПО. Есть и более раннее иследование GitHub от сентября 2022 года, его результаты интересны для истории и изучения методологии, но сама информация мало релевантна текущей ситуации

3. JetBrains Developer Ecosystem Survey (2023, 2024)
JetBrains проводит свое исследование с 2017 года, впервые включив вопросы об AI в 2023 году. В 2024 году 84% разработчиков были знакомы с генеративными AI-инструментами. Исследование показало, что разработчики наиболее заинтересованы в делегировании AI рутинных задач.

4. DORA Research (2023, 2024)
Знаменитые DORA метрики создала команда DevOps Research and Assessment (DORA), что сейчас относится к Google. Ежегодно они публикуют отчеты, а в 2025 году они опубликовали отдельно "Impact of Gen AI in Software Development". Они обнаружили, что 76% разработчиков используют AI для ежедневных задач. При этом выявлен парадокс: AI увеличивает индивидуальную продуктивность на 2.1%, но снижает командную производительность на 1.5%. Этот report я разберу отдельно подробнее.

5. WeAreDevelopers "State of WebDev AI" (2025)
Интересное исследование, в котором участвовали 4к+ респондентов. 91% опрошенных веб-разработчиков "проводили эксперименты" с ChatGPT; Cursor IDE признан лидером AI-редакторов (80% узнаваемости) .

6. The Pragmatic Engineer Survey (2025)
Интересное исследование, в котором участвовали 3к+ респондентов. 72% инженеров считают AI-тулинг «самым инновационным рынком»; большинство отмечает быстрый приход стартап-инструментов, конкурирующих с Copilot

Исследования показывают, что AI стал неотъемлемой частью разработки ПО, но индустрия все еще находится в процессе адаптации к этой технологии, балансируя между преимуществами и рисками.

P.S.
Из похожего я недавно делал подборку (1 и 2) на тему "Developer Productivity for Humans", каждую из которых я разбирал и изучал отдельно. Думаю, что и опросы из сегодняшней подборки я разберу в деталях позже:)

#AI #ML #Software #Engineering #Processes #Metrics #Management

Картинки опросов, в которых большая доля вопросов про влияние AI

Валерий Стромов: от стажёра до CEO Алисы за 9 лет (Рубрика #Management)

Интересное интервью Валерия Стромова, 29-летнего CEO Алисы и умных устройств Яндекса, который пришёл в Яндекс в 2016 году стажёром-разработчиком в возрасте 20 лет, а к 2025 году возглавил команду из более чем 700 человек. Интервью берут двое ведущих подкаста "Это моя работа": Дарья Золотухина, HR-директор Яндекса, одна из ведущих подкаста, и Никита Толстой, который в команде Я Маркета отвечает за пользовательский опыт и технологии логистики. Интервью показалось мне интересным как с точки зрения гостя и его стремительной карьеры, а также некоторых идей, которыми он поделился на подкасте

1. Путь от стажёра к CEO
Валерий рассказал о своём необычном карьерном пути, который начался с увлечения программированием ещё в четвёртом классе. Ключевым моментом стало знакомство с олимпиадным программированием через сайт Codeforces в седьмом классе. Интересно, что в Яндекс он попал случайно - увидел рекламный баннер на Яндекс.Погоде и подал заявку на стажировку, приложив вместо резюме простой текстовый файл со словами «Я олимпиадник»
2. Видение универсального ИИ-ассистента
Валерий представил амбициозное видение будущего Алисы - создание универсального искусственного интеллекта, который выйдет за рамки чатовых интерфейсов и станет полноценным помощником в физическом мире. Этот ассистент будет способен выполнять сложные аналитические задачи за минуты, которые сейчас требуют дней работы специалистов
3. Эмоциональный синтез и эмпатия
Одним из главных технических вызовов команды Валерия является разработка технологий эмоционального синтеза. Алиса должна научиться понимать эмоции пользователя по акустическим токенам и подстраиваться под его настроение. Это означает, что виртуальный ассистент сможет не только обрабатывать текст, но и воспринимать интонацию, эмоциональное состояние и реагировать соответствующим образом. Это, кстати, было для меня интересной мыслью - раньше я адаптацию ассистента под настроение человека не особо учитывал в своих размышлениях.
4. Философия менеджмента
Валерий рассказал про свою философиею лидерства, подчеркнув важность постановки амбициозных целей с временными ограничениями. Он считает, что команды должны отказаться от чрезмерной осторожности и научиться принимать решения в условиях неопределённости. Ключевым принципом является создание атмосферы, где "даже внутри компании технологии выглядят как волшебство". Могу отметить, что мне самому не хватает аппетита к риску и это зачастую меня тормозит :(
5. Найм сотрудников
Валерий поделился двумя критериями при найме
- Искренняя заинтересованность в работе - способность кандидата увлечься проектом настолько, что готов работать сверхурочно не по принуждению, а по внутренней мотивации
- Любознательность - постоянное стремление к изучению нового, способность привести примеры того, что человек освоил в последние недели или месяцы
6. Роль менеджера
По мнению Валерия, тезис о том, что хорошие менеджеры просто "собирают команду лучших и не мешают им работать" - это миф. Он подчеркнул, что менеджер должен определять цели, стратегию, мотивировать команду и создавать эффективные процессы
7. Культура инноваций
Здесь Валерий рассказал про концепт "working backwards", что был популяризирован Amazon и про который можно почитать книгу "Working Backwards: Insights, Stories, and Secrets from Inside Amazon", о которой я уже рассказывал.
8. Про Алису и ее будущее
Валерий считает, что Алиса должна стать не просто голосовым помощником, а полноценным универсальным ассистентом с эмпатией, способным понимать контекст, эмоции и решать сложные задачи в различных сферах жизни. Это соответствует недавним обновлениям Алисы, включающим режим рассуждений, работу с файлами и свободное общение на английском языке

В общем, этот эпизод подкаста получился интересным, посмотрим что будет дальше.

#AI #Leadership #Management #Engineering #ML #Agents #Software

[1/2] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Рубрика #AI)

Я достаточно оперативно познакомился с этим whitepaper, где показано замедление разработчиков при использовании AI. Но изначально я не хотел про него писать - методология мне показалось хоть и интересной, но объем выборки аж в 16 инженеров казался мне маловатым для того, чтобы делать громкие заявления о замедлении разработки. Но я поменял свое мнение после того, как посыпались заголовки в стиле "Учёный изнасиловал журналиста" и дальше падкие на громкие заголовки люди начали присылать это исследование с аргументацией "вот они доказательства: усы, лапы и хвост".

После этого я пошел и прочитал не только краткую выжимку с сайта METR (Model Evaluation & Threat Research), но и все 50 страниц основного whitepaper, где авторы описали всю методологию эксперимента, свои мысли о результатах и их причинах (конечно, без стат значимости) и даже инструкции для участников экспериментов. Дальше я поделюсь своими мыслями насчет этого эксперимента.

Начнем с того, почему это исследование получило столько внимания и тут есть несколько причин
1. Противоречие общепринятому мнению
Результаты исследования прямо противоречат широко распространенному убеждению о том, что AI-инструменты неизбежно повышают продуктивность разработчиков. Исследование показало, что AI-инструменты фактически замедляют опытных разработчиков на 19%, что стало шокирующим открытием даже для самих авторов.
2. Методологическая точность
Авторы провели исследование используя рандомизированные контролируемые испытания (фактически, a/b тест) для оценки реального влияния AI на продуктивность разработчиков в их обычной рабочей среде. Исследование отличается от предыдущих работ использованием фиксированных задач и опытных разработчиков, работающих в знакомых кодовых базах. Правда, тут участники знали про сам эксперимент, а значит мог проявляться эффект Хоторна
3. Актуальность для индустрии
Результаты исследований про влияние AI имеют огромное значение для оценки многомиллиардных инвестиций в AI-инструменты для разработки. Предыдущие исследования по другому подходили к оценке эффекта и все поголовно показывали увеличение продуктивности. А это исследование поднимает вопросы о реальной окупаемости инвестиций в AI-инструменты разработки.

Продолжим тем, а почему нам стоит доверять исследователям из METR.
Начать надо с того, что METR - это некоммерческая исследовательская организация, специализирующаяся на оценке возможностей фронтирных AI-систем и их потенциальных рисков. Организация работает с ведущими AI-компаниями, включая OpenAI и Anthropic, и сотрудничает с государственными институтами AI-безопасности. В группу исследователей входили технические сотрудники Joel Becker, Nate Rush, David Rein, а также Beth Barnes - основатель и главный исследователь METR, бывший исследователь OpenAI и DeepMind, ведущий эксперт по AI-безопасности и оценке AI-систем.

И как же выглядела методология рандомизированных контролируемых испытаний?
- Участвовали 16 опытных разработчиков open-source проектов со средним опытом работы с репозиториями 5 лет и 1500 коммитов в среднем.
- Решали они 246 реальных задач из крупных open-source репозиториев (в среднем 23,000 звезд, 1,100,000 строк кода).
- Дизайн эксперимента предполагал, что каждая задача случайным образом назначалась в одну из двух групп
-- AI-разрешенная группа: разработчики могли использовать любые AI-инструменты (преимущественно Cursor Pro с Claude 3.5/3.7 Sonnet)
-- AI-запрещенная группа: использование генеративного AI запрещено
- Измерялось время выполнения задачи, что разработчики отслеживали самостоятельно. Дополнительно собирались записи экрана, интервью и детальная аналитика использования AI.
- Помимо этого все задачи проходили стандартный процесс code review и должны были соответствовать высоким стандартам качества репозиториев.

Про результаты и почему его результаты надо воспринимать с осторожностью я расскажу в продолжении.

#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes

[2/2] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Рубрика #AI)

Продолжая пост про исследование, расскажу про полученные результаты
- Было получено статистически значимое замедление на 19% при использовании AI-инструментов с 95% доверительным интервалом
- Авторы отдельно указали на ограничения обобщаемости этих выводов
-- Опыт разработчиков. Результаты специфичны для опытных разработчиков (5+ лет опыта с репозиториями). Для менее опытных разработчиков результаты могут быть противоположными.
-- Размер и сложность кодовых баз. Исследование проводилось на крупных, зрелых проектах (1M+ строк кода). На меньших или новых проектах AI может показать положительный эффект.
-- Знакомство с проектом. Разработчики работали в знакомых им репозиториях.
-- Тип задач. Задачи уже были декомпозированы до размера не больше 2х часов, что может не отражать весь спектр разработческих задач.
-- Внешняя валидность. Результаты не означают, что AI-инструменты бесполезны во всех контекстах разработки.

По результатам авторы сдели следующие выводы
1. AI-инструменты замедляют опытных разработчиков на 19% при работе в знакомых кодовых базах, что противоречит ожиданиям как разработчиков (предсказывали ускорение на 24%), так и экспертов (предсказывали ускорение на 38-39%).
2. Также они поразмышляли насчет факторов замедления, выделив 5 основных, хотя и сделали такую ремарку

However, we strongly caution against over-indexing on the basis of any individual pieces of evidence, as we are not powered for statistically significant multiple comparisons when subsetting our data. This analysis is intended to provide speculative, suggestive evidence about the mechanisms behind slowdown.

Вот эти факторы
- Чрезмерный оптимизм относительно полезности AI
- Высокая знакомость разработчиков с репозиториями
- Большие и сложные кодовые базы
- Низкая надежность AI (принимается <44% предложений)
- Неявный контекст репозиториев, недоступный AI

В итоге, авторы подчеркивают, что результаты не означают, что AI-инструменты бесполезны.

А теперь поговорим про проблемы исследования и почему его результаты надо воспринимать с осторожностью
1. Малый размер выборки
Только 16 разработчиков, что ограничивает статистическую мощность, а также ставит под вопрос репрезентативность выборки относительно генеральной совокупности. Сетап эксперимента не позволил ответить на вопросы, какие факторы повлияли на результаты
2. Краткосрочность
Исследование не учитывает долгосрочные эффекты обучения использованию AI-инструментов.
3. Специфичность контекста
Были выбраны крупные open source репозитории, что говорит о том, что результаты могут не обобщаться на другие типы проектов по размеру или специфике (web, мобильная разработка)
4. Эффект Хоторна
Участники знали о том, что участвуют в исследовании, что могло влиять на их поведение.
5. Субъективность измерений
Время выполнения задач измерялось самими разработчиками, что могло вносить систематические ошибки.
6. Определение продуктивности
Исследование фокусировалось только на времени выполнения, не учитывая другие аспекты продуктивности: качество кода (главное было пройти code review), удовлетворенность работой

Итого, мне кажется сам эксперимент интересным, но я больше верю в измерения практических эффектов в организациях, где есть измерение developer productivity и AI там добавляется в экосистему разработчиков постепенно и через a/b эксперименты на большом масштабе, которые позволяют отследить эффекты. Конкретно, про такие подходы можно почиитать в постах
- Про Google и их подходы из серии статей "Developer Productivity for Humans" (подробнее в постах: 1 и 2)
- Про подход запрещенной в России компании Meta, который они описали в статье "What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time" (подробнее в постах: 1, 2 и 3)
- Ну или на крайний случай можно глянуть мое выступление "Зачем заниматься темой developer productivity в большой компании"

#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes

Tech Lead в AI-команду (Рубрика #AI)

Мы в Т-Банке разрабатываем крутой стартап на стыке Generative AI и финтеха, в котором создаем AI-сотрудника, полностью автономного оператора поддержки. Сейчас у нас есть автономно работающий агент, который уже обрабатывает реальные обращения с прода на небольшом сегменте. Это крутая возможность для staff инженера проявить себя в продукте, который включает в себя передовые технологии. Тут нужен крутой технарь примерно такой, какого я описывал во время круглого стола про техлидов и IC высокго грейда на Techlead Conf. Ну а для того, чтобы иметь возможность претендовать на эту позицию хорошо бы знать то, как строятся AI приложения хотя бы на уровне знаний книги "AI Engineering", которую я начал разбирать с Евгением Сергеевым из Flo Health и уже выпустил пару серий подкаста: 1 и 2.

В общем, если вам нравится быть на передовом краю технологий и руками создавать будущее, то пишите моему коллеге, Антону Скогореву (@skogorev).

#AI #Engineering #Staff #Leadership #ML #Data #Software

Дискуссия: RnD на стероидах: вычислительная революция, AI-агенты с суперпамятью и новая эра кибербезопасности (Рубрика #AI)

Появилась расшифровка дискуссии на Conversations, в которой я участвовал месяц назад. Тогда мы говорили о скорости изменений в индустрии и методах отслеживания важных технологических релизов, перспективах вычислительной революции, альтернативах NVIDIA и безопасности LLM, подходах к вайбкодингу в разработке и кейсах применения AI-ассистентов. Для этого обсуждения мы собрались компанией джентельменов
- Илья Карев - Team Lead GenAI Solutions, Just AI
- Сергей Марков - популяризатор науки, директор по развитию технологий искусственного интеллекта SberAI
- Олег Королев - руководитель разработки AI Lab, Авито
- Евгений Кокуйкин - сооснователь Raft и SeoHive Trace
- Александр Поломодов - технический директор, Т-Банк

#AI #Engineering #Software #Processes #Management #RnD

Netflix's Big Bet: One model to rule recommentdations (AI)

Посмотрел вчера интересное выступление Есу Фэна (Yesu Feng) из Netflix про использование генеративных foundation-моделей для персональных рекомендаций. Кстати, Yesu Feng до прихода в Netflix работал в LinkedIn над лентой новостей и в Uber над оптимизацией маркетплейса. Я выделил для себя следующие ключевые идеи

1. Единая foundation-модель для всей системы рекомендаций
Вместо множества специализированных моделей (для разных страниц, жанров, форматов контента) Netflix переходит к одной "базовой" автогрес­сивной трансформер-модели, способной охватить все варианты использования.
2. Масштабирование как основной драйвер качества
Они пришли к этому сформулировав две достаточно логичные гипотезы
- При увеличении объёма данных и параметров модели персонализация улучшается по тем же законам масштабирования, что и у LLM.
- Интеграция этой модели во все подсистемы создаёт синергетический эффект и ускоряет инновации.
3. Особенности данных и обучения
В итоге, модель получилась многоуровневая
- На базовом уровне ребята делали event representation: when, where (locale & device & canvas), what (action type & entity & duration related)
- Дальше был уровень embedding/feature transformation - тут надо было объединять id embedding и дополнительные semantic embeddings, чтобы решать проблему холодного старта (например, новый контент)
- Следующий уровень содержал transformer/attention - hidden state layers отсюда использовались в качестве user representation, надо было гарантировать стабильность репрезантации пользователей, также надо было уметь явно адаптироваться под разные цели пользователей, также надо было понять как агрегрировать разные уровни и разные sequence для получения этой репрезентации
- На верхнем уровне располагалась objective loss function, которая была сложной - так как на выходе LLM было несколько последовательнотельностей (sequences) - это давало мультизадачностью на уровне функции потерь (предсказание типа действия, длительности сеанса, устройства и пр.)
-- main objective: entity id
-- auxiliary objectives: action types, entity metadate, duration, device, time
-- reward, weight & mask
4. Уроки из мира LLM
При построении LLM модели ребята набили ряд шишек и они поделились ими
- Много­токенное предсказание для повышения устойчивости к временным сдвигам и фокусировки на долгосрочном поведении.
- Многослойное представление и самодистилляция для стабильности эмбеддингов пользователя.
- Обработка длинных контекстных окон через прогрессивное увеличение длины и разреженное внимание.
5. Сценарии применения foundation-модели
Они пришли к следующим сценариям
- Встраивание как подграф в downstream-модель.
- Экспорт и обновление эмбеддингов пользователей и контента в центральном хранилище.
- Дообучение или дистилляция для узкоспециализированных задач с жёсткими требованиями по задержке.
6. Результаты и выводы
- Масштабирование модели от десятков миллионов до миллиарда параметров подтверждает закономерности роста качества при увеличении данных.
- Внедрение единой модели привело к заметным A/B-выигрышам и консолидации инфраструктуры: ускорилась разработка новых функций и снизились дублирующиеся усилия.
- Основная "ставка" Netflix полностью оправдала себя: foundation-модель оказалась масштабируемым и гибким решением для персонализации рекомендации.

Этот подход планируют развивать в следующих направлениях
- Универсальные представления для гетерогенных сущностей (видео, игры, прямые трансляции и пр.).
- Генеративный подбор коллекций при помощи многошагового декодирования.
- Быстрая адаптация через prompt-тюнинг и «мягкие» токены для оперативной смены целей модели.

#AI #Engineering #ML #Architecture #Software #Data

Летняя распродажа в издательстве «Питер» (Рубрика #Sales)

В издательстве Питер очередная распродажа со скидками в 35% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг, причем значительную часть из них прочитал, включая книги
- Data mesh в действии - я прочитал эту книгу с прошлой распродажи и даже рассказал уже об этом. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale".
- Грокаем алгоритмы искусcтвенного интеллекта - я прочитал эту книгу недавно, вот пост про нее
- Настоящий CTO: думай как технический директор - я прочитал эту книгу, рассказал про нее, а потом мы даже с Сашей Шевченко записали эпизод подкаста с обсуждением этой книги
- Грокаем Continuous Delivery - интересная и простая книжка от сотрудницы Google про CI/CD, я ее уже успел ее прочитать и рассказать о ней
- Паттерны проектирования API - я начал читать и рассказал про эту книгу + читал whitepapers от автора насчет API Governance в Google (кратенько об этом тут)
- Чистый Python. Тонкости программирования для профи - решил вспомнить теорию по python
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок. Сейчас я прочитал 150 страничек из нового издания и могу сказать, что книга не ухудшилась:)
- Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас я уже прочитал и рассказал об этом
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT, я ее уже прочел и даже рассказывал оо ней
- Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу
- Распределенные данные. Алгоритмы работы современных систем хранения информации - в девичестве на английском эта книга Алекса Петрова называлась Database Internals и я про нее много рассказывал (1 и 2), а также мы ее обсуждали в подкасте "Code of Architecture"
- Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее.
- Head First Software Architecture (Head First. Архитектура ПО) - простая книга по проектированию и архитектуре для начинающих, я про нее уже рассказал
- Acing the System Design Interview (System Design: пережить интервью) - хорошая книга про system design interview, я про нее уже рассказывал: 1 и 2
- Креативный программист - я решил изучить креативные методы, что могут помочь в решении инженерных задач

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

#Sales

Интегрируем AI в процессы разработки в большой компании (Рубрика #AI)

Полтора месяца я выступал с этим докладом на CTO Conf X, но организаторы решили не публиковать доклады. Поэтому я решил его записать для своего канала и рассказать про state of the art-подходы к тому, как разложить работу инженеров на jobs to be done-сценарии, а дальше как уже эти сценарии можно улучшать. В процессе говорю про как классические подходы к написанию кода, так и варианты помощи с проектированием API, проведением code review, запуском тестов, устранением уязвимостей или детекцией аномалий при эксплуатации решений. В докладе будет не только рассмотрение SOTA, но и рассказ о том, что у нас реально работает и как мы подходим к оценке эффекта применения этих методов. В часовом докладе я рассказал про следующие темы

- Введение и план доклада
- История появления AI-копилотов (Copilot и аналоги)
- Что такое vibe coding
- Перспективы AI в разработке, протокол MCP от Anthropic
- Протоколы взаимодействия агентов и проблемы интеграции
- DevOps- и платформенные трансформации в больших компаниях
- Концепция developer experience и снижение когнитивной сложности
- Измерение целей и эффективности разработчиков
- API Governance в Google про AI-Enhanced API Design
- Code review в ByteDance
- Large scale migration при помощи AI в Uber
- Опыт Booking (API, code review, migrations)
- Observability платформа DataDog и AI On-call Engineer
- Подход T-Bank к AI в SDLC
- AI-Copilot Т-Банка Nester и его возможности
- Значение AI для крупных, средних и малых компаний

Кстати, я уже делал расшифровку этих докладов в трех частях: 1, 2 и 3

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

Andrew Ng: Building Faster with AI (Рубрика #AI)

Посмотрел интересное выступление Эндрю Нг на AI Startup School от Y Comibnator. Эндрю является соучредителем и главным партнером AI Fund, соучредителем и председателем Coursera, основателем DeepLearning.AI, а также адъюнкт-профессором Стэнфордского университета. Интересно, что AI Fund - это венчурная студия, созданная в 2018 году, которая работает как "со-основатель" стартапов, помогая предпринимателям строить AI-компании с нуля.

1. Скорость как главный фактор успеха
Способность управленческой команды к быстрому выполнению задач является сильным предиктором успеха стартапа. Интересно, что большие компании не настолько зависят от скорости, но зато они могут действовать с большим рычагом (например, за счет дистрибуции на текущую аудиторию)
2. Стек искусственного интеллекта
Эндрю представил структуру AI-стека, состоящую из пяти уровней
- Полупроводниковые компании (базовый уровень)
- Гипермасштабируемые облачные сервисы
- Компании-разработчики базовых моделей
- Уровень агентной оркестровки (новый слой)
- Прикладной уровень (где находятся наибольшие возможности)
Причем прикладной уровень (apps layer) должен быть наиболее ценным, поскольку приложения должны генерировать достаточно дохода для поддержки всех нижележащих уровней.
3. Революция агентного ИИ
Агентные рабочие процессы представляют собой итеративный подход к решению задач, при котором AI-система может планировать, исследовать, пересматривать и улучшать свою работу. Вместо линейного создания контента агентные системы могут:
- Создавать план
- Проводить исследования
- Писать черновики
- Критически оценивать результаты
- Пересматривать и улучшать работу
4. Конкретные идеи против расплывчатых
Эндрб подчеркивает важность конкретных идей - идей, настолько детализированных, что инженер может их реализовать немедленно. Например:
Расплывчатая идея: «Использовать ИИ для оптимизации активов здравоохранения»
Конкретная идея: «Создать ПО для онлайн-бронирования слотов МРТ в больницах»
Конкретные идеи обеспечивают скорость, поскольку команда может быстро их реализовать и получить обратную связь. Забавно, что часто в корпорациях говорят про расплывчатые идеи - их можно вкидывать легко и все с ними согласны, но когда наступает время их реализовывать, то упсс
5. Трансформация разработки с помощью ИИ-помощников
Здесь было интересно услышать оценки Эндрю о том, как AI-ассистенты влияют на разработку
- Производственный код: улучшение на 30-50%
- Быстрые прототипы: ускорение в 10+ раз
Инструменты эволюционируют от автозавершения кода (GitHub Copilot) до высокоагентных помощников (Claude Code, новые версии с o3).
6. Сдвиг узких мест в разработке
С ускорением разработки софта основным узким местом становится управление продуктом. Эндрю отмечает изменение традиционных соотношений: вместо 1 продакт-менеджера на 4-7 инженеров, некоторые команды предлагают 1 продакт-менеджера на 0,5 инженера. Походу, это характерно для стартапов из AI Fund.
7. Важность открытых моделей
Эндрю выступает за защиту открытого исходного кода в области ИИ, предупреждая о попытках некоторых компаний создать регулирование, которое установит их в качестве "привратников" больших языковых моделей.

Вот такие советы можно вывести из выступления Эндрю
- Сосредоточьтесь на конкретных идеях - избегайте расплывчатых концепций
- Изучите программирование - даже нетехнические роли выигрывают от понимания кода
- Получайте быструю обратную связь - от личной интуиции до тестирования с незнакомцами
- Углубляйтесь в понимание AI - технические решения могут сэкономить месяцы работы
- Используйте разные тактики для получения обратной связи от пользователей

Отдельно стоит отметить, что Эндрю критикует шумиху вокруг AI, включая
- Угрозы человеческому существованию (безопасность ИИ зависит не от технологии, а от ее ответственного применения.)
- Массовую потерю рабочих мест
- Необходимость только ядерной энергии для ИИ

В общем, это очень дельное выступление с интересными мыслями.

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