Code of Leadership #30 - Interview with Vadim Goncharov about T-Bank and management approaches (Рубрика #Management)

В этом выпуске подкаста ко мне опять пришел Вадим Гончаров, мой коллега, с которым мы обсудили его путь в Т-Банке. Вадим в веб-разработке больше 15 лет. В 2008 руководил собственной веб-студией. С 2013 работал в VK, а в 2017 присоединился к Т-Банку, где в качестве технического руководителя запускал самое крупное медиа про деньги в России: Т—Ж. А с 2020 Вадим года руководит разработкой интерактивных спецпроектов и игр в мобильном приложении Т-Банка. Он проповедует lifelong learning: закончил МИЭМ, учился в Британке и Вышке, а сейчас учится в Сколково на программе МБА. Этот выпуск продолжает "Code of Leadership #28", где мы обсудили работу Вадима до Т-Банка, а также важность дизайна в разработке. Ну а здесь мы говорили про

- Появление Вадима в Т
- Работа в Т-Журнале и улучшение финансовой грамотности населения и бренда
- Переход к руководству людьми и проблемы выгорания и делегирования
- Спецпроекты в Т-Банке
- Игры и их развитие в экосистеме Т
- Использование моделей управления (DISC, PCM, Hogan)
- Образование и постоянное развитие как залог карьерного и личностного роста

Эпизод доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Management #Leadership #Software #Processes #Retrospective #Design #Processes #SelfDevelopment

Oscar, an open-source contributor agent architecture (Рубрика #AI)

Oscar - это интересный проект от Google про применение LLM-агентов в программировании. Правда, ребята ставят себе целью не генерацию кода, а скорее устранение рутинной работы по поддержанию крупного open source проекта. Суть в том, что написание кода является интересной частью создания софта, а вот обработка входящих issues, сопоставление вопросов с существующей документацией или проверка reports - это все неинтересная часть работы и ее хорошо было бы автоматизировать. Сам проект Oscar является сейчас экспериментом и частью проекта golang, но в будущем может стать отдельным проектом. Изначальной целью было

- Reduce maintainer effort to resolve issues [note that resolve does not always mean fix]
- Reduce maintainer effort to resolve change lists (CLs) or pull requests (PRs) [note that resolve does not always mean submit/merge]
- Reduce maintainer effort to resolve forum questions
- Enable more people to become productive maintainers

Для решения этих задач авторы решили, что у Oscar должно быть три ключевых вощможности
1) Индексирование и отображение связанного контекста проекта во время взаимодействия участников.
2) Использование естественного языка для управления детерминированными инструментами.
3) Анализ отчетов о проблемах, Change list / Pull requests и групповых обсуждений для их улучшения в режиме реального времени во время или вскоре после отправки, а также для их соответствующей маркировки и маршрутизации отчетов

В общем, подход авторов состоит в том, чтобы использовать LLM в том, в чем они сильны, а точнее в семантическом анализе естественного языка и его трансформации в вызовы детерминистического кода для выполнения остальной работы.

1) Индексирование и отображение связанного контекста проекта
Здесь авторы предлагают использовать embeddings и векторые базы данных для индексирования и поиска релевантной информации. Примерно об этом рассказывалось и в других документах: статье Фаулера"Emerging Patterns in Building GenAI Products" (мой краткий рассказ здесь) и Whitepaper "Agents" by Google (мой рассказ здесь). Авторы проекта Oscar отмечают следующие плюсы использование агентов
- The agent surfaces related context to contributors - контрибьюторам сообщается о похожих проблемах, что позволяет не дублировать проблемы
- The agent surfaces related context even to project maintainers - мейнтейнерам бывает полезно увидеть похожие баги и собрать более точную информацию, что позволяет правильно выставить приоритет, закрыть или переоткрыть баг
- The agent interacts with bug reporters immediately - немедленная обратная связь тому, кто зарепортил баг, позволяет собрать больше релевантной информации, так как reporterts готов предоставить доп. информацию в моменте или глубже исследовать проблемное поведение, если его попросить об этом сразу
2) Using natural language to control deterministic tools
Здесь авторы бота оставили точку для расширения, но пока не интегрировали это в бот. Но, по-факту, тут описывается использование tools из фреймворка про агентов, описанного в whitepaper "Agents", про который я уже писал. Например, тут может быть фикс текста репорта или предложение как его пофиксить. Например, вот тут есть whitepaper от ребят из Google "Evaluating Agent-based Program Repair at Google".
3) Analyzing issue reports and CLs/PRs
Здесь авторы опять оставили точку расширения под действия навроде проставления правильного label для issue или проверки правильного заполнения отчета об ошибке. В принципе, тут все достаточно понятно.

