The third golden age of software engineering - thanks to AI, with Grady Booch (Рубрика #AI)
Интересное интервью Гради Буча, создателя UML и Chief Scientist for Software Engineering в IBM, в подкасте The Pragmatic Engineer. Гради и Gergely Orosz, автор подкаста, обсуждают как меняется ремесло инженера, когда уровень абстракции снова поднимается (как было во времена появления ассемблера, а потом высокоуровневых языков программирования).
Интересно, что в этом интервью Гради Буч заочно дискутирует с Дарио Амодеи, что в прошлом марте публично говорил, что мы можем быть в 6–12 месяцах от ситуации, когда модели будут делать end‑to‑end то, что делают software engineers, а инженеры перейдут в режим "модель пишет - я редактирую. Буч на это реагирует очень жестко и по сути: это взгляд на программирование как на набор строк кода, а не на инженерную дисциплину:)
В общем, основные тезисы интервью такие
1️⃣ Мы уже в "третьем золотом веке" - и он про системы, а не про код
Буч раскладывает историю на 3 золотых века:
1) 1940-1970 - алгоритмы и автоматизация бизнеса
2) 1970-2000 - объектные абстракции
3) 2000-сейчас - системы, где мы собираем продукты из библиотек, платформ, API, облаков - и теперь поверх всего этого появляется ИИ‑слой.
И по мнению Гради AI - это не конец профессии, а очередной скачок абстракции
2️⃣ Экзистенциальная паника - повторяющийся цикл
Когда появились компиляторы и языки высокого уровня, тоже казалось, что всё, программисты не нужны. Но индустрия не умерла - она пересобралась и пошла выше по стеку. Одна из центральных мыслей Буча: ваши инструменты меняются, но ваши проблемы - нет
3️⃣ ИИ силён там, где паттерны уже установились
Текущие инструменты типа Cursor/Claude хороши там, где задачи повторяются: типовые CRUD, стандартные интеграции, привычные веб‑паттерны. Буч прямо отмечает, что они обучены на проблемах, которые мы видели снова и снова. А вот граница интересного - в системах, контексте, компромиссах, ответственности.
4️⃣ Software engineering - это не набор кода, а баланс сил и решений
Инженерия - это баланс технических ограничений, человеческих факторов и этики, а код - лишь один из инструментов. А отсюда у нас простой вывод - ИИ может ускорить производство артефактов, но не заменить принятие решений под ограничениями.
5️⃣ Автоматизация ударит по delivery pipeline (и это нормально)
Буч отдельно отмечает, что пайплайн поставки (всё вокруг сборки/доставки/рутины) - это низко висящий фрукт для автоматизации. И людям в этих ролях может понадобиться дообучение
6️⃣ Чем выше абстракция - тем важнее фундамент
Парадоксально, но факт: когда код писать стало легче, больше ценится глубокая модель мира. Буч рекомендует усиливать фундамент и мышление системами
Кажется, что инженерам теперь качать нужно следующие навыки
- System design и distributed systems, а эта тема неплохо описана на сайте system-design.space
- Умение работать с ограничениями: стоимость, сроки, риски, легаси, безопасность, регуляторика, команда - эта тема хорошо описана там же + скоро появится новый сайт для технических лидеров в том же стиле, что я сделал system-design.space
- Навык “review & governance: проверять, тестировать, ставить ограничения, ловить неочевидные баги, которые ИИ легко генерит наряду с работающим кодом
- Доменные знания: бизнес‑контекст, который теперь ценится еще больше:)
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems #History
Интересное интервью Гради Буча, создателя UML и Chief Scientist for Software Engineering в IBM, в подкасте The Pragmatic Engineer. Гради и Gergely Orosz, автор подкаста, обсуждают как меняется ремесло инженера, когда уровень абстракции снова поднимается (как было во времена появления ассемблера, а потом высокоуровневых языков программирования).
Интересно, что в этом интервью Гради Буч заочно дискутирует с Дарио Амодеи, что в прошлом марте публично говорил, что мы можем быть в 6–12 месяцах от ситуации, когда модели будут делать end‑to‑end то, что делают software engineers, а инженеры перейдут в режим "модель пишет - я редактирую. Буч на это реагирует очень жестко и по сути: это взгляд на программирование как на набор строк кода, а не на инженерную дисциплину:)
В общем, основные тезисы интервью такие
1️⃣ Мы уже в "третьем золотом веке" - и он про системы, а не про код
Буч раскладывает историю на 3 золотых века:
1) 1940-1970 - алгоритмы и автоматизация бизнеса
2) 1970-2000 - объектные абстракции
3) 2000-сейчас - системы, где мы собираем продукты из библиотек, платформ, API, облаков - и теперь поверх всего этого появляется ИИ‑слой.
И по мнению Гради AI - это не конец профессии, а очередной скачок абстракции
2️⃣ Экзистенциальная паника - повторяющийся цикл
Когда появились компиляторы и языки высокого уровня, тоже казалось, что всё, программисты не нужны. Но индустрия не умерла - она пересобралась и пошла выше по стеку. Одна из центральных мыслей Буча: ваши инструменты меняются, но ваши проблемы - нет
3️⃣ ИИ силён там, где паттерны уже установились
Текущие инструменты типа Cursor/Claude хороши там, где задачи повторяются: типовые CRUD, стандартные интеграции, привычные веб‑паттерны. Буч прямо отмечает, что они обучены на проблемах, которые мы видели снова и снова. А вот граница интересного - в системах, контексте, компромиссах, ответственности.
4️⃣ Software engineering - это не набор кода, а баланс сил и решений
Инженерия - это баланс технических ограничений, человеческих факторов и этики, а код - лишь один из инструментов. А отсюда у нас простой вывод - ИИ может ускорить производство артефактов, но не заменить принятие решений под ограничениями.
5️⃣ Автоматизация ударит по delivery pipeline (и это нормально)
Буч отдельно отмечает, что пайплайн поставки (всё вокруг сборки/доставки/рутины) - это низко висящий фрукт для автоматизации. И людям в этих ролях может понадобиться дообучение
6️⃣ Чем выше абстракция - тем важнее фундамент
Парадоксально, но факт: когда код писать стало легче, больше ценится глубокая модель мира. Буч рекомендует усиливать фундамент и мышление системами
Кажется, что инженерам теперь качать нужно следующие навыки
- System design и distributed systems, а эта тема неплохо описана на сайте system-design.space
- Умение работать с ограничениями: стоимость, сроки, риски, легаси, безопасность, регуляторика, команда - эта тема хорошо описана там же + скоро появится новый сайт для технических лидеров в том же стиле, что я сделал system-design.space
- Навык “review & governance: проверять, тестировать, ставить ограничения, ловить неочевидные баги, которые ИИ легко генерит наряду с работающим кодом
- Доменные знания: бизнес‑контекст, который теперь ценится еще больше:)
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems #History
YouTube
The third golden age of software engineering – thanks to AI, with Grady Booch
Every few decades, software engineering is declared “dead” or on the verge of being automated away. We’ve heard versions of this story before. But what if it’s just the start of a new “golden age” of a different type of software engineering, like it has been…
1🔥34❤9👍7
Как я пишу посты в канал (Рубрика #SelfDevelopment)
Меня периодически спрашивают как я пишу так много постов и есть ли там помощь от LLM. И вот я решил написать про свой подход к потреблению знаний и ведению канала.
Если кратко, то пайплан выглядит примерно следующим образом
- Discovery: у меня есть набор телеграм каналов, обученная система рекомендаций от Google (в браузере и Youtube), есть подписки, что делают отбивки мне на почту. Мои интересы сфокусированы вокруг разработки, менеджмента, наук (в основном точных), искусств (здесь скорее визуальных, включая фотографию)
- Digest: каждый день я смотрю пару видео, читаю несколько статей + несколько глав из книг
- Discuss: дальше я обсуждаю изученное с LLM моделями - раньше у меня часто была проблема, что обсудить материал было не с кем, а теперь даже если я читаю зубодробительный whitepaper, то у меня есть собеседник
- Describe: дальше мой диалог с LLM я прощу суммаризировать SOTA модель в формат поста
- eDit: дальше я делаю ревью того, что получилось, куда входит фактчекинг + проверка того, что в коротком посте подсвечены именно те инсайты, что возникли у меня после просмотра видео / прочтения статьи и дальше дискуссии с LLM
- Deliver: дальше остается запланировать публикацию поста на нужный день и нужное время с учетом моего настроения и тем, которые я люблю группировать в блоки
В итоге, получается 6D процесс, который позволяет мне глубоко погружаться в интересующие меня темы, а также делиться возникшими мыслями с аудиторией канала.
#Engineering #AI #Productivity #Writing
Меня периодически спрашивают как я пишу так много постов и есть ли там помощь от LLM. И вот я решил написать про свой подход к потреблению знаний и ведению канала.
Если кратко, то пайплан выглядит примерно следующим образом
- Discovery: у меня есть набор телеграм каналов, обученная система рекомендаций от Google (в браузере и Youtube), есть подписки, что делают отбивки мне на почту. Мои интересы сфокусированы вокруг разработки, менеджмента, наук (в основном точных), искусств (здесь скорее визуальных, включая фотографию)
- Digest: каждый день я смотрю пару видео, читаю несколько статей + несколько глав из книг
- Discuss: дальше я обсуждаю изученное с LLM моделями - раньше у меня часто была проблема, что обсудить материал было не с кем, а теперь даже если я читаю зубодробительный whitepaper, то у меня есть собеседник
- Describe: дальше мой диалог с LLM я прощу суммаризировать SOTA модель в формат поста
- eDit: дальше я делаю ревью того, что получилось, куда входит фактчекинг + проверка того, что в коротком посте подсвечены именно те инсайты, что возникли у меня после просмотра видео / прочтения статьи и дальше дискуссии с LLM
- Deliver: дальше остается запланировать публикацию поста на нужный день и нужное время с учетом моего настроения и тем, которые я люблю группировать в блоки
В итоге, получается 6D процесс, который позволяет мне глубоко погружаться в интересующие меня темы, а также делиться возникшими мыслями с аудиторией канала.
#Engineering #AI #Productivity #Writing
1🔥77👍32❤19🤝1
IntelliJ IDEA — The IDE That Changed Java Forever | DOCUMENTARY (Рубрика #Engineering)
Посмотрел эту документалку про IntelliJ IDEA, что вышла 5 марта 2026. Это захватывающая история о том, как небольшая команда стартовала создала продукт, который переопределил ожидания от dev tools. В кадре находятся как сотрудники компании JetBrains, так и представители индустрии которые делятся своими воспоминаниями о том, как это было.
JetBrains росла органически, без внешних инвестиций, и с самого начала строила не просто редактор, а "интеллектуальный" инструмент для разработчика - забавно, что в конце фильма обсуждается роль искусственного интеллекта в разработке софта и будущего IDE, а сотрудники JetBrains говорят, что редактор даже в названии своем сразу содержал часть про интеллект:) Но если начать сначала, то когда-то IntelliJ шла от рефакторинга и понимания структуры кода, а не от красивой оболочки. Это важно: они сделали ставку не на "еще один IDE", а на то, чтобы машина реально понимала программу глубже.
Другая интересная мысль - это то, что ребята показали как developer tools могут быть платформой, а не только продуктом. В 2009 году JetBrains открыла Community Edition и прямо писала, что убирает главный барьер для более широкого использования - цену, сохраняя при этом коммерческий Ultimate. Причем Community Edition и IntelliJ Platform стали базой не только для IDEA, но и для других инструментов JetBrains. А дальше цепочка уже известна: Android Studio официально построена на IntelliJ IDEA, а Kotlin, запущенный JetBrains в 2011 году и рано открытый в open source, со временем стал частью очень большого сдвига в JVM и Android-мире.
Следующая мысль крутится вокруг качества продукта и общей любви потребителей к нему. В фильме видно, что dog fooding в JetBrains был с самого начала и это был не маректинг. Ребята честно рассказывают о том, как их продукты часто рождались из внутренних потребностей, а сами команды ежедневно работают в собственных инструментах. Плюс у них есть культура 20%-проектов, хакатонов и Labs для выращивания новых идей. Это очень узнаваемый паттерн: когда разработчики сами страдают от своих UX-решений, качество обратной связи резко растет.
Дургой инетерсный момент связан с подходом к ведению бизнеса. Доверие пользователей для JetBrains постулируется важнее "правильной бизнес-модели на бумаге". Это проявилось в 2015 году, когда JetBrains переходили на подписочную модель, что вызвало сильную негативную реакцию. Компания потом публично признала, что не учла важные группы пользователей и плохо объяснила изменения, после чего быстро добавила perpetual fallback license и continuity discounts. Для меня это один из самых сильных эпизодов всей истории: хороший продукт не дает иммунитета от ошибок, но прозрачная коррекция курса помогает доверие вернуть. Не часто видишь похожий подход к тому, чтобы не только декларировать важность доверия пользователей, но и оправдывать его.
Ну и последняя мысль связана с современным трендом на AI4SDLC. Cейчас JetBrains продвигает AI как продолжение IDE: Next Edit Suggestions умеют использовать нативные IDE-действия вроде Rename refactoring, а Junie позиционируется как coding agent прямо внутри IDE. То есть ребята хотят стать центром нового процесса, где генерация соединяется с навигацией, рефакторингом, инспекциями и проверкой изменений. Правда, про это в фильме не говорится, но это видно по анонсам новинок в их продуктах:)
В итоге, руководителям можно забрать тезисы про
- Важность инвестиций в DevEx и крутые инструменты как бустеры эффективности разработки
- Dogfooding как бустер качества продуктов
- Open core как варианта развития коммерческого продукта в связке с open source
- Важность уметь не только декларировать ценности, но и следовать им даже во времена кризисов
- Понимание, что нельзя почивать на лаврах и надо уметь ловить волну (в этом случае AI в разработке)
P.S.
Summary есть и на system-design.space.
#Engineering #Software #Management #Leadership #Startup #Architecture #Documentary #AI
Посмотрел эту документалку про IntelliJ IDEA, что вышла 5 марта 2026. Это захватывающая история о том, как небольшая команда стартовала создала продукт, который переопределил ожидания от dev tools. В кадре находятся как сотрудники компании JetBrains, так и представители индустрии которые делятся своими воспоминаниями о том, как это было.
JetBrains росла органически, без внешних инвестиций, и с самого начала строила не просто редактор, а "интеллектуальный" инструмент для разработчика - забавно, что в конце фильма обсуждается роль искусственного интеллекта в разработке софта и будущего IDE, а сотрудники JetBrains говорят, что редактор даже в названии своем сразу содержал часть про интеллект:) Но если начать сначала, то когда-то IntelliJ шла от рефакторинга и понимания структуры кода, а не от красивой оболочки. Это важно: они сделали ставку не на "еще один IDE", а на то, чтобы машина реально понимала программу глубже.
Другая интересная мысль - это то, что ребята показали как developer tools могут быть платформой, а не только продуктом. В 2009 году JetBrains открыла Community Edition и прямо писала, что убирает главный барьер для более широкого использования - цену, сохраняя при этом коммерческий Ultimate. Причем Community Edition и IntelliJ Platform стали базой не только для IDEA, но и для других инструментов JetBrains. А дальше цепочка уже известна: Android Studio официально построена на IntelliJ IDEA, а Kotlin, запущенный JetBrains в 2011 году и рано открытый в open source, со временем стал частью очень большого сдвига в JVM и Android-мире.
Следующая мысль крутится вокруг качества продукта и общей любви потребителей к нему. В фильме видно, что dog fooding в JetBrains был с самого начала и это был не маректинг. Ребята честно рассказывают о том, как их продукты часто рождались из внутренних потребностей, а сами команды ежедневно работают в собственных инструментах. Плюс у них есть культура 20%-проектов, хакатонов и Labs для выращивания новых идей. Это очень узнаваемый паттерн: когда разработчики сами страдают от своих UX-решений, качество обратной связи резко растет.
Дургой инетерсный момент связан с подходом к ведению бизнеса. Доверие пользователей для JetBrains постулируется важнее "правильной бизнес-модели на бумаге". Это проявилось в 2015 году, когда JetBrains переходили на подписочную модель, что вызвало сильную негативную реакцию. Компания потом публично признала, что не учла важные группы пользователей и плохо объяснила изменения, после чего быстро добавила perpetual fallback license и continuity discounts. Для меня это один из самых сильных эпизодов всей истории: хороший продукт не дает иммунитета от ошибок, но прозрачная коррекция курса помогает доверие вернуть. Не часто видишь похожий подход к тому, чтобы не только декларировать важность доверия пользователей, но и оправдывать его.
Ну и последняя мысль связана с современным трендом на AI4SDLC. Cейчас JetBrains продвигает AI как продолжение IDE: Next Edit Suggestions умеют использовать нативные IDE-действия вроде Rename refactoring, а Junie позиционируется как coding agent прямо внутри IDE. То есть ребята хотят стать центром нового процесса, где генерация соединяется с навигацией, рефакторингом, инспекциями и проверкой изменений. Правда, про это в фильме не говорится, но это видно по анонсам новинок в их продуктах:)
В итоге, руководителям можно забрать тезисы про
- Важность инвестиций в DevEx и крутые инструменты как бустеры эффективности разработки
- Dogfooding как бустер качества продуктов
- Open core как варианта развития коммерческого продукта в связке с open source
- Важность уметь не только декларировать ценности, но и следовать им даже во времена кризисов
- Понимание, что нельзя почивать на лаврах и надо уметь ловить волну (в этом случае AI в разработке)
P.S.
Summary есть и на system-design.space.
#Engineering #Software #Management #Leadership #Startup #Architecture #Documentary #AI
YouTube
IntelliJ IDEA: The Documentary | An origin story
This is the IDE that changed everything.
This documentary traces the 25-year journey of one of the most beloved tools in software development. Through rare archival footage, intimate interviews, and behind-the-scenes moments, it explores how IntelliJ IDEA…
This documentary traces the 25-year journey of one of the most beloved tools in software development. Through rare archival footage, intimate interviews, and behind-the-scenes moments, it explores how IntelliJ IDEA…
❤11🔥10👍7👎1
DPE Summit 2025 от Gradle: почему это одна из самых полезных конференций про инженерную продуктивность (Рубрика #Productivity)
Мне нравится конференция DPE (Developer Productivity Engineering) от Gradle, которая проходит ежегодно в Сан-Франциско. Я часто рассказывал про доклады с саммита 2024 года (например, здесь: 1, 2, 3 и 4). Это событие целиком посвящено темам инженерной продуктивности и DX (developer experience) и в этом году оно прошло 23–24 сентября и организаторы уже выложили записи сессий (вот плейлист).
Почему мне кажется это событие важным и интересным - потому что DPE - это взгляд на продуктивность разработки не в лоб вида "сколько строк кода написал инженер", а скорее как на инженерную задачу:
- Как ускорить feedback loops и снизить cognitive loag
- Как улучшить CI/CD (ускорить, упростить, сделать дешевле)
- Как улучшить observability и упростить troubleshooting
Сами Gradle и dpe.org прямо описывают DPE как практику, которая повышает продуктивность и счастье разработчиков за счет инструментов, автоматизации и данных, а не только менеджерских метрик.
Самое ценное в этой конференции - это не абстрактный треп про "developer productivity", а кейсы от крупных инженерных организаций (где все равно может быть вода ). В программе были спикеры и доклады от Netflix, Google, Meta, Microsoft, Capital One, Uber, JetBrains, Okta, Lloyds Bank, Square, Databricks и других компаний. Они обсуждали среди прочего темы влияния GenAI на delivery, подходы к измерению эффекта AI на продуктивность, ускорение билдов, universal cache, merge queue, flaky tests, dependency updates, observability и DevEx-метрики.
Если обобщать, то основной вывод саммита в том, чтоGenAI ускоряет написание кода, но не гарантирует ускорение поставки работающего софта. В keynote Ханс Доктер прямо формулирует вопрос:
Логика вопроса простая: чем больше кода генерирует AI, тем сильнее нагрузка на build, test, compliance и deployment. Если pipeline не готов, то AI не ускоряет delivery, а просто переносит bottleneck вниз по цепочке. Отсюда фокус на smarter pipelines, observability, predictive test orchestration, caching и shift-left практиках.
Я посмотрел пока только несколько докладов, но уже видно, что не все доклады как keynote абстрактны. Например, Max Kanat-Alexander из Capital One в доклада "What Makes a Great Developer Experience?" рассказыват о трех вещах, что улучшают DevEx: быстрее итерации, больше focus time и меньше cognitive load. Netflix разбирает productivity в эпоху GenAI и отдельно показывает, как они подходят к build vs buy и внедрению AI coding agents. Google обсуждает, как реально улучшать влияние AI на продуктивность разработчиков. Uber показывает тему merge queue "at scale", а Square - как использовать idle time разработческих машин, чтобы ускорять workflows и улучшать cache hit rate.
Для технических руководителей ценность в том, что DPE Summit хорошо показывает, что продуктивность - это уже не HR-дискуссия и не спор про velocity, а полноценная область platform engineering и engineering management. Мерить надо не только output, но и flow, friction, надежность пайплайна, время обратной связи, стоимость изменений и реальный опыт разработчика. Ну и если посмотреть доклады, то можно перейти от поверхностных разговоров в стиле "AI заменит разработчиков" на обсуждение изменений всего контура delivery - от локальной среды и тестов до pipeline, observability и управляемых DevEx-инвестиций.
В следующие дни я буду много рассказывать про интересные доклады с этого саммита.
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership
Мне нравится конференция DPE (Developer Productivity Engineering) от Gradle, которая проходит ежегодно в Сан-Франциско. Я часто рассказывал про доклады с саммита 2024 года (например, здесь: 1, 2, 3 и 4). Это событие целиком посвящено темам инженерной продуктивности и DX (developer experience) и в этом году оно прошло 23–24 сентября и организаторы уже выложили записи сессий (вот плейлист).
Почему мне кажется это событие важным и интересным - потому что DPE - это взгляд на продуктивность разработки не в лоб вида "сколько строк кода написал инженер", а скорее как на инженерную задачу:
- Как ускорить feedback loops и снизить cognitive loag
- Как улучшить CI/CD (ускорить, упростить, сделать дешевле)
- Как улучшить observability и упростить troubleshooting
Сами Gradle и dpe.org прямо описывают DPE как практику, которая повышает продуктивность и счастье разработчиков за счет инструментов, автоматизации и данных, а не только менеджерских метрик.
Самое ценное в этой конференции - это не абстрактный треп про "developer productivity", а кейсы от крупных инженерных организаций (
Если обобщать, то основной вывод саммита в том, чтоGenAI ускоряет написание кода, но не гарантирует ускорение поставки работающего софта. В keynote Ханс Доктер прямо формулирует вопрос:
You can write code faster. Can you deliver it faster?
Логика вопроса простая: чем больше кода генерирует AI, тем сильнее нагрузка на build, test, compliance и deployment. Если pipeline не готов, то AI не ускоряет delivery, а просто переносит bottleneck вниз по цепочке. Отсюда фокус на smarter pipelines, observability, predictive test orchestration, caching и shift-left практиках.
Я посмотрел пока только несколько докладов, но уже видно, что не все доклады как keynote абстрактны. Например, Max Kanat-Alexander из Capital One в доклада "What Makes a Great Developer Experience?" рассказыват о трех вещах, что улучшают DevEx: быстрее итерации, больше focus time и меньше cognitive load. Netflix разбирает productivity в эпоху GenAI и отдельно показывает, как они подходят к build vs buy и внедрению AI coding agents. Google обсуждает, как реально улучшать влияние AI на продуктивность разработчиков. Uber показывает тему merge queue "at scale", а Square - как использовать idle time разработческих машин, чтобы ускорять workflows и улучшать cache hit rate.
Для технических руководителей ценность в том, что DPE Summit хорошо показывает, что продуктивность - это уже не HR-дискуссия и не спор про velocity, а полноценная область platform engineering и engineering management. Мерить надо не только output, но и flow, friction, надежность пайплайна, время обратной связи, стоимость изменений и реальный опыт разработчика. Ну и если посмотреть доклады, то можно перейти от поверхностных разговоров в стиле "AI заменит разработчиков" на обсуждение изменений всего контура delivery - от локальной среды и тестов до pipeline, observability и управляемых DevEx-инвестиций.
В следующие дни я буду много рассказывать про интересные доклады с этого саммита.
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership
Developer Productivity Engineering Summit 2025 -
The Home of Developer Productivity Engineering (DPE)
Developer Productivity Engineering (DPE) uses tools and technologies to improve developer productivity and happiness. Join us to learn more.
❤15🔥11👍2🤝1
Чат "Архитектура, менеджмент и влияние AI на разработку"
У меня давно был чат для комментариев в этом канале, но я про него особо не рассказывал:)
Теперь я решил поменять подход и приглашаю вас в этот чат @ai4sdlc, где мы сможем обсудить вопросы проектирования, технического руководства и не только.
Ну и конечно там можно общаться про влияние AI на разработку, так как я теперь full-time занимаюсь этой темой на своей работе.
Я буду бывать в этом часте достаточно часто (как минимум, чтобы удалять ботов из него).
В общем, you are welcome - https://t.me/ai4sdlc
#Architecture #AI #Management
У меня давно был чат для комментариев в этом канале, но я про него особо не рассказывал:)
Теперь я решил поменять подход и приглашаю вас в этот чат @ai4sdlc, где мы сможем обсудить вопросы проектирования, технического руководства и не только.
Ну и конечно там можно общаться про влияние AI на разработку, так как я теперь full-time занимаюсь этой темой на своей работе.
Я буду бывать в этом часте достаточно часто (как минимум, чтобы удалять ботов из него).
В общем, you are welcome - https://t.me/ai4sdlc
#Architecture #AI #Management
🔥10❤6🆒3
You can write code faster. Can you deliver it faster? (Рубрика #Productivity)
Это открывающий keynote доклад с конференции DPE Summit 2025 (я уже про нее упоминал). Его рассказывает Hans Dockter, CEO Gradle Inc, который ассоциируется с темой build automation и delivery pipeline: он основал Gradle Build Tool, руководил крупными enterprise-сборками и давно работает на стыке tooling, DevEx и software delivery.
Главный тезис доклада вынесен в название - GenAI ускоряет написание кода, но это не означает ускорение доставки работающего софта, Автор отмечает, что если AI увеличивает объём изменений upstream, то downstream-система - build, test, compliance, deploy - начинает захлёбываться и это выглядит как звучит как предупреждение для слушаетелей. Hans объясняет эту проблему так
- AI делает код быстрее, чаще и в больших объёмах, но одновременно снижает глубину человеческого понимания
- Это провоцирует крупные и более рискованные батчи изменений
- Это ухудшает feedback loops и растёт число сбоев
- В итоге, между "быстро поэкспериментировать" и "надёжно доставить в production" возникает всё больше трения
Если говорить про инсайты выступления, то они такие
1️⃣ Фокусироваться надо не на output, а на outcome
Важен не рост объёма сгенерированного кода (LoC, lines of code), а рост количества рабочего софта, которое команда реально доводит до пользователей
2️⃣ Узкое место смещается из coding в delivery system
Если раньше многие команды оптимизировали IDE, code review и генерацию кода, то теперь конкурентное преимущество будет у тех, кто умеет ускорять pipeline throughput без потери качества и без взрывного роста стоимости CI (continious integrations). То есть выигрывает уже не тот, кто "быстрее пишет код", а тот, у кого архитектура пайплайна выдерживает AI-нагрузку.
3️⃣ GenAI-ready pipeline - это не просто больше железа
Автор рассказывает про конкретные классы решений, что надо улучшать: траблшутинг, интеллектуальная параллелизация запусков, предиктивное выполнение тестов, универсальное кеширование, автоматизация применения политик. В общем, закидать раннерами не получиться - придется перестраивать систему как умный конвейер с хорошей диагностикой и управлением риском
4️⃣ Observability и быстрый анализ ключевых причин становятся частью developer experience
Кажется, что мы идем в сторону того, что AI-кодинг может становиться для разработчика все более "чёрным ящиком", а поэтому важно усиливать не только тестирование, но и видимость сигналов: результаты тестов, статический анализ, группировку фейлов, coverage, диагностику причин падений.
Мне понравилась еще и метафора, что автор подобрал для выступления - он сравнивал скорость мутаций в организмах и появление рака со скоростью AI кодинга и мутациями GenAI моделей, которые приводят к галлюцинациям. В итоге, автор провел параллели между количеством клеток у слонов по сравнению с людьми и работой их механизмов коррекции и защиты от мутаций - если бы у слонов не было такой защиты и они имели похожие средства само-корректировки ДНК, то они бы жили на порядок меньше и умирали от рака. Параллель тут была с нашими CI/CD инструментами, которые должны быть крутыми, чтобы мы могли защищаться от недетерминистической природы GenAI моделей, которые теперь генерируют нам потоки кода:)
Если говорить про выводы, то мне кажется следует вынести следующие четыре вещи
1. Мерить надо не сколько кода написали, а как изменились lead time, failure rate, MTTR и time-to-feedback
2. DevEx теперь включает качество delivery loops, а не только удобство редактора и SDK
3. Платформенная команда становится ещё важнее: именно она делает AI adoption безопасным и экономически оправданным
4. Самая зрелая позиция для руководителя - не спорить "заменит ли AI инженеров", а перестроить систему так, чтобы рост output не разрушал outcome
В общем, AI тут скорее сделал все эти вещи еще более важными, так как они и раньше были на повестке многих компаний.
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership
Это открывающий keynote доклад с конференции DPE Summit 2025 (я уже про нее упоминал). Его рассказывает Hans Dockter, CEO Gradle Inc, который ассоциируется с темой build automation и delivery pipeline: он основал Gradle Build Tool, руководил крупными enterprise-сборками и давно работает на стыке tooling, DevEx и software delivery.
Главный тезис доклада вынесен в название - GenAI ускоряет написание кода, но это не означает ускорение доставки работающего софта, Автор отмечает, что если AI увеличивает объём изменений upstream, то downstream-система - build, test, compliance, deploy - начинает захлёбываться и это выглядит как звучит как предупреждение для слушаетелей. Hans объясняет эту проблему так
- AI делает код быстрее, чаще и в больших объёмах, но одновременно снижает глубину человеческого понимания
- Это провоцирует крупные и более рискованные батчи изменений
- Это ухудшает feedback loops и растёт число сбоев
- В итоге, между "быстро поэкспериментировать" и "надёжно доставить в production" возникает всё больше трения
Если говорить про инсайты выступления, то они такие
1️⃣ Фокусироваться надо не на output, а на outcome
Важен не рост объёма сгенерированного кода (LoC, lines of code), а рост количества рабочего софта, которое команда реально доводит до пользователей
2️⃣ Узкое место смещается из coding в delivery system
Если раньше многие команды оптимизировали IDE, code review и генерацию кода, то теперь конкурентное преимущество будет у тех, кто умеет ускорять pipeline throughput без потери качества и без взрывного роста стоимости CI (continious integrations). То есть выигрывает уже не тот, кто "быстрее пишет код", а тот, у кого архитектура пайплайна выдерживает AI-нагрузку.
3️⃣ GenAI-ready pipeline - это не просто больше железа
Автор рассказывает про конкретные классы решений, что надо улучшать: траблшутинг, интеллектуальная параллелизация запусков, предиктивное выполнение тестов, универсальное кеширование, автоматизация применения политик. В общем, закидать раннерами не получиться - придется перестраивать систему как умный конвейер с хорошей диагностикой и управлением риском
4️⃣ Observability и быстрый анализ ключевых причин становятся частью developer experience
Кажется, что мы идем в сторону того, что AI-кодинг может становиться для разработчика все более "чёрным ящиком", а поэтому важно усиливать не только тестирование, но и видимость сигналов: результаты тестов, статический анализ, группировку фейлов, coverage, диагностику причин падений.
Мне понравилась еще и метафора, что автор подобрал для выступления - он сравнивал скорость мутаций в организмах и появление рака со скоростью AI кодинга и мутациями GenAI моделей, которые приводят к галлюцинациям. В итоге, автор провел параллели между количеством клеток у слонов по сравнению с людьми и работой их механизмов коррекции и защиты от мутаций - если бы у слонов не было такой защиты и они имели похожие средства само-корректировки ДНК, то они бы жили на порядок меньше и умирали от рака. Параллель тут была с нашими CI/CD инструментами, которые должны быть крутыми, чтобы мы могли защищаться от недетерминистической природы GenAI моделей, которые теперь генерируют нам потоки кода:)
Если говорить про выводы, то мне кажется следует вынести следующие четыре вещи
1. Мерить надо не сколько кода написали, а как изменились lead time, failure rate, MTTR и time-to-feedback
2. DevEx теперь включает качество delivery loops, а не только удобство редактора и SDK
3. Платформенная команда становится ещё важнее: именно она делает AI adoption безопасным и экономически оправданным
4. Самая зрелая позиция для руководителя - не спорить "заменит ли AI инженеров", а перестроить систему так, чтобы рост output не разрушал outcome
В общем, AI тут скорее сделал все эти вещи еще более важными, так как они и раньше были на повестке многих компаний.
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership
YouTube
You can write code faster. Can you deliver it faster?
Presented by Hans Dockter (Gradle) at DPE Summit 2025, an event developed and hosted by Gradle.
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=write-code-faster-deliver…
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=write-code-faster-deliver…
👍15❤8🔥4
Как незаметно DORA метрик стало не четыре, а пять (Рубрика #Productivity)
Долгие году у DevOps Research & Assesment или попросту DORA было 4 метрики, на которых строилась кластеризация команд по разным уровням элитности. Эти метрики были про скорость поставки и стабильность
- Скорость поставки: deployment frequency и lead time for changes
- Стабильнсоть: MTTR / time to restore service и change fail rate
Подробнее эту историю можно прочитать в моем разборе книги "Accelerate")
С января 2026 года у DORA стало 5 software delivery performance metrics, которые на их сайте тоже разбиты на две категории
1️⃣ Throughput - пропускная способность системы
- Change lead time - время от коммита до успешного деплоя в прод
- Deployment frequency - как часто вы выкатываете изменения
- Failed deployment recovery time - как быстро вы восстанавливаетесь именно после неудачного деплоя
2️⃣ Instability
- Change fail rate - доля деплоев, требующих немедленного вмешательства
- Deployment rework rate - доля незапланированных деплоев, которые пришлось делать из-за прод-инцидента / дефекта
Возникает вопрос, а что именно изменилось по сравнению со старой моделью и зачем это было сделано?
Вообще, измений было два и оба они важные
1) Старый MTTR / time to restore service в 2023 был уточнен и переопределен как failed deployment recovery time. DORA прямо объясняет это тем, что старое определение смешивало проблемы, вызванные изменением в коде, и внешние инциденты вроде outage в датацентре. Новая формулировка лучше статистически "сцепляется" именно с delivery-метриками.
2) В 2024 DORA добавила новую пятую метрику - deployment rework rate. Их логика была такой: change fail rate хорошо ловит немедленные проблемы после релиза, но плохо отражает объем последующей незапланированной переделки. Поэтому DORA решила отдельно измерять rework как самостоятельную часть instability.
Если же говорить про использование метрик, то возникает вопрос: а теперь классификация будет идти по 5 метрикам?
И тут по сути ответ "да", но есть нюансы ... ребята из DORA отдельно подчеркивают, что число кластеров не фиксировано и не задается вручную. В FAQ они пишут, что кластеры у них emergent from the data: до 2018 обычно было 3, с 2018 по 2021 - 4, в 2022 снова 3, а в 2023 и 2024 - опять 4. То есть фиксированного "всегда 4 класса команд" больше воспринимать не стоит.
Если подумать, а что это значит для обычных технических руководителей (кто не упарывается по методолгии и метрикам )?
Кажется, что DORA стала лучше различать два разных вида проблем:
- Немедленный фейл после релиза → change fail rate
- Отложенная незапланированная переделка из-за продовых проблем → deployment rework rate
Это полезно, потому что команда может выглядеть "нормально" по rollback/hotfix сразу после релиза, но при этом системно тонуть в незапланированном rework через день-два. В старой 4-метричной модели это было видно хуже; в новой - видно лучше. Это и есть главное содержательное обновление модели.
Отдельно стоит сказать, что 5 метрик бывало в DORA и раньше, а именно в 2021/2022 годах, когда была операционная метрика reliability, но она была не про software delivery performance, а вот текущая великолепная пятерка - это уже именно delivery metrics.
P.S.
В чате @ai4sdlc вчера обсуждали метрики и было предложение просто использовать DORA. В итоге, я решил написать этот пост, чтобы показать, что даже DORA не просто так посчитать, а еще само понимание метрик дрифтит со временем:)
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership
Долгие году у DevOps Research & Assesment или попросту DORA было 4 метрики, на которых строилась кластеризация команд по разным уровням элитности. Эти метрики были про скорость поставки и стабильность
- Скорость поставки: deployment frequency и lead time for changes
- Стабильнсоть: MTTR / time to restore service и change fail rate
Подробнее эту историю можно прочитать в моем разборе книги "Accelerate")
С января 2026 года у DORA стало 5 software delivery performance metrics, которые на их сайте тоже разбиты на две категории
1️⃣ Throughput - пропускная способность системы
- Change lead time - время от коммита до успешного деплоя в прод
- Deployment frequency - как часто вы выкатываете изменения
- Failed deployment recovery time - как быстро вы восстанавливаетесь именно после неудачного деплоя
2️⃣ Instability
- Change fail rate - доля деплоев, требующих немедленного вмешательства
- Deployment rework rate - доля незапланированных деплоев, которые пришлось делать из-за прод-инцидента / дефекта
Возникает вопрос, а что именно изменилось по сравнению со старой моделью и зачем это было сделано?
Вообще, измений было два и оба они важные
1) Старый MTTR / time to restore service в 2023 был уточнен и переопределен как failed deployment recovery time. DORA прямо объясняет это тем, что старое определение смешивало проблемы, вызванные изменением в коде, и внешние инциденты вроде outage в датацентре. Новая формулировка лучше статистически "сцепляется" именно с delivery-метриками.
2) В 2024 DORA добавила новую пятую метрику - deployment rework rate. Их логика была такой: change fail rate хорошо ловит немедленные проблемы после релиза, но плохо отражает объем последующей незапланированной переделки. Поэтому DORA решила отдельно измерять rework как самостоятельную часть instability.
Если же говорить про использование метрик, то возникает вопрос: а теперь классификация будет идти по 5 метрикам?
И тут по сути ответ "да", но есть нюансы ... ребята из DORA отдельно подчеркивают, что число кластеров не фиксировано и не задается вручную. В FAQ они пишут, что кластеры у них emergent from the data: до 2018 обычно было 3, с 2018 по 2021 - 4, в 2022 снова 3, а в 2023 и 2024 - опять 4. То есть фиксированного "всегда 4 класса команд" больше воспринимать не стоит.
Если подумать, а что это значит для обычных технических руководителей (
Кажется, что DORA стала лучше различать два разных вида проблем:
- Немедленный фейл после релиза → change fail rate
- Отложенная незапланированная переделка из-за продовых проблем → deployment rework rate
Это полезно, потому что команда может выглядеть "нормально" по rollback/hotfix сразу после релиза, но при этом системно тонуть в незапланированном rework через день-два. В старой 4-метричной модели это было видно хуже; в новой - видно лучше. Это и есть главное содержательное обновление модели.
Отдельно стоит сказать, что 5 метрик бывало в DORA и раньше, а именно в 2021/2022 годах, когда была операционная метрика reliability, но она была не про software delivery performance, а вот текущая великолепная пятерка - это уже именно delivery metrics.
P.S.
В чате @ai4sdlc вчера обсуждали метрики и было предложение просто использовать DORA. В итоге, я решил написать этот пост, чтобы показать, что даже DORA не просто так посчитать, а еще само понимание метрик дрифтит со временем:)
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership
1❤10👍7🔥3
DORA AI Capabilities Model - Разбор отчета (Рубрика #Productivity)
Прочитал на выходных отчет про эту модель-компаньон отчета 2025 года, который называется "State of AI-assisted Software Development". Основная мысль "DORA AI Capabilities Model" в том, что AI сам по себе не гарантирует улучшения, но он усиливает уже существующую социотехническую систему - хорошие практики усиливает, плохие тоже. Модель выделяет 7 capabilities, которые повышают шанс, что AI даст заметный положительный эффект. Отдельно отмечу, что я уже рассказывал как собираются отчеты DORA, как анонсировали AI Capabilities и что было в DORA 2025 - State of AI-assisted Software Development
Но если возвращаться к новому отчету, то вот эта великолепная семерка capabilities ивратарь AI
1. Clear and communicated AI stance - у организации есть понятная и донесенная позиция по использованию AI: что разрешено, что ожидается, какие инструменты можно применять.
2. Healthy data ecosystems - внутренние данные качественные, доступные и не разрозненные.
3. AI-accessible internal data - AI-инструменты могут безопасно получать контекст из внутренних кодовых баз, wiki, систем и документов.
4. Strong version control practices - зрелые практики version control, включая частые коммиты и возможность rollback.
5. Working in small batches - маленькие изменения, маленькие релизы, короткий цикл обратной связи.
6. User-centric focus - команда держит в центре пользователя и пользовательскую ценность.
7. Quality internal platforms - качественная внутренняя платформа помогает масштабировать эффект AI на уровне организации.
Исследователи из DORA нашли следующие связи между этими семью capabilities и интересующими всех outcomes
1. Clear and communicated AI stance ~ individual effectiveness и organizational performance
2. Healthy data ecosystems ~ organizational performance
3. AI-accessible internal data ~ individual effectiveness и code quality
4. Strong version control practices ~ individual effectiveness и team performance
5. Working in small batches ~ product performance и снижении friction
6. User-centric focus ~ team performance, но без этого фокуса AI даже может ухудшать team performace (команда будет быстрее двигаться не туда )
7. Quality internal platforms ~ organizational performance
Отдельно надо отметить, что эти новые capabilities напрямую связаны с классической DORA Core Model - новые capabilities дополняют core модель
- Core Model - это более консервативное ядро DORA: capabilities, metrics и outcomes, которые многократно подтверждались в исследованиях за многие годы.
- AI Capabilities Model - это надстройка поверх Core, которая отвечает на другой вопрос: при каких условиях AI-assisted development реально улучшает результаты
DORA отдельно подчеркивает, что многие AI-capabilities - это те же самые базовые инженерные и организационные способности, которые и раньше были связаны с high performance.
Интересно отметить, что 7 факторов получилось не совсем из головы - по описанию DORA, процесс был таким:
- Сначала исследователи сформировали широкий список гипотез о capability, которые могут влиять на успех AI-assisted development, опираясь на 78 in-depth interviews, мнения domain experts и прошлые исследования DORA
- Затем через приоритизацию они отобрали 15 кандидатов в capabilities для включения в опрос
- Потом в количественном анализе они оставили те, по которым нашлось существенное evidence of interaction with AI use
В общем, в итоговую модель вошли те 7 capabilities, которые статистически усиливали эффект AI adoption на значимые outcomes
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership
Прочитал на выходных отчет про эту модель-компаньон отчета 2025 года, который называется "State of AI-assisted Software Development". Основная мысль "DORA AI Capabilities Model" в том, что AI сам по себе не гарантирует улучшения, но он усиливает уже существующую социотехническую систему - хорошие практики усиливает, плохие тоже. Модель выделяет 7 capabilities, которые повышают шанс, что AI даст заметный положительный эффект. Отдельно отмечу, что я уже рассказывал как собираются отчеты DORA, как анонсировали AI Capabilities и что было в DORA 2025 - State of AI-assisted Software Development
Но если возвращаться к новому отчету, то вот эта великолепная семерка capabilities и
1. Clear and communicated AI stance - у организации есть понятная и донесенная позиция по использованию AI: что разрешено, что ожидается, какие инструменты можно применять.
2. Healthy data ecosystems - внутренние данные качественные, доступные и не разрозненные.
3. AI-accessible internal data - AI-инструменты могут безопасно получать контекст из внутренних кодовых баз, wiki, систем и документов.
4. Strong version control practices - зрелые практики version control, включая частые коммиты и возможность rollback.
5. Working in small batches - маленькие изменения, маленькие релизы, короткий цикл обратной связи.
6. User-centric focus - команда держит в центре пользователя и пользовательскую ценность.
7. Quality internal platforms - качественная внутренняя платформа помогает масштабировать эффект AI на уровне организации.
Исследователи из DORA нашли следующие связи между этими семью capabilities и интересующими всех outcomes
1. Clear and communicated AI stance ~ individual effectiveness и organizational performance
2. Healthy data ecosystems ~ organizational performance
3. AI-accessible internal data ~ individual effectiveness и code quality
4. Strong version control practices ~ individual effectiveness и team performance
5. Working in small batches ~ product performance и снижении friction
6. User-centric focus ~ team performance, но без этого фокуса AI даже может ухудшать team performace (
7. Quality internal platforms ~ organizational performance
Отдельно надо отметить, что эти новые capabilities напрямую связаны с классической DORA Core Model - новые capabilities дополняют core модель
- Core Model - это более консервативное ядро DORA: capabilities, metrics и outcomes, которые многократно подтверждались в исследованиях за многие годы.
- AI Capabilities Model - это надстройка поверх Core, которая отвечает на другой вопрос: при каких условиях AI-assisted development реально улучшает результаты
DORA отдельно подчеркивает, что многие AI-capabilities - это те же самые базовые инженерные и организационные способности, которые и раньше были связаны с high performance.
Интересно отметить, что 7 факторов получилось не совсем из головы - по описанию DORA, процесс был таким:
- Сначала исследователи сформировали широкий список гипотез о capability, которые могут влиять на успех AI-assisted development, опираясь на 78 in-depth interviews, мнения domain experts и прошлые исследования DORA
- Затем через приоритизацию они отобрали 15 кандидатов в capabilities для включения в опрос
- Потом в количественном анализе они оставили те, по которым нашлось существенное evidence of interaction with AI use
В общем, в итоговую модель вошли те 7 capabilities, которые статистически усиливали эффект AI adoption на значимые outcomes
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership
❤9👍3🔥1
What Makes a Great Developer Experience? (Рубрика #Productivity)
Интересный доклад Макса Канат-Александра с DPE Summit 2025 (подробнее про саммит здесь). Макс рассказывает про трех китов хорошего опыта разработчиков
1. Cycle time - сколько времени проходит от идеи до работающего результата
2. Focus - сколько у разработчика непрерывного времени на работу без дёрганий
3. Cognitive load - сколько лишнего нужно держать в голове, чтобы сделать полезную задачу
Идея в том, что почти любую проблему инженерной продуктивности можно разложить по этим трём осям по мнению Макса. А он знает толк в DevEx, так как он занимался этим всю инженерную карьеру
- как главный архитектор Bugzilla
- работая над Code Health в Google
- отвечая за Developer Experience в LinkedIn
- а сейчас он Executive Distinguished Engineer в Capital One (банк чьей моделью бизнеса вдохновлялись при создании Тинькофф)
Поэтому мне взгляд Макса на productivity кажется не абстрактной теорией, а опытом полученным на практике.
Главная мысль доклада в том, что отличный developer experience - это не про красивый интерфейс внутреннего портала разработки. Это про системное снятие барьеров, которые замедляют инженера, выбивают его из фокуса и заставляют тратить мозг не на продукт, а на инфраструктурный шум. Макс по сути говорит: если улучшение не сокращает цикл, не защищает фокус и не снижает когнитивную нагрузку, то его ценность для DevEx сомнительна.
А теперь про инсайты
1️⃣ Скорость - это не мантра "работайте быстрее"
От призывов ускориться или поднажать появляется только стресс, а для реального ускорения надо ускорять внутренние циклы разработки (между внутренними этапами цикла), например можно сделать
- Быстрее ревью
- Меньше и понятнее PR
- Короче сборки
- Прозрачнее CI/CD
- Быстрее локальную обратную связь
Настоящая скорость рождается не из героизма, а из хорошо настроенной системы.
2️⃣ Фокус - это недооценённый актив
Каждое прерывание стоит дорого. Непонятная ошибка, внезапный статус-митинг, кривой tooling, шумные алерты - всё это рвёт контекст. А восстановление контекста часто занимает заметно больше времени, чем само прерывание. Интересна мысль про то, что developer productivity часто тонет не в больших проблемах, а в постоянной мелкой фрагментации внимания.
3️⃣ Когнитивная нагрузка - главный скрытый налог
Если для обычной продуктовой задачи инженеру нужно помнить особенности пяти пайплайнов, трёх систем мониторинга и семи способов доставки, то проблема не в инженере. Плохой DevEx часто выглядит именно так: разработчик пришёл делать бизнес-фичу, а вместо этого изучает внутренний зоопарк платформенных решений.
Из доклада можно извлечь очень практичные советы для технических руководителей
1) Оптимизируйте не лозунги, а путь работы
Смотрите не на абстрактную "производительность", а на конкретные бутылочные горлышки: сборка, ревью, тесты, деплой, ожидание доступа, диагностика падений.
2) Убирайте фазу угадывания
Если CI/CD падает с сообщением уровня "something went wrong", вы создаёте анти-DevEx. Хорошая система не просто сообщает о сбое, а помогает сразу понять причину и следующий шаг.
3) Берегите инженерный фокус как ограниченный ресурс
Линейных инженеров не стоит без необходимости тащить на статусные синки. Контекст-свитчинг - один из самых дорогих видов потерь в разработке.
4) Снижайте вариативность базовой платформы
Один стандартный CI, один понятный observability stack, единый способ запуска типовых сценариев - это не "ограничение свободы", а способ вернуть командам внимание к продукту.
5) Не путайте внутренний портал платформы с решением проблемы
Склеить 20 плохих процессов в один красивый UI - не значит улучшить DevEx. Иногда лучший интерфейс - это вообще отсутствие ручного шага.
P.S.
У Макса есть много интересных выступлений, например, про "Developer Experience in the Age of AI Coding Agents" я уже рассказывал
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Интересный доклад Макса Канат-Александра с DPE Summit 2025 (подробнее про саммит здесь). Макс рассказывает про трех китов хорошего опыта разработчиков
1. Cycle time - сколько времени проходит от идеи до работающего результата
2. Focus - сколько у разработчика непрерывного времени на работу без дёрганий
3. Cognitive load - сколько лишнего нужно держать в голове, чтобы сделать полезную задачу
Идея в том, что почти любую проблему инженерной продуктивности можно разложить по этим трём осям по мнению Макса. А он знает толк в DevEx, так как он занимался этим всю инженерную карьеру
- как главный архитектор Bugzilla
- работая над Code Health в Google
- отвечая за Developer Experience в LinkedIn
- а сейчас он Executive Distinguished Engineer в Capital One (банк чьей моделью бизнеса вдохновлялись при создании Тинькофф)
Поэтому мне взгляд Макса на productivity кажется не абстрактной теорией, а опытом полученным на практике.
Главная мысль доклада в том, что отличный developer experience - это не про красивый интерфейс внутреннего портала разработки. Это про системное снятие барьеров, которые замедляют инженера, выбивают его из фокуса и заставляют тратить мозг не на продукт, а на инфраструктурный шум. Макс по сути говорит: если улучшение не сокращает цикл, не защищает фокус и не снижает когнитивную нагрузку, то его ценность для DevEx сомнительна.
А теперь про инсайты
1️⃣ Скорость - это не мантра "работайте быстрее"
От призывов ускориться или поднажать появляется только стресс, а для реального ускорения надо ускорять внутренние циклы разработки (между внутренними этапами цикла), например можно сделать
- Быстрее ревью
- Меньше и понятнее PR
- Короче сборки
- Прозрачнее CI/CD
- Быстрее локальную обратную связь
Настоящая скорость рождается не из героизма, а из хорошо настроенной системы.
2️⃣ Фокус - это недооценённый актив
Каждое прерывание стоит дорого. Непонятная ошибка, внезапный статус-митинг, кривой tooling, шумные алерты - всё это рвёт контекст. А восстановление контекста часто занимает заметно больше времени, чем само прерывание. Интересна мысль про то, что developer productivity часто тонет не в больших проблемах, а в постоянной мелкой фрагментации внимания.
3️⃣ Когнитивная нагрузка - главный скрытый налог
Если для обычной продуктовой задачи инженеру нужно помнить особенности пяти пайплайнов, трёх систем мониторинга и семи способов доставки, то проблема не в инженере. Плохой DevEx часто выглядит именно так: разработчик пришёл делать бизнес-фичу, а вместо этого изучает внутренний зоопарк платформенных решений.
Из доклада можно извлечь очень практичные советы для технических руководителей
1) Оптимизируйте не лозунги, а путь работы
Смотрите не на абстрактную "производительность", а на конкретные бутылочные горлышки: сборка, ревью, тесты, деплой, ожидание доступа, диагностика падений.
2) Убирайте фазу угадывания
Если CI/CD падает с сообщением уровня "something went wrong", вы создаёте анти-DevEx. Хорошая система не просто сообщает о сбое, а помогает сразу понять причину и следующий шаг.
3) Берегите инженерный фокус как ограниченный ресурс
Линейных инженеров не стоит без необходимости тащить на статусные синки. Контекст-свитчинг - один из самых дорогих видов потерь в разработке.
4) Снижайте вариативность базовой платформы
Один стандартный CI, один понятный observability stack, единый способ запуска типовых сценариев - это не "ограничение свободы", а способ вернуть командам внимание к продукту.
5) Не путайте внутренний портал платформы с решением проблемы
Склеить 20 плохих процессов в один красивый UI - не значит улучшить DevEx. Иногда лучший интерфейс - это вообще отсутствие ручного шага.
P.S.
У Макса есть много интересных выступлений, например, про "Developer Experience in the Age of AI Coding Agents" я уже рассказывал
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
YouTube
What Makes a Great Developer Experience?
Presented by Max Kanat-Alexander (Capital One) at DPE Summit 2025, an event developed and hosted by Gradle.
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=what-makes…
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=what-makes…
1❤17🔥14👍9💯1
От классического PDLC к AI-native разработке (Рубрика #ai4sdlc)
Написал статью на Medium про то, как AI меняет не только скорость написания кода, а саму организацию инженерного труда. Мы постепенно движемся от SE 1.0 - процесса с ролями, стадиями и handoff’ами - к SE 2.0, где часть инженерной работы берут на себя AI-инструменты и агенты. Но это не бесплатное ускорение. Если не перестроить review, тесты, CI/CD и guardrails, AI просто переносит bottleneck дальше по цепочке. Для больших компаний рабочая стратегия - не ломать всё сразу, а использовать SE 2.0 как полигон новых практик и затем переносить лучшие из них в основной производственный контур.
В этой статье на 10 минут чтения я разобрал, что именно меняется в lifecycle и как на это смотреть инженерам и техническим руководителям.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Написал статью на Medium про то, как AI меняет не только скорость написания кода, а саму организацию инженерного труда. Мы постепенно движемся от SE 1.0 - процесса с ролями, стадиями и handoff’ами - к SE 2.0, где часть инженерной работы берут на себя AI-инструменты и агенты. Но это не бесплатное ускорение. Если не перестроить review, тесты, CI/CD и guardrails, AI просто переносит bottleneck дальше по цепочке. Для больших компаний рабочая стратегия - не ломать всё сразу, а использовать SE 2.0 как полигон новых практик и затем переносить лучшие из них в основной производственный контур.
В этой статье на 10 минут чтения я разобрал, что именно меняется в lifecycle и как на это смотреть инженерам и техническим руководителям.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Medium
От классического PDLC к AI-native разработке
На начало 2026 года разработка находится в переходной фазе. С одной стороны, у нас по‑прежнему доминирует классический процесс, построенный…
1👍18❤12🔥7
[1/2] Measuring the Impact of AI on Developer Productivity at Meta (Рубрика #AI)
Превосходное выступление от ребят из запрещенной в России Meta, которое я пересматривал раза 3, чтобы получше разобраться со всеми деталями. Выступали Payam Shodjai (senior director of product management) и Pavel Avgustinov (techlead) направления developer productivity в Meta и они рассказали кучу интересных подходов + технических деталей того, как они подходят к этому вопросу. После этого выстулпения я гораздо лучше понял концепты из статьи "What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time" (см. мой разбор).
Основная идея доклада крутилась вокруг вопроса "а как измерять влияние AI-инструментов на реальную инженерную продуктивность в большой компании?". И из доклада видно, что Meta построила всеобъемлющий набор метрик, собрала исчерпывающую телеметрию, научилась учитывать сложные операции в системах контроля версий (это обещали пошарить в новом whitepaper, так как базовый git не умеет делать так, как Sapling от Meta). Дальше они искали прямые корелляции между использованием AI и классическими метриками productivity/business value. И речь тут шла не про стандартный code completion, а о более широком наборе AI-инструментов по всему SDLC.
Если упрощать, то ребята показали, что без хорошей инструментализации разговор про ROI от AI быстро превращается в мнения и ощущения. Поэтому Meta делает ставку не на опросы как единственный источник, а на связку из телеметрии, diff-метрик, поведенческих данных и проверки этих данных на реальных рабочих сессиях. Это хорошо согласуется с описанной Meta системой Diff Authoring Time (DAT), которая объединяет privacy-aware telemetry из IDE, ОС и version control и затем валидируется наблюдательными исследованиями, опросами и визуализациями.
1️⃣ Умная классификация пулл-реквестов с помощью LLM
Долгое время главной метрикой в компании был DDM (Diffs per Developer per Month - количество диффов/коммитов на разработчика в месяц). Однако с внедрением ИИ эта метрика стала уязвима для "закона Гудхарта": разработчики могли искусственно завышать показатели, нарезая задачи на мелкие коммиты, а ИИ генерировал много бойлерплейта (шаблонного кода). Чтобы измерять реальную бизнес-ценность, Meta внедрила метрику Feature DDM. Для этого они используют LLM, которые автоматически анализируют содержимое каждого пулл-реквеста и классифицируют его на:
- Feature Diffs: код, создающий новую продуктовую ценность для пользователя.
- Non-Feature Diffs: рефакторинг, обновление конфигураций, тесты и документация.
ИИ-ассистенты оцениваются именно по тому, насколько они увеличивают количество продуктовых диффов.
2️⃣ Посимвольная телеметрия и внутренние инструменты (Devmate)
Meta не полагается на базовую статистику системы контроля версий. Для сбора данных они используют свой внутренний ИИ-инструмент - Devmate (кастомное расширение для IDE). Главный нюанс их телеметрии - посимвольное отслеживание (character-level tracking). Система точно знает происхождение каждого символа в коде. Meta может с абсолютной точностью сказать, какой процент символов в итоговом слитом пулл-реквесте был напечатан инженером вручную, а какой - сгенерирован нейросетью и оставлен без изменений. Отдельно упоминается про то, что Sapling позволяет умно отслеживать transition между commits и правильнее считать как трансформируется код при помощи edit/rebase и остального, а также кем именно (людьми или автоматикой). Помимо этого, телеметрия отслеживает узкие места всего цикла (SDLC): время нахождения задачи на код-ревью, циклы одобрения и прохождение автоматических тестов.
В следующем посте я расскажу про основные инсайты, которыми поделились авторы и которые реально интересны.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
Превосходное выступление от ребят из запрещенной в России Meta, которое я пересматривал раза 3, чтобы получше разобраться со всеми деталями. Выступали Payam Shodjai (senior director of product management) и Pavel Avgustinov (techlead) направления developer productivity в Meta и они рассказали кучу интересных подходов + технических деталей того, как они подходят к этому вопросу. После этого выстулпения я гораздо лучше понял концепты из статьи "What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time" (см. мой разбор).
Основная идея доклада крутилась вокруг вопроса "а как измерять влияние AI-инструментов на реальную инженерную продуктивность в большой компании?". И из доклада видно, что Meta построила всеобъемлющий набор метрик, собрала исчерпывающую телеметрию, научилась учитывать сложные операции в системах контроля версий (это обещали пошарить в новом whitepaper, так как базовый git не умеет делать так, как Sapling от Meta). Дальше они искали прямые корелляции между использованием AI и классическими метриками productivity/business value. И речь тут шла не про стандартный code completion, а о более широком наборе AI-инструментов по всему SDLC.
Если упрощать, то ребята показали, что без хорошей инструментализации разговор про ROI от AI быстро превращается в мнения и ощущения. Поэтому Meta делает ставку не на опросы как единственный источник, а на связку из телеметрии, diff-метрик, поведенческих данных и проверки этих данных на реальных рабочих сессиях. Это хорошо согласуется с описанной Meta системой Diff Authoring Time (DAT), которая объединяет privacy-aware telemetry из IDE, ОС и version control и затем валидируется наблюдательными исследованиями, опросами и визуализациями.
1️⃣ Умная классификация пулл-реквестов с помощью LLM
Долгое время главной метрикой в компании был DDM (Diffs per Developer per Month - количество диффов/коммитов на разработчика в месяц). Однако с внедрением ИИ эта метрика стала уязвима для "закона Гудхарта": разработчики могли искусственно завышать показатели, нарезая задачи на мелкие коммиты, а ИИ генерировал много бойлерплейта (шаблонного кода). Чтобы измерять реальную бизнес-ценность, Meta внедрила метрику Feature DDM. Для этого они используют LLM, которые автоматически анализируют содержимое каждого пулл-реквеста и классифицируют его на:
- Feature Diffs: код, создающий новую продуктовую ценность для пользователя.
- Non-Feature Diffs: рефакторинг, обновление конфигураций, тесты и документация.
ИИ-ассистенты оцениваются именно по тому, насколько они увеличивают количество продуктовых диффов.
2️⃣ Посимвольная телеметрия и внутренние инструменты (Devmate)
Meta не полагается на базовую статистику системы контроля версий. Для сбора данных они используют свой внутренний ИИ-инструмент - Devmate (кастомное расширение для IDE). Главный нюанс их телеметрии - посимвольное отслеживание (character-level tracking). Система точно знает происхождение каждого символа в коде. Meta может с абсолютной точностью сказать, какой процент символов в итоговом слитом пулл-реквесте был напечатан инженером вручную, а какой - сгенерирован нейросетью и оставлен без изменений. Отдельно упоминается про то, что Sapling позволяет умно отслеживать transition между commits и правильнее считать как трансформируется код при помощи edit/rebase и остального, а также кем именно (людьми или автоматикой). Помимо этого, телеметрия отслеживает узкие места всего цикла (SDLC): время нахождения задачи на код-ревью, циклы одобрения и прохождение автоматических тестов.
В следующем посте я расскажу про основные инсайты, которыми поделились авторы и которые реально интересны.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
YouTube
Measuring the Impact of AI on Developer Productivity at Meta
Presented by Pavel Avgustinov and Payam Shodjai (Meta) at DPE Summit 2025, an event developed and hosted by Gradle.
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=measuring…
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=measuring…
❤14🥴6🔥4⚡2
[2/2] Measuring the Impact of AI on Developer Productivity at Meta (Рубрика #AI)
Этот пост продолжение разбора отличного выступления ребят из Meta содержит инсайты, которыми они поделились с аудиторией.
1️⃣ У пользователей DevMate (внутренний аналог Claude Code или Cursor) выше среднего Meta наблюдала примерно 6–12% рост DDM (Diffs per developer per month). Это не звучит как "революция в 2 раза", но для большой инженерной организации такой прирост уже выглядит существенным, особенно если он устойчиво воспроизводится на больших массивах внутренних данных.
2️⃣ Эффект использования AI был неравномерным. Пока ИИ генерирует условные 10–30% изменений в диффе, выигрыш по времени почти не виден. А заметные улучшения появлялись, когда AI вносил более 60% кода в diff. Это намекает, что максимальный выигрыш возникает не тогда, когда AI используется "понемногу везде", а когда задача и workflow действительно позволяют передать инструменту большой кусок рутинной работы. То есть AI окупается сильнее в задачах, где можно делегировать значимый объем механического кода, а не только подсказки по мелочам.
3️⃣ Senior engineers использовали AI эффективнее, чем junior, хотя junior могли обращаться к нему чаще. Это важный анти-интуитивный момент: более частое использование не равно большему эффекту. Похоже, выигрывают те, кто лучше задает контекст, умеет проверять ответ модели и понимает, где AI стоит доверять, а где нет. В итоге, в среднем диффы синьоров содержат заметно больший процент AI‑кода, чем диффы джунов. Тезис ребят в том, что опыт, архитектурное мышление и умение формулировать точные инструкции сильно усиливают эффект от ИИ - синьор как будто просто даёт ТЗ не джуну, а модели.
4️⃣ После внедрения AI сначала может быть просадка, а уже потом рост продуктивности (J-кривая адаптации). По данным Meta наблюдается просадка продуктивности порядка 15%: люди учатся промптить, перепроверяют код, меняют привычный процесс. Уже после адаптации (через несколько месяцев) начинается устойчивый плюс к DDM и сокращение времени кодинга на дифф, что и даёт итоговые 6–12% роста выхода. Практический смысл тут простой: если компания смотрит на эффект AI только в первые недели после rollout, она может ошибочно решить, что инструмент "не работает".
5️⃣ Телеметрия показала, что инженеры меньше сидят в чатах и документах, потому что ответы и контекст получают прямо в IDE через DevMate. Из‑за этого время "coding time per diff" формально растёт, но авторы считают это хорошим сигналом: меньше дёрганья по ссылкам и мессенджерам, больше фокуса в одном инструменте.
6️⃣ Не все команды выигрывают одинаково - команды с высокой долей ML/ресёрча показывают меньший рост DDM, потому что много времени уходит на ноутбуки, эксперименты и аналитику, которые плохо отражаются в "диффах". Также DDM сильно "шумит" от праздников и внешних факторов, поэтому Meta не использует его в лоб как KPI для людей, а только как агрегированную продуктовую метрику влияния ИИ‑инструментов.
Если подводить итог, то я могу порекомендовать это видео и сопутстующие whitepaper тем, кто занимается вопросами измерения эффекта AI в разработке - это хороший методологический и практический подход к этой сложной теме.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
Этот пост продолжение разбора отличного выступления ребят из Meta содержит инсайты, которыми они поделились с аудиторией.
1️⃣ У пользователей DevMate (внутренний аналог Claude Code или Cursor) выше среднего Meta наблюдала примерно 6–12% рост DDM (Diffs per developer per month). Это не звучит как "революция в 2 раза", но для большой инженерной организации такой прирост уже выглядит существенным, особенно если он устойчиво воспроизводится на больших массивах внутренних данных.
2️⃣ Эффект использования AI был неравномерным. Пока ИИ генерирует условные 10–30% изменений в диффе, выигрыш по времени почти не виден. А заметные улучшения появлялись, когда AI вносил более 60% кода в diff. Это намекает, что максимальный выигрыш возникает не тогда, когда AI используется "понемногу везде", а когда задача и workflow действительно позволяют передать инструменту большой кусок рутинной работы. То есть AI окупается сильнее в задачах, где можно делегировать значимый объем механического кода, а не только подсказки по мелочам.
3️⃣ Senior engineers использовали AI эффективнее, чем junior, хотя junior могли обращаться к нему чаще. Это важный анти-интуитивный момент: более частое использование не равно большему эффекту. Похоже, выигрывают те, кто лучше задает контекст, умеет проверять ответ модели и понимает, где AI стоит доверять, а где нет. В итоге, в среднем диффы синьоров содержат заметно больший процент AI‑кода, чем диффы джунов. Тезис ребят в том, что опыт, архитектурное мышление и умение формулировать точные инструкции сильно усиливают эффект от ИИ - синьор как будто просто даёт ТЗ не джуну, а модели.
4️⃣ После внедрения AI сначала может быть просадка, а уже потом рост продуктивности (J-кривая адаптации). По данным Meta наблюдается просадка продуктивности порядка 15%: люди учатся промптить, перепроверяют код, меняют привычный процесс. Уже после адаптации (через несколько месяцев) начинается устойчивый плюс к DDM и сокращение времени кодинга на дифф, что и даёт итоговые 6–12% роста выхода. Практический смысл тут простой: если компания смотрит на эффект AI только в первые недели после rollout, она может ошибочно решить, что инструмент "не работает".
5️⃣ Телеметрия показала, что инженеры меньше сидят в чатах и документах, потому что ответы и контекст получают прямо в IDE через DevMate. Из‑за этого время "coding time per diff" формально растёт, но авторы считают это хорошим сигналом: меньше дёрганья по ссылкам и мессенджерам, больше фокуса в одном инструменте.
6️⃣ Не все команды выигрывают одинаково - команды с высокой долей ML/ресёрча показывают меньший рост DDM, потому что много времени уходит на ноутбуки, эксперименты и аналитику, которые плохо отражаются в "диффах". Также DDM сильно "шумит" от праздников и внешних факторов, поэтому Meta не использует его в лоб как KPI для людей, а только как агрегированную продуктовую метрику влияния ИИ‑инструментов.
Если подводить итог, то я могу порекомендовать это видео и сопутстующие whitepaper тем, кто занимается вопросами измерения эффекта AI в разработке - это хороший методологический и практический подход к этой сложной теме.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
Telegram
Книжный куб
[1/2] Measuring the Impact of AI on Developer Productivity at Meta (Рубрика #AI)
Превосходное выступление от ребят из запрещенной в России Meta, которое я пересматривал раза 3, чтобы получше разобраться со всеми деталями. Выступали Payam Shodjai (senior…
Превосходное выступление от ребят из запрещенной в России Meta, которое я пересматривал раза 3, чтобы получше разобраться со всеми деталями. Выступали Payam Shodjai (senior…
❤16🔥6⚡3
Как пользоваться System Design Space + треки изучения (Рубрика #SystemDesign)
Сделал онбординг для сайта system-design.space. Там я рассказываю, что сайт помогает системно развивать навыки проектирования: от базовых принципов до собеседований и практических архитектурных решений.
На сайте есть разные типы материалов
- Books - конспекты ключевых книг с практическими выводами и ссылками на оригиналы.
- Cases - пошаговые разборы проектирования реальных систем с требованиями и trade-offs.
- Films - документальные материалы и интервью с контекстом, таймлайнами и полезными источниками.
- Originals - авторские главы по архитектурным подходам, паттернам и инженерной практике.
Материалы можно сохранять в закладки, чтобы возвращаться к ним (в страницах настроек).
Также есть граф знаний, который позволяет увидеть связи между главами, быстро находить смежные темы и строить маршрут от базовых концепций к более сложным.
Также я создал возможность выбора трека обучения исходя из доступного для обучения времени, текущего уровня, а также бекграунда. После прохождения визарда собирается персональный маршрут, по которому дальше учиться. Также есть возможность отслеживать прогресс, который включается в настройках - это позволяет отмечать пройденные главы и видеть, как продвигается учебный маршрут.
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
Сделал онбординг для сайта system-design.space. Там я рассказываю, что сайт помогает системно развивать навыки проектирования: от базовых принципов до собеседований и практических архитектурных решений.
На сайте есть разные типы материалов
- Books - конспекты ключевых книг с практическими выводами и ссылками на оригиналы.
- Cases - пошаговые разборы проектирования реальных систем с требованиями и trade-offs.
- Films - документальные материалы и интервью с контекстом, таймлайнами и полезными источниками.
- Originals - авторские главы по архитектурным подходам, паттернам и инженерной практике.
Материалы можно сохранять в закладки, чтобы возвращаться к ним (в страницах настроек).
Также есть граф знаний, который позволяет увидеть связи между главами, быстро находить смежные темы и строить маршрут от базовых концепций к более сложным.
Также я создал возможность выбора трека обучения исходя из доступного для обучения времени, текущего уровня, а также бекграунда. После прохождения визарда собирается персональный маршрут, по которому дальше учиться. Также есть возможность отслеживать прогресс, который включается в настройках - это позволяет отмечать пройденные главы и видеть, как продвигается учебный маршрут.
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
System Design Space
System Design Space — Главная, граф знаний, треки и материалы
Главная страница System Design Space: быстрый старт, граф знаний, библиотека материалов, персональные треки и трекинг прогресса.
53🔥69❤9👍8🏆2
The Software Development Lifecycle Is Dead (Рубрика #Software)
В это интересной февральской статье 2026 Boris Tane делает громкое заявление о смерти SDLC, которое по моему мнению хорошо отражает ситуацию стратегически, но опережает текущие подходы на годик. Сам я думаю, что мы перейдем от классического PDLC к AI-native разработке и эту статью Бориса упомянул @brolnickij в канале @ai4sdlc, где можно обсудить посты из этого канала и не только.
Если возвращаться к главному тезису Бориса в его статье, то он такой
- Классический SDLC с фазами requirements → design → implementation → testing → code review → deployment → monitoring больше не распадается на отдельные этапы
- Вместо этого появляется короткий цикл: intent + context → agent → build/test/deploy → observe → repeat
Ну и дальше очень интересен взгляд автора на новый lifecycle по стадиям
- Требования больше не замораживаются перед стартом задачи, а уточняются по ходу итераций
- System design теперь не предписывается заранее, а обнаруживается в диалоге с агентом
- Имплементация изменений в коде почти целиком уходит агенту
- Тестирование теперь существует не отдельно, а тесты пишутся вместе с кодом (как многие хотели раньше)
- PR/code review как отдельный ритуал должны исчезнуть и стать exception-based (на случай, если автоматика не спрашивала)
- Деплои становятся действивтельно continuous и by design отделяются от release через flags/rollbacks
- Мониторинг превращается из последнего этапа в главный safety layer всей системы
Из этого у него следует довольно жесткий вывод: новый главный навык - context engineering, а новый контур safety - это observability. То есть выигрывает не та команда, у которой больше церемоний, а та, которая лучше умеет собирать контекст, задавать ограничения агенту и быстро замыкать telemetry обратно в цикл изменений. Это хорошо бьется и с DORA: они отдельно выделяют AI-accessible internal data и context engineering как ключевую capability для AI-assisted разработки.
Все это выглядит очень реалистично для небольших компаний или на greenfield проектах - инструменты уже реально умеют работать на уровне всего репозитория: читать codebase, менять много файлов, запускать команды и тесты, делать refactoring и code review. OpenAI пишет, что Codex заточен под длинные инженерные задачи и review, а Anthropic показывает, что опытные пользователи со временем дают агенту больше автономии, хотя продолжают активно вмешиваться по ходу работы. Плюс бенчмарки вроде SWE-bench Verified показывают, что agentic systems уже решают заметную долю реальных issue из open-source.
А вот что ждет большие компании и как будет выглядеть переход я рассказывал в статье "От классического PDLC к AI-native разработке"
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
В это интересной февральской статье 2026 Boris Tane делает громкое заявление о смерти SDLC, которое по моему мнению хорошо отражает ситуацию стратегически, но опережает текущие подходы на годик. Сам я думаю, что мы перейдем от классического PDLC к AI-native разработке и эту статью Бориса упомянул @brolnickij в канале @ai4sdlc, где можно обсудить посты из этого канала и не только.
Если возвращаться к главному тезису Бориса в его статье, то он такой
- Классический SDLC с фазами requirements → design → implementation → testing → code review → deployment → monitoring больше не распадается на отдельные этапы
- Вместо этого появляется короткий цикл: intent + context → agent → build/test/deploy → observe → repeat
Ну и дальше очень интересен взгляд автора на новый lifecycle по стадиям
- Требования больше не замораживаются перед стартом задачи, а уточняются по ходу итераций
- System design теперь не предписывается заранее, а обнаруживается в диалоге с агентом
- Имплементация изменений в коде почти целиком уходит агенту
- Тестирование теперь существует не отдельно, а тесты пишутся вместе с кодом (как многие хотели раньше)
- PR/code review как отдельный ритуал должны исчезнуть и стать exception-based (на случай, если автоматика не спрашивала)
- Деплои становятся действивтельно continuous и by design отделяются от release через flags/rollbacks
- Мониторинг превращается из последнего этапа в главный safety layer всей системы
Из этого у него следует довольно жесткий вывод: новый главный навык - context engineering, а новый контур safety - это observability. То есть выигрывает не та команда, у которой больше церемоний, а та, которая лучше умеет собирать контекст, задавать ограничения агенту и быстро замыкать telemetry обратно в цикл изменений. Это хорошо бьется и с DORA: они отдельно выделяют AI-accessible internal data и context engineering как ключевую capability для AI-assisted разработки.
Все это выглядит очень реалистично для небольших компаний или на greenfield проектах - инструменты уже реально умеют работать на уровне всего репозитория: читать codebase, менять много файлов, запускать команды и тесты, делать refactoring и code review. OpenAI пишет, что Codex заточен под длинные инженерные задачи и review, а Anthropic показывает, что опытные пользователи со временем дают агенту больше автономии, хотя продолжают активно вмешиваться по ходу работы. Плюс бенчмарки вроде SWE-bench Verified показывают, что agentic systems уже решают заметную долю реальных issue из open-source.
А вот что ждет большие компании и как будет выглядеть переход я рассказывал в статье "От классического PDLC к AI-native разработке"
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Boristane
The Software Development Lifecycle Is Dead | Boris Tane
AI agents didn't make the SDLC faster. They killed it. All that's left is context.
❤8🔥8👌3🥴2🥰1
Аквапарк в Завидово (#Travel)
Со второй попытки мы доехали семьей в этот аквапарк и нам тут нравится. Мы должны были сюда приехать на восьмое марта, но младший сын заболел и мы все перенесли на неделю. А сегодня утром встали, собрались и за полтора часа по платнику Москва-Питер приехали в отель "Рябина", заселились и по подземному переходу отправились в аквапарк прямо в халатах. В самом аквапарке тепло, солнышко много горок и не очень много людей - самое то для наших детей, которые сразу пошли исследовать новое место, что открылось всего несколько месяцев назад. В общем, этот аквапарк отличный - рекомендую его к посещению (надеюсь, что он не испортится, когда посетителей станет в разы больше)
#ForKids #ForParents
Со второй попытки мы доехали семьей в этот аквапарк и нам тут нравится. Мы должны были сюда приехать на восьмое марта, но младший сын заболел и мы все перенесли на неделю. А сегодня утром встали, собрались и за полтора часа по платнику Москва-Питер приехали в отель "Рябина", заселились и по подземному переходу отправились в аквапарк прямо в халатах. В самом аквапарке тепло, солнышко много горок и не очень много людей - самое то для наших детей, которые сразу пошли исследовать новое место, что открылось всего несколько месяцев назад. В общем, этот аквапарк отличный - рекомендую его к посещению (надеюсь, что он не испортится, когда посетителей станет в разы больше)
#ForKids #ForParents
❤12👍12🔥2🌚2
[1/2] Soviet Space Mythologies: Public Images, Private Memories, and the Making of a Cultural Identity (Мифология советского космоса) (Рубрика #Space)
Прочитал превосходную книгу Вячеслава Геровича (Slava Gerovitch), историка науки, senior lecturer MIT. Оригинал вышел в 2015 году в University of Pittsburgh Press, а русский перевод вышел в 2024 году в "Новом литературном обозрении". У этой книги интересное происхождение - автор пришел к этой теме из истории вычислительной техники: его позвали в проект по истории бортового компьютера Apollo, после чего его заинтересовало, как в СССР решали задачи управления в пилотируемой космонавтике. Дальше вопрос сместился от истории компьютеров к более общему вопросу: как распределяются функции человека и машины, кто реально принимает решения, и как дизайн корабля отражает баланс сил внутри программы. В итоге проект превратился в исследование памяти, нарративов и профессиональной идентичности инженеров и космонавтов.
Книга стала результатом 13-летней работы, что финансировалась разнообразными американскими грантами: исследование на раннем этапе шло в рамках проекта по Apollo Guidance Computer, поддержанного Sloan Foundation и Dibner Institute; затем были два проекта National Science Foundation, Fellowship in Aerospace History от American Historical Association и проект oral history, поддержанный NASA History Program. Круто, что эти гранты получилось использовать для изучения советской истории космонавтики.
Ниже основные идеи книги, которые делают книгу захватывающей
1️⃣ Автор показывает, что советская космическая мифология родилась из конфликта между секретностью и пропагандой. Публичная версия истории вычищала ошибки, аварии и неудачи и оставляла образ безупречных космонавтов на безотказной технике (миф, который развеялся во времена перестройки)
2️⃣ Центральный конфликт книги - космонавт как герой-пилот против космонавта как пассажира автоматизированной системы. Это не просто образный прием: в главах о взаимодействии человека и машины автор показывает, что спор об автоматизации был одновременно техническим, профессиональным и политическим. Иными словами, спорили не только о безопасности и control loop, но и о статусе, ответственности и праве принимать решения.
3️⃣ В книге явно показывается, что дизайн системы оказывается функцией организационной политики. По словам автора, конструкция советских кораблей отражала расстановку сил внутри отрасли; доминирование инженеров закрепило парадигму автоматического управления, а роль космонавтов во многом свелась к резервированию основных систем. Плюс на архитектуру влияла конкуренция конструкторских бюро и их патронов наверху.
4️⃣ Автор рассказывает не только про основной миф, но и о контрмифах. Он специально подчеркивает, что задача историка не просто опровергать красивую легенду, а разбирать, как она вообще собирается и зачем живет. Поэтому в книге много дневников, мемуаров, интервью и сопоставления несовпадающих версий одних и тех же событий - особенно вокруг полета Гагарина. Меня эта часть настолько сильно заинтересовала, что я купил коробку книг издательства "Космоскоп" (на многие из них ссылается автор)
5️⃣ Ну и после распада Советов началась переработка советского космоса в символ национальной идентичности - старый нарратив рухнул, но космос быстро стал удобным источником "истории, которой можно гордиться", уже в новом идеологическом и даже коммерческом контексте. Например, я смотрел с интересом фильмы "Королев" (2007), "Главный" (2015) и "Время первых" (2017).
А в продолжении я расскажу что из этого можно забрать разработчикам софта и техническим руководителям на подумать:)
#Science #SystemDesign #Architecture #Processes #History #PopScience #Engineering #Culture #Leadership
Прочитал превосходную книгу Вячеслава Геровича (Slava Gerovitch), историка науки, senior lecturer MIT. Оригинал вышел в 2015 году в University of Pittsburgh Press, а русский перевод вышел в 2024 году в "Новом литературном обозрении". У этой книги интересное происхождение - автор пришел к этой теме из истории вычислительной техники: его позвали в проект по истории бортового компьютера Apollo, после чего его заинтересовало, как в СССР решали задачи управления в пилотируемой космонавтике. Дальше вопрос сместился от истории компьютеров к более общему вопросу: как распределяются функции человека и машины, кто реально принимает решения, и как дизайн корабля отражает баланс сил внутри программы. В итоге проект превратился в исследование памяти, нарративов и профессиональной идентичности инженеров и космонавтов.
Книга стала результатом 13-летней работы, что финансировалась разнообразными американскими грантами: исследование на раннем этапе шло в рамках проекта по Apollo Guidance Computer, поддержанного Sloan Foundation и Dibner Institute; затем были два проекта National Science Foundation, Fellowship in Aerospace History от American Historical Association и проект oral history, поддержанный NASA History Program. Круто, что эти гранты получилось использовать для изучения советской истории космонавтики.
Ниже основные идеи книги, которые делают книгу захватывающей
1️⃣ Автор показывает, что советская космическая мифология родилась из конфликта между секретностью и пропагандой. Публичная версия истории вычищала ошибки, аварии и неудачи и оставляла образ безупречных космонавтов на безотказной технике (миф, который развеялся во времена перестройки)
2️⃣ Центральный конфликт книги - космонавт как герой-пилот против космонавта как пассажира автоматизированной системы. Это не просто образный прием: в главах о взаимодействии человека и машины автор показывает, что спор об автоматизации был одновременно техническим, профессиональным и политическим. Иными словами, спорили не только о безопасности и control loop, но и о статусе, ответственности и праве принимать решения.
3️⃣ В книге явно показывается, что дизайн системы оказывается функцией организационной политики. По словам автора, конструкция советских кораблей отражала расстановку сил внутри отрасли; доминирование инженеров закрепило парадигму автоматического управления, а роль космонавтов во многом свелась к резервированию основных систем. Плюс на архитектуру влияла конкуренция конструкторских бюро и их патронов наверху.
4️⃣ Автор рассказывает не только про основной миф, но и о контрмифах. Он специально подчеркивает, что задача историка не просто опровергать красивую легенду, а разбирать, как она вообще собирается и зачем живет. Поэтому в книге много дневников, мемуаров, интервью и сопоставления несовпадающих версий одних и тех же событий - особенно вокруг полета Гагарина. Меня эта часть настолько сильно заинтересовала, что я купил коробку книг издательства "Космоскоп" (на многие из них ссылается автор)
5️⃣ Ну и после распада Советов началась переработка советского космоса в символ национальной идентичности - старый нарратив рухнул, но космос быстро стал удобным источником "истории, которой можно гордиться", уже в новом идеологическом и даже коммерческом контексте. Например, я смотрел с интересом фильмы "Королев" (2007), "Главный" (2015) и "Время первых" (2017).
А в продолжении я расскажу что из этого можно забрать разработчикам софта и техническим руководителям на подумать:)
#Science #SystemDesign #Architecture #Processes #History #PopScience #Engineering #Culture #Leadership
🔥18❤11👍8👌1