Code of Leadership #29 "Think like a CTO" (Рубрика #Management)

В очередном выпуске подкаста Code of Leadership обсуждается неоднозначная книга "Think like a CTO" ("Думай как CTO"). В разборе помогает крутой гость, Саша Шевченко. Саша - мой коллега, который является техническим руководителем в управлении цифровых экосистем. Возглавляет 10+ продуктовых команд мобильного банка. Под его управлением развивается главный экран и приватный профиль, треки UX, ESG и не-клиентов, и другие ключевые продукты и сервисы. Кстати, я уже рассказывал про эту книгу в двух частях: 1 и 2

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


За час мы успели обсудить темы
- Роль и зоны ответственности CTO
- Жизненный цикл компании и как меняется роль CTO
- Управление ожиданиями и коммуникация
- Формирование команды и её управление
- Технологическая стратегия и долгосрочное видение
- Управление бюджетом и проектами
- Качество инженерных практик: QA, reliability, security, ...
- Процессы и важность документации
- Саморазвитие и подготовка преемника

Рекомендации для изучения от Саши Шевченко

Управление
- "Идеальный руководитель" | Адизес Ицхак - подробнее в моем посте
- "Карьера Software Engineering Manager" | Стэньер Джеймс - есть у меня на полке, но пока не прочитал
- "The Elegant Puzzle" ("Элегантная головоломка") | Уилл Ларсон - разбирали вместе с Eugene Sergueev в эпизодах Code of Leadership 9 и Code of Leadership 10

Лидерство
- "Вызов лидерства. Пять практик выдающихся руководителей" | Джеймс Кузес, Барри Познер
- "Turn the ship around" ("Разверните ваш корабль") | Дэвид Марке - разбирали вместе с Екатериной Шестимеровой в Code of Leadership 4
- "The Five Dysfunctions of a Team" ("Пять пороков команды") | Патрик Ленсиони - разбирали вместе с Андреем Соколовым в Code of Leadership 16
- "Servant Leadership", "Ситуационное лидерство", "Management 3.0" - книгу про "Management 3.0" я прочитал на 2/3 пару лет назад, но не смог дочитать из-за феерического количества отсылок на другие книги от автора

Создание команд
⁃ "Team Topologies" | Skelton Matthew - разбирали со Стасом Халупом в Code of Leadership 1
- "Реальные полномочия. Самостоятельность сотрудников как ключ к успеху" | Шоул Джон
- "Шесть гениев команды" | Патрик Ленсиони - есть у меня на полке, но пока не читал
- "Уроки выдающихся лидеров" | Питер Симс
- Модель Такмана
- Обратный маневр Конвея

Разработка
- "Learning DDD" ("Изучаем DDD предметно-ориентированное проектирование") | Хононов В - я много писал про книгу и даже обсуждал ее с автором
- "Accelerate" ("Ускоряйся!") | Форсгрен Николь - разбирали вместе с Игорем Курочкиным в Code of Leadership 13
- "Site Reliability Engineering" | Бейер Б - я уже рассказывал про книгу
- "Building Secure and Reliable Systems" ("Безопасные и надежные системы") | Адкинс Х. - я уже рассказывал про эту книгу
- Data Mesh. Новая парадигма работы с данными | Дегани Ж.

Романы про разработку
- Проект «Феникс» | Джин Ким - обсуждали книгу с Иваном Михеевым в Code of Leadership 5
- Цель. Процесс непрерывного улучшения| Голдратт -
- Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения | ДеМарко Том

Управление изменениями
- Наш айсберг тает. Как добиться результата в условиях изменений | Коттер - я уже рассказывал про эту книгу
- Восхождение по спирали. Теория и практика реформирования организаций | Марк Розин

В книге так же есть отсылки к
- Думай медленно... решай быстро | Даниэль Канеман - я уже рассказывал про эту книгу
- Невозвратным затратам или эффекту Конкорда
- Кривой Гартнера - недавно рассказывал про нее

#Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture #SelfDevelopment

