Writing an engineering strategy

Интересная статья про инженерную стратегию от Will Larson, автора книг An Elegant Puzzle (про engineering management, я про нее как-то рассказывал) и Staff Engineer (про высокоуровневых SDE, у меня есть обзор этой книги в двух частях: 1, 2).
В этой статье автор рассказывает про то, как писать engineering strategy, являясь engineering executive, используя структуру которую предложил Richard Rumelt в книге "Good Strategy, Bad Strategy". В этой структуре 3 составляющих:
1. Diagnosis - объяснение в чем вызов и корневая проблема, которую мы решаем
2. Guiding policies - подходы, которым стоит следовать для решения вызовов. Эти руководящие policies могут быть как явными, так и неявными компромиссами (tradeoffs) между вариантами действий.
3. Coherent actions - набор действий, которые направляются принципами для решения challenge. Эта самая важная часть стратегии.

Дальше автор рассказывает про
- Процесс написания
- Когда ее стоит писать
- Что делать с отсутствующими бизнесовой и продуктовой стратегией, которые должны учитываться в инженерной стратегии
- Как структурировать руководящие принципы
- Как поддерживать нужный уровень руководящих принципов
- Как сформировать перечень конкретных действий
- Почему стратегия - это про top-down approach
- И как начать писать стратегию

#Strategy #Engineering #Management #Leadership #Process #SystemEngineering

Interviewing & Hiring Like a Boss • Kristine Howard • YOW! 2023

Интересное выступление Kristine Howard из Amazon, которая рассказала про то как проводить интервью более качественно. Мне эта тема интересна из-за того, что я сильно вовлечен в процессы найма и я стараюсь улучшать их по мере своих сил. Если же возвращаться к выступлению Кристин, которая является AWS Head of Developer Relations APJ, то она начала выступление с того, что лет 8 назад ненавидела проводить интервью, но как известно от любви до ненависти один шаг и когда-то она сделала его в обратном направлении как принято в Amazon:)

Дальше она перешла к основным пунктам своего выступления
- Что делать перед интервью - рассказ про подготовку job description, про ревью CV (и их подготовку со стороны кандидатов), как выстроить структуру цепочки интервью, как проверять hard skills и leadership principles (шардируя проверку разных скиллов по разным интервьюерам), как проводить preebrief, на котором можно получить дополнительную информацию о требованиях к кандидату, как готовить конкретные вопросы к кандидату (выбирая из подготовленого списка вопросов)
- Как проводить интервью - помочь им успокоиться, рассказать про регламент проведения интервью, зачем и как просить кандидатов рассказывать истории - по-факту, спикер рассказывает про использование STAR (situation-task-action-result) и SBI (situation-behavior-impact) для проведения интервью:) Дальше она говорит о том, на что обращать внимание при общении с кандидатом: смотреть на цифры, scope, impact. Уточнять что именно делал кандидат для получения результата. Не бояться прерывать поток воды и переходить к следующему вопросу. Как написать фидбек о кандидате - здесь спикер говорит о том, как уменьшить влияние предубеждений и объективно оценить кандидата по заранее составленному списку критериев.
- Как принимать решения по итогам всех интервью - здесь идет речь про debrief и ревью итоговых результатов кандидата и стоит ли его нанимать. Здесь приводятся стандартные подходы к принятию решений в группе. А также как обсуждать сильные и слабые стороны кандидата, а также интересный вопрос про непреодолимую причину для найма кандидата. Тут же разбирается вопрос о том, как коучить интервьюеров и давать им фидбек для их роста. А заканчивается эта часть тем, что у ребят весь процесс найма обвешан метриками и существует SLA на скорость и качество каждого шага процесса.
- Подсказки - спикер рассказывает про важность менеджмента календаря и затраты по времени на проведение интервью, также про отдельное интервью, где кандидат может поспрашивать не под запись о том, как работается в компании (полезно для minority representatives), про важность процесса обучения интервьюверов, а также улучшение опыта кандидатов.

