Marat @ Predictable.Team

➿ Запускаю The Human Loop.

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

Первый выпуск — про то, почему команды сопротивляются AI.

Обычно это объясняют слишком просто: «люди боятся нового», «надо провести обучение», «надо сильнее продавить внедрение».

🏛 Но сопротивление чаще оказывается не проблемой людей, а диагностикой системы работы. За ним могут стоять разные причины:

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

🔍 В тексте разбираю 6 источников сопротивления, 5 позиций людей, диагностику, чеклист внедрения и Карту сопротивления AI.

🎥 А 23 июля в 19:00 разберем эту тему голосом на вебинаре Agile Ufa: «6 причин, почему команды сопротивляются внедрению AI в работу».

Зарегистрироваться можно на Timepad.

🗞 Последние новости из AI в менеджменте, эффективности команд и изменениях я продолжаю выкладывать в своем канале Predictable Team.

💼 Наконец выкатили на Хабр кейс моего подразделения про внедрение ИИ и ускорение доставки через агентскую разработку.

Главный вывод довольно быстро оказался неприятным, но полезным: рост использования AI сам по себе не равен ускорению разработки. Можно вырастить использование инструментов, но не сдвинуть скорость доставки, потому что локальная оптимизация одной роли не ускоряет систему целиком.

Поэтому, если цель — не просто раздать всем LLM, а радикально ускорить скорость доставки продукта до клиента, то идти нужно в agentic engineering. Это уже про перестройку самого контура поставки: когда агенты помогают двигать задачу через весь поток, а не улучшают один отдельный шаг.

А реальность такова: ограничения лежат не только в инструментах, а в валидации, смежниках, бизнес-контексте и неравномерности изменений по ролям.

Поэтому финальный вопрос всегда один и тот же: как построить систему метрик, которая показывает не adoption ради adoption, а реальное изменение потока.

В нашем случае это
- Usage-метрики
- Процессные метрики (Lead Time, Throughput)
- Балансирующие (Defect Rate, Availability)

📰 Посты на хабре:
- Часть 1 - Почему рост использования AI не равен ускорению разработки
- Часть 2 - Почему радикально ускорить delivery можно только через agentic engineering

🎁 А на следующей неделе нас ждет целый ресерч: почему команды в принципе сопротивляются внедрению ИИ и что с этим делать + вебинар по этой теме + воркшоп

📚 У меня в коворкинге (кстати у нас акция - в июле всего 10к в месяц) есть своя полочка с книгами в быстром доступе.

И вот кто-то туда добавляет какие-то левые книжки.
Как думаете, какие? 🫣

- ❤️ добавили левые книжки по продуктам и процессам
- 😱 по связи с потусторонним миром
- 🗿по инфоцыганству

☝🏽 Кстати говоря, Гибкое тестирование и связь с потусторонним миров - вода водой.

💹 Ну что, начали уже считать во сколько вам обходится ИИ и есть ли возврат инвестиций?

Чем глубже я погружаюсь в пучины подсчёта эффекта от внедрения AI в разработке, тем чаще напарываюсь на интересные отчёты и мнения в индустрии. И иногда хочется сказать "а я ж говорил!".

Вот, например, важная мысль из DORA / Google Cloud:

AI ROI плохо считается по формуле: «разработчик сэкономил 20% времени → можно сократить 20% команды».

Разработчик быстрее написал boilerplate, тест или pull request. Дальше задача всё равно идёт через аналитику, ревью, тестирование, согласования, релиз, безопасность и бизнес-валидацию. Если узкое место живёт там, локальная экономия времени просто растворяется в очереди.

📰 DORA / Google Cloud в отчёте про ROI of AI-Assisted Software Development предлагает смотреть на AI через всю систему доставки, без фантазии про мгновенное сокращение FTE. Главный вопрос звучит так: какое ограничение в потоке работы AI помог снять?

Например:
- разработчик быстрее находит нужный контекст;
- меньше ручной рутины при подготовке кода;
- проще писать тесты и документацию;
- быстрее разбираются инциденты;
- меньше переделок после ревью;
- высвободившаяся capacity уходит в техдолг, качество, безопасность, discovery-процессы.
Вот здесь начинает появляться реальный ROI.

В отчёте DORA есть кейс для инженерной организации на 500 человек:
• инвестиции за первый год: $8.4M
• возврат за первый год: $11.6M
• ROI: 39% - вернулось: за около 8 месяцев.