[1/2] This Year in Uber’s AI-Driven Developer Productivity Revolution (Рубрика #DevEx)

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

- Uber - это крупная мультинациональня компания с распределенными командами, 156+ млн MAU, 30M поездок в день, 10к городов
- В компании есть IDP (internal developer platform), внутренняя платформа разработки, которая помогает инженерам в их деятельности
- Ребята в платформе фокусируются не на тулинге, а на удобстве инженеров и ориентируются на NPS (net promoter score)
- Uber сталкивается с проблемами техдолга и необходимости миграций кодовой базы, также у них сейчас тоже есть тренд на flat headcount и "do more with less". В итоге, они решили фокусироваться на использовании AI для повышения продуктивности инженеров
- Для решения этих задач была создана отдельная платформенная команды для работы на AI developer experience, которая включает инженеров из всех платформ + специалистов в ML, которые предоставляют модели и абстракции для создания инструментов на основе ИИ.
- Uber практикует AI-хакатоны еще с 2022 года, а сейчас строит свои агентские решения строит на LangChain
- Фокус в применении AI в SDLC был на трех моментах: coding assistance, generating tests, java to kotlin migrations

——— Code assistance ———

- В качестве coding assistant в Uber использовали Copilot, но потом возникла гипотеза, что нужен свой ассистент с дообученной на своем коде моделью. Для этой модели выставили критерии успешности: +10% acceptance rate, latency меньше 1s на 100 токенов, экономическая эффективность, а также интеграция ассистента в рабочие процессы. Проект включал разработку MVP и оценку эффективности различных AI решений
- Проект потребовал много ресурсов и времени, но за полгода MVP было готово. Дальше авторы оценили результаты и решили остановить проект с такими выводами

- MVPs are easy, productionisation is hard
- Latency requirements vary per tool
- User Experience matters
- UI surface cannibalization is a risk
- Follow ecosystem principle
- Continuously evaluate landscape

- Вывод был в том, чтобы использовать индустриальные инструменты, но смогли переиспользовать из своего MVP части про
-- Code context gathering - Summarize & rank code context to provide best input to use-cases (data race fixer, linter warning fixer, crash fixer)
-- Gather telemetry
-- Fine-tuned LLM - Custom model with knowledge of internal libraries, custom frameworks, and company-specific best practices
- Помимо ассистента по коду ребята сделали ассистента для вопросов по базе монореп, которых в Uber 6:) Также ребята проводят воркшопы для обучения инженеров лучшим практикам использования AI, а также активно евангелизируют подход внутри
- В будущем планируют добавить
-- Интеграция с платформами, такими как VS Code и Xcode.
-- Vendor fine tuning и дополнительные возможности по расширению функционала ассистента
-- Использование инструментов для аналитики и рабочих процессов

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

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