P.S.

За 7 лет в Тинькофф я провел 700+ интервью и прошел путь от фаната найма к себе в команду с кастомным интервью в один этап до человека, который понимает зачем нужен четкий и понятный процесс, разделенный на отдельные этапы с формальными критериями оценки для каждого из них. И основное отличие в размерах компании и стоимости ошибок первого и второго рода (ложноположительных и ложноотрицательных соответственно).

В итоге, теперь я часто рассказываю про наши подходы к найму:
- Про проверку навыков проектирования (system design interview) - мы спрашиваем про это у software development engineer и технических руководителей - вот тут есть материалы по этому типу интервью
- Про проверку навыков работы с инцидентами (troubleshooting interview) - мы спрашиваем про это у site reliability engineers и их руководителей - подробнее подробнее можно здесь
- Про менеджмент интервью - этот тип интервью варьируюется для тимлидов и руководителей уровнем выше - вот тут можно почитать подробнее

#Management #Hiring #Leadership #Process #Software

Практическое руководство по статистическому управлению процессами

Эту книгу Юрия Адлера и Владимира Шпера я читал несколько недель. И дело не в том, что книга скучна, а скорее в том, что она сложна для восприятия и требует понимания статистики и системного мышления. Авторы пропагандируют использование контрольных карт Шухарта, которые в свое время популяризировал сам Шухарт и его коллега Деминг, который приложил руку к японскому экономическому чуду. Все это укладывается в цикл PDCA Шухарта-Деминга (plan - do - check - act). Сама книга состоит из восьми глав

1. Что такое системное, статистическое и визуальное мышление и для чего оно нужно?
2. История возникновения статистического мышления. Основы теории вариабельности.
3. Основы теории вариабельности (продолжение). Анализ стабильности процессов. Игра "Красные бусы"
4. Правила построения и интерпретации ККШ (контрольных карт Шухарта). Классификация типов ККШ
5. Построение и анализ гистограмм. Диаграммы ствол-и-листья (stem-and-leaf) и ящик-с-усами (box-and-whisker). Вероятностные сетки и законы распределения
6. Индексы воспроизводимости процессов (ИВП)
7. Проблемы и трудности при построении и применении ККШ и гистограмм на практике. Алгоритм процесса анализа стабильности и воспроизводимости
8. SPC, AI, Big Data и новые идеи в области ККШ

Если кртако, то книга посвящена тому, как анализировать вариабельность процессов. Как оценивать причины вариабельности, где авторы говорят про
- общие причины вариабельности, что присущи самому процессу
- особые (assignable) причины вариабельности, что возникают из-за внешних по отношению к процессу воздействий
Особые причины требуют локального вмешательства в процесс, а общие причины вариаций требуют вмешательства в систему (оно обычно должно осуществляться со стороны высшего менеджмента).
Дальше в книге рассказывается про статистическое мышление

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

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

1. Как выбрать показатели, требующие изменения?
2. Сколько таких показателей надо измерять?
3. Каким методом следует измерять каждый выбранный показатель?
4. Как часто надо измерять каждый показатель?
5. С какой точностью надо измерять каждый показатель?
6. Кто должен анализировать каждый показатель?

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

В общем, в книге еще много интересного и я думаю, что ее полезно изучить менеджерам как в реальном, так и в digital производстве.

#Management #Process #Statistics #Math #Metrics #Leadership

Modern Platform Engineering: 9 Secrets of Generative Teams • Liz Fong-Jones • GOTO 2023

Интересный доклад от Liz Fong-Jones, Field CTO из Honeycomb. Сначала Liza вспоминает что такое DevOps, потом SRE, а потом переходит к теме Platform Engineering.
В части про devops идет речь про стремление к culture, automation, lean, measurement и sharing. А DORA метрики позволяют измерить насколько хорошо это получается у команд. Но эти метрики имеют ряд проблем:
- Путь улучшений не слишком ясный
- Сами улучшения сложно померить (плюс мы измеряем запаздывающие показатели)
- Есть дилемма с самой моделью зрелости и непрерывными улучшениями (модели зрелости предполагают, что можно попасть на определенный уровень зрелости, а дальше уже улучшаться не требуется - кстати, в "Accelerate" для решения этой проблемы предлагали использовать capabilities model - я рассказывал про это в обзоре книги)
- Как достигать консистентности в разных командах

