Разработка собственного AI-ассистента для кода: спринт или марафон? (Рубрика #AI)

Недавно у нас прошла конференция Platform Engineering Night, которую открывал Игорь Маслов докладом про "AI и Platform Engineering", основные мысли из которого я уже рассказывал. Но на этой конфе еще был целый ряд выступлений, одно из которых было Дениса Артюшина, который рассказал про то, как мы разрабатываем собственного ассистента Nestor, под которым зонтиком объединяются copilot вещи для SDLC (но первым делом copilot для кода в IDE). Основные мысли выступления были примерно следующими

1. В чем мотивация создания собственного ассистента?
Начал Денис с объяснения, а зачем делать своего ассистента, где были несколько основных моментов
- Безопасность решения, что сложно соблюсти при отправке кода внешним вендорам
- Санкционные риски, которые защкаливают в текущих сложных геополитических условиях
- Необходимость интеграции с внутренней инфраструктурой, которую так и так пришлось реализовывать
2. Как подходить к вопросу: как спринтер или как стайер?
Сначала Денис рассказал про быстрые эксперименты в режиме спринтеров - так ребята запустили commit-сообщения, где от идеи до готового прототипа прошел один вечер пятницы. Схема была простой: берем diff, добавляем примеры, формируем промт и отдаем в модель. А потом он рассказал, что code completion требует серьезной инфраструктуры с A/B-тестами, анализом поведения пользователей и поиском похожего кода в кодовой базе, то есть тут нужен системный и размеренный подход
3. Что умеет Nestor?
Основные фичи сейчас достаточно классические
- Автодополнение кода
- Чат с поиском по внутренней документации
- Генерация commit-сообщений
- Прототип редактирования кода
- Генерация тестов (сейчас в разработке)
4. Какие метрики использования у ассистента?
Они уже впечатляют: WAU: 5k, MAU: 9.5k. В некоторых профессиях проникновение превысило 60%, а acceptance rate поднялся до 30% на Go (пора переходить на go, ведь ассистенты на нем лучше всего ассистируют 😉)
5. Как сделали поиск по документации?
На самом деле про поиск можно посмотреть в докладе Егора Прохоренко, про который я уже рассказывал. Но в Nestor пошли примерно так: структурированная документация → краткие описания → эмбеддинги → поисковая база. Также использовали русскоязычную модель TP Pro для лучшего качества ответов.
6. Как решали проблему масштабирования UI в плагине для IDE?
Первоначальные чаты на TypeScript/CSS и Swing оказались немасштабируемыми. Перешли на React и Compose позволил легко добавлять новую функциональность.
7. Как балансировать тем в команде разработки?
Спринты помогают тестировать гипотезы и поддерживать мотивацию олимпиадников в команде (значимая часть команды Nestor - это олимпиадники по программированию). А вот марафоны нужны для создания качественного продукта.
8. На какие метрики качества обращают внимание?
Метрики есть разные
- Adoption Nestor
- Acceptance rate (очищенный от мусорных показов)
- Внутренние бенчмарки для поиска по документации
- Пользовательский фидбек и предложения по улучшению.
9. Какие планы по развитию?
Планов много, но сейчас они видятся такими
- Полноценное редактирование кода
- Генерация тестов
- Платформа агентов для всех отделов компании
- Интеграция в другие продукты экосистемы (платформа для работы с данными Helicopter, observability платформа Sage)

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

#AI #Software #Engineering #Architecture #Agents

Modular Monolith: Is This the Trend in Software Architecture? (Рубрика #Architecture)

Интересный и короткий whitepaper на тему модульных монолитов, который задает вопрос насчет их трендовости. Авторы статьи сделили Systematic Grey Literature Review (SGLR) для анализа этого вопроса. По-факту, это анализ материалов, не прошедшие коммерческое академическое издание (отчёты ведомств и НКО, диссертации, доклады конференций, технические спецификации, preprint-репозитории, сайты проектов и т. д.). Они пытались понять насколько распространены модульные монолиты, стратегически сочетающие простоту разработки традиционных монолитов с преимуществами масштабируемости микросервисов, предлагая альтернативу, избегающую сложностей распределенных систем при сохранении модульных принципов. Вопрос был в том, а сможет ли modular monolith стать жизнеспособным компромиссом, дающим "лучшее из двух миров".Исследование мотивировано анонсом фреймворка Service Weaver от Google, позволяющего писать приложения как модульные монолиты с возможностью микросервисного деплоя. Интересно, что сам Service Weaver от Google и ответил на этот вопрос - с 6 июня он отправится в архив, не достигнув нужного уровня adoption.

Но если возвращаться к самому whitepaper, то авторы пытались показать, что modular monolith обеспечивает:
- Сохранение скорости разработки, характерной для монолитов
- Четкие границы модулей, предотвращающие эволюцию в "big ball of mud"
- Гибкость использования как самостоятельной архитектуры или промежуточного этапа перед микросервисами
- Упрощение процессов отладки и тестирования
- Эффективное масштабирование команд через распределение модулей

Из исследования литературы они выделили следующие ключевые характеристики модульных монолитов
- Segregation of modules: независимые модули с собственными слоями (Domain, Infrastructure, API)
- Modularity: слабая связность и сильная связность внутри модулей, асинхронная коммуникация через API
- Unified Database Schema: единая схема БД вместо отдельных схем на сервис
- Monolithic Deployment: все модули работают в рамках одной VM или распределены по выделенным VM
- Unified Application Process: единый процесс приложения для всех масштабов
- Enhanced Maintainability: измеримое улучшение поддерживаемости vs традиционные монолиты

В самом исследовании отмечалось, что известнейшими компаниями с модульными монолитами являются Shopify, Appsmith, Gusto, PlayTech, правда, они не использовали Service Weaver.

P.S.
Если отходить от самого whitepaper и оценить проблемы, что привели к закрытию Service Weaver, то можно отметить следующие
1) Низкий adop­tion rate - по-факту, это написано на странице проекта в аргументации к его закрытию

We realized that it was hard for users to adopt Service Weaver directly since it required rewriting large parts of existing applications. Therefore, Service Weaver did not see much direct use, and effective December 5, 2024, we will transition Service Weaver into maintenance mode.

2) Только go стек, что сужало целевую аудиторию
3) Опасность абстракций, когда локальный вызов может внезапно стать RPC (remote procedure call) - этим weaver напоминал концепцию CORBA/RMI, которая еще 20 лет назад показала свою непрактичность
4) Недостаточная функциональность - в фреймворке не было готовой маршрутизации/retries как в service mesh, нет встроенной mtls, нет удобного мониторинга
5) Конкуренция внутри самого Google Cloud - большинство кейсов, где weaver помогал пользователи уже решали через Cloud Run, GKE Autopilot + Istio или Functions, то есть им было проще использовать привычный стек, чем учить новую CLI и TOML-конфиги Weaver

