[2/2] The Mythical Man-Month (Мифический человеко-месяц)

Продолжая рассказ про классическую книгу Брукса (1 и 2), расскажу про то, в какую сторону его идеи можно развивать сейчас

1) Для профилактики задержек в графике сдачи проекта
- Не стоит копить техдолг, который выстрелит ближе к сдаче проекта
- Не стоит использовать мифические человеко-месяцы, а взять метрики реальной производительности: cycle time, throughput и другие
2) Архитектурные принципы
- Стоит поддерживать концептуальную целостность с самого начала проекта - я бы тут предложил использовать RFC (request for comments) для обсуждения архитектурных вопросов, решения фиксировать в ADR (architecture decision records). Я про это как-то рассказывал в докладе про масштабирование архитектурных процессов лет 5 назад
- Также стоит инвестировать в документацию, положить ее поближе к коду и максимально автоматизировать
3) Коммуникации
- Желательно сократить по максимуму встреча, а те что исчезли перевести в асинхронный режим, а значить писать больше документов и комментить их асинхронно
- Выделять сфокусированное время для работы - это позволит не рвать поток работа (flow state)
4) Масштабирование команд
- Здесь я просто рекомендую глянуть подход из Team Topologies, который хорошо описывать типа команд и форматы их взаимодействия. Про эту книгу я много рассказывал и даже разбирал в первой серии подкаста Code of Leadership вместе со Стасом Халупом, моим бывшим коллегой
- По-факту, тут получается 2 основных типа команд: stream-aligned и platform. Первая наносит бизнесовую пользу, а вторая делает платформенные инструменты, что используют stream-aligned команды
- Ну и важно учитывать числа Донбара для понимания границ масштабирования из-за накладных расходов на коммуникации

Если подводить итоги, то книга Брукса до сих пор не устарела и может быть применена к современным проблемам. Несмотря на то что Agile и DevOps решают проблемы *случайной сложности*, его предупреждения о перегрузке ресурсами и фрагментации дизайна остаются актуальными. Команды достигают устойчивой продуктивности благодаря балансу автоматизации и процессов, ориентированных на людей — подтверждая взгляд Брукса на разработку ПО как на процесс, прежде всего зависящий от человеческого фактора. В условиях роста масштабов распределенных систем возвращение к идеям *Мифического человеко-месяца* предлагает как предостережения, так и вдохновение: инструменты меняются, но динамика команд определяет успех проекта.

#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps

#60 – Agile Metrics (Рубрика #Management)

Наткнулся тут на очередной комикс от Comic Agile на этот раз на тему метрик, которая является очень интересной. Авторы комикса заслуженно иронизируют над velocity, burndown, predictability, lead time и business value, обыгрывая стандартные способы покраски этот метрик в зеленый. Дальше они отмечают, что эти метрики могут помогать с идентификацией зон для улучшений, но по их скромному мнению есть 2 метрики, что стоит мерить
- NPS (net promoter score) - удовлетверенность клиентов
- The hapiness of team members - удовлетворенность членов команды
Забавно, что NPS - это супер-общая метрика, которую сейчас берут все и используют по принципу "не знаешь что показывать по продукту - покажи NPS". А вторую метрику авторы предлагают мерить при помощи Spotify Squad Health Check, про который я рассказывал раньше (1 и 2). Интересно, что эти метрики как и остальные приведенные в обсуждении могут быть испорчены, например, продукт есть и пользователи им довольны, команда тоже довольна своей работой, только фичи не катятся - а смысл напрягаться, когда NPS высокий:) Но дальше авторы говорят коронную фразу про outcome

We must remember that working agile is a means to an end and not the goal, itself. Therefore, thinking about what outcome we want by working agile is what we should measure.

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

#Management #Leadership #Engineering #Software #Metrics

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