📎 InfoQ хорошо пересказывает эту модель и подчёркивает главный тезис DORA: ценность AI определяется не количеством написанного кода. Важнее, какие узкие места он помогает убрать. Это история про организацию, которая смогла встроить AI в delivery-систему: снять ограничения, снизить переделку работы, усилить инженерные практики и переиспользовать высвободившуюся мощность.

💭 Самая важная мысль DORA: AI усиливает систему, в которую попадает. В DORA State of AI-assisted Software Development 2025 это хорошо видно: эффект AI зависит от инструмента, платформы, практик, данных, процессов, доверия и всей инженерной среды.

Если есть нормальная внутренняя платформа и культурный стержень (это и тесты, CI/CD, понятные правила, доступ к внутренним данным и здоровые инженерные практики) — ИИ ускоряет поток работы. Если система уже живёт в хаосе, AI добавит больше кода, больше ревью, больше проверки и больше недоверия к результату.

Короче, считать и смотреть надо на то:

- где сократился Lead Time;
- где уменьшился rework;
- где снизилась стоимость проверки;
- где вырос throughput без просадки качества;
- куда команда переинвестировала высвободившуюся capacity;
- какие бизнес-результаты стали появляться быстрее.

ИИ ROI начинается с вопроса: какое узкое место нашей системы теперь проходит быстрее?

Больше про работу с командами и внедрение ИИ в инженерку в блоге Марата Киньябулатова predictable.team

People Sense 26' отгремела - а мысли не утихают.

Человеки - это сложно и запутанно!

Побывал на воркшопе Сережи и Никиты про команду как объект управления. И у меня сильно срезонировало то, к каким выводам ребята приводят через цепочку активностей.

✍️ Большинство руководителей работают с людьми в команде, а не с командой. 1-1, индивидуальные цели, 360-review — всё это инструменты работы с отдельными людьми. Команда — это другой объект. Не сумма людей, а отдельная сущность со своей динамикой, своим «иммунитетом» и своими болезнями.

На воркшопе это показали через симуляцию: вот команда на этапе Storming, вот дедлайн, вот набор техник-карточек — выбирай. И сразу видно последствия: прошёл квартал, расхлёбывай. Никакого «правильного ответа» — только контекст, люди и твоё понимание динамики.

🎓 Мне это сильно откликается: на работе я один из тренеров программы для инженерных менеджеров. И у меня есть похожий раздел — про то, что эффективная команда — это пересечение трёх вещей: достижение целей, метрики и вовлечённость. И там тоже карточки техник, тоже паттерны и разные варианты развития событий. Ведь что единственного правильного пути нет. Есть только понимание, на каком этапе твоя команда и что сейчас реально поможет.

☝️ К чему это я?

- Во-первых, работа с людьми и группами людей — это много контекста и отсутствие единственно правильног
о пути.
- Во-вторых, чтобы не считать себя самозванцем, круто делиться кейсами с коллегами по цеху и нарабатывать коллективн
ый опыт.
- В-третьих, People Sense — пока единственная конференция, на которой можно потрещать как на тему работы с командами, так и на тему производительности GPU Huawei Ascend для инференса (привет ребятам с Selectel ;). И всё это, внимание, 🔥 вечером у костра в суперуютной атмосфере. Такого я пока ещё нигде не видел.

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

➡️ Папка «После сцены PeopleSense’26»

В конце мая мы с @listl и @aigizk провели в Уфе первый митап 🇷🇺 Bash Agentic Engineering.
Вадим — Team Lead, основатель Ufa .NET. Айгиз — MLOps и автор башкирской умной колонки Homai.

Идея проросла весьма органично: в нашем коворкинге давно собирается сильная ИТ-тусовка, а с приходом AI мы все чаще обсуждали кодинг-агентов, LLM и мультиагентную разработку. В какой-то момент стало понятно — пора выносить это в открытый формат.

На митапе дали минимум теории, а потом сразу ушли в практику. Разбирали реальные кейсы обработки жалоб ЖКХ: сначала ручной режим, потом - работа через чат с LLM и затем агентный сценарий с Playwright CLI. Параллельно показали benchmark-driven подход, harness вокруг LLM и автономных агентов для проверки качества ответов.

Самое классное — после митапа люди не разошлись: остались обсуждать, спорить и делиться своими кейсами. Пришли разработчики, аналитики, тестировщики, исследователи, предприниматели и инвесторы.

Будем делать еще. Уфе точно нужно больше AI-движухи, больше практики и больше людей, которые не просто читают про агентов, а реально пробуют это руками.