Внутри go коммьюнити Oscar представлен в виде бота Gaby ("Go AI bot"), который работает с новыми issues. Интересно, что внутри go коммьюнити есть gopherbot, но он основан на коде, который детермистическом реагирует на команды.

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

Beyond the Hype: A Realistic Look at Large Language Models • Jodie Burchell • GOTO 2024

Джоди Берчилл, developer advocate в JetBrains, в своем выступлении в середине 2024 года представила реалистичный взгляд на большие языковые модели (LLM), их развитие, возможности и ограничения. Она стремилась развеять ажиотаж вокруг LLM и представить сбалансированное понимание их применения.

1. История и развитие LLM
- LLM являются частью долгой истории исследований в области обработки естественного языка (NLP), начиная с автоматизации текстовых задач, таких как классификация и обобщение текстов
- Прорывы в технологиях, такие как CUDA (для обучения нейронных сетей на графических процессорах) и доступ к большим наборам данных (например, Common Crawl), позволили создать более мощные модели.
- Важным этапом стали сети с LSTM (Long short-term memory), появившиеся в середине 2000х годов, которые улучшили обработку контекста, но их ограничения привели к созданию трансформеров.
2. Модели-трансформеры и GPT
- Трансформеры заменили последовательную обработку текста на параллельную, что сделало их более эффективными для NLP.
- Генеративные предварительно обученные трансформеры (GPT) стали основой современных моделей.
- С момента выхода GPT-1 до GPT-4 наблюдается значительное улучшение качества генерации текста:
-- GPT-1 создавал грамматически правильный текст без контекста.
-- GPT-3 начал учитывать контекст и кодировать языковую информацию.
-- GPT-4 достиг 1 триллиона параметров и стал более универсальным.
3. Возможности и ограничения LLM
LLM демонстрируют впечатляющие результаты в задачах NLP, таких как перевод, суммирование текста и ответы на вопросы. Однако они остаются ограниченными:
- Модели могут запоминать обучающие данные вместо обобщения.
- Их способность решать новые задачи зависит от уровня обобщения:
-- Локальное обобщение: работа с похожими примерами.
-- Широкое обобщение: решение задач в разных областях.
-- Крайнее обобщение: выход за рамки человеческих возможностей (недостижимо для текущих моделей).
- Проблема оценки интеллекта моделей связана с фокусом на навыках, а не на базовых способностях.
4. Применение и практические примеры
Джоди продемонстрировала использование LLM для извлечения информации из баз данных с помощью подхода RAG (поисковая расширенная генерация):
- Разделение документов на части, создание вложений и сохранение их в векторной базе данных.
- Преобразование запросов во вложения для поиска релевантных данных.
- Создание приложений для ответов на вопросы с помощью инструментов вроде LangChain.
Пример: поиск информации в документации PyCharm с использованием модели ChatGPT. Про RAG отдельно интересно почиать статью "Emerging Patterns in Building GenAI Products", про которую я рассказывал раньше
5. Оценка производительности и выбор модели
Эффективность моделей зависит от предметной области и варианта использования. Для сложных задач может потребоваться настройка модели или создание специализированных наборов данных, а таблицы лидеров, такие как Huggingface, помогают сравнивать производительность моделей.
6. Ограничения и перспективы
Несмотря на успехи, LLM не достигли уровня искусственного общего интеллекта (AGI). Они требуют тщательной настройки, выбора задачи и оценки производительности. Джоди подчеркнула важность реалистичного подхода к ожиданиям от LLM, сравнив текущие проблемы с теми, что существуют в разработке ПО и машинном обучении десятилетиями.

