В одном цикле обновления Chromium сходятся около 10 000 коммитов апстрима и примерно 1500 собственных изменений Яндекс Браузера. Итог — больше тысячи VCS-конфликтов, а после их разрешения — ещё тысячи ошибок компиляции. Исторически на один такой цикл уходило несколько человеко-месяцев и до 100 разработчиков, которых регулярно выдёргивали из продуктовых задач.
Контекст
Яндекс Браузер — не просто ребрендированный Chromium. Поверх апстрима у команды большой слой собственных изменений: оптимизации рендеринга, работа движка, функции, которых в оригинальном проекте нет. Поэтому каждое обновление — это не один коммит, а столкновение двух активно развивающихся кодовых баз.
Процесс двухступенчатый. Сначала снимаются VCS-конфликты — текстовые пересечения правок в одних и тех же файлах. Старая авторезолвилка на основе правил и регулярных выражений закрывала около половины самых простых случаев; остальное — вручную. Затем запускается сборка: переименованные API, удалённые сущности, архитектурные перестройки апстрима ломают ещё тысячи строк. На каждую платформу приходится 500–600 уникальных ошибок компиляции, часть пересекается.
На втором этапе подключалось до 100 разработчиков — значительная часть команды временно бросала продуктовые задачи и переключалась на «починку мерджа». Раз в четыре недели. Каждый раз.
Аналитика
Яндекс сделал то, что большинство команд откладывает: автоматизировал не «одну ошибку за раз», а весь регулярный процесс пакетно. Разница принципиальная. Cursor и Copilot отлично работают в интерактивном режиме — один вопрос, один ответ. Но при сотнях конфликтных файлов человек всё равно остаётся в контуре на каждом шаге. Не масштабируется.
Ключевое архитектурное решение — разделение поиска контекста и генерации патчей. Агент сначала находит релевантный коммит в апстриме Chromium, понимает что именно изменилось, и только потом генерирует правку. Монолитная схема «скорми весь файл в LLM» не работает: в Chromium есть файлы на 20 000 строк C++, они просто забивают контекст и качество ответов падает. Вместо этого — локальный фрагмент конфликта плюс ограниченный контекст до и после.
Результаты конкретные. По конфликтам: 30% влито полностью автоматически, ещё около половины — после одного ревьюера вместо двух. 75% конфликтов закрыто за один день вместо двух. Точное совпадение с человеческим резолвом — 63%, смысловая корректность по LLM-as-a-judge — 81%. По компиляции: интегральная метрика качества выросла с 57% до 78% после оптимизации промптов и сокращения числа итераций с 60 до ~20 на одну ошибку.
Кейсы применения в бизнесе
B2B-SaaS стартап с активным форком OSS-проекта — кастомизированный движок, библиотека, платформа. Если команда регулярно накатывает апстрим, стоит построить аналогичный двухэтапный пайплайн. Первый шаг — кластеризовать прошлые ошибки: по опыту Яндекса, 10 кластеров покрывают около 99% всех случаев. Второй — для каждого кластера написать целевой промпт с примерами решений из истории. Ресурс: 1–2 инженера на 2–3 спринта, выигрыш — часы ручной работы каждый цикл.
Корпорация с legacy C++ или Java кодовой базой: переход на новые версии SDK или внутреннего фреймворка — та же структура. Разрыв между апстримом и внутренними патчами накапливается годами. LLM-агент с RAG по истории коммитов и двухуровневой схемой (быстрый путь для типовых случаев, медленный для сложных) — это инженерная задача с понятной архитектурой, а не исследовательский проект.
Аутсорс-студия или IT-продукт в КР/СНГ, поддерживающий несколько клиентских сборок на общей кодовой базе: если клиентские кастомизации регулярно конфликтуют с обновлениями ядра, пайплайн с LLM-резолвом снизит стоимость поддержки и уберёт вынужденное переключение контекста у разработчиков между задачами.
Кейсы в личной жизни
Разработчик, поддерживающий форк популярной библиотеки: если периодически приходится накатывать апстрим вручную, попробуй скормить LLM не весь файл, а только конфликтный фрагмент плюс несколько строк контекста до и после — и добавь в промпт то, что изменилось в апстриме по git log. Даже без агента качество резко выше, чем «выбери одну сторону».
Контент-мейкер или технический писатель, следящий за LLM-инструментами для кода: кейс Яндекса — редкий публичный разбор production-пайплайна с реальными метриками. Хорошая точка опоры, чтобы объяснять аудитории, где агенты реально работают — не в IDE-ассистентах «спроси и получи», а в автономных пайплайнах с чёткими задачами и измеримым результатом.
Студент или junior-инженер, изучающий agentic AI: статья — учебник по слоям. Поиск (RAG по коммитам апстрима), планирование (план изменений → атомарные задачи), генерация (Aider в ноде патчей), верификация (локальная сборка + LLM-as-a-judge). Это и есть современный production agentic workflow — без магии, с метриками.
Как применить сегодня
- Есть кодовая база с регулярными апстрим-обновлениями — начни с кластеризации прошлых ошибок компиляции. Сгруппируй по причинам: переименование, удалённые API, архитектурные изменения. 10 кластеров, покрывающих большинство случаев — первый практический шаг.
- При работе с конфликтами: не скармливай LLM весь файл. Выдели блок конфликта + фиксированное число строк контекста до и после. Качество растёт, токены экономятся.
- Изучи Aider — open-source инструмент для LLM-assisted редактирования кода из CLI. Яндекс использовал его в ноде генерации патчей именно за встроенные эвристики обработки некорректных правок.
- Для оценки качества LLM-решений на больших объёмах: опиши аспекты корректного решения заранее и попроси модель проверить их выполнение (LLM-as-a-judge). Дешевле ручного ревью, масштабируется.
- Архитектуру «поиск контекста → план → атомарная генерация → верификация сборкой» можно переиспользовать для любой задачи массовой кодогенерации: миграции API, переименования сущностей, обновления зависимостей.