В итоге, Liz предлагает модель с 9 секретами, что способствуют генеративной культуре по Веструму (я уже писал про этот подход к типизации культур)
1. Reproducible deploys (If it ain't in Git it don't exist!) - нам нужна повторяемость в сборках и деплоях. Про это шла речь еще во времена появления 12 factor app, а сейчас это стандарт де-факто:)
2. Fast CI/CD (I wanna go fast!) - ускоряем циклы обратной связи, помогаем разработчикам быстрее видеть результаты своего труда.
3. Observability (Don't drive with snow on your windshield!) - дефолт для понимания того, что происходит с нашим приложением. Без этого не ясно как определять наличие проблем, а также траблшутить их.
4. Feature flagging (Smaller boom, less fear!) - в комплекте с TBD (trunk-based development) позволяет правильно делать CI (подробнее в докладе)
5. Code ownership (You build it, you run it! (with a twist)) - мантра, которая убирает забор между dev и ops (sre) командами. По-факту, SDEs (software development engineers) владеют не только кодом, но и самим приложением, что крутится в продакшене
6. Blameless culture (No one wins the shame game!) - здесь посоветую сразу несколько статей и выступлений
- Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?"
- A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative)
Мои выступления на связанные темы
- Культура постмортемов
- От монолита к микросервисам и обратно
7. Service level objectives (SLOs) (If you liked it you shoulda put an SLO on it!) - про это я говорил в докладе "Проектируем надежные системы - стоит ли игра свеч"
8. Chaos Engineering (Test your assumptions!) - рекомендую на эту тему глянуть выступление Kelly Shortridge "Practical Magic: The Resilience Potion & Security Chaos Engineering"
9. Platform teams (to tie it all together and systematise it) - рекомендую почитать книгу Team Topologies про team-first подход при проектировании архитектуры программных систем, так и организации. В ней очень хорошо рассказывается про платформенные команды. А вот как сама Liz характеризует эти команды

Platform teams outsource as much as possible, write as little code as possible.
Platform teams are experts in outsourcing. It’s a very high-leverage role; they use their infra expertise to offload as much operational burden as possible.

В итоге, в модели Liz платформенные команды помогают всем остальным 8 пунктам и позволяют построить генеративную культуру и высокоэффективные команды.

#Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #Devops #PlatformEngineering #Process #Culture #SRE

[1/2] The Mythical Man-Month (Мифический человеко-месяц) (Рубрика #Management)

Эта книга Фредерика Брукса была впервые издана 50 лет назад, в 1975 года, но она до сих пор переиздается, а цитаты из нее стали классическими. Я решил вспомнить про нее к юбилею и посмотреть насколько она еще актуальна.

В заглавие книги вынесена идея о том, что "добавление сотрудников в отстающий проект только увеличивает задержки" из-за роста коммуникационных издержек, времени на адаптацию новых членов команды и неделимости некоторых задач. Брукс критикует ошибочное предположение, что труд (измеряемый в "человеко-месяцах") можно масштабировать линейно, сравнивая это с невозможностью девяти женщин родить ребенка за один месяц. Это относится к области управления проектом/продуктом и так же актуально, как было 50 лет назад. Еще он подчеркивает важность концептуальной целостности - согласованной архитектуры системы под руководством единого видения - для предотвращения хаоса, вызванного "проектированием при помощи комитетов". Этот тезис относится к проектированию софта. Следующая ключевая идея относится к "эффекту второй системы" (перегрузка сложностью при создании следующей версии). Вот эта проблема кажется уже решена, так как продукты часто сейчас строятся итеративно и понятие версии системы вообще размывается:) Ну и последняя идея, которую стоит отметить - это различие между essential complexity (существенной сложностью, что присуща задаче) и accidental complexity (случайной сложностью, которая возникает из-за неэффективных инструментов или процессов).

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