Таким образом, выступление Джоди Берчилл акцентировало внимание на необходимости трезвой оценки возможностей LLM, их ограничений и практического применения.

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

[2/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)

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

Представим опрос про связь самооценки продуктивности инженеров и воспринимаемого уровня качества кода. Даже получив результаты опросы, у нас эффекты, что мешают вывести причинно-следственную связь между качеством кода и продуктивностью
1) Time-invariant effects - эти эффекты имеют тот же самый эффект в разные моменты времени, например, уровень образования респондентов
2) Respondent-independent time effects - это эффекты, которые влияют на респондентов одинаково, например, сезонные эффекты или крупные инициативы на всю компанию
3) Non-differentiated response effects - это эффекты, когда респонденты склонны давать одинаковый ответ на все вопросы. У одного респондента это может быть средний вариант ответа на все вопросы, а у другого самый высокий.
Но в панельном исследовании есть возможность устранить эти эффекты, анализируя данные за разные промежутки времени, а также есть возможность попробовать установить не только корреляции, но и причинно-следственные связи. Дальше авторы описывают связанные научные работы и показывают как обычно использовались time-series данные и что их можно использовать для ответов на часть вопросов, изначально поставленных в исследовании. Правда, эти эти способы не использовались раньше для анализа developer productivity, а также они не подходят для того типа данных, что используют авторы этого исследования.

Дальше авторы переходят к рассказу о методах панельного исследования, где в качестве источников данных используются
1) Данные из логов использования внутренних инструментов, навроде, данных о редактировании файлов, билдах, работе в системе codee review и так далее. Важно отметить, что эти данные содержат хорошо гранулированную историю о работе инженеров, что точно измерять поведение инженеров и характеризовать используемые ими рабочие практики и задачи, которые они выполняют при этом.
2) Данные лонгитюдных исследований (опросов), которые проводятся посредством EngSat (engineering satisfaction survery). Это долговременные исследования в виде опросов, ответы на которые собираются каждый квартал у трети инженеров. Подробнее про них в отдельном whitepaper "Measuring Developer Experience With a Longitudinal Survey", про который я уже рассказывал.

Дальше описываются зависимые и независимые переменные, которые используются в модели исследования и объясняется как мы строим модель, чтобы ее можно было ответить на изначальные вопросы исследования. В качестве зависимых переменных используются самооценки продуктивности инженеров, которые взяты из опросов. С одной стороны именно эту переменную исследовали в других исследованиях и выявили некоторую корреляцию между субъективным и объективными исследованиями. В качестве объективных метрик были взяты следующие три категории метрик
1) The amount of output (per quater) - тут было 2 метрики: total number of changelists и total lines of code
2) The amount of time per item (changelist) - тут было 2 метрики: median active coding time, median well-clock coding
3) The amount of time for non-productive activities - тут было 2 метрики: median wall-clock review time и median wall-clock merge time

Для анализа авторы собрали данные 6 последовательных кварталов с 2018Q1 по 2019Q2. Для анализа у исследователей накопилось порядка 2к точекк и дальше они построили модельку, что на рандомно выбранных 10% данных для валидации получили 83% precision и 99% recall. Причем основным предиктивным фактором оказался Median Active Coding TIme, что кажется логичным.