И да: несмотря на просьбу заранее настроить Codex, все равно пришлось делиться подпиской на z.ai 🙂

#AI #AgenticEngineering #LLM #Ufa #BashAgenticEngineering

Как идти к Agentic Engineering, когда оргструктуру команды трогать нельзя

Красивый образ AI-native команды обычно такой: 2–3 человека, полная E2E-ответственность, агенты забирают рутину, команда быстро доводит идею до production.

На слайде выглядит отлично. Фигушки. 🙅

В большой организации этот слайд сразу начинает конфликтовать с годовыми целями, бюджетами, стратегическими проектами, административными контурами и уже собранной структурой команд. Пересобрать всё ради новой модели работы редко получается быстро. Да и, возможно, это не самый оптимальный путь — просто вокруг него сейчас больше всего хайпа.

🥦 Поэтому я всё больше верю в органичный путь, специфичный для контекста команды. Один подход на все команды не натянешь.

Команде нужен путь, где одновременно растут два навыка:

- люди понимают E2E-специфику работы целиком, включая соседние зоны;
- люди умеют работать с агентами как с нормальной частью инженерного процесса.

Без этого Agentic Engineering быстро превращается в красивую демку, после которой человек вручную проверяет всё, что агент нагенерил, и едет кукухой от невозможности это поддерживать.

___

🗿 Путь 1. Агентизировать нудный run-процесс

Берём рутину. Лучше жирную, скучную, местами недетерминированную.

Это может быть новый процесс. Ещё лучше — уже автоматизированный. Девопсы обычно знают его «особенности»: где падает, где нужна ручная проверка, где живут исключения.

Сначала один человек собирает агента вокруг этого процесса. Потом подключаем второго: показываем, как делали, и просим агентизировать ещё один процесс. Потом вовлекаем третьего.

Ценность простая: команда набивает руку там, где риск ниже. Рутины становится меньше, появляется место для change-работы и экспериментов.

🤩 В таком режиме примерно за полгода половина команды начинает нормально пользоваться кодинг-агентами.

___

💪 Путь 2. Оставить команду как есть и выделить 2–3 человека в режим “look ma, no hands”

Мам, смотри, я без рук.

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

Внутри неё 2–3 человека берут правило: задачи проходят через агентов. Руками формируем фреймворк работы: рамку, проверку, финальное решение и места, где без человека пока никак.

Через первый месяц эти люди обычно начинают делиться находками с остальными «сослуживцами»: промптами, скилами, способами декомпозиции, проверки, отладки, работы с легаси.

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

🤩 В нашем опыте за 3–6 месяцев 70–80% команды уже активно используют кодинг-агентов и примерно понимают, как их готовить.

___

🔬 Путь 3. Разделить команду на микро-юниты внутри той же оргструктуры

Команда из 15 человек может остаться одной командой на бумаге. Внутри появляются маленькие кросс-функциональные юниты по 2–3 человека.

Статические или динамические — зависит от контекста. Важнее другое: работу берёт юнит, не вся команда целиком и не один человек отдельно.

Сразу проявляется дефицит специальностей. Аналитиков и тестировщиков обычно меньше, чем разработчиков. Людям приходится чаще работать вместе: mob programming, swarming, быстрые синхронизации, совместная проверка результата.

Вот здесь и растёт E2E-понимание.
Разработчик видит аналитику. Аналитик видит инженерные ограничения. Тестировщик наконец-то попадает в процесс создания ценности раньше — не в момент, когда реализация уже готова и её надо только проверить.

Агент становится общим инструментом юнита.

🤩 В нашем опыте за пару месяцев почти вся команда начинает активно пользоваться кодинг-агентами и лучше понимает полный путь задачи.

___

Короче: если цель — сокращать время реализации с помощью AI, начинать стоит с условий для практики.

Prosci в AI Adoption Guide 2026 называет четыре главные причины сопротивления AI.

Потихоньку закрываю темы, которые не успеваю озвучить на конференциях.

Исходя из новостей о стремительной замене людей ИИ-агентами думаешь: там страх увольнений, безопасность и недоверие к качеству моделей.

В отчёте причины лежат ближе к обычному рабочему дню:

1. человек не понимает, зачем это лично ему;
2. боится неизвестности и неловкости;
3. не знает, как начать;
4. чувствует, что его исключили из решения.

В нашей практике картина почти совпала.