1) Закон Брукса vs Agile и гибридной работы
- Agile подходы снижают риск неожиданностей и даже работая проектно мы на поздних стадиях получаем меньше рисков, это соответствует мыслям Брукса о важности прототипирования в больших проектах
- Гибридная работа - современные инструменты (GitHub, Jira, Slack) снижают барьеры для коммуникаций, но правило про квадратичный рост затрат на коммуникацию от роста команды никуда не девается (помним, что в полном графе n*(n-1)/2 связей)
- Брукс рекомендовал использовать локализованные "хирургические команды", а у нас теперь есть two-pizza teams
2) Модульность и мокросервисы
- У Брукса вызывала опасения монолитная система, что они делали для мейнфрейма, но в наше время у нас пронеслись перед глазами SOA, микросервисы, FaaS и теперь людям монолит уже не кажется таким плохим вариантом для старта
- По-факту, нам нужна модульность нашего кода, а как он разворачивается можно решить потом (условно модульный монолит можно нормально разделить на отдельные микросервисы при необходимости)
3) Инструменты против человеческого фактора
- Одна из ключевых мыслей Брукса была про то, что серебрянной пули для повышения производительности разработки нет
- Но мы видим, что хорошие инженерные практики постепенно повышали продуктивность инженеров - речь про CI/CD и всю автоматизацию
- А сейчас мы живем во время, когда щепотка AI, добавленная в SDLC (software development life cycle) навроде GitHub Copilot обещает в будущем грандиозный эффект (если LLM продолжат также прогрессировать)
- Но пока мы все еще видим AI в качестве ассистента, а значит нам нужно обращать внимание на человеческий фактор, тут есть классная колонка про "Human approach to developer productivity" от Google, про которую я уже рассказывал раньше

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

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