Итого, интересная идея не полетела из-за того, что не набрала критической массы пользователей, а также не предложила ответа на концептуальные вопросы вида local/remote procedure calls и их неполное соответствие друг друга в плане НФТ при разных видах deployments. Но для любителей модульных монолитов остались фреймворки вида Spring Modulith.

#Architecture #Whitepaper #DistributedSystems #SystemDesign #Software #Engineering

Research Insights Made Simple #10 - Measuring Developer Experience With a Longitudinal Survey (Рубрика #DevEx)

Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы проведения опросов инженеров "Measuring Developer Experience With a Longitudinal Survey". Для разбора этой статьи ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал - https://t.me/badTechProject

За 40 минут мы успели обсудить следующие темы

- Опыт Google в проведении опросов
- Преимущества и процесс проведения опросов
- Методология и анализ опросов
- Важность коммуникации и внедрения изменений по итогам опросов
- Роль менеджера и сменяемость ролей в команде
- Масштабирование и частота опросов
- Продуктовый подход и интеграция онлайн-опросов
- Двухсторонний анализ: опросы и логи

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

P.S.
Я разбирал этот whitepaper раньше в своем tg канале в двух частях: 1 и 2

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

AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI)

Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже

1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.

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

#AI #Software #Engineering #Architecture #Agents