Дали доступ всем — пришли единицы. Провели вебинары — люди послушали и вернулись к обычной работе. Сделали реестр инструментов — он стал ещё одной ссылкой, которую никто сам не открывает.

После этого фокус сместился с доступа к первому рабочему опыту.

🧩 1. Личная польза появляется на живой задаче

Для инженера (это любой сотрудник айти-команды) «AI-стратегия» слишком далека от реальной задачи. А уж как она далека линейным сотрудникам - думаю не надо и описывать :) Лучше работает конкретика: 30 boilerplate-классов за 2 минуты (не спрашивайте, зачем это надо), тест-кейсы по реальному тикету, разбор старого модуля перед задачей.

Практика: Это как научить рыбачить, вместо того чтобы сразу кормить. Примеры и выгоду показываем типовые для нужной когорты людей (ведь у всех ролей разные запросы), связанный с конкретными и рутинными задачами.

⛑ 2. Первый опыт должен быть безопасным

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

В посте выше есть формат воркшопа и хакатона, которые тут помогут. Но пререквизит к этому: обязательно упростите установку кодинг-агента + доступов + нужных инструментов и mcp. В идеале shell-скриптом. А для сотрудников на винде сразу закажите админские роли. А для сотрудников на VDI - проработайте решение с безопасниками.

🎢 3. Первый маршрут лучше собрать заранее

Одна команда установки. Готовый сценарий запуска. Пример на реальном тикете. Понятные ограничения. Чеклист проверки результата.

Человек должен быстро дойти до первого маленького успеха.

Практика: Даем примеры, которые можно решить (чтоб не разочаровать, если пример не решится). Прогоняем воркшоп на подопытных, чтобы отловить типичные проблемы на каждом шаге. Не грузим кучей теории

🧠 4. Практика приживается, когда команда собирает её сама

QA собирают свои сценарии. Аналитики описывают свои артефакты. Разработчики формируют скилы для кода и ревью. Техлид показывает пример на собственной работе. Продакт учится самостоятельно делать прототипы.

Так AI становится темой нормального инженерного разговора: какие задачи отдаём агенту, где держим стандарт, где финальное решение остаётся за человеком.

Сопротивление AI часто начинается с нормальных вопросов команды.

Практика: Мы в обучении и вовлечении даем самый минимум. Скелет, фреймворк для использования. Когда у людей есть желание улучшаться (а в agile мы его воспитываем ретроспективами и культурой непрерывного развития) - при необходимых инструментах они сами учатся оптимизироваться. Важно создать среду для поддержки подобных благих намерений.

💅 Короче говоря: Хорошее внедрение даёт человеку первый маленький результат — и право попробовать самому.

Больше про работу с командами и внедрение ИИ в инженерку в блоге Марата Киньябулатова predictable.team

🤝 Всем привет, сегодняшняя презентация с People Sense - мы обсуждали проблемы перехода в Agentic Engineering.

Мы, вероятно, не успели покрыть темы:

- топ причин сопротивления внедрению ИИ в организациях;
- почему ИИ может привести к тому, что ваша компания станет Feature Factory на стероидах;
- как двигаться в сторону AI Adoption и Agentic engineering - если вы не готовы менять структуру команды.

Про все эти три темы будут отдельные посты.

Дополнительные материалы в этом посте

Или мне в личной телеге

🤖 Маленькие AI-команды, которые радикально меняют SDLC это гипотеза, которая апробируется. А не аксиома, как многие сейчас думают.

Я очень много слышу (и сам привожу примеры) о том, как AI двигает нас к микро-командам из 2-3-4 человек вместо 7+- 2 (по разным причинам: например сокращение координационной цепочки).

🚀 Кейсы, которые у всех на слуху: как строили Sora for Android в 4 человека, 28 дней, #1 в Google Play — это все кейсы от OpenAI и Anthropic. То есть компании, которые сами строят AI-инструменты, их продают, и сами же ими пользуются.

И почему-то когда мы приводим их в пример, мы забываем что там нет legacy, нет трёх уровней согласований, самый ранний доступ к моделям и инфраструктуре. Потом еще можно вспомнить uptime сервисов Anthropic (он невысокий) и понять, что они-то на стадии роста могут им жертвовать (а я в финтехе - не могу).

Это важный контекст, если думаешь о переносе паттерна в свою компанию.