[2/2] This Year in Uber’s AI-Driven Developer Productivity Revolution (Рубрика #DevEx)

В продолжении рассказа, я опишу подход ребятк генерации тестов и миграциям

——— Generating tests ———
- Ребята используют стандартную пирамиду тестирования, где сквозные тесты на вершине, модульные тесты внизу
- Собственно вот идеи для использования AI в тестировании:
-- Сквозное тестирование при помощи AI-агентов. Забавно, что мы у себя пытались лет 5 назад прикрутить crowd тестирование, где e2e проверяли ребята из Klex, нашего внутреннего инструмента типа Я Толоки. А сейчас мможно не крауд привлекать, а AI агентов
-- Анализ качества тестов (мутационное тестирование)
-- Предиктивный выбор тестов для ускорения прогонов
-- А на нижнем уровне можно использовать AI для генерации unit тестов
- Так ребята сделали Autocover с фокусом на регрессионных тестах, повышения code coverage и оставляя разработчиков в цикле взаимодействия с autocover (keep the developer-in-the-loop). Интересно, что ребята делят этапы работы над тестами на детерменистические, а также на вероятностые

——— Java to Kotlin migration ———
- В Uber исторически было много Java кода, постепенно ребята подсели на Kotlin и потом решили полностю мигрировать на него
- Платформенная команда сделала инструмент миграции и предоставила его продуктовым командам в децентрализованном режиме
- Если это делать это постепенно и в ручном режиме, то это миграция закончится где-то за 10 лет, что не попадало в ожидания
- Ребята решили это автоматизировать причем с использованием AI
- Для этого они решили объединить подходы на основе анализа AST (abstract syntax tree) и LLM для улучшения правил работы с AST деревьями
- Этот подход позволил им ускорить процесс миграции где-то на порядок

Итого, ребята в Uber оптимистично смотрят на применение AI в SDLC, но отмечают, что важно правильно выбирать метрики для оценки эффекта улучшений и их побочных эффектов. Они предлагают использовать метрику времени сэкономленного для разработчиков (saved developer hours). Мне это напомнило метрику на часы просмотренного видео через Youtube. Подробнее в моем обзоре книги "Like, Comment, Subscribe" ("Youtube. Как самый популярный видеохостинг завоевал мир?").

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

Митап "AI в Software Engineering" в Т-Банке (Рубрика #AI)

Вечером 4 марта в офисе Т-Банка в Москве пройдет митап о том, как AI трансформируют инженерные практики. На митапе будет разговор о том, куда движется RnD в разработке софта и какие у нас есть результаты на этом пути. Мои коллеги продемонстрируют реальные примеры внедрения AI в разные этапы SDLC (software development life cycle). Также будет разговор о том, какие это риски несет: новые security-уязвимости, снижение квалификации инженеров, а также фокус на качестве поддержки AI-генерируемого кода. В митапе примут участие эксперты из RnD центров и техлиды индустрии. В общем, на митапе будет полезно и интересно.

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

#AI #Software #Engineering #Architecture #RnD

Emerging Patterns in Building GenAI Products (Рубрика #AI)

Интересная статья от Мартина Фаулера и Bharani Subramaniam, в которой ребята рассказывают в формате паттернов про базовые кубики, из которых строятся GenAI приложения. Эта статья характерна для текущего Фаулера - в ней нет совсем ничего нового, но достаточно четко описано то, что уже известно на текущий момент:) Сейчас в списке паттернов присутствуют только те, что приведены ниже, но авторы обещают его постепенно пополнять.

- Direct prompting - пропмптинг из приложения foundation LLM. Не уверен, что это тянет на паттерн, но авторы походу в этом уверены. Думаю, что это примерно как вызов функции назвать дизайн паттерном:)
- Embeddings - здесь авторы рассказывают о переводе текста или картинки в вид многомерного вектора так, чтобы близкие по сути сущности были близки в этом многомерном пространстве. Метрика близости может быть разная, но часто это cosine similarity, когда мы смотрим насколько векторы соноправлены. В примере само преобразование текста в embedding происходит через вызов библиотечной функции (и инженерам не надо думать о том, а как она работает под капотом). Суть в том, что эти embeddings нужны и самой LLM и их также можно дальше использовать для поиска по векторной базе данных. Рекомендую глянуть доклад "A Fun & Absurd Introduction to Vector Databases - Alexander Chatzizacharias - GOTO 2024", про который я рассказывал раньше
- Evals - здесь авторы рассказывают про оценку ответов LLM в контексте конкретных задач. По-факту, это напоминает тестирование обычного софта, но со звездочкой. Звездочка обусловлена тем, что ответ LLM не детерминирован, а значит тестировать в лоб "запрос - ответ" не получится, а надо делать что-то типа нагрузочного тестирования, когда мы тестируем performance модели в плане семантики и точности ответа. Для этого нужны сценарии + ожидания от ответа + какой люфт мы разрешаем в отклонениях от этого ответа.
- Hybrid retriever - здесь авторы рассказывают, что можно комбинировать ответы от векторной базы данных при поиске близких сущностей в плане embeddings с более каноническим поиском, условно, full text
- Query rewriting - можно использовать LLM#2 для того, чтобы переписать промпт и дальше несколько его вариантов скормить LLM#1. Это в теории позволяет улучшить промпт, причем LLM#1 и LLM#2 могут быть как одной и той же LLM, так и разными. Например, LLM#2 может быть обучена делать хорошие промпты из плохих, а LLM#1 отвечать качественно на промпты
- Reranker - При поиске данных может возвращаться много документов, а контекст моделей пока не резиновый, поэтому есть вариант отдельно отранжировать найденные документы и только нужные прокинуть в контекст запроса для LLM
- Retrieval augmented Generation (RAG) - этот паттерн про то, что можно не просто просить LLM сгенерировать ответ, но и позволить ей сделать поиск информации, а дальше найденную информацию прокинуть в контекст запроса. В рамках этого паттерна мы можем использовать Hybrid retriever, Reranker, Query rewriting

Про файнтюнинг моделей обещали написать в следующих сериях, возможно, потом допишут что-то и про агентов.

В общем, статья полезна именно инженерам, чтобы понять базовые примитивы GenAI приложений.

P.S.
Про статью я узнал из канала @startup_architecture моего коллеги, Антона Скогорева, который является техдиром у нас в AI Центре.

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

Финансовые результаты МКПАО "Яндекс" за 2024 год (Рубрика #Management)

Сегодня Яндекс опубликовал свои показатели за Q4 и за весь 2024 год, а также прогнозы по вырчке и прибыли на 2025 год. Что можно сказать интересного про группу компаний
- Все показатели на инфографике подросли (если бы не подросли, то их бы не было на инфографике)
- Бизнес-направления агрегируют внутри сервисы, чтобы показывать благополучение направлений в общем, по крайней мере с точки зрения роста
- Проникновение сервисов значительное, поиск 110 млн, go - 53.2 млн, плюс - 39.2 млн
- На инфографике не слишком ясно кто из бизнес-линий является донором денег, а кто реципиентом (и тратит их в качестве инвестиций для развития направления). Условно реклама-поиск зарабатывают и делятся с райдтехом, автономными технологиями, а яндекс плюс как бы связывает экосистему

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

#Economics #Engineering

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

Наконец-то я дочитал и написал разбор этого whitepaper 2022 года, что пролежал распечатанным на моем столе около года. Не могу сказать, что заставило меня остановиться при первом прочтении на полпути, возможно это 16 страниц убористого шрифта, а возможно наличие целых 40 параметров анализа того, что влияет на продуктивность инженеров, но я с этим справился:) Оказалось, что треть этих страниц - это аппендиксы, а из 40 параметров авторы выделили целых 6, что оказались статзначимы и сильно влияли на продуктивность. В условиях Google эти пять параметров такие: code quality, technical debt, infra tools & support, team communications, goals & priorities, org change & process. Собственно, первое место заняло code quality, поэтому его проанализировали поглубже и вынесли в название статьи. Если говорить про статью в общем, то она очень интересная и если вы планируете исследовать тему developer productivity у себя в компании, то очень рекомендую изучить эту статью, так как авторы рассказывают в деталях о методологии, пишут формулы и проводят анализ того, что может нарушить валидность модели (этого часто не хватает во многих других исследованиях, что попроще).

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

What causes improvements to developer productivity in practice?

который для меня кажется похожим н классические вопросы "Кто виноват" и "Что делать"

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

Основной вклад этой статьи в исследования продуктивности - возможность получить более строгий вывод о факторах, что причинно-следственно влияют на продуктивность инженеров. Для этого авторы решают использовать подход под названием "panel data analysis" (панельное исследование). Если объяснять на пальцах, то в таких исследованиях данные собираются за определённое время у одних и тех же групп людей или индивидов, а затем проводится регрессия. То есть в широком смысле панельное исследование - это синоним лонгитюдного исследования.

Стандартным форматом для проведения исследований продуктивности является использование cross-sectional data (перекрёстных данных). Если объяснять на пальцах, то в таких исследованиях данные собираются путём наблюдения за объектами в один и тот же период времени. Обычно это проще всего сделать, бахнув опрос, но тут есть проблемки.

А про них мы поговорим в следующей части обзора.

P.S.
Интересно, что по результатам этого исследования родилась куча отдельных статей на отдельные темы, многие из которых попали в колонку IEEE про developer proudctivity, о которой я уже рассказывал. Причем эту колонку видут соавторы рассматриваемой в этом посте статьи:)

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

