[2/2] AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)
Продолжая рассказ о своем докладе, поделюсь своими мыслями о том, как подходить к AI-фикации разработки, которые основаны на whitepaper Measuring Developer Goals. В этой статье авторы рассказывали о том, что понимание и эффективное измерение целей критически важно для улучшения опыта разработчиков и повышения их эффективности. Для ответа на вопросы о продуктивности удобнее привязывать измерения не к конкретным инструментам, а к тем целям, которые разработчики ставят перед собой при использовании инструментов. Это позволяет отвечать на вопросы, похожие на те, что приведены выше, сохраняя метрики ориентированными на пользователя, а не инструмент. Подробный разбор в блоге, а также есть восьмая серия подкаста Research Insights Made Simple, где мы разбирали эту статью с Сашей Кусургашевым, моим коллегой, что руководит разработкой Spirit (наша внутренняя платформа разработки). Вообще, может быть полезна вся серия статей про "Developer Productivity for Humans", которуя я разбирал в двух постах (1 и 2).
Если привязывать эти идеи к внедрению AI в разработку, то ясно, что надо фокусироваться на главных jobs to be done сценариях, которые массовые/проблемные - помогая с ними можно получить максимальный эффект. Причем начинать стоит с AI-assisted вещей, а по мере улучшения ассистирования двигаться в сторону делегирования всего сценария агенту (правда, тут придется поработать с подготовкой контекста, настройкой evaluation, изменениями в процессах работы людей). И по мере изменений надо уметь измерять эффекты от этих улучшений так, чтобы показывать результаты топ-менеджерам (а они любят цифры ).
Про измерения продуктивности (как и зачем) я уже рассказывал раньше, но там были классические DORA, SPACE, DevEx. А в последнее время я пристально наблюдаю за платформой для измерения продуктивности DX, которая была основана теми, кто развивал предыдущие подходы. Эти ребята сделали систему с опросами и интеграцией с системами типа Jira, Wiki, git, CI/CD, ... В общем, ребята придумали свой фреймворк DX Core 4 для измерения инженерной продуктивности (см мой текстовый разбор + разбор в моем подкасте с Женей Сергеевым из Flo), а в этом году они же расширили его веткой для измерения эффективности AI ассистентов и агентов (см мой текстовый разбор + разбор в моем подкасте с Женей).
По-факту, эффективность AI ассистентов и агентов можно измерять с точки зрения трех направлений
1) Utilization - отслеживание внедрения и использования AI-инструментов (DAU, MAU, % сгенерированного кода, % PR с AI ассистированием, ...). Обычно с этого начинаются измерения, так как эти показатели измерить проще, чем те, что в следующих пунктах (Impact, Cost)
2) Impact - измерение реального эффекта на производительность (экономия времени разработчиков, PR throughput, percieved rate of delivery, ...)
3) Cost - отслеживание затрат и чистой прибыли
У ребят из DX есть бенчмарки по этим метрикам, которые они предоставляют клиентам DX платформы.
Если говорить про наш подход в Т-Банке, то мы умеем мерить первый уровень Utilization, а также у нас внедрен фреймворк SPACE для оценки developer productivity. Это позволдяет нам двигаться в сторону оценки Impact. Кстати, про наш фреймворк SPACE ребята рассказывали на IT Пикнике и вот разбор этого выступления. Но если у вас не внедрены инструменты для измерения developer productivity в компании, то не стоит грустить. Уровень утилизации можно измерить относительно просто, а большего вам может быть и не надо - сейчас разработка революционно меняется за счет использования AI-ассистентов и AI-агентов, а значит можно не вкладывать кучу сил в измерения старого подхода к делу, а экспериментировать с новым. Условно, не стоит обмерять деревянное колесо диллижанса, если у нас уже его вытесняет металлическое колесо машины:)
Ну а если хочется бенчмарков, то можно поучаствовать в нашем Большом исследовании AI в инженерной культуре России.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
Продолжая рассказ о своем докладе, поделюсь своими мыслями о том, как подходить к AI-фикации разработки, которые основаны на whitepaper Measuring Developer Goals. В этой статье авторы рассказывали о том, что понимание и эффективное измерение целей критически важно для улучшения опыта разработчиков и повышения их эффективности. Для ответа на вопросы о продуктивности удобнее привязывать измерения не к конкретным инструментам, а к тем целям, которые разработчики ставят перед собой при использовании инструментов. Это позволяет отвечать на вопросы, похожие на те, что приведены выше, сохраняя метрики ориентированными на пользователя, а не инструмент. Подробный разбор в блоге, а также есть восьмая серия подкаста Research Insights Made Simple, где мы разбирали эту статью с Сашей Кусургашевым, моим коллегой, что руководит разработкой Spirit (наша внутренняя платформа разработки). Вообще, может быть полезна вся серия статей про "Developer Productivity for Humans", которуя я разбирал в двух постах (1 и 2).
Если привязывать эти идеи к внедрению AI в разработку, то ясно, что надо фокусироваться на главных jobs to be done сценариях, которые массовые/проблемные - помогая с ними можно получить максимальный эффект. Причем начинать стоит с AI-assisted вещей, а по мере улучшения ассистирования двигаться в сторону делегирования всего сценария агенту (правда, тут придется поработать с подготовкой контекста, настройкой evaluation, изменениями в процессах работы людей). И по мере изменений надо уметь измерять эффекты от этих улучшений так, чтобы показывать результаты топ-менеджерам (
Про измерения продуктивности (как и зачем) я уже рассказывал раньше, но там были классические DORA, SPACE, DevEx. А в последнее время я пристально наблюдаю за платформой для измерения продуктивности DX, которая была основана теми, кто развивал предыдущие подходы. Эти ребята сделали систему с опросами и интеграцией с системами типа Jira, Wiki, git, CI/CD, ... В общем, ребята придумали свой фреймворк DX Core 4 для измерения инженерной продуктивности (см мой текстовый разбор + разбор в моем подкасте с Женей Сергеевым из Flo), а в этом году они же расширили его веткой для измерения эффективности AI ассистентов и агентов (см мой текстовый разбор + разбор в моем подкасте с Женей).
По-факту, эффективность AI ассистентов и агентов можно измерять с точки зрения трех направлений
1) Utilization - отслеживание внедрения и использования AI-инструментов (DAU, MAU, % сгенерированного кода, % PR с AI ассистированием, ...). Обычно с этого начинаются измерения, так как эти показатели измерить проще, чем те, что в следующих пунктах (Impact, Cost)
2) Impact - измерение реального эффекта на производительность (экономия времени разработчиков, PR throughput, percieved rate of delivery, ...)
3) Cost - отслеживание затрат и чистой прибыли
У ребят из DX есть бенчмарки по этим метрикам, которые они предоставляют клиентам DX платформы.
Если говорить про наш подход в Т-Банке, то мы умеем мерить первый уровень Utilization, а также у нас внедрен фреймворк SPACE для оценки developer productivity. Это позволдяет нам двигаться в сторону оценки Impact. Кстати, про наш фреймворк SPACE ребята рассказывали на IT Пикнике и вот разбор этого выступления. Но если у вас не внедрены инструменты для измерения developer productivity в компании, то не стоит грустить. Уровень утилизации можно измерить относительно просто, а большего вам может быть и не надо - сейчас разработка революционно меняется за счет использования AI-ассистентов и AI-агентов, а значит можно не вкладывать кучу сил в измерения старого подхода к делу, а экспериментировать с новым. Условно, не стоит обмерять деревянное колесо диллижанса, если у нас уже его вытесняет металлическое колесо машины:)
Ну а если хочется бенчмарков, то можно поучаствовать в нашем Большом исследовании AI в инженерной культуре России.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
Telegram
Книжный куб
[1/2] AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)
Сегодня с таким докладом я выступал на конференции AI Boost от Surf. В этом посте я тезисно расскажу о самой сути выступления, а также поделюсь всеми материалами для дополнительного изучения. И…
Сегодня с таким докладом я выступал на конференции AI Boost от Surf. В этом посте я тезисно расскажу о самой сути выступления, а также поделюсь всеми материалами для дополнительного изучения. И…
👍3❤2🔥2
Podlodka Techlead Crew про архитектурные антипаттерны (Рубрика #Architecture)
Когда рассказывают про архитектуру, то теоретики часто фокусируются на том, а как строить качественную архитектуру. Но на практике инженеры часто сталкиваются с неидеально спроектированными системами, которые доставляют много проблем. Поэтому часто бывает полезно знать симптомы того, что ваша архитектура требует доработок. Ну а вообще лучше изначально разобраться с типовыми ошибками проектирования, которые бывают и у опытных инженеров. Именно этой теме посвящен новый сезон онлайн-конференции Podlodka Techlead Crew.
В программе конференции будут следующие выступления
- От спагетти кода к доменной модели: критерии выбора между Transaction Script, Active Record, DDD и Clean Architecture, практический взгляд Кирилла Ветчинкина (Авито).
- AI для архитектора: валидация требований, поиск зависимостей, возможность ускорения архитектурного ревью с AI в интервью с Тимуром Баюровым (Т-Банк). Кстати, Тимур многое делает для проникновения AI в архитектурные процессы Т-Банка.
- Архитектура хранилища данных для вашего проекта: советы от Евгения Ненахова (МТС Web Services).
- Еда, EDA и C4 — выбери 3 из 3: практический воркшоп по Event-Driven Architecture и отказоустойчивости с разметкой в C4 проведёт Владимир Невзоров (автор канала System Design World).
Конференция пройдет на неделе с 13-17 октября и может принести вам много пользы, если вы связаны с проектированием и разработкой софта. Подробности здесь.
P.S.
Спасибо ребятам за то, что пошарили информацию о нашем исследовании AI в инженерной культуре России.
#Architecture #DistributedSystems #Software #Engineering #Processes #AI
Когда рассказывают про архитектуру, то теоретики часто фокусируются на том, а как строить качественную архитектуру. Но на практике инженеры часто сталкиваются с неидеально спроектированными системами, которые доставляют много проблем. Поэтому часто бывает полезно знать симптомы того, что ваша архитектура требует доработок. Ну а вообще лучше изначально разобраться с типовыми ошибками проектирования, которые бывают и у опытных инженеров. Именно этой теме посвящен новый сезон онлайн-конференции Podlodka Techlead Crew.
В программе конференции будут следующие выступления
- От спагетти кода к доменной модели: критерии выбора между Transaction Script, Active Record, DDD и Clean Architecture, практический взгляд Кирилла Ветчинкина (Авито).
- AI для архитектора: валидация требований, поиск зависимостей, возможность ускорения архитектурного ревью с AI в интервью с Тимуром Баюровым (Т-Банк). Кстати, Тимур многое делает для проникновения AI в архитектурные процессы Т-Банка.
- Архитектура хранилища данных для вашего проекта: советы от Евгения Ненахова (МТС Web Services).
- Еда, EDA и C4 — выбери 3 из 3: практический воркшоп по Event-Driven Architecture и отказоустойчивости с разметкой в C4 проведёт Владимир Невзоров (автор канала System Design World).
Конференция пройдет на неделе с 13-17 октября и может принести вам много пользы, если вы связаны с проектированием и разработкой софта. Подробности здесь.
P.S.
Спасибо ребятам за то, что пошарили информацию о нашем исследовании AI в инженерной культуре России.
#Architecture #DistributedSystems #Software #Engineering #Processes #AI
podlodka.io
Онлайн-конференция Podlodka Teсhlead Crew #10
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам techlead-разработки, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
🔥4❤2👍1
Эволюция метрик и практика применения SPACE (Рубрика #DevEx)
Мои коллеги Саша Кусургашев и Дима Гаевский на IT Пикнике летом рассказывали про то, как мы используем фреймворк SPACE для оценки продуктивности инженеров. Недавно появилась запись выступления Саши (который отдувался за двоих ) и я решил поделится кратким саммари этого рассказа.
Если уложить это саммари в одну мысль, то она примерно такая "инженеров нельзя адекватно оценить одной цифрой или простым количественным показателем" - хотя часто это пытались сделать (например, число коммитов, строк кода, выполненных задач), но каждая такая метрика отражает лишь одну сторону дела и сильно зависит от контекста. Например, большое число изменений в коде может свидетельствовать как о высоком темпе команды, так и о переработках или неэффективном процессе – без контекста такие цифры вводят в заблуждение. Ребята привели в докладе кучу примеров того, как приходится учитывать множество граней эффективности: скорость работы, качество результата, командное взаимодействие, удовлетворённость сотрудников и другие факторы.
Собственно, первая половина доклада была про сам фреймворк "SPACE", где рассказ строился на статье "The SPACE of Developer Productivity", о которой я уже рассказывал раньше. Сам акроним SPACE расшифровывается как
- Satisfaction & Well being (удовлетворённость)
- Performance (результативность)
- Activity (активность)
- Communication & Collaboration (коммуникация)
- Efficiency (эффективность)
Каждое из этих измерений дополняет остальные, создавая целостную картину. В выступлении отмечалось, что такой многомерный подход родился как реакция на злоупотребления однобокими метриками и нацелена на то, чтобы сделать оценку работы инженеров более справедливой и осмысленной.
Вторая часть доклада была посвящена опыту внедрения SPACE и мне она кажется самой полезной частью выступления. Саша рассказал с чего начать сбор метрик и как интерпретировать.Внедрение многомерной системы измерений оказалось непростой задачей – потребовалось агрегировать данные из разных источников (систем контроля версий, трекеров задач, CI/CD, опросов сотрудников и пр.) и привести их к единой основе для сравнения. Авторы подчеркнули важность нормализации данных и правильных «разрезов» – нужно решать, по каким сечениям анализировать метрики (по командам, по проектам, по временным периодам), чтобы выявлять закономерности и проблемные зоны. Это оказалось нетривиально: разные сегменты показывали разную картину, и неправильный выбор среза мог скрыть проблему или создать иллюзию успеха. Например, сравнение по командам требует учёта специфики проектов; сравнение по времени – учёта сезонности и изменений обстоятельств.
Круто, что ребята честно поделились ошибками первого подхода к SPACE. Поначалу они старались измерить «всё и сразу» и получить мгновенный интегральный показатель. Это привело к избытку данных и трудностям в их понимании. Как итог - не стоит пытаться охватить сразу все метрики без приоритизации. Вместо этого лучше выбрать несколько метрик по ключевым измерениям, которые наиболее актуальны для текущих проблем команды, и начать с них. Важно «не перегнуть палку и не утонуть в данных», а подбирать метрики под свой контекст. Постепенно, когда культура работы с метриками начала формироваться, они расширяли охват SPACE-факторов, но уже осознанно и с учётом полученных инсайтов.
Из выступления можно забрать такие мысли
1) Комбинируйте объективные метрики с обратной связью от людей
2) Используйте метрики как инструмент для улучшения, а не для наказания. Стоит выявлять узкие места и точки роста, а не устраивать «соревнование разработчиков» или повышать бюрократию
3) Вводите метрики постепенно и осмысленно. Начать с пилотной команды или направления, выбрать небольшое подмножество SPACE-метрик, относящихся к наиболее болезненной проблеме, и опробовать их в деле
4) Важна роль культуры и поддержки руководства. Внедрение SPACE – это не разовая акция, а изменение подхода к управлению
#Processes #Management #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SRE
Мои коллеги Саша Кусургашев и Дима Гаевский на IT Пикнике летом рассказывали про то, как мы используем фреймворк SPACE для оценки продуктивности инженеров. Недавно появилась запись выступления Саши (
Если уложить это саммари в одну мысль, то она примерно такая "инженеров нельзя адекватно оценить одной цифрой или простым количественным показателем" - хотя часто это пытались сделать (например, число коммитов, строк кода, выполненных задач), но каждая такая метрика отражает лишь одну сторону дела и сильно зависит от контекста. Например, большое число изменений в коде может свидетельствовать как о высоком темпе команды, так и о переработках или неэффективном процессе – без контекста такие цифры вводят в заблуждение. Ребята привели в докладе кучу примеров того, как приходится учитывать множество граней эффективности: скорость работы, качество результата, командное взаимодействие, удовлетворённость сотрудников и другие факторы.
Собственно, первая половина доклада была про сам фреймворк "SPACE", где рассказ строился на статье "The SPACE of Developer Productivity", о которой я уже рассказывал раньше. Сам акроним SPACE расшифровывается как
- Satisfaction & Well being (удовлетворённость)
- Performance (результативность)
- Activity (активность)
- Communication & Collaboration (коммуникация)
- Efficiency (эффективность)
Каждое из этих измерений дополняет остальные, создавая целостную картину. В выступлении отмечалось, что такой многомерный подход родился как реакция на злоупотребления однобокими метриками и нацелена на то, чтобы сделать оценку работы инженеров более справедливой и осмысленной.
Вторая часть доклада была посвящена опыту внедрения SPACE и мне она кажется самой полезной частью выступления. Саша рассказал с чего начать сбор метрик и как интерпретировать.Внедрение многомерной системы измерений оказалось непростой задачей – потребовалось агрегировать данные из разных источников (систем контроля версий, трекеров задач, CI/CD, опросов сотрудников и пр.) и привести их к единой основе для сравнения. Авторы подчеркнули важность нормализации данных и правильных «разрезов» – нужно решать, по каким сечениям анализировать метрики (по командам, по проектам, по временным периодам), чтобы выявлять закономерности и проблемные зоны. Это оказалось нетривиально: разные сегменты показывали разную картину, и неправильный выбор среза мог скрыть проблему или создать иллюзию успеха. Например, сравнение по командам требует учёта специфики проектов; сравнение по времени – учёта сезонности и изменений обстоятельств.
Круто, что ребята честно поделились ошибками первого подхода к SPACE. Поначалу они старались измерить «всё и сразу» и получить мгновенный интегральный показатель. Это привело к избытку данных и трудностям в их понимании. Как итог - не стоит пытаться охватить сразу все метрики без приоритизации. Вместо этого лучше выбрать несколько метрик по ключевым измерениям, которые наиболее актуальны для текущих проблем команды, и начать с них. Важно «не перегнуть палку и не утонуть в данных», а подбирать метрики под свой контекст. Постепенно, когда культура работы с метриками начала формироваться, они расширяли охват SPACE-факторов, но уже осознанно и с учётом полученных инсайтов.
Из выступления можно забрать такие мысли
1) Комбинируйте объективные метрики с обратной связью от людей
2) Используйте метрики как инструмент для улучшения, а не для наказания. Стоит выявлять узкие места и точки роста, а не устраивать «соревнование разработчиков» или повышать бюрократию
3) Вводите метрики постепенно и осмысленно. Начать с пилотной команды или направления, выбрать небольшое подмножество SPACE-метрик, относящихся к наиболее болезненной проблеме, и опробовать их в деле
4) Важна роль культуры и поддержки руководства. Внедрение SPACE – это не разовая акция, а изменение подхода к управлению
#Processes #Management #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SRE
YouTube
Дмитрий Гаевский, Александр Кусургашев — «Эволюция метрик и практика применения SPACE»
Рассмотрим эволюцию подходов к измерению эффективности инженеров: от LOC и Function Points до DORA и SPACE. Покажем, как внедряли SPACE у себя: сбор и нормализация данных, сложности разрезов, ошибки первого внедрения, подтвержденные и неподтвержденные гипотезы.…
❤12🔥7👍5
The Software Engineer's Guidebook (Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов) (Рубрика #Engineering)
Недавно дочитал книгу Гергели Ороша, автора рассылки "The Pragmatic Engineer", бывшего engineering менеджера в Uber и разработчика в Skype/Microsoft и Skyscanner. Я уже рассказывал про эту книгу раньше, когда я только начинал ее читать. Теперь, после прочтения, я могу поделиться кратким саммари.
Книга хорошо подходит для инженеров, которые хотят пройти по всем ступенькам от джуна до стафф+ инженера - часть материалов адресована всем уровням, а дальше блоки для middle → senior → tech lead → staff идут по нарастающей. Автор отдельно замечает, что книга полезна и менеджерам, особенно тем, кто старается оставаться «hands‑on». Книга разбита на отдельные темы + есть бонусные онлайн-главы
- Базовые принципы карьеры - пути развития, «владение» своей карьерой, performance‑review, промо, как работать в разных средах (стартап/BigTech), смена работы.
- Компетентный разработчик - как доводить задачи до результата, написание кода, процесс разработки, инструменты продуктивного инженера.
- Senior инженер - взаимодействие и командная работа, инженерные практики, тестирование, архитектура.
- Техлид (не важно должность это или роль) - проектное управление, выпуск в прод, управление стейкхолдерами, структура и динамика команды.
- Staff/Principal - понимание бизнеса, влияние без полномочий, надёжность и архитектура.
- Заключение + онлайн‑«бонус‑главы» к предыдущим частям
Книгу можно использовать как настольный справочник и читать точечно, в нужном месте.
Мне показались интересным советы о карьере, которые повышают осознанность и успешность движения по карьерной лестнице
- "Владейте своей карьерой" - ведите журнал выполненных задач, регулярно просите обратную связь и делайте менеджера союзником — это прямая инвестиция в промо.
- Готовьтесь к performance‑review готовятся заранее - начинайте собирать контекст и артефакты за месяцы до ревью, помогая менеджеру и калибровке.
- Промо ≠ просто "побольше сделать" - эффект конечно важен, но также нужно демонстрировать компетенции следующего уровня и координировать сложные инициативы.
- Среда имеет значение - BigTech и стартапы требуют разных стратегий; выбирайте то, что лучше под ваши цели и этап
В принципе, есть и другие похожие книги для IC и engineering managers, о которых я уже рассказывал
- Will Larson "Staff Engineer: Leadership Beyond the Management Track" - про то, как расти и работать на staff‑ветке без ухода в менеджмент (см. мой обзор)
- Tanya Reilly "The Staff Engineer’s Path" - подробное руководство по роли staff‑инженера: стратегия, влияние, стандарты качества (см. мой обзор)
- Camille Fournier "The Manager’s Path" - путь инженера в engineering менеджеры (см. мой обзор)
- Will Larson "An Elegant Puzzle" - системный взгляд на инженерный менеджмент и организационные решения (см. мой обзор)
Итого, эта книга мне показалсь довольно практичной и полезной для инженеров, которые хотят осознанно развивать свою карьеру не просто прыгая по уровням, а строя правильный инженерный фундамент и фокусируясь на важных вопросах на каждом этапе от джуна до staff инженера.
#Engineering #Management #Leadership #Processes #Software #Career #Staff #Career #Architecture
Недавно дочитал книгу Гергели Ороша, автора рассылки "The Pragmatic Engineer", бывшего engineering менеджера в Uber и разработчика в Skype/Microsoft и Skyscanner. Я уже рассказывал про эту книгу раньше, когда я только начинал ее читать. Теперь, после прочтения, я могу поделиться кратким саммари.
Книга хорошо подходит для инженеров, которые хотят пройти по всем ступенькам от джуна до стафф+ инженера - часть материалов адресована всем уровням, а дальше блоки для middle → senior → tech lead → staff идут по нарастающей. Автор отдельно замечает, что книга полезна и менеджерам, особенно тем, кто старается оставаться «hands‑on». Книга разбита на отдельные темы + есть бонусные онлайн-главы
- Базовые принципы карьеры - пути развития, «владение» своей карьерой, performance‑review, промо, как работать в разных средах (стартап/BigTech), смена работы.
- Компетентный разработчик - как доводить задачи до результата, написание кода, процесс разработки, инструменты продуктивного инженера.
- Senior инженер - взаимодействие и командная работа, инженерные практики, тестирование, архитектура.
- Техлид (не важно должность это или роль) - проектное управление, выпуск в прод, управление стейкхолдерами, структура и динамика команды.
- Staff/Principal - понимание бизнеса, влияние без полномочий, надёжность и архитектура.
- Заключение + онлайн‑«бонус‑главы» к предыдущим частям
Книгу можно использовать как настольный справочник и читать точечно, в нужном месте.
Мне показались интересным советы о карьере, которые повышают осознанность и успешность движения по карьерной лестнице
- "Владейте своей карьерой" - ведите журнал выполненных задач, регулярно просите обратную связь и делайте менеджера союзником — это прямая инвестиция в промо.
- Готовьтесь к performance‑review готовятся заранее - начинайте собирать контекст и артефакты за месяцы до ревью, помогая менеджеру и калибровке.
- Промо ≠ просто "побольше сделать" - эффект конечно важен, но также нужно демонстрировать компетенции следующего уровня и координировать сложные инициативы.
- Среда имеет значение - BigTech и стартапы требуют разных стратегий; выбирайте то, что лучше под ваши цели и этап
В принципе, есть и другие похожие книги для IC и engineering managers, о которых я уже рассказывал
- Will Larson "Staff Engineer: Leadership Beyond the Management Track" - про то, как расти и работать на staff‑ветке без ухода в менеджмент (см. мой обзор)
- Tanya Reilly "The Staff Engineer’s Path" - подробное руководство по роли staff‑инженера: стратегия, влияние, стандарты качества (см. мой обзор)
- Camille Fournier "The Manager’s Path" - путь инженера в engineering менеджеры (см. мой обзор)
- Will Larson "An Elegant Puzzle" - системный взгляд на инженерный менеджмент и организационные решения (см. мой обзор)
Итого, эта книга мне показалсь довольно практичной и полезной для инженеров, которые хотят осознанно развивать свою карьеру не просто прыгая по уровням, а строя правильный инженерный фундамент и фокусируясь на важных вопросах на каждом этапе от джуна до staff инженера.
#Engineering #Management #Leadership #Processes #Software #Career #Staff #Career #Architecture
Telegram
Книжный куб
The Software Engineer's Guidebook (Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов)
Сегодня мне пришла книга Gergely Orosz, известного инженера и автора "The Pragmatic Engineer", самого популярного технического…
Сегодня мне пришла книга Gergely Orosz, известного инженера и автора "The Pragmatic Engineer", самого популярного технического…
👍14🔥8❤6
У наших аналитиков в Т есть подкаст InSAйт, куда они зовут гостей обсуждать интересные темы. Второй сезон заканчивался темой "У системных аналитиков нет комьюнити: миф или реальность", куда ребята позвали гостем Анастасию Кабищеву, Head of project management office компании Ekleft, консультанта по психологической безопасности команд, а также мою жену. В итоге, я не мог ни рассказать об этом подкасте - рекомендую его к прослушиванию всем, кто занимался темой построения коммьюнити.
🔥8❤6👍2
Forwarded from InSAйт
У системных аналитиков нет комьюнити: миф или реальность
Почему у аналитиков нет ощущения «мы — вместе»? Можно ли построить сообщество без формальной структуры и зачем вообще это делать?
И правда, что фраза «мы как семья» больше мешает?
Все это мы обсудили в финальном выпуске второго сезона подкаста с Анастасией Кабищева, PMO Ekleft и консультантом по психологической безопасности команд.
Слушайте последний выпуск этого сезона, чтобы узнать:
➡️ Что такое комьюнити и почему его нельзя построить «сверху».
➡️ Зачем сообществу нужны цели, роли и даже «боли».
➡️ Как уживаются конфликтность и безопасность внутри одной группы.
➡️ Почему научить людей спрашивать — отдельный навык.
➡️ Какие качества помогают системным аналитикам создавать живое комьюнити.
Где слушать?
🔸Яндекс.Музыка
🔸ВК
🔸Apple Podcasts
🔸Telegram-плеер
🔸остальные платформы
Почему у аналитиков нет ощущения «мы — вместе»? Можно ли построить сообщество без формальной структуры и зачем вообще это делать?
И правда, что фраза «мы как семья» больше мешает?
Все это мы обсудили в финальном выпуске второго сезона подкаста с Анастасией Кабищева, PMO Ekleft и консультантом по психологической безопасности команд.
Слушайте последний выпуск этого сезона, чтобы узнать:
Где слушать?
🔸Яндекс.Музыка
🔸ВК
🔸Apple Podcasts
🔸Telegram-плеер
🔸остальные платформы
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤4👍4👀1
[1/2] Исследование AI в SDLC от IT One и Сколково (Рубрика #AI)
Недавно я был на презентации результатов исследования от IT One и Сколково, где участвовал в панельной дискуссии. Потом я взял это исследование и изучил все 59 страниц, в которых примерно следующая структура
1) Мировая практика: существующая и предстоящая трансформация SDLC под влиянием ИИ - здесь авторы провели мета-исследование, проанализировав отчеты других уважаемых ребят (приведу ссылки ниже при описании результатов)
2) AI в SDLC в России: ландшафт рынка, сервисы, практики и ожидания по развитию - здесь авторы проанализировали публичные сервисы, доступные на рынке Росии + проанализировали крупные анонсы от игроков, даже если сами решения еще не доступны для широкого круга пользователей
3) Взгляд технологических лидеров на AI в SDLC: результаты интервью СТО / CIO и руководителей по разработке крупных компаний - здесь авторы взяли интервью с 50+ уважаемых людей в индустрии (списка этих людей я в отчете не нашел, но поверим на слово)
4) Прогнозы, выводы и рекомендации о возможностях и рисках, с которыми связано использованием AI в SDLC - мнение авторов о том, как дальше будет развиваться AI и как его интегрировать в разработку
Начнем в этом посте с общемировой практики
- Рынку AI-инструментов для разработки : $6,9 млрд → $29,6 млрд к 2032 (х4). Наибольший эффект на этапах разработки и тестирования. Источник Spherical Insights
- 62% разработчиков уже используют ИИ; ещё 13,8% — в планах (по данным 2024 года). Менеджеры оценивают проникновение ниже, но тренд ускоряется. Источник StackOverflow 2024 (я разбирал этот отчет 2024 года, а также разбирал и новый отчет 2025 года)
- Ценность смещается от личной эффективности (быстрее пишет код) к командной: сейчас +10% к скорости кодинга, в горизонте нескольких лет +25–30% к продуктивности команд при работе "ИИ-на-уровне-команд" (чтобы это ни значило). Источник Mia Platform
- Ускорение SDLC: уже 15–20% сейчас (источник: Forrester), потенциал 30–50% на среднесрочном горизонте (источник: medium статья от Сатиш Рама, Director Gen AI @ Paypal)
- Горизонт трансформации процессов - 1–3 года; у 32% техлидеров фактический эффект уже превзошёл ожидания (Источник: MIT, но конкретной ссылки на статью нет)
Отдельно авторы упоминают про исследование METR, где на сложных задачах/репозиториях ИИ может замедлять работу опытных инженеров. Подробный разбор есть в моих постах 1 и 2 и даже в подкасте RIMS, где показано, что само исследование задизайнено под конкретный результат + представляет очень узкий кейс.
Интересно, что авторы исследования нашли модель зрелости от министерства DEFRA правительства Великобритании "The AI-Powered SDLC: A Comprehensive Technical and Cultural Maturity Assessment Framework". Я сначала не понял как ведомство, отвечающее за охрану окружающей среды, продовльственную политику и развитие сельских регионов связано с цифровизацией, но потом изучил вопрос и понял:) С середины 2010-х DEFRA стало одним из лидеров цифровой трансформации в британском госсекторе, во многом благодаря активному сотрудничеству с Government Digital Service (GDS) и Central Digital and Data Office (CDDO). У DEFRA тысячи источников данных (от спутников до фермерских отчетов) и огромное разнообразие пользователей. Поэтому именно здесь британское правительство активно тестирует свои AI/ML темы и агентские системы.
Если же говорить про риски AI, которые отмечают западные отчеты, то они такие
- Утечки кода/данных и проблемы с соблюдение требований комплаенса;
- Деградация компетенций инженеров и «слепое» доверие подсказкам;
- Рост техдолга и vendor lock‑in на провайдеров
В итоге, видно, что тема AI-фикации процессов разработки софта сейчас горяча как никогда. На Западе только ленивый не публикует свои отчеты/прогнозы/продукты/... и по большей части они сейчас в положительной тональности. Но многие отмечают, что скачок эффективности будет при переходе от личных копилотов к интеграции в процессы компаний. Дальше поговорим про Россию.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
Недавно я был на презентации результатов исследования от IT One и Сколково, где участвовал в панельной дискуссии. Потом я взял это исследование и изучил все 59 страниц, в которых примерно следующая структура
1) Мировая практика: существующая и предстоящая трансформация SDLC под влиянием ИИ - здесь авторы провели мета-исследование, проанализировав отчеты других уважаемых ребят (приведу ссылки ниже при описании результатов)
2) AI в SDLC в России: ландшафт рынка, сервисы, практики и ожидания по развитию - здесь авторы проанализировали публичные сервисы, доступные на рынке Росии + проанализировали крупные анонсы от игроков, даже если сами решения еще не доступны для широкого круга пользователей
3) Взгляд технологических лидеров на AI в SDLC: результаты интервью СТО / CIO и руководителей по разработке крупных компаний - здесь авторы взяли интервью с 50+ уважаемых людей в индустрии (списка этих людей я в отчете не нашел, но поверим на слово)
4) Прогнозы, выводы и рекомендации о возможностях и рисках, с которыми связано использованием AI в SDLC - мнение авторов о том, как дальше будет развиваться AI и как его интегрировать в разработку
Начнем в этом посте с общемировой практики
- Рынку AI-инструментов для разработки : $6,9 млрд → $29,6 млрд к 2032 (х4). Наибольший эффект на этапах разработки и тестирования. Источник Spherical Insights
- 62% разработчиков уже используют ИИ; ещё 13,8% — в планах (по данным 2024 года). Менеджеры оценивают проникновение ниже, но тренд ускоряется. Источник StackOverflow 2024 (я разбирал этот отчет 2024 года, а также разбирал и новый отчет 2025 года)
- Ценность смещается от личной эффективности (быстрее пишет код) к командной: сейчас +10% к скорости кодинга, в горизонте нескольких лет +25–30% к продуктивности команд при работе "ИИ-на-уровне-команд" (чтобы это ни значило). Источник Mia Platform
- Ускорение SDLC: уже 15–20% сейчас (источник: Forrester), потенциал 30–50% на среднесрочном горизонте (источник: medium статья от Сатиш Рама, Director Gen AI @ Paypal)
- Горизонт трансформации процессов - 1–3 года; у 32% техлидеров фактический эффект уже превзошёл ожидания (Источник: MIT, но конкретной ссылки на статью нет)
Отдельно авторы упоминают про исследование METR, где на сложных задачах/репозиториях ИИ может замедлять работу опытных инженеров. Подробный разбор есть в моих постах 1 и 2 и даже в подкасте RIMS, где показано, что само исследование задизайнено под конкретный результат + представляет очень узкий кейс.
Интересно, что авторы исследования нашли модель зрелости от министерства DEFRA правительства Великобритании "The AI-Powered SDLC: A Comprehensive Technical and Cultural Maturity Assessment Framework". Я сначала не понял как ведомство, отвечающее за охрану окружающей среды, продовльственную политику и развитие сельских регионов связано с цифровизацией, но потом изучил вопрос и понял:) С середины 2010-х DEFRA стало одним из лидеров цифровой трансформации в британском госсекторе, во многом благодаря активному сотрудничеству с Government Digital Service (GDS) и Central Digital and Data Office (CDDO). У DEFRA тысячи источников данных (от спутников до фермерских отчетов) и огромное разнообразие пользователей. Поэтому именно здесь британское правительство активно тестирует свои AI/ML темы и агентские системы.
Если же говорить про риски AI, которые отмечают западные отчеты, то они такие
- Утечки кода/данных и проблемы с соблюдение требований комплаенса;
- Деградация компетенций инженеров и «слепое» доверие подсказкам;
- Рост техдолга и vendor lock‑in на провайдеров
В итоге, видно, что тема AI-фикации процессов разработки софта сейчас горяча как никогда. На Западе только ленивый не публикует свои отчеты/прогнозы/продукты/... и по большей части они сейчас в положительной тональности. Но многие отмечают, что скачок эффективности будет при переходе от личных копилотов к интеграции в процессы компаний. Дальше поговорим про Россию.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
👍5❤2🔥1
[2/2] Исследование AI в SDLC от IT One и Сколково (Рубрика #AI)
Продолжая рассказ про исследование и переходя к российским реалиям хочется процитировать отчет
На текущий момент в России проникновение ИИ в задачи разработчиков происходит темпами, сопоставимыми с мировыми. Однако, на российском рынке, в отличие от мирового, проблемы и вызовы изменения жизненного цикла разработки под влиянием ИИ только начинают входить в приоритеты и фокусы технологических лидеров и тимлидов.
Эта цитата подкрепляется исследованием Руссофт от 2024 года, где опрос софтверных компаний показал, что 54,8% из них отметили, что они имеют экспертизу и опыт в области искусственного интеллекта и используют их в разработке новых заказных систем или собственных решений (эта чиселка отросла с 46,6% в 2023 году).
Авторы исследования дают оценку, что ИИ используют ~62% сотрудников ИТ‑команд (в 2 раза выше 2024), а к 2028 пороникновение будет ~98% (~3,22 млн пользователей). Я не смог источник, откуда взят этот прогноз (упоминается отчет Руссофта, приведенный выше, а также отчет T-Adviser про рынок труда).
Дальше авторы рассказывают про ландшафт AI инструментов в России и делятся оптимистичными цифрами
- Ассистенты разработчика: GigaCode (Сбер), Yandex Code Assistant / SourceCraft, МТС Kodify; DevSecOps: Safeliner (Т‑Банк)
- Публичные заявления о результатах применения этих инструментов навроде
-- GigaCode: до +28% к скорости разработки; −50% времени на регрессию; +30% скорость UI‑автотестов; 3× быстрее настройка конвейера; 2× быстрее онбординг DevOps;
-- 5× быстрее обработка ИБ‑уязвимостей в Safeliner от Т-Банка
-- Platform V Works (СберТех): −40% времени до прома в CI/CD; −50% времени на тестирование; +25% релизов; −20% трудозатрат
-- Альфа‑Банк: ИИ‑агенты‑тестировщики — −30% ошибок за счёт роста покрытия, до 70% быстрее генерация автотестов; масштаб на 60+ команд
Среди трендов авторы выделяют
- Встраивание AI в платформы разработки: IDE, CI/CD, DevSecOps и т.д
- Появление агентных сценариев - автогенерация тестов/кода, проведения код-ревью
- Изменение нормы эффективности и дальнейшее движение в стороны T‑shaped разработчиков
Интересно, что вызовами являются темы
- Измерений эффектов - меньше 25% компаний замеряют их, а те, кто измеряют ориентируются на TTM/Lead Time, дефекты на проде
- Регуляторика и риски качества недетерминированной работы LLM - ИБ/152‑ФЗ, качество LLM, контроль использования и «галлюцинаций»
Авторы исследования предлагают следующий план внедрения AI
- Выберите 1–2 узких сценария: юнит‑тесты, код‑ревью, ...
- Зафиксируйте базовые метрики: TTM, Lead Time, дефекты
- Примите политику ИБ: что можно/нельзя; on‑prem/cloud LLM для кода
- Встраивайте в платформу разработки/CI‑CD, а не кустарно сбоки
- Введите quality‑gate для AI‑кода% кодстайл, статанализ, обязательное ревью
- Создайте библиотеку промптов и обучите команду.
- Сравнивайте российские и зарубежные модели на своих задачах.
- Масштабируйте после 2–3 успешных пилотов с подтверждённым ROI.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
Продолжая рассказ про исследование и переходя к российским реалиям хочется процитировать отчет
На текущий момент в России проникновение ИИ в задачи разработчиков происходит темпами, сопоставимыми с мировыми. Однако, на российском рынке, в отличие от мирового, проблемы и вызовы изменения жизненного цикла разработки под влиянием ИИ только начинают входить в приоритеты и фокусы технологических лидеров и тимлидов.
Эта цитата подкрепляется исследованием Руссофт от 2024 года, где опрос софтверных компаний показал, что 54,8% из них отметили, что они имеют экспертизу и опыт в области искусственного интеллекта и используют их в разработке новых заказных систем или собственных решений (эта чиселка отросла с 46,6% в 2023 году).
Авторы исследования дают оценку, что ИИ используют ~62% сотрудников ИТ‑команд (в 2 раза выше 2024), а к 2028 пороникновение будет ~98% (~3,22 млн пользователей). Я не смог источник, откуда взят этот прогноз (упоминается отчет Руссофта, приведенный выше, а также отчет T-Adviser про рынок труда).
Дальше авторы рассказывают про ландшафт AI инструментов в России и делятся оптимистичными цифрами
- Ассистенты разработчика: GigaCode (Сбер), Yandex Code Assistant / SourceCraft, МТС Kodify; DevSecOps: Safeliner (Т‑Банк)
- Публичные заявления о результатах применения этих инструментов навроде
-- GigaCode: до +28% к скорости разработки; −50% времени на регрессию; +30% скорость UI‑автотестов; 3× быстрее настройка конвейера; 2× быстрее онбординг DevOps;
-- 5× быстрее обработка ИБ‑уязвимостей в Safeliner от Т-Банка
-- Platform V Works (СберТех): −40% времени до прома в CI/CD; −50% времени на тестирование; +25% релизов; −20% трудозатрат
-- Альфа‑Банк: ИИ‑агенты‑тестировщики — −30% ошибок за счёт роста покрытия, до 70% быстрее генерация автотестов; масштаб на 60+ команд
Среди трендов авторы выделяют
- Встраивание AI в платформы разработки: IDE, CI/CD, DevSecOps и т.д
- Появление агентных сценариев - автогенерация тестов/кода, проведения код-ревью
- Изменение нормы эффективности и дальнейшее движение в стороны T‑shaped разработчиков
Интересно, что вызовами являются темы
- Измерений эффектов - меньше 25% компаний замеряют их, а те, кто измеряют ориентируются на TTM/Lead Time, дефекты на проде
- Регуляторика и риски качества недетерминированной работы LLM - ИБ/152‑ФЗ, качество LLM, контроль использования и «галлюцинаций»
Авторы исследования предлагают следующий план внедрения AI
- Выберите 1–2 узких сценария: юнит‑тесты, код‑ревью, ...
- Зафиксируйте базовые метрики: TTM, Lead Time, дефекты
- Примите политику ИБ: что можно/нельзя; on‑prem/cloud LLM для кода
- Встраивайте в платформу разработки/CI‑CD, а не кустарно сбоки
- Введите quality‑gate для AI‑кода% кодстайл, статанализ, обязательное ревью
- Создайте библиотеку промптов и обучите команду.
- Сравнивайте российские и зарубежные модели на своих задачах.
- Масштабируйте после 2–3 успешных пилотов с подтверждённым ROI.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
Telegram
Книжный куб
[1/2] Исследование AI в SDLC от IT One и Сколково (Рубрика #AI)
Недавно я был на презентации результатов исследования от IT One и Сколково, где участвовал в панельной дискуссии. Потом я взял это исследование и изучил все 59 страниц, в которых примерно следующая…
Недавно я был на презентации результатов исследования от IT One и Сколково, где участвовал в панельной дискуссии. Потом я взял это исследование и изучил все 59 страниц, в которых примерно следующая…
❤6👍4🔥2👎1
Сезон кода: Нижний Новгород (Рубрика #Engineering)
Сегодня вечером я уезжаю в Нижний Новгород, где планирую завтра потусить в офисе и пообщаться с коллегами, включая сессию вопросов и ответов, а в субботу загляну на наше мероприятие "Сезон кода", где будет плотная программа про надежность, масштабируемость и полезные инженерные практики. Так что если вы будете на этом событии, то можно будет попробовать найти меня. Правда, я еду в Нижний с семьей: женой и двумя младшими детьми, а значит в планах у меня не только сезон кода, куда я загляну всей семьей, но и более широкомасшабные прогулки по городу, в котором детишки еще не бывали.
#Engineering #Travel #ForKids
Сегодня вечером я уезжаю в Нижний Новгород, где планирую завтра потусить в офисе и пообщаться с коллегами, включая сессию вопросов и ответов, а в субботу загляну на наше мероприятие "Сезон кода", где будет плотная программа про надежность, масштабируемость и полезные инженерные практики. Так что если вы будете на этом событии, то можно будет попробовать найти меня. Правда, я еду в Нижний с семьей: женой и двумя младшими детьми, а значит в планах у меня не только сезон кода, куда я загляну всей семьей, но и более широкомасшабные прогулки по городу, в котором детишки еще не бывали.
#Engineering #Travel #ForKids
ИТ-события Т-Банка
Сезон кода: Нижний Новгород
Большой осенний фестиваль о технологиях. Ждем опытных специалистов в Java, Python, .NET и Data
❤4🔥3👍2
Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap (Рубрика #AI)
Недавно прочитал интересное продолжение whitepaper "Rethinking Software Engineering in the Foundation Model Era: From Task-Driven AI Copilots to Goal-Driven AI Pair Programmers", которую я уже разбирал. В новой статье те же авторы развивают идеи и рассказывают про Software Engineering 3.0, где текущий этап copilot и AI ассистентов они нумеруют SE 2.0 (они ускоряют работу, но создают когнитивный шум). На новом этапе разработка будет строиться вокруг намерений (intent-first). Условно, инженер говорит AI агенту, что нужно, а уже агент в формате диалога пишет код. Агент работает как напарник, обученный понимать цели и превращать их в работающую систему.
Авторы этой научной статьи выделяют пять составляющих новой экосистемы
- Teammate.next - AI-партнёр с «социальным интеллектом». Учится на диалогах, уточняет требования, помогает держать контекст.
- IDE.next - чат-среда вместо редактора. Код можно скрыть: внимание фокусируется на смысле, а не синтаксисе.
- Compiler.next - компилятор-агент, который не просто компилирует, а проверяет, совпадает ли результат с намерением и стандартами качества.
- Runtime.next - динамическая среда, оптимизирующая ресурсы для AI-сгенерированного кода, с учётом SLA и latency.
- FM.next — новое поколение foundation моделей: не обученных на шумных данных, а «воспитанных» через curriculum engineering – структурированное обучение инженерным знаниям
Авторы считают, что SE 3.0 будет работать лучше 2.0, так как в новой версии исчезает «шквал подсказок»: AI-партнёр сам агрегирует решения. Человек отвечает за смысл, машина — за механику. Вместе они снижают когнитивную нагрузку и ускоряют цикл разработки. Компилятор-агент проверяет качество, а knowledge-driven модели делают выводы не по шаблонам, а через понимание принципов. Авторы уверены: при целенаправленных исследованиях эти технологии приведут к новой эре разработки — более масштабируемой, надёжной и человеко-центричной. По мнению авторов мы стоим на пороге перехода от ремесла к наставничеству. Разработчик будущего не пишет код, а обучает ИИ-агента думать о системе, ставит задачи и проверяет результаты. Код превращается во вторичный артефакт — результат диалога человека и машины.
Интересно, что статья вышла осенью 2024 года, поэтому она предвосхитила хайп 2025 года вокруг AI агентов. В этом году концепция “agentic AI”, то есть AI-агентов, способных самостоятельно принимать решения, набирает популярность и рассматривается как следующий этап эволюции помощников для программистов. Аналитики прогнозируют, что эта тенденция уже в ближайшие годы подтолкнёт переход от простых AI-копилотов к полноценной AI-native разработке софта.
Собственно, авторы не стали скромничать и в сентябре этого года выпустили продолжение "Agentic Software Engineering: Foundational Pillars and a Research Roadmap" с таким описанием (заметим, что ключевые слова про агентский подход к разработке теперь указаны правильно )
Посмотрим, что будет дальше, но пока дейстительно кажется, что AI-агенты могут стать значительной вехой в разработке софта.
#AI #Software #Architecture #Agents #Leadership #ML #SystemDesign
Недавно прочитал интересное продолжение whitepaper "Rethinking Software Engineering in the Foundation Model Era: From Task-Driven AI Copilots to Goal-Driven AI Pair Programmers", которую я уже разбирал. В новой статье те же авторы развивают идеи и рассказывают про Software Engineering 3.0, где текущий этап copilot и AI ассистентов они нумеруют SE 2.0 (они ускоряют работу, но создают когнитивный шум). На новом этапе разработка будет строиться вокруг намерений (intent-first). Условно, инженер говорит AI агенту, что нужно, а уже агент в формате диалога пишет код. Агент работает как напарник, обученный понимать цели и превращать их в работающую систему.
Авторы этой научной статьи выделяют пять составляющих новой экосистемы
- Teammate.next - AI-партнёр с «социальным интеллектом». Учится на диалогах, уточняет требования, помогает держать контекст.
- IDE.next - чат-среда вместо редактора. Код можно скрыть: внимание фокусируется на смысле, а не синтаксисе.
- Compiler.next - компилятор-агент, который не просто компилирует, а проверяет, совпадает ли результат с намерением и стандартами качества.
- Runtime.next - динамическая среда, оптимизирующая ресурсы для AI-сгенерированного кода, с учётом SLA и latency.
- FM.next — новое поколение foundation моделей: не обученных на шумных данных, а «воспитанных» через curriculum engineering – структурированное обучение инженерным знаниям
Авторы считают, что SE 3.0 будет работать лучше 2.0, так как в новой версии исчезает «шквал подсказок»: AI-партнёр сам агрегирует решения. Человек отвечает за смысл, машина — за механику. Вместе они снижают когнитивную нагрузку и ускоряют цикл разработки. Компилятор-агент проверяет качество, а knowledge-driven модели делают выводы не по шаблонам, а через понимание принципов. Авторы уверены: при целенаправленных исследованиях эти технологии приведут к новой эре разработки — более масштабируемой, надёжной и человеко-центричной. По мнению авторов мы стоим на пороге перехода от ремесла к наставничеству. Разработчик будущего не пишет код, а обучает ИИ-агента думать о системе, ставит задачи и проверяет результаты. Код превращается во вторичный артефакт — результат диалога человека и машины.
Интересно, что статья вышла осенью 2024 года, поэтому она предвосхитила хайп 2025 года вокруг AI агентов. В этом году концепция “agentic AI”, то есть AI-агентов, способных самостоятельно принимать решения, набирает популярность и рассматривается как следующий этап эволюции помощников для программистов. Аналитики прогнозируют, что эта тенденция уже в ближайшие годы подтолкнёт переход от простых AI-копилотов к полноценной AI-native разработке софта.
Собственно, авторы не стали скромничать и в сентябре этого года выпустили продолжение "Agentic Software Engineering: Foundational Pillars and a Research Roadmap" с таким описанием (
Agentic Software Engineering (SE 3.0) represents a new era where intelligent agents are tasked not with simple code generation, but with achieving complex, goal-oriented SE objectives. To harness these new capabilities while ensuring trustworthiness, we must recognize a fundamental duality within the SE field in the Agentic SE era, comprising two symbiotic modalities: SE for Humans and SE for Agents.
Посмотрим, что будет дальше, но пока дейстительно кажется, что AI-агенты могут стать значительной вехой в разработке софта.
#AI #Software #Architecture #Agents #Leadership #ML #SystemDesign
arXiv.org
Towards AI-Native Software Engineering (SE 3.0): A Vision and a...
The rise of AI-assisted software engineering (SE 2.0), powered by Foundation Models (FMs) and FM-powered copilots, has shown promise in improving developer productivity. However, it has also...
❤6🔥6🥱4👍2👏1🥴1🤝1
Дискуссия — «GenAI и dev платформы – как меняется разработка» (Рубрика #AI)
На летнем IT Пикнике мой коллега Дима Гаевский вел дискуссию на эту тему, где участвовали уважаемые джентельмены
- Иван Пузыревский, CTO Yandex Cloud
- Александр Лукьянченко, руководитель разработки платформы в Авито
- Станислав Сычев, руководитель разработки платформы в Т-Банке
Ребята обсуждали следующие темы
1. Роль разработчика меняется
ИИ перестал быть только частью IDE. AI пишет код, предлагает оптимизации, генерирует тесты - а инженер становится ревьюером и архитектором решений, а не только исполнителем. Сильные инженеры теперь курируют и людей, и AI-агентов. Джуны растут быстрее - у них под рукой “AI-ассистент”, который подсказывает, как писать код.
Главный навык будущего - уметь ставить задачи ИИ и проверять результат, а не просто знать синтаксис языка.
2. AI становится частью платформ разработки
- Платформы (CI/CD, IDE, облака) интегрируют AI-помощников, которые анализируют код, собирают метрики, предлагают фиксы.
- AI-модели дообучаются на данных из внутренних репозиториев, понимают корпоративный стиль кода и стандарты.
Как итог: внутренние dev-платформы становятся “живыми системами”, где ИИ не только помогает людям, но и сам учится на их паттернах.
3. Автономность AI пока не так велика
- Ни один из участников не верит в «AI-разработчика без человека».
- Сейчас граница ясна: AI можно доверить рутину (генерацию шаблонов, тестов, фиксов), но не архитектуру и продакшен-код.
- Везде действует правило: «AI предлагает, инженер утверждает» (условно, есть human in the loop). Это связано со стоимостью ошибок
4. Новые роли и процессы
- Появляются новые профессии: AI-инженеры, промпт-дизайнеры, ревьюеры моделей.
- Некоторые частично детерминированные сценарии работают лучше: генерация тест-кейсов, юнит-тестов, агенты для код-ревью, миграции кода
- DevEx-платформы превращаются в экосистемы для людей и агентов: оба учатся на общих данных и повышают эффективность.
5. Что дальше
- AI-first-платформы станут стандартом: без встроенного помощника IDE или CI/CD скоро не обойтись.
- Команды станут меньше и междисциплинарнее - рутину берут машины, людям остаются дизайн, логика и ответственность за свою работу и работу AI-агентов
- AI-грамотность станет новой базовой компетенцией инженера.
- Появятся агентные среды, где несколько AI-сервисов будут решать задачу “от ТЗ до деплоя” под присмотром тимлида-человека.
Если подводить итоги, то ребята
- Не верят, что AI не заменит инженеров - скорее инженеры станут тимлидами команды AI-агентов
- Платформы разработки становятся умнее, интегрируя AI-возможности в себя
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
На летнем IT Пикнике мой коллега Дима Гаевский вел дискуссию на эту тему, где участвовали уважаемые джентельмены
- Иван Пузыревский, CTO Yandex Cloud
- Александр Лукьянченко, руководитель разработки платформы в Авито
- Станислав Сычев, руководитель разработки платформы в Т-Банке
Ребята обсуждали следующие темы
1. Роль разработчика меняется
ИИ перестал быть только частью IDE. AI пишет код, предлагает оптимизации, генерирует тесты - а инженер становится ревьюером и архитектором решений, а не только исполнителем. Сильные инженеры теперь курируют и людей, и AI-агентов. Джуны растут быстрее - у них под рукой “AI-ассистент”, который подсказывает, как писать код.
Главный навык будущего - уметь ставить задачи ИИ и проверять результат, а не просто знать синтаксис языка.
2. AI становится частью платформ разработки
- Платформы (CI/CD, IDE, облака) интегрируют AI-помощников, которые анализируют код, собирают метрики, предлагают фиксы.
- AI-модели дообучаются на данных из внутренних репозиториев, понимают корпоративный стиль кода и стандарты.
Как итог: внутренние dev-платформы становятся “живыми системами”, где ИИ не только помогает людям, но и сам учится на их паттернах.
3. Автономность AI пока не так велика
- Ни один из участников не верит в «AI-разработчика без человека».
- Сейчас граница ясна: AI можно доверить рутину (генерацию шаблонов, тестов, фиксов), но не архитектуру и продакшен-код.
- Везде действует правило: «AI предлагает, инженер утверждает» (условно, есть human in the loop). Это связано со стоимостью ошибок
4. Новые роли и процессы
- Появляются новые профессии: AI-инженеры, промпт-дизайнеры, ревьюеры моделей.
- Некоторые частично детерминированные сценарии работают лучше: генерация тест-кейсов, юнит-тестов, агенты для код-ревью, миграции кода
- DevEx-платформы превращаются в экосистемы для людей и агентов: оба учатся на общих данных и повышают эффективность.
5. Что дальше
- AI-first-платформы станут стандартом: без встроенного помощника IDE или CI/CD скоро не обойтись.
- Команды станут меньше и междисциплинарнее - рутину берут машины, людям остаются дизайн, логика и ответственность за свою работу и работу AI-агентов
- AI-грамотность станет новой базовой компетенцией инженера.
- Появятся агентные среды, где несколько AI-сервисов будут решать задачу “от ТЗ до деплоя” под присмотром тимлида-человека.
Если подводить итоги, то ребята
- Не верят, что AI не заменит инженеров - скорее инженеры станут тимлидами команды AI-агентов
- Платформы разработки становятся умнее, интегрируя AI-возможности в себя
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
YouTube
Дискуссия — «GenAI и dev платформы – как меняется разработка»
Gen AI уже не просто инструмент, он меняет роли в разработке: инженеры становятся ревьюерами AI, платформы — полигоном для обучения моделей, а код все чаще пишется без прямого участия человека. Но кто на самом деле принимает решения?
CTO платформ Яндекса…
CTO платформ Яндекса…
👍7❤5🔥3🥱2
Гуляя с семьей по парку Швейцария в Нижнем Новгороде, наткнулся на "Отель для книг" и "Отель для насекомых". Креативный тут подход у ребят:)
А чуть позже мы поедем на нашу конфу "Сезон кода".
А чуть позже мы поедем на нашу конфу "Сезон кода".
👍9❤6🔥4
Водоходъ (Рубрика #ForKids)
Решили прокатиться на кораблике в Нижнем Новгороде. Пришли вчера в кассы компании "Водоходъ" купить билеты, но их на вчера уже не было. Мы решил попробовать покататься сегодня и купили комфорт билеты на сайте Водоходъ. Пришли на посадку, но нам объяснили, что даже с билетами мы не покатаемся на кораблике. На сайте было указано, что для детей до 5 лет включительно билет нужен, но он бесплатный. Опции получить этот бесплатный билет на сайте не было и мы решили получить его в кассах. А в кассах нам сказали, что этот бесплатный билет для детей есть только в тарифе билетов стандарт, а в комфорт надо покупать билеты на всех (но на сайте этой инфы не было). Докупить билет мы не смогли - мест в комфорт не было. Сдать билеты на комфорт нормально тоже не получилось - в кассе сказали "где билет покупали, туда и идите", а на сайте Водохода предлагают заполнять документ и ножками приносить его в офис компании (или присылать письмом Почтой России). Классно, что у нас в Т-Банке есть возможность оспорить любую операцию, по которой не предоставили услугу.
Вывод: оплачивайте картами Т, чтобы иметь возможность оспорить оплату у таких "водоходов".
Решили прокатиться на кораблике в Нижнем Новгороде. Пришли вчера в кассы компании "Водоходъ" купить билеты, но их на вчера уже не было. Мы решил попробовать покататься сегодня и купили комфорт билеты на сайте Водоходъ. Пришли на посадку, но нам объяснили, что даже с билетами мы не покатаемся на кораблике. На сайте было указано, что для детей до 5 лет включительно билет нужен, но он бесплатный. Опции получить этот бесплатный билет на сайте не было и мы решили получить его в кассах. А в кассах нам сказали, что этот бесплатный билет для детей есть только в тарифе билетов стандарт, а в комфорт надо покупать билеты на всех (но на сайте этой инфы не было). Докупить билет мы не смогли - мест в комфорт не было. Сдать билеты на комфорт нормально тоже не получилось - в кассе сказали "где билет покупали, туда и идите", а на сайте Водохода предлагают заполнять документ и ножками приносить его в офис компании (или присылать письмом Почтой России). Классно, что у нас в Т-Банке есть возможность оспорить любую операцию, по которой не предоставили услугу.
Вывод: оплачивайте картами Т, чтобы иметь возможность оспорить оплату у таких "водоходов".
vodohod-nn.ru
Речные прогулки в Нижнем Новгороде | Теплоходы и экскурсии - ВодоходЪ
Откройте лучшие речные прогулки по Волге в Нижнем Новгороде с компанией ВодоходЪ. Увлекательные экскурсии, комфортные теплоходы и незабываемые впечатления. Забронируйте билеты онлайн!
😢24😁5👍3👎1
Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering)
Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем
- Введение и представление гостя
- Детство, образование и первые шаги в IT
- Работа в «Одноклассниках»: начало карьеры
- Инцидент в ОК и переосмысление надежности
- Переход к системной надежности
- Работа с Cassandra и автоматизация процессов
- Новые технологии и взаимодействие команд
- Миграция дата-центра: проект и организация
- Уход из «Одноклассников»
- Первые шаги с Cassandra в новой роли
- Развитие Cassandra как сервиса в Т-Банке
- Проблемы архитектуры и декомпозиции кода
- Практические выводы и преимущества Cassandra
- Рекомендации инженерам по поводу развития и роста
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems
Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем
- Введение и представление гостя
- Детство, образование и первые шаги в IT
- Работа в «Одноклассниках»: начало карьеры
- Инцидент в ОК и переосмысление надежности
- Переход к системной надежности
- Работа с Cassandra и автоматизация процессов
- Новые технологии и взаимодействие команд
- Миграция дата-центра: проект и организация
- Уход из «Одноклассников»
- Первые шаги с Cassandra в новой роли
- Развитие Cassandra как сервиса в Т-Банке
- Проблемы архитектуры и декомпозиции кода
- Практические выводы и преимущества Cassandra
- Рекомендации инженерам по поводу развития и роста
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems
YouTube
Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases
Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал…
👍8🔥7❤4
Жемчужины программирования (Рубрика #Engineering)
Первое издание этой книги Джона Бентли вышло почти 40 лет назад, как раз в год моего рождения. Но я читал уже второе издание, что вышло в начале 2000х годов. Это была книга, которая отличалась от других - она учила думать как инженер, а не просто писать код. Автор книги - исследователь из Bell Labs и Carnegie Mellon, соавтор алгоритма k-d деревьев и усовершенствованного quicksort. Но известен он больше колонкой в журнале "Communications of the ACM", из которой выросла эта книга. Это было в 1980-х годах, эпохе, когда 1 МБ памяти считался роскошью. Бентли писал для практиков, которые хотели не просто “работающий код”, а *красивое решение*. Он сравнивал алгоритм с жемчужиной: реальная проблема - это песчинка раздражения, а изящное решение - результат терпения и формы.
Каждая глава - это короткое эссе с задачей, размышлением и выводом. Они покрывают следующие темы
- Как формулировать задачу и искать ага!-решение;
- Оценка на салфетке, где автор рассказывает про оценку времени и памяти алгоритмов буквально на пальцах;
- Алгоритмические трюки: сортировка, выборка, поиск, оптимизация;
- Как писать корректные и понятные программы.
Интересно, что Бентли написал еще и книгу продолжение "More Programming Pearls", где он добавил следующие темы
- Философия инженерного мышления (“исповеди кодера”);
- Маленькие языки - предтечи DSL и скриптов внутри систем;
- Афоризмы и практические советы вроде “плохую программу ухудшить не грех”.
Если говорить про значимость книги в далекие времена, то автор в ней показал, что программирование - это не набор трюков, а искусство видеть структуру задачи. Когда-то книгу использовали в курсах по алгоритмам и дизайну программ. Сейчас большинство примеров устарело, но подход - нет.
В итоге, книги Джона Бентли по праву считаются сокровищницей знаний для программистов. Они объединяют поколение инженеров 1980-х и современных разработчиков общими ценностями - страстью к изящным решениям и глубокому пониманию задач. «Жемчужины программирования» до сих пор сияют и продолжают вдохновлять новых читателей на поиск красоты в коде.
#Engineering #Software #Architecture #SystemDesign
Первое издание этой книги Джона Бентли вышло почти 40 лет назад, как раз в год моего рождения. Но я читал уже второе издание, что вышло в начале 2000х годов. Это была книга, которая отличалась от других - она учила думать как инженер, а не просто писать код. Автор книги - исследователь из Bell Labs и Carnegie Mellon, соавтор алгоритма k-d деревьев и усовершенствованного quicksort. Но известен он больше колонкой в журнале "Communications of the ACM", из которой выросла эта книга. Это было в 1980-х годах, эпохе, когда 1 МБ памяти считался роскошью. Бентли писал для практиков, которые хотели не просто “работающий код”, а *красивое решение*. Он сравнивал алгоритм с жемчужиной: реальная проблема - это песчинка раздражения, а изящное решение - результат терпения и формы.
Каждая глава - это короткое эссе с задачей, размышлением и выводом. Они покрывают следующие темы
- Как формулировать задачу и искать ага!-решение;
- Оценка на салфетке, где автор рассказывает про оценку времени и памяти алгоритмов буквально на пальцах;
- Алгоритмические трюки: сортировка, выборка, поиск, оптимизация;
- Как писать корректные и понятные программы.
Интересно, что Бентли написал еще и книгу продолжение "More Programming Pearls", где он добавил следующие темы
- Философия инженерного мышления (“исповеди кодера”);
- Маленькие языки - предтечи DSL и скриптов внутри систем;
- Афоризмы и практические советы вроде “плохую программу ухудшить не грех”.
Если говорить про значимость книги в далекие времена, то автор в ней показал, что программирование - это не набор трюков, а искусство видеть структуру задачи. Когда-то книгу использовали в курсах по алгоритмам и дизайну программ. Сейчас большинство примеров устарело, но подход - нет.
В итоге, книги Джона Бентли по праву считаются сокровищницей знаний для программистов. Они объединяют поколение инженеров 1980-х и современных разработчиков общими ценностями - страстью к изящным решениям и глубокому пониманию задач. «Жемчужины программирования» до сих пор сияют и продолжают вдохновлять новых читателей на поиск красоты в коде.
#Engineering #Software #Architecture #SystemDesign
👍18❤10🔥6