🐻 Большинство компаний в 2026-м осторожно движутся к небольшим, измеримым AI-проектам (а не оголтелому перенарезанию оргструктуры). Прирост продуктивности на уровне задач, когда ты выстраиваешь агентский SDLC вокруг конкретного бизнес процесса реальный (15–40%). А вот конвертация этого в результат на уровне всей компании — отдельная работа, которая зависит от структуры, legacy и культуры в самой организации. Потому что ускорив одну команду, ты тупо упрешся в соседние.

Где точно круто работают микрокоманды - это прототипирование через vibe coding. Путь же от прототипа до прода — это тесты, security, observability, CI/CD, feature флаги, рефакторинг. И это все упирается в правильную обвязку, а выстроить ее - это понимать и исповедовать инженерную культуру.

🚵‍♀️ Третий год мы зачеркиваем предыдущие подходы: prompt engineering → context engineering → и вот сейчас harness engineering: проектирование сред, ограничения, циклы обратной связи, жизненный цикл агентов. OpenAI в феврале 2026-го написали, что их самые сложные задачи теперь именно здесь — в проектировании среды для агентов.

Когда harness engineering перечеркнем, интересно?

Короче говоря, команды из 2–4 человек работают в специфических условиях: greenfield, автономия, senior-состав, нет legacy. Это живой эксперимент, результаты которого ещё накапливаются. А работают ли они на масштабе в других средах: brownfield, зарегулированных и отчетных - это пока еще вопрос.

❓ Есть ли у вас примеры того, как микро-команды работают или не работают

🚫🐞 Zero Bug Policy: как мы сократили бэклог багов в 4 раза

- Уменьшили бэклог с 77 → 18 багов за месяц.
- 80% всех багов - с датами фиксов, которые сбываются.
- Разбор всех новых багов в течение 2 дней.

📝 Контекст

Кейс с прошлой работы: в MetaMap мы быстро росли. Команд добавлялось, фичей становилось больше, клиентская база расширялась. Бэклог багов рос - 77 открытых, у 60 ни сроков, ни ответственного.

Приоритизировали хаотично:
- кто громче кричит,
- у какого клиента больше ARR,
- насколько панически звучит запрос 😅.

Поддержка не могла обещать клиентам конкретики. Разработка откладывала баги из спринта в спринт (знакомо?). Дефект попадал в бэклог и пропадал куда-то за горизонт событий черной дыры.

⚙ Что сделали

Ввели Zero Bug Policy. Три правила:

• Critical — production down, data loss, security breach. Бросаем всё, чиним сейчас
• Moderate — следующий спринт, 30% capacity
• Low багов нет — мы их сразу закрываем и информируем, почему не будем чинить
• Баг висит > 2 спринтов — останавливаем фичи, разбираемся с долгом

High / Major нет принципиально. Оставили только три уровня

Каждому багу — Due Date или хотя бы «дата, когда мы назовём дату».

Результат

Через месяц: 77 → 18. Поддержка впервые стала говорить клиентам «исправим тогда-то» — и сдерживала слово. Доверие между отделами и пользователями восстановилось.

Наконец-то собрал этот опыт в полноценный пост на Хабре — с механикой, SLA и тем, как это работает на практике. А также как это дело интегрировать в вашу компанию.

Всем бодрого понедельника!

📣 На следующей неделе выступаю на People Sense (в Москве и онлайн) про Agentic Engineering (когда агенты делают за вас всю работу). А именно:

- Как сокращать время на разработку с помощью Agentic Engineering,
- Что такое AI-first команда,
- Почему всем это не подходит,
- Как трансформируются роли в команде при переходе в Agentic Engineering

🗞 Последние два месяца у нас была куча экспериментов, из которых я раскрою:

- Какие первые метрики для измерения эффектов от внедрения ИИ можно поставить в инженерных командах,
- Почему, несмотря на все ускорение команд мы все еще можем сталкиваться отсутствием системных изменений,
- Какие челленджи нам припасли руководители команд и почему все упирается в них.

Буду рад увидеть всех. Если есть какие-то конкретные вопросы, можно кидать их в комменты :)

👉 Регистрация по ссылочке 👈

Всем хорошей рабочей недельки (а жителям 🗺 Башкортостана - хорошей сокращенной рабочей недельки)

🔫 AI-агент удалил базу данных за 9 секунд. А потом написал явку с повинной.

Пока готовлю большой материал по Zero Bugs Policy, сравниваю OpenClaw vs Hermes, бенчмаркаю аналог Deep Research и судорожно перед отпуском готовлюсь к People Sense (буду рассказывать про челленджи AI-native команд) почитываю в фоне новостные дайджесты. В очередной раз поржал:

