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
Интересная статья про инженерную стратегию от 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
Lethain
Writing an engineering strategy.
Once you become an engineering executive, an invisible timer starts ticking in the background.
Tick tick tick. At some point that timer will go off,
at which point someone will rush up to you demanding an engineering strategy.
It won’t be clear what they…
Tick tick tick. At some point that timer will go off,
at which point someone will rush up to you demanding an engineering strategy.
It won’t be clear what they…
👍12
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
Интересное выступление 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
❤6👍6🔥2👏1🤗1
Практическое руководство по статистическому управлению процессами
Эту книгу Юрия Адлера и Владимира Шпера я читал несколько недель. И дело не в том, что книга скучна, а скорее в том, что она сложна для восприятия и требует понимания статистики и системного мышления. Авторы пропагандируют использование контрольных карт Шухарта, которые в свое время популяризировал сам Шухарт и его коллега Деминг, который приложил руку к японскому экономическому чуду. Все это укладывается в цикл PDCA Шухарта-Деминга (plan - do - check - act). Сама книга состоит из восьми глав
Если кртако, то книга посвящена тому, как анализировать вариабельность процессов. Как оценивать причины вариабельности, где авторы говорят про
- общие причины вариабельности, что присущи самому процессу
- особые (assignable) причины вариабельности, что возникают из-за внешних по отношению к процессу воздействий
Особые причины требуют локального вмешательства в процесс, а общие причины вариаций требуют вмешательства в систему (оно обычно должно осуществляться со стороны высшего менеджмента).
Дальше в книге рассказывается про статистическое мышление
И дается определение операциональных определений, которые понятны и для которых указан практический способ их однозначной реализации. А дальше контрольная карта Шухарта приводится как операциональное определение статистически управляемого или стабильного процесса. Но для построения этих карт надо ответить на ряд практических вопросов
Каждый из вопросов скрывает под собой кучу интересного, но мне бы хотелось отметить ответ на 6 вопрос, где авторы говорят о том, что показатели надо анализировать владельцам самих процессов, так как они знают сущностную составляющую процесса и его особенности.
В общем, в книге еще много интересного и я думаю, что ее полезно изучить менеджерам как в реальном, так и в digital производстве.
#Management #Process #Statistics #Math #Metrics #Leadership
Эту книгу Юрия Адлера и Владимира Шпера я читал несколько недель. И дело не в том, что книга скучна, а скорее в том, что она сложна для восприятия и требует понимания статистики и системного мышления. Авторы пропагандируют использование контрольных карт Шухарта, которые в свое время популяризировал сам Шухарт и его коллега Деминг, который приложил руку к японскому экономическому чуду. Все это укладывается в цикл 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
❤8👍5💩3🤓3🤔1
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 характеризует эти команды
В итоге, в модели Liz платформенные команды помогают всем остальным 8 пунктам и позволяют построить генеративную культуру и высокоэффективные команды.
#Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #Devops #PlatformEngineering #Process #Culture #SRE
Интересный доклад от 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
YouTube
Modern Platform Engineering: 9 Secrets of Generative Teams • Liz Fong-Jones • GOTO 2023
This presentation was recorded at GOTO Copenhagen 2023. #GOTOcon #GOTOcph
https://gotocph.com
Liz Fong-Jones - Field CTO at Honeycomb.io @lizthegrey
RESOURCES
https://twitter.com/lizthegrey
https://linkedin.com/in/efong
https://www.lizthegrey.com
ABSTRACT…
https://gotocph.com
Liz Fong-Jones - Field CTO at Honeycomb.io @lizthegrey
RESOURCES
https://twitter.com/lizthegrey
https://linkedin.com/in/efong
https://www.lizthegrey.com
ABSTRACT…
🔥10❤3👍3
[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
Эта книга Фредерика Брукса была впервые издана 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
👍17❤5🔥2
[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 и 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
Telegram
Книжный куб
👍11❤6🔥6
[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
Этот 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
Google Research
Resolving Code Review Comments with Machine Learning
❤7👍5🔥1
[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, если отклоняет, то просто комментарий
- Дальше автор кода при ревью может жмякнуть кнопку автопринятия
Цель всей работы и метрика для оптимизации была сформулирована так
Стата по каждому этапу выглядит сильно интереснее, чем просто 7.5% автоприемов suggest от всех комментариев.
Ну и шаг превью в этой стате не так значим как в первом варианте того, как они сделали эту фичу, там под табличкой такая аннотация идет
Качественный фидбек по этой фиче звучал так
Помимо результатов авторы статьи описали как они тюнили качество системы через тюнинг модели и тюнинг данных
- Model tuning включал: fine-tuning DIDACTR модели, size tuning количества параметров в модели, уменьшение precision, тюнинг hyperparameters, тюнинг под языки программирования и финально preview для ревьюверов, что позволило еще нише сделать отсечку по precision
- Data tuning включал: оффлайн датасет для оценки ограничили только single comment изменениях, тренировка на "done" комментариях, тренировка на синтетических задачках
В общем, получился интересный whitepaper с описанием подхода ребят в Google и интересными практическими результатами. В последнем посте прилинкованы интересные картинки из этой статьи.
#Software #AI #Engineering #Process #DevEx
Продолжая рассказ про 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
Telegram
Книжный куб
[1/3] Resolving Code Review Comments with Machine Learning (Рубрика #AI)
Этот whitepaper от Google Research, впервые опубликованный в 2023 году и представленный на Международной конференции по инженерии программного обеспечения (ICSE) в апреле 2024 года.…
Этот whitepaper от Google Research, впервые опубликованный в 2023 году и представленный на Международной конференции по инженерии программного обеспечения (ICSE) в апреле 2024 года.…
👍7🔥6❤4
[3/3] Resolving Code Review Comments with Machine Learning (Рубрика #AI)
Заканчивая обзор (1 и 2) whitepaper от Google на тему code review, приведу красивые иллюстрации из статьи. На них видно как работает система, как ребята тюнили качество модели, а также приведены примеры сложных продуктовых кейсов, навроде, 3-way-merges, когда "author attempts to accept an ML-suggested edit in anincompatible code stat."
#Software #AI #Engineering #Process #DevEx
Заканчивая обзор (1 и 2) whitepaper от Google на тему code review, приведу красивые иллюстрации из статьи. На них видно как работает система, как ребята тюнили качество модели, а также приведены примеры сложных продуктовых кейсов, навроде, 3-way-merges, когда "author attempts to accept an ML-suggested edit in anincompatible code stat."
#Software #AI #Engineering #Process #DevEx
❤5👍4🔥2
[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
Интересная научная статья от 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
arXiv.org
BitsAI-CR: Automated Code Review via LLM in Practice
Code review remains a critical yet resource-intensive process in software development, particularly challenging in large-scale industrial environments. While Large Language Models (LLMs) show...
❤7👍5🔥1
[2/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)
Продолжаем рассмотрение интересного whitepaper о code review со второй части модели, а именно механизму data flywheel
Data flywheel — это системный подход к постоянному улучшению за счёт:
1. Annotation Feedback Integration: BitsAI-CR собирает и использует обратную связь пользователей для дообучения и улучшения датасетов.
2. Outdated Rate Measurement: введён новый метрик — Outdated Rate, который измеряет процент строк кода, изменённых после того, как BitsAI-CR их пометил. Это даёт объективную оценку того, насколько часто разработчики реально принимают предложения системы.
3. Dynamic Rule Adjustment: cистема постоянно корректирует правила review на основе точности и Outdated Rate, убирая те, что генерируют малоценные комментарии (низкий Outdated Rate при высокой точности).
Вместе эти компоненты создают цикл обратной связи, который шаг за шагом повышает качество code review на основе реального поведения разработчиков.
Авторы применили продвинутую стратегию обучения и оптимизации BitsAI-CR, включающую несколько ключевых элементов:
- В качестве базовой модели выбран Doubao-Pro-32K-0828 (собственная LLM ByteDance), что обусловлено требованиями безопасности и приватности данных. Размер последовательности выбран 8192 токена, так как 99% примеров review укладываются в этот лимит.
- Для дообучения RuleChecker и ReviewFilter использовалась техника LoRA (Low-Rank Adaptation)
- Также они учились на основе подробной таксономии правил code review, что дало
-- Структурированную основу для выявления и классификации проблем в коде
-- Системный сбор и разметку данных для обучения
-- Чёткие критерии для оценки качества системы
- Такой подход показал себя эффективным: BitsAI-CR, обученный на таксономии, достиг точности 57.03%, тогда как версия без таксономии (на случайных человеческих review) — лишь 16.83%.
Для оценки модели авторы новую метрику - Outdated Rate, измеряющий долю строк кода, изменённых после комментариев BitsAI-CR. Это позволяет:
1. Автоматически оценивать реальное влияние комментариев на практике
2. Понимать, насколько предложения системы действительно внедряются разработчиками
Такой подход закрывает недостатки традиционных метрик точности, которые требуют ручной разметки и не отражают реальную пользу для бизнеса.
При внедрении в production система показала впечатляющие технические результаты
1. Точность (Precision): Без таксономии и двухступенчатой архитектуры точность была около 25%. После внедрения этих элементов точность RuleChecker выросла с 27.9% до 62.6%, а ReviewFilter — с 35.6% до 75.0%. Это доказывает эффективность двухступенчатой архитектуры в снижении ложных срабатываний.
2. Outdated Rate: Для языка Go (основного в ByteDance) Outdated Rate вырос до 26.7% через 18 недель оптимизации. Для сравнения, у людей этот показатель колеблется между 35-46%. Постепенное приближение к человеческому уровню — свидетельство практической ценности BitsAI-CR.
Кроме того, BitsAI-CR быстро стал частью процесса разработки:
1. Аудитория: Более 12 000 Weekly Active Users (WAU), свыше 210 000 Weekly Page Views (WPV) — система интегрирована в рабочий процесс.
2. Retention: Retention на второй неделе — 61.64%, через восемь недель — около 48%. Это первый опубликованный бенчмарк retention для подобных инструментов code intelligence.
3. Оценка пользователей: В опросе (N=137) и интервью с экспертами (N=12) 74.5% (102/137) пользователей подтвердили пользу и эффективность BitsAI-CR.
Все эксперты отметили пользу BitsAI-CR, указав на пожелания по скорости, кастомизации и поддержке языков.
Авторы обозначили чёткие планы по развитию BitsAI-CR:
1) Расширение языковой поддержки до всех языков программирования, а не только пяти основных.
2) Улучшение контекстного понимания. Сейчас BitsAI-CR анализирует код на уровне функций с ограниченным контекстом. В планах — кросс-файловый анализ (cross-file review), чтобы находить проблемы, связанные с архитектурой и зависимостями между файлами.
3) Постоянное развитие и доработки системы
#Software #AI #Engineering #Process #DevEx
Продолжаем рассмотрение интересного whitepaper о code review со второй части модели, а именно механизму data flywheel
Data flywheel — это системный подход к постоянному улучшению за счёт:
1. Annotation Feedback Integration: BitsAI-CR собирает и использует обратную связь пользователей для дообучения и улучшения датасетов.
2. Outdated Rate Measurement: введён новый метрик — Outdated Rate, который измеряет процент строк кода, изменённых после того, как BitsAI-CR их пометил. Это даёт объективную оценку того, насколько часто разработчики реально принимают предложения системы.
3. Dynamic Rule Adjustment: cистема постоянно корректирует правила review на основе точности и Outdated Rate, убирая те, что генерируют малоценные комментарии (низкий Outdated Rate при высокой точности).
Вместе эти компоненты создают цикл обратной связи, который шаг за шагом повышает качество code review на основе реального поведения разработчиков.
Авторы применили продвинутую стратегию обучения и оптимизации BitsAI-CR, включающую несколько ключевых элементов:
- В качестве базовой модели выбран Doubao-Pro-32K-0828 (собственная LLM ByteDance), что обусловлено требованиями безопасности и приватности данных. Размер последовательности выбран 8192 токена, так как 99% примеров review укладываются в этот лимит.
- Для дообучения RuleChecker и ReviewFilter использовалась техника LoRA (Low-Rank Adaptation)
- Также они учились на основе подробной таксономии правил code review, что дало
-- Структурированную основу для выявления и классификации проблем в коде
-- Системный сбор и разметку данных для обучения
-- Чёткие критерии для оценки качества системы
- Такой подход показал себя эффективным: BitsAI-CR, обученный на таксономии, достиг точности 57.03%, тогда как версия без таксономии (на случайных человеческих review) — лишь 16.83%.
Для оценки модели авторы новую метрику - Outdated Rate, измеряющий долю строк кода, изменённых после комментариев BitsAI-CR. Это позволяет:
1. Автоматически оценивать реальное влияние комментариев на практике
2. Понимать, насколько предложения системы действительно внедряются разработчиками
Такой подход закрывает недостатки традиционных метрик точности, которые требуют ручной разметки и не отражают реальную пользу для бизнеса.
При внедрении в production система показала впечатляющие технические результаты
1. Точность (Precision): Без таксономии и двухступенчатой архитектуры точность была около 25%. После внедрения этих элементов точность RuleChecker выросла с 27.9% до 62.6%, а ReviewFilter — с 35.6% до 75.0%. Это доказывает эффективность двухступенчатой архитектуры в снижении ложных срабатываний.
2. Outdated Rate: Для языка Go (основного в ByteDance) Outdated Rate вырос до 26.7% через 18 недель оптимизации. Для сравнения, у людей этот показатель колеблется между 35-46%. Постепенное приближение к человеческому уровню — свидетельство практической ценности BitsAI-CR.
Кроме того, BitsAI-CR быстро стал частью процесса разработки:
1. Аудитория: Более 12 000 Weekly Active Users (WAU), свыше 210 000 Weekly Page Views (WPV) — система интегрирована в рабочий процесс.
2. Retention: Retention на второй неделе — 61.64%, через восемь недель — около 48%. Это первый опубликованный бенчмарк retention для подобных инструментов code intelligence.
3. Оценка пользователей: В опросе (N=137) и интервью с экспертами (N=12) 74.5% (102/137) пользователей подтвердили пользу и эффективность BitsAI-CR.
Все эксперты отметили пользу BitsAI-CR, указав на пожелания по скорости, кастомизации и поддержке языков.
Авторы обозначили чёткие планы по развитию BitsAI-CR:
1) Расширение языковой поддержки до всех языков программирования, а не только пяти основных.
2) Улучшение контекстного понимания. Сейчас BitsAI-CR анализирует код на уровне функций с ограниченным контекстом. В планах — кросс-файловый анализ (cross-file review), чтобы находить проблемы, связанные с архитектурой и зависимостями между файлами.
3) Постоянное развитие и доработки системы
#Software #AI #Engineering #Process #DevEx
Telegram
Книжный куб
[1/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)
Интересная научная статья от ByteDance, создателя TikTok на тему автоматизированного code review с использованием GenAI. Интересно, что чуть раньше я уже разбирал как Google подходит…
Интересная научная статья от ByteDance, создателя TikTok на тему автоматизированного code review с использованием GenAI. Интересно, что чуть раньше я уже разбирал как Google подходит…
👍6❤3🔥2
[1/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Разработка программного обеспечения через приемочные тесты) (Рубрика #Engineering)
Перечитал эту книгу Маркуса Гэртнера десятилетней давности про подходы к разработке через приемочные тесты. В те времена я как раз познакомился с BDD (behavioral driven development). а точнее с Cucumber, а дальше почитал про ATDD. Сейчас книга все еще актуальна на уровне концепций, но ручную работу по составлению приемочных тестов грозятся забрать на себя LLM модели, смотри например whitepaper "Acceptance Test Generation with Large Language Models: An Industrial Case Study" от апреля 2025 года, где предлагается двухшаговый подход
Если говорить про саму книгу, то это практическое руководство начального уровня по внедрению и успешному применению методики ATDD. Основная цель работы — показать, как заказчики, разработчики и qa-инженеры могут совместно создавать тестируемые требования, что позволяет создавать высококачественный софт в сжатые сроки. Автор демонстрирует фундаментальные принципы ATDD через два сквозных кейса: систему для оплаты парковки, а также систему для управления светофорами. А дальше он описывает основные принципы ATDD, а также рассказывает как его внедрить в организациях. В первом кейса для автоматизации используются Ruby, Cucumber и Selenium, во второй части примеры реализованы на Java с использованием FitNesse. Каждый кейс сопровождается обширным набором артефактов, включая классы автоматизации тестирования, определения шагов и полные реализации.
Подробнее про содержание книги в следующем посте.
#QA #DevOps #Process #Software #Engineering #AI
Перечитал эту книгу Маркуса Гэртнера десятилетней давности про подходы к разработке через приемочные тесты. В те времена я как раз познакомился с BDD (behavioral driven development). а точнее с Cucumber, а дальше почитал про ATDD. Сейчас книга все еще актуальна на уровне концепций, но ручную работу по составлению приемочных тестов грозятся забрать на себя LLM модели, смотри например whitepaper "Acceptance Test Generation with Large Language Models: An Industrial Case Study" от апреля 2025 года, где предлагается двухшаговый подход
(i) generating acceptance test scenarios in natural language (in Gherkin) from user stories, and
(ii) converting these scenarios into executable test scripts (in Cypress), knowing the HTML code of the pages under test
Если говорить про саму книгу, то это практическое руководство начального уровня по внедрению и успешному применению методики ATDD. Основная цель работы — показать, как заказчики, разработчики и qa-инженеры могут совместно создавать тестируемые требования, что позволяет создавать высококачественный софт в сжатые сроки. Автор демонстрирует фундаментальные принципы ATDD через два сквозных кейса: систему для оплаты парковки, а также систему для управления светофорами. А дальше он описывает основные принципы ATDD, а также рассказывает как его внедрить в организациях. В первом кейса для автоматизации используются Ruby, Cucumber и Selenium, во второй части примеры реализованы на Java с использованием FitNesse. Каждый кейс сопровождается обширным набором артефактов, включая классы автоматизации тестирования, определения шагов и полные реализации.
Подробнее про содержание книги в следующем посте.
#QA #DevOps #Process #Software #Engineering #AI
👍8🔥4❤2
[2/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Разработка программного обеспечения через приемочные тесты) (Рубрика #Engineering)
Продолжая рассказ о книге, расскажу про ключевые принципы ATDD, изложенные в ней
1. Коллаборативная спецификация требований. ATDD базируется на совместной работе бизнес-заказчиков, разработчиков и тестировщиков для формулирования тестируемых требований. Цикл состоит из четырех стадий:
- Discuss - обсуждение пользовательских историй
- Distill - выделение критериев приемки
- Develop - разработка
- Demo - демонстрация прототипа
Этот подход гарантирует, что все члены команды имеют одинаковое понимание целей.
2. Примеры как основа коммуникации. В ATDD команда использует конкретные примеры для описания поведения системы вместо абстрактных требований. Эти примеры служат живой документацией и должны быть написаны на языке бизнеса, понятном всем участникам процесса.
3. Автоматизация как буквальная интерпретация. Приемочные тесты должны автоматизироваться таким образом, чтобы они буквально отражали описанные примеры. Это означает, что автоматизированные тесты становятся исполняемой документацией, которая всегда актуальна и может служить регрессионным тестированием.
4. Тестирование до написания кода. Подобно TDD, в ATDD тесты создаются до написания продуктивного кода. Это помогает фокусироваться на том, что действительно нужно пользователю, и избегать оверинжиниринга.
5. Формат Given-When-Then. Для описания сценариев часто используется формат Gherkin с конструкциями Given-When-Then. Given описывает начальные условия, When — действия пользователя, Then — ожидаемые результаты. Этот формат делает тесты читаемыми как для технических, так и для нетехнических участников команды.
6. Фокус на бизнес-ценности. В отличие от unit-тестов, приемочные тесты проверяют функциональность с точки зрения пользователя и бизнес-ценности. Они отвечают на вопрос "работает ли система так, как ожидает заказчик", а не "работает ли конкретный метод правильно".
7. Интеграция с процессом разработки. ATDD не заменяет другие практики тестирования, а дополняет их. Он прекрасно сочетается с TDD на уровне модульных тестов, создавая многоуровневую систему обеспечения качества.
8. Постоянная обратная связь. Автоматизированные приемочные тесты обеспечивают постоянную обратную связь о состоянии системы.
9. Чистота и поддерживаемость тестов. Приемочные тесты должны быть написаны чисто и поддерживаемо. Они являются долгосрочными активами проекта и требуют такого же внимания к качеству кода, как и продакшен код. Рефакторинг тестов — неотъемлемая часть процесса.
10. Демонстрация как валидация. Финальная стадия цикла ATDD — демонстрация работающей функциональности заинтересованным сторонам. Это не только показывает результат, но и позволяет получить обратную связь для дальнейших итераций. Демо служит точкой валидации того, что построено именно то, что требовалось.
В итоге, книга ок с точки зрения базы, но требуется обновление в части
- Использования LLM для генерации тестов (подробнее в "Acceptance Test Generation with Large Language Models: An Industrial Case Study")
- Использовании актуального стека (например, Playwright или Cypress).
- Интеграции в процессы CI/CD
P.S.
Книга отправляется в booksharing уголок, что расположен в нашем московском офисе на 7 этаже (надеюсь, что она найдет себе новых читателей).
#QA #DevOps #Process #Software #Engineering #AI
Продолжая рассказ о книге, расскажу про ключевые принципы ATDD, изложенные в ней
1. Коллаборативная спецификация требований. ATDD базируется на совместной работе бизнес-заказчиков, разработчиков и тестировщиков для формулирования тестируемых требований. Цикл состоит из четырех стадий:
- Discuss - обсуждение пользовательских историй
- Distill - выделение критериев приемки
- Develop - разработка
- Demo - демонстрация прототипа
Этот подход гарантирует, что все члены команды имеют одинаковое понимание целей.
2. Примеры как основа коммуникации. В ATDD команда использует конкретные примеры для описания поведения системы вместо абстрактных требований. Эти примеры служат живой документацией и должны быть написаны на языке бизнеса, понятном всем участникам процесса.
3. Автоматизация как буквальная интерпретация. Приемочные тесты должны автоматизироваться таким образом, чтобы они буквально отражали описанные примеры. Это означает, что автоматизированные тесты становятся исполняемой документацией, которая всегда актуальна и может служить регрессионным тестированием.
4. Тестирование до написания кода. Подобно TDD, в ATDD тесты создаются до написания продуктивного кода. Это помогает фокусироваться на том, что действительно нужно пользователю, и избегать оверинжиниринга.
5. Формат Given-When-Then. Для описания сценариев часто используется формат Gherkin с конструкциями Given-When-Then. Given описывает начальные условия, When — действия пользователя, Then — ожидаемые результаты. Этот формат делает тесты читаемыми как для технических, так и для нетехнических участников команды.
6. Фокус на бизнес-ценности. В отличие от unit-тестов, приемочные тесты проверяют функциональность с точки зрения пользователя и бизнес-ценности. Они отвечают на вопрос "работает ли система так, как ожидает заказчик", а не "работает ли конкретный метод правильно".
7. Интеграция с процессом разработки. ATDD не заменяет другие практики тестирования, а дополняет их. Он прекрасно сочетается с TDD на уровне модульных тестов, создавая многоуровневую систему обеспечения качества.
8. Постоянная обратная связь. Автоматизированные приемочные тесты обеспечивают постоянную обратную связь о состоянии системы.
9. Чистота и поддерживаемость тестов. Приемочные тесты должны быть написаны чисто и поддерживаемо. Они являются долгосрочными активами проекта и требуют такого же внимания к качеству кода, как и продакшен код. Рефакторинг тестов — неотъемлемая часть процесса.
10. Демонстрация как валидация. Финальная стадия цикла ATDD — демонстрация работающей функциональности заинтересованным сторонам. Это не только показывает результат, но и позволяет получить обратную связь для дальнейших итераций. Демо служит точкой валидации того, что построено именно то, что требовалось.
В итоге, книга ок с точки зрения базы, но требуется обновление в части
- Использования LLM для генерации тестов (подробнее в "Acceptance Test Generation with Large Language Models: An Industrial Case Study")
- Использовании актуального стека (например, Playwright или Cypress).
- Интеграции в процессы CI/CD
P.S.
Книга отправляется в booksharing уголок, что расположен в нашем московском офисе на 7 этаже (надеюсь, что она найдет себе новых читателей).
#QA #DevOps #Process #Software #Engineering #AI
Telegram
Книжный куб
[1/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Разработка программного обеспечения через приемочные тесты) (Рубрика #Engineering)
Перечитал эту книгу Маркуса Гэртнера десятилетней давности про подходы к разработке через…
Перечитал эту книгу Маркуса Гэртнера десятилетней давности про подходы к разработке через…
👍6❤4🔥1
Анастасия, моя любимая жена, получила сегодня диплом по психоаналитическому бизнес-консультированию в ВШЭ. Она два года шла к этому диплому и сегодня обучение официально закончилось и диплом оказался в ее руках. Она попробовала персональные консультации, но в итоге решила вернуться с новыми знаниями в IT. Она опять стала руководителем и возглавила проектный офис в небольшой IT компании. Ей нравится групповая динамика и поиска баланса между бизнес-результатами и человеческими взаимоотношениями.
P.S.
Мы записывали с Настей подкаст из серии Code of Leadership, где обсуждали модель групповой динамики "BART" и сравнивали эту модель с моделью командообразования Такмана.
#Psychology #Management #Project #Process #Edu
P.S.
Мы записывали с Настей подкаст из серии Code of Leadership, где обсуждали модель групповой динамики "BART" и сравнивали эту модель с моделью командообразования Такмана.
#Psychology #Management #Project #Process #Edu
👍56❤26🔥20😍6🏆3
State of Code Developer Survey report by SonarSource (Рубрика #AI)
Интересный 57-страничный отчет от производителя SonarQube, средства для верификации качества кода. Отчет вышел еще 8 января 2026 года, а основан был на опросе от октября 2025 года. Если обобщить одной фразой основную мысль, то она такая: AI не снял нагрузку с разработки - он просто перенёс бутылочное горлышко из написания в в верификацию кода.
Методология исследования выглядела как количественный онлайн-опрос на 1149 респондентов по всему миру. В выборке - взрослые специалисты в tech-ролях, которые пишут код или управляют разработчиками и использовали AI в работе за последний год. Вопросы были не просто "используете ли вы AI", а как именно он меняет инженерную работу:
- Где AI реально помогает
- Где есть разрыв между принятием (adoption) и эффетивностью (effectiveness)
- Доверяют ли разработчики AI-коду
- Как меняются безопасность и технический долг
- Что происходит с junior/senior инженерами и есть ли разница в их отношении к AI
- Что с использованием AI агентов
- Что происходит с управлением всем этим зоопарком инструментов
Результаты вышли такие
- AI уже не эксперимент, а рутина: 72% тех, кто попробовал AI coding tools, используют их каждый день, а в среднем 42% кода в коммитах уже AI-generated или AI-assisted
- Ценность AI распределена неровно: лучше всего AI показывает себя в документации, объяснении существующего кода и генерации тестов; заметно хуже - в рефакторинге и изменении существующего кода (напомню этот опрос был до большого сдвига в возможностях моделей осенью 2025 года)
- Параллельно команды жонглируют в среднем 4 AI-инструментами, а 35% разработчиков используют часть из них через личные аккаунты, а не через санкционированный на работе доступ.
В итоге, скорость личная выросла, но доверие не появилось. 96% не полностью доверяют функциональной корректности AI-кода. 95% тратят время на review/testing/fixing AI output, 38% говорят, что ревьюить AI-код сложнее, чем человеческий, а только 48% всегда проверяют AI-assisted code перед commit. Неудивительно, что самым важным навыком в AI-era респонденты назвали ревью и валидацию AI-кода на качество и безопасность.
Если говорить про больные места, то 57% опасаются утечки чувствительных данных, 47% - появления новых subtle security vulnerabilities. По техническому долгу картина тоже двойственная: 88% увидели хотя бы один негативный эффект AI на долг, чаще всего “код выглядит правильным, но ненадёжен” (53%) и лишний/дублирующий код (40%). Но 93% одновременно увидели и пользу: AI помогает с документацией, тестами/debugging и частью refactoring work. Junior-разработчики чаще опираются на AI и чаще говорят, что проверка такого кода требует больше усилий, чем у senior.
Также заметна разница между организациями разного масштаба:
- Малые и средние компании (SMB) снимают больше пользы с ускорения поставки и быстрее улучшают time-to-market, а корпораты чаще видят улучшения в качестве кода и поддерживаемости - похоже, за счёт более жёсткой governance и контроля AI-рисков.
Выводы авторов отчета простые - процессам разработки нужно понимать происхожение кода, усилить ревью кода, добавить quality gates, статический анализ, и выстроить нормальный governance вокруг AI-инструментов. Иначе ускоряется не поставка, а производство непроверенного кода. Ну и конечно со всем этим может помочь SonarQube от авторов исследования:)
#Engineering #Software #DevOps #DevEx #Process #Management #Metrics
Интересный 57-страничный отчет от производителя SonarQube, средства для верификации качества кода. Отчет вышел еще 8 января 2026 года, а основан был на опросе от октября 2025 года. Если обобщить одной фразой основную мысль, то она такая: AI не снял нагрузку с разработки - он просто перенёс бутылочное горлышко из написания в в верификацию кода.
Методология исследования выглядела как количественный онлайн-опрос на 1149 респондентов по всему миру. В выборке - взрослые специалисты в tech-ролях, которые пишут код или управляют разработчиками и использовали AI в работе за последний год. Вопросы были не просто "используете ли вы AI", а как именно он меняет инженерную работу:
- Где AI реально помогает
- Где есть разрыв между принятием (adoption) и эффетивностью (effectiveness)
- Доверяют ли разработчики AI-коду
- Как меняются безопасность и технический долг
- Что происходит с junior/senior инженерами и есть ли разница в их отношении к AI
- Что с использованием AI агентов
- Что происходит с управлением всем этим зоопарком инструментов
Результаты вышли такие
- AI уже не эксперимент, а рутина: 72% тех, кто попробовал AI coding tools, используют их каждый день, а в среднем 42% кода в коммитах уже AI-generated или AI-assisted
- Ценность AI распределена неровно: лучше всего AI показывает себя в документации, объяснении существующего кода и генерации тестов; заметно хуже - в рефакторинге и изменении существующего кода (напомню этот опрос был до большого сдвига в возможностях моделей осенью 2025 года)
- Параллельно команды жонглируют в среднем 4 AI-инструментами, а 35% разработчиков используют часть из них через личные аккаунты, а не через санкционированный на работе доступ.
В итоге, скорость личная выросла, но доверие не появилось. 96% не полностью доверяют функциональной корректности AI-кода. 95% тратят время на review/testing/fixing AI output, 38% говорят, что ревьюить AI-код сложнее, чем человеческий, а только 48% всегда проверяют AI-assisted code перед commit. Неудивительно, что самым важным навыком в AI-era респонденты назвали ревью и валидацию AI-кода на качество и безопасность.
Если говорить про больные места, то 57% опасаются утечки чувствительных данных, 47% - появления новых subtle security vulnerabilities. По техническому долгу картина тоже двойственная: 88% увидели хотя бы один негативный эффект AI на долг, чаще всего “код выглядит правильным, но ненадёжен” (53%) и лишний/дублирующий код (40%). Но 93% одновременно увидели и пользу: AI помогает с документацией, тестами/debugging и частью refactoring work. Junior-разработчики чаще опираются на AI и чаще говорят, что проверка такого кода требует больше усилий, чем у senior.
Также заметна разница между организациями разного масштаба:
- Малые и средние компании (SMB) снимают больше пользы с ускорения поставки и быстрее улучшают time-to-market, а корпораты чаще видят улучшения в качестве кода и поддерживаемости - похоже, за счёт более жёсткой governance и контроля AI-рисков.
Выводы авторов отчета простые - процессам разработки нужно понимать происхожение кода, усилить ревью кода, добавить quality gates, статический анализ, и выстроить нормальный governance вокруг AI-инструментов. Иначе ускоряется не поставка, а производство непроверенного кода. Ну и конечно со всем этим может помочь SonarQube от авторов исследования:)
#Engineering #Software #DevOps #DevEx #Process #Management #Metrics
❤7👍4🔥3
От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear) (Рубрика #Management)
Написал статью про то, что эпоха фразы “заведи тикет в Jira” подходит к концу … и не потому, что тикеты исчезнут, и не потому, что завтра все команды внезапно переедут в какой-то новый инструмент, а потому, что тикет перестает быть центром мира. В классической модели он был основной единицей координации: в нем жили требования, приоритет, исполнитель, статус, комментарии, передача ответственности между ролями. В AI-native мире этой единицей постепенно становится не тикет, а context: намерение, ограничения, права доступа, история решений, автоматизации и агенты, которые способны доводить работу до результата.
В некотором смысле эта статья логично продолжает две предыдущие
- Про переход от классического PDLC к AI-native разработке
- Про переход от AI-native разработки к AI-native организации
А в этой статье я размышляю о том, а как будет выглядеть управление работой в таких компаниях
#Engineering #Software #DevOps #DevEx #Process #Management #Metrics
Написал статью про то, что эпоха фразы “заведи тикет в Jira” подходит к концу … и не потому, что тикеты исчезнут, и не потому, что завтра все команды внезапно переедут в какой-то новый инструмент, а потому, что тикет перестает быть центром мира. В классической модели он был основной единицей координации: в нем жили требования, приоритет, исполнитель, статус, комментарии, передача ответственности между ролями. В AI-native мире этой единицей постепенно становится не тикет, а context: намерение, ограничения, права доступа, история решений, автоматизации и агенты, которые способны доводить работу до результата.
В некотором смысле эта статья логично продолжает две предыдущие
- Про переход от классического PDLC к AI-native разработке
- Про переход от AI-native разработки к AI-native организации
А в этой статье я размышляю о том, а как будет выглядеть управление работой в таких компаниях
#Engineering #Software #DevOps #DevEx #Process #Management #Metrics
Medium
От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)
Кажется, эпоха фразы “заведи тикет в Jira” подходит к концу … и не потому, что тикеты исчезнут, и не потому, что завтра все команды…
🔥9❤3👎3🤨2👍1