[1/3] Acing the System Design Interview (System Design: пережить интервью) (Рубрика #Architecture)

Последний месяц я потихоньку читаю книгу Zhiyong Tan, что посвящена system design interview и в виде перевода выпущена издательством Питер. Книгу я решил прочесть из интереса, чтобы сравнить с тем подходом, который близок мне и про который я рассказывал и долгое время развивал у нас внутри компании.
TLDR; книга мне показалась полезной и понравилась, причем больше, чем книга Alex Xu, про которую я тоже рассказывал.

Начнем с того, что автор, Zhiyong Tan, сейчас engineering manager в Paypal, а до этого был senior fullstack инженером в Uber, data инженером в небольших стартапах, а также инженером в Teradata. В общем, этот опыт позволил ему посмотреть на вопросы проектирования решений и найма сотрудников в компаниях разного масштаба и уровня зрелости. Сама книга поделена на три части:
1) Первая часть состоит из 6 глав и содержит стрктурированное введение в system design interview - про эту часть мы поговорим ниже подробнее
2) Вторая часть содержит 11 примеров system design задачек
3) В приложениях есть сравнения монолитов и микросервисов, базовыый разбор OAuth 2.0 и OpenID Connect, рассказ про C4 Model, а также разбор того, как устроен двух-фазный коммит. В принципе, все эти темы так или иначе могут быть затронуты на собеседовании

Дальше я расскажу про первые шесть глав, которые показались довольно здравыми

1. A walkthrough of system design concepts
В первой главе автор вводит базовые понятия system design, знакомит с ключевой терминологией и объясняет, что system design - это про дискуссию вокруг компромиссов, на которые надо пойти при проектировании решения:) Дальше автор быстро и по верхам рассазывает про масштабирование различных сервисов, начиная с маленькой инсталляции приложения и накручивая сверху GeoDNS, кеширование, CDN, горизонтальное и вертикальное масштабирование, управление кластерами, разделение на функционально-независимые части. Интересно, что автор разбирает историю про работу с аналитическими данными (ETL), выделение общих сервисов, а также размещение рабочих нагрузок на bare metall, cloud или вообще внутри FaaS:) В общем, большая часть этих блоков может быть раскрыта в отдельную главу, если не книгу, но автор дает неплохое общее представление о самих концепциях

2. A typical system design interview flow
Здесь автор описывает типичный процесс system design interview, акцентируя внимание на важности уточнения требований до начала проектирования. Особое внимание уделяется разделению functional и non-functional requirements. Интересно, что я как-то с ребятами из клуба {между скобок} разбирал flow собеседования, предложенный в книге Alex Xu, а также сравнивал с тем, что принято в Т. Если говорить подробнее про содержание главы, то тут идет речь про
- Уточнение требований
- Создание драфта спек API
- Связь пользователей и данных
- Моделирование моделей данных
- Обсуждение логгирования, мониторинга и алертинга (я часто это оставляю на финал собеседования)

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