В апреле стартап PocketOS попросил Cursor с Claude помочь с рутинной задачей. Агент нашёл в соседнем файле production-токен, решил «заодно всё поправить» — и за 9 секунд снёс всю базу данных вместе с бэкапами. 30+ часов даунтайма. Клиенты приходили забирать арендованные машины — данных нет.

Когда основатель спросил, что произошло, Claude ответил: «Я нарушил каждый принцип, который мне дали. Я угадывал вместо того, чтобы проверять. Я выполнил деструктивное действие, которого меня никто не просил».

Инженеры из Railway назвали это vibe deletion — по аналогии с vibe coding.

🎲 Когда работаешь на ощущениях, без guardrails (системы ограничений) и least privilege (у агента минимум прав) — иногда получаешь фичу, иногда 30-часовой даунтайм. И это не единственный случай: за 8 месяцев таких инцидентов уже семь (и назвали это production destruction pattern).

Хорошая пятница, чтобы проверить: а ваш агент сейчас чем занимается? Роняли прод агентами на работе?


Я вот в энтерпрайзе пока придерживаюсь позиции на пушечный выстрел к деплоям не подпускать агентов.

🚀 Парадокс 2026 года: мы стали писать код быстрее, но качество летит в пропасть

Каждую неделю у меня по расписанию агент подкидывает все последние новости из AI + SDLC + Management исследований. Сегодня поделюсь отчетом от Faros AI: я наблюдаю очень похожие выводы на своем масштабе - а тут они подтверждаются сильнее). Отчет приложил.

Вышел мощный отчёт Faros AI, основанный не на опросах в духе «как вам кажется?», а на суровой телеметрии 22 000 разработчиков. Аналитики назвали новый феномен «Acceleration Whiplash» (травма хлыстом от ускорения).

Суть: ИИ-инструменты (Copilot, Cursor, Claude Code и другие) позволяют двигать роудмапы, но при этом ломают на части процессы ревью и тестирования. Наш старый процесс просто не рассчитан на новую скорость генерации кода (раз, два).

📈 Что хорошего в отчете про ИИ (где AI реально ускоряет):

- Закрытых эпиков на разработчика: +66%
- Количество закрытых задач (throughput): +34%

📉 Где скрыта боль (тот самый Whiplash):

- Количество багов на разработчика: +54%
- Инциденты на один PR: +242% (каждый мёрдж стал почти втрое опаснее!)
- Средний размер PR вырос на 51%
- Время ревью одного PR увеличилось в 5 раз

🧠 Почему так происходит?

ИИ отлично генерирует код, но не понимает ваш архитектурный контекст. Инженер быстро (если долго смотреть станет плохо) принимает сгенерированный блок и отправляет его дальше. Главный защитный механизм индустрии — «маленькие PR до 400 строк» — сейчас сломан.

На ревьюера падает огромный кусок логики. Его когнитивная нагрузка зашкаливает (об этом я говорил на докладе на прошлой неделе). Итог: на 31% выросла доля PR, которые мёрджатся вообще без содержательного ревью (просто не глядя).

🛠 Что с этим делать тимлидам и руководителям?

1. Верните жёсткие лимиты на размер PR

Исследования (в т.ч. от Microsoft) показывают: PR больше 400 строк ревьюить бесполезно, мозг переходит в режим слепого скроллинга. Вшивайте в обвязку (agent harness) автоматические гайды и алерты на огромные многофайловые коммиты от ИИ.

2. Меняйте метрики.

«Строки кода» и «количество PR» больше ничего не значат (AI легко их накрутит). Смотрите на Code Churn (сколько строк пришлось удалить/переписать после мёрджа) и Incidents per PR (ошибок на PR - и аварий, и багов).

3. Инженеры-люди нужны как никогда.

Сокращать штат с мыслью «AI напишет код за них» — фатальная ошибка. Вам нужны сильные (senior) инженеры именно как надёжный буфер на код-ревью между ИИ-генератором и вашим продакшеном. Именно такие синьоры, которые умеют выстроить систему, которая будет справляться (качественно) с новым объемем артефектов от агентов.

В 2026 году выигрывает не та команда, которая генерирует больше кода, а та, которая смогла перестроить пайплайны ревью под эти сумасшедшие объёмы - заключает исследование

👍 Больше про системную работу с эффективностью команд + AI в блоге Марата Киньябулатова про предсказуемые команды