На этом этот пост заканчивается, а в следующий раз я расскажу про независимые переменные и модельку целиком.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Andrew Ng Explores The Rise Of AI Agents And Agentic Reasoning | BUILD 2024 Keynote (Рубрика #AI)

Три месяца назад Andrew Ng выступал с keynote докладом про AI Agents и агенсткие размышления. Мне доклад понравился и я решил поделиться саммари с основными мыслями

1) AI как трансформационная технология
Эндрю сравнивает AI с "новым электричеством", подчеркивая его потенциал для создания прорывных приложений. Основной фокус смещается к прикладному уровню, где генерируется основная ценность, благодаря возможности быстрого прототипирования (создание MVP за дни вместо месяцев).
2) Эволюция стек-технологий ИИ
Выделены три слоя:
- Инфраструктура - полупроводники, облачные платформы
- Базовые модели - trainings, foundation models
- Application слой - быстрорастущий сегмент с примерами вроде чат-ботов и автоматизированных рабочих процессов
3) Gen AI как катализатор
Создание приложений с AI возможностями в некоторых случаях ускорилось в 100 раз: создание приложений типа распознавания речи или анализа изображений теперь занимает 3 дня вместо года. Ключевой вызов - оценка эффективности моделей, где внедряются параллельное тестирование и автоматизированные циклы обратной связи.
4) Агентские рабочие процессы — новая парадигма
Представлены 4 шаблона проектирования:
- Reflecation: Итеративное улучшение кода через автоматизированную критику (пример: генерация Python-скрипта с проверкой юнит-тестами).
- Tool use (API calls): Интеграция с внешними сервисами (возврат платежей, отправка email).
- Planning (decide on steps for task): Последовательное выполнение сложных задач (генерация изображения → анализ позы → коррекция).
- Multi-agent collaboration: Коллаборация специализированных агентов (аналитик + дизайнер + тестировщик).
5) Vision Agent - кейс применения
Платформа Landing AI демонстрирует:
- Автоматическую индексацию видео с выделением ключевых кадров (пример: поиск "лыжник в воздухе" среди 10 часов записи).
- Распознавание контекста: Поиск объектов по сложным описаниям ("черный чемодан с царапиной у ручки").
- Генерацию метаданных для тренировки custom-моделей.
6) Тренды будущего
- Революция в обработке изображений/видео по аналогии с текстовым ИИ.
- Рост мультимодальных агентов, способных комбинировать текст, изображения и API-вызовы.
- Смена парадигмы разработки: смещение от hand-coded алгоритмов к оркестровке автономных агентов.

В заключении своего рассказа Эндрю призывает разработчиков экспериментировать с агентскими фреймворками, прогнозируя взрывной рост приложений в компьютерном зрении и мультимедийной аналитике. Ключевой месседж: "Сейчас лучшее время создавать ИИ-продукты, где 90% работы выполняют агенты, а люди фокусируются на высокоуровневом дизайне".

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

[1/2] The learning trap. How Byju's took Indian edtech for a ride (Ловушка обучения) (Рубрика #Management)

С большим интересом я прочитал эту книгу осени 2023 года, в которой подробно рассказано о махинациях гиганта индийского edtech сектора Byju's. Если говорить про саму компанию, то когда-то оценка компании составляла 22 млрд долларов, а сейчас она буквально ничего не стоит. Отдельно отмечу потерянную при переводе игру слов в английском названии книги - основное приложение BYJU's называлось "The Learning App", а автор в своем названии обыграл это через "The learning trap" и получилось очень точно и красиво. Книгу написал журналист Прадип Сахи, который задавал вопросы по поводу бизнес-модели компании и когда она была на коне, но когда начались проблемы он решил оформить свое журналисткое расследование в остросюжетную книгу. Здесь Прадип раскрывает агрессивные маркетинговые тактики, корпоративные провалы и финансовые махинации под руководством основателя Биджу Равендрана, чья империя рухнула из-за обвинений в мошенничестве, неустойчивой бизнес-модели и токсичной корпоративной культуры. К 2025 году BYJU'S столкнулась с процедурой банкротства, потерей 95% стоимости и судебными исками в Индии и США, став поворотным моментом для всего сектора. Последствия включают скептицизм инвесторов, усиление регуляторного контроля и переоценку гиперроста.