Majorana 1 Explained: The Path to a Million Qubits (Рубрика #PopScience)

Интересное видео от Microsoft про квантовые вычисления и их прорыв в этой области. В общем, квантовые вычисления с нами уже давно, но обычно это здоровенная сильно охлажденная штука в которой несколько десятков кубитов (квантовых битов). А тут ребята из Microsoft рассказывают, что они 17 лет исследовали исследовали и наисследовали новый материал, что помогает организовать топологические кубиты (надо будет отдельно изучить что это и как работает). Этот материал позволяет получить миллион топологических кубитов при комнатной температуре, но пока получено всего восемь. Но это proof of concept, где мы получили 2^3, а обещают, что будет 2^20. Всего лишь надо от 3 до 20 дойти в степени двойки:) Но если вернуться к тому, а почему все так ждали квантовый компьютер, то такие вычисления в перспективе позволят гораздо проще моделировать поведение субатомных частиц, что очень хорошо повлияет на материаловедение, создание новых лекарств и так далее. В общем, на все те области, что сейчас слишком сложно точно считать на классических компьютерах с архитектурой фон Неймана.

Отдельно интересно почитать биографию ученого, в честь которого назван чит. Этторе Майорана был гениальным физиком-теоретиком, что публиковал работы в 30-е годы и предсказал существование особого типа фермионов, которые являются своей собственной античастицей. А лет 15 назад физики наметили путь реализации этих частиц на практике, дальше прошло еще сколько-то лет и Microsoft выпустило этот чип Majorana 1. Интересно, что сам Этторе не стремился к славе - он пропал без вести в 1938 году, но есть документальные подвтерждения, что с 1955 до 1959 он жил в Вэнесуэле, а потом его следы потерялись.