Привет старичкам и всем новичкам ♥️

Преза с выступления сегодня на DUMP (о чем она - пост выше).

📚 Доп. материалы:

• Мысли вслух: Как AI-агенты меняют процесс разработки в разных типах проектов (Хабр)

• ИИ-ассистенты не ломают поддерживаемость кода. Но есть нюансы (выжимка из исследования Echoes of AI) (Хабр)

• Что такое ADKAR. - фреймворк управления изменениями в организациях

• Серия постов про внедрение AI (цель, изменения, мероприятия, события, ограничения)

- Изменение роли QA в эпоху ИИ

- Что такое эффективная команда и как на это смотреть на масштабе

🤖 Почему внедрение ИИ не делает разработку быстрее? Наш опыт на масштабе моего подразделения (500 человек)

Все ждут, что AI автоматически ускорит Time-to-Market, но на практике всё гораздо сложнее. Мы проверили три гипотезы ускорения Lead Time (LT) с помощью ИИ на 500 инженерах, и ни одна не сработала так, как ожидалось.

Вот как эволюционировал наш подход:

❌ Гипотеза 1: Дать доступ к LLM = ускорить работу
Мы просто раздали доступы и получили красивый рост использования (MAU) до 50%, но Lead Time не сдвинулся. Оказалось, что использование ИИ в формате чата — это просто «туризм» без формирования привычки. Люди ситуативно играются, но барьер для применения ИИ непосредственно в написании кода остается огромным.

❌ Гипотеза 2: Обучить кодингу через агенты = ускорить работу
Поняв ошибки, мы применили фреймворк изменений ADKAR: заменили рассылки на воркшопы и добились того, что 40% инженеров стали регулярно использовать API агентов. Разработчики стали быстрее писать код, но метрика Lead Time снова не сдвинулась.
Причина: Локальная оптимизация. Мы ускорили только одно звено, но общее время ожидания аналитики и тестирования осталось прежним, поэтому вся цепь не ускорилась.

❌ Гипотеза 3: Agentic Engineering (ИИ забирает весь цикл)
В пилоте 2 разработчика с помощью ИИ взяли на себя e2e ответственность и сделали объем работы фиче-команды из 5 человек. Жизненный цикл разработки (SDLC) сжался, но появилось новое бутылочное горлышко — человек. Чем быстрее агенты генерируют код, тем сильнее перегружаются бизнес-эксперты на валидации требований и лиды на ревью.

💡 Главные системные выводы, которые мы вынесли:

- Считайте людей, а не токены: Количество запросов в дашбордах легко раздувается автоматизацией одного инженера. Поэтому мы смотрим на регулярность. Главная метрика, которая предвосхищает готовность команды к переходу на Agentic Engineering — это когда 80% команды использует агентов 80% рабочих дней (с поправкой на отпуска и выходные).
- ИИ внедряется через Pull, а не Push: Насильно заставить использовать ИИ не получится, это вызывает только сопротивление. Сработали малые демо-группы и демонстрация конкретной пользы («сделаешь 30 DTO за 2 минуты вместо 2 часов»).
- AI не чинит сломанное: Недостаточно ускорить одну команду, нужно работать с системными ограничениями всего потока поставки ценности.

А на каком этапе внедрения AI находится ваша команда: пока просто тестируете чаты или уже решаете проблему перегруза на код-ревью сгенерированного кода? Делитесь в комментариях! 👇

Материалы к сегодняшнему выступлению на MergeConf Tatarstan 2026, можно не ходить, а просто посмотреть на презу :)

50 команд и 1 Учпочмак: масштабируемый рецепт эффективности

Статьи на Хабре

• Что такое эффективная команда, почему 91% сотрудников работают вслепую и причем тут «эчпочмак»? Модель «Учпочмак» подробно: три вершины, чек-лист диагностики, статистика. Текстовая основа доклада.

• Предсказуемость и метрики потока
Throughput: как научиться перестать гадать сроки и начать их предсказывать через Monte-Carlo Как использовать Throughput для вероятностных прогнозов. Закон Литтла в действии, Lead Time перцентили, симуляции.

• 5 причин, почему ваши Story Points не работают (и что делать) Почему переход на flow metrics (Cycle Time, Throughput, Lead Time, Aging) даёт более объективную картину, чем Story Points.

• Цели и Feature Factory
Уводим стартап от «конвейерной штамповки фичей». Включаем продуктовый подход и начинаем считать ROI Feature ROI Check и Engineering Cost Check — как понять, какие фичи создают ценность, а какие уходят в никуда.