[2/3] Acing the System Design Interview (System Design: пережить интервью) (Рубрика #Architecture)

Продолжая рассказ про книгу о system design, расскажу про оставшиеся четыре главы первой части.

3. Non-functional requirements
Эта глава целиком посвящена нефункциональным требованиям, которые часто называются архитектурными характеристиками ("-ilities") или атрибутами качества. Автор отдельно разбирает такие штуки как scalability, availability, fault-tolerance, performance/latency и throughput, consistency, accuracy, maintainability, cost, security, privacy, cloud native. Интересно, что я много раз рассказывал про НФТ или "-ilities", например с теми же ребятами из {между скобок} мы как-то разбирали работу с архитектурными характеристиками. Ну и недавно у меня был обзор whitepaper "Quality Metrics in Software Architecture" в трех частях: 1, 2 и 3.

4. Scaling databases
Эта глава целиком посвящена том, а как жить с состоянием, которое надо где-то хранить. В system deisgn задачах обычно эта stateful часть одна из самых интересных и она требует умения ее масштабировать и отвечачть на вопрос, а как обрабатывать сотни миллионов пользователей и миллиарды запросов. Здесь автор рассказывает про репликацию и шардирование, аггрегацию событий, батчинг и стриминг. Дальше наступает время денормализации и кеширования, где обсуждаются разные техники кеширования, инвалидации кешей, а также их прогрева. Рекомендую почитать книгу "Database Internals", про которую я рассказывал в двух частях: storage engines и distributed systems.

5. Distributed transactions
Целая глава посвящена распределенным транзакциям, хотя двух-фазный коммит вынесен в приложение и автор рассказывает о спрособах избежать распределенных транзакций. Для этого он говорит про крупные темы вида
- Event driven architecture и event sourcing - интересно, что эту тему отличо разбирает Влад Хононов в книге ""Learning Domain-Driven Design", я даже делал обзор этой темы в виде статьи в своем блоге.
- CDC - описание как отливать изменения из баз данных, используя условный Debezium
- Использование супервизоров транзакций, а также использование саг (оркестрируемых и хореографируемых)
В общем, интересная глава, но короткая - для реального понимания затронутых тем придется почитать книги поглубже

6. Common services for functional partitioning queue
В этой главе автор рассказывает про общую функциональность, что нужна сервисам:
- Аутентификация, авторизация, шифрование
- Проверка ошибок: валидация, дедубликация
- Производительность и надежность: опять кеширование, rate limiting
- Логгирование и аналитика
Дальше идут паттерны для декомпозиции вида service mesh (istio) и sidecars, service discovery, использование библиотек для общей функциональности или вынос сервисов. Ну и финализируется все обсуждением API, которое автор начинает с рассказа про модель OSI, а дальше идут стандартные REST, RPC, GraphQL, WebSocket и их сравнения.

В общем, в первой части излагаются важные концепции, которые полезны не только на собеседованиях, но и в практической работе:) Структурированный подход к работе с требованиями, анализу trade-offs и принятию архитектурных решений помогает в реальных проектах. Особое внимание автор книги уделяет коммуникации и зрелости инженеров — умению объяснять решения, обсуждать компромиссы, адаптироваться к изменяющимся требованиям. Эти качества важны для взаимодействия с другими командами и бизнес-стейкхолдерами.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