[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

[1/3] Resolving Code Review Comments with Machine Learning (Рубрика #AI)

Этот whitepaper от Google Research, впервые опубликованный в 2023 году и представленный на Международной конференции по инженерии программного обеспечения (ICSE) в апреле 2024 года. Исследование посвящено AI-фикации процесса код ревью. Суть в том, что исследователи сделали систему, что способна понимать комментарии рецензентов на естественном языке и предлагать соответствующие изменения в коде. Авторы описывают, как Google успешно внедрил эту технологию в свой рабочий процесс разработки, что привело к значительной экономии времени и повышению производительности. Мне этот paper понравился своим подходом - авторы не просто впиливали AI куда-то в процесс разработки, а делали это в продуктовом стиле, меняя как саму модель, так и сам UX процесса код ревью. Суть самой статьи можно описать так

- Проблематика: Ревью кода - это важный процесс особенно в Google, но он занимает много времени. Разработчики тратят в среднем около часа на каждое изменение кода после ревью.
- Решение: AI-система читает комментарии рецензентов и автоматически предлагает изменения кода для исправления проблем.
- Как это работает: Система обучена на прошлых code reviews; она анализирует контекст кода, понимает комментарий рецензента и генерирует подходящие изменения. Это решение прошло несколько итераций от асинхронной генерации исправлений до генерации предложенного фикса на лету, пока ревьювер пишет свой комментарий. Финальный вариант предполагает, что ревьювер может согласиться с предложенным моделькой исправлением, а может пореджектить его.
- Эффект: Реализованное решение в итоге привело к тому, что авторы изменений принимают автоматически предложенное моделью в 7.5% случаев. Это экономит сотни тысяч часов работы разработчиков ежегодно.
- Гибкость: Система справляется как с простыми изменениями, так и со сложными. Отдельно авторы отмечают, что ревьюверы начали подстраивать свои комментарии к коду так, чтобы система генерировала лучшие подсказки для автора кода.
- Обратная связь: Пользовательская обратная связь помогла улучшить систему со временем за счет фильтрации некорректных предсказаний.
- Польза для разработчиков: Система позволяет сосредоточиться на более творческих аспектах разработки вместо рутины.

Автор подход был примерно следующим
- Авторы воспринимали эту задачу как стандартную text-to-text ML задачу, для использования которой взяли традиционный трансформер на базе T5X Framework
- Авторы взяли реальные code review и сделали inline комментариев из ревью в код в виде комментов, а таргетом было уметь предсказывать предлагаемый diff patch, который реально был предложен для решения этого комментария из ревью
- Тренировали он модель для код ревью и других задач в области software engineering и использовали для этого DIDACT фреймворк. Тренировочный корпус состоял из 3 миллиардов примеров, из которых 60 миллионов были примерами с code review. В pre-training использовались достаточно свободный набор code review примеров, включая автоматические комментарии, комментарии для всего набора изменений, а также целых файлов. Для fine-tuning использовали code-review примеры, где комментарии писали только люди. Тюнили метрику standard cross-entropy loss, типичную для таких моделе
- На этапе inference модель использовали так, чтобы выдать желаемый precision - каждое предсказание сопровождалось вероятностью и большая вероятность означала большую уверенность модели в предсказании
- Для валидации модели использовался набор данных, что не использовался при тренировках
- Отдельно авторы выставляли threshhold для предсказаний, то есть предлагаемые изменения показываются пользователям только тогда, когда модель уверена в своем предсказании и удовлетворяет дополнительным эвристикам.

Продолжение в следующем посте, где я расскажу как это решение было встроено в процесс ревью.

#Software #AI #Engineering #Process #DevEx

[2/3] Resolving Code Review Comments with Machine Learning (Рубрика #AI)

Продолжая рассказ про whitepaper от Google опишу чуть подробнее эволюция системы
V1) Начиналось все с генерации suggests изменений после отправки комментариев код ревьюверами
V2) Инструмент развился до предложения изменений кода ревьюверам во время написания комментариев
V2 + IDE integration) На основе обратной связи пользователей команда внедрила лучшую интеграцию с IDE, включая просмотр конфликтующих изменений (3-way-merges)

В итоге, текущий процесс работы этой фичи и воронку
- Ревьювер пишет коммент - на лету моделька генерирует код для фикса
- Ревьювер может принять этот код или нет, если принимает, то дальше автору MR прилетает комментарий с этим auto suggest, если отклоняет, то просто комментарий
- Дальше автор кода при ревью может жмякнуть кнопку автопринятия

Цель всей работы и метрика для оптимизации была сформулирована так

A primary goal for any assistance tool is to increase productivity. One metric we use to gauge the positive impact of our assistant on productivity is acceptance rate, the fraction of all code-review comments that are resolved by the assistant; this measures, out of all (non-automated) comments left by human reviewers, what fraction received an ML-suggested edit that the author accepted and applied directly to their changelist.

Стата по каждому этапу выглядит сильно интереснее, чем просто 7.5% автоприемов suggest от всех комментариев.

Stage -- (%) of total -- (%) of previous step
Incoming comments -- 100.0% -- 100.0%
Confident predictions -- 49.0% -- 49.0%
Accepted by reviewer -- 33.1% -- 63.6%
Previewed by authora -- 10.7% -- 34.5%
Applied by author -- 7.5% -- 69.5%

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

The concept of author preview is less significant in V2. The author automatically sees a small preview and can “click-to-view” full suggested edits. This full view either shows the “Apply“ button or informs about an edit that requires a three-way merge. Almost all not-applied previews in V2 denote an edit that required a three-way merge to be applied.

Качественный фидбек по этой фиче звучал так

