В продолжение темы про ИИ — наш второй пост о хакатоне персональных агентов-помощников BitGN. Платформу для него сделал наш бывший коллега Ринат Абдуллин, который сейчас живет в Вене. Огромное ему спасибо за такие классные инициативы!
В этом мероприятии я выступил как соорганизатор
- с Айгизом (автором колонки Homai и ML Engineer в TimeToAct),
- Вадимом (тимлидом TYIN и активным контрибьютором в AI community).
- Школа 21 Уфа (предоставили площадку).
а заодно прочитал мини-лекцию.
Ожидания и реальность
Помните, в прошлом посте я говорил про низкий уровень владения ИИ? На хакатоне это подтвердилось наглядно: около 80% пришедших участников до этого не ставили вообще никаких оболочек для работы с LLM.
Мой коллега и идейный вдохновитель хакатона сначала думал, что с установкой софта участники справятся сами и париться не стоит. Но я, наученный опытом внедрения ИИ в своем отделе, понимал, что без базы мы далеко не уедем.
Лекция и долгая установка
Пришлось сделать подробный вводный гайд. Мы разобрали, что такое LLM, токены и контекст, а затем пошагово ставили opencode (CLI/UI) и шли в OpenRouter. Отдельно учились брать бесплатные модели (nemotron 30b free), так как платные мало кто использует, а до китайских сеток люди вообще не добираются.
На прикрепленной фотке я в полуспящем состоянии читаю этот самый гайд по настройке оболочек. В итоге установка, которая в идеальном мире занимает 10 минут, растянулась на добрые полтора часа. 😄
Практика с агентами
Когда мы справились с инфраструктурой, началось самое интересное — запуск Python-агента сначала в песочнице, а потом в проде. Агент должен был выполнять задачи разного профиля, но делал это с заранее заложенными ошибками.
Участникам нужно было разобраться в его логике, найти баги и заставить агента работать правильно.
Крутые итоги
Получилось очень здорово! Мы фактически с нуля научили 35 человек пользоваться opencode и оплатили им доступ к модели GLM (за это отдельное спасибо @listl). Наши ребята попали в топ лидерборда и прокачались в создании агентов.
Дело за малым — осталось обучить технологиям ИИ остальные 1,1 миллиона жителей Уфы! 😄
Думаем летом сделать Vibe Code Night 🍾
В этом мероприятии я выступил как соорганизатор
- с Айгизом (автором колонки Homai и ML Engineer в TimeToAct),
- Вадимом (тимлидом TYIN и активным контрибьютором в AI community).
- Школа 21 Уфа (предоставили площадку).
а заодно прочитал мини-лекцию.
Ожидания и реальность
Помните, в прошлом посте я говорил про низкий уровень владения ИИ? На хакатоне это подтвердилось наглядно: около 80% пришедших участников до этого не ставили вообще никаких оболочек для работы с LLM.
Мой коллега и идейный вдохновитель хакатона сначала думал, что с установкой софта участники справятся сами и париться не стоит. Но я, наученный опытом внедрения ИИ в своем отделе, понимал, что без базы мы далеко не уедем.
Лекция и долгая установка
Пришлось сделать подробный вводный гайд. Мы разобрали, что такое LLM, токены и контекст, а затем пошагово ставили opencode (CLI/UI) и шли в OpenRouter. Отдельно учились брать бесплатные модели (nemotron 30b free), так как платные мало кто использует, а до китайских сеток люди вообще не добираются.
На прикрепленной фотке я в полуспящем состоянии читаю этот самый гайд по настройке оболочек. В итоге установка, которая в идеальном мире занимает 10 минут, растянулась на добрые полтора часа. 😄
Практика с агентами
Когда мы справились с инфраструктурой, началось самое интересное — запуск Python-агента сначала в песочнице, а потом в проде. Агент должен был выполнять задачи разного профиля, но делал это с заранее заложенными ошибками.
Участникам нужно было разобраться в его логике, найти баги и заставить агента работать правильно.
Крутые итоги
Получилось очень здорово! Мы фактически с нуля научили 35 человек пользоваться opencode и оплатили им доступ к модели GLM (за это отдельное спасибо @listl). Наши ребята попали в топ лидерборда и прокачались в создании агентов.
Дело за малым — осталось обучить технологиям ИИ остальные 1,1 миллиона жителей Уфы! 😄
Думаем летом сделать Vibe Code Night 🍾
🔥6❤1
🍷Классическая романтика продуктовой разработки полна уютных ритуалов:
- многостраничные описания в Google Docs,
- стратегические сессии,
- бесконечные груминги,
- детальные диаграммы пользовательского пути.
🧱Индустрия решила добавить в этот процесс щепотку сурового реализма и максимальной прикладной пользы.
TL;DR: Google обновил формат собеседований для продакт-менеджеров — кандидатов просят открыть Cursor и собрать работающий прототип фичи ровно за 45 минут.
Акаш Гупта любезно подсветил этот новый тренд в X. Процесс оценки уверенно перешел в плоскость создания осязаемых артефактов.
Кандидаты демонстрируют уверенное владение ИИ-инструментами и способность буквально на лету превращать концепции в кликабельный код. Привычные продуктовые фреймворки и красивые презентации теперь дополняются навыком быстрого «вайбкодинга».
Практика для команд:
Способность продакта самостоятельно собрать демо-версию радикально повышает прозрачность процессов. Прототип, созданный за час с помощью Cursor или Bolt, переводит обсуждение гипотез в предметное русло.
Команда разработчиков сразу получает осязаемый контекст, количество слепых зон на планировании стремится к нулю, а идеи обретают форму задолго до попадания в бэклог. Это отличный инструмент для снижения рисков и повышения общей предсказуемости поставки ценности. Навык самостоятельного ИИ-прототипирования уверенно занимает свое место в резюме рядом с CustDev-ом.
Чо как у вас с ИИ? Уже собираете прототипы сами, или пока просто изучаете инструменты? 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥3🤡2❤1
Echpochmak_efficiency-condensed_final.pdf
48.3 MB
Материалы к сегодняшнему выступлению на MergeConf Tatarstan 2026, можно не ходить, а просто посмотреть на презу :)
50 команд и 1 Учпочмак: масштабируемый рецепт эффективности
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
🔥11❤1
🤖 Почему внедрение ИИ не делает разработку быстрее? Наш опыт на масштабе моего подразделения (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 находится ваша команда: пока просто тестируете чаты или уже решаете проблему перегруза на код-ревью сгенерированного кода? Делитесь в комментариях! 👇
Все ждут, что 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 находится ваша команда: пока просто тестируете чаты или уже решаете проблему перегруза на код-ревью сгенерированного кода? Делитесь в комментариях! 👇
1🔥14👍2👏2
Kiniabulatov_Marat-AI-Adoption_DUMP_(bq).pdf
17.7 MB
Привет старичкам и всем новичкам ♥️
Преза с выступления сегодня на DUMP (о чем она - пост выше).
📚 Доп. материалы:
• Мысли вслух: Как AI-агенты меняют процесс разработки в разных типах проектов (Хабр)
• ИИ-ассистенты не ломают поддерживаемость кода. Но есть нюансы (выжимка из исследования Echoes of AI) (Хабр)
• Что такое ADKAR. - фреймворк управления изменениями в организациях
• Серия постов про внедрение AI (цель, изменения, мероприятия, события, ограничения)
- Изменение роли QA в эпоху ИИ
- Что такое эффективная команда и как на это смотреть на масштабе
Преза с выступления сегодня на DUMP (о чем она - пост выше).
📚 Доп. материалы:
• Мысли вслух: Как AI-агенты меняют процесс разработки в разных типах проектов (Хабр)
• ИИ-ассистенты не ломают поддерживаемость кода. Но есть нюансы (выжимка из исследования Echoes of AI) (Хабр)
• Что такое ADKAR. - фреймворк управления изменениями в организациях
• Серия постов про внедрение AI (цель, изменения, мероприятия, события, ограничения)
- Изменение роли QA в эпоху ИИ
- Что такое эффективная команда и как на это смотреть на масштабе
1🔥10✍2👍2❤🔥1
AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf
1.8 MB
🚀 Парадокс 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 в блоге Марата Киньябулатова про предсказуемые команды
Каждую неделю у меня по расписанию агент подкидывает все последние новости из 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 раз
🧠 Почему так происходит?
ИИ отлично генерирует код, но не понимает ваш архитектурный контекст. Инженер быстро
На ревьюера падает огромный кусок логики. Его когнитивная нагрузка зашкаливает (об этом я говорил на докладе на прошлой неделе). Итог: на 31% выросла доля PR, которые мёрджатся вообще без содержательного ревью (просто не глядя).
🛠 Что с этим делать тимлидам и руководителям?
1. Верните жёсткие лимиты на размер PR
Исследования (в т.ч. от Microsoft) показывают: PR больше 400 строк ревьюить бесполезно, мозг переходит в режим слепого скроллинга. Вшивайте в обвязку (agent harness) автоматические гайды и алерты на огромные многофайловые коммиты от ИИ.
2. Меняйте метрики.
«Строки кода» и «количество PR» больше ничего не значат (AI легко их накрутит). Смотрите на Code Churn (сколько строк пришлось удалить/переписать после мёрджа) и Incidents per PR (ошибок на PR - и аварий, и багов).
3. Инженеры-люди нужны как никогда.
Сокращать штат с мыслью «AI напишет код за них» — фатальная ошибка. Вам нужны сильные (senior) инженеры именно как надёжный буфер на код-ревью между ИИ-генератором и вашим продакшеном. Именно такие синьоры, которые умеют выстроить систему, которая будет справляться (качественно) с новым объемем артефектов от агентов.
В 2026 году выигрывает не та команда, которая генерирует больше кода, а та, которая смогла перестроить пайплайны ревью под эти сумасшедшие объёмы - заключает исследование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5💯2
Пока готовлю большой материал по 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).
Хорошая пятница, чтобы проверить: а ваш агент сейчас чем занимается? Роняли прод агентами на работе?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤3
Всем бодрого понедельника!
📣 На следующей неделе выступаю на People Sense (в Москве и онлайн) про Agentic Engineering (когда агенты делают за вас всю работу). А именно:
- Как сокращать время на разработку с помощью Agentic Engineering,
- Что такое AI-first команда,
- Почему всем это не подходит,
- Как трансформируются роли в команде при переходе в Agentic Engineering
🗞 Последние два месяца у нас была куча экспериментов, из которых я раскрою:
- Какие первые метрики для измерения эффектов от внедрения ИИ можно поставить в инженерных командах,
- Почему, несмотря на все ускорение команд мы все еще можем сталкиваться отсутствием системных изменений,
- Какие челленджи нам припасли руководители команд и почему все упирается в них.
Буду рад увидеть всех. Если есть какие-то конкретные вопросы, можно кидать их в комменты :)
👉 Регистрация по ссылочке 👈
Всем хорошей рабочей недельки (а жителям🗺 Башкортостана - хорошей сокращенной рабочей недельки)
- Как сокращать время на разработку с помощью Agentic Engineering,
- Что такое AI-first команда,
- Почему всем это не подходит,
- Как трансформируются роли в команде при переходе в Agentic Engineering
🗞 Последние два месяца у нас была куча экспериментов, из которых я раскрою:
- Какие первые метрики для измерения эффектов от внедрения ИИ можно поставить в инженерных командах,
- Почему, несмотря на все ускорение команд мы все еще можем сталкиваться отсутствием системных изменений,
- Какие челленджи нам припасли руководители команд и почему все упирается в них.
Буду рад увидеть всех. Если есть какие-то конкретные вопросы, можно кидать их в комменты :)
👉 Регистрация по ссылочке 👈
Всем хорошей рабочей недельки (а жителям
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥9❤3👍1
Хабр
Кейс. Zero Bug Policy: как мы снизили бэклог багов в 4 раза за месяц
Баги — неизбежная часть разработки. В этой статье расскажу наш опыт: как мы внедрили Zero Bug Policy в MetaMap (B2B fintech, ~200 человек в IT, распределённая команда, скоринг благонадежности...
🚫🐞 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 и тем, как это работает на практике. А также как это дело интегрировать в вашу компанию.
- Уменьшили бэклог с 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 и тем, как это работает на практике. А также как это дело интегрировать в вашу компанию.
1🔥6👍3
🤖 Маленькие 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, зарегулированных и отчетных - это пока еще вопрос.
❓ Есть ли у вас примеры того, как микро-команды работают или не работают
Я очень много слышу (и сам привожу примеры) о том, как AI двигает нас к микро-командам из 2-3-4 человек вместо 7+- 2 (по разным причинам: например сокращение координационной цепочки).
И почему-то когда мы приводим их в пример, мы забываем что там нет legacy, нет трёх уровней согласований, самый ранний доступ к моделям и инфраструктуре. Потом еще можно вспомнить uptime сервисов Anthropic (он невысокий) и понять, что они-то на стадии роста могут им жертвовать (а я в финтехе - не могу).
Это важный контекст, если думаешь о переносе паттерна в свою компанию.
Где точно круто работают микрокоманды - это прототипирование через vibe coding. Путь же от прототипа до прода — это тесты, security, observability, CI/CD, feature флаги, рефакторинг. И это все упирается в правильную обвязку, а выстроить ее - это понимать и исповедовать инженерную культуру.
🚵♀️ Третий год мы зачеркиваем предыдущие подходы: prompt engineering → context engineering → и вот сейчас harness engineering: проектирование сред, ограничения, циклы обратной связи, жизненный цикл агентов. OpenAI в феврале 2026-го написали, что их самые сложные задачи теперь именно здесь — в проектировании среды для агентов.
Короче говоря, команды из 2–4 человек работают в специфических условиях: greenfield, автономия, senior-состав, нет legacy. Это живой эксперимент, результаты которого ещё накапливаются. А работают ли они на масштабе в других средах: brownfield, зарегулированных и отчетных - это пока еще вопрос.
❓ Есть ли у вас примеры того, как микро-команды работают или не работают
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥3👍2
ppl_sense_ai-adoption-marat.pdf
2.7 MB
🤝 Всем привет, сегодняшняя презентация с People Sense - мы обсуждали проблемы перехода в Agentic Engineering.
Мы, вероятно, не успели покрыть темы:
- топ причин сопротивления внедрению ИИ в организациях;
- почему ИИ может привести к тому, что ваша компания станет Feature Factory на стероидах;
- как двигаться в сторону AI Adoption и Agentic engineering - если вы не готовы менять структуру команды.
Про все эти три темы будут отдельные посты.
Дополнительные материалы в этом посте
Или мне в личной телеге
Мы, вероятно, не успели покрыть темы:
- топ причин сопротивления внедрению ИИ в организациях;
- почему ИИ может привести к тому, что ваша компания станет Feature Factory на стероидах;
- как двигаться в сторону AI Adoption и Agentic engineering - если вы не готовы менять структуру команды.
Про все эти три темы будут отдельные посты.
Дополнительные материалы в этом посте
Или мне в личной телеге
❤8🔥6
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
Потихоньку закрываю темы, которые не успеваю озвучить на конференциях.
Исходя из новостей о стремительной замене людей ИИ-агентами думаешь: там страх увольнений, безопасность и недоверие к качеству моделей.
В отчёте причины лежат ближе к обычному рабочему дню:
1. человек не понимает, зачем это лично ему;
2. боится неизвестности и неловкости;
3. не знает, как начать;
4. чувствует, что его исключили из решения.
В нашей практике картина почти совпала.
Дали доступ всем — пришли единицы. Провели вебинары — люди послушали и вернулись к обычной работе. Сделали реестр инструментов — он стал ещё одной ссылкой, которую никто сам не открывает.
После этого фокус сместился с доступа к первому рабочему опыту.
🧩 1. Личная польза появляется на живой задаче
Для инженера (это любой сотрудник айти-команды) «AI-стратегия» слишком далека от реальной задачи. А уж как она далека линейным сотрудникам - думаю не надо и описывать :) Лучше работает конкретика: 30 boilerplate-классов за 2 минуты (не спрашивайте, зачем это надо), тест-кейсы по реальному тикету, разбор старого модуля перед задачей.
Практика: Это как научить рыбачить, вместо того чтобы сразу кормить. Примеры и выгоду показываем типовые для нужной когорты людей (ведь у всех ролей разные запросы), связанный с конкретными и рутинными задачами.
⛑ 2. Первый опыт должен быть безопасным
Люди редко задают простые вопросы на большом вебинаре. Маленькая группа, эксперт рядом, можно останавливаться, ошибаться и спрашивать про установку, доступы, промпт, ошибку в терминале.
В посте выше есть формат воркшопа и хакатона, которые тут помогут. Но пререквизит к этому: обязательно упростите установку кодинг-агента + доступов + нужных инструментов и mcp. В идеале shell-скриптом. А для сотрудников на винде сразу закажите админские роли. А для сотрудников на VDI - проработайте решение с безопасниками.
🎢 3. Первый маршрут лучше собрать заранее
Одна команда установки. Готовый сценарий запуска. Пример на реальном тикете. Понятные ограничения. Чеклист проверки результата.
Человек должен быстро дойти до первого маленького успеха.
Практика: Даем примеры, которые можно решить (чтоб не разочаровать, если пример не решится). Прогоняем воркшоп на подопытных, чтобы отловить типичные проблемы на каждом шаге. Не грузим кучей теории
🧠 4. Практика приживается, когда команда собирает её сама
QA собирают свои сценарии. Аналитики описывают свои артефакты. Разработчики формируют скилы для кода и ревью. Техлид показывает пример на собственной работе. Продакт учится самостоятельно делать прототипы.
Так AI становится темой нормального инженерного разговора: какие задачи отдаём агенту, где держим стандарт, где финальное решение остаётся за человеком.
Сопротивление AI часто начинается с нормальных вопросов команды.
Практика: Мы в обучении и вовлечении даем самый минимум. Скелет, фреймворк для использования. Когда у людей есть желание улучшаться (а в agile мы его воспитываем ретроспективами и культурой непрерывного развития) - при необходимых инструментах они сами учатся оптимизироваться. Важно создать среду для поддержки подобных благих намерений.
💅 Короче говоря: Хорошее внедрение даёт человеку первый маленький результат — и право попробовать самому.
Больше про работу с командами и внедрение ИИ в инженерку в блоге Марата Киньябулатова predictable.team
👍2