#PopularScience #Physics #Math #Engineering #Software

Jeff Dean & Noam Shazeer – 25 years at Google: from PageRank to AGI (Рубрика #AI)

Интересное интервью двух легендарных инженеров Google раскрывает трансформацию компании от стартапа до лидера в области искусственного интеллекта. Джефф Дин и Ноам Шазир, проработавшие в корпорации суммарно почти 50 лет, поделились инсайтами о технологической эволюции, текущих проектах и будущем AI.

Эволюция Google и личный опыт
Рост компании от 25 сотрудников до технологического гиганта сопровождался сменой парадигмы управления. Дин вспоминает этапы: от личного знакомства со всеми коллегами до системы управления через проектные метрики. Шазир подчеркивает уникальность ранней культуры Google, где он начинал под менторством самого Дина, разрабатывавшего базовую инфраструктуру компании. Интересно, что Ноам дважды покидал компанию (с разницей примерно в 12 лет), что стало внутренней шуткой. Его последнее возвращение стоило корпорации $2.7 млрд по условиям сделки с Character.AI.

Развитие ИИ-технологий
Основное внимание в интервью уделено проекту Gemini — флагманской системе AI Google. Разработчики раскрывают три ключевых аспекта:
- Архитектурные инновации: переход от монолитных моделей к модульной системе с асинхронным обновлением компонентов. Это позволяет улучшать отдельные модули без полного переобучения системы.
- Контекстное окно: работа над расширением до триллионов токенов, что во много раз превосходит текущие показатели. Эксперименты показывают, что модели с увеличенным контекстом демонстрируют элементы долгосрочного планирования.
- Экономика вычислений: стоимость ИИ-операций снижена в 100 раз по сравнению с чтением электронной книги и в миллион раз относительно найма разработчика. Это достигнуто за счёт новых TPU 5-го поколения, оптимизированных именно для inference.

Практическое применение
25% кода Google уже генерируется ИИ через специальную версию Gemini, обученную на внутренней кодовой базе. Внедрена система MENA — корпоративный чат-бот, предшественник ChatGPT, используемый сотрудниками с 2021 года. Шазир отмечает парадокс: несмотря на публичную сдержанность, Google десятилетиями инвестирует в ИИ, начиная с пионерских работ по статистическому машинному переводу и спелл-чекингу на основе веб-индекса ещё в 2000-х.

Будущие направления
- "Органические" архитектуры: разработка систем с самоадаптацией, где разные модули специализируются на конкретных задачах (язык, код, планирование).
- Мультиагентные системы: управление тысячами параллельных агентов с персонализацией через интеграцию персональных данных (email, документы, метрики здоровья).
Аппаратные инновации: проектирование чипов, где ИИ автоматизирует 80% процесса разработки, сокращая цикл с 3 лет до 9 месяцев.

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

#AI #Engineering #Software #History #Management #Architecture

Манюня: День рождения Ба (Рубрика #Kids)

В прошлые выходные мы были с детишками на только что вышедшем фильме "Манюня: День рождения Ба", который основан на книгах Наринэ Абгарян, про которые я уже писал. Картина отлично передает атмосферу книги и сочетает в себе ностальгию по детским приключениям, семейные ценности и тонкий юмор. Основой для фильма послужила повесть Наринэ Абгарян «Манюня, юбилей Ба и прочие треволнения» — заключительная часть серии о приключениях трех подруг. Абгарян, известная своими автобиографическими историями, вложила в сценарий личные воспоминания о детстве в армянском городке. Её участие в написании сценария (совместно с Нарой Акобян и Гайком Асатряном) обеспечило экранизации близость к первоисточнику. Например, эпизоды с побегом барана или испорченным тортом напрямую отсылают к книжным описаниям, подчеркивая хаотичное очарование деревенской жизни. Важным элементом стала тема взросления. Если в первых фильмах франшизы акцент делался на шалостях героинь, то в финальной части режиссер и сценаристы исследуют их эмоциональные конфликты. Сцена ссоры Наринэ и Манюни из-за предстоящего переезда последней отражает страх потерять дружбу — мотив, который Абгарян раскрывает через метафору кошмара Наринэ.

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

#ForKids #ForParents #Humor

Whitepaper "Agents" by Google (Рубрика #AI)

На выходных прочел интересный whitepaper на тему агентов от ребят из Google (Julia Wiesinger, Patrick Marlow, Vladimir Vuskovic). В этой статье они описывают фреймвор для создания AI агентов, что способны к автономному принятию решения и взаимодействию с реальным миром. Для этого они описывают как такие системы могут объединять когнитивную архитектуру с LLM моделями, что позволяет обойти ограничения последних. Эта статья напоминает по подходу "Emerging Patterns in Building GenAI Products", про которую я рассказывал раньше. Но статья "Emerging ..." совсем про базу (прямой вызов LLM, prompt engineering, RAG), а эта уже про агентов.

Авторы специализируются на AI инфраструктуре и когнитивной архитектуре, а точнее Julia Wiesinger на обучении агентских систем, Patrick Marlow на иструментах оркестрации, Vladimir Vuskovic на децентрализованных AI системах. Их работа основана на развитии LLM и агентских workflow, а также презентует Google’s Vertex AI как foundational платформу для разворачивания таких систем, поэтому во всех примерах она активно используется. Вообще, ребята в Google определяют агентов как

An autonomous system that observes its environment, reasons about goals, and takes actions using tools to achieve outcomes

Здесь важно, что агент
- Наблюдает за окружением через сенсоры
- Формирует внутреннее состояние через рассуждения
- Выбирает действия через планировщик с использованием инструментов (API, функции, базы данных)

В этом определении фокус не на статических LLM моделях, а на динамическом взаимодействии с внешними данными и инструментами. Вообше, архитектура представляет
1) The model - LLM как центральный процессор для chain-of-thought reasoning;
2) The tools - соединяет агентов с реальным миром через тройку
- Extensions - интеграция с API, исполнение на строне агента
- Functions - генерация кода для исполнения, что выполнеяется на стороне клиента, что вызывает агента
- Data stores - работа с базами данных, которые обычно бывают векторными и для поиска используются embeddings
3) The orchestration layer - управление итеративным размышлением с использованием подходов вида
- ReAct - Reasoning + Acting
- CoT - Chain of Thoughts
- ToT - Tree-of-Thoughts

Сами агенты могут использовать три стратегии обучения
- In-context learning: адптация в реальном времени с использованием промпта и примеров в нем
- Retrieval-based learning: динамичепский доступ к внешней памяти для принятие решений с дополнительным контекстом
- Fine-tuning: специфичное для домена до-обучение (pre-training) для оптимизации во время использования в этом домене

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

У Google есть проект с открытым исходным кодом "Project Oscar" для созданиия агентов для SDLC. Его интересно изучить, так как он фокусируется не на написании кода (что является веселой частью этой работы), а для скучных частей

Oscar is a project aiming to improve open-source software development by creating automated help, or “agents,” for open-source maintenance. We believe there are many opportunities to reduce the amount of toil involved with maintaining open-source projects both large and small.

Если говорить про будущее агентов, то
- Агенты будут независимо управлять вычислительными ресурсами, что сможет снизить зависимость от централизированных платформ
- Агенты смогут в коллаборации решать более сложные проблемы
- Для агентов будут важны вопросы безопасности, чтобы сложнее было эксплуатировать уязвимости API или получать неправомерный доступ к данным в data stores

В итоге, это хороший базовый whitepaper на тему построения агентских систем.

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

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