Источники и литература по вершинам модели

Вершина 1: Цели

• Gallup — State of the Global Workplace gallup.com/workplace Ежегодное исследование вовлечённости.
• McKinsey & Company — исследования по strategy execution mckinsey.com/capabilities/people-and-organizational-performance
• Axios HQ — Employee Communication Report 2024 axioshq.com Исследование о степени согласованности целей сотрудников. Ищите их Annual Employee Communication Report.

Вершина 2: Люди

• Книга: The Fearless Organization (2018) — Harvard Business Review Press amazon.com → "Amy Edmondson Fearless Organization"
• Оригинальное исследование: "Psychological Safety and Learning in Work Teams" (1999) scholar.google.com → "Edmondson 1999 psychological safety"
• Реально виновных в намеренном вредительстве — 1–4%
Google — Project Aristotle rework.withgoogle.com
• Spotify Squad Health Check Model Авторы: Henrik Kniberg, Anders Ivarsson (Spotify). «Spotify Squad Health Check» → оригинальный пост Kniberg на Spotify Engineering blog
• Gallup — роль менеджера. В лучших организациях вовлечённость менеджеров достигает 79% против глобального среднего 22%. gallup.com/workplace

Вершина 3: Предсказуемость
• Daniel Vacanti — Actionable Agile Metrics for Predictability Книга — главный источник по flow metrics для Kanban/Agile.
• David J. Anderson — Kanban Книга: Kanban: Successful Evolutionary Change for Your Technology Business (2010)
• Little's Law L = λW → Lead Time = WIP / Throughput Оригинал: Little, J.D.C. (1961). «A Proof for the Queuing Formula L = λW». Работает для любых стабильных систем.
• Troy Magennis — Monte Carlo для Agile focusedobjective.com Вероятностное прогнозирование на основе исторического Throughput. Шаблоны и инструменты — на сайте (бесплатно).

QBR (Quarterly Business Review)

Atlassian — гайды по QBR atlassian.com/team-playbook Практические шаблоны для квартальных ревью с командами.

Инструменты

• Jira + OKR-плагины для
трассировки задач (OKR Board, BigPicture)
• Predictable Team - анализ и рекомендации по метрикам потока, прогнозирование выполненной работы методом монте-карло
• ActionableAgile Analytics - Flow metrics (Lead Time, Throughput) - из РФ нет доступа
• Monte Carlo Excel шаблоны, вероятностные прогнозы - focusedobjective.com

Марат Киньябулатов

• Телеграм-канал
t.me/predictableteam предсказуемость, метрики, управление командами.
• Habr: habr.com/ru/users/Eskimo
• LinkedIn: linkedin.com/in/maratkinyabulatov

🏳️‍🌈 Google теперь требует от PM-ов вайб-кодить прототипы прямо на собесах

🍷Классическая романтика продуктовой разработки полна уютных ритуалов:

- многостраничные описания в Google Docs,
- стратегические сессии,
- бесконечные груминги,
- детальные диаграммы пользовательского пути.

🧱Индустрия решила добавить в этот процесс щепотку сурового реализма и максимальной прикладной пользы.

TL;DR: Google обновил формат собеседований для продакт-менеджеров — кандидатов просят открыть Cursor и собрать работающий прототип фичи ровно за 45 минут.

Акаш Гупта любезно подсветил этот новый тренд в X. Процесс оценки уверенно перешел в плоскость создания осязаемых артефактов.

Кандидаты демонстрируют уверенное владение ИИ-инструментами и способность буквально на лету превращать концепции в кликабельный код. Привычные продуктовые фреймворки и красивые презентации теперь дополняются навыком быстрого «вайбкодинга».

Практика для команд:
Способность продакта самостоятельно собрать демо-версию радикально повышает прозрачность процессов. Прототип, созданный за час с помощью Cursor или Bolt, переводит обсуждение гипотез в предметное русло.

Команда разработчиков сразу получает осязаемый контекст, количество слепых зон на планировании стремится к нулю, а идеи обретают форму задолго до попадания в бэклог. Это отличный инструмент для снижения рисков и повышения общей предсказуемости поставки ценности. Навык самостоятельного ИИ-прототипирования уверенно занимает свое место в резюме рядом с CustDev-ом.

Чо как у вас с ИИ? Уже собираете прототипы сами, или пока просто изучаете инструменты? 👇