Early feedback about the assistant in internal message boards is enthusiastic, including characterizations such as “sorcery!”, “magic!”, “impressive”. Although the new version V2, in which suggested edits are presented as the reviewer is typing a comment, has only been deployed to 100% of the population for a relatively limited time, we have received delighted reports demonstrating that just the location and the initial sentiment of the reviewer’s comment can lead to helpful suggested edits, for both parties involved.

Помимо результатов авторы статьи описали как они тюнили качество системы через тюнинг модели и тюнинг данных
- Model tuning включал: fine-tuning DIDACTR модели, size tuning количества параметров в модели, уменьшение precision, тюнинг hyperparameters, тюнинг под языки программирования и финально preview для ревьюверов, что позволило еще нише сделать отсечку по precision
- Data tuning включал: оффлайн датасет для оценки ограничили только single comment изменениях, тренировка на "done" комментариях, тренировка на синтетических задачках

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

#Software #AI #Engineering #Process #DevEx

[1/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)

Интересная научная статья от ByteDance, создателя TikTok на тему автоматизированного code review с использованием GenAI. Интересно, что чуть раньше я уже разбирал как Google подходит к этому вопросу при разборе "Resolving Code Review Comments with Machine Learning" в трех частях: 1, 2 и 3. Но у ребят из ByteDance немного другой подход - они сделали систему, в которой LLM пишет на MR (merge requests) комментарии в code review, а у ребят из Google сам комментарий писал инженер, а LLM делало code suggest, который предлагал фикс, что соответствует этому комментарию. Но давайте посмотрим какие проблемы авторы из ByteDance пытались решить, создавая BitsAI-CR:
- Избавиться от трудоемкого узкого места в виде традиционного code review
- Устранить ошибки и непоследовательности в комментариях при code review

Вообще, тема использования LLM для code review плодотворна, но там есть проблемки, которые авторы учли и попробовали устранить (кстати, в списке ссылок больше 50 других научных статей, десяток из которых про code review)
1. Низкая точность и надёжность: многие LLM-решения генерируют неточные или нерелевантные комментарии, тратя время разработчиков.
2. Недостаточная практичность: текущие системы часто не дают полезной обратной связи, которую реально используют разработчики.
3. Отсутствие механизма постоянного улучшения: большинство решений не учатся на обратной связи пользователей и не эволюционируют со временем.

Для решения этих проблем авторы придумали архитектуру из двух частей, что сочетает высокоточный pipeline генерации комментариев к review и механизм data flywheel. Такой подход не только выявляет потенциальные проблемы в коде с высокой точностью, но и запускает цикл постоянного улучшения на основе реальной обратной связи от разработчиков. Интересно, что для генерации комментариев используется таксономия правил code review, где есть категории security vulnerability, code defect, maintainability and readability, performance issue.

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

Review Comment Generation Pipeline
Pipeline работает в четыре последовательных этапа:
1. Context Preparation: на этом этапе входные изменения кода структурируются для дальнейшего анализа. Изменения разбиваются на сегменты по header hunks, добавляются полные определения функций - это даёт LLM достаточно контекста для качественного анализа.
2. RuleChecker: это дообученная LLM, обученная на широкой таксономии из 219 правил review. RuleChecker выявляет потенциальные проблемы в каждом сегменте кода, классифицируя ошибки по типам: уязвимости, проблемы производительности, нарушения стандартов кодирования и др. На выходе - первоначальные комментарии к review.
3. ReviewFilter: этот слой верификации - ключевой механизм контроля качества, который фильтрует ложные срабатывания и галлюцинации RuleChecker. ReviewFilter - тоже дообученная LLM, использующая три паттерна рассуждений: Direct Conclusion, Reasoning-First, Conclusion-First. После тестов наиболее эффективным оказался Conclusion-First - он лучше всего балансирует точность и производительность.
4. Comment Aggregation: на этом этапе схожие комментарии группируются с помощью cosine similarity, чтобы не перегружать разработчиков дублирующей обратной связью. В каждой группе сохраняется один представитель.

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

#Software #AI #Engineering #Process #DevEx