How To Design Better AI Apps (Рубрика #AI)

Интересное интервью с Pete Koomen, генерального партнера Y Combinator и основателя Optimizely, где обсуждаются идеи из его эссе "AI Horseless Carriages", в котором он создал демо с использование AI для работы с почтой с нуля. Собственно, в этом интервью речь идет о следующих темах

1. Проблема "AI-колясок без лошадей"
Многие разработчики используют старые подходы разработки софта для создания AI-функций, не раскрывая полный потенциал технологии. Как отмечает Koomen: "Мы используем старую ментальность разработки ПО, старые техники для создания этих функций, и мы на самом деле не используем полностью то, что может AI".
2. Скрытые системные промпты ограничивают возможности
Gmail AI создает формальные, безликие письма из-за скрытого системного промпта, который пользователи не могут увидеть или изменить. Это приводит к тому, что AI-помощник пишет как "универсальный писатель электронных писем для всех", а не как конкретный пользователь.
3. Пользователи должны иметь доступ к системным промптам
Возможность редактировать системные промпты позволяет персонализировать AI под конкретного пользователя. Koomen демонстрирует в своем демо, как изменение промпта с универсального на персональный кардинально улучшает результат.
4. Преодоление разделения "разработчик-пользователь"
Традиционное ПО требует разделения: разработчик пишет код, пользователь использует интерфейс. AI позволяет пользователям "программировать" приложения на естественном языке, что меняет эту парадигму.
5. AI-агенты для чтения писем эффективнее чат-ботов
Koomen показывает пример email agent, который может автоматически сортировать, помечать и отвечать на письма на основе пользовательских инструкций. Это более мощный подход, чем простые чат-боты.
6. Важность инструментов (tools) для AI-агентов
AI-агенты становятся по-настоящему полезными, когда у них есть доступ к инструментам для выполнения действий в реальном мире. Разработчики должны фокусироваться на создании богатой экосистемы инструментов. Здесь можно вспомнить про MCP протокол, который сейчас популярен для предоставления доступа агентам к внешним инструментам
7. Coding agents показывают правильное направление
Coding agents как Cursor и Windsurf работают лучше других AI-приложений, потому что они дают полный доступ к возможностям модели без ограничений (ну или почти без ограничений)
8. Чат-бот парадигма ограничивает AI
Большинство продуктов просто встраивают чат-агентов в существующие интерфейсы, что не использует истинные возможности AI (мы не знаем какие системные промпты есть на стороне чатботов)
9. Каждый может стать prompt engineer
Написание промптов интуитивно понятно - это просто объяснение AI того, как вы принимаете решения. "Это не навык, с которым мы рождаемся, но это довольно интуитивно".
10. Переосмысление продуктов с нуля для AI
Основателям стартапов следует спрашивать не "Как вставить AI в мой инструмент?", а "Как я бы спроектировал этот инструмент с нуля, чтобы максимально автоматизировать повторяющуюся работу пользователя?".

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

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

AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms (Рубрика #AI)

В середине мая Google выпустила интересную статью про своего агента AlphaEvolve, который способен разрабатывать продвинутые алгоритмы для решения задач оптимизации. По-факту, это эволюционирующий coding agent на базе пары LLM от Google. Более подробный рассказ о внутренностях этого агента доступен в отдельной научной статье (на 44 страницы). Этот алгоритм AlphaEvolve – результат коллективной работы команды Google DeepMind под руководством восьми ведущих исследователей, внесших равный вклад: Alexander Novikov, Ngân Vũ, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov и Borislav Kozlovskii. Среди других авторов: Francisco J. R. Ruiz, Abbas Mehrabian, M. Pawan Kumar, Abigail See, Swarat Chaudhuri, George Holland, Alex Davies, Sebastian Nowozin, Pushmeet Kohli и Matej Balog. Данный коллектив объединил специалистов в области машинного обучения, алгоритмической оптимизации и математического моделирования.

Если говорить про схему работы агента, то ключевые моменты следующие
1. В системе используется два типа моделей
- Gemini Flash – более быстрая и эффективная модель с низкой задержкой, максимизирующая объем генерируемых идей за единицу времени
- Gemini Pro – более мощная модель, обеспечивающая периодические высококачественные предложения для прорывных решений
2. Система использует эволюционный подход к модификации кода
AlphaEvolve использует эволюционную структуру, где агенты предлагают программы, реализующие алгоритмические решения в виде кода. Эти решения автоматически оцениваются при помощи чего-то типа fitness functions
3.Автоматизированная оценка
Система включает автоматизированные оценщики, которые проверяют, запускают и оценивают предложенные программы по объективным метрикам. Это обеспечивает количественную оценку точности и качества каждого решения, делая систему особенно эффективной в областях, где прогресс может быть четко и систематически измерен. Вот цитата из научной статьи, на которую я давал ссылку выше

The LLM-directed evolution process is grounded using code execution and automatic evaluation

В статье ребята рассказывают про крутые результаты модели
- Повышение эффективности дата-центров: AlphaEvolve разработал эвристику для оркестратора Borg, которая непрерывно восстанавливает в среднем 0,7% мировых вычислительных ресурсов Google.
- Оптимизация чипов: система предложила переписать код Verilog для удаления избыточных битов в арифметической схеме умножения матриц, что было интегрировано в новую версию TPU.
- Ускорение обучения LLM моделей: AlphaEvolve ускорил ключевой компонент архитектуры Gemini на 23%, что привело к сокращению времени обучения Gemini на 1%
- Новый алгоритм умножения матриц: AlphaEvolve обнаружил алгоритм для умножения комплексных матриц 4×4 с использованием всего 48 скалярных умножений, что превосходит алгоритм Штрассена 1969 года, что был топовым раньше.

Эти достижения базируются на предудыщих исследованиях
- AI Co-scientist (2025) - мультиагентная система на базе Gemini 2.0, предназначенная для помощи ученым в генерации новых гипотез и исследовательских предложений.
- AlphaTensor (2022) - система от DeepMind, специализирующаяся на автоматическом обнаружении новых алгоритмов умножения матриц с использованием глубокого обучения с подкреплением.
- AlphaZero (2018) - Технология глубокого обучения с подкреплением, лежащая в основе этих систем, берет свое начало от AlphaZero – самообучающейся системы DeepMind, которая освоила настольные игры, такие как го, шахматы и сёги.

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

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

Moving Faster and Reducing Risk: Using LLMs in Release Deployment (Рубрика #AI)

Интересный lighting talk с DPE Summit 2024 от Руи Абреу из Meta на тему повышения надежности релизов при помощи LLMs (Meta признана экстремисткой организацией и ее деятельность запрещена на территории России).

Основные моменты из этого выступления представлены ниже

1. Проблема масштаба в релизной инженерии - на масштабах Meta невозможно централизованно решать, что выпускать в продакшн. Ответственность передается разработчикам, пишущим и ревьюящим код.
2. Треугольник продуктивности - для ребят продуктивность является балансом между тремя измерениями: скорость (velocity), надежность (reliability) и читаемость кода (readability). Оптимизация одного параметра влияет на остальные.
3. Система оценки рисков диффов - ребята разработали модели для предсказания вероятности того, что diff вызовет серьезный сбой, влияющий на пользователей
4. Эволюция практик code freeze - ребята перешли от полной блокировки изменений к интеллектуальному гейтингу на основе оценки рисков.
5. Многоуровневое гейтирование - ввели четыре типа ограничений: зеленый (без ограничений), выходные дни (5%), средний риск (10%) и высокий риск (50% самых рискованных диффов).
6. Сравнение подходов к ML - проверяли модели на базе логистической регрессии, BERT-based моделей (StarBERT) и генеративных LLM для предсказания рисков.
7. Превосходство risk-aligned LLM - по результатам тестов победили risk-aligned модели iDiffLlama-13B
8. Упрощение feature engineering - для LLM моделей потребовались только три входных параметра: название изменений , план тестирования и сами изменения кода (интересно, что summary изменений в модель не подаются, так как они позволяют манипуляции).
9. Практические применения - по итогу внедрения этих рисковых моделей ребята смогли прийти к рекомендациям ревьюеров для рискованных диффов, автоматическому одобрению низкорискованных изменений, ну и общему улучшению процесса релизов.
10. Баланс скорости и качества - появилась возможность "разморозить" некоторые диффы во время code freeze, не блокируя все изменения на 100%, что повышает продуктивность инженеров.

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

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

Круглый стол «Техлид и развитие в Individual Contributor: как превратить код в карьеру» (Рубрика #Engineering)

Сегодня буду в рамках круглого стола на Techlead Conf X обсуждать этот вопрос с джентельменами из разных компаний, где у нас соберется квартет представленный ниже
- Максим Вишневский, ведущий (Mindbox)
- Глеб Михеев (Сбер)
- Александр Белотуркин (Делимобиль)
- Александр Поломодов (Т-Банк)

И вместе мы точно поговорим про то
- Как роль техлида влияет на бизнес: от компаний с развитой IC-веткой до тех, где влияние минимально?
- Какие навыки и подходы нужны техлиду в бизнесе, архитектуре и технической экспертизе, а также как расти по IC-ветке?
- Почему в российском IT IC-ветка слабо развита и какие перспективы для роста?
- Как формируется роль техлида в разных компаниях, почему она часто остается неофициальной и как развивать навыки без продуктового контекста?

Думаю, что мне будет, что добавить к этой дискуссии, так как раньше я уже много рассказывал на эту тему
- Code of Leadership #6 Staff+ инженеры, архитектура и SDLC
- Варианты роста инженера, если он уже Senior на Tinkoff Meetup 2023
- Как нанимать технических руководителей на Teamlead Conf 2023
- Архитектура в масштабе на ArchDays 2020
- System Design Interview на ArchDays 2021
- Как подготовиться и пройти System Design Interview на ArchDays 2022
- Книга Will Larson "Staff Engineer" и мои обзоры этой книги в двух частях: 1 и 2
- Книга Tanya Reilly "The Staff Engineer's Path" (перевод этой книги есть в издательстве Питер под названием "Карьера разработчика. Стафф - круче, чем senior")

#Staff #SoftwareDevelopment #Software #SelfDevelopment #Career