Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks (Рубрика #AI)
2 декабря вышло интересное исследование про безопасность vibe-coding от авторов Songwen Zhao, Danqing Wang, Kexun Zhang, Jiaxuan Luo, Zhuo Li и Lei Li. Основная группа ученых здесь связана с университетом Карнеги Меллон.
Если объяснять на пальцах суть исследования, то авторы сначала рассказывают, что vibe coding - новый подход к программированию, при котором человек-программист формулирует задачу на естественном языке, а агент на базе большой языковой модели (LLM) выполняет сложные задачи кодирования с минимальным ручным вмешательством. Но вот вопрос, а код, полученный таким способом безопасен?
Для ответа на этот вопрос авторы разработали новый бенчмарк SUSVIBES, 200 реалистичных задач по разработке фичей для существующих проектов с открытым исходным кодом. Интересно, что каждая из этих задач взята из реальной истории разработки: ранее, когда эти фичи реализовывали люди, в код по незнанию закрались уязвимости безопасности. Задачи намного сложнее единичных примеров из предыдущих бенчей безопасности - они требуют правок в среднем в ~180 строк кода, затрагивая несколько файлов в крупном репозитории (в отличие от тривиальных задач в рамках одной функции или файла). Совокупно задачи покрывают 77 различных категорий уязвимостей согласно классификации CWE.
Прогон этого бенчмарка на популярных агентских системах (SWE-Agent, OpenHands, Claude Code) с популярными LLM (Claude 4 Sonnet, Kimi K2, Gemini 2.5 Pro) показал тревожную картину. Лучшая система (агент SWE-Agent с моделью Claude 4 Sonnet от Anthropic) успешно решала 61% поставленных задач, но лишь 10,5% из этих решений оказались действительно безопасными, то есть не содержали уязвимостей.
Попытки улучшить ситуацию простыми мерами - например, снабжать агента дополнительными подсказками о возможных уязвимостях в тексте задания - не дали существенного эффекта и агенты чаще не справлялись с функциональной частью задачи, а общий успех безопасных решений почти не вырос.
В итоге, на текущем уровне развития технологий вайбкодинг ускоряет создание функционала, но скрыто приносит проблемы с безопасностью. Без существенных улучшений в архитектуре AI-агентов или обучении моделей, доверять такой код в ответственных системах нельзя. Исследование служит призывом к индустрии - заняться разработкой таких улучшений.
P.S.
Мне особо понравился пайплпан сбора бенчмарка и прогона тестов:)
Пайплайн автоматизирован и основан на реальных репозиториях с известными уязвимостями. Для каждой уязвимости из истории проекта они подготовили соответствующую задачу на добавление функционала, где внедрение этой функции ранее привело к проблеме безопасности. В задачу включаются: актуальное состояние кода (репозиторий до внесения исправления уязвимости), описание требуемой новой функции (feature request) и набор тестов. Тесты разбиты на две категории - функциональные тесты, и тесты безопасности, которые ловят именно ту уязвимость, что была допущена изначально. Таким образом, заранее известно, каким требованиям должно удовлетворять безопасное решение.
На каждом таком задании испытывались агенты, что запускалиси внутри изолированного окружения (например, Docker-контейнера) с доступом к коду проекта. Получив задачу (описание новой функции), агент мог взаимодействовать с окружением: читать и редактировать файлы, компилировать и запускать проект, запускать тесты и т.п., делая это в несколько итераций, имитируя реальный процесс разработки. В конце агент выдавал patch - набор изменений к исходному коду репозитория, реализующий требуемую функциональность. Этот сгенерированный патч автоматически прогонялся через оба набора тестов. Метрики успеха были такими:
- Func Pass - процент задач, где патч прошёл все функциональные тесты (правильно реализовал задачу).
- Sec Pass - процент задач, где патч прошёл также все тесты безопасности (не внёс уязвимостей).
#Engineering #Software #Processes #Productivity #Economics #Security
2 декабря вышло интересное исследование про безопасность vibe-coding от авторов Songwen Zhao, Danqing Wang, Kexun Zhang, Jiaxuan Luo, Zhuo Li и Lei Li. Основная группа ученых здесь связана с университетом Карнеги Меллон.
Если объяснять на пальцах суть исследования, то авторы сначала рассказывают, что vibe coding - новый подход к программированию, при котором человек-программист формулирует задачу на естественном языке, а агент на базе большой языковой модели (LLM) выполняет сложные задачи кодирования с минимальным ручным вмешательством. Но вот вопрос, а код, полученный таким способом безопасен?
Для ответа на этот вопрос авторы разработали новый бенчмарк SUSVIBES, 200 реалистичных задач по разработке фичей для существующих проектов с открытым исходным кодом. Интересно, что каждая из этих задач взята из реальной истории разработки: ранее, когда эти фичи реализовывали люди, в код по незнанию закрались уязвимости безопасности. Задачи намного сложнее единичных примеров из предыдущих бенчей безопасности - они требуют правок в среднем в ~180 строк кода, затрагивая несколько файлов в крупном репозитории (в отличие от тривиальных задач в рамках одной функции или файла). Совокупно задачи покрывают 77 различных категорий уязвимостей согласно классификации CWE.
Прогон этого бенчмарка на популярных агентских системах (SWE-Agent, OpenHands, Claude Code) с популярными LLM (Claude 4 Sonnet, Kimi K2, Gemini 2.5 Pro) показал тревожную картину. Лучшая система (агент SWE-Agent с моделью Claude 4 Sonnet от Anthropic) успешно решала 61% поставленных задач, но лишь 10,5% из этих решений оказались действительно безопасными, то есть не содержали уязвимостей.
Попытки улучшить ситуацию простыми мерами - например, снабжать агента дополнительными подсказками о возможных уязвимостях в тексте задания - не дали существенного эффекта и агенты чаще не справлялись с функциональной частью задачи, а общий успех безопасных решений почти не вырос.
В итоге, на текущем уровне развития технологий вайбкодинг ускоряет создание функционала, но скрыто приносит проблемы с безопасностью. Без существенных улучшений в архитектуре AI-агентов или обучении моделей, доверять такой код в ответственных системах нельзя. Исследование служит призывом к индустрии - заняться разработкой таких улучшений.
P.S.
Мне особо понравился пайплпан сбора бенчмарка и прогона тестов:)
Пайплайн автоматизирован и основан на реальных репозиториях с известными уязвимостями. Для каждой уязвимости из истории проекта они подготовили соответствующую задачу на добавление функционала, где внедрение этой функции ранее привело к проблеме безопасности. В задачу включаются: актуальное состояние кода (репозиторий до внесения исправления уязвимости), описание требуемой новой функции (feature request) и набор тестов. Тесты разбиты на две категории - функциональные тесты, и тесты безопасности, которые ловят именно ту уязвимость, что была допущена изначально. Таким образом, заранее известно, каким требованиям должно удовлетворять безопасное решение.
На каждом таком задании испытывались агенты, что запускалиси внутри изолированного окружения (например, Docker-контейнера) с доступом к коду проекта. Получив задачу (описание новой функции), агент мог взаимодействовать с окружением: читать и редактировать файлы, компилировать и запускать проект, запускать тесты и т.п., делая это в несколько итераций, имитируя реальный процесс разработки. В конце агент выдавал patch - набор изменений к исходному коду репозитория, реализующий требуемую функциональность. Этот сгенерированный патч автоматически прогонялся через оба набора тестов. Метрики успеха были такими:
- Func Pass - процент задач, где патч прошёл все функциональные тесты (правильно реализовал задачу).
- Sec Pass - процент задач, где патч прошёл также все тесты безопасности (не внёс уязвимостей).
#Engineering #Software #Processes #Productivity #Economics #Security
1🔥12👍8❤3☃1
[1/2] How did we get to where we are in AI? (Рубрика #AI)
Пару недель назад Джефф Дин (Jeff Dean), Chief Data Science at Google, выступал в Stanford AI Club, где он приводил ретроспективу последних 15+ лет развития искусственного интеллекта. Он объяснял как сочетание трех факторов: масштабирования вычислений (scale), новых алгоритмов и специализированного железа привело к появлению современных больших мультимодальных моделей, таких как Gemini 3.0. Сам Джефф - это легендарная фигура в мире CS и software engineering, который с 1999 году работает в Google, сейчас он Chief Data Science, а вообще приложил руку к MapReduce, BigTable, Spanner, TensorFlow и сейчас к Gemini 3. Ниже представлен список whitepaper, который Джефф Дин выделил как ключевые точки развития технологий (в части из них он был соавтором)
2012 - Large Scale Distributed Deep Networks
До этого момента нейросети тренировались на локальных машинах. Дин и команда создали программную архитектуру для распределенного обучения на тысячах CPU. Это позволило тренировать модели в 50-100 раз больше, чем кто-либо до этого. В самом whitepaper говорится про использование параллелизма данных и моделей (Data/Model Parallelism) и асинхронного стохастического градиентного спуска.
2012 - Building high-level features using large scale unsupervised learning
В этом эксперименте нейросеть "смотрела" 10 миллионов случайных кадров из YouTube без разметки. В итоге, модель самостоятельно научилась распознавать концепции (например, кошек, человеческие лица) просто наблюдая за данными. Это доказало эффективность unsupervised learning на больших масштабах.
2013 - Distributed Representations of Words and Phrases and their Compositionality
В этой whitepaper речь шла про алгоритм Word2Vec для построения векторных представлений слов и переходом восприятия слова как дискретного значения к вектору в многомерном пристранстве. В итоге, оказалось, что слова с похожим смыслом оказываются рядом в векторном пространстве. Более того, арифметические операции над векторами сохраняют семантику (знаменитый пример: King - Man + Woman = Queen).
2014 - Sequence to Sequence Learning with Neural Networks
Авторы представили алгоритм Seq2Seq с использованием рекуррентных сетей (LSTM) для задач перевода последовательностей. Работало это примерно так: одна сеть кодирует входную фразу (например, на английском) в вектор, а другая декодирует его в выходную (например, на французском). Этот подход отработал хорошо и стал базой для машинного перевода на года.
2015 - Distilling the Knowledge in a Neural Network
Авторы описали метод сжатия знаний огромной модели в маленькую и быструю. Концепт был в том, что маленькая модель ("студент") учится не только на правильных ответах, но и подражая распределению вероятностей большой модели ("учителя"). Это позволяет запускать мощный ИИ на мобильных устройствах.
2017 - In-Datacenter Performance Analysis of a Tensor Processing Unit
Рассказ про то, как ребята в Google поняли, что надо придумать что-то вместо CPU и GPU для работы нейросетей. Так ребята решили делать TPU (tensor process unit), чью историю я разбирал отдельно. Сделали в 2015 и запустили, а рассказали про это в 2017. Ну и дальше Джефф еще вспоминает в лекции про конфигурируемый суперкомпьютер TPU v4: An Optically Reconfigurable Supercomputer for Machine Learning with Hardware Support for Embeddings, что сделали в 2017, а рассказли в whitepaper в 2023
2017 - Attention Is All You Need
Знаменитая статья, что принесла в мир революционную архитектуру трансформеров, что позволило отказаться от RNN (рекуррентных сетей) в пользу механизма внимания (Self-Attention). Концепт в том, что теперь модель может "смотреть" на все слова в предложении одновременно, а не по очереди - это позволяет балансировать куда ей обращать внимание + есть параллелизм по входу. Это обеспечило кратный рост скорости обучения и качества, став основой для всех современных LLM (GPT, Gemini, Claude).
Продолжение обзора во второй части.
#AI #ML #Software #Engineering #Architecture #Infrastructure #Data
Пару недель назад Джефф Дин (Jeff Dean), Chief Data Science at Google, выступал в Stanford AI Club, где он приводил ретроспективу последних 15+ лет развития искусственного интеллекта. Он объяснял как сочетание трех факторов: масштабирования вычислений (scale), новых алгоритмов и специализированного железа привело к появлению современных больших мультимодальных моделей, таких как Gemini 3.0. Сам Джефф - это легендарная фигура в мире CS и software engineering, который с 1999 году работает в Google, сейчас он Chief Data Science, а вообще приложил руку к MapReduce, BigTable, Spanner, TensorFlow и сейчас к Gemini 3. Ниже представлен список whitepaper, который Джефф Дин выделил как ключевые точки развития технологий (в части из них он был соавтором)
2012 - Large Scale Distributed Deep Networks
До этого момента нейросети тренировались на локальных машинах. Дин и команда создали программную архитектуру для распределенного обучения на тысячах CPU. Это позволило тренировать модели в 50-100 раз больше, чем кто-либо до этого. В самом whitepaper говорится про использование параллелизма данных и моделей (Data/Model Parallelism) и асинхронного стохастического градиентного спуска.
2012 - Building high-level features using large scale unsupervised learning
В этом эксперименте нейросеть "смотрела" 10 миллионов случайных кадров из YouTube без разметки. В итоге, модель самостоятельно научилась распознавать концепции (например, кошек, человеческие лица) просто наблюдая за данными. Это доказало эффективность unsupervised learning на больших масштабах.
2013 - Distributed Representations of Words and Phrases and their Compositionality
В этой whitepaper речь шла про алгоритм Word2Vec для построения векторных представлений слов и переходом восприятия слова как дискретного значения к вектору в многомерном пристранстве. В итоге, оказалось, что слова с похожим смыслом оказываются рядом в векторном пространстве. Более того, арифметические операции над векторами сохраняют семантику (знаменитый пример: King - Man + Woman = Queen).
2014 - Sequence to Sequence Learning with Neural Networks
Авторы представили алгоритм Seq2Seq с использованием рекуррентных сетей (LSTM) для задач перевода последовательностей. Работало это примерно так: одна сеть кодирует входную фразу (например, на английском) в вектор, а другая декодирует его в выходную (например, на французском). Этот подход отработал хорошо и стал базой для машинного перевода на года.
2015 - Distilling the Knowledge in a Neural Network
Авторы описали метод сжатия знаний огромной модели в маленькую и быструю. Концепт был в том, что маленькая модель ("студент") учится не только на правильных ответах, но и подражая распределению вероятностей большой модели ("учителя"). Это позволяет запускать мощный ИИ на мобильных устройствах.
2017 - In-Datacenter Performance Analysis of a Tensor Processing Unit
Рассказ про то, как ребята в Google поняли, что надо придумать что-то вместо CPU и GPU для работы нейросетей. Так ребята решили делать TPU (tensor process unit), чью историю я разбирал отдельно. Сделали в 2015 и запустили, а рассказали про это в 2017. Ну и дальше Джефф еще вспоминает в лекции про конфигурируемый суперкомпьютер TPU v4: An Optically Reconfigurable Supercomputer for Machine Learning with Hardware Support for Embeddings, что сделали в 2017, а рассказли в whitepaper в 2023
2017 - Attention Is All You Need
Знаменитая статья, что принесла в мир революционную архитектуру трансформеров, что позволило отказаться от RNN (рекуррентных сетей) в пользу механизма внимания (Self-Attention). Концепт в том, что теперь модель может "смотреть" на все слова в предложении одновременно, а не по очереди - это позволяет балансировать куда ей обращать внимание + есть параллелизм по входу. Это обеспечило кратный рост скорости обучения и качества, став основой для всех современных LLM (GPT, Gemini, Claude).
Продолжение обзора во второй части.
#AI #ML #Software #Engineering #Architecture #Infrastructure #Data
❤6👍2🔥2
[2/2] How did we get to where we are in AI? (Рубрика #AI)
Продолжая рассказ про выступление Джеффа Дина надо рассказать, а какие ключевые whitepapers выходили после Attention Is All You Need и дальше поделится выводами о том, где мы сейчас
2017 - Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer
Статья про распространенный сейчас подход с разряженными сетями или mixture of experts (MOE). В статье показывается как с помощью условного вычисления можно строить "возмутительно большие" сети с десятками и сотнями миллиардов параметров, почти не увеличивая вычислительные затраты по сравнению с обычными моделями.
2018 - BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding
Авторы показали, что одну большую двунаправленную трансформерную модель можно один раз предобучить на сыром тексте, а потом с минимальными доработками дообучать под десятки разных NLP‑задач, получая state‑of‑the‑art без спецархитектур под каждую задачу.
2021 - An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale
В этой статье авторы применили подход трансформеров для классификации изображений. Интерес в том, что это можно делать без CNN - достаточно взять "чистый" трансформер и кормить ему изображение как последовательность элементов фиксированного размера (тот самый "16×16 слов" в названии).
2022 - Pathways: Asynchronous Distributed Dataflow for ML
Статья про асинхронный распределённый поток данных, когда вычисление задаётся как граф операторов, обменивающихся futures. А дальше единый контроллер может параллельно планировать и шедулить гетерогенные задачи на кластере TPU, скрывая зависимости в data‑plane и упрощая программную модель и управление ресурсами. В общем, это обеспечивает масштабирование вычислений на масштабе Google
2022 - Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
Открытие было в том, что модели лучше решают задачи, если просить их "подумать шаг за шагом". Если в промпте показать модели пример рассуждения, она начинает генерировать промежуточные шаги вычислений, что резко повышает точность в математике и логике.
Напоследок Джефф упоминает релиз новой модели Gemini 3.0, которая объединяет все предыдущие достижения, которые помогли ей выбить SOTA по многим бенчам.
В итоге, если посмотреть лекцию и полистать whitepaper, то можно сделать примерно следующие выводы
- Масштаб имеет значение. Прогресс последних 15 лет был обеспечен не только новыми идеями, но и грубой вычислительной мощностью. Рост количества параметров и объема данных неизменно приводил к появлению новых способностей (emergent capabilities), которых не было у маленьких моделей (например, понимание юмора или решение задач по физике).
- Специализация железа неизбежна. Универсальные процессоры (CPU) больше не являются драйвером прогресса. Будущее за специализированными чипами (как TPU), заточенными под низкоточную линейную алгебру. Энергоэффективность становится ключевым ограничением для дальнейшего роста моделей.
- Разреженные модели (Sparse Models) - путь к эффективности. Дин подчеркнул эффект перехода к архитектурам (таким как MoE), где для обработки одного запроса активируется лишь малая часть нейросети (1-5%). Это позволяет делать модели колоссальными по объему "знаний", но быстрыми в работе.
- Мультимодальность как стандарт. ИИ перестает быть просто "текстовым". Современные системы нативно понимают и генерируют видео, аудио и изображения. Пример из видео: модель может прочитать рукописные рецепты на разных языках, перевести их, сгенерировать картинки блюд и написать код готового веб-сайта.
- ИИ как помощник в науке и творчестве. Основное позитивное влияние ИИ ожидается в ускорении научных открытий (AlphaFold, материаловедение) и снижении порога входа в сложные навыки (программирование, дизайн).
- В развитии этой технологии существуют риски. Например, сгенерированный контент становится неотличимым от реального, и нужны технические и социальные механизмы защиты.
#AI #ML #Software #Engineering #Architecture #Infrastructure #Data
Продолжая рассказ про выступление Джеффа Дина надо рассказать, а какие ключевые whitepapers выходили после Attention Is All You Need и дальше поделится выводами о том, где мы сейчас
2017 - Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer
Статья про распространенный сейчас подход с разряженными сетями или mixture of experts (MOE). В статье показывается как с помощью условного вычисления можно строить "возмутительно большие" сети с десятками и сотнями миллиардов параметров, почти не увеличивая вычислительные затраты по сравнению с обычными моделями.
2018 - BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding
Авторы показали, что одну большую двунаправленную трансформерную модель можно один раз предобучить на сыром тексте, а потом с минимальными доработками дообучать под десятки разных NLP‑задач, получая state‑of‑the‑art без спецархитектур под каждую задачу.
2021 - An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale
В этой статье авторы применили подход трансформеров для классификации изображений. Интерес в том, что это можно делать без CNN - достаточно взять "чистый" трансформер и кормить ему изображение как последовательность элементов фиксированного размера (тот самый "16×16 слов" в названии).
2022 - Pathways: Asynchronous Distributed Dataflow for ML
Статья про асинхронный распределённый поток данных, когда вычисление задаётся как граф операторов, обменивающихся futures. А дальше единый контроллер может параллельно планировать и шедулить гетерогенные задачи на кластере TPU, скрывая зависимости в data‑plane и упрощая программную модель и управление ресурсами. В общем, это обеспечивает масштабирование вычислений на масштабе Google
2022 - Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
Открытие было в том, что модели лучше решают задачи, если просить их "подумать шаг за шагом". Если в промпте показать модели пример рассуждения, она начинает генерировать промежуточные шаги вычислений, что резко повышает точность в математике и логике.
Напоследок Джефф упоминает релиз новой модели Gemini 3.0, которая объединяет все предыдущие достижения, которые помогли ей выбить SOTA по многим бенчам.
В итоге, если посмотреть лекцию и полистать whitepaper, то можно сделать примерно следующие выводы
- Масштаб имеет значение. Прогресс последних 15 лет был обеспечен не только новыми идеями, но и грубой вычислительной мощностью. Рост количества параметров и объема данных неизменно приводил к появлению новых способностей (emergent capabilities), которых не было у маленьких моделей (например, понимание юмора или решение задач по физике).
- Специализация железа неизбежна. Универсальные процессоры (CPU) больше не являются драйвером прогресса. Будущее за специализированными чипами (как TPU), заточенными под низкоточную линейную алгебру. Энергоэффективность становится ключевым ограничением для дальнейшего роста моделей.
- Разреженные модели (Sparse Models) - путь к эффективности. Дин подчеркнул эффект перехода к архитектурам (таким как MoE), где для обработки одного запроса активируется лишь малая часть нейросети (1-5%). Это позволяет делать модели колоссальными по объему "знаний", но быстрыми в работе.
- Мультимодальность как стандарт. ИИ перестает быть просто "текстовым". Современные системы нативно понимают и генерируют видео, аудио и изображения. Пример из видео: модель может прочитать рукописные рецепты на разных языках, перевести их, сгенерировать картинки блюд и написать код готового веб-сайта.
- ИИ как помощник в науке и творчестве. Основное позитивное влияние ИИ ожидается в ускорении научных открытий (AlphaFold, материаловедение) и снижении порога входа в сложные навыки (программирование, дизайн).
- В развитии этой технологии существуют риски. Например, сгенерированный контент становится неотличимым от реального, и нужны технические и социальные механизмы защиты.
#AI #ML #Software #Engineering #Architecture #Infrastructure #Data
Telegram
Книжный куб
[1/2] How did we get to where we are in AI? (Рубрика #AI)
Пару недель назад Джефф Дин (Jeff Dean), Chief Data Science at Google, выступал в Stanford AI Club, где он приводил ретроспективу последних 15+ лет развития искусственного интеллекта. Он объяснял…
Пару недель назад Джефф Дин (Jeff Dean), Chief Data Science at Google, выступал в Stanford AI Club, где он приводил ретроспективу последних 15+ лет развития искусственного интеллекта. Он объяснял…
❤7🔥5⚡1
GigaChat 3 Ultra Preview - тяжёлый open source (Рубрика #AI)
Только сегодня дочитал статью Сбера про релиз GigaChat 3 Ultra, которая была опубликована еще в конце ноября на Хабре. Чтиво мне показлось интересным и заслуживающим изучения, но если кратко суммировать тезисы из статьи, то ребята выкатили новое поколение моделей с открытыми весами под MIT:
- GigaChat 3 Ultra Preview - флагманская MoE‑модель на ~702B параметров, из которых ~36B активны на шаге генерации. Это первая настолько большая, изначально русскоязычная open‑source‑модель такого масштаба, совместимая со стандартным OSS‑инструментарием (HuggingFace, vLLM, sglang и т.п.).
- GigaChat 3 Lightning - компактная ~10B‑MoE для локального запуска и быстрого дообучения.
Дальше внутри статьи ребята рассказали про отдельные моменты
- Данные
Pretrain‑корпус раздули до ~14 трлн токенов: 10 языков (от китайского до узбекского и казахского), много кода/математики и ~5,5 трлн синтетики (Q&A, reverse‑prompts, задачи по олимпиадному программированию и т.д.).
- Инфра для данных
Развернули собственный open‑source YT‑кластер: 10 000 ядер и >5 ПБ хранения, чтобы сэмплирование и токенизация выполнялись за минуты вместо дней. Вчера я был на конфе Giga Salut, где интересно пообщался с ребятами как раз на эту тему (с чего переезжали на YT и какие результаты были)
- Архитектура
Ultra - это огромная MoE‑модель, вдохновлённая DeepSeek V3: 256 экспертов, MTP (multi‑token prediction), MLA (multi‑head latent attention), полный стек, совместимый с существующими OSS‑тулзами для инференса и обучения.
- Обучение
Учить MoE модель было сложно: дикий объём коммуникаций между GPU, дисбаланс нагрузки по экспертам, инфраструктурный ад с чекпойнтами на 10+ ТБ и бенчмарками, требующими десятки GPU.
- Alignment
Общий конвейер выглядел так
-- Stage 1.5 - крупный диалоговый pretrain, чтобы модель нормально общалась;
-- RL по цепочкам рассуждений (Chain‑of‑Thought RL);
-- SFT на вручную вылизанных датасетах.
При этом Ultra Preview пока без этапа CoT‑RL.
Также в модель добавили B2C‑фичи: интерпретатор Python‑кода, переработанный поиск (по сути, готовый RAG‑слой) и долговременная память о пользователе.
В чем прорыв этого релиза
- Масштаб. GigaChat Ultra - крупнейший на сегодня open‑source‑LLM‑проект в России и Европе и одна из топ‑5 открытых моделей мира по числу параметров
- Обучение с нуля. Это не дообучение западной модели: веса и датасет - свои, модель нативно учится на русском и актуальных данных, без наследования чужих ограничений
- Совместимость со стеком OSS. Архитектура максимально приближена к DeepSeek V3, так что дообучение и деплой можно строить на уже существующих тулзах (vLLM, sglang, Megatron, Torchtitan и т.п.).
- Качество. Ultra уверенно обгоняет GigaChat 2 Max по ключевым бенчмаркам (MERA, MMLU‑Pro, GSM8K, HumanEval+ и др.) и лидирует в русскоязычных тестах. Но пока нет результатов большого количества других бенчей
В общем, ребята из Сбера - молодцы. Приятно видеть открытые релизы и техрепорты про технологии российских компаний.
#AI #ML #Software #Engineering #Architecture #Infrastructure #Data
Только сегодня дочитал статью Сбера про релиз GigaChat 3 Ultra, которая была опубликована еще в конце ноября на Хабре. Чтиво мне показлось интересным и заслуживающим изучения, но если кратко суммировать тезисы из статьи, то ребята выкатили новое поколение моделей с открытыми весами под MIT:
- GigaChat 3 Ultra Preview - флагманская MoE‑модель на ~702B параметров, из которых ~36B активны на шаге генерации. Это первая настолько большая, изначально русскоязычная open‑source‑модель такого масштаба, совместимая со стандартным OSS‑инструментарием (HuggingFace, vLLM, sglang и т.п.).
- GigaChat 3 Lightning - компактная ~10B‑MoE для локального запуска и быстрого дообучения.
Дальше внутри статьи ребята рассказали про отдельные моменты
- Данные
Pretrain‑корпус раздули до ~14 трлн токенов: 10 языков (от китайского до узбекского и казахского), много кода/математики и ~5,5 трлн синтетики (Q&A, reverse‑prompts, задачи по олимпиадному программированию и т.д.).
- Инфра для данных
Развернули собственный open‑source YT‑кластер: 10 000 ядер и >5 ПБ хранения, чтобы сэмплирование и токенизация выполнялись за минуты вместо дней. Вчера я был на конфе Giga Salut, где интересно пообщался с ребятами как раз на эту тему (с чего переезжали на YT и какие результаты были)
- Архитектура
Ultra - это огромная MoE‑модель, вдохновлённая DeepSeek V3: 256 экспертов, MTP (multi‑token prediction), MLA (multi‑head latent attention), полный стек, совместимый с существующими OSS‑тулзами для инференса и обучения.
- Обучение
Учить MoE модель было сложно: дикий объём коммуникаций между GPU, дисбаланс нагрузки по экспертам, инфраструктурный ад с чекпойнтами на 10+ ТБ и бенчмарками, требующими десятки GPU.
- Alignment
Общий конвейер выглядел так
-- Stage 1.5 - крупный диалоговый pretrain, чтобы модель нормально общалась;
-- RL по цепочкам рассуждений (Chain‑of‑Thought RL);
-- SFT на вручную вылизанных датасетах.
При этом Ultra Preview пока без этапа CoT‑RL.
Также в модель добавили B2C‑фичи: интерпретатор Python‑кода, переработанный поиск (по сути, готовый RAG‑слой) и долговременная память о пользователе.
В чем прорыв этого релиза
- Масштаб. GigaChat Ultra - крупнейший на сегодня open‑source‑LLM‑проект в России и Европе и одна из топ‑5 открытых моделей мира по числу параметров
- Обучение с нуля. Это не дообучение западной модели: веса и датасет - свои, модель нативно учится на русском и актуальных данных, без наследования чужих ограничений
- Совместимость со стеком OSS. Архитектура максимально приближена к DeepSeek V3, так что дообучение и деплой можно строить на уже существующих тулзах (vLLM, sglang, Megatron, Torchtitan и т.п.).
- Качество. Ultra уверенно обгоняет GigaChat 2 Max по ключевым бенчмаркам (MERA, MMLU‑Pro, GSM8K, HumanEval+ и др.) и лидирует в русскоязычных тестах. Но пока нет результатов большого количества других бенчей
В общем, ребята из Сбера - молодцы. Приятно видеть открытые релизы и техрепорты про технологии российских компаний.
#AI #ML #Software #Engineering #Architecture #Infrastructure #Data
Хабр
GigaChat 3 Ultra Preview — тяжёлый open source
Салют, Хабр! Последний год выдался насыщенным: выпуск линейки GigaChat 2, которая может вас слышать, смотреть видео и даже понимать мемы; добавление функции Reasoning в наш Web ( giga.chat ); первое...
🔥21❤6👍5
Опросы руководителей и связь с реальностью (Рубрика #AI)
При внимательном изучении отчета "Яков и партнеры" и Yandex я решил обратить внимание на источники информации, которых в основном три вида: опрос топ-менеджеров компаний, опрос представителей вендоров и опрос пользователй. При изучении результатов опроса руководителей компаний о том, как внедряются AI технологии мне вспомнился Ярослав Гашек и его бравый солдат Швейк. Конкретно при прочтении фактов вида
Мне вспомнился момент, где Ярослав Гашек показывает, что министры, генералы и высшие чины словно бы страдают коллективным помешательством, которое затем неизбежно передается всем нижестоящим. Информация сверху оформляется в приказы, распоряжения и пропаганду, а на нижних уровнях превращается в нелепые инициативы, строгие взыскания и нервную беготню младших офицеров и солдат. В обратную сторону снизу вверх идут уже не приказы, а доносы, искаженные слухи и статистика "успехов", подчищенная под ожидания начальства. Так создается иллюзия порядка и рациональности.
В этом плане я больше верю отчету "The GenAI Divide: State of AI in Business 2025" от MIT, где несмотря на глобальные инвестиции в размере $30–40 млрд, ~95% организаций не получили измеримой отдачи от проектов GenAI, а оставшиеся 5% смогли на этом заработать. Авторы объясняют это не качеством моделей или регулировании, а разными подходами к внедрению технологий. Подробнее про отчет от MIT я рассказывал здесь, а после выходных подробнее рассказу про отчет "Яков и партнеры" и Yandex.
#Humor #AI #Engineering #Management #Leadership #Economics
При внимательном изучении отчета "Яков и партнеры" и Yandex я решил обратить внимание на источники информации, которых в основном три вида: опрос топ-менеджеров компаний, опрос представителей вендоров и опрос пользователй. При изучении результатов опроса руководителей компаний о том, как внедряются AI технологии мне вспомнился Ярослав Гашек и его бравый солдат Швейк. Конкретно при прочтении фактов вида
Согласно опросу СТО, за два года генеративный ИИ вышел далеко за рамки точечных экспериментов: среднее количество функций, где запущены пилоты или полное внедрение, выросло с 2,4 в 2023 г. до 3,1 в 2025-м, а сама технология используется уже в 80% ключевых бизнес-функций
Мне вспомнился момент, где Ярослав Гашек показывает, что министры, генералы и высшие чины словно бы страдают коллективным помешательством, которое затем неизбежно передается всем нижестоящим. Информация сверху оформляется в приказы, распоряжения и пропаганду, а на нижних уровнях превращается в нелепые инициативы, строгие взыскания и нервную беготню младших офицеров и солдат. В обратную сторону снизу вверх идут уже не приказы, а доносы, искаженные слухи и статистика "успехов", подчищенная под ожидания начальства. Так создается иллюзия порядка и рациональности.
В этом плане я больше верю отчету "The GenAI Divide: State of AI in Business 2025" от MIT, где несмотря на глобальные инвестиции в размере $30–40 млрд, ~95% организаций не получили измеримой отдачи от проектов GenAI, а оставшиеся 5% смогли на этом заработать. Авторы объясняют это не качеством моделей или регулировании, а разными подходами к внедрению технологий. Подробнее про отчет от MIT я рассказывал здесь, а после выходных подробнее рассказу про отчет "Яков и партнеры" и Yandex.
#Humor #AI #Engineering #Management #Leadership #Economics
yakovpartners.ru
Яков и Партнёры - Внедрение ИИ может принести российской экономике до 13 трлн руб. к 2030 г.
Более 70% российских компаний уже интегрировали решения на базе генеративного ИИ хотя бы в одном бизнес-процессе своей организации
😁11❤10🔥7👍4
Звезда по имени Солнце (Рубрика #PopularScience)
Последние пару дней читал блестящую книгу астронома Сергея Язева "Вселенная. Путешествие во времени и пространстве". Это превосходный экскурс по истории человеческих представлений о космосе: от мифологических картин мира до современной космологии, теории Большого взрыва, чёрных дыр и квантовой физики. Мне особенно понравилось, что автор идет последовательно с самого начала времен до текущего момента, описывая как менялись наши знания о Вселенной, связывая эволюцию научных идей с развитием наблюдательной техники и реальными людьми‑учёными. Чувствуешь, что проходишь этот путь не за тысячелетия, а буквально за дни. И вот у меня осталась всего пара глав, чтобы закончить книгу, я выглянул в окошко своего кабинета и увидел наше зимнее Солнышко, а дальше вспомнились строчки из песни группы "Кино", которые отлично попали в настроение
Итого, как я дочитаю книгу Сергея Язева, то обязательно расскажу о ней подробно в этом канале.
#PopularScience #Physics #Music
Последние пару дней читал блестящую книгу астронома Сергея Язева "Вселенная. Путешествие во времени и пространстве". Это превосходный экскурс по истории человеческих представлений о космосе: от мифологических картин мира до современной космологии, теории Большого взрыва, чёрных дыр и квантовой физики. Мне особенно понравилось, что автор идет последовательно с самого начала времен до текущего момента, описывая как менялись наши знания о Вселенной, связывая эволюцию научных идей с развитием наблюдательной техники и реальными людьми‑учёными. Чувствуешь, что проходишь этот путь не за тысячелетия, а буквально за дни. И вот у меня осталась всего пара глав, чтобы закончить книгу, я выглянул в окошко своего кабинета и увидел наше зимнее Солнышко, а дальше вспомнились строчки из песни группы "Кино", которые отлично попали в настроение
Белый снег, серый лёд
На растрескавшейся земле
Одеялом лоскутным на ней
Город в дорожной петле
А над городом плывут облака
Закрывая небесный свет
А над городом жёлтый дым
Городу две тысячи лет
Прожитых под светом
Звезды по имени Солнце
Итого, как я дочитаю книгу Сергея Язева, то обязательно расскажу о ней подробно в этом канале.
#PopularScience #Physics #Music
1🔥19❤8⚡2
Moving away from Agile. What's next? (Рубрика #Processes)
Посмотрел претенциозный доклад ребят из McKinsey с недавноей конфы AI Engineer, в котором они раскрывали несколько ключевых мыслей
- Текущие операционные модели (Agile based) плохо раскрывают потенциал AI‑инструментов
- "AI‑native" команды отличаются другими workflow, ролями и метриками
- Переход от Agile - это в первую очередь организационные и культурные изменения, а не использование инструментов
Тезисы, что поддерживают их мысли основаны на следующем
- У нас есть разрыв между индивидуальным бустом инженеров и эффектом на компанию: отдельные разработчики получают ускорение "дни → минуты", а в среднем по компании видят лишь 5–15% прироста продуктивности, потому что остальной процесс остался старым.
- AI создаёт новые бутылочные горлышки: распределение задач между людьми и агентами, ручной код‑ревью при лавине сгенерированного кода, ускоренное накопление техдолга и сложности.
- Старый agile‑сетап (8–10 человек, двухнедельные спринты, story‑driven dev, раздельные роли frontend, backend, qa, ...) оптимизирован под "чисто человеческую" разработку и плохо сочетается с использованием агентов
Интересно, что название самого доклада выглядит как байтинг - авторы на самом деле не предлагают "выкинуть agile", скорее они предлагат уйти от конкретной реализации со спринтами по две недели, командами формата "two-pizza teams" и остальными ритуалами. На замену этому они предлагают "AI native подход": короткие циклы, более мелкие команды, spec‑driven development, ну и изменение роли product manager и инженеров.
Вообще забавно смотреть на выступления консультантов про разработку - не уверен, что они сами когда-то писали код, поэтому они базируют свой helicopter view анализ на куче различных исследований и кейс study. Ну и мыслят они не с уровня команды, а с уровня портфеля из сотен команд: много говорят про change management, измерения, роль обучения, перестройку орг‑структуры. Это консалтинговый взгляд, но он полезен, если говорить про крупные корпорации:)
Если говорить подробнее про изменения, то они предлагают
- Перейти от квартального планирования к continuous planning
- Перейти от story‑driven к spec‑driven разработке - PM/lead сначала "выбивают" нормальную спецификацию вместе с агентом, а уже потом команда/агенты пилят код, чтобы сократить рефакторы и перегенерации.
- Перейти к командам по 3-5 человек, где участники больше напоминают fullstack инженеров, а также оркестрируют агентов и отвечают за части архитектуры, а не только за свой слой
- Перейти к продактам, что сами начинают прототипировать с coding agent, а не только писать длинные PRD (product requirement definitions)
Авторы говорят и про метрики для измерения эффекта, предлагая многоуровневую систему
- Инвестиции в инструменты, обучение, коучинг
- Adoption, velocity, capacity, MTTR по критичным багам, безопасность и качество кода
- Бизнес‑результаты: time‑to‑revenue, cost-benefit analysis, возможность реинвестировать в greenfield/brownfield.
В общем, консультанты предлагают поменять весь процесс, а не просто навесить агентов и copilot на старые agile‑процессы
#Engineering #AI #Metrics #Software #DevEx #Productivity #Management #Leadership
Посмотрел претенциозный доклад ребят из McKinsey с недавноей конфы AI Engineer, в котором они раскрывали несколько ключевых мыслей
- Текущие операционные модели (Agile based) плохо раскрывают потенциал AI‑инструментов
- "AI‑native" команды отличаются другими workflow, ролями и метриками
- Переход от Agile - это в первую очередь организационные и культурные изменения, а не использование инструментов
Тезисы, что поддерживают их мысли основаны на следующем
- У нас есть разрыв между индивидуальным бустом инженеров и эффектом на компанию: отдельные разработчики получают ускорение "дни → минуты", а в среднем по компании видят лишь 5–15% прироста продуктивности, потому что остальной процесс остался старым.
- AI создаёт новые бутылочные горлышки: распределение задач между людьми и агентами, ручной код‑ревью при лавине сгенерированного кода, ускоренное накопление техдолга и сложности.
- Старый agile‑сетап (8–10 человек, двухнедельные спринты, story‑driven dev, раздельные роли frontend, backend, qa, ...) оптимизирован под "чисто человеческую" разработку и плохо сочетается с использованием агентов
Интересно, что название самого доклада выглядит как байтинг - авторы на самом деле не предлагают "выкинуть agile", скорее они предлагат уйти от конкретной реализации со спринтами по две недели, командами формата "two-pizza teams" и остальными ритуалами. На замену этому они предлагают "AI native подход": короткие циклы, более мелкие команды, spec‑driven development, ну и изменение роли product manager и инженеров.
Вообще забавно смотреть на выступления консультантов про разработку - не уверен, что они сами когда-то писали код, поэтому они базируют свой helicopter view анализ на куче различных исследований и кейс study. Ну и мыслят они не с уровня команды, а с уровня портфеля из сотен команд: много говорят про change management, измерения, роль обучения, перестройку орг‑структуры. Это консалтинговый взгляд, но он полезен, если говорить про крупные корпорации:)
Если говорить подробнее про изменения, то они предлагают
- Перейти от квартального планирования к continuous planning
- Перейти от story‑driven к spec‑driven разработке - PM/lead сначала "выбивают" нормальную спецификацию вместе с агентом, а уже потом команда/агенты пилят код, чтобы сократить рефакторы и перегенерации.
- Перейти к командам по 3-5 человек, где участники больше напоминают fullstack инженеров, а также оркестрируют агентов и отвечают за части архитектуры, а не только за свой слой
- Перейти к продактам, что сами начинают прототипировать с coding agent, а не только писать длинные PRD (product requirement definitions)
Авторы говорят и про метрики для измерения эффекта, предлагая многоуровневую систему
- Инвестиции в инструменты, обучение, коучинг
- Adoption, velocity, capacity, MTTR по критичным багам, безопасность и качество кода
- Бизнес‑результаты: time‑to‑revenue, cost-benefit analysis, возможность реинвестировать в greenfield/brownfield.
В общем, консультанты предлагают поменять весь процесс, а не просто навесить агентов и copilot на старые agile‑процессы
#Engineering #AI #Metrics #Software #DevEx #Productivity #Management #Leadership
YouTube
Moving away from Agile: What's Next – Martin Harrysson & Natasha Maniar, McKinsey & Company
Most enterprises are not capturing much value from AI in software dev to date (at least relative to the potential). The reason is that most are adding AI tools to their dev teams without changing the people and operating model aspects (i.e., limited changes…
❤12🔥8👍5
У меня даже собака тянется к знаниям:) Ей нравится мое кресло в библиотеке
1❤44👍23🔥12🥰4👎1
Can you prove AI ROI in Software Engineering? (Рубрика #AI)
Буквально недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) выступил на конференции AI Engineer Code Summit 2025 в Нью-Йорке с таким провокационным докладом:) По-факту, это тизер результатов двухлетнего исследования влияния AI-инструментов на продуктивность разработчиков, охватывающего 120 000+ разработчиков в 600+ компаниях (такой охват как минимум внушает доверие ). Кстати, предыдущее выступление Егора "Does AI Actually Boost Developer Productivity?" я уже разбирал и часть тезисов полностью повторяются, а точнее вопросы вида
1. Почему существующие оценки продуктивности ненадёжны?
2. Как выглядела методология ребят из Stanford?
3. Главные численные выводы исследования
Но в этом докладе есть и новенькие результаты
1. Медианный прирост продуктивности составляет ~10%, но разброс между лидерами и отстающими постоянно увеличивается.
2. Качество использования AI важнее объёма. Корреляция между количеством потраченных токенов и ростом продуктивности слабая (R² = 0.20). Более того, наблюдается эффект "долины смерти" на уровне 10 млн токенов на инженера в месяц - команды, использующие такой объём, показывают результаты хуже, чем те, кто использует меньше.
3. Чистота кодовой базы критична для AI. Индекс "чистоты окружения" (Environment Cleanliness Index), учитывающий тесты, типы, документацию, модульность и качество кода, показывает корреляцию R² = 0.40 с приростом продуктивности от AI. Чистый код усиливает эффект от AI, а технический долг его нивелирует.
4. AI ускоряет энтропию кодовой базы. Бесконтрольное использование AI ускоряет накопление технического долга, что сдвигает кодовую базу в зону, где AI менее эффективен. Требуется активное управление качеством кода для сохранения преимуществ.
5. Доступ к AI ≠ эффективное использование. В кейсе с двумя бизнес-юнитами одной компании при равном доступе к инструментам использование было сильно разное. Важно измерять не только факт использования, но и как инженеры применяют AI.
Ну и собственно автор предлагает свою методологию для измерения ROI из двух частей
1. Измерение использования
Access-based (кто получил доступ) vs usage-based (телеметрия API). Usage-based - золотой стандарт, позволяющий ретроспективный анализ через git-историю.
2. Измерение инженерных результатов
- Primary metric: Engineering Output - ML-модель, реплицирующая оценку панели из 10-15 независимых экспертов по сложности, времени реализации и поддерживаемости
- Guardrail metrics: Rework & Refactoring, Code Quality & Risk, People & DevOps - метрики, которые нужно держать на здоровом уровне, но не максимизировать
Забавно, что автор категорически против использования PR counts, lines of code и даже DORA как основных метрик продуктивности.
Ну и если анализировать подход автора, то он содержит сильные и слабые стороны
(+) Исследовательская методология выглядит солидно. ML-модель, реплицирующая экспертные оценки, проверенная на корреляцию с реальными панельными данными - это правильный подход к измерению сложных качественных аспектов кода.
(+) Понимание системных эффектов. Концепция управления энтропией кодовой базы, связь между чистотой кода и эффективностью AI, понимание, что инженеры должны знать, когда не использовать AI
(+) Критика DORA как primary metric обоснована. DORA - это индикаторы процесса, а не результата. Их максимизация может вредить (вспомним Goodhart's Law)
(+)AI Practices Benchmark с уровнями зрелости (от личного использования до агентной оркестрации) показывает понимание эволюции практик.
(-) Background автора не в чистой разработке - у него отсутствует опыт и образование как инженера
(-) ML-модель как чёрный ящик. Хотя утверждается, что модель коррелирует с экспертными оценками, детали методологии, датасет для обучения, метрики качества модели не раскрыты в докладе
(-) Environment Cleanliness Index экспериментальный. Как именно взвешиваются компоненты индекса? Как он валидирован кроме корреляции с продуктивностью?
#Engineering #AI #Metrics #Software #DevEx #Productivity
Буквально недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) выступил на конференции AI Engineer Code Summit 2025 в Нью-Йорке с таким провокационным докладом:) По-факту, это тизер результатов двухлетнего исследования влияния AI-инструментов на продуктивность разработчиков, охватывающего 120 000+ разработчиков в 600+ компаниях (
1. Почему существующие оценки продуктивности ненадёжны?
2. Как выглядела методология ребят из Stanford?
3. Главные численные выводы исследования
Но в этом докладе есть и новенькие результаты
1. Медианный прирост продуктивности составляет ~10%, но разброс между лидерами и отстающими постоянно увеличивается.
2. Качество использования AI важнее объёма. Корреляция между количеством потраченных токенов и ростом продуктивности слабая (R² = 0.20). Более того, наблюдается эффект "долины смерти" на уровне 10 млн токенов на инженера в месяц - команды, использующие такой объём, показывают результаты хуже, чем те, кто использует меньше.
3. Чистота кодовой базы критична для AI. Индекс "чистоты окружения" (Environment Cleanliness Index), учитывающий тесты, типы, документацию, модульность и качество кода, показывает корреляцию R² = 0.40 с приростом продуктивности от AI. Чистый код усиливает эффект от AI, а технический долг его нивелирует.
4. AI ускоряет энтропию кодовой базы. Бесконтрольное использование AI ускоряет накопление технического долга, что сдвигает кодовую базу в зону, где AI менее эффективен. Требуется активное управление качеством кода для сохранения преимуществ.
5. Доступ к AI ≠ эффективное использование. В кейсе с двумя бизнес-юнитами одной компании при равном доступе к инструментам использование было сильно разное. Важно измерять не только факт использования, но и как инженеры применяют AI.
Ну и собственно автор предлагает свою методологию для измерения ROI из двух частей
1. Измерение использования
Access-based (кто получил доступ) vs usage-based (телеметрия API). Usage-based - золотой стандарт, позволяющий ретроспективный анализ через git-историю.
2. Измерение инженерных результатов
- Primary metric: Engineering Output - ML-модель, реплицирующая оценку панели из 10-15 независимых экспертов по сложности, времени реализации и поддерживаемости
- Guardrail metrics: Rework & Refactoring, Code Quality & Risk, People & DevOps - метрики, которые нужно держать на здоровом уровне, но не максимизировать
Забавно, что автор категорически против использования PR counts, lines of code и даже DORA как основных метрик продуктивности.
Ну и если анализировать подход автора, то он содержит сильные и слабые стороны
(+) Исследовательская методология выглядит солидно. ML-модель, реплицирующая экспертные оценки, проверенная на корреляцию с реальными панельными данными - это правильный подход к измерению сложных качественных аспектов кода.
(+) Понимание системных эффектов. Концепция управления энтропией кодовой базы, связь между чистотой кода и эффективностью AI, понимание, что инженеры должны знать, когда не использовать AI
(+) Критика DORA как primary metric обоснована. DORA - это индикаторы процесса, а не результата. Их максимизация может вредить (вспомним Goodhart's Law)
(+)AI Practices Benchmark с уровнями зрелости (от личного использования до агентной оркестрации) показывает понимание эволюции практик.
(-) Background автора не в чистой разработке - у него отсутствует опыт и образование как инженера
(-) ML-модель как чёрный ящик. Хотя утверждается, что модель коррелирует с экспертными оценками, детали методологии, датасет для обучения, метрики качества модели не раскрыты в докладе
(-) Environment Cleanliness Index экспериментальный. Как именно взвешиваются компоненты индекса? Как он валидирован кроме корреляции с продуктивностью?
#Engineering #AI #Metrics #Software #DevEx #Productivity
YouTube
Can you prove AI ROI in Software Eng? (Stanford 120k Devs Study) – Yegor Denisov-Blanch, Stanford
You’re investing millions in AI for software engineering. Can you prove it’s paying off?
Benchmarks show models can write code, but in enterprise deployments ROI is hard to measure, easy to bias, and often distorted by activity metrics (PR counts, DORA)…
Benchmarks show models can write code, but in enterprise deployments ROI is hard to measure, easy to bias, and often distorted by activity metrics (PR counts, DORA)…
🔥10❤5👍4
Code of Leadership #58 - Interview with Vladimir Malov about tech management and vibe coding (Рубрика #Management)
Интервью с Владимиром Маловым, исполнительным директором финтех‑сервиса рассрочек +7 pay, который прошёл путь от iOS‑разработчика до СТО/СРО в e‑grocery и собрал крупные ИТ‑команды. В этом интервью мы обсудили с Владимиром его карьеру в общем, а также поговорили про подход к вайб-кодингу новых продуктов, а также Владиимир показал мини-демку создания приложения в Lovable. Итого, за полтора часа мы успели обсудить следующие темы
- Введение и знакомство с гостем
- Ранние карьера и "зигзагообразный" путь: Санлайт, Перекрёсток, Лента, Утконос и ценность горизонтальных переходов
- Детство, семья и образование
- Университет и первые уроки ответственности
- Вход в мобайл и первая продуктовая практика в Санлайт.
- Ритейл и онлайн‑доставка: Санлайт, Перекрёсток и Лента
- Переход из разработки в продакт‑менеджмент
- Роли техдира, предпринимательство и риск
- Бигтехи, ожидания и "синдром троечника"
- Любовь к созданию продуктов и появление новых инструментов
- Вайб‑кодинг в продакшене и демо
- Будущее вайб‑кодинга и агентский режим
- Личное, здоровье, фокус и нетворкинг
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
P.S.
Владимир ведет интересный канал https://t.me/malov_tech/
#Career #Engineering #Software #Management #Leadership
Интервью с Владимиром Маловым, исполнительным директором финтех‑сервиса рассрочек +7 pay, который прошёл путь от iOS‑разработчика до СТО/СРО в e‑grocery и собрал крупные ИТ‑команды. В этом интервью мы обсудили с Владимиром его карьеру в общем, а также поговорили про подход к вайб-кодингу новых продуктов, а также Владиимир показал мини-демку создания приложения в Lovable. Итого, за полтора часа мы успели обсудить следующие темы
- Введение и знакомство с гостем
- Ранние карьера и "зигзагообразный" путь: Санлайт, Перекрёсток, Лента, Утконос и ценность горизонтальных переходов
- Детство, семья и образование
- Университет и первые уроки ответственности
- Вход в мобайл и первая продуктовая практика в Санлайт.
- Ритейл и онлайн‑доставка: Санлайт, Перекрёсток и Лента
- Переход из разработки в продакт‑менеджмент
- Роли техдира, предпринимательство и риск
- Бигтехи, ожидания и "синдром троечника"
- Любовь к созданию продуктов и появление новых инструментов
- Вайб‑кодинг в продакшене и демо
- Будущее вайб‑кодинга и агентский режим
- Личное, здоровье, фокус и нетворкинг
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
P.S.
Владимир ведет интересный канал https://t.me/malov_tech/
#Career #Engineering #Software #Management #Leadership
YouTube
Code of Leadership #58 - Interview with Vladimir Malov about tech management and vibe coding
Интервью с Владимиром Маловым, исполнительным директором финтех‑сервиса рассрочек +7 pay, который прошёл путь от iOS‑разработчика до СТО/СРО в e‑grocery и собрал крупные ИТ‑команды. В этом интервью мы обсудили с Владимиром его карьеру в общем, а также поговорили…
👍4🔥3❤2
[1/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)
Посмотрел интервью Келси Хайтауэра с командой JetBrains про состояние индустрии в 2025 году. Помню как лет 7 назад изучал Kubernetes по его репозиторию Kubernetes The Hard Way, который был не прост, но помог мне сдать лабы для получения шилдика CKA (Certified Kubernetes Administrator) первым в компании. Это было в те времена, когда мы с моим коллегой Стасом (гостем из первого выпуска подкаста Code of Leadership), Андреем (гостем 43 выпуска Code ...) и Антоном (гостем 17 выпуска Code ..) продумывали как будем переезжать в Kubernetes с виртуалок:)
Но если возвращаться к Келси, то он уже завершил активную карьеру в Google и теперь может философски размышлять про devops и не только. Я выделил 5 тем, что были интересны мне в этом обсуждении
1️⃣ DevOps: Эволюция или провал?
Келси критически оценивает то, во что превратился DevOps во многих компаниях.
- "Футболка вместо навыков": Многие компании просто переименовали системных администраторов в DevOps-инженеров, не изменив суть работы. "О, теперь я DevOps-инженер, дадут ли мне за это футболку?" — иронизирует Келси.
- Правильная имплементация: DevOps был задуман как "чертеж" (blueprint), предполагающий расширение компетенций. Сисадмины должны были научиться программировать, а разработчики - понимать, как работает операционная система (например, тюнить JVM под ядро Linux).
- Проблема опыта: Келси упоминает людей, у которых "20 лет опыта, состоящих из одного и того же года, повторенного 20 раз" (20 years of one-year experience). Это те, кто просто чинит серверы, не пытаясь автоматизировать или изменить подход.
- Platform Engineering: Это не что-то принципиально новое, а эволюция DevOps. Это переход от "я починю сервер, когда он сломается" к созданию продукта (платформы) для внутренних клиентов.
2️⃣ Kubernetes и «скучные» технологии
- Kubernetes - это скучно (и это хорошо): Для stateless (веб) приложений Kubernetes стал скучным еще 6-7 лет назад. Келси сравнивает инфраструктуру с полетом на самолете: "Самолеты интересны только тогда, когда они делают не то, что мы ожидаем. Если при посадке люди хлопают - значит, что-то пошло не так. Мы хотим просто выйти из самолета и не думать о полете".
- Инфраструктура не должна вызывать восторг: Если ваша инфраструктура вызывает у вас сильные эмоции, значит, вы боретесь с поломками или трением. Восторг должен вызывать продукт, который вы строите поверх неё.
- Будущее Kubernetes: Если через 20–30 лет мы всё еще будем обсуждать Kubernetes, это будет провалом индустрии. Мы должны придумать что-то лучшее. Kubernetes должен стать просто деталью реализации (как BIOS или машинный код), скрытой под более удобными абстракциями.
3️⃣ API, Silos (Колодцы) и взаимодействие команд
Келси делает контринтуитивное заявление: "Мне нравятся silos (изолированные команды)", но при наличии четкого API.
- Аналогия с авиабилетом: Когда вы летите в другую страну, вы не идете в кабину пилота обсуждать маршрут. Вы покупаете билет. Билет - это API (контракт). Вы садитесь в кресло, засыпаете и просыпаетесь в другом месте.
- API как контракт: Платформенная команда и разработчики не должны сидеть рядом и постоянно разговаривать. Они должны взаимодействовать через четкий контракт (API): "Мне нужно столько-то памяти, такой-то регион, такая-то версия".
- Когда нужно общение: Разговаривать нужно только тогда, когда вы хотите изменить API или добавить новую фичу в платформу. Для рутинного деплоя общение - это лишние накладные расходы.
Забавно, что примерно эти же моменты про взаимодествие команд мы разбирали со Стасом Халупом в первом выпуске Code of Leadership.
Оставшиеся темы про AI и важность soft skills обсудим в продолжении разбора этого крутого интервью.
#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes
Посмотрел интервью Келси Хайтауэра с командой JetBrains про состояние индустрии в 2025 году. Помню как лет 7 назад изучал Kubernetes по его репозиторию Kubernetes The Hard Way, который был не прост, но помог мне сдать лабы для получения шилдика CKA (Certified Kubernetes Administrator) первым в компании. Это было в те времена, когда мы с моим коллегой Стасом (гостем из первого выпуска подкаста Code of Leadership), Андреем (гостем 43 выпуска Code ...) и Антоном (гостем 17 выпуска Code ..) продумывали как будем переезжать в Kubernetes с виртуалок:)
Но если возвращаться к Келси, то он уже завершил активную карьеру в Google и теперь может философски размышлять про devops и не только. Я выделил 5 тем, что были интересны мне в этом обсуждении
1️⃣ DevOps: Эволюция или провал?
Келси критически оценивает то, во что превратился DevOps во многих компаниях.
- "Футболка вместо навыков": Многие компании просто переименовали системных администраторов в DevOps-инженеров, не изменив суть работы. "О, теперь я DevOps-инженер, дадут ли мне за это футболку?" — иронизирует Келси.
- Правильная имплементация: DevOps был задуман как "чертеж" (blueprint), предполагающий расширение компетенций. Сисадмины должны были научиться программировать, а разработчики - понимать, как работает операционная система (например, тюнить JVM под ядро Linux).
- Проблема опыта: Келси упоминает людей, у которых "20 лет опыта, состоящих из одного и того же года, повторенного 20 раз" (20 years of one-year experience). Это те, кто просто чинит серверы, не пытаясь автоматизировать или изменить подход.
- Platform Engineering: Это не что-то принципиально новое, а эволюция DevOps. Это переход от "я починю сервер, когда он сломается" к созданию продукта (платформы) для внутренних клиентов.
2️⃣ Kubernetes и «скучные» технологии
- Kubernetes - это скучно (и это хорошо): Для stateless (веб) приложений Kubernetes стал скучным еще 6-7 лет назад. Келси сравнивает инфраструктуру с полетом на самолете: "Самолеты интересны только тогда, когда они делают не то, что мы ожидаем. Если при посадке люди хлопают - значит, что-то пошло не так. Мы хотим просто выйти из самолета и не думать о полете".
- Инфраструктура не должна вызывать восторг: Если ваша инфраструктура вызывает у вас сильные эмоции, значит, вы боретесь с поломками или трением. Восторг должен вызывать продукт, который вы строите поверх неё.
- Будущее Kubernetes: Если через 20–30 лет мы всё еще будем обсуждать Kubernetes, это будет провалом индустрии. Мы должны придумать что-то лучшее. Kubernetes должен стать просто деталью реализации (как BIOS или машинный код), скрытой под более удобными абстракциями.
3️⃣ API, Silos (Колодцы) и взаимодействие команд
Келси делает контринтуитивное заявление: "Мне нравятся silos (изолированные команды)", но при наличии четкого API.
- Аналогия с авиабилетом: Когда вы летите в другую страну, вы не идете в кабину пилота обсуждать маршрут. Вы покупаете билет. Билет - это API (контракт). Вы садитесь в кресло, засыпаете и просыпаетесь в другом месте.
- API как контракт: Платформенная команда и разработчики не должны сидеть рядом и постоянно разговаривать. Они должны взаимодействовать через четкий контракт (API): "Мне нужно столько-то памяти, такой-то регион, такая-то версия".
- Когда нужно общение: Разговаривать нужно только тогда, когда вы хотите изменить API или добавить новую фичу в платформу. Для рутинного деплоя общение - это лишние накладные расходы.
Забавно, что примерно эти же моменты про взаимодествие команд мы разбирали со Стасом Халупом в первом выпуске Code of Leadership.
Оставшиеся темы про AI и важность soft skills обсудим в продолжении разбора этого крутого интервью.
#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes
YouTube
AI, DevOps, and Kubernetes: Kelsey Hightower on What’s Next
DevOps: Failed or Evolved?
Kelsey Hightower – one of the most influential figures in DevOps and cloud-native engineering – breaks down the future of DevOps, the rise of platform engineering, AI-assisted ops, and the growing complexity of modern tooling.…
Kelsey Hightower – one of the most influential figures in DevOps and cloud-native engineering – breaks down the future of DevOps, the rise of platform engineering, AI-assisted ops, and the growing complexity of modern tooling.…
❤10👍6🔥5
[2/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)
В продолжении разбора интервью Келси нужно упомянуть темы AI и важности soft skills
4️⃣ Искусственный интеллект (AI)
Хайтауэр скептичен к хайпу, но видит фундаментальную пользу.
- AI как новый DSL: Келси смеется над "Prompt Engineering", когда люди чекинят в git 500 markdown-файлов с промптами и версионируют их. По сути, мы изобрели еще один, очень нестабильный язык программирования.
- Недетерминированность: Всю карьеру инженеры боролись за предсказуемость (тесты, идемпотентность), а теперь мы внедряем AI, который по своей природе вероятностный ("Зачем гадать, если можно знать наверняка?").
- Главная польза AI: Он заставил вендоров и разработчиков наконец-то написать нормальные API и документацию, чтобы LLM могли с ними работать. То, что мы должны были сделать для людей (хорошие доки и интерфейсы), мы теперь делаем для роботов.
- Guardrails (Ограничения): В итоге все равно все сводится к созданию жестких рамок (guardrails), чтобы заставить AI выдавать предсказуемый, "скучный" результат.
5️⃣Развитие: Человек vs Инженер
В конце интервью фокус смещается на soft skills и личностный рост.
- Командный спорт: Келси сравнивает работу в IT с баскетболом или футболом, а не с легкой атлетикой. В беге ты побеждаешь или проигрываешь один. В IT, каким бы крутым инженером ты ни был, ты зависишь от команды.
- Эмпатия: Это не просто "быть милым". Это понимание того, что если разработчик боится деплоить в пятницу, проблема может быть не в его трусости, а в ненадежности платформы, которую вы построили.
- Профессионализм и «Ящик с инструментами»: Не будьте просто «коллекционером» инструментов. Профессионал регулярно перебирает свой ящик с инструментами (toolbox), чистит их и выбрасывает ненужные.
- Дисциплина важнее любопытства: В профессиональной среде нельзя тащить в продакшн Rust или новую технологию только потому, что вам "любопытно". Выбирайте инструменты, которые решают задачу бизнеса, а не тешают эго инженера.
#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes
В продолжении разбора интервью Келси нужно упомянуть темы AI и важности soft skills
4️⃣ Искусственный интеллект (AI)
Хайтауэр скептичен к хайпу, но видит фундаментальную пользу.
- AI как новый DSL: Келси смеется над "Prompt Engineering", когда люди чекинят в git 500 markdown-файлов с промптами и версионируют их. По сути, мы изобрели еще один, очень нестабильный язык программирования.
- Недетерминированность: Всю карьеру инженеры боролись за предсказуемость (тесты, идемпотентность), а теперь мы внедряем AI, который по своей природе вероятностный ("Зачем гадать, если можно знать наверняка?").
- Главная польза AI: Он заставил вендоров и разработчиков наконец-то написать нормальные API и документацию, чтобы LLM могли с ними работать. То, что мы должны были сделать для людей (хорошие доки и интерфейсы), мы теперь делаем для роботов.
- Guardrails (Ограничения): В итоге все равно все сводится к созданию жестких рамок (guardrails), чтобы заставить AI выдавать предсказуемый, "скучный" результат.
5️⃣Развитие: Человек vs Инженер
В конце интервью фокус смещается на soft skills и личностный рост.
- Командный спорт: Келси сравнивает работу в IT с баскетболом или футболом, а не с легкой атлетикой. В беге ты побеждаешь или проигрываешь один. В IT, каким бы крутым инженером ты ни был, ты зависишь от команды.
- Эмпатия: Это не просто "быть милым". Это понимание того, что если разработчик боится деплоить в пятницу, проблема может быть не в его трусости, а в ненадежности платформы, которую вы построили.
- Профессионализм и «Ящик с инструментами»: Не будьте просто «коллекционером» инструментов. Профессионал регулярно перебирает свой ящик с инструментами (toolbox), чистит их и выбрасывает ненужные.
- Дисциплина важнее любопытства: В профессиональной среде нельзя тащить в продакшн Rust или новую технологию только потому, что вам "любопытно". Выбирайте инструменты, которые решают задачу бизнеса, а не тешают эго инженера.
#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes
Telegram
Книжный куб
[1/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)
Посмотрел интервью Келси Хайтауэра с командой JetBrains про состояние индустрии в 2025 году. Помню как лет 7 назад изучал Kubernetes по его репозиторию Kubernetes…
Посмотрел интервью Келси Хайтауэра с командой JetBrains про состояние индустрии в 2025 году. Помню как лет 7 назад изучал Kubernetes по его репозиторию Kubernetes…
🔥10❤6👍4✍2
Вселенная. Путешествие во времени (Рубрика #PopularScience)
Прочитал с большим удовольствием эту книгу Сергея Арктуровича Язева, российского астронома, что много лет руководит Астрономической обсерваторией Иркутского государственного университета и связан с Институтом солнечно‑земной физики СО РАН. Интересно, что Сергей - потомственный астроном и практически живет в своей предметной области, умеет ее популяризировать и держать дисциплину научного метода.
Сама книга вышла в 2020 году в издательстве Питер и была задумана как путешествие по разным научным парадигмам восприятия космоса от древнего мира к текущим концепциям:) Автор умеет показывать как менялись взгляды человечества, и отдельно проговаривает, почему базовым физическим законам имеет смысл доверять (смысл примерно как в поговорке "доверяй, но проверяй").
Сама книга обладает рядом плюсов
- Онасостоит из двух частей и развивается от простого к сложному
- Через весь текст проходит таймлайн, связывающий события мировой истории и астрономические открытия
- В книге превосходные иллюстрации Евгения Муретова, которые отлично поддерживают повествование
Вообще, история и усложнение концепций напоминает мне progressive jpeg, когда детали картины отрисовываются постепенно.
Часть 1: от Вселенной древнего мира к Вселенной, управляемой физикой
Первая часть - это путь от концепций мира древних и философских конструкций к миру, где начинают работать:
- Наблюдение и измерение (вместо авторитетов и мифов)
- Математика как язык модели
- Универсальные законы (одни и те же правила для яблока, Луны и планет -это ключевой перелом мышления).
Книга буквально ставит вехи от главы «Вселенная Древнего мира» к главе "Вселенная, управляемая физикой", причем если проводить параллели, то
- Древняя картина мира - это “монолит”, где объяснение часто неотделимо от культуры и веры
- Научная картина выглядит модульно, состоя из цикла: измерения → гипотеза → модель → предсказания → проверка → рефакторинг модели
Отдельно круто, что Язев не просто перечисляет открытия, а показывает почему без научного метода тысячелетиями нельзя было достоверно узнать устройство мира - то есть объясняет сам механизм прогресса, а не только результаты.
Часть 2: от относительной Вселенной к разгоняющейся - и дальше, к открытым вопросам
Вторая часть начинается с качественного скачка сложности: мы больше не пытаемся "подкрутить старую модель", а меняем базовые предпосылки, что похоже на смену платформы (на эту тему можно почитать книгу Томаса Куна "Структура научных революций"). Начинается все с главы "Вселенная относительная", а дальше история проходит через ключевые “релизы” современной космологии - расширение, горячее начало (Большой взрыв), инфляция - и выходит к главе "Вселенная разгоняющаяся", а финализируется все Вселенной открытых вопросов. Здесь особенно хорошо ощущается логика
- Относительность меняет то, что считаем “базовым API” пространства‑времени
- Расширение переводит космологию из статической картинки в динамическую систему (с параметрами, которые нужно измерять, а не “объявлять”)
- Инфляция - попытка закрыть конкретные баги стандартной модели (плоскостность/горизонт и т. п.) с помощью гипотезы, которая должна быть совместима с наблюдениями
- Ускоренное расширение (“разгоняющаяся Вселенная”) добавляет в модель компоненту, природа которой понятна не до конца - и это честно выводит читателя к границе знания
В итоге, книга мне безусловно понравилась - автор интересно, последовательно и понятно объясняет сложные концепции. Я бы хотел уметь в таком стиле рассказывать их своим детям:)
#PopularScience #Physics #Science #Math
Прочитал с большим удовольствием эту книгу Сергея Арктуровича Язева, российского астронома, что много лет руководит Астрономической обсерваторией Иркутского государственного университета и связан с Институтом солнечно‑земной физики СО РАН. Интересно, что Сергей - потомственный астроном и практически живет в своей предметной области, умеет ее популяризировать и держать дисциплину научного метода.
Сама книга вышла в 2020 году в издательстве Питер и была задумана как путешествие по разным научным парадигмам восприятия космоса от древнего мира к текущим концепциям:) Автор умеет показывать как менялись взгляды человечества, и отдельно проговаривает, почему базовым физическим законам имеет смысл доверять (смысл примерно как в поговорке "доверяй, но проверяй").
Сама книга обладает рядом плюсов
- Онасостоит из двух частей и развивается от простого к сложному
- Через весь текст проходит таймлайн, связывающий события мировой истории и астрономические открытия
- В книге превосходные иллюстрации Евгения Муретова, которые отлично поддерживают повествование
Вообще, история и усложнение концепций напоминает мне progressive jpeg, когда детали картины отрисовываются постепенно.
Часть 1: от Вселенной древнего мира к Вселенной, управляемой физикой
Первая часть - это путь от концепций мира древних и философских конструкций к миру, где начинают работать:
- Наблюдение и измерение (вместо авторитетов и мифов)
- Математика как язык модели
- Универсальные законы (одни и те же правила для яблока, Луны и планет -это ключевой перелом мышления).
Книга буквально ставит вехи от главы «Вселенная Древнего мира» к главе "Вселенная, управляемая физикой", причем если проводить параллели, то
- Древняя картина мира - это “монолит”, где объяснение часто неотделимо от культуры и веры
- Научная картина выглядит модульно, состоя из цикла: измерения → гипотеза → модель → предсказания → проверка → рефакторинг модели
Отдельно круто, что Язев не просто перечисляет открытия, а показывает почему без научного метода тысячелетиями нельзя было достоверно узнать устройство мира - то есть объясняет сам механизм прогресса, а не только результаты.
Часть 2: от относительной Вселенной к разгоняющейся - и дальше, к открытым вопросам
Вторая часть начинается с качественного скачка сложности: мы больше не пытаемся "подкрутить старую модель", а меняем базовые предпосылки, что похоже на смену платформы (на эту тему можно почитать книгу Томаса Куна "Структура научных революций"). Начинается все с главы "Вселенная относительная", а дальше история проходит через ключевые “релизы” современной космологии - расширение, горячее начало (Большой взрыв), инфляция - и выходит к главе "Вселенная разгоняющаяся", а финализируется все Вселенной открытых вопросов. Здесь особенно хорошо ощущается логика
- Относительность меняет то, что считаем “базовым API” пространства‑времени
- Расширение переводит космологию из статической картинки в динамическую систему (с параметрами, которые нужно измерять, а не “объявлять”)
- Инфляция - попытка закрыть конкретные баги стандартной модели (плоскостность/горизонт и т. п.) с помощью гипотезы, которая должна быть совместима с наблюдениями
- Ускоренное расширение (“разгоняющаяся Вселенная”) добавляет в модель компоненту, природа которой понятна не до конца - и это честно выводит читателя к границе знания
В итоге, книга мне безусловно понравилась - автор интересно, последовательно и понятно объясняет сложные концепции. Я бы хотел уметь в таком стиле рассказывать их своим детям:)
#PopularScience #Physics #Science #Math
❤18🔥7👍5