Основные моменты истории отмечены ниже
1) BYJU'S когда-то начиналась с офлайн-репетиторства ооснователя компании, Byju Raveendran (Бью Равендрана), в Керале, которое к 2015 году трансформировалось в цифровую платформу. Компания использовала пробелы индийской системы образования, позиционируя себя как инструмент для «средних учеников». Пандемический спрос на онлайн-обучение подстегнул рост: в 2020–2022 гг. BYJU'S поглотила конкурентов, включая Aakash Educational Services ($1 млрд), Epic! ($500 млн) и Great Learning ($600 млн).
2) Стратегия компании основывалась на страхе упустить возможность (FOMO) получения хорошего образования, практиковались следующие вещи
- Хищнический маркетинг: запугивание родителей обещаниями гарантированных результатов с участием звезд (например, Шахрукх Кхана или Леонель Месси)
- Манипуляции метриками: завышение числа подписок через «самопокупки» сотрудников и быстрые возвраты средств.
- Культ личности: харизма Равендрана маскировала операционные проблемы, а его выступления сравниваются с «религиозными проповедями».
3) В компании не было профессионального менеджмента и управления финансами
- Безответственное лидерство: Равендран игнорировал совет директоров, единолично одобряя сделки, включая кредит $1,2 млрд в 2021 г.
- Творческий учет: задержка отчетности за 2022 финансовый год скрыла рост убытков на 81%, аудированная отчетность задерживалась на годы, аудиторы публично отказывались от работы с BYJU's
- Токсичная культура: сотрудники отдела продаж сталкивались с нереальными целями, что привело к массовым увольнениям и психическим расстройствам.

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

#Edu #SelfDevelopment #Management #Leadership #Processes

[2/2] The learning trap. How Byju's took Indian edtech for a ride (Ловушка обучения) (Рубрика #Management)

Продолжая историю компании BYJU's (1 и 2) стоит рассказать о моменте, когда агрессивный рост дал сбой и к чему все это привело.
По мнению автора книги к падению привели следующие проблемы
1) Долговая спираль (2023–2024)
- Рост ставок: повышение ставок ФРС увеличило стоимость долларовых займов BYJU'S.
- Коллапс залогов: BlackRock снизил оценку компании до $1 млрд к декабрю 2023 г., а партнеры заморозили образовательные кредиты.
- Распродажа активов: продажа Epic! и Tynker принесла гораздо меньше, чем было потрачено на их приобретение на пике во времена ковида
2) Юридические проблемы
- Банкротство в США: Судья в США признал перевод средств «прямым мошенничеством», инициировав расследование против Равендрана.
- Процедура несостоятельности в Индии: NCLT начал процесс банкротства в 2024 г., а кредиторы вернули малую долю средств.
- Расследования: индийские органы начали изучать отмывание денег, а против Равендрана действуют запреты на выезд.

Все это повлияло не только на BYJU's, что был лидером edtech сектора, но и на остальные компании
1) Отток инвестиций
- Обвал оценок: Unacademy и Vedantu потеряли больше половины стоимости, а глобальные фонды (Sequoia, SoftBank) сократили вложения.
- Жесткий аудит: инвесторы теперь требуют аудированную отчетность и планы выхода на прибыльность.
2) Регуляторные изменения
- Защита потребителей: Edtech Consortium ввел обязательные возвраты и «периоды охлаждения».
- Этический кодекс: с 2024 г. запрещены гарантии успеха в рекламе и таргетинг на несовершеннолетних.
3) Перестройка рынка
- Гибридные модели: PhysicsWallah и upGrad развивают офлайн-центры, сочетая их с цифровым контентом.
- Нишевая фокусировка: стартапы вроде Scaler и Masai School сместились на профессиональное обучение, избегая K-12 (школьников).
4) Системные последствия
- Ответственность основателей: дело Равендрана стимулировало реформы Закона о компаниях.
- Зрелость сектора: доля edtech на индийском рынке образования ($180 млрд) упала до 3,8% (с 6,2% в 2022 г.).

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

P.S.
Кажется, что российские edtech компании тоже после ковида подсдулись, хотя и не так ярко, как BYJU's.

#Edu #SelfDevelopment #Management #Leadership #Processes

Predictive Synthesis of API-Centric Code (Рубрика #AI)

Я продолжаю изучать темы, связанные с AI в SDLC, что наталкивает меня на статьи вроде "Predictive Synthesis of API-Centric Code" 2022 года. В этой статье Daye Nam и остальные представляют новый подход, enumerative program synthesis для работы с API обработки данных, таких как PyTorch, NumPy и Pandas. Этот подход объединяет человеческую интуицию программирования с автоматизированным синтезом, используя сочетание глубокого обучения (deep learning) и традиционных методов поиска. Ниже я приведу некоторые ключевые моменты статьи

1) Композиционная модель для предсказания последовательностей API
Ключевая идея заключается в том, что код, ориентированный на API, можно синтезировать путем предсказания последовательностей вызовов функций API композиционным способом. Авторы предлагают два варианта моделей:
- First-of-Sequence (FOS): Предсказывает первую функцию API в последовательности на основе свойств входных/выходных тензоров.
- Full-Sequence (FUS): Генерирует всю последовательность вызовов API, необходимых для преобразования входных данных в выходные.
Обе модели используют рекуррентные нейронные сети (RNNs) для кодирования форм тензоров (tensor shapes) и эмбеддингов API, что позволяет им изучать шаблоны по примерам входных и выходных данных.

2) Интеграция с перечислительным поиском (Enumerative Search)
ML-модели интегрируются в перечислительный синтезатор для сокращения пространства поиска. Приоритизируя последовательности API, предсказанные нейронными моделями, время синтеза сокращается в 6–10 раз по сравнению с базовыми методами, такими как DeepCoder.

3) Обработка сложных структур данных
В работе представлены графовые кодировки (graph-based encodings) для представления фреймов данных (dataframes) и тензоров, что позволяет нейронным сетям понимать структурные преобразования. Это особенно важно для таких API, как pandas, где операции включают изменение формы данных, объединение и агрегацию таблиц.

Детали реализации
Датасет: Модели обучаются на синтетических примерах входных и выходных данных, сгенерированных путем выполнения случайных последовательностей вызовов API. Для pandas AutoPandas использует 1.4 миллиона точек данных, охватывающих 119 функций.
Embedding Layers: Кодируют функции API и формы тензоров в плотные векторы.
RNN Layers: Обрабатывают последовательности эмбеддингов для предсказания следующего вызова API или всей последовательности.
Graph Neural Networks (GNNs): Представляют фреймы данных как графы с узлами (столбцы/строки) и ребрами (отношения между ними).

Улучшения алгоритма поиска
Подход объединяет символьное исполнение (symbolic execution) с ML-ориентированной приоритизацией. Для каждого кандидата вызова API система проверяет семантическую корректность (например, совместимость форм тензоров) и использует оценки уверенности модели для приоритизации исследования.

Интересно, что эта whitepaper повлияла на последующие работы
1. Развитие ML-ориентированного синтеза программ
Методология статьи повлияла на инструменты вроде AutoPandas, который использует генераторы на основе нейронных сетей для синтеза преобразований фреймов данных.
2. Вывод типов (Type Inference) и автозавершение кода
Поздние работы, такие как Type4Py и DeepInfer, опираются на идею использования ML для семантических предсказаний

Ограничения и открытые вопросы
- Обобщение на неизвестные API: Модели испытывают трудности с обработкой API, не включенных в обучающие данные; это требует повторного обучения моделей.
- Масштабируемость для длинных последовательностей: Точность предсказаний снижается для последовательностей длиной более 3–4 шагов (что решается иерархическим обучением с подкреплением)
- Интерпретируемость: Black box нейронных моделей затрудняет отладку; это стимулирует исследования в области explainable synthesis.

Интересно, что эта whitepaper была написана до засилья авторегрессионных моделей типа GPT всех версий и больше полагалась на RNN сети, получая пристойные результаты.

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

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

Research Insights Made Simple #9 "What Do Developers Want From AI?" (Рубрика #AI)

В этой серии подкаста речь идет про whitepaper "What Do Developers Want From AI?", про который я уже писал раньше. Для его обсуждения я позвал в гости Николая Бушкова из RnD центра Т-Банка. Николай занимается исследованиями инженерной продуктивности и глубоко погружен в темы того, как AI может улучшать инженерные процессы. Кстати, здесь можно подробнее почитать про RnD центр Т-Банка и о направлении инженерной продуктивности.

Мы обсудили следующие темы
1. Введение в тему: AI и разработчики
2. Метафоры технологических изменений (параллели с электрификацией)
3. Три уровня AI-улучшений (параллели с автомобильной промышленностью)
4. Подходы к измерению продуктивности (комбинация опросов и логов)
5. Code review и роль AI (примеры из практики)
6. Проблемы документации и технического долга
7. Платформенный подход к инструментам
8. Агентные системы и метауровень
9. Исследования продуктивности и сотрудничество (примеры из Google и Т-Банка)

Также мы упоминали и другие научные статьи, которые хорошо ложились в тему дискуссии
1) "Measuring developer goals" от Google - мы его обсуждали в предыдущей серии Research Insights вместе с Сашей Кусургашевым, а также у меня было краткое саммари по нему
2) "Resolving code review comments with ML" от Google - пока я про нее не писал, но скоро будет обзор
3) "BitsAI-CR: automated code review via LLM in practice" от ByteDance, по ней тоже будет обзор
4) "Defining, Measuring, and Technical Debt" от Google - мы его обсуждали в одной из серий Research Insights вместе с Димой Гаевским, а также у меня было краткое саммари этой статьи
5) "Build Latency, Predictability, and Developer Productivity" от Google - у меня было краткое саммари этой статьи

Эпизоды доступны на Youtube, VK Video, Podster.fm, Ya Music.

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

Какие каналы я читаю для получения релевантной информации (Рубрика #Stories)

Я уже рассказывал откуда я беру интересные научные статьи, но это специфический вид контента:) А сегодня я хотел поделиться тем, как я получаю более приземленные знания по интересующим себя темам. Для этого я собрал список таких каналов

#Economics
- @hoolinomics - экономические обзоры с юмором и глубиной, нравится подача автора и школа мысли относительно разбора экономических ситуаций
#AI
- @ai_newz - новости из мира AI, которые подаются с пылу с жару, автор канала сам прикладывает руку к SOTA моделям Meta, а также хорошо знает происходящее в индустрии
- @gonzo_ML - канал с разбором ML whitepapers. Я люблю сам читать whitepapers, но они в основном про software engineering. А вот про ML я знакомлюсь с научными новостями через этот канал.
- @seeallochnaya - хороший канал с AI/ML тематикой, где выходят глубокие и интересные посты с разборами технологий и новинок
- @theworldisnoteasy - крутой канал с обсуждением будущего и футуристичными статьями, очень хорошо расширяет кругозор
#Engineering
- @rockyourdata - много информации про data engineering за рубежом, про Snowflake, Databricks и другие cloud native решения, включая open source, что позволяют увидеть как происходит сдвиг от канонического DWH в сторону Lake House и Data Mesh
- @it_arch - хороший канал по архитектуре Максима Смирнова, которого я знаю как компетентного архитектора. Максим постит индустриальные новости вокруг enterprise, solution и software architecture
- @databaseinternalschat - чат про базы данных - в этом канале есть разработчики популярных баз данных и с ними можно обсудить сложные вопросы работы планировщика, транзакций, оптимизаций и т.д.
- @backend_megdu_skobkah - в чате много ребят, что исполняют роль техлидов/архитекторов в своих компаниях, поэтому можно обсудить сложные вопросы
#T-Tech
- @kod_zheltyi - технические новинки от Т-Технологий - хороший источник новостей из мира российского бигтеха (а конкретнее Т-Технологий)
- @tbank_education - канал про образование от Т Технологий

Изначально список был подлиннее, но потом я понял, что часть каналов у меня висит и я их не читаю, а значит и рекомендовать их не стоит. В общем, остались только те каналы, что я действительно считаю полезными для себя.

#AI #Software